The Engineers Who Exist on the Org Chart, but Not in Your Capacity

Imagine an organization with 1,000 software engineers.

Across those 1,000 people, significant engineering time may be consumed by activities such as:

• Fixing defects that escaped from requirements, design or implementation
• Investigating and reproducing issues
• Reworking completed functionality
• Stabilizing releases
• Waiting for builds, environments, approvals or other teams
• Resolving integration problems
• Switching repeatedly between planned work and urgent issues
• Managing accumulated technical debt

None of those engineers has disappeared.

Their capacity has.

If, collectively, 35% of available engineering capacity is consumed this way, the organization doesn’t really have 1,000 engineers available to create new product value.

Its Effective Engineering Capacity is closer to 650.

That raises a question I think every software executive should be able to answer:

How many effective engineers does your organization actually have?

Where Does the Missing Capacity Go?

Engineering capacity rarely disappears because of one catastrophic problem.

It leaks away throughout the Software Development Lifecycle.

A requirement ambiguity isn’t detected during requirements analysis, so it reaches architecture.

A design issue isn’t detected during design, so it reaches implementation.

A coding problem isn’t detected during implementation, so it reaches integration.

Eventually the problem is discovered—but now several people, teams and artifacts may be involved in correcting it.

The later an issue is detected relative to where it was introduced, the more engineering capacity is generally required to resolve it.

The defect itself is therefore only part of the cost.

There is also investigation, coordination, rework, rebuilding, retesting and context switching.

Multiply this by thousands of issues across a large engineering organization and an enormous amount of engineering capacity can be consumed without ever appearing as a line item in the R&D budget.

Calculating Effective Engineering Capacity

The basic concept is surprisingly simple:

Effective Engineering Capacity = Engineering Headcount × Productive Capacity Ratio

For example:

1,000 engineers × 65% productive capacity = 650 effective engineers

The difficult part isn’t the arithmetic.

It’s determining the productive capacity ratio.

To understand that, you need to identify where engineering capacity is being consumed across the entire development lifecycle.

At BetterSoftware, we examine 35 competencies across the SDLC, from requirements and architecture through implementation, verification, integration and release. The objective is to identify where problems are injected, where they are detected, and how much downstream activity they create.

This matters because simply measuring developer activity won’t reveal the problem.

A developer can be extremely busy while creating zero net-new product value.

Why More Developers May Not Solve the Problem

Suppose our 1,000-engineer organization wants 10% more output.

The obvious solution is to hire another 100 engineers.

But consider the alternative.

If the organization currently operates at an Effective Engineering Capacity of 650 engineers, increasing productive capacity from 65% to 75% produces:

1,000 × 75% = 750 effective engineers

That’s the equivalent of 100 additional engineers’ worth of productive capacity without hiring 100 additional engineers.

The people were already there.

The organization simply reclaimed more of their capacity.

This is why engineering effectiveness can be economically very different from traditional cost reduction.

The objective isn’t necessarily to employ fewer engineers.

It’s to get more value from the engineering organization you already have.

The Most Important Question Isn’t “How Productive Are My Developers?”

This distinction matters.

Effective Engineering Capacity isn’t intended to measure whether individual developers are working hard enough.

In most organizations we’ve worked with, developers aren’t the problem.

The system surrounding them is.

A developer fixing a production defect for three days may be working extremely hard. But if that defect could have been prevented or detected months earlier, the organization has still lost productive capacity.

The better question is therefore:

How effectively does our software engineering system convert engineering time into product value?

And once you can measure that, something interesting happens.

Instead of launching dozens of improvement initiatives, you can identify where the largest amounts of capacity are being lost and focus there first.

What Would 10% More Effective Capacity Be Worth?

Take the 1,000-engineer organization again.

Reclaiming just 10 percentage points of engineering capacity would create the equivalent productive capacity of approximately 100 additional engineers.

No recruitment.

No additional headcount.

No additional offices.

No additional management layers.

The same engineering organization simply produces more value from the resources it already has.

For a large R&D organization, even a relatively small improvement in effective capacity can therefore represent a substantial economic opportunity.

And this is why I think Effective Engineering Capacity may be a number worth putting next to engineering headcount on the executive dashboard.

We routinely know exactly how many engineers we employ.

Perhaps we should also know how many effective engineers we’re actually getting.