Most engineering hiring I’ve seen is reactive. A headcount opens up, a requisition gets approved, teams scramble to put together an interview loop, and everyone is focused on filling the seat as fast as possible because there’s work waiting. The question being asked is: who can we get, and can they start soon?
That’s not a hiring strategy. That’s a response to a vacancy.
I remember a stretch at Capital One when active headcount was limited and the pressure was to hold the line rather than grow. Instead of treating that as a quiet period, I stayed in deliberate contact with a handful of engineering leaders I’d worked with and respected — occasional check-ins, sometimes sharing something relevant to what they were building. When significant headcount opened up several months later, I had a short list of people I already knew and trusted. One of those conversations turned into our strongest hire of that cycle. The difference wasn’t luck. It was that I hadn’t started from zero.
Strategic hiring starts with a different question: what does this organisation need to look like in eighteen months, and what kinds of people do I need to bring in now to get there? The answers to those questions might lead you to the same candidate, or they might lead you somewhere very different.
When I’m thinking about my org’s composition over the next year or more, I try to map the gaps that aren’t yet causing pain but will. If I’m building out a capability that doesn’t exist yet — a new technical domain, a new layer of the stack, a function the org hasn’t owned before — I need to bring in leaders who can build that capability before the business is depending on it, not after. Hiring reactively into a gap that’s already painful means the person you hire starts behind from day one, carrying both the ramp time and the pressure of an unmet need.
This requires a certain kind of faith that not all organisations support, which is: spending headcount budget on problems that aren’t yet on fire. The way I’ve made this argument to leadership is by translating the future gap into a current cost. If my org is going to need a capability by Q3 and it takes four to six months to hire and ramp someone, I need to start that search in Q1 at the latest. If I wait until Q3 when the need becomes urgent, I’m paying for a gap I could have closed six months earlier.
The second thing I try to get right is the interview process itself, which in many engineering orgs is a theatre performance that both sides have learned to play. The candidate has read the prep guides, the interviewers ask the standard questions, everyone performs their assigned role, and at the end you have data that’s mostly measuring how well the person prepared for this specific performance rather than how they’ll actually operate in your org.
One change I’ve made that I think meaningfully improves signal: replacing part of the technical interview with a conversation about a technical decision the candidate made on a past project. Not a hypothetical — something they actually did. I ask them to walk me through a call they made that turned out to be wrong, or a tradeoff they made that they’d make differently now. What I’m listening for isn’t the technical content specifically. It’s how they reason, how they take ownership of outcomes, how honest they are with themselves about what they didn’t see coming.
This question separates people more reliably than most algorithmic problems, because it requires actual experience and actual reflection, not preparation for an expected format. The candidates who do best on this question tend to be the ones who are comfortable with complexity and uncertainty — which is most of what senior engineering work actually involves.
The pipeline also matters in a way that single-hire thinking misses. If you only activate your network when you have an open req, you’re always starting from zero. The leaders whose orgs consistently attract strong people are the ones who are always, at some low level of effort, maintaining relationships with good engineers and engineering leaders — people they’ve worked with before, people they’ve met at conferences or through collaborators, people who aren’t looking right now but might be in a year. When a req opens, they’re not starting from a cold search.
I don’t think this requires a lot of time. It requires some intentionality — occasionally checking in with someone you respect, staying engaged in communities where strong engineering leaders spend time. But it pays off disproportionately when you need to hire quickly and you already have a short list of people you trust.
Reactive hiring fills seats. Strategic hiring builds orgs — and the compounding difference, over a few hiring cycles, is the gap between a team that’s always catching up and one that’s always ready.