On this page
If your platform team is producing roadmaps, something is wrong.
This will sound provocative, because every engineering function in your organisation is expected to produce a roadmap. The product teams have them. The application engineering teams have them. The board reviews them. The CTO presents them. Roadmaps are the lingua franca of engineering planning.
But platform engineering, done well, doesn’t fit the roadmap shape. When you force it to, you produce the wrong behaviour in the team, the wrong expectations in the rest of the organisation, and the wrong outcomes overall.
Most platform teams that look like they are under-performing are not under-performing. They are being evaluated against the wrong artefact.
The Roadmap Reflex
When a new platform team is set up, or when a new engineering leader takes over an existing one, there is a near-universal reflex: ask for a roadmap.
This is not unreasonable. The leader needs to plan, the board needs to understand the investment, and the rest of engineering needs to know what is coming. A roadmap appears to provide all three.
So the platform team produces one. They pick four or five initiatives. They commit them to quarters. They put the artefact in front of the leadership team. Everyone agrees this is a sensible plan. The work begins.
Six months later, the roadmap is half-correct at best. Two of the initiatives have shifted because operational reality intervened. One has expanded because an unexpected dependency was discovered. One has been deprioritised because a higher-leverage opportunity emerged. The team is producing real value, but they are visibly off-plan, and the conversation with leadership becomes defensive.
This is not a failure of execution. It is a failure of artefact choice.
What Roadmaps Implicitly Promise
The reason roadmaps don’t fit platform work is that they encode a set of assumptions that are reasonable for product engineering and unreasonable for platform engineering:
- That the scope of work can be predicted in advance. Product teams can usually predict what they will build because the inputs - customer demand, market positioning, feature scope - are relatively stable. Platform teams cannot, because their inputs include operational incidents, infrastructure decay, dependency changes, and shifts in how the rest of engineering wants to work.
- That the value of work is in shipping a specific thing. Product teams ship features that produce value when they reach customers. Platform teams produce value continuously through the operation of a service that other engineers depend on. The value is not in shipping; it is in the ongoing quality of what already exists.
- That priority is set quarterly. Product teams can reasonably batch decisions into quarterly planning. Platform teams have to respond to events that don’t fit quarterly cadence - upgrade lifecycles, vendor changes, security incidents, the emergence of a new pattern that should be standardised before it sprawls.
When you commit a platform team to a roadmap, you are implicitly telling them that none of these properties of their work matter. You are asking them to operate as a project team instead.
Some platform teams resist this and produce work that doesn’t match the roadmap. The leadership conversation becomes about variance. Other platform teams comply with the roadmap and produce work that matches the plan but ignores the operational reality. The leadership conversation becomes about why the rest of engineering is still complaining.
Neither outcome is good.
What Platform Teams Should Produce Instead
Platform teams that operate well produce a different set of artefacts. They are not as legible as roadmaps, but they are more honest about what platform engineering actually is.
A strategy
The platform team should have a clear, written strategy: what the platform is for, who it serves, what shape it is trying to take over the next year, and what it has explicitly decided not to invest in.
The strategy is stable over twelve to eighteen months. It is the document that says “we are building toward a self-service deployment model with three supported patterns” rather than “in Q2 we will ship the self-service deployment system.” The first survives operational reality. The second does not.
A good platform strategy has four properties:
- It is specific enough to use as a decision-making tool (“does this proposed work move us toward the strategy?”).
- It is honest about trade-offs (“we are not investing in X because we are investing in Y”).
- It includes a clear statement of who the platform’s users are and what they need.
- It is reviewed and updated annually, not quarterly.
A prioritised backlog
The team should maintain a backlog of work, ranked by priority, with the priorities driven by a combination of user demand and operational reality. The backlog is the working artefact that says “here is what we will do next.”
Crucially, the backlog is not a roadmap. It does not commit work to specific dates. It expresses an ordered set of priorities that the team is currently working through, and that priorities will shift based on what is learned.
This is uncomfortable for stakeholders used to roadmaps. The right response is to explain that the platform team is committing to outcomes, not to a delivery schedule.
Outcome commitments
What the platform team should commit to is outcomes. Specific, measurable, and visible. Things like:
- “Developers can provision a new service end-to-end in under one hour.”
- “Production deployments succeed without platform team involvement in 95% of cases.”
- “Infrastructure cost per engineer reduces by 15% over the year.”
- “Platform-related incident time reduces by 30% year-over-year.”
These are the things the platform team should be evaluated on. They are durable, they survive operational reality, and they communicate what the work is actually for.
A platform team operating against outcome commitments will sometimes ship things that weren’t planned, deprioritise things that were, and respond to events the original plan didn’t anticipate. That is the correct behaviour. The outcome commitments make the work legible without forcing the artefact into a project shape.
Visible operating state
The fourth artefact is an honest, visible view of the operating state of the platform. Not a status report; a continuously updated view that the rest of the organisation can see.
This includes things like cluster upgrade status, the team’s current capacity allocation, recurring incident causes, and ongoing migrations. It exists so that stakeholders can understand why priorities shift, without needing the team to produce a presentation each time.
The visible operating state is what replaces the comfort that roadmaps provide. It does not promise the future, but it makes the present and recent past legible.
What Changes When You Stop Asking for a Roadmap
When a platform team stops being evaluated against a roadmap and starts being evaluated against a strategy and a set of outcome commitments, three things change:
- The team’s incentives align with sustained outcomes rather than scheduled delivery. They start making trade-offs based on what their users need, rather than what was committed in advance.
- The conversation with leadership shifts from variance to value. Instead of “why are you behind on Q2?” the conversation becomes “are the outcomes still the right ones?”.
- The team’s capacity for response improves. They can react to incidents, opportunities, and emerging patterns without breaking the plan, because the plan was never the artefact.
This is also harder to sell up the chain. Boards want roadmaps. Stakeholders want roadmaps. The pressure to produce one is constant, even when it is the wrong artefact.
The engineering leader’s job is to hold that line. The strategy, the backlog, and the outcome commitments are the artefacts. The roadmap is not.
The Caveat
This is not an argument against planning. Platform teams should plan. They should know what they are building, why, and for whom. They should communicate that clearly to the rest of the organisation.
The argument is against the specific artefact - the time-bound, Gantt-style roadmap - that encodes assumptions about platform work that do not match how it actually unfolds. Replace the artefact, and the team’s behaviour changes accordingly.
There are also occasional pieces of platform work that genuinely fit the project model: a large migration, a major upgrade, a defined replatforming. For these, a project plan is the right artefact. The mistake is treating all platform work as projects when most of it isn’t.
The Takeaway
The roadmap is the default planning artefact in engineering organisations because it works well for product teams. Platform teams are not product teams in that sense - they are operating an ongoing product that serves internal users, and their work doesn’t fit the project shape.
If you are an engineering leader and your platform team is consistently presenting roadmaps that don’t match what they actually do, the problem is probably not the team. It is the artefact you are asking them to produce.
Stop asking for a roadmap. Ask for a strategy, a prioritised backlog, and a small set of outcome commitments. Then evaluate the team against those.
The conversation gets harder before it gets easier, because the rest of the organisation is used to roadmaps. But the work the team produces gets better, and the relationship between leadership and the platform function gets more honest.
If your platform team is producing roadmaps and the conversation around them isn’t quite working, we can help you rethink the operating model.