Hire the Domain-Switcher

Hey everyone, Neil here. You're reading High-Signal Hiring. Hiring systems from 20+ years of global recruitment experience and 500+ technical hires. Zero noise and instantly actionable.

Last week in Issue #26, I argued the Salesforce "no new engineers" headline was being read wrong, and that the engineer worth hiring is the one who handles ambiguity, not the one who closes well-defined tickets.

This week, a filter almost every founder applies on instinct, and it works directly against that kind of hire. The industry filter. "We need someone who's done fintech." "They have to come from a marketplace background." "No healthtech experience, no interview."

Applying it feels like diligence. What it does is quietly screen out the strongest candidates you could hire.

You'll learn why domain experience is worth far less than founders assume, why AI has made it cheaper still, and how to spot the switcher who'll outperform the insider.

Not a subscriber yet? Sign up here

When a founder tells me they'll only look at engineers from their own industry, what they're really doing is drawing a border around a tiny pool and then complaining that hiring is hard.

Think about who sits inside that border. The same engineers your competitors are chasing, at the same handful of companies, carrying the same inflated comp expectations. You've taken an already-thin early-stage talent market and shrunk it to a fraction of its size. Then you wonder why three months of outreach produced two lukewarm conversations.

There's a second cost, and it's the one founders rarely consider. The insider you finally hire arrives carrying the orthodoxy of the company you poached them from. They know how that industry is "supposed" to work, which is often the exact assumption you started a company to break. You wanted a fresh build and you hired the person most likely to recreate what already exists.

I covered the company-level version of this back in Issue #12, fishing in the wrong pond. This is the same mistake one level up, applied to whole industries rather than individual companies.

This is the part that has changed, and it has changed fast.

Domain knowledge used to be a real edge for a candidate. Learning the regulations, the data quirks and the customer behaviour of an industry took years, so paying up for someone who already had it made sense. That maths has shifted now that a strong engineer working alongside AI can absorb most of a new domain's context in weeks rather than years. If you read one thing next to this issue, make it getDX's piece on hiring for AI-native developers. It's the clearest writing I've seen on how the signal has moved, away from what an engineer already knows and toward how fast they can learn and apply it.

There's one honest caveat here. Not all domain knowledge is the cheap kind. If you're in a heavily regulated or safety-critical space, the deep compliance and regulatory knowledge still takes real time to earn, and a wrong assumption there can do genuine damage. So default to the switcher, unless your domain truly demands years of that hard-won depth. For most startups, it doesn't.

Once domain context becomes the cheapest gap to close, hiring mainly for it means paying a premium for the thing that's become easy to acquire. What stays scarce is the ability to reason from first principles, make good calls with half the information, and get up to speed quickly. None of that is industry-specific.

So if "has worked in my industry" is a weak signal, what's a strong one?

The first is fundamentals. Can the candidate reason about systems, trade-offs and failure modes from the ground up, rather than reciting how their last employer did it? Strong fundamentals travel across any domain, while memorised playbooks stay behind at the company that taught them.

The second is learning velocity. How quickly does this person get productive on something genuinely unfamiliar? The best evidence is a track record of having already done it, so an engineer who's crossed from gaming into fintech, or from hardware into pure software, has already proven the muscle early-stage work demands.

The third is the switch itself. People who deliberately move between domains tend to be curious and comfortable being a beginner again, and that temperament matters far more in your first ten hires than another year of industry-matched experience on a CV.

You don't need a new process for this. You need to point the one you have at the right target.

If you're running a loop like the one I laid out in Issue #19, Screening, then Mission and Depth, then Alignment, the adjustment is small. In the Depth interview, stop testing recall of your industry's trivia. Hand the candidate a real problem from your world and watch how they reason toward an answer they couldn't have memorised. An insider can fake familiarity with the right words, but nobody can fake clear thinking on a problem they've never seen before.

Test learning velocity directly too. Ask them to walk you through the last time they moved into an unfamiliar domain, how they got up to speed, and how long before they were doing real work. The strong ones have a deliberate system for ramping and can describe it. The weak ones describe being carried until it clicked.

There's one trap worth watching here. Don't let a candidate change too much at once. Switching industry is an asset on its own. Switching industry while also jumping two seniority levels and moving from big-company structure into seed-stage chaos is a stack of new variables landing on one person at the same time. Change one major thing and you've got an adaptable hire settling in. Change three at once and you've got a gamble. Keep the rest steady and let the domain be the part that's new.

The engineer who already knows your industry sits in a small, overpriced pool, and often turns out to be the one most likely to rebuild the thing you're trying to replace. The engineer who can learn your industry fast is sitting in a far bigger pool that nobody else is bothering to look at.

Stop filtering for where someone has been. Filter for how fast they can get to where you're going.

Cheers
Neil