Why two people with real ownership can accomplish more than a larger team kept artificially busy.
In Star Wars, the Sith are an order that draws power from the dark side of the Force, driven by ambition and the pursuit of control. Darth Bane was a Sith Lord who lived roughly a thousand years before the events of the films. He saw how their hunger for power kept turning them against one another, undermining their own plans. Having more of them did not make the order stronger. His answer was the Rule of Two: only one master and one apprentice at a time. The master would pass on what they knew, and the apprentice would learn, grow stronger, and eventually seek to take their place.
There is an interesting idea inside that rule: adding more people does not necessarily increase the amount of useful work a group can accomplish.
Most software teams begin with the opposite assumption. Four developers should deliver more than two. Six should deliver more than four. Eight should let the business run several initiatives at once. People are added because the organization wants more throughput.
But the business must be able to produce enough meaningful work for those people. It has to understand problems, make decisions, resolve uncertainty, and provide context. It has to refine more than tickets. It has to refine its own thinking.
A product area might have enough clarity for one or two important changes, but six developers assigned to it. Their capacity remains visible while the business works out what matters next. And visible capacity creates pressure.
Management rarely wants to see people waiting. An engineer without a ticket can look underutilized. A team without a full backlog can look poorly managed.
So the organization creates work.
A weak idea becomes a feature because somebody is available to build it. A speculative abstraction becomes a technical improvement. A dashboard gets requested without a decision it is meant to inform.
The backlog fills. Everyone becomes busy. The business does not necessarily become better.
I think this is one of the most expensive consequences of treating utilization as progress. A shortage of worthwhile problems becomes a shortage of tickets, and the organization solves it by producing more tickets.
The larger team can also create work for itself. Changes overlap. Decisions need broader agreement. Ownership becomes less obvious. Meetings appear to keep everyone aligned. Some coordination is necessary, but its cost belongs in the calculation of what the team actually accomplishes.
This concern is not new. In The Mythical Man-Month, Fred Brooks argued that software work cannot always be divided cleanly among more people. Additional people bring communication, learning, and coordination costs.
His chapter on the surgical team offers a related idea. Drawing on Harlan Mills's proposal, Brooks describes a chief programmer and a copilot who knows the system intimately, evaluates ideas, and provides continuity. Other specialists support them. It is a larger team organized around a small technical core, rather than a prescription for teams of two.
I think there is another limit alongside the costs Brooks described: the business must supply enough meaningful problems for the team to solve. Otherwise, more development capacity can become pressure to invent work.
This makes me wonder whether two people should be the default unit of ownership for many parts of a software business.
One could be an experienced engineer who understands the system and the business. The other could be another senior engineer or someone with less experience who can learn, challenge assumptions, and take on responsibility. Both would know the capability well enough to make decisions and maintain it.
Together, they would own an end-to-end slice of the business: a module, a customer journey, or a capability with a clear purpose. They would help understand the problem, decide what should change, implement it, deploy it, observe the result, and maintain it afterward.
They would also have the authority to decide that something should not be built.
That matters because autonomy begins before implementation. It includes questioning a task, clarifying the outcome, and finding a smaller intervention. A pair receiving poorly understood tickets from elsewhere still has the same problem, just with fewer people.
Two is also meaningfully different from one. A single owner can move quickly, but the capability depends on one person's memory, availability, and judgment. Two people can review each other's thinking, preserve context when one is away, and disagree before a weak decision reaches production.
The number should still follow the work. A major migration can require several specialties. Demanding operational coverage can require a broader rotation. Some capabilities contain more responsibility than two people can safely hold.
But those are reasons to shape a team around its actual obligations. Giving every business area the same six- or eight-person template and manufacturing enough activity to fill it reverses that relationship.
An organization can also grow by creating additional pairs around distinct capabilities. Each pair stays close to an outcome. When several capabilities need to change together, they coordinate around that problem. Shared platforms, documentation, and engineering communities help them work together without becoming isolated.
A small team still needs support. Autonomy does not mean being left alone with every dependency and every failure.
I think the deeper question is what we believe a team exists to do. If its purpose is to keep developers occupied, management will always need more tasks. If its purpose is to improve a business capability, its size can follow that responsibility, and its success can be judged by what becomes better because the team exists.
A team should not need invented work to justify its size.
Two people with context, authority, and end-to-end responsibility can already be a team.
More people should arrive when the problem requires them.
Not when the org chart does.
Originally published on Rodrigo Vidal’s Substack.
Top comments (0)