A Tip for Recruiters

I work with a lot of recruiters (particularly tech recruiters). The vast majority of them are incredibly nice people who really are trying to help me fill a spot on my team. They’re able to get a job listing out and do the legwork of sourcing candidates, and after some trial and error, we can usually zero in on a candidate.

Some recruiters, however, are just awful.

There’s one recruiter right now (and, if you’ve ever talked to me, or had me return an email, it’s not you), who I will never do business with. Let me lay out the scenario, and see if you can figure out why.

  • Office phone rings, don’t recognize number, ignore and wait for voicemail
  • Cell phone rings, same number, no voicemail
  • Office phone rings, different number, ignore and wait for voicemail
  • Cell phone rings, that same number, no voicemail

That was within 2 minutes.

I did some googling, and it turned out that the number was a recruiter’s office I’d worked with before, and the other number seemed to point back to a particular person. Linkedin confirmed that person was a recruiter in that office.

Ok. Douchey, but I figured this person would leave a message or send an email, and then we could go from there.

Nope.

A few hours later?

  • Office phone
  • Cell phone
  • Office phone
  • Cell phone

This repeated every day for a week. And now it’s every other day or so. That’s just lazy. How hard is it to leave a voicemail, or send an email, or even send a stupid Linkedin message?

I’ve blocked the numbers on my cell phone. Shortly, I’ll do the same on my office phone. There’s enough recruiters who are willing to make my life easier (in exchange for the opportunity to make their company some money, and build a relationship). If you’re just trying to annoy me into answering the phone, why would I ever work with you?

Ah-gee-lay … it must be Italian!

Like all things that become the standard, agile[1]/scrum is seeing a bit of a backlash. I just happened across a couple of interesting posts that lay out interesting arguments against the new standards.

First, a long article from OK I Give Up:

This is actually my biggest gripe about Scrum. As mentioned above, in Scrum, the gods of story points per sprint reign supreme. For anything that doesn’t bring in points, you need to get the permission of the product owner or scrum master or someone who has a say over them. Refactoring, reading code, researching a topic in detail are all seen as “not working on actual story points, which is what you are paid to do”. Specialization is frowned upon. Whatever technology you develop or introduce, you are not allowed to become an expert at it, because it is finishing a story that brings the points, not getting the gist of a technology or mastering an idea. These are all manifestations of the control mania of Scrum.

I do think there is something nefarious to the godliness of points in the Scrum process (and the immediate, inarguable counter-argument that if it isn’t working for you, you’re doing it wrong).

Put in a slightly more graphical way:

Tasks

(Hilarious image from RobBomb)


  1. “Ah-gee-lay” – if you don’t get the reference, check out this video:  ↩

Open Floor Plans are (Mostly) Pure Marketing

Came across this post on open floor plans via Gabe at Macdrifter. The article is about labs, but I think it’s applicable to offices in general. Our new office has a major problem with not having enough quiet space. We moved from an office with lots of offices and meeting rooms to an office with fewer offices per employee and many fewer meeting rooms. The other side of that exchange? More “open space” and the serendipitous collaboration that theoretically results.

Open offices can work. Open offices can be beneficial. But there has to be a place you can go have a meeting, or go make a phone call, or go get some quiet work done. I’d worked in an office for 5 years before we moved into our new building, where I ended up trading an office for a cube. I don’t mind that (well, that much).

What I do mind is the inability to lock out the world and get work done when I’m on a deadline. With an office, or at a minimum, with a door, the act of shutting the door is a sign “Hey, I’m busy, it has to be really important.” It’s a simple mechanism to increase the friction required to interrupt you. And, as we all know, it works.

Cubes and desks don’t facilitate that. You are at your desk, you are fair game to interrupt.

Open offices aren’t inherently bad. They can and do foster collaboration. They can encourage the type of interactions that drive innovation. There’s a great presentation by my basketball comrade Bill Aulet about designing office space for innovation, and I think he’s right: you want a particular type of office for collaboration, innovation, and invention.

There’s also the famous discussion by Joel Spolsky on the need for private offices for developers. The gist: developers need the ability to work privately as they think through and work through the complicated tasks they’ve been tasked with solving. You can likely extrapolate that to many job roles.

As they say, everything in moderation. If you’re in an office where you require collaboration on a daily basis, and private work is the exception, an open office may be perfect. If you’re in an office where you’ve got a team on two week sprints and tight deadlines, the last thing you want is people having conversations and interrupting the entire team. There’s a balance.

And almost every open office space I’ve seen misses the mark. Our current office space did. There aren’t enough quiet places to go and close a door and get work done. The biggest thing I’ve done for my productivity in the past few weeks was use my seniority to claim a better cube and position white boards as movable walls. Now, people can’t actually tell if I’m at my desk, so they’re less likely to walk up and interrupt me, and will use email or IM (both media that I can ignore) to query me. If I need to work with a team, I can go to a space to collaborate. If you asked me to redesign our office space, I’d invert the ratio of open space to private space. I’d give people a place to work privately by default, and allow them many rooms to come together and collaborate. But, hindsight, 20/20 …

In the end, this is the most telling thing about open offices:

But no matter what, there’s one area that never does seem to turn into a big, open, collaborative share-space: wherever the higher-level executives work. Funny how that happens.

Ain’t that the truth.

(Via Macdrifter)

The LinkedIn Conundrum

Every few weeks, I log into LinkedIn and to accept/reject connections and clear out the stupid notices of people who’ve said I can do something well.

(I don’t think the people are stupid. I think the notices are stupid and spammy. Which, I think, you could say about pretty much 99% of LinkedIn’s email communications.)

I clear all the notifications, flags, messages, requests for human blood from LinkedIn and then I notice my profile is out-of-date. As I go to update it, I encounter The LinkedIn Conundrum.

“What’s The LinkedIn Condundrum?”, you ask? Good question.

The LinkedIn Conundrum (or at least, what I see as the conundrum …) is the desire to update your profile so that it at least reflects reality, but then the fear to do so because you don’t want it to look to your colleagues that you’re shining up your resume to look for a job.[1] Some people clearly don’t have this fear, and they update their profile one hundred times a day, outlining every new thing they’ve done in their job (“skills: getting coffee four times a day without anyone noticing I’m away from my desk”). There are certainly others, and I fall into this category, where I struggle over whether to update my profile at all, fearing that someone will assume I’m looking for a job. So instead, my profile stays there, frozen in carbonite, forever out of date.


  1. The corollary to The LinkedIn Conundrum is the same fear whenever you accept the connection of a recruiter on LinkedIn, which clearly makes people think you’re talking to a recruiter, when in reality, you’re just accepting some connection to a recruiter who reached out to you, or you’re using for sourcing. Of course, none of this would be a problem if it was socially acceptable to not connect with everyone on LinkedIn, but that doesn’t seem to be the societal norm. Though, I do, on occasion, not accept a connection, if only to exert some feeble power over the LinkedIn borg.

     ↩

Solve the Problem You Have, Not the Problem You Think You Have

One of the things that I’ve been struggling at work is helping get projects and people aligned around solving for the right thing. Sometimes (possibly often …), a request will come in that reads something like:

I want you to build a hovercraft, because people have a need for travel, and a hovercraft satisfies that need.

And that’s fine, right?

Except, in this scenario, building a hovercraft doesn’t really solve the problem of travel. It is a possible solution, but it’s a really complicated solution that maybe can’t get delivered for years (we have to invent hovercraft technology). Maybe a bike would solve the problem? That would be easier. Maybe we don’t need a vehicle at all—maybe we just need shoes.

This is a ridiculous example, but hopefully the point is clear. It can be hard to convince people that they’re trying to solve the problem they want to solve (or worse yet, that they’re simply solving the problem they think they have).

I’ve found this is common in tech organizations where you’ve got folks all around who are somewhat technical, and they get stuck on an idea, and that idea becomes the solution to every possible problem.

Man, it takes us too long to build stuff. We should setup some really complicated technological process that allows us to more easily build stuff.

The problem there is well stated. It takes too long to build stuff. The solution, however, is solving the problem that the person believes exists: that the lack of some technological process is the real cause of the “taking too long” problem.

That is, more often than not, a fallacy. Everyone gets hung up on the solution. The challenge is to help people get hung up on the problem: what is the issue, how does it manifest itself, what is the pain, etc.

I’m as bad as anyone at this. My brain starts making connections and rapidly gets to the point that I believe I understand the problem and that I’ve figured out the optimal solution (the biggest bang for the buck solution, in my mind). In thinking about this, I came across this quote:

If I were given one hour to save the planet, I would spend 59 minutes defining the problem and one minute resolving it

Albert Einstein was pretty clever.

Challenging

A couple of months ago, I changed roles (part time) in the company. I moved to a team with the premise that a small team of developers, unencumbered by the process and inertia of a large company, could develop and iterate on products and find things that were good fits for our customers. In a big company (which my little company now is), it was a great—maybe ideal— opportunity. A small, (little a) agile team cranking out product.

As of two weeks ago, I’m back in the main office, managing the entire team of developers, while in the midst of the business adopting the (big a) Agile methodology. It’s probably been two of the most challenging weeks of my career.

Our development process was never “waterfall”, but it wasn’t “agile”. It was some in between mish-mash of working on what was important and reprioritizing weekly without the understanding that not everything deserved to be worked on. Not everything was important to the business. Loads of horse trading so that everyone got their slice of resources, without regard to how much value those resources might generate for the company.

In that regard, agile (or maybe that’s Agile) has definitely helped. We’re slowly helping people realize that we don’t have infinite resources, and therefore, we can only work on the really important stuff (and maybe some slightly less than really important stuff). But no “because I want it” stuff.

It’s not been easy. It’s been a slog. As a company, other parts of the business (not the development team) are still getting on board, which is a challenge. There’s the culture clash: do you bridge the gap between the old process and new, or push everyone in the deep end. The former means slower adoption, the latter can lead to some interesting conflict.

All this is going on while still needing to ship code and re-learn how to manage a team of people. With some people pushing to move faster than the organization (and team and individuals and processes and technology) might be ready to.

It’s going to be an interesting challenge.