♦Over the last few years, I have helped put together several engineering teams across very different environments.
And somewhere along the way, I became much less interested in the question:
“Who is the strongest engineer?”
Because the strongest engineer on paper was not always the person who made the team stronger.
Sometimes the person who looked exceptional individually created more friction than value around them. Sometimes the quieter engineer became the reason five other people could move faster. Sometimes the obvious senior hire added more of a capability we already had, while the person we actually needed looked less impressive on a traditional scorecard.
After enough teams, a pattern started to become clear:
Engineering talent is not really a ranking problem. It is a composition problem.
Because a team of strong individuals is not automatically a strong team.
Imagine two engineers.
Max ships features incredibly fast. His output is obvious, measurable, and easy to reward.
Sara ships less herself, but somehow six other engineers move faster when she is around. She decomposes problems clearly. She notices dependencies before they become incidents. Product conversations become less ambiguous. Junior engineers become more independent. Architecture discussions eventually become decisions.
If you measure individual productivity, Max probably wins.
If you measure how quickly the whole organization can move, Sara becomes much harder to ignore.
That distinction is becoming increasingly relevant. McKinsey’s 2026 Global Tech Agenda describes a move toward capability-led talent models and greater focus on organizational velocity rather than simply adding capacity. The useful part of that framing, for me, is that it changes the unit of thinking.
Instead of asking:
How many engineers do we need?
You start asking:
What does this team actually need to be able to do?
And those are very different questions.
A team modernizing a legacy platform may need someone who understands all the ugly historical decisions buried inside it. It may also need someone who can design what replaces it without turning the project into a three-year architecture exercise. Someone else may be excellent at moving from ambiguity to working software. Another person may be unusually good at connecting product, business, and engineering.
None of them has to be “the best engineer.”
Together, they may be exactly the team you need.
This is where engineering leadership starts looking suspiciously like architecture.
When we design technical systems, we think in terms of capabilities, dependencies, bottlenecks, redundancy, and failure modes. We do not ask which component is the most impressive.
Yet we often forget to use the same thinking with teams.
Consider the engineer who knows everything.
Every strange production issue ends up with them. They know why an ancient database table still exists. They know which service cannot be restarted at 4 PM. When something breaks, somebody says, “Ask Alex.”
Alex looks indispensable.
And Alex probably is.
But if the system cannot safely operate without Alex, you have also created a human single point of failure.
If this were software architecture, we would identify the dependency and try to remove it. When the dependency is a person, we sometimes reward it instead.
That does not mean making Alex less valuable. It means turning Alex’s knowledge into organizational capability: shared ownership, documentation, pairing, simpler systems, better operational practices.
The same thinking changes hiring.
“We need another senior engineer” is not a particularly useful requirement.
Do you need more delivery capacity?
Deep domain knowledge?
Someone who can simplify an overengineered platform?
Someone who can work across product and technology?
Someone who can make less experienced engineers stronger?
The most impressive candidate may still be the wrong hire if they add a capability you already have five times over.
It changes promotion decisions too.
Promotions do not just reward people. They teach the organization what is valuable.
If the person repeatedly saving production at midnight gets promoted while the person quietly preventing incidents does not, people notice.
If complex architecture gets more recognition than simplification, people notice that too.
If individual heroics consistently beat mentoring and knowledge sharing, you should not be surprised when your organization produces more heroes and more dependencies.
People are extremely good at discovering what a company actually rewards.
Usually better than they are at remembering what is written in its values deck.
This is also why some contributions are so easy to underestimate.
An engineer who can move fluently from business problem to product decision to architecture to implementation may not be the strongest person in any single category.
Their advantage is the combination.
They connect layers that organizations often separate. They catch misunderstandings earlier. They help teams build the right thing before everybody gets very efficient at building the wrong thing.
That kind of value is difficult to see if the main question is still, “Who produces the most?”
Engineering leadership, then, is less about ranking talent and more about composing it.
Not in the sense of turning people into boxes on an architecture diagram. People are fortunately much less predictable than microservices.
But the questions are surprisingly similar.
- Where does critical knowledge live?
- Which capabilities are missing?
- Where do we have unnecessary duplication?
- Who makes the people around them better?
- Where have we created dependencies that would hurt if someone left?
- What does this particular team need now that it did not need a year ago?
That last part matters.
The right composition changes.
A startup trying to prove an idea needs something different from a platform team operating at scale. A modernization program needs something different from a greenfield product. A team in crisis needs something different from a team that has become too comfortable.
So perhaps “Who is the strongest engineer?” was never the most useful leadership question.
Sometimes you already have several exceptional engineers. What your team desperately needs is something else.
Now, the Hard PartThere is also one uncomfortable question this way of thinking creates:
How do you know you are actually composing a better team, rather than just rationalizing the team you already have?
Because “we need different kinds of strengths” can become a convenient excuse for avoiding harder performance decisions.
Composition is not a softer alternative to talent quality.
There still has to be a bar.
People still need to execute.
They still need clear ownership.
They still need to be accountable for outcomes.
And not every dependency is automatically bad either. Sometimes, especially in smaller or fast-moving teams, concentrating knowledge in one person is the fastest way to move. The real question is whether that dependency is intentional, temporary, and understood.
The same applies to redundancy. Sharing knowledge is useful. Duplicating every capability everywhere is not.
So maybe the real leadership questions are harder than simply asking who the strongest engineer is.
What capability is actually constraining the business right now?
Is this person a force multiplier, or have we just found a sophisticated way to avoid measuring their individual contribution?
Would I design this team the same way if I were starting from zero today?
For me, that is where the idea of composition becomes useful.
Not as an argument against individual excellence.
Not as an argument for keeping everyone.
And certainly not as a reason to make engineering teams into perfectly balanced collections of personality types.
The composition is only good if it helps the company do something better: move faster, make better decisions, build more reliable systems, learn more quickly, or create capabilities it did not have before.
So I still would not ask, “Who is the best engineer?”
I would ask:
What is the business trying to become capable of next — and do we have the right people, in the right combination, to get there?
Maybe that is the question I have come to trust more.
♦Engineering Talent Is a Composition Problem was originally published in Code Like A Girl on Medium, where people are continuing the conversation by highlighting and responding to this story.