You've seen what pairing does to a project. The work is better. The decisions are faster. Your inbox gets quieter. So you formalise it — pairs become the unit, not individuals.
Then someone goes on holiday. And everything stops.
That's the moment you understand what pairing actually is: not a solution, but a foundation. Strong enough to build on, not strong enough to stand alone.
The Case for Pairs
When you move from a contractor swarm to a structured pairing model, you're not just changing how work gets allocated. You're changing who holds the context, who makes decisions, and who feels responsible for the outcome.
In a dispatch model, the engineering lead is the centre of gravity. Every question flows up. Every priority decision comes back down. The lead is the only person with a complete picture of the work.
In a pairing model, that centre of gravity shifts. Each pair holds the picture for their project. They decide. They review each other's work. They onboard new requirements. The lead stops being a dispatcher and starts being something more useful — a connector, a coach, a person who thinks about the whole rather than managing every part.
This is not a small change. It's a structural shift in how knowledge and responsibility flow through the team.
What the Structure Reveals
Here is the observation that took me longest to articulate: pairing doesn't just change how work gets done. It reveals who the people actually are.
In a task-based model, engineers execute instructions. You don't learn much about their judgment, their instincts, their ability to navigate ambiguity. You learn whether they can complete a ticket.
When you pair two people on a real project with real scope and real ownership, you learn something different. You see who steps up to drive decisions. You see who asks the better questions. You see who naturally thinks about the problem behind the problem, not just the implementation in front of them.
Some engineers step into the driver role immediately. Some develop into it over a few projects. Some plateau at a certain level of scope and complexity. That's not a failure — it's information. Genuinely useful information that shapes how you build the team from here.
Pairs don't create leaders. They make visible the leaders that were already there.
The Driver and the Co-pilot
Within a pair, roles naturally differentiate even without being formally assigned.
One person tends to drive — they own the direction, they make the calls when the pair is split, they communicate to the rest of the team. The other supports — they challenge assumptions, catch blind spots, handle the parts of the work that the driver is weaker on.
These roles are not fixed. They can rotate across projects, or even within a long project as the nature of the work shifts. What matters is that both people understand the project well enough to have that conversation — and that the structure makes the conversation happen.
In a ticket-based model, that conversation almost never happens. There is nothing to discuss. There is only the ticket.
Ownership Changes Motivation
There is a difference between "I got assigned this task" and "this is my project."
It sounds like a small thing. It is not a small thing.
When a pair owns a project, they have a reason to think beyond the immediate implementation. To notice when the scope is drifting. To flag the technical debt accumulating in a corner they're responsible for. To care about the user experience of the thing they're building, not just the correctness of their portion of it.
That caring — that ownership — is what produces quality. Not code review checklists. Not architecture mandates. Ownership.
The dispatch model structurally prevents ownership from forming. The pairing model structurally enables it.
The Limit: Single Points of Failure
And then someone goes on holiday.
Or gets sick. Or picks up a personal commitment for a week. Or leaves.
And the project stops.
The other person in the pair can carry the work forward, technically. But they're slower without their partner. Decisions that the pair would have made together in five minutes now require either escalation or unilateral judgment calls. The momentum breaks.
This is not a failure of the pairing model. It's the signal that you've outgrown it.
Two people sharing a project is more resilient than one person owning it alone. But it is still fragile. It is still a single point of failure, just a slightly larger one.
The natural question is what comes next — and the answer is not "add more pairs." It's something slightly more interesting than that.
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.