More developers, slower delivery?

Over the past years I have worked with several systems where a slowdown in development was first read as a capacity problem.

Management saw that changes were taking longer and longer, and the developers were permanently overloaded. The obvious answer in that situation is to hire a few more people.

Sometimes that really is what is needed.

But on several occasions I saw that extra developers alone would not have solved the problem. Not because the team was not working hard enough, but because there were bottlenecks in the system and in the development process that were slowing everyone down.

When every change is harder than expected

One recurring situation is when a change that looks simple at first takes surprisingly long.

A new field. A change to a business rule. A minor screen adjustment.

From the outside the task does not look big, yet weeks go by. There is a lot of back-and-forth, a lot of clarification, a lot of uncertainty. The developer does not immediately know where the system needs to be modified, which other parts the change might affect, and how to make sure nothing breaks elsewhere.

At this point it is easy to say that the developers are slow.

The reality is often that the system has become hard to change. The code works, but it is no longer easy to understand. The effect of a decision is not visible in one place. The tests do not give enough confidence. Before a release, a lot has to be checked by hand.

In a system like this a new developer cannot deliver meaningful speed either. First they have to understand the same difficulty the existing team is already dealing with every day.

When the team's time does not go into development

In another system I saw that a significant share of the developers were not working on new features, but on keeping the existing system running.

They were chasing bugs that only appeared in production. Restarting processes by hand. Trying to reconstruct data that had never been logged properly. After each incident a quick fix was made, but there was no time left to remove the underlying cause.

From the outside this can also look like there are too few developers.

In reality, part of the team is continuously handling the consequences of earlier technical decisions. They are not building new value; they are solving the same problems again and again.

This work is not always visible, but it has a very real cost. Features are not delivered because of it, uncertainty grows, and the team can plan ahead less and less.

When nobody fully understands the system

In many mature systems the biggest problem is not the absence of documentation, but the absence of a shared, reliable picture of how the system works.

One part is genuinely understood by one person. Another process was built by a team that has since left the company. Nobody remembers exactly why an earlier decision was made, so before every change the past has to be decoded again.

This kind of uncertainty builds up slowly. It does not necessarily cause an immediate failure, but it makes every later change more expensive and more risky.

Developers in this situation are not slow because they do not know what to do. Often it is the opposite: they are trying to understand too much up front before they dare to change anything safely.

New people sometimes increase the load first

Growing the team has a frequently underestimated cost: new colleagues have to be brought into the system.

If the system is well structured, responsibilities are clear, and the development process is predictable, this is a natural part of growth.

But if most of how things work lives in a few people's heads, the documentation is incomplete, and the production system is risky to change, then onboarding puts a significant load on the existing team.

In that case new developers do not necessarily speed things up at first. They ask questions, they need context, they try to understand decisions — and that is entirely reasonable. Meanwhile the existing team has less time for its own work.

So growing the team is not something to evaluate on its own. The question is whether the system and the way of working can absorb the new capacity.

What I look at first

When I try to understand a situation like this, I do not start with how many developers work on the system.

I start by looking at how the full elapsed time of a change is spent.

How much of it is actual development? How much is waiting? Where does information have to be requested again? How long do testing and release take? Which failures keep coming back? Which parts does everyone touch carefully, and why?

This usually reveals the real problem faster than another round of capacity planning.

It also matters whether the slowdown shows up everywhere, or only in certain modules, processes or parts of the product. Often the whole system is not in bad shape. It may be that only a few critical parts are holding up the entire team.

In that case it can be far more sensible to fix those parts deliberately than to add people or new technology as a general remedy.

When more developers really are needed

There are of course situations where growing the team is the right decision.

For example if:

• the product and the priorities are clear;
• how the system works is reasonably well understood;
• the development process is predictable;
• release and testing are not a constant obstacle;
• onboarding new colleagues can be planned;
• the team genuinely needs more execution capacity.

Headcount helps meaningfully once we know what work has to be done, and what is currently preventing it from being done.

If we do not know that, growing the team easily results in nothing more than a bigger team with the same problem.

We do not start by building

A slowdown in development is an important signal, but on its own it does not tell you what the solution is.

Maybe more people are needed. Maybe the release process has to be fixed. Maybe a critical module has to be restructured. Maybe how the system behaves needs to be made more visible. And it may well be that several of these are needed — but the order matters.

That is why I do not start by building, but by understanding.

First we have to establish where the system, the process or the capacity is getting in the way. Only then can a responsible decision be made about the next step.

The goal is not to change things at any cost. It is to make development predictable and safe again, with the smallest justified change.