There was a period in my career when we needed to deliver more software.
The demand was there. The team was busy. There was more work than we could comfortably handle.
So we did what seemed like the obvious thing.
We hired more developers.
And it worked.
We delivered more.
But as the development team grew, something else started to happen. The problems around delivery grew with it.
Looking back, the mistake wasn’t hiring more developers. We needed the additional capacity.
What we hadn’t done was scale the way we worked at the same time.
More people didn’t remove the dependencies
At the time, a lot of knowledge was concentrated in a small number of senior people, including me.
Handing a piece of work to somebody wasn’t always a quick conversation.
Sometimes I could spend hours explaining the problem, the history behind it, where changes needed to be made and what somebody needed to be careful about.
Under delivery pressure, there was an obvious temptation.
I could spend several hours handing the work over, or I could do it myself in considerably less time.
Very often, I chose the latter.
For that individual task, it was probably the fastest decision.
But the next time similar work appeared, the dependency was still there.
As the team grew, this became increasingly difficult. Developers could finish what they were working on and sometimes there wasn’t enough time to prepare and explain the next piece of work.
We had increased our development capacity, but some of that capacity was waiting on the same people it had depended on before.
More development meant more changes to manage
There was another constraint.
We were using SVN and our process for bringing software changes together involved a significant amount of manual merging.
With a smaller development team, that had been manageable.
As we added developers, more work happened in parallel. More changes were being produced, and more changes needed to be merged.
The process around development hadn’t grown with the development team.
We also had around 20 pieces of software at the time. As the volume of development increased, keeping track of who had changed what became increasingly difficult.
And then those changes needed to be deployed.
Deployment was manual too, and much of that responsibility also came through me.
I made mistakes.
I remember merging something incorrectly. I remember deploying to the wrong place.
It would be easy to look back and describe those simply as human errors. They were.
But today I look at them differently.
We had a process in which an increasing amount of software change depended on people correctly performing a series of manual steps.
Adding more developers increased how much change entered that process. It didn’t increase the ability of the process to handle it.
We filled gaps by taking on more ourselves
The same pattern appeared elsewhere.
We didn’t have a dedicated DBA. Database work therefore became another responsibility I covered alongside everything else.
Developers had access to production because they sometimes needed it to get things done. That solved an immediate problem, but it also meant mistakes could happen directly in production.
None of these decisions felt unreasonable in isolation.
We weren’t deliberately designing a difficult way of working.
Most of the decisions made sense in the situation immediately in front of us.
Doing the task myself was quicker.
Manual deployment got the release out.
Giving somebody access allowed them to solve the problem.
Hiring another developer gave us more capacity.
The difficulty was what happened when all those individual decisions accumulated while the organisation continued to grow.
Eventually, adding people wasn’t enough
There wasn’t one reason why delivery eventually became more difficult. There were several, and some of them became clearer to me only with hindsight.
But the pattern I recognise today is straightforward.
We had scaled the number of people producing software faster than we had scaled the way the organisation supported them.
More developers gave us more development capacity.
They also created more work that needed to be understood, coordinated, merged, deployed and supported.
And some of the people who were already bottlenecks became even more important as the team grew.
At some point, adding another developer doesn’t necessarily remove the constraint.
It can simply send more work towards it.
What I think differently about today
Today, when I think about growing an engineering team, I don’t think about the number of developers in isolation.
I think about what needs to grow around them.
Can another engineer pick up meaningful work without depending on one person to explain everything?
Can several developers make changes in parallel without creating a merging bottleneck?
Can those changes be tested and deployed consistently without relying on somebody remembering a sequence of manual steps?
Can we see what changed, who changed it and what happened afterwards?
Can engineers investigate and resolve problems without needing unrestricted access to production?
And are we building knowledge into the team rather than continuing to concentrate it in a few individuals?
These experiences are part of why I put so much emphasis today on automated delivery, clear ownership, observability, controlled access, documentation and knowledge transfer.
Not because they are fashionable engineering practices.
They create the conditions in which a team can grow without every additional developer increasing the pressure elsewhere in the organisation.
Hiring wasn’t the mistake
If I went back to that period, I wouldn’t conclude that we shouldn’t have hired those developers.
We needed them.
And they did help us deliver more.
What I would think about differently is what needed to change alongside the team.
The processes that work with a handful of people don’t necessarily work with ten.
The knowledge held by one senior person becomes increasingly expensive as more people depend on it.
A manual process that happens occasionally can become a significant constraint when the volume of change increases.
And shortcuts that help you move quickly today can quietly become part of the operating model tomorrow.
Adding developers is relatively easy.
Scaling the way the organisation works around them is the harder part.