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.
Capacity in software relies heavily on intangible assets like shared context. While different from manufacturing in many ways, the foundational principles are the same.
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.
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. Teams must monitor and respond to feedback in tighter loops.
Teams build and maintain the factory while operating it. They maintain and upgrade what they 'ship' for long periods of time.
Capacity is the result of countless investments and decisions, and its future theoretical capacity is a mix of expected constraints, market dynamics, and economics.
Where you invest your time and energy can be a helpful data point, but it is only part of the bigger picture.
An executive asking where did our money go this year 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?'
Oversimplified time allocations aren't the path to figuring out if it's economically viable. Time is a small piece of the picture.