Capacity-based workload planning: when does your team actually run out of hours?
Nobody decides to overcommit a team. It happens one reasonable yes at a time: each new project looks affordable against a vague sense of slack, because at the moment of saying yes, nobody can see the sum. The sum only becomes visible weeks later, as its symptoms: everything slightly late, everyone context-switching, the heroics culture that teams mistake for high performance when it is actually just an unpaid capacity debt coming due.
The failure is informational, not moral, and it has a precise shape: commitments are made per-project while capacity is spent per-person. Any system where the ledgers are kept on different axes will drift. Capacity-based workload planning is just the discipline of keeping one ledger, on the person axis, and checking it before every yes.
One pool, many straws#
The mechanics in Topolog are direct. Each person paints their real weekly availability (the painted week): that grid is their capacity, the only hours that exist. Every active plan needs hours from specific people: that is demand, and it is computed from the plans themselves (the dependency-ordered work, the estimates with their spread, loops at their expected lengths), not from a separately maintained resourcing spreadsheet.
The scheduler's job is the allocation: pack every plan's demand into every person's paint, respecting dependencies, and report the result. Three readouts fall out:
Per-person load. Allocated hours against painted hours, per week, per member: the team view renders it as bars. The pattern worth catching is not this week's overload but the structural one: someone allocated 110% indefinitely is not busy, they are the place where several plans' schedules are quietly impossible.
Per-plan risk. When the pool cannot cover every plan, something has to move, and the scheduler shows which plans land where: which are fully resourced, which are starved, and whose dates therefore carry capacity risk on top of their ordinary estimate risk. A plan can be perfectly designed and still doomed by arithmetic happening two plans away; this is the view that catches it. Cross-project visibility is the entire point: no plan can be honestly scheduled alone.
The marginal cost of yes. The question that actually decides things ("if we take this on, what happens to what we already promised?") becomes a what-if edit: add the candidate plan, watch the allocation recompute, and read off exactly which existing commitments move and by how much. "Yes, and the platform migration slips three weeks" is a sentence a leadership team can act on. A vibe about slack is not.
The fictions this replaces#
Capacity planning has a bad name because its traditional implementations track utilisation percentages in a spreadsheet bolted onto reality with good intentions. The failure modes are predictable, and each maps to a fix:
| Fiction | The cost | The correction |
|---|---|---|
| Everyone is 40 hours | All dates optimistic by the real-life ratio | Painted weeks: only painted hours get scheduled |
| Demand equals the estimate | Loops, spread, and rework vanish from the load | Demand from the simulated plan, expected iterations included |
| Parallel bars mean parallel work | One person "doing" three tasks at once | One human is a serial resource; the engine packs accordingly |
| The resourcing sheet | Drifts from the plans within a week | Demand is computed from the plans; there is nothing to maintain |
| Utilisation targets near 100% | Zero slack means every surprise cascades | The spread is visible, so the buffer argument makes itself |
The serial-resource point deserves a highlight because the plan-shape article meets reality here: a beautiful ten-branch fan-out executed by two people is a chain in disguise, and a capacity-aware scheduler is what tells you so before the quarter does.
Small teams need this most#
Capacity tooling is marketed at enterprises, which is backwards. A 200-person organisation overcommitted by one project absorbs it; a five-person team overcommitted by one project loses a quarter, and small teams say yes more often because every opportunity feels existential. The five-person version of this discipline is also drastically simpler: five painted grids, a handful of plans, one allocation view, no PMO required.
The cultural shift is the real product. When capacity is visible and shared, "no" stops being a courage problem. The team is not declining work; the pool is full, the view shows it, and the conversation moves to the real trade-off: which existing commitment is worth displacing. Heroics stop being the default plan and go back to being what they should have been all along: the exception, for the surprises, not the budgeted operating mode.