I left Sainsbury’s a couple of months ago and spent the summer recharging, relaxing, and enjoying some time off. Along the way I’ve had a steady stream of conversations with former colleagues and recruiters who’d heard I was “on the market”.

I haven’t been seriously looking for work in years, and I wouldn’t say I’m doing much of it now, but I am paying more attention than before. And one thing has stood out to me.

A lot of job descriptions specify that candidates must have experience in the company’s particular industry. banking, fintech, insurance, government, retail – you name it. Recruiters also often ask me what industry I want to work in next. Maybe I’m the odd one out here, but across a career that’s spanned banking, insurance, retail, government, manufacturing, and big tech, I’ve never thought first about industry. I’ve always looked for interesting problems to solve, new technology to use in anger, or people I’d enjoy working with again.

For me, technology is the industry. Good software engineering is good software engineering regardless of context, and it’s similar to for delivery , architecture, and team management. Sure, one sector might emphasise security, another scalability, another performance. Regulations and non-functional requirements vary too. But those are all learnable variables, not the heart of the craft.

Which makes me wonder how many great people get excluded from candidate pools because we’ve baked industry-specific requirements into job specs that don’t actually need them.

When I moved from highly secure CRM systems at an investment bank to manufacturing governance, the core engineering principles were identical. What changed was the vocabulary and the compliance frameworks, not the fundamentals. And some of the most innovative solutions I’ve seen came from people who carried lessons across sectors. Cross-pollination creates breakthroughs that industry lifers might miss because they’re stuck in “we’ve always done it this way” thinking.

That’s why it frustrates me when hiring managers conflate domain knowledge with engineering competence. Compliance frameworks matter, but they can be learned. The team that can build a system that processes millions of transactions reliably will figure out the rules. The one that knows every regulation but can’t design for scale won’t succeed, no matter how much sector experience they have.

This need with industry experience also betrays a lack of confidence in onboarding. If a capable colleague can’t learn your business domain in a reasonable timeframe, what does that say about your knowledge management and processes? Some of the best people I’ve worked with were the ones asking questions that exposed assumptions nobody had thought to challenge.

The talent market is tough enough without making it smaller. Demanding five years of sector experience for a role that’s essentially about building APIs that happen to perform a specific function is a miss. It prioritises familiarity over capability, which is the opposite of what an innovative industry should be doing.

The best people I’ve worked with have always been problem solvers first, domain experts second. Rigour, curiosity, and technical excellence translate everywhere. The industry knowledge follows.

Maybe it’s time to start hiring for excellence and teach the domain, instead of the other way around.