Year one of a platform gets a budget, a roadmap, and a launch deck. Year two gets the support queue, the upgrade backlog, and the first awkward realisation that the golden path you shipped six months ago is already drifting away from the estate it was meant to simplify. That is the part nobody budgets for properly: a platform is a product, so shipping it once is the same mistake as shipping any product once.
This is also why so many internal platforms feel promising in the demo and frustrating a year later. The visible work in year one is building: templates, guardrails, self-service workflows, maybe a portal, maybe a paved road people can actually use. The invisible work in year two is keeping the thing alive while the world underneath it keeps moving: Kubernetes releases, Helm chart churn, identity changes, cloud policy updates, framework upgrades, and the steady trickle of support requests from teams whose use case never quite fit the happy path.
Platform engineering does not usually fail because the idea was wrong. It stalls because teams fund the build and underfund the maintenance.
The launch was the easy part
There is a familiar shape to the first year of a platform effort.
A team gets a mandate to improve developer experience, standardise delivery, or reduce ticket-driven toil. It has executive attention. It has a date to hit. It has a story people can understand: we are building the internal platform.
That phase is real work, but it has one advantage: the scope looks finite. You can imagine a first version. You can plan the launch. You can decide what the thinnest viable platform looks like and cut everything else.
Year two is harder because the work stops looking like a project and starts looking like ownership.
Now you are carrying things like:
- patching and upgrading the platform's own dependencies
- repaving templates and starter repos as upstream defaults change
- deciding which one-off exceptions should become product features
- pruning workflows nobody uses before they become permanent support burdens
- proving that adoption is still growing, rather than assuming it is
None of that produces the same tidy before-and-after slide as the original launch. It is still the work that determines whether the platform becomes part of how the organisation ships software or just another ambitious internal system people route around.
That is why Team Topologies keeps insisting on platform as a product rather than platform as a shared tools pile. The point is not that platforms need prettier language. The point is that products have ongoing discovery, maintenance, and evolution. A platform that is not continuously evolved is just a frozen opinion about how engineering used to work.
Most of the field is only just getting to year two
One reason there is so little useful day-two writing is that the discipline itself is still young.
The 2024 State of Platform Engineering report from Humanitec and Gitpod, based on a vendor-sponsored survey of platform teams, found that 56% of respondent teams were less than two years old, and only 13% had been doing platform engineering for more than five years. That is enough to explain why there is still so little hard-won writing about the maintenance phase: a lot of the field is only just arriving there.
In other words, there is not a deep institutional playbook here. There are patterns. There are good principles. There is some solid research. But there is also a lot of collective improvisation.
That matters because year-two problems do not look like year-one problems.
The first year asks whether you can build a paved road. The second asks whether you can keep repaving it while traffic is already on it.
The first year asks whether you can make self-service possible. The second asks whether the self-service path still fits the organisation as it changes.
The first year asks whether the platform team can ship. The second asks whether it can avoid becoming the bottleneck it was created to remove.
Golden paths do not stay golden by themselves
A platform's main promise is usually straightforward: give teams a safer, faster default path than stitching everything together from scratch.
That is a good promise. It is also one with a permanent maintenance bill attached.
The paved road starts decaying the moment upstream moves. A base chart changes shape. A cluster policy tightens. A framework introduces a new recommended default. A cloud provider deprecates some corner of the identity model you buried in a template months ago. A service team needs one capability the platform path did not anticipate, so it forks the template "just for now" and never really comes back.
This is where platform credibility leaks away quietly. Not in one dramatic outage, but in a long series of tiny moments where engineers learn that the official path is slightly stale, slightly rigid, or slightly behind the reality of the stack. Once that happens often enough, people stop asking whether they should use the platform and start assuming they will need to work around it.
That is also why the advice in Stop copying big-tech platform architecture: right-size to your scale matters even more in year two than in year one. Over-built platform machinery does not just cost more to launch. It costs more to keep current. Every extra control plane, abstraction layer, and bespoke workflow becomes another thing that needs tending after the excitement has worn off.
A golden path without a gardener is just a future migration project.
The upgrade treadmill is not a side quest
If you want one brutally practical example of year-two reality, use Kubernetes itself.
Kubernetes now ships three minor releases a year, and the project maintains patch support for only the most recent three minor versions. Under the yearly support policy that works out to roughly a 14-month window per release: twelve months of standard patches, then two months of maintenance mode before end of life. If your platform sits on Kubernetes, the upgrade tax is not occasional. It is structural. You are budgeting for two to three cluster upgrades a year, forever, before you even count the other components attached to the platform.
And of course it is never just Kubernetes.
There is ingress or Gateway API, cert management, policy tooling, observability agents, CI runners, secret syncing, identity plumbing, image build tooling, and whatever home-grown wrappers your platform created around those things to make them usable. One upstream change can ripple through templates, documentation, tests, and support expectations all at once.
Teams often talk about this as if it were operational overhead adjacent to the roadmap. It is not. For a platform team, the upgrade treadmill is part of the roadmap. If you do not plan for it explicitly, it eats the roadmap anyway.
This is the part that breaks year-two planning. A team thinks it has funded one staff engineer to "keep the lights on" while everyone else moves on to the next strategic thing. Then the calendar turns, the supported version window narrows, and suddenly the strategic thing is an upgrade programme whether anyone likes it or not.
Adoption stalls when nobody is listening
There is a second year-two trap that looks softer but is just as destructive: the team assumes that shipping the platform was the same thing as winning adoption.
It is not.
DORA's 2024 Accelerate State of DevOps report is useful here because it is more honest than most of the hype. It found that internal platforms were associated with better individual productivity and team performance, but also with weaker throughput and change stability where the implementation added complexity or reduced developer independence. DORA describes this as a J-curve: you can see early gains, then hit a dip, and only recover if the platform matures in a user-centred way.
That finding lands because it matches what many teams feel in practice. A platform can absolutely remove toil. It can also create a new layer of process, abstraction, and waiting if the product discipline is weak.
The warning signs are usually familiar:
- teams need tickets for routine changes the platform was meant to self-serve
- exceptions pile up because the happy path is too narrow
- the platform roadmap is driven by internal architecture debates rather than user pain
- the team measures launches and features, but not adoption or abandonment
This is why Team Topologies talks about sensing user needs rather than just building services for them. The thinnest viable platform is only a starting point. If you stop there, the platform freezes while the organisation keeps changing around it.
Puppet's 2024 State of DevOps report makes the same point from a different angle: 52% of respondents said a product manager was crucial to a platform team's success, with a further 21% calling one nice to have. That is not a plea to add ceremony. It is a recognition that somebody needs to own adoption, prioritisation, and the discipline of learning what the users of the platform actually need next.
Without that function, year two becomes a familiar kind of drift. The platform team keeps shipping things. The users keep needing different things. Everyone is technically busy, and the gap still widens.
This is how the platform team becomes the bottleneck again
Platform engineering is often sold as the way out of ticket Ops. Build the paved road, standardise the sharp edges, push routine work into self-service, and let product teams move without waiting for a central platform group.
That is the right goal. But an under-staffed year-two platform team can relapse into the exact behaviour it was supposed to replace.
You see it when every unusual request becomes a handoff. You see it when upgrades consume so much attention that user-facing platform work slips for a quarter. You see it when the team starts protecting itself with queues and process because it no longer has the slack to evolve the underlying system.
At that point the platform still exists, but the interaction model has changed. The platform is no longer a capability. It is a department.
And yes, that sounds harsh. It is still a useful test. If the main experience of the platform for most engineers is waiting for another team, something important has gone wrong even if the underlying architecture is perfectly respectable.
What year-two funding actually looks like
If the first-year mistake is treating the platform like a one-off delivery project, the year-two fix is not mysterious. It is just less glamorous than the original launch.
A serious year-two platform budget needs to fund four things explicitly:
- maintenance as first-class work: upgrades, repaving, dependency churn, template hygiene, and pruning stale paths
- product management: somebody accountable for adoption, prioritisation, and the sensing loop with platform users
- operational slack: enough capacity that support and upgrades do not consume every sprint
- evidence: metrics for adoption, developer independence, and the support burden the platform is actually removing
That last point matters because year-two platform conversations often become strangely qualitative. People can tell that the platform feels helpful or painful, but the organisation stops short of measuring the signs that matter.
A better year-two review asks questions like:
- how many teams are still on the paved path versus a forked one?
- which support requests repeat often enough to deserve product work?
- how old are the core templates and platform dependencies?
- where does a platform user still need a human instead of self-service?
- did the last upgrade consume planned capacity, or did it blow up the quarter?
Those are product questions as much as technical ones. Which is the point.
The real work starts after the applause
Platform engineering year two is where the discipline becomes real. The launch matters, but the launch is only the opening move. After that comes the unglamorous part: keeping the path current, paying the upgrade tax, listening hard enough to notice when adoption is flattening, and funding the platform team as owners of a product rather than custodians of a project.
If you get that part right, the J-curve recovers and the platform becomes genuinely compounding infrastructure for the organisation. If you get it wrong, the platform slowly turns back into the queue it was meant to remove.
Nobody warns you about year two because year one is easier to tell as a story. Year two is mostly maintenance, judgement, and sustained ownership. It is also the part that decides whether the platform was ever really a platform at all.
Top comments (0)