Capacity planning before adding more developers

Developer capacity planning should identify where work waits before deciding how many people to add. More implementation capacity helps when ready work lacks an owner. It can make the queue worse when completed changes already wait for one reviewer, a product decision, or a release window.

Start with the work in progress, not the annual headcount target. The most useful evidence is often in the timestamps and blocker notes of a few recent tickets.

Separate effort from waiting

Follow representative items through clarification, implementation, review, verification, and release. Record active effort separately from elapsed time. A ticket open for a week may contain little implementation and several days waiting for an answer.

Google’s engineering guidance on review speed explains how slow reviews affect team progress. For capacity planning, the practical implication is to count reviewer availability as a constraint rather than assume that every extra developer creates proportional delivery capacity.

Check whether the same person owns architecture decisions, approvals, and incident response. A calendar full of those responsibilities cannot also provide unlimited onboarding and review support.

Build a capacity ledger with explicit assumptions

Use hours or comparable work units that your team understands. Do not convert story points from another team into capacity. Keep a separate line for uncertainty instead of hiding it inside a confident delivery date.

Include these demands before assigning new roadmap work:

• Planned implementation and verification.
• Reviews and integration work for other contributors.
• Operational support and recurring maintenance.
• Known leave and unavailable working periods.
• Onboarding effort from both the new person and existing staff.
• A reserve chosen from the team’s actual interruption history.

If interruption history is unavailable, say that the reserve is an assumption and revise it after observing the work. A staffing request should not depend on pretending every nominal hour is available for features.

Worked hypothetical: the missing reviewer

Consider a hypothetical planning period with 160 engineering hours available. Assume support needs 32 hours, planned reviews need 24, and onboarding requires 16 hours from existing staff. That leaves 88 hours before accounting for new feature implementation. These numbers are illustrative, not 5e Labs results or recommended allocations.

Suppose the ready backlog requires 120 implementation hours. Adding an engineer appears to close the 32-hour gap. But their changes also need review, and the only qualified reviewer is already fully allocated.

The team can narrow the incoming engineer’s first scope, train a second reviewer, or reduce other commitments. Without one of those decisions, the added person may simply create more finished branches waiting for approval.

The arithmetic does not predict delivery. It exposes an assumption that the plan otherwise conceals.

Choose a staffing trigger you can inspect

Add a developer when there is ready, separable work, an accountable product owner, and enough review and release support. Add specialist capacity when a specific layer is the constraint. Fix decision ownership when tickets cannot become ready in the first place.

Set a review point after the incoming person has completed a representative change. Compare where work waits now with where it waited before. Avoid judging the arrangement solely by utilization or tickets started.

Map the next planning period’s ready work and its reviewer before discussing developer staff augmentation. That map should explain what the added person will finish and who can help it reach release.