Contractor Swarm: Why It Works (Until It Doesn't)

The team is small, there is one talented CTO or head of engineering leading and things work great. Then something shift.

Comfort of Clarity

Small teams, under 6 people, have a natural nimble quality to them: things work fast, changes in direction are also fast and everything can be directed from that one chair.

With such a small number the team members know each other well after a few months and the dynamic is really smooth and fast. The CTO can direct everything quickly, knowing in depth what each engineer is working on, planning and tracking their load within one board. To some extent it's a very natural way to run a team: everyone around one big table, no second row, not much small talk.

The scope of all the work stays indeed small and that's why at some point the team needs to grow: "things are working well, we have more users and they request more features, we can tackle all that with just the 6 of you".

Before digging into the impact of such a growth, let's look at the hidden cost of this model.

This is a very dispatch model: the leadership can just dispatch tasks to the swarm and they get taken care of. Yet, this teaches the engineers they can only take orders, they have limited freedom in deciding what to work on and how. All decisions bubble up to the CTO and through him, the leadership. Each member of the swarm is independent from others, or with limited, CTO-driven coordination. Finally the CTO is the one keeping everything tied together: distributing tickets, keeping the overview of the plan.

This is totally fine at this time, with only 6 engineers to drive, the project is relatively small and all of it can be indeed driven by one person. The CTO holds the cognitive load. They know what's happening, they can reprioritize on the fly, they can unblock anyone immediately. It feels sustainable because it is—at this scale.

Inflection point

Six to eight are kind of magical numbers. If you have ever arranged a group meal you will have seen that: past 6 people, you definitely can't have a single conversation going on around the table.

Even with 6 people you might start to see 2 or 3 people peel off to the side to discuss a different topic. With 8 people that's not just a possibility, it's happening right at the door of the restaurant. The group naturally fragments.

The great news is that this signals something important: you can have independent groups of people working on something, not just single engineers on individual tasks, but groups of tasks related to one endeavor. A typical first use case is to pair a Backend Engineer with a Frontend Engineer on a feature.

Yet, this creates another dynamic: those pairs of engineers start organizing themselves. They coordinate between themselves and make decisions without waiting for the CTO. To a purely directive CTO, this can feel like a loss of control—when actually, it's the opposite. It frees them to move toward operational and strategic work. Without having to check everything with the CTO, the pairs start to move faster and velocity improves noticeably.

If the team doesn't go in that direction—if the CTO tries to keep the dispatch model going—something else happens: the CTO starts to get overwhelmed. Days fill up with meetings. Daily standups grow longer and longer, with every project dissected in excruciating detail. People check out during standups because their attention is only needed for 5 minutes of a 45-minute meeting. Everyone feels it getting heavier.

Accepting the jump

At some point, the change in structure is obvious and actually happening whether you want it or not.

Tasks naturally grow bigger as engineers pair up, splitting work: "I take the backend part, you do the frontend." Daily standup meetings grow longer with the team getting nervous or disconnected as their attention is fragmented across too many projects.

Until 10 people, the swarm model is usually still doable. Past that point there is no more choice, really. The cognitive load becomes too much and a layer of abstraction is needed. Otherwise, it gets pretty chaotic—tasks get dropped, context switches explode, and the CTO becomes a bottleneck for everything.

This is where things start to get quite interesting for everyone involved.

Flying up

Making pairs out of 10 or 12 people is straightforward enough: you base yourself on recent projects, mastery of domains, and complementary skills. You come up with a handful of focused tasks for each pair and off they go.

With just that structural change, the role of the CTO transforms quickly, and the capacity of the team changes with it. Suddenly you start to observe some interesting patterns:

Features get delivered faster by each pair compared to individual contributors. The pairs own their work end-to-end. Knowledge stays within the pair, so onboarding the next contractor into that pair becomes easier—they learn from a peer, not just from tickets.

But there's something else: leaders emerge from each pair. People you didn't expect step up. People you thought were solid individual contributors suddenly reveal themselves as people who can coordinate, decide, and drive forward.

This is what we will explore next time.