You made the move to pairs of engineers. You have seen how your projects get shaped, built and delivered at a more sustainable pace. Some teams have asked your support for a couple of projects but at some point everybody is moving forward ok. You start to look at the further horizon and then ... it's Summer, 3 out of 12 engineers ask for time off at the same time.

Three of your pairs get halved and suddenly they are much slower to deliver. You need to coalesce two of them temporarily or ask for some engineers to step up and lend a hand for code reviews.

Congratulations, you have met one of the key limits of this approach. It's ok, again, you are learning through growth.

The problem

Pairs do work great, but there is an hidden cost: fragility. As soon as one person is out the project stalls. Let's look at the capacity math:

• 2 people means 1.5 capacity on average (considering time off, meetings, context switching, etc)
• you are always one absence away from the single engineer problem
• knowledge is stuck in two heads

You might see this coming immediately. Or it might hit you in retrospectives: "Why are we suddenly slower?"

Why three matters

The solution is straightforward: add one more person. This gives us:

• An average of 2.5 capacity
• One person is out of office? You still have 2 people working
• Code reviews and discussions can still happen healthily
• No need to pull in someone from another team

Another benefit is that the team is much more resilient to departures for both knowledge and capacity.

Inflection point

When can a team do this jump? Obviously not when there are only 3 engineers. Once you pass 8 to 12 engineers and have spent some time working with 4 to 6 pairs, you will start to see the problem often enough.

Of course, you also need to be able to afford it. One extra person per team is a serious cost that can't be forgotten.

What signals to monitor for:

• Projects stalling when someone is absent or blocked on something else
• Retrospectives mentioning "we would have avoided this if we had another person with us"
• Pressure on code reviews and architecture discussions

What Becomes Possible at Three

With this new average capacity of 2.5 and the resilience it brings, things will change again.

Those trios will start to develop deeper knowledge about the work they're doing. They won't just pick "whatever feature comes next"—they'll develop context and understanding over time.

As a consequence, with this deeper understanding, they'll be able to do better architectural thinking for the work they own. They can make decisions and refactor with a wider perspective and thus better results. This improves their capacity to target and clean technical debt, improving their delivery capacity overall.

With real ownership and vision of their work, they can much better coordinate with other teams and help with decisions. Team-to-team communication patterns emerge naturally.

But You Need Someone to Lead This

Here's where things shift structurally: managing 12 to 16 engineers directly as a single Head of Engineering becomes a bottleneck again, even with duos or trios. Not the same bottleneck as dispatch-and-details, but a real one.

This is when you need a new role: a Lead Engineer or Team Lead. Part technical, part management. Someone who:

• Leads and manages 2 to 3 trios (6-9 people) as a coherent unit
• Does code reviews, pairs programming with team members, reviews architectural choices
• Leads daily meetings, does regular 1-1s with all engineers
• Makes decisions at their level without constantly escalating to the CTO
• Represents their team when cross-team discussions happen

On paper, this looks like another management layer. But it's actually the opposite: it removes a layer of escalation.

The Impact of a Lead

Because the Lead is close to the work and knows their teams deeply, they can:

• Make decisions at their level without asking the CTO for approval all the time
• Unblock their teams faster (they understand what's happening)
• Represent their teams in cross-team decisions
• Provide real technical input, not just people management

Without a Lead at this scale, you're back to the CTO trying to maintain visibility and decision-making across 8-12 people. You know how that ends.

The Constraint: Dunbar's Number

A Lead can effectively manage 8 to 10 people directly. Beyond that, it's time for another Lead to appear and the ownership to be split.

This is important: you can't just keep adding more people under one Lead. The structure breaks. Better to split the team and add another Lead.

Why You Can't Jump Here Too Early

To support this structured team approach, an engineering team needs to be both big enough and ready enough. Until both criteria are met, you likely have neither the capacity nor the maturity to sustain it.

For a while, you will only be able to have large parts of the product split between 2 or 3 groups of engineers (themselves organized as trios). And that's ok. Trust the teams, give them ways to communicate and raise alarms, and support the ones who do. If you do that, you already have a good basis to adopt bigger patterns later.

In simple terms: you have to build capacity before you can build organization.

Context Matters: When These Rules Don't Apply

This progression isn't universal. Some teams skip directly to trios (they waited too long on swarms, or they're well-funded from the start). Some start with larger teams (the complexity of their product demands it). Some stay at pairs longer (smaller team, specific project cadence).

The principle: match structure to your actual capacity needs and team maturity. Don't force a progression. Observe your constraints and adapt.

The Growth Path

As you grow from 6, to 9, to 12 engineers, you will go from duos to 2 trios, to 3 trios to 2 teams of 6.

At each step you will see better resilience and scaled capacity. Yet, as you grow in numbers and team communication becomes more complex, new questions emerge:

• Who owns what?
• How do we know what other teams are doing?
• How do we articulate large projects?
• How do we make decisions across teams?

This trios structure will also be a stepping stone towards something else. Just like swarms and duos, it will help how projects are done and delivered—until the limits of this approach start to show.

This step is important though: it's when real organization begins to emerge within the engineering team. And then the next question becomes: how do these teams actually work together? How do decisions get made when multiple teams are involved?

That's what we're exploring next.