TBM 334: The Capacity Allocation Illusion

One of the big challenges of offering a customizable tool in the product space is that you risk reinforcing unhelpful practices.

I can't think of a better example than time tracking (or points tracking) and allocating "team capacity" to different objectives, investment categories, etc. While intuitive on the surface—and maybe even marginally helpful—it obscures a much more nuanced view of capacity.

The big threat of oversimplifying capacity and how you "spend" it is that you may not make the future investments necessary to sustain and grow it.

If someone has recently asked you, "So where did our $###m in salaries go in 2024? Do you mind getting a rough breakdown of where people spent their time?" I think you might enjoy this post, and the video at the bottom of the post.

Capacity Perspectives

Imagine that I ask you to frame the idea of "capacity" in the context of a factory. If you're like most people without deep manufacturing experience, you'll respond with something like this:

I'd imagine it is a function of the layout, the machinery, whether you can add people, the length of shifts, how often the line goes down and needs to be repaired, etc.

That's a good start!

People with more background in manufacturing will offer ideas like:

You have to consider factors like supply chain reliability, the quality of raw materials, equipment maintenance schedules, seasonal demand, and energy costs. And it 100% depends on the current bottleneck. One thing can limit the output of the whole line, no matter how well everything else is running. Also, capacity isn't just about how much you can produce but how consistently you can hit that number under real-world conditions. There are many ways to theoretically boost production in the near-term that are unsustainable long-term in the real world.

Say you meet someone with a finance and macro/micro economics background.

They weigh in:

You need to think about capacity in terms of expected demand and how prices might shift as a function of that demand. And then there's the relative cost of increasing capacity. Some approaches are cheaper, like tweaking processes or adding shifts. However, retooling machinery or building a new factory can be way more expensive. You also have to factor in interest rates, access to capital, and the broader economic environment.

The Plot Thickens

Current capacity is the result of many factors. Some involve long-term investments, such as infrastructure and machinery, while others are more short-term and interchangeable, like labor or shift adjustments. Some things are easier to change, while others are more difficult and expensive.

A factory's current capacity is the output of countless investments and decisions, and its future theoretical capacity is a mix of expected constraints, market dynamics (e.g., demand), and economics. To make smart decisions, you have to make predictions about the state of the industry and world and factor in uncertainty and different scenarios.

This is why manufacturers struggle when conditions shift unexpectedly. Their factories are not optimized for the new environment. Provided it makes economic sense, they must retool, reskill, rethink their supply chain, adjust inventory, repurpose equipment, etc. They may have to write down inventory, assess for "impairments," accelerate depreciation, and juggle the optics of the hit on earnings.

Software Development

Shifting to the software product development world, let's brainstorm the investments that constitute our "current capacity." Today's capacity is a function of investments in:

1. Hiring, onboarding, training, developing, and retaining employees

2. Developing high-performing teams with trust and psychological safety

3. The current organizational structure, reporting lines, etc.

4. Insights about the market, customers, partners, competitors, the codebase

5. Building "the product" and everything learned while building the product

6. Working (or not working) down technical debt

7. Tools, systems, and infrastructure to enable teams

8. Partnerships, brand equity, and customer relationships/goodwill

9. Taming bureaucracy, waste, friction, perverse incentives, etc.

10. Efforts to strengthen and preserve the unique culture

The challenge is that when software teams talk about "spending" or "allocating" capacity, they fall into the trap of boiling capacity down to # of engineers multiplied by working hours. Meanwhile, as we learned in our factory examples, the question of where (and how) a team "spends" its capacity is so much more nuanced.

Two brief examples:

1. I once worked at a company that encouraged a lot of mobility between teams. Despite it likely being less efficient in the short term, it had the benefit of giving people broad exposure to the codebase, different customer personas, and different teammates and team environments. When conditions changed, the company was able to adapt without too much disruption. Meanwhile, I've worked at other companies where deprioritizing a particular product area meant almost certain layoffs due to more rigid reporting lines and budgeting. Decisions in both companies impacted the nature of their capacity.

2. Picture a team experiencing debt-induced friction and high context-switching costs caused by juggling too many efforts simultaneously ("I'm sorry, they are all high priority"). The team's capacity to deliver impactful changes is low, not because they lack hours, but because the system is overwhelmed and the code is hard to work with.

Both examples involve investments in (and decides related to) capacity building.

An executive asking, "Where did our money go this year?" (where money is time and salaries) is asking a reasonable but ultimately reductive question. They should ask, "How are we spending, and how should we spend our years of investment in current capacity? And how are we setting ourselves up for future success?"

Time is a small piece of the picture. When we talk about where we allocate our time, we're not talking about what we invested. Reported time allocation doesn't account for the historical investments that shape where time is going (and can go) today, the depreciation (or appreciation) of those investments, etc.

I have observed teams fret over whether to allocate 20% or 30% to refactoring and debt work-down when, meanwhile, they are experiencing 40-70% drag in everything they do. Also, they're unsure whether their work is moving the needle for customers. To top it off, they spend 5-10% of their time doing data entry so that finance can look at neat-and-tidy reports showing "time investment by the initiative" or "time investment by strategic pillar."

That's wild if you think about it!

Or not: it could be that the cost to remove that drag (and collect those impact metrics) is deemed prohibitive, and there's questionable demand for the product. As we discovered in our manufacturing examples, it isn't as simple as waving a magic wand and increasing capacity. It might not be worth it. Either way, oversimplified time allocations aren't the path to figuring that out.

Conclusion

Capacity in the context of software development is different from manufacturing in a couple of key ways:

1. Teams frequently tackle new, novel problems.

2. Adding more people to a software team doesn't linearly increase capacity (though I have seen large groups self-organize into smaller, loosely coupled groups to get something big done).

3. Teams build and maintain the factory while operating it

4. They maintain and upgrade what they "ship" for long periods of time.

5. Teams must monitor and respond to feedback in tighter loops.

6. The tool and technology landscape changes rapidly

7. Capacity in software relies heavily on intangible assets like shared context.

In manufacturing, we intuitively think of "capacity" as the ability to produce more goods. But capacity can take many forms. It could mean the capacity to innovate, the capacity to adapt to new technologies, or the capacity to learn from the market.

While different from manufacturing in many ways, he foundational principles are the same. You invest to build, sustain, grow, and adapt it (if economically viable). Where you invest your time and energy can be a helpful data point, but it is only part of the bigger picture.

So what do you do if a company leader asks, "So where did our $###m in salaries go in 2024?" I think the right response is something like:

One thing to remember is that where we invested our time isn't necessarily a good proxy for how we allocated our capacity. It is informative, and I can try to get a rough breakdown, but it is not the big picture. Capacity is a multi-faceted thing. It is more than simply the working hours we had available. It is the cumulative amount we invested in our "capacity to" operate in ways that are strategically aligned. Time invested doesn't give us a clear sense of how productive we were when spending that time. Take, for example, [an example of a team that was wading through a fair amount of friction]. Our biggest opportunities at the moment to increase capacity include [some "cheap" opportunities like doing less at once, etc.] along with investing in [a bigger, higher leverage opportunity].

You might also try sharing this video internally. It puts time allocation in context:

Like the newsletter? Support TBM by upgrading your subscription. Get an invite to a Slack group where I answer questions.