We doubled the team and nothing got faster - A story of perfomance

A few years ago, at a scale-up where I was CTO, the engineering team was cut in half. Tough economic context, like many companies at the time. On paper, it was a disaster.

Except velocity didn't drop by half. It dropped by maybe 20%, possibly less. Standups got shorter. PRs moved faster. The people who stayed knew exactly what to do, and they finally had room to do it.

To be fair, what made the difference is partly that the right people had stayed. The ones actually driving projects forward hadn't left. Critical domains were still covered. Scope had shrunk. The headcount reduction didn't improve anything on its own. What mattered was who remained.

And that raises a broader question: why do some people weigh so much more than others in an organization's ability to ship?

Barrels

In any team, there are two or three people without whom nothing ships. The ones who take a vague topic, break it down, get others on board, and push it to production.

Keith Rabois put a name on this while observing PayPal: out of 254 people, 12 to 17 carried projects end to end. He calls them barrels. Everyone else is ammunition: the people who execute.

The ratio is striking. It's also a heuristic drawn from one specific company at one specific time. A 2000s fintech, a B2B SaaS platform, and an e-commerce scale-up don't have the same dynamics. But the intuition holds: in most organizations, a small number of people carry the bulk of the ability to ship.

And "carrying" doesn't look the same everywhere. The Staff Engineer who secures platform architecture carries. The EM who unblocks their team every week carries. The PM who makes priority calls and protects product focus carries, without writing a line of code. The SRE whose reliability lets everyone else build with confidence carries too. Very different profiles, same function: turning an initiative into a result.

An organization's real capacity is the number of these people. Not total headcount.

More people, less speed

When things slow down, the reflex is almost always the same: hire. Look at the roadmap, count the features, divide by estimated capacity per developer, conclude you need fifteen more people. Brooks showed the problem back in 1975: coordination cost grows at n(n-1)/2. Teams of 5-7 consistently outperform teams of 15-20 in per-capita productivity (QSM, across thousands of projects).

Sometimes headcount really is the bottleneck. An undersized platform team, 24/7 coverage to maintain, a multiplication of business domains requiring new expertise. In those cases, hiring is the right call.

But when the problem is "we're not moving fast enough on existing work," it's rarely a staffing problem. Ten more developers with nobody to frame the project, break it down, unblock it when things get stuck: ten people waiting or heading in different directions. The bottleneck is the number of people able to carry a topic end to end.

You can't hire into a broken system

On another engagement, I faced strong pressure to hire into a struggling team. My stakeholder couldn't understand why I was pushing back. The team was struggling, so it needed more people. To him, it was obvious.

I saw the outcome of that logic in a different context: external hires added to a dysfunctional team. They didn't push back, didn't bring the fresh perspective everyone hoped for. Within weeks, they'd adopted the same workarounds as the rest of the team, the same shortcuts in review, the same topics everyone avoids in standup. The resources were there, the goodwill too. But when the system has structural flaws, new hires don't fix them. They absorb them.

Will Larson calls this organizational debt. You don't hire into a broken system expecting the newcomers to fix it despite themselves.

Find the bottleneck, not the headcount gap

Goldratt laid it out in The Goal: a system's throughput is limited by a single bottleneck at a time. Optimizing anything else is waste. In The Phoenix Project, Brent is the one everything flows through, the one without whom nothing moves. Redistributing his load is the only lever. Hiring next to him does nothing.

In the team I watched shrink by half, that's what happened naturally. Fewer people, so fewer projects in parallel. Those who remained finally had the bandwidth to run their topics end to end, without being interrupted every hour to coordinate.

Skelton and Pais frame the same idea differently in Team Topologies: the real constraint is cognitive load, not headcount. When a team is overloaded, you need to reduce the surface area, the scope per person, the number of domains to keep in mind. Not add more heads.

And often, the bottleneck isn't even in engineering. It's in product decisions. Fuzzy priorities, calls that don't get made, business dependencies that nobody resolves. You can have all the technical barrels you want: if nobody on the product side holds the vision and protects focus, the team builds fast in directions that don't converge.

Growing barrels

Barrels don't stand out by their technical level. They stand out by how they react to ambiguity.

On a recent engagement, I needed barrels in a team that didn't have enough. Rather than hiring directly, I gave a leadership role to about ten people, in rotation. Same conditions, same scope, same expectations.

Within weeks, the difference was clear. Some grabbed the role: they broke down problems on their own, asked questions about the why not just the how. They felt accountable for outcomes beyond their own scope. Others still needed guidance, and that's fine. Not a judgment call, just a snapshot of readiness at a given point.

Where some waited for instructions or escalated, those few started moving.

It takes time. It's less dramatic than a senior hire showing up with an impressive resume. But people you grow internally know the context, the product, the debt. They don't need three months of onboarding. And above all, they have the team's trust. You can't mandate that.

AI doesn't make barrels

All of this was observed and theorized before every team had access to AI. AI doesn't change the equation. It makes it worse.

Todd Gagne offers an analogy that clarifies things. When electricity arrived in factories in the 19th century, the first industrialists simply replaced the steam engine with an electric motor while keeping the same production layout. The gains were marginal. It took a complete rethinking of factory organization for electricity to deliver on its promise.

AI is the same story. Deploying Copilot or Cursor on a team that lacks barrels is putting an electric motor in a steam-age factory. AI generates code, tests, documentation. But it doesn't know what to build, it doesn't know how to prioritize, and it doesn't push anything to production.

Using Rabois's heuristic: if 12 barrels drove 254 people at PayPal, AI lets those 254 produce ten times more code. But if the barrels are still 12, the bottleneck hasn't moved. It's gotten worse: there's now ten times more output to sort, validate, and carry to production.

A team without barrels armed with AI produces more code that nobody ships. The result is noise, not throughput.

Barrels don't stand out by their technical level. They stand out by their ability to turn uncertainty into execution.

When an organization slows down, the first question isn't "How many people are we missing?" The first question is "Who actually turns vague topics into concrete results?"

As long as those people remain the bottleneck, hiring more doesn't change the trajectory.

Sources

Keith Rabois, How to Operate — Stanford/YC, 2014. The barrels vs ammunition concept.
Fred Brooks, The Mythical Man-Month, 1975. Coordination cost at n(n-1)/2.
Will Larson, Sizing Engineering Teams — and An Elegant Puzzle, 2019. Organizational debt and team sizing.
Eliyahu Goldratt, The Goal, 1984. Theory of Constraints.
Gene Kim et al., The Phoenix Project, 2013. Brent as the human bottleneck.
Matthew Skelton & Manuel Pais, Team Topologies, 2019. Cognitive load as the real constraint.
Todd Gagne, The Barrels Paradox, 2025. The electricity/AI analogy and why human judgment becomes the real bottleneck.