Don’t Lower the Bar, Widen the Net

A handful of our clients work in very specialized industries, or are often looking for talent where the number of candidates who will have expertise in a specific area is very small – even in a large software town like Seattle.

It could be small for a few reasons:

–It’s a new technology, or new enough that companies are either just starting to test it for production use or are doing their first deployments, so nobody has a track record of success; today, for example, the number of engineers with significant experience doing successful node.js deployments is much smaller than the number of companies that want to try.

–There are only a small number of local companies that ever need that technology, and so there’s no incentive for people to keep working in it; Windows device driver development, generally done by just a few Microsoft vendors, is a great example.

–It’s always been small – new engineers with this skill are effectively at replacement level.


Whatever the reason, hiring for these roles – especially if you need them all the time – can be frustrating: you feel like you’ve talked to everyone in town (mostly because you have). There are a few disciplines where I’m certain that we have the names and resumes for 100% of the discoverable engineers in Seattle in our database.

When a company gets into this role, there’s a lot of pressure – especially from people who are directly measured by their hiring, like internal recruiting and HR teams – to lower the bar: “I know that Bob didn’t pass our C development test, but he was sort of close, and we can’t find anyone as good as our current team – they just don’t exist!”

We all know how this one ends: unhappy engineers, unproductive delivery teams, and disappointment. Engineers do, and should, fight this urge – but that doesn’t get you closer to delivery.

If you find yourself in this place, don’t lower the bar, widen the net. (Or to avoid mixing metaphors: go broad, not shallow.) Find skills that are reasonably complementary and accept the cost of training (or enabling self-training) – and evaluate the candidates for learning potential (mostly with behavioral questions, plus asking them a few things out of their comfort zone to see how they puzzle through). Need ARM Cortex-A9? Look for someone who’s done any constrained development in the last 10 years. Need node.js? Look for server-side and dynamically-typed language experience (i.e. hire that Ruby guy).

This includes contractors: the problem is the same, and while it’s painful to eat the cost of training, it’s often more painful to never get things done.


This isn’t rocket surgery, and it’s not the same thing as hiring for “raw smarts,” which can feel painful for small companies or companies under pressure to deliver (and everyone should be). You should be able to draw a bright line from the technology you need to the technology the candidate brings – but if they bring it, and they’re good at it, then hire.

(Did I write this post so I could do cool stuff with Paper, co-founded by a Friend of Rooster Park, and because I heart what Stratechery is doing? Perhaps. Also, it’s been a while. Hello!)