The roadmap is accurate when it is published.
Then a customer threatens to churn. A dependency slips. A competitor ships something awkwardly similar. A production incident takes three engineers for a week. An executive asks for a new initiative to be treated as urgent. A senior engineer leaves. The team still has the roadmap. The organization has moved.
Roadmaps drift because they freeze intent while execution happens inside changing constraints.
The drift is often blamed on discipline. Teams did not stick to the plan. Product changed its mind. Engineering estimated badly. Stakeholders interfered. Some of that may be true. The deeper issue is that most roadmaps model what the organization wants to happen, not the forces that decide what actually gets capacity.
Intent Is Cleaner Than Capacity
A roadmap shows features, milestones, themes, and releases. It rarely shows approval queues, interrupt load, shared-resource constraints, executive override rights, production support burden, or the probability that a dependency team will be pulled elsewhere.
The plan assumes usable capacity. Execution reveals contested capacity.
Engineers take leave, incidents happen, hiring slips, onboarding consumes senior time, customer escalations create unplanned commitments, and technical debt turns a small feature into system work. The roadmap may still show the original allocation because capacity changes are harder to communicate than feature dates.
By the time the shortfall is visible, the roadmap is already behind.
Priorities Keep Negotiating After Planning
Planning feels like a moment when priorities are set.
Execution is a period where priorities keep negotiating.
Sales brings a deal. Support brings a customer issue. Security brings a risk. Leadership brings a new market signal. Engineering brings a constraint discovered in the code. Each input can be legitimate. Each can change what should happen next.
The roadmap drifts because it records the outcome of one negotiation and assumes the negotiation has ended.
Organizations with stable roadmaps protect the plan. Interruptions have a cost. Overrides require authority. Trade-offs are explicit. Without that protection, the roadmap becomes a polite suggestion underneath the live priority system.
Dependencies Are Discovered by Work
A feature appears independent during planning.
Implementation discovers authentication changes. Authentication exposes a session-service scaling issue. The scaling issue requires a migration. The migration affects three teams and a compliance report. The roadmap did not show the chain because the chain did not become visible until work touched the system.
More planning can help, up to a point. Dependency mapping, architecture review, and pre-planning can surface known coupling. They cannot fully reveal emergent complexity in systems that keep changing.
Treating dependencies as facts makes roadmaps brittle. Treating them as risks makes roadmaps more honest.
Velocity Is a Property of the Work
Teams do not have one velocity.
They move quickly through isolated work in familiar parts of the system. They slow down when the work crosses teams, touches fragile architecture, depends on unclear requirements, or requires production migration. The same team can look fast one quarter and slow the next because the work changed.
Roadmaps often project past velocity onto future work as if throughput were a stable team trait. It is more often an interaction between team, system, scope, coordination cost, and interrupt load.
When the next quarter contains harder interfaces than the last quarter, the roadmap drifts even if the team executes well.
Decision Rights Decide What Ships
A roadmap is an artifact produced by authority, not a source of authority.
If an executive can pull people onto a fire drill, the roadmap does not control that capacity. If a large customer can force a commitment, the roadmap is downstream of sales escalation. If architecture review can block a feature, the roadmap cannot promise the date alone.
Roadmaps drift when the people who make the plan differ from the people who can override it during execution.
A more honest roadmap shows what is planned, who can change the plan, and under what conditions. Without that, the document describes intent and hides power.
Roadmaps Persist Because They Still Help
A drifting roadmap can still be useful.
The planning process surfaces assumptions, exposes conflicts, and gives teams a shared object to react to. It helps stakeholders see what is being attempted and what might collide. It forces dependencies into the open earlier than pure improvisation would.
The mistake is treating the roadmap as a contract.
When drift is treated as failure, teams defend dates and hide uncertainty. When drift is treated as signal, the roadmap becomes a way to communicate what reality is doing to the plan.
The useful roadmap is maintained as an interface between planning and execution, not as proof that planning defeated uncertainty.
How to Reduce Drift
Map real capacity. Track interrupts separately from roadmap work. If incidents, escalations, and support consume twenty percent of engineering time, the plan should start from eighty percent.
Make override rights explicit. If a stakeholder can derail the roadmap, they belong in the governance model. If they cannot, the organization needs to enforce that boundary.
Show dependency risk. A dependency on another team should carry a contingency: what happens if it slips, who decides, and what scope changes first.
Update continuously enough that the roadmap is never completely fictional. Quarterly planning with no adjustment mechanism creates a long gap between published intent and operating truth.
Most of all, stop treating drift as a moral failure. A roadmap that never drifts is either trivial or disconnected from the world. The aim is drift that becomes visible early enough to make decisions, rather than late enough to become blame.
