The best team I ever worked on had a loudmouth, a worrier, a perfectionist, and someone who never stopped asking “but why?” They drove each other mad. They shipped the best software of my career.
The worst team I ever worked on was five smart, agreeable, experienced developers who got along perfectly and never challenged each other. We shipped mediocre software pleasantly and nobody noticed for six months because the meetings were so harmonious.
Every conversation about team composition eventually lands on “hiring the best people.” This is unhelpful advice, not because it’s wrong but because it’s incomplete in a way that leads to bad decisions. Hiring the best individuals doesn’t produce the best team, any more than assembling the best ingredients produces the best dish. What matters is the combination, how the pieces fit together, what’s missing, and whether the resulting team can do things that none of its members could do alone.
Cognitive diversity: what it is and why it matters
Cognitive diversity is the variation in how people think, approach problems, and process information. It’s distinct from demographic diversity, though they’re related, and I’ll come back to that, because it’s about mental models, not identities.
A team with high cognitive diversity includes people who think in systems and people who think in stories. People who see risks first and people who see opportunities first. People who want to plan carefully before starting and people who want to start and adjust as they go. People who focus on the detail and people who focus on the big picture.
This is uncomfortable. Cognitively diverse teams argue more. They take longer to reach consensus. The meetings are messier. Somebody is always saying “have we thought about…” when everyone else wants to move on. It feels slower.
It is slower, at the start. And then it’s faster, and better, and the gap widens over time.
The research on this is substantial. Scott Page’s work on diversity and problem-solving shows that diverse groups consistently outperform homogeneous groups of higher-ability individuals on complex problems. Not because the diverse group is smarter, but because they bring different tools to the problem. The homogeneous group is smart in the same way and has the same blind spots. The diverse group is smart in different ways and covers each other’s blind spots.
A team of five backend developers who all think in database schemas will build a brilliant database schema and an unusable user interface. A team that includes someone who thinks about user journeys, someone who thinks about operations, and someone who thinks about failure modes will build something that works for real humans in the real world. Not because any individual is better, but because the team sees more of the problem.
DISC: useful, limited, not magic
DISC is a behavioural profiling model that maps people along four dimensions: Dominance (direct, results-oriented), Influence (enthusiastic, collaborative), Steadiness (patient, reliable), and Conscientiousness (analytical, quality-focused).
It’s popular in corporate settings because it’s simple, easy to administer, and gives people a shared vocabulary for talking about working styles. “I’m a high-D, I need directness and speed” is a useful thing to know about a colleague. “She’s a high-C, she needs time to review the data before committing” saves you from interpreting thoughtfulness as resistance.
Here’s where DISC is useful:
Self-awareness. Taking a DISC profile and reading the results often produces genuine “oh, that’s why I do that” moments. Understanding your own default working style is the first step toward adapting it to work better with others.
Team composition conversations. When you can see that your team is four high-D personalities and zero high-S, you can have a useful conversation about what’s missing. “We’re all fast decision-makers who hate detail. Who’s catching the things we’re missing?” That’s a valuable question, and DISC makes it visible.
Conflict resolution. When two team members clash, it’s often because their styles are incompatible, not because either person is wrong. The high-D who makes quick decisions and the high-C who needs time to analyse aren’t disagreeing about the answer; they’re disagreeing about the process. Making that visible helps both sides adapt.
Here’s where DISC is limited or actively harmful:
Hiring decisions. Using DISC profiles to filter candidates is a terrible idea. The science doesn’t support it, the predictive validity is weak, and it creates a legal liability in many jurisdictions. DISC measures self-reported preferences, not capabilities. A high-D person is not inherently better at leadership than a high-S. They just lead differently.
Fixed labels. The worst thing that happens with DISC is when people use it as an excuse. “I’m a high-D, I can’t help being blunt.” Yes you can. DISC describes your default, not your ceiling. Adults can adapt their communication style. That’s called professionalism.
Pseudoscience adjacent. DISC has less empirical support than its popularity suggests. The test-retest reliability is moderate; take it twice and you might get different results. The categories are broad enough that almost anyone can see themselves in the description, which is the same trick that makes horoscopes feel accurate. Use it as a conversation tool, not a scientific instrument.
My recommendation: use DISC (or similar profiles like Insights Discovery, which is DISC with colours) as a workshop activity to start conversations about working styles. Don’t use it to make decisions about people. Don’t put it on CVs. Don’t refuse to hire someone because the team “needs an S.”
Belbin team roles: a better lens for composition
Meredith Belbin’s team role model is more useful than DISC for thinking about team composition, because it focuses on what a team needs rather than what individuals are like.
Belbin identified nine roles that a team needs to function well:
Action-oriented roles: Shaper (challenges, pushes, drives), Implementer (turns ideas into practical action), Completer-Finisher (catches errors, polishes, meets deadlines).
People-oriented roles: Coordinator (clarifies goals, delegates, draws people in), Teamworker (builds bridges, smooths friction, supports others), Resource Investigator (finds opportunities, builds external contacts, brings ideas in from outside).
Thinking-oriented roles: Plant (creative, generates novel ideas), Monitor-Evaluator (analytical, judges options dispassionately), Specialist (deep expertise in a specific area).
No one person fills all nine roles. Most people have two or three strong roles and several that they can manage but don’t prefer. A well-composed team has coverage across all nine. An unbalanced team has gaps, and those gaps predict the team’s failure modes.
A team with no Plant will lack creativity. They’ll be competent at executing known solutions but struggle with novel problems. A team with no Completer-Finisher will have a long trail of almost-done work. A team with no Coordinator will have plenty of smart ideas and nobody pulling them into a direction.
I find Belbin more useful than DISC because it’s prescriptive about what’s missing, not just descriptive about what’s there. When you map a team’s Belbin roles and see a gap, you know what to look for in the next hire. Not “we need another senior developer” but “we need someone who naturally challenges assumptions and pushes past the comfortable option” (a Shaper) or “we need someone who will actually finish things and catch the details we’re all too impatient for” (a Completer-Finisher).
Belbin’s framework also makes it clear that roles exist in tension and that’s the point. The Plant who generates creative ideas and the Monitor-Evaluator who shoots holes in them are not in conflict; they’re a system. The Shaper who pushes for action and the Teamworker who smooths the interpersonal friction the Shaper creates are not in conflict, they’re complementary. A team that’s comfortable isn’t a team that’s performing. A team that’s in productive tension is.
The myth of the 10x developer
You’ve heard this one. There are developers who are ten times as productive as the average. Find them. Hire them. Pay them whatever they want.
The original research behind this claim. Sackman, Erikson, and Grant’s 1968 study, measured individual variation in programming tasks and found a 10:1 ratio between the fastest and slowest programmers. This is real, as far as it goes. Some individuals do solve isolated coding problems much faster than others.
But “solves coding problems fast” is not the same as “makes a team more productive,” and the difference is everything.
The 10x developer, in my experience, comes in two varieties.
The force multiplier. This person makes everyone around them better. They review code carefully and leave comments that teach. They pair with junior developers and bring them up to speed. They write documentation that saves hours of confusion. They notice when the team is heading in the wrong direction and raise it early. They do less individual work and produce more team output. This person is genuinely 10x, but the “10x” is a property of the team with them on it, not of the individual.
The individual contributor with a social problem. This person writes brilliant code fast, in isolation, that nobody else can understand or maintain. They don’t review others’ code because they’re too busy. They don’t pair because it’s slower than just doing it themselves. They build things that work but are incomprehensible to anyone else, creating a dependency on themselves that they mistake for importance. When they leave, and they always leave, because people who can’t work with others eventually select themselves out, the team inherits a codebase that takes months to untangle.
The second variety is not 10x. They’re 1x with a long tail of maintenance debt that someone else will pay. They look productive on individual metrics because individual metrics can’t see the cost they impose on the system.
The real insight isn’t that 10x developers exist; it’s that 10x teams exist, built from people who complement each other rather than five copies of the same brilliant individual.
Hiring for complement, not similarity
The natural human tendency when hiring is to select for similarity. We like people who think like us, communicate like us, and have similar backgrounds and experiences. This feels like “culture fit.” It’s actually cloning, and it produces the homogeneous team that agrees on everything and misses what it can’t see.
Hiring for complement means deliberately looking for what the team is missing.
If the team is all experienced developers, hire someone junior. Not because junior developers are cheap, but because they ask the questions that experienced developers have stopped asking. “Why do we do it this way?” is the most valuable question in engineering, and experienced developers stop asking it because they think they know the answer.
If the team is all planners, hire a doer. Someone who wants to build first and think second. Not because that approach is better, but because the tension between planning and doing is where good software lives. Too much planning and nothing ships. Too much doing and the wrong thing ships.
If the team is all introverts, hire an extrovert. Not for “culture,” but because someone needs to talk to the stakeholders, push back on unreasonable requirements, and build relationships with the teams you depend on. That’s not decoration; it’s a capability the team needs.
If the team is all generalists, hire a specialist. Deep knowledge in a specific domain, security, performance, accessibility, data, changes the team’s capability in ways that five more generalists won’t.
The practical challenge is that hiring for complement requires knowing what the team has. This sounds obvious, but most hiring managers I’ve worked with couldn’t tell me their team’s profile if I asked. They know who’s senior and who’s junior. They know the tech stack. They don’t know whether the team’s failure mode is “we plan too long” or “we don’t plan enough,” whether the team has someone who challenges ideas or just people who agree, whether anyone on the team naturally finishes things or whether everything is eighty percent done.
Before writing a job description, map the team. Not skills: roles, styles, strengths, gaps. Then write the job description for the gap, not for a generic “senior developer” who looks like everyone you already have.
The culture fit trap
“Culture fit” is the most abused concept in hiring. In theory, it means “this person shares our values and will thrive in our environment.” In practice, it means “this person reminds me of me and I’d enjoy having a beer with them.”
The research on culture fit in hiring is damning. Lauren Rivera’s work at Northwestern found that interviewers consistently rated candidates higher when they shared hobbies, backgrounds, and communication styles. The result: teams that hire for culture fit become more homogeneous over time, losing cognitive diversity and reinforcing existing biases.
This doesn’t mean culture doesn’t matter. It does. A team needs shared values: commitment to quality, respect for each other, willingness to learn. But those are values, not vibes. You can assess values in an interview. “Tell me about a time you disagreed with your team and how you handled it” tells you about respect and collaboration. “Tell me about a time you found a bug in production and what you did” tells you about accountability and quality.
What you can’t assess, and shouldn’t try to, is whether you’d enjoy grabbing lunch with this person. That’s not a work requirement. The best team I mentioned at the start of this post, the loudmouth, the worrier, the perfectionist, and the “but why” person, would have been a terrible lunch group. We had almost nothing in common outside work. We were a phenomenal team because our differences created the productive tension that produced great software.
How to interview for team contribution
A few practices I’ve found effective for hiring people who will make the team better, rather than people who will make the team more comfortable.
Include the team in the interview. Not just the manager: the people who will work with this person daily. Give them a voice in the decision. They know what the team is missing better than any hiring manager.
Ask about collaboration, not just capability. “What’s the best team you’ve worked on and what made it work?” tells you more than “what’s your favourite programming language?” The answer reveals what they value in a team, what role they naturally play, and whether they think in terms of individual achievement or collective outcome.
Give them a problem that requires asking for help. The best interview exercise I’ve seen isn’t a solo coding challenge; it’s a pairing exercise where the candidate works with a team member on a real problem. Can they ask questions? Do they listen? Do they build on the other person’s ideas or bulldoze them? A candidate who can’t collaborate in a forty-five-minute pairing session won’t collaborate in a forty-five-hour sprint.
Check for learning orientation. “Tell me about the last thing you learned that changed how you work.” People who are still learning are people who will keep improving. People who haven’t learned anything new in two years are coasting, and coasting is the enemy of high performance.
Actively counter your biases. Use structured interviews: the same questions for every candidate, scored against a rubric. It’s less fun than a free-flowing conversation. It’s dramatically more fair and more predictive. Unstructured interviews are one of the weakest predictors of job performance in the psychological literature. Structured interviews are one of the strongest.
Demographic diversity and cognitive diversity
I said earlier that demographic diversity and cognitive diversity are related. Here’s how.
People with different life experiences, backgrounds, identities, and perspectives tend to think differently about problems. A woman in a male-dominated team doesn’t just bring a different identity; she brings different experiences that shape how she sees user needs, team dynamics, risk, and communication. A person from a non-traditional background doesn’t just bring a different CV; they bring a different mental model of what “normal” looks like, which is exactly what a team needs to challenge its own assumptions.
This isn’t guaranteed. Not every diverse hire increases cognitive diversity. But the correlation is strong enough that a team that’s homogeneous on demographic dimensions is almost certainly homogeneous on cognitive dimensions too. If everyone on your team went to the same three universities, worked at the same five companies, and grew up in the same socioeconomic bracket, they probably think alike, even if they think they don’t.
Demographic diversity is a good proxy for cognitive diversity, and it matters independently for reasons that go beyond performance. But this is a post about building effective teams, and the performance case is clear: teams that include people who see the world differently build products that work for more of the world.
Putting it together
Building a high-performing team is not about collecting the best individuals. It’s about assembling a group of people whose strengths complement each other, whose weaknesses are covered by someone else’s strengths, and whose differences create the productive tension that produces better decisions.
Use frameworks like Belbin to understand what roles the team has and what’s missing. Use DISC or similar tools to start conversations about working styles, but don’t treat them as science. Hire for the gap, not for the clone. Interview for collaboration and learning, not just technical skill. Resist the seductive pull of “culture fit” when what you really mean is “they remind me of me.”
The best teams are not the most comfortable teams. They’re the teams where people are different enough to challenge each other and respectful enough to do it productively. That combination of difference plus respect is the foundation of everything that follows.