Why hiring more developers costs more than you think

Introduction

Hiring more developers may cost more than you think. Scaling challenges are rarely caused by a lack of developers or how many lines of code are written each sprint. Let’s explore some of the challenges caused by prematurely expanding your team, and why you’re less likely to scale your productivity and more likely to scale your existing bottlenecks.

A story about the urge to hire more developers

It’s Tuesday morning, and the team has just started sprint planning. It doesn’t take long before myself and another developer start pushing back which tickets are doable. But we just can’t realistically do enough in the sprint to keep the project on track.

Leadership is frustrated, the development team is frustrated, clients are getting frustrated. Finally, someone speaks up: “Maybe it’s time we hire more developers?” I naively agree — more developers working means more work gets done. Right?

Things are never as simple as they seem. Within a few weeks, it is clear that hiring more developers has slowed velocity even more. So what exactly is the problem? Why hasn’t this seemingly sound plan worked out?

The hidden costs of hiring more developers

Hiring experienced developers is expensive; and not just because of the additional salaries. To hire, you need people to review resumes and conduct interviews. We are already underwater and adding several hour-long meeting blocks throughout the week doesn’t help. So deadlines are adjusted again, and the search is on. Within a few weeks, we have found our new team members. Finally, things are going to start improving. Right?

Even if you have the best onboarding process in the world, new team members will still need time to learn about the project, the team itself, and everything in between. To help get our new hires acquainted with everyone, we assign each person an onboarding buddy. This gives each new hire someone to shadow, to ask questions, and to learn from. 

The hiring process might be over, but now the onboarding process begins. Just like with hiring, this too is not free. I now find myself juggling my day-to-day tasks while also trying to onboard a new developer. These are the perfect conditions for burnout, and burnout is the last thing you want in this environment.

More developers, more problems

It’s now six months later and each of the newly hired developers has a good understanding of the project, their role, and team dynamics. This is it, the moment we’ve been waiting for.

We’re tackling more points each sprint, features are being implemented, bugs are being fixed, and the backlog is shrinking. Right?

That is the expectation at least; unfortunately, the reality is anything but.

Sure, bugs are being fixed and new features are being built, but the overall team velocity is about the same as it was before we expanded. So what happened? Why didn’t hiring more developers solve our issues? Let's break it down.

Identifying the bottlenecks

Too many cooks in the codebase

You’ve likely heard the expression “Too many cooks in the kitchen” — the idea that too many people working in a confined space will start getting in each other's way and blocking others' progress.

This principle applies to software development in much the same way. With more developers writing more code, the number of pull requests increases and so too does the number of pull request reviews.

It's inevitable that eventually, one or more developers will become blocked as they await others to review their pull requests. Sometimes, a developer might even be blocked by another developer's pull request if it introduces new code that they need to complete their own work.

Communication complexity slows down development

Communication is hard and the more people involved, the more complex it gets. A smaller team generally has a much easier time communicating and sharing knowledge. As you start adding more people though, the amount of communication needed to maintain that same level of knowledge sharing becomes almost unmanageable.

Imagine trying to mentally keep track of everything you need to do and everything each other person on your team is doing. The solution to this is to utilize knowledge bases like Confluence or Notion. But even in the ideal scenario, where everyone has time to update them with their knowledge, do you have time to read all of it all of the time? Of course not, you reference what you need, when you need it. 

These bottlenecks are both major issues that exist in some form before growing the team, and will continue to be an issue as the team increases. 

Uncovering root causes holding back your team

The worst bottlenecks often exist long before any hiring. And these bottlenecks are often the real reason velocity isn’t where it could be. Let's explore a few pitfalls that may be the real reason behind your team's woes.

Unclear or incomplete tickets lead to rework

No amount of developers is going to overcome missing or unclear requirements in a ticket. In fact, the more developers you have trying to work through messy tickets, the more bugs that will be produced.

More bugs leads to even more frustration within the team and for the client as well. It’s a vicious cycle of fixing, deploying, and then finding out the “fix” was wrong or didn’t work. This is a major contributor to team burnout.

Technical debt makes development more complicated

Technical debt is the sometimes hidden cost of using a quick or easy solution over a more appropriate one.  It can turn simple refactors into complex messes, introduce endless bugs, and lower morale.

Before hiring, take some time to analyze your backlog and see how many tickets are caused or blocked by tech debt. Maintenance is an important part of any system, and your software is no exception. Dealing with your technical debt can feel impossible, but by iterating a little bit each cycle, you’ll find it gets a little easier each time.

Little or no tooling kills velocity

In my case, our team was severely lacking in tooling, which resulted in developers spending hours and hours doing repetitive tasks each sprint. Sure, having more developers did technically help here, but how many extra hours were being wasted?

Custom tooling isn’t always appropriate either. However, proper CI/CD pipelines, dependency update bots, and reproducible development environments will almost certainly improve your team's velocity.

By spending less time on repetitive tasks, you’ll find you have far more time to focus on priority features. As a bonus, when it does come time to scale, new team members will spend far less time on setup and more time learning about your software.

Final thoughts

Before hiring more developers, spend some time thinking about major pain points you and your team are currently facing. I can assure you that there’s likely plenty of room for improvement in your current process that won’t be solved by adding more hands. When it's time to hire, you and your team will be much more confident in onboarding.

Not sure where your processes can improve? We’re great at pattern matching across similar systems and business situations, so we can help make recommendations that will stick.

We meet your teams where they are and help make incremental improvements in both codebases and processes. Let’s talk about how we can help. 

‍