Most engineering roadmaps begin with visible product outcomes and then allocate people as though every available day can be converted into feature delivery. The plan looks credible until incidents, support, maintenance, onboarding, security updates and cross-team dependencies consume the capacity that was never acknowledged.
This is often described as unexpected work. Much of it is entirely predictable. The uncertainty lies in timing and volume, not in whether it will exist.
Capacity is not headcount
A team of six does not provide six full-time units of roadmap capacity. People attend planning, reviews, one-to-ones and organisational work. They take leave, support colleagues, respond to production and maintain existing services. Specialists may create constraints that average headcount conceals.
Start with historical evidence. Review how time was actually spent across several months: planned product work, operational support, defects, platform maintenance, discovery and unplanned requests. The objective is not perfect timesheets. It is a realistic range for recurring demand.
Separate demand categories
A useful plan makes four forms of work visible:
- Committed outcomes: product or business results the team is expected to deliver.
- Operational obligations: support, incidents, compliance, security and lifecycle maintenance.
- Enabling investment: testing, delivery tooling, observability and architecture needed to sustain future work.
- Contingency: capacity reserved for uncertainty rather than pre-allocated optimistically.
These categories expose the trade-off when new work appears. Without them, enabling investment silently disappears and operational load is absorbed through overtime or missed commitments.
Plan with ranges
A roadmap should express confidence. Near-term work can carry tighter estimates and clear dependencies. Later work should describe outcomes, assumptions and ranges rather than false precision.
Use scenarios. Show what is likely with normal operational demand, what becomes possible if dependencies arrive early and what will move if incident load or staffing changes. This gives leadership options before the organisation is under pressure.
Protect the constraint
Team capacity is often limited by a particular skill, system owner or approval path. Adding more general work can increase queues around that constraint rather than improve throughput.
Identify where work repeatedly waits. Spread knowledge, simplify ownership or sequence initiatives so the same specialist is not critical to several commitments at once. A roadmap that ignores its constraint is a wish list.
Price interruption honestly
Small requests are not free. Each carries clarification, context switching, testing, release and follow-up cost. Create an intake path and decide which existing commitment changes when urgent work enters.
The phrase "can we squeeze this in?" should trigger a trade-off conversation, not invisible expansion of the plan. Leaders build trust when they explain the consequence clearly rather than accepting everything and missing several dates later.
Track confidence, not only status
Red, amber and green reporting often describes current activity while hiding declining confidence. Ask teams to report whether the outcome remains achievable, what assumption changed and which decision is needed.
An amber item with a clear recovery choice is healthier than a green item protected by optimism. Escalation should be rewarded when it creates time to act.
A roadmap is a resource decision
Planning is not the art of filling every week. It is choosing where limited engineering attention will produce the greatest outcome while preserving the ability to operate safely.
Once hidden work is visible, the roadmap may look smaller. That is not reduced ambition. It is a more honest agreement between engineering and the business, one that allows teams to deliver what they commit to without sacrificing system health or relying on permanent heroics.
No comments:
Post a Comment