Summer arrives. Two of your engineers take holiday at the same time. They're a pair — they own the same project. For two weeks, nothing moves.
This is not a staffing problem. It's a structural one.
The pair model solved the ownership problem. It didn't solve the resilience problem. For that, you need one more person.
The Mathematics of Availability
A pair has 2.0 units of capacity when both people are present. When one is absent, it drops to roughly 0.5 — not 1.0, because the remaining person carries the full cognitive load of a shared context they were never meant to carry alone.
Add a third person and the mathematics change. When one is absent, you have 1.5 units of capacity — enough to keep the project moving, enough to make meaningful decisions, enough to not lose the thread.
This is not the most interesting thing about trios. But it's the most immediate argument for them.
The more interesting thing is what happens when all three are present.
What the Third Person Changes
A pair is efficient. Two people with complementary skills working on a shared project move quickly. They know each other's working style. They fall into a rhythm.
But a pair has a blind spot: it can become a closed system.
Two people working closely together for long enough start to share the same assumptions. Their code review conversations cover the same ground. Their architectural discussions return to the same conclusions. The peer pressure is gone — not because they've become complacent, but because they've become too similar.
The third person breaks that closure. They bring a fresh angle. They ask the question the other two stopped asking because they'd already agreed on the answer. They see the thing that became invisible through familiarity.
In a trio, the quality of the internal conversation goes up — not in spite of the added complexity, but because of it.
The Lead Role Emerges
With two people, informal leadership is manageable. If the pair disagrees, they discuss until they align or flip a coin. There's no urgency for a formal decision-maker.
With three people, informal leadership starts to create friction. Decisions that should take five minutes take thirty because there's no clear mechanism for resolving a split. Someone has to hold the thread — to maintain the overall direction when the team is navigating a complicated piece of work.
This is where the Lead role emerges, and it's important to say clearly: it doesn't emerge from seniority. It emerges from the work.
The Lead in a trio is the person who:
- Maintains the overall direction of the project, not just their part of it
- Communicates to the rest of the engineering organisation what the team is doing and needs
- Makes the call when the trio is split, and makes it in a way the others can accept
- Thinks about the next piece of work while the other two are heads-down on the current one
This is a coordination function, not a management function. The Lead is not above the team. They are the team's interface with everything outside it.
And crucially: this role can rotate. It can be project-specific. It can be informal. What matters is that it exists — that someone in the trio is holding the thread.
Context Matters: This Is Not a Universal Template
A trio is not always the answer.
Some projects are genuinely pair-scale. Some engineers thrive in a duo and find trios awkward. Some codebases have areas of specialisation so concentrated that adding a third person adds noise rather than value.
The point is not that every team should be three people. The point is that when you find yourself hitting the resilience ceiling of the pair model — when absences derail projects, when the pair's blind spots become visible in the output, when the Lead function is needed but nobody is filling it — the trio is the natural next step.
Not because a framework says so. Because the work is telling you something.
What You Now Have
If you've moved from contractor swarms through pairs to trios, something significant has happened.
You've built a team where:
- Work is owned by the people doing it, not dispatched from above
- Knowledge lives in the team, not in the engineering lead's head
- Resilience is structural, not dependent on no one ever being absent
- Leadership is developing organically, visible to you in how people function under pressure
- The engineering lead has been freed from dispatching and can think about something more important: what these teams should be working on, and why
That last point is where the conversation about strategy begins.
Thomas Riboulet is a Fractional VP of Engineering working with European tech companies. He writes about engineering leadership, team structure, and sustainable delivery at insights.wa-systems.eu.