Capacity allocation is about a team's true ability to deliver, not just counting hours. Mixing it with time allocation wastes money; separating the two lets leaders discuss real impact.
Capacity allocation is not a simple tally of hours. The piece argues that treating capacity as a raw time bucket blinds leaders to the deeper system factors that actually enable delivery. When leaders ask "where did we allocate capacity?" they need to look beyond hours and consider the energy of people, tooling, codebase health, and past investments.
The author contrasts the "time-as-capacity" mental model-five people, 40 hours each, 200 hours to split-with a lean-manufacturing view where capacity is the potential output of a system shaped by constraints, maintenance, changeovers, and equipment availability. Effective capacity emerges only after accounting for those real-world frictions, and the same principle applies to software teams.
Concrete examples illustrate the gap. Irene was slated for 80% project work on paper, but pipeline delays, confusing code, and constant interruptions ate most of her theoretical hours. Another pair of teams with identical headcount showed wildly different outcomes because one invested in stable tooling and documentation while the other did not. These stories show that time sheets hide the true cost of inefficiencies.
The solution is to decouple the language: use "time allocation" for accounting purposes and "capacity allocation" for strategic discussions about what the team can actually deliver. By being explicit about the distinction, leaders can have honest conversations about impact, efficiency, and productivity without the noise of mis-labelled hours.
Check out the full stdlib collection for more frameworks, templates, and guides to accelerate your technical leadership journey.