Make hiring everyone’s business

Let me tell you a typical hiring story. A bit more than 10 years ago, I was contractor at a bank on a C++ front office application. The system had initially been well engineer, but it had been stuffed together merged with another system that had a completely different architecture. Ha, and there were no automated tests. As you’d guess, we had quite our dose of bugs, and maintaining this application was not easy.

The manager wanted to hire a C++ programmer to beef up the team. Along with the division’s architect he was conducting interviews to find just that guy. A few weeks later, he found a known C++ & Windows local expert. A few weeks later, the team unanimously declared that we could not work with him because he was both pretentious and incompetent.

I’m pretty sure every developer already witnessed a similar story.

Managers do the hiring

This is the usual practice. The motivation is that managers have more experience so they should be better at it, and also that it alleviates developers from non-programming work. As we saw in the introduction story, there are issues with this approach too :

• it’s pretty bad for the team ‘fit’ : there is no team building here. You often end up with a collection of individual working at the same place rather than with a real team.
• during these interviews, the candidate only interacts with a particular type of profiles, who can tell how he’ll be doing with more junior team members for example ?
• as usual, this administrative work removes some programming from the manager’s time. That’s often not a good bargain
• it decreases the team sense of control, as it is being ‘forced’ to work with someone they did not choose. This makes it harder for them to take responsibility of what they are trying to achieve.

How we self organized hiring

As I already explained in a previous post we engaged in various self delegation initiative by doing a delegation board. During this meeting, we identified hiring as something that could be self delegated.

In order to fix that, we started a workshop for 1 hour per day with a sub group of the team. We started with a brainstorming, then we voted, and finally presented our proposition to the rest of the team, which actually validated it. The whole thing lasted for one week (5 hours).

What we decided for hiring

Here is the process we have decided to follow to handle hiring team members

1. First, everyone in the team is responsible to speak up when he thinks we need to hire someone, during our retrospectives for example
2. To handle new applications, we have prepared an online interview. It contains open questions and online coding exercises, on cyber-dojo, which allows us to track all the candidates iterations
3. We do a round robin to find out who will follow the candidate through the hiring process. This means taking notes, organizing interviews, keeping the rest of the team up to date.
4. When a candidate passes the online interview, we will receive him for an technical and general interview with 2 people from the team.
5. All the team will then meet the candidate for a coffee break, in order to know if he will fit in the team
6. We’ll then play the Google hiring committee until we reach a consensus
7. When in doubt, we’ll do extra interviews, and repeat

That’s just what we came up with, if you start this road, you might well come up with a very different process.

One more thing

It’s great to have a selective hiring, but you’ll also need to improve the input of the hiring pipeline, but that’s another story …

Stay up to date with content and upcoming products

I usually write about 15 minutes worth of reading per month. I won't transfer your email. No Spam, unsubscribe whenever you want.

As a gift for subscribing, you'll receive an illustrated mini-ebook "How to start a team coding dojo"!