As pointed in "Contractors Swarm: Why it works", scaling a small team up from Swarm to Mini teams of two changes the dynamics. First and foremost the "task dispatch" strategy reduces or disappear, and that's when further changes happen.

Of course, no pairs will be the silver bullet, but pairing reveals capacity you didn't know you had.

The symptoms (why you need this)

With a team grown to 8, 10 or 12 engineers the head of engineering (CTO, or acting as ..) starts to have difficulty to keep up with all the projects at once. With 12 engineers on the dispatch model, it means you have 12 simultaneous projects to keep track, think about and feed direction into.

If you think 'I handled 6-8 fine, what's two or three more?'—you're about to learn a hard lesson.

• daily standups will grow quite long as you will try to dig into each and every project
• if you don't do daily standups you will spend you time in meetings
• you will mix up projects
• you will end up loosing track of some in favor of others
• you won't have time to hire or strategize unless you do 70 hours work week

Stop this. The only thing you will succeed in is burning yourself out and crashing.

What to do then ? How do teams scale past the 8-12 mark? The answer is the same as any engineering problem: you split the big problem into smaller, manageable pieces.

How pairings works (mechanics)

One project = 2 engineers with complimentary skills

Start here: pair engineers with complementary skills. The pairs should be made of complementary engineers (frontend + backend, senior + mid-level, or fullstack and specialist). They should be able to tackle a feature from start to finish. They work in parallel—one shouldn't wait for the other.

One pilot, one co-pilot

The Pilot is responsible for refining and managing the task list for the project. They also need to be the spokesperson for the pair during standups.

Here's what matters: this role rotates between projects. Everyone gets a turn leading. This is important for later—you'll see why.

Giving agency

The pair shapes the Epic (not just executing pre-shaped tasks). They should question the product sketch. Why this approach? What are we actually solving? What about alternative solutions?

They build iteratively, not following a waterfall approach. They own the delivery cadence within the timeframe you've set.

This forced conversation between two people changes everything. When one engineer works solo, there's a tendency to skip tasks, skip reviews, skip architecture discussions. With two people involved, these conversations are unavoidable. And these conversations—the ones that happen before and during implementation—are where the real surprises emerge.

What this changes for you (Head of Eng.)

With this structure, your job becomes:

• Set the direction (not the implementation)
• Set boundaries (scope, success criteria)
• Unblock when needed
• Maintain cadence (check-ins, not deep dives)

Yes, you'll lose deep visibility into every project. That's the trade-off. But you'll gain something more valuable: time to focus on strategy, hiring, and the bigger picture.

What this reveals about your team

The setup

You've given them agency. Now watch. Either one will take charge, both will collaborate, or neither will step up. This is the signal you're looking for.

Why this matters

You're learning whether you can delegate to them. Whether they're ready for more responsibility. Whether they have leadership capacity. This is data you didn't have before—data that's hard to get any other way.

The patterns that emerge

Some engineers will step up immediately (they're ready now). Some will develop into it over time (they show promise, just need the experience). Some will plateau (solid individual contributors, not leaders).

All three are valuable. The question is: which is which?

Why this is valuable

It's not judgment, it's information. This information helps you make better hiring and promotion decisions later. It tells you who to turn to for specific projects and bigger things.

Importantly: with this information, you stop guessing.

The role rotation matters

Remember: the pilot role rotates between projects. Everyone gets a turn leading. The engineers with leadership capacity get better at it. The individual contributors get experience in the role. And the whole team becomes more resilient—because when someone is out, others can step in and hold the fort.

Reality check

You can't have a team made only of good leaders. You can't have a team made only of great individual contributors. That's just how groups of people work. But this is also a blessing—a mixed team brings better results.

What you want is to coach the ones with a leader profile to be excellent at it while staying capable as individual contributors. And you want to coach the ICs to understand leadership—not to become leaders necessarily, but to recognize the role and step in when needed.

Your organization needs both profiles. And knowing your team's composition early saves pain later.

The Trade-off You're Making

With this approach, you're trading deep visibility for speed and ownership. This will be deeply uncomfortable at first.

Yet it will work:

• Standups will be shorter: only one person per pair talks, gives an update, lists blockers
• Decisions will be faster: pairs decide as much as possible, not waiting for you
• Better quality: peer review is forced
• Your time frees up: for strategy, hiring, unblocking

This is not a loss. It's a net gain.

The Limit

Pairing has limits. And they matter.

• If one person is out of the office, the project stalls
• Knowledge lives in the pair—there's no redundancy. If one person leaves the company, that knowledge walks out the door
• One engineer in the pair can't carry a project alone (back to the single-engineer problem)

These aren't design flaws. They're signals that you've outgrown this structure. They tell you the team has grown, and another coordination model is needed.

What's Next

Once you're regularly seeing these limits in action, you make a natural move: you pair your pairs. "This project is bigger. We need four of you to tackle it."

Now they coordinate with each other. Suddenly you have a 4-person team.

But here's where it gets really interesting: now you have teams that coordinate. And that changes everything about how decisions get made, how ownership works, and what kind of leaders emerge.

That's what we'll explore next.