The challenge of hiring experienced developers

Hiring is likely the hardest, most time-consuming aspect of building a team. Hiring experienced team members (tech leads, architects) is especially challenging, and often fails. Why is that the case, and what can you do about it?

Why it fails (officially)

From working with and talking to a range of teams, I’ve heard a few answers regularly mentioned:

  • Experienced people are just happy where they are currently employed - they’ve tried a range of companies and jobs during their career, and have settled in one which ticks their boxes

  • They’re not interested in new challenges - they’re likely married with children by now, so wouldn’t want to disrupt this with a new challenge

  • They have a pretty precise and narrow area of expertise or interest, even ‘niche’ - something you’re unlikely to cater for

  • They’re comparatively very expensive - with many years of experience, their expectations are really high

  • We ended up compromising and hired someone who whose quite good, and that we could afford - but (s)he didn’t turn out so great

All of which makes sense. But I suspect there is another, underlying reason.

Two pyramids

Most tech leads (whether CTO or team lead, whether in a startup or a more established company) typically want to create balanced and harmonious teams.

Such a team would include a couple of experienced team members, a couple of graduate or ‘junior’ people, and a few more whose experience sits somewhere in the middle. With the idea that the least experienced developers can learn from the intermediate ones, the intermediate ones from the most experienced. And that these most experienced ones have an overall ratio of about 1:3. So something like this:

Screen Shot 2018-02-06 at 13.53.05.png

Back in the real world, software engineers, once they get into this industry, tend to follow one of many different career paths.

Some will quickly find out that it isn’t what they expected, it was just a mistake. Others will maybe get a good first experience, but eventually will have a bad enough one to fall out of love with it. Others will after several years have a change of vocation: it turns out they really want to setup a restaurant, go travelling, etc. Or they will fancy becoming a Scrum Master, or a Product Manager. Maybe this will be combined with finding out they’re just not so great at development, or some personal issues will sadly get in the way (illness or worse). All in all, this means that the available talent pool looks more like this:

Screen Shot 2018-02-06 at 13.53.15.png

Now, putting the 2 pyramids side-by-side, there is a clear mismatch between what employers are looking for and who’s available. That’s not to say that hiring great junior developers is easy (it isn’t), but that it’s relatively harder to hire more experienced developers and keep a balanced team.

Screen Shot 2018-02-06 at 13.49.12.png

So what’s the solution?

There isn’t a magic wand to waive at this challenge. But there are a few steps you can take to address it:

Ask yourself if you genuinely need a balanced team

Would a single, good technical lead (architect) provide enough technical guidance to the team? Are you genuinely looking for very broad and rich experience, or more for talent that a less experienced person can provide?

Have crystal clear objectives for your experienced hires

Do they really need to do line management? Not many candidates may like this or be good at it. Do they really need to mentor other developers, and how many of them? Less experienced people can be very good mentors, and mentoring can be two-ways anyway.
In any case, make these objectives very clear in your job description, and follow up on them with whoever you end up recruiting. Use the objectives in reviews and 1-on-1s, don’t just hope it will happen. And do give the person credit when they achieve them.

Look for a star, not a superhero

Many times I’ve seen a huge burden of hopes dropped on the shoulders of an experienced, but brand new, team member. “He/She will solve our scalability issues, coach the 3 juniors, sort out support and code more quickly.” This is bound to lead to disappointment. Instead, focus on the 1 or 2 key areas where you feel there is a gap to fill, and find the best person for this. If you hire someone who ends up doing even more, consider it a bonus.