Monday Myth: High-Performing Teams Need High Performers

There is an appealing piece of arithmetic behind many approaches to building engineering teams. Find excellent engineers, put enough of them together, and eventually an excellent engineering team should emerge. Better engineers should write better software, solve harder problems, make better technical decisions and require less supervision, so increasing the quality of the individuals should increase the quality of the team.

The reasoning sounds convincing because individual capability obviously matters. A team without the expertise required for its mission will struggle, and no amount of collaboration can completely compensate for missing fundamental skills. The mistake lies elsewhere: we assume that because individual capability contributes to team performance, collective performance must somehow approximate the sum of those individual capabilities.

Professional sport has spent extraordinary amounts of money demonstrating otherwise. Teams packed with individually exceptional players regularly lose to teams containing fewer stars. A football team does not produce performance by adding together the ability of eleven players. Performance emerges through positioning, timing, anticipation, trust, complementary behaviours and the ability of each player to adapt to what the others are doing.

Software engineering has the same inconvenient property. Yet organisations still devote enormous attention to optimising the components while paying considerably less attention to the relationships between them.

The Team Is Not a Collection

We naturally describe teams through their constituent parts. We have three senior engineers, two mid-level engineers, a staff engineer, an engineering manager and a product manager. We map their competencies, identify gaps and recruit against the missing boxes. The resulting diagram may suggest that we have assembled everything necessary for success.

But the diagram describes inventory, not dynamics.

A useful analogy comes from physics. At one level, we can describe a system by studying its particles and their individual properties. At another level, including in the language of second quantisation and quantum field theory, what becomes interesting is not merely the catalogue of particles but the possible states, interactions and transformations of the system. The analogy should not be stretched literally into organisational theory, but it offers a useful change of perspective: understanding the components does not automatically explain the behaviour of the system they form.

Teams work in much the same conceptual way. Individual capabilities establish possibilities, but relationships determine which of those possibilities the group can actually realise. Knowledge moves between people, ideas collide, assumptions get challenged, trust changes how quickly disagreement can occur, experience changes how risk gets perceived, and complementary ways of thinking allow one person's partial solution to become another person's better one.

The potential of the team therefore matters more than the arithmetic sum of its current individual skill sets. A team contains not only what each person can do today, but also what those people can learn from one another and what they can discover together.

That distinction changes how we should think about building one.

Sourcing Is Team Design

Recruitment often gets framed as the process of finding the strongest candidate who satisfies a role specification. We define the competencies, establish the seniority, assess candidates against the criteria and select the person with the strongest evidence.

That makes sense if the unit we are optimising is the individual.

If the unit we are optimising is the team, the problem changes considerably.

The most valuable candidate may not be the candidate with the highest isolated capability. It may be the person whose capabilities, behaviours and perspective create the greatest increase in the potential of the existing group. Someone who introduces knowledge nobody currently possesses may strengthen the team. Someone who asks different questions may strengthen it. Someone who can connect two specialists who currently struggle to communicate may strengthen it. Someone who makes others comfortable exposing uncertainty may unlock knowledge that already existed inside the team but rarely surfaced.

Conversely, an individually exceptional engineer can reduce collective potential. A person who dominates technical discussions may improve some decisions while preventing several other engineers from developing their judgement. Someone who optimises relentlessly for their own delivery can create work for everyone downstream. A brilliant specialist who hoards difficult problems can gradually make themselves indispensable while making the team less capable.

This is why sourcing represents one of the most consequential phases of team design. You are not filling an empty position in an organisational chart. You are introducing a new element into an existing network of relationships, and the topology of that network changes when the person arrives.

The question therefore should not stop at whether the candidate can perform the job. It should include what becomes possible for the team if this particular person joins it.

Capability Can Multiply

This is where the arithmetic model fails most dramatically.

Imagine a team containing five engineers whose capabilities we could somehow assign numbers to. Adding a sixth engineer does not simply add the capability of that engineer. The new person creates relationships with the existing five, changes how knowledge circulates and may alter how the others behave.

Those interactions can destroy value. They can also create it.

An experienced engineer who explains reasoning rather than merely providing answers can improve the judgement of everyone around them. A strong reviewer can improve code they never wrote. Someone with deep operational experience can change how an entire team thinks about failure before the next incident occurs. A person comfortable saying “I don't understand this” can make uncertainty discussable and expose assumptions that several others were privately questioning.

None of those effects fits comfortably into an individual performance metric because the value appears in other people's performance.

This is one reason mature teams can become considerably more capable without replacing anyone. People learn each other's strengths. Communication compresses because context becomes shared. Trust reduces the cost of disagreement. Engineers develop knowledge outside their original specialities. Problems that once required a particular expert gradually become solvable by several people.

The individuals grow because the team grows them.

A strong team therefore does not merely consume individual capability. It produces capability.

The Compounding Effect of Team Dynamics

This also explains why some organisations repeatedly produce strong engineers while others repeatedly search the market for them.

When people operate in a healthy learning system, expertise compounds. Senior engineers expose others to better reasoning. Less experienced engineers ask questions that force assumptions to become explicit. Code review transfers knowledge. Pairing spreads context. Incidents become collective learning mechanisms rather than exercises in finding responsibility. Disagreement improves decisions because relationships can tolerate it.

Over time, the distribution of capability changes.

Someone hired as a competent mid-level engineer becomes senior. A senior engineer develops architectural judgement because a staff engineer involved them in decisions rather than simply making those decisions. An engineer with little operational experience becomes excellent at reliability because the team treats production as part of engineering rather than somebody else's responsibility.

The organisation has not merely retained talent. The interaction system has manufactured more of it.

The opposite compounds too. In a team dominated by a few heroes, difficult work gravitates towards those heroes. Other engineers receive fewer opportunities to develop. The gap widens, which appears to confirm that the heroes really are uniquely capable. Management gives them even more difficult work, further reducing learning opportunities for everyone else.

Eventually the organisation concludes that it needs more heroes. And the system has created the evidence supporting its own diagnosis.

When High Performers Hide a Weak Team

Exceptional engineers can make these dynamics particularly difficult to see because strong individuals often compensate for weak collective systems. They remember undocumented dependencies, know whom to contact when deployment fails, bypass dysfunctional processes through personal relationships, reconstruct missing context from experience and intervene when incidents escape the monitoring system.

From outside, the team appears effective because important things continue to happen.

But sometimes what looks like team capability is concentrated individual capability surrounded by dependency.

The distinction becomes visible when one of those people goes on holiday or leaves the company. Decisions slow down, deployments become riskier, incidents take longer to diagnose and knowledge gaps suddenly appear everywhere. Management says that the organisation has lost a high performer, which is certainly true, but it has discovered something more important: the team never converted enough of that individual's capability into collective capability.

A genuinely strong team should benefit enormously from exceptional people while becoming progressively less dependent upon any particular one of them.

That may sound paradoxical, but it follows naturally once we stop treating talent as something individuals possess and organisations merely consume. The strongest contributors increase the capability of the system around them.

The Weak-Link Reflex

When a team struggles, organisations nevertheless tend to search for the weak component. Perhaps one engineer lacks sufficient seniority, perhaps the engineering manager needs replacing, perhaps Product needs somebody stronger, or perhaps the team needs a more experienced technical lead.

Any of those diagnoses may prove correct. Individual performance problems exist, and pretending otherwise would simply replace one simplistic model with another.

The problem is that replacing people often feels easier than understanding interactions. People have names, job levels, objectives and performance reviews. Relationships between people rarely appear on dashboards. Neither does the knowledge that stopped circulating after a reorganisation, the engineer who quietly enables three others, the technical lead whose behaviour discourages disagreement, or the pair of engineers who together solve problems neither could solve alone.

So organisations optimise what they can observe.

They hire stronger individuals, raise the bar, tighten performance management and remove weaker contributors. Then they place the new people into essentially the same interaction system and wonder why collective performance changes far less than expected.

Designing for Potential

None of this argues for lowering the hiring bar. It argues for defining the bar more intelligently.

Individual capability matters, but it represents only one input into a collective system. When sourcing someone for an existing team, we should care about technical ability and experience while also asking what happens to the system when that person joins it. What knowledge becomes available? What new connections become possible? Which existing people might grow faster? Which assumptions might finally get challenged? Does this person increase the number of problems the team can solve without external help, or merely increase the number they can personally solve?

This perspective also changes how we evaluate an existing team. Instead of asking only how strong each engineer is, we can examine whether capability travels. Does knowledge spread or concentrate? Do strong engineers create stronger engineers around them? Can disagreement occur without damaging relationships? Do people become more capable after a year in the team than they would have become working independently?

Those questions reveal something that a competency matrix cannot.

A high-performing team is not a container filled with high performers. It is a system capable of turning individual capability into collective capability, and then using that collective capability to grow the individuals inside it.

That makes team building a different problem from talent collection. The objective is not to maximise the sum of the parts. It is to create relationships through which the whole can develop capabilities that none of those parts possessed alone.

When that happens, hiring a strong engineer adds more than one strong engineer.

It changes what everyone else can become.