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:
Hiring, onboarding, training, developing, and retaining employees
Developing high-performing teams with trust and psychological safety
The current organizational structure, reporting lines, etc.
Insights about the market, customers, partners, competitors, the codebase
Building "the product" and everything learned while building the product
Working (or not working) down technical debt
Tools, systems, and infrastructure to enable teams
Partnerships, brand equity, and customer relationships/goodwill
Taming bureaucracy, waste, friction, perverse incentives, etc.
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:
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.
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:
Teams frequently tackle new, novel problems.
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).
Teams build and maintain the factory while operating it
They maintain and upgrade what they "ship" for long periods of time.
Teams must monitor and respond to feedback in tighter loops.
The tool and technology landscape changes rapidly
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.
Excellent post John! Two observations on it:
- I agree that how individuals are passing their time is not the focus leadership should have, but it is still a very important metrics to diagnose the team bottlenecks. For example, finding that 5-10% of dev time is in filling timesheets is likely a sign that the time reporting tool is inadequate or that the team is putting way too much details in it (even at team level, you shouldn't need more than half-hour precision, and I would even go with half-day).
- for a long time, I found the notion of maturity of a team to be inadequate, and this capacity talk seems to point to something similar. Maturity models are often use as a way to identify the next step to improve a team "productivity" (vaguely defined as the capacity of a team to deliver good value across time) and my main objection on the term is that maturity is always expected to grow and immaturity is a very pejorative terms with childish connotations (never treat your employees as children, even metaphorically). I taught that Capacity Model would have been a good replacement, but a quick search shown that the term have been reduced to the staff allocation you mentioned. What term would you suggest to extend the scope to what you have identified?
I find this topic fascinating. I had responsibility for a product delivery function and we had timesheets which allowed everyone to capture how they spent their time in great detail. What we observed (me and finance) was that this was (a) expensive and (b) wrong. From an accounting perspective we were able to justify a management judgement of where time was spent as more accurate that self-reported, highly detailed timesheets.
We then set and objective of eliminating timesheets, which was welcomed by pretty much everyone. We moved to a model where team leads and project managers were responsible for forecasting expected allocation at an initiative level - initiative being something an exec might recognise. There was a monthly process run by finance to get managers to review their forecast at month end and adjust based on what happened.
We absolutely did not have the level of detail that you describe, but my question is who does that serve? You rightly propose nuanced commentary alongside any model of how capacity was allocated. Any exec is likely to follow the question “where did we spend our time?” with “why was that so expensive?” Or “what do all those managers do?”, which is where all the factors you list come in.
Keep up the great work and thank you for sharing your experience and insight.