Earlier this year an associate engineer and an intern were added to my team. I am generally in favor of giving junior engineers the opportunity to learn and upskill themselves “on the job”, as it were, but it had a snowball effect on the team that I hadn’t fully anticipated.
The senior engineers on the team started writing things down. Not that they didn’t write loads of good stuff before of course (solution previews, architectural decisions, etc.), but not this stuff: the kind of documentation that senior people always mean to write and rarely get around to, because everyone already knows how things work. Except of course they don’t, not really. A lot of it was living in people’s heads, and it took two people joining who needed to actually read it before that became obvious. Pair programming picked up too, not just to onboard the new arrivals but between the seniors as well. Quick Slack answers started turning into actual conversations. Then our new hires started building things, fixing things, asking questions that sometimes turned out not to have good answers, and within a surprisingly short time both had made themselves genuinely valuable to the team.
Our delivery speed went up. Quality went up. Not in a way that could be explained just by having two extra people. Something else was happening.
What diverse experience actually does
There’s a version of the diversity conversation that people tend to tune out. The one that’s mostly about representation and compliance. Those things matter of course, but if that’s the whole argument it sounds like a constraint rather than anything meaningful. The more compelling case is just simpler: teams with different experiences are technically better at the job.
Think about what an engineering team actually does when it’s working well. It’s not just running known solutions against known problems. It’s diagnosing situations that are genuinely ambiguous, making trade-offs under uncertainty, spotting failure modes before they bite, sometimes inventing an approach that didn’t exist before the problem did. All of that gets better when the people in the room have different technical histories to draw from.
Someone who spent years in high-traffic consumer products thinks about scale differently to someone who came up through embedded systems or healthcare. Someone who worked at a startup where everything was always on fire has different instincts about pragmatic trade-offs to someone who came from an enterprise environment where stability was everything. A developer who’s spent time on the receiving end of a badly documented API brings a specific kind of empathy to API design that training doesn’t really replicate. These aren’t just different opinions. They’re years of encountering problems in different contexts, building intuitions that their teammates don’t have yet.
The same thing applies beyond engineering backgrounds. The engineer who spent time in product management thinks differently about scope. The one who did a year in support knows instinctively what confuses users. The one with lived experience of systemic bias (race, gender, culture, neurodiversity, you name it) hightens awareness of where the product fails to be equitable or how it might inadvertantly disadvantage a particular group. The one who came from a data background asks measurement questions the rest of the team might not think to ask until it’s expensive to find out.
The all-senior team isn’t the gold standard
What I saw on my team this year lines up with something the research on team composition has been pointing at for a while, which is that the all-senior team is not actually the high-performance setup most engineering leaders assume it to be.
LeadDev’s analysis of team composition identifies a failure mode that felt familiar to me: pack a team with highly opinionated, experienced engineers and you can end up with more conflict than collaboration. Seniority brings expertise, but it also brings the accumulated bias of having solved problems a particular way for a long time. Junior engineers tend to question existing approaches more readily, not because they don’t know what they’re doing, but because nobody has yet convinced them to stop asking why. They also tend to have more current knowledge of tools and methods than engineers whose habits formed ten years ago.
What I watched happen on my team is almost exactly what Tito Sarrionandia wrote about from his time building UK Government digital services. The junior arrivals created a multiplier effect. Not just through their own output, but by improving how the whole team worked. Workarounds that senior engineers had long since stopped noticing became visible when someone new had to navigate them. Fixing them made things better for everyone. Documentation that nobody had gotten around to became necessary when someone actually needed to read it. And the curiosity they brought, the genuine enthusiasm of people who haven’t yet grown tired of the work, turned out to be contagious. I watched experienced engineers seem to rediscover why some of this stuff is interesting.
The research backs this up. A meta-analysis in the Journal of Management found consistent evidence that diversity in expertise level improves team performance by widening the range of approaches a team can bring to a problem. An all-senior team isn’t stronger. It’s more brittle, and more static.
Hiring for coverage rather than comfort
Left alone, most hiring managers, and I’ve been guilty of this, tend to hire people who are easy to work with. And easy to work with usually means thinks similarly to me. You end up with a team that has good chemistry and a reliable set of blind spots.
Being intentional about diversity means asking different questions than the ones hiring processes usually ask. What kinds of experience is missing from the team? Who has worked closest to the customer, and who has spent the most time furthest away from them? Where does the team’s collective instinct tend to let it down? Those questions have real answers, and the answers should shape who you hire.
It also means genuinely making space for the voices that don’t naturally fill a room. The engineer with two years of experience rather than ten may be the least confident about pushing back on the consensus, but they’re also often quite likely to be right. We often talk about “safe spaces” but this needs to be a genuine thing, not a pro-forma. Culture Amp’s research found that employees who believe their company genuinely values diversity are 86% engaged, compared to just 20% among those who don’t. People can tell when inclusion is real and when it’s being performed. And they respond accordingly.
None of this happens by itself. What I keep coming back to is that the value of having different perspectives on a team only shows up when the environment makes it safe to actually use them. In the next post in this series, I will dig deeper into what technology leaders can do to ensure such an environmnent.
Part 2 of a series on building technology teams that perform. See part 1: How diversity, engagement, and performance strengthen each other. Part 3: Engagement as a performance lever for team leaders