Why Do We Have So Many Developers?

Answering CEOs Favorite Question: 13 Reasons Why Engineering Gets Too Large

👋 Hi Technocrats,

I’m sure you’ve heard this question before: “why do we have so many developers?” In fact, CEOs and CFOs love asking this question. And it’s a good one. Sometimes Engineering Teams do get too big for the business. We’ll dive into why and what to do about it.

Cheers & keep the shark swimming! 🦈 Bobby

Mid-market company CEOs often scratch their heads wondering why their engineering teams keep growing yet productivity doesn’t scale proportionally.

At board meetings, leadership retreats, and financial reviews, one question keeps surfacing repeatedly: why do we have so many (expensive) developers?

Despite having larger teams, the CEO is still seeing project timelines slip, budgets expanding, and productivity stagnating.

So this is a very natural question for the CEO and CFO.

I outline 13 blunt reasons why companies find themselves buried under developer headcount.

Understanding these reasons is the first critical step towards creating a more balanced organization and ultimately improving the results of the engineering teams.

The 13 Reasons

1. Companies want to feel successful so they hire unnecessarily

2. Technology teams often have highly inaccurate estimates for work

3. Product roadmaps can be irrelevant feature factories

4. A lot of businesses have huge technical debt & don’t realize it

5. Sometimes the company culture is simply slow, requiring more devs

6. Technical complexity in software is generally going upwards

7. Some people just like to be complacent at times

8. Specialization is increasing in software engineering globally

9. Because companies have the money

10. Engineering org design often doesn’t suit the business

11. Companies are afraid to let people go

12. Engineering may be bad at automation

13. Management makes too many irrational demands

Now let’s get into the details of each one.

Companies Want to Feel Successful

Growing mid-market companies often equate success with increased headcount. Adding more developers can signal strength and stability to themselves, investors, boards, and customers.

This perception can drive companies to hire unnecessarily, focusing more on appearances than on actual productivity or outcomes desired.

Unfortunately, this superficial measure of success often does not translate into real business value as exampled by large companies getting out-classed by smaller competitors.

Headcount growth without corresponding increases in outcomes or efficiency simply inflates expenses and frequently dilutes accountability across the organization.

At the base of this issue is an emotion or feelings-based driver, not a set of facts. To solve this particular issue that emotion must give way to clear numbers and data.

Engineering Teams Often Make Bad Estimates

Engineering teams are notorious for underestimating the complexity and level of effort for large and even medium sized projects.

Poor estimates lead to inflated hiring plans. This is especially true in scenarios where engineering is unsure about a project. In this case they often pad the hiring.

This cycle compounds quickly, where each missed milestone prompts even more aggressive hiring to make up for the slippages.

Instead of adjusting estimates or managing expectations, businesses often double down, swelling the developer count with diminishing returns.

CEOs and CFOs must force engineering teams to get better at making estimates. This is literally one of the biggest drivers for unnecessary headcount.

Roadmaps Can Become Feature Factories

Roadmaps are the lifeblood of an engineering team. It is the primary driver for the demand placed on engineering.

Many product roadmaps are little more than feature factories, producing an endless stream of work without any clear business value (which drives CEOs nuts).

Teams are constantly adding features without evaluating their necessity or impact, causing unnecessary growth in engineering headcount.

When every requested feature is deemed essential, companies continually add developers to churn through endless & pointless backlogs.

This feature factory mindset results in sprawling teams working tirelessly on tasks disconnected from core strategic objectives.

If you want to fix this problem get a really good Product Team!

Technical Debt Is Getting Scary

In general, software systems are getting older and larger leading to enormous amounts of technical debt.

This technical debt accumulates silently over time, as quick fixes and shortcuts build up into major problems eventually.

Many companies underestimate the sheer volume of time and effort developers spend maintaining their outdated and unstable systems.

In fact, unrecognized technical debt forces teams into constant firefighting mode.

Rather than slowing down and tackling debt systematically, businesses respond by hiring even more developers, inadvertently deepening inefficiencies.

The right answer here is to strategically pay down technical debt on a consistent basis while intelligently ignoring the rest.

Company Culture Can Be Inherently Slow

Some companies just have a really slow culture and don’t necessarily care that it’s slow or even know that it is.

I’ve seen too many examples of companies like this to count.

Invariably their developer headcount is massive. They keeps slotting people in because it takes them 10 times more people to do the same thing a high velocity organization would need.

The funny thing is in such environments, developers spend more time waiting on decisions and approvals than actually doing engineering.

To combat these inefficiencies, management mistakenly hires even more developers, assuming increased manpower will speed up output.

Instead, this typically increases bureaucracy, further reducing overall speed.

To fix this look at your company culture across the board. You need to create a sense of urgency ASAP.

Software Complexity is Astoundingly High

Modern software stacks have become exceptionally complex, integrating cloud services, numerous programming languages, and advanced security measures.

This complexity requires specialized knowledge, increasing the number of roles and developers necessary to manage and maintain systems.

As complexity grows, so does team size.

The overhead and coordination required to manage complex platforms slow teams down, further driving the need for more hires.

To fix this problem the CTO and engineering leaders must have a laser-focus on simplicity in the technical stack.

Avoiding technical complexity should be a core part of leadership and developer roles.

People Can Be Complacent

Let’s be honest: people can just be complacent at times.

This connects to the earlier note about company culture, but it’s a bit different in the sense that you have to be serious about exiting highly complacent individuals from the team.

People who fall into complacency, preferring to remain comfortable rather than stretching their capabilities or expanding their skill sets drives headcount up.

Their managers don’t get a lot of output from this kind of team so they augment them with new hires. We’ve all probably seen this a hundred times.

You must encourage existing staff to grow. If they aren’t growing they should find a company where being stagnant is OK — and there are lots of them out there.

Technical Specialization is Increasing

As technology diversifies, specialized roles in frontend, backend, DevOps, security, data engineering, and more become standard.

This specialization leads to hiring multiple experts for each discipline, causing developer numbers to rise significantly.

With specialization comes increased coordination overhead as well. You have to hire more managers to handle more developers.

This complexity slows down productivity, creating a cycle where even more specialists are hired to try to keep up, exacerbating inefficiencies.

To address this issue it’s critical to do 3 things: keep the roadmap focused, keep the tech stack as simple as possible, and finally scrutinize every hire to see if they are really needed.

Because Companies Have the Money

This one sounds silly but is true.

Companies flush with funding or fast growing revenue streams often hire developers simply because they can afford to (they have the budget).

Easy access to resources can lead to really lax hiring practices and bloated teams. We’ve all seen this one a 100 times as well.

Without strict financial oversight or clear financial goals, companies accumulate developers without assessing true necessity.

Over time, this habit creates large, unwieldy teams that lack clear direction and purpose. They were hired during times when the company was flush with cash.

The CFO must be very strong to fix this one. He or she has to be strict no matter how well the organization is doing.

The Organizational Design is Wrong

Sometimes engineering teams are designed the way they are because of momentum or random desires of leadership & not proper logic.

In other words, the size, shape and complexity of the engineering team is sometimes not at all lined up with the needs of the business.

You may have a data science team of 40 in a company of only 200. Maybe it makes sense for you or maybe not. But has it been questioned?

Poor organizational design is a thing in engineering just like any other department and it needs to be looked at very carefully to avoid driving headcount bloat.

The fix is actually easy. Once a year the CTO/CPO and CEO/CFO should sit down and look over the org structure and decide if it’s a fit or not.

Companies Are Afraid to Let People Go

Businesses often fear making tough staffing decisions. This is especially true for businesses in employee friendly states.

Whether due to culture, emotional discomfort, or risk aversion, companies avoid downsizing even when teams are clearly overstaffed or underperforming.

This reluctance traps businesses in a cycle of inefficiency, sustaining bloated teams that drain resources and reduce productivity rather than enhancing output.

Cutting staff can lead to bad morale, lack of confidence from the market or lawsuits. However, it’s required sometimes if headcount is to be keep balanced.

Companies should have strong legal departments when necessary, strong performance review systems and strong HR policies & guidance related to performance-based exits.

Keeping under-performers is a disservice to everyone.

The Dev Org is Bad at Automation

These days with AI if your business is not automating you’re running behind your competitors for sure — it’s a very big deal now.

Poor automation practices mean developers spend disproportionate time on repetitive, manual tasks such as testing, deployments, and infrastructure management.

Without proper automation headcount can grow unchecked.

Companies wrongly respond to organizational inefficiencies by adding more developers rather than addressing the automation gaps directly.

All CEOs should be investing in automation in Engineering. This is not a nice-to-have but a must-have in this day and age to keep headcount balanced.

Management Makes Ludicrous Demands

Of all the reasons this is the one people most stakeholders don’t admit to. However, it is a highly important and common driver for headcount increases.

Let’s look at a couple of examples:

• A CFO needs some analytics to happen so the CTO hires a contractor to help. Later that contractor turns into a full time hire. The need is long gone but the role is still around.

• The ELT wants to build a new product. They have’t done their homework but it sounds cool. The CTO goes off and hires a team offshore.

You see how common this type of thinking is.

Executives often impose unrealistic deadlines, unclear expectations, or unmanageable workloads on engineering teams.

Developers struggle to meet chaotic demands, causing management to reflexively increase headcount.

Instead of clarifying and prioritizing tasks effectively, management perpetuates the cycle of ineffective hiring.

This dramatically inflates developer headcount while failing to improve outcomes, perpetuating frustration for all parties involved.

To fix this the CTO and Product Leader need to be super strict about the “top of the funnel” demand coming in to Engineering.