Engineering Leadership
The Problem With Rising Engineering Costs:“We Just Need More Engineers”
Before you hire your way out of a delivery problem, find out whether it's really a headcount problem.
We have all experienced this at some point.
A project is late. Engineering costs are rising. The team is busy. Deadlines slip, customers wait, and the roadmap keeps getting pushed.
Then we hear: “We just need more engineers.” It sounds reasonable.
If the work exceeds what the current team can handle, adding people should increase capacity. And sometimes, it absolutely does. A company that has genuinely outgrown its engineering team eventually needs to hire.
But hiring more engineers is often treated as the solution before anyone understands the problem.
A team can be overloaded because it has too much work in progress. It may spend much of its time maintaining old systems. Engineers may be waiting for other teams, dealing with unexpected production issues, reviewing large amounts of code, or working on projects that are no longer important to the business.
In those situations, adding five more engineers doesn't necessarily make the company five engineers more productive. It can simply make an expensive system larger.
The better question is not: “Do we need more engineers?” It is: “What is happening to the engineers we already have?” That question can tell you much more about where your next engineering investment should go.
More People Doesn't Always Mean More Output
There is a simple assumption behind hiring: more engineers → more capacity → more output.
Sometimes that works. But software development doesn't work that way, adding more engineers doesn't automatically mean more output.
Engineers work within systems. They depend on other engineers, product managers, designers, infrastructure teams, customers, decisions, and sometimes external vendors. Adding people also creates additional work.
New engineers need onboarding. Someone has to explain the architecture, review their early work, answer questions, and help them understand how the organization operates. More people also mean more communication.
A five-person team can make certain decisions quickly. A twenty-person team may need more meetings, more coordination, more reviews, and clearer ownership. And if several teams depend on one another, adding people to one team may not remove the bottleneck.
Let's consider that a product team is waiting for an infrastructure team before it can release a major feature. Hiring three more product engineers doesn't necessarily solve that problem. The product team now has more people available to work on something that is still blocked.
The same thing happens when a team has too much work in progress. If engineers are already working on ten different initiatives, adding more engineers can result in more initiatives being started rather than finished. The company gets busier, but the work doesn't get done any faster.
This is why engineering productivity is not simply a question of how many people are on the team. It is also about how effectively the organization turns engineering effort into completed, valuable work.
Before Hiring, Look at Where the Current Team's Time Goes
One of the most useful questions a leadership team can ask is surprisingly simple: “What are we actually paying our engineers to spend their time on?”
The answer may be different from what appears on the roadmap. A team might officially be working on a new product feature, but much of its time could be going elsewhere — for example:
None of this work is necessarily wasteful. Maintenance keeps the business running. Bug fixes protect customers. Code reviews protect quality. Technical debt sometimes has to be addressed.
The problem is visibility. If leadership sees only the roadmap, it can look like the team is simply moving too slowly. But if half of the team's capacity is being consumed by maintenance and unplanned work, the situation looks very different.
The company may not have an engineering team cost problem. It may have a capacity allocation problem. That distinction matters because the solutions are completely different — you might need another engineer, or you might need to reduce maintenance, stop a low-value project, improve ownership, remove a dependency, or address technical debt that's slowing down every new piece of work.
Without that visibility, hiring becomes a guess.
The Real Cost of Getting This Decision Wrong
Hiring engineers is one of the most significant recurring commitments a technology company can make. The obvious cost is salary. But salary is only part of the software development costs involved.
Recruiting costs, onboarding time, management overhead, equipment, software, infrastructure, benefits, and the opportunity cost of the people responsible for getting new employees productive all add up. There is also a less obvious cost: organizational complexity. A larger engineering organization requires more coordination — more teams, more ownership boundaries, more communication paths, and more decisions that need alignment.
None of this means companies shouldn't hire. It means hiring should be treated as an engineering investment, not simply as a response to a growing backlog.
Company A
Hires Eight Engineers
A major project is six months behind schedule, so the team gets bigger.
Company B
Investigates the Delay
Finds 35% of time going to maintenance, two teams blocked by the same dependency, and a project that's no longer a priority — then fixes the allocation instead.
Company B may still hire later. But when it does, it knows why. The problem isn't hiring more engineers — it's hiring them without a clear purpose or understanding of the problems they're meant to solve.
What Should a CEO Look at Before Hiring?
A CEO doesn't need to understand every technical detail of the engineering organization. But they do need enough visibility to ask better business questions.
Where is engineering time going?
How much capacity is going toward new product development? How much goes toward maintenance, bugs, support, infrastructure, technical debt, and other unplanned work? This helps distinguish a genuine capacity problem from a work-allocation problem.
Which projects are taking longer than expected?
Delays matter, but the pattern behind them matters more. Is one project unusually difficult, or do most projects consistently take longer than expected? If projects repeatedly miss expectations, adding engineers may not address the underlying issue.
How much work is unfinished?
A large backlog can create the impression that the team needs more capacity. But the more useful question is how much work is actively being worked on. Reducing work in progress may improve delivery more than increasing headcount.
Where are teams waiting on each other?
Dependencies are easy to overlook from the executive level. Look for repeated handoffs, blocked work, delayed reviews, infrastructure dependencies, and decisions that require another group.
How much work is unplanned?
Frequent incidents, urgent customer requests, recurring bugs, and operational problems can quietly reduce the capacity available for strategic work. If unplanned work is consistently high, adding engineers may only hide the problem.
Are the most expensive resources on the highest-value problems?
A company can have a highly capable engineering team and still allocate that capability poorly. The question isn't whether people are working hard — it's whether effort is directed at what matters most.
Sometimes the Problem Is the Work, Not the Team
Leadership teams should consider another uncomfortable possibility. Sometimes the engineering organization isn't the primary problem — the company may simply be asking the team to do too much. Five major initiatives may all be considered priorities.
Every stakeholder wants their project completed. Nothing gets stopped. The engineering team tries to accommodate everything. Eventually, everything moves slowly, and the conclusion is simple: “The team needs more people.”
But the real problem may be prioritization. A larger team cannot compensate indefinitely for an organization that keeps adding priorities. The same applies to technical debt — if every new feature requires engineers to work around fragile systems, hiring more engineers just increases the number of people experiencing the same friction.
This is why engineering management and business leadership need to look at delivery as a system rather than treating headcount as the main variable.
Hiring More Engineers Can Still Be the Right Answer
None of this means hiring is wrong. Some situations genuinely require more engineers — the product may have grown significantly, or there may be clear initiatives the existing team cannot reasonably support.
Perhaps the company has already removed unnecessary work, reduced dependencies, improved prioritization, and understood where capacity is going — and there is still more valuable work than the team can handle. That's a strong case for hiring, because the decision is now based on evidence.
You can say: “We have more high-priority work than our current capacity can support.” That's very different from: “Everyone is busy, so let's hire.” The first is an investment decision. The second is a reaction.
Where GitRevio Fits
Tools such as GitRevio can help leadership and engineering teams connect engineering activity with delivery patterns so they can better understand what is happening across the software development team. The goal isn't to create a leaderboard for developers or reduce engineering performance to a single number — it's to make patterns easier to see.
Instead of asking “Why is engineering taking so long?” you can start asking more useful questions:
- “What is consuming the team's capacity?”
- “Where are the bottlenecks?”
- “Which work is taking longer than expected?”
- “Is this a capacity problem or an organizational problem?”
- “Would another five engineers actually change the outcome?”
That last question is often the most valuable one. GitRevio doesn't need to answer whether you should hire — it can provide more context before you decide.
Make Hiring a Decision, Not a Reflex
When delivery slows down, hiring more engineers is an understandable response. But it shouldn't automatically be the first one. Before increasing the engineering team costs, take a step back. Understand where the current team's time is going.
Look at unfinished work. Understand dependencies. Examine unplanned work. Look at maintenance and technical debt. Question whether priorities are clear. And, most importantly, ask whether engineering capacity is being spent on the work that matters most to the business.
Sometimes the answer will still be: “Yes, we need more engineers.” That's a perfectly reasonable conclusion. But sometimes the answer will be something else — fewer priorities, clearer ownership, removing a bottleneck, investing in the systems slowing everyone down, or stopping work that no longer matters.
And sometimes, you may discover that the team has enough people — they just don't have enough capacity because too much of that capacity is being consumed elsewhere. For founders, CEOs, and other leaders responsible for the engineering budget, that distinction can be worth a lot of money.
The goal isn't to keep the engineering team small. The goal is to make sure every increase in engineering investment solves a real business problem.
So the next time someone says, “We just need more engineers,” don't reject the idea. Just ask one question first: “What is happening with the engineers we already have?” The answer may tell you what to do next.
Frequently Asked Questions
Hire more engineers when the current team cannot handle important work. First, make sure the problem is really a lack of people.
More people do not always mean faster work. Teams may still face too many tasks, unclear priorities, technical debt, and delays between teams.
Check where engineers spend their time — maintenance, bugs, unfinished work, unplanned tasks, and projects that are taking too long.
By reducing unnecessary work, focusing on fewer projects, and fixing the problems that slow engineers down.
Look at how work moves through the team — check delays, unfinished work, blocked tasks, and where engineers spend their time.