This essay expands the “resources and capacity” thread from Management Retrospective.
When resources are short, the most common patch is to make a few people work harder: take on more requests, cut back on checks, and handle the leftover issues at night. In the short term it looks like the delivery is protected, but in the long term it disguises a capacity problem as individual performance — until fatigue, complaints, and incidents arrive together.
I myself once treated “hang in there a little longer” as a solution, until a late-night release incident made me realize: what was being overdrawn was not anyone’s will, but a gap in the capacity system. What follows are principles, not aimed at any particular team.
Capacity Planning First Helps Three Parties Reach Consensus
“How many people does this team need” looks like a headcount question, but it is really a question of effectiveness and delivery expectations. No one can answer it with a ratio alone: with the same ten people, different project commitments, skill mixes, dependency complexity, and existing risks produce completely different real capacity.
The purpose of capacity planning is to help three parties reach consensus: what the team can deliver steadily right now; what must be dropped to add a new commitment; and under what conditions risk exceeds the acceptable range. It is not a defense of the current headcount, nor a way to repackage unreasonable goals as a resource request.
First Draw the Real Capacity
Capacity is not headcount times working days; you must also subtract maintenance, support, communication, learning, unexpected problems, and necessary buffer. When taking stock, list at least people, available resources, and project commitments: how much capacity is consumed by operations and maintenance, online support, long-term projects, collaboration, and hiring; whether key work is held by single points of contact; and which dependencies the team cannot control itself.
Each cycle, list three kinds of commitments: operations and risk items that must be protected, confirmed deliveries, and explorations that can be adjusted with resources. If the third category gets squeezed out, don’t pretend it will still happen; if the first two already exceed capacity, escalate early.
Break Complaints Back Down Into Concrete Events
“The partner is unhappy” is not an actionable conclusion. First ask: in which project, at which handoff, and what expectation was not met? Was it an actual delay, a quality defect, or distrust caused by how a communication was handled? Does the problem point at the matter, or has it been enlarged into a judgment about people?
For example, a certain support team was always said to be “slow to respond.” After a week of recording, they found that most requests were not slow to handle — they lacked necessary information when submitted, and back-and-forth clarification took up half the time. At that point the entry and triage rules should be changed, rather than demanding that the people on duty reply faster. Complaints are often system alarms, not people not trying hard enough.
Make Capacity Boundaries Public, and Let Choices Align Upward
The team should be able to state clearly: what current capacity can guarantee and what it cannot; if a new commitment is added, what must be paused or postponed; and which risks are being temporarily accepted. This process is uncomfortable, but more honest than silently overdrawing.
Priority is not marking every task as high priority, but making each “yes” correspond to a clear “no.” When resources are short and multiple directions conflict, the frontline team should not make promises on its own; it needs to escalate and align upward: let the people with more resources and higher decision-making authority choose, over the same set of facts, whether to add resources, cut scope, extend time, or change the goal. The real value capacity planning creates is that these choices are no longer silently carried by the people closest to the pressure.
Give risks names. Don’t just say “it may be delayed”; instead, explain that a dependency interface is unsettled, that critical knowledge rests with a single person, that the testing window is insufficient, or that the plan cannot be rolled back quickly — and attach an owner, trigger signals, and response options. Once a risk is named, partners can take part in the trade-off.
Don’t Treat People as a Buffer
Short sprints can exist, but they must have a clear end point, compensation, and a retrospective. If a team routinely relies on overtime, heroic firefighting, and ad-hoc coordination, what usually needs fixing is the commitment mechanism, the process entry point, or resource allocation.
A manager’s responsibility is not to guarantee that no one is disappointed, but to make the costs visible and the choices clear when resources are limited, and to protect the team from mistaking the unsustainable for dedication.
A complaint can be an expression of emotion or a system alarm. The former should be heard with respect, and the latter should be fixed concretely; neither should become a label on people. Only by openly reviewing commitments, results, and the points that should surface earlier next time will capacity problems stop being made personal.