Why diverse engineering teams outperform, and why most businesses aren’t serious about it

MH
Marie Higgins Product and Engineering Search Partner
March 2026
6 min read

Most corporate D&I programs failed. Not because the idea was wrong, and not everywhere. Some businesses genuinely get it right and the overall direction of travel has been positive. But the majority of D&I initiatives that launched over the last decade were never treated as commercial initiatives. They lived in HR programs, marketing campaigns, and compliance exercises. Peripheral activity run by teams that didn’t own a P&L and couldn’t draw a line between what they were doing and what it was worth to the business. The economy tightened and they were the first things cut. That tells you everything about how seriously they were ever taken.

The thing is, diverse teams genuinely do perform better. The evidence is there and the commercial logic is sound. But that only matters if you hire for it with the same rigour you’d apply to any other decision that affects your bottom line. Most businesses didn’t. They ran diversity as a brand exercise, and they’re proving that right now by dropping it the moment things get tight.

The commercial case that never got made

The reason most D&I programs collapsed so quickly is that nobody built the commercial case underneath them. There was a moral argument, a reputational argument, and a compliance argument. All real. None of them survive a board conversation about cost reduction because none of them connect to revenue, margin, or delivery quality in terms a CFO can point at.

The commercial case for diverse engineering teams is straightforward. Teams made up of people with different backgrounds, different operating contexts, and different ways of framing problems catch failure modes earlier, challenge assumptions that homogeneous teams take for granted, and produce more resilient technical outcomes. That isn’t a nice idea. It shows up in the quality of architecture decisions, in how quickly a team identifies risk, and in whether the product actually works for the full range of people using it.

I’ve seen this play out enough times to know the pattern. The engineering teams that consistently deliver the best commercial outcomes aren’t the ones stacked with the strongest individual contributors on paper. They’re the ones where someone in the room sees the problem differently from everyone else, and the team is set up to use that rather than ignore it.

But the performance advantage doesn’t materialise just because you’ve got a mix of people in the room. It shows up when the team has the working practices and the leadership to turn different perspectives into better decisions. Composition creates the conditions. Culture determines whether the advantage actually lands.

What it costs when everyone thinks the same way

The cost of a homogeneous engineering team is usually invisible because it looks like everything working well. The team agrees quickly, ships predictably, and nobody raises difficult questions. From the outside that looks efficient. From the inside it often is efficient, in the narrow sense that decisions happen fast when everyone already agrees.

The problem is that quick agreement isn’t the same as good decisions. A team where everyone shares the same mental models will optimise for the same things, underweight the same risks, and build solutions shaped by one set of experiences when several were needed. Over time this produces a specific kind of technical debt: not the kind you can see in a backlog, but the kind baked into design choices that nobody questioned because nobody in the room had a reason to.

This plays out most visibly in platform and infrastructure teams where the original architecture was built by engineers with very similar backgrounds. The patterns they chose were sound within their frame of reference but didn’t account for scale challenges, accessibility requirements, or integration constraints that someone with a different operating context would have flagged in week two. By the time those gaps surfaced, the cost of addressing them was structural.

That’s a commercial outcome. It hits timelines, it hits budgets, and it creates the kind of rework that boards ask hard questions about. The businesses that avoided it weren’t running D&I programs. They were hiring deliberately for teams that could see the problem from more than one angle.

Why the hiring process works against you

If diverse teams produce better outcomes, the obvious question is why most engineering teams aren’t particularly diverse. The answer usually isn’t intentional bias. It’s that hiring processes are built in ways that systematically favour similarity, and the people running them don’t notice because the results look normal.

The most common one is “cultural fit” as a selection criterion. In theory it means someone who’ll work well with the team. In practice it often means someone who reminds the hiring manager of the people already there. The language is vague enough to pass without scrutiny and specific enough to filter out anyone who doesn’t match the existing profile.

Technical evaluation is the second. Whiteboard coding exercises and timed algorithm tests measure a specific skill set under specific conditions. They’re reasonable proxies for some aspects of engineering capability, but they’re poor proxies for how someone will actually perform building real products under real constraints. The candidates who do best in these formats tend to be the ones who’ve had the most practice with them, which correlates more with background and access than with engineering quality.

The third is referral-heavy sourcing. Referral networks are efficient and produce candidates who are already trusted by someone on the team. They also reproduce the team’s existing profile because people refer people they know, and people tend to know people like themselves. That’s not a reason to stop using referrals. It’s a reason to make sure they’re one channel among several.

None of these require anyone to have bad intentions. They just need to go unexamined, and they usually do.

What hiring for performance actually looks like

This isn’t a process overhaul. It’s being honest with yourself about where the gaps are and treating team composition as what it is: a commercial decision that affects delivery quality.

Start by looking at the team as it is and asking a direct question: where are we all the same, and what might we be missing because of it? That question is uncomfortable, which is why it gets asked so rarely. But it’s the most practical starting point because it connects the diversity conversation directly to the engineering outcomes conversation.

From there, three things make a real difference.

Structure evaluation so each interviewer assesses independently before the group discusses. The first strong opinion in a room shapes everyone else’s assessment. Independent scoring first, discussion second, produces more accurate outcomes. It’s low cost and easy to implement.

Expand the sourcing pool deliberately. Go beyond referrals and job boards into community networks and specialist groups where candidates with non-traditional backgrounds are actually present. It’s more work. It also surfaces candidates the standard process would never find, and some of those candidates are exactly the people who’d bring the different thinking the team needs.

Write role descriptions that describe the problem the hire needs to solve, the context they’ll operate in, and what good looks like in practical terms. Overly specific requirements lists, framed around years of experience with particular technologies, filter out strong engineers who have the capability but not the exact CV pattern.

Team composition is a commercial decision

This ties to something we believe about every technology hiring decision: team composition should be treated with the same rigour as any other commercial decision. That means hiring for the perspectives and capabilities the team actually needs, not defaulting to a process that reproduces what you’ve already got.

Most D&I didn’t fail because the idea was wrong. It failed because it was never given commercial ownership. The businesses that build the strongest engineering teams won’t be the ones with the best programs. They’ll be the ones that treat diversity as a hiring discipline, not a side project.

Frequently asked questions

The opposite. Hiring for genuine diversity of thought and experience means expanding where you look and how you evaluate, not accepting a lower standard. The bar stays the same. The difference is you’re assessing against it properly rather than filtering out strong candidates because they don’t match a narrow pattern. The teams I’ve seen built this way have a higher average quality because the sourcing pool was wider and the assessment was more rigorous, not less.
Speed matters in hiring, and building a broader sourcing pool does take more effort upfront. But the time investment is front-loaded. Once you’ve built relationships with a wider range of communities and networks, the sourcing pipeline runs at the same pace as any other. The real cost of speed-first hiring is ending up with a team that can only see the problem one way, and that cost shows up later in rework, missed risks, and architecture decisions that didn’t hold up.
Stop using “cultural fit” as a selection criterion and replace it with something specific: can this person deliver in this environment and work productively with people who think differently from them? That one change shifts the entire assessment from pattern-matching against the existing team to evaluating whether the candidate actually makes the team stronger. Everything else, sourcing, evaluation design, role descriptions, matters too. But reframing what “fit” means is where it starts.
MH
Marie Higgins
Founder & Product and Engineering Search Partner, Innova Search
Marie specialises in building high-performance engineering and product teams, with a focus on diverse hiring that drives better commercial outcomes.

Starting a technology leadership search?

The brief is where it begins. Let's get it right.

Start a conversation