Engineering leadership · Capacity planning · Product delivery
How much engineering capacity is actually available for the roadmap?
Build the delivery plan around required skills, existing obligations and the work that coordinates the team. Check capacity at the constrained role and reconcile the roadmap with realistic staffing dates.
Translate the roadmap into demands on specific skills
List the capabilities each planned outcome requires: customer research, interaction design, application development, specialist modeling, infrastructure or release support. Identify when each capability is needed and what another role is waiting for. The relevant planning unit is the work a team can complete with its available skills.
Map current commitments onto the same view. Include incident response, maintenance, security changes, customer escalations and review work. GitLab's engineering handbook includes technical debt and improvement work in its roadmap planning alongside feature development. Use that example to make these demands visible when discussing what the team can take on.
Use recent work records to estimate a range for recurring demand. Keep unusual incidents visible without treating every exceptional week as normal. Ask the people performing the work to identify obligations missing from the plan and distinguish scheduled availability from time that has already been committed elsewhere.
Examine the queue around the constrained role
A team can have open time while important work waits for one specialist, reviewer or environment. Inspect where tasks accumulate and what would allow them to move. Adding another feature to someone's active list does not resolve a missing dependency or make the review arrive sooner.
DORA's work-in-process guidance recommends making the whole delivery flow visible and accounting for support, meetings and technical debt when setting limits. Use that guidance to discuss which work should finish before more begins. Choose limits from the team's circumstances rather than copying another organization's allocation ratio.
Reserve explicit capacity for improvements that reduce recurring effort, with a defined problem and an observable completion condition. Check whether the change frees the constrained role or merely shifts work to another team. Preserve time for necessary operations while making the tradeoff with new product work understandable.
Make staffing assumptions earn their place in the plan
Reconcile the roadmap with the staffing plan by role and date. A proposed hire has a different availability assumption from a person already doing the work. Include recruiting, onboarding, access and the experienced team members' time needed to help someone become effective on the relevant system.
Apply the same check to contractors and partner teams. Specify what work they own, who reviews it and how operating knowledge stays available afterward. Include coordination and management demands in the receiving team's capacity instead of treating external delivery as requiring no internal attention.
Review planned and completed work together, including interruptions and blocked time. When capacity falls short, choose a concrete response: reduce concurrent scope, change the sequence, remove a dependency or add the missing capability. Update affected dates and assumptions together so the roadmap remains a usable agreement.