If you're running a small product team with 5 to 8 engineers, the contractor swarm model is probably working fine. You know what everyone is doing. You dispatch tasks, track progress, unblock people when needed. The work moves. The product ships.
This is not a mistake. It's the right model for that stage.
The problem isn't that you chose swarms. The problem is not knowing when to stop.
Why the Dispatch Model Makes Sense Early
At 5 to 8 people, direct coordination works because it's cognitively manageable. As the engineering lead — whether CTO, Head of Engineering, or founding engineer — you can hold the full picture in your head. You know what each person is working on, where the blockers are, what's coming next.
The model is elegant in its simplicity:
- A ticket lands on the board
- You assign it to the right person
- They deliver it
- You move to the next one
There's no coordination overhead. No team dynamics to manage. No architecture discussions that slow things down. You can pivot quickly, adjust priorities daily, and stay close to every piece of work.
For a startup or a small product company, this feels like speed. And it is.
The First Sign of Strain
The inflection point usually arrives quietly. Not with a crisis, but with a project that's slightly too large for one person.
A feature that touches both frontend and backend. An integration that requires two skill sets working in parallel. A refactor that needs a second set of eyes to not spiral out of control.
So you pair two contractors on it. Almost by accident. And something unexpected happens.
The work goes better.
Not marginally better — noticeably better. The pair talks through decisions before implementing them. They catch each other's mistakes. The code is cleaner. The delivery is faster. And critically: you, the dispatcher, get asked fewer questions.
That last part is the signal worth paying attention to.
What Pairing Actually Changes
When two engineers own a project together, several dynamics shift at once.
Decisions move to the pair. Instead of escalating every choice to the engineering lead, the pair discusses and decides. The scope of what requires your attention shrinks. Your cognitive load drops.
Context stays in the pair. Both people understand the full picture of what they're building. Knowledge doesn't fragment across tickets. Onboarding someone new into an ongoing piece of work becomes easier — they learn from a peer, not from a task description.
Peer review becomes natural. With two people involved, code review stops being a checkbox and becomes part of the conversation. Quality improves not because you mandated it but because the structure makes it the path of least resistance.
Ownership becomes real. "My ticket" becomes "our project." That's a different psychological relationship with the work — and it shows in the output.
The Inflection Point: 8 to 10 People
When your team grows past 8 people and you're still running the dispatch model, the seams start to show.
You're now managing 8 or more concurrent tracks of work. You're doing 8 one-on-ones. You're context-switching between 8 different projects every day, trying to hold enough detail about each one to allocate tasks, review work, and unblock progress.
The first symptom is usually a feeling — you're drowning, but you can't quite say why. The second symptom is visible: some projects get scrutinised and some don't, because you don't have the bandwidth for all of them.
By 13 to 15 people, the model has stopped working and started harming. You're no longer a technical leader — you're a task dispatcher who's too busy dispatching to do anything else. The contractors feel directionless because no one has time to properly orient them. Quality becomes inconsistent because there's no ownership, no peer review, and no one close enough to each project to catch problems early.
What the Swarm Model Can't Give You
It's worth naming what you're trading away when you run the dispatch model, even when it's working:
Continuity. When a contractor finishes their tickets and rolls off, everything they learned about your codebase leaves with them. Knowledge doesn't accumulate; it resets.
Cross-pollination. Contractors working in parallel on isolated tasks don't learn from each other. Best practices don't spread. Patterns don't emerge. Each person reinvents the wheel in their own way.
Investment. A contractor who picks up tickets has no reason to think about the broader product, the user experience, or the technical debt accumulating around the edges of their work. That's not their job. It's yours. And that's the problem.
The Natural Next Step
The good news is that the transition away from the swarm model rarely requires a dramatic reorganisation. It tends to emerge organically from the work itself.
Once you've seen what happens when you pair people on a project — the quality, the speed, the reduction in escalations — the logic is clear. You do it again. You formalise it slightly. You start thinking about which engineers complement each other and why.
Mini-teams of two aren't a framework you impose. They're the structure that appears when you stop fighting what the work is trying to tell you.
That's where the next piece 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.