TL;DR - Year one of a platform team is a construction project and everybody plans it as one. Year two is a running service and almost nobody re-plans for it, so the team keeps writing year-one quarters into a calendar that no longer has room for them. The denominator changed: maintenance, support and migrations now take somewhere between a third and two thirds of the team’s capacity, and because nobody wrote that down, every quarter ends late and the org’s honest read is that the platform team slowed down. There are two failure modes and they are opposites. One is drowning in a run cost you never budgeted. The other is refusing to admit the build phase is over and inventing a project to justify the headcount. The cure for both is the same: put the run cost in the plan as a number, defend it in public, measure support-per-user rather than support-total, and be willing to say out loud what a smaller version of your team would look like.
I build and run platforms for a living, and I have written a lot about the beginning of this job: what the first ninety days should produce, how to build the first paved road, and what changes when you pave the second and third. What gets written about far less is the year after all that lands, when the roads exist, the adoption curve has flattened into something respectable, and the team wakes up one Monday to discover the job it is doing is not the job it was hired to do.
Nobody announces this transition. There is no reorg, no new mandate, no conversation. The work just quietly changes shape underneath a plan that did not change with it.
The denominator changed and nobody told you
Here is the arithmetic that explains most of the frustration in a second-year platform team.
In year one, your capacity is roughly ninety percent build and ten percent run. You have one road, three services on it, and nobody depends on you enough to interrupt you. Everything you ship is new, everything new is visible, and the quarterly plan is a list of things that did not exist before.
By the middle of year two you have three or four paths, sixty or eighty services, a handful of shared primitives, and a support surface that touches every team in engineering. The run cost - patching, version bumps, answering questions, unbreaking the road, moving people between versions of it - is now somewhere between a third and two thirds of the team’s time. That is not a failure. It is the bill for the thing you claimed you were doing: the entire premise of platform engineering is that the platform is an internal product, and products in production have a run cost that arrives whether or not anyone budgeted for it. It is exactly what you signed up for when you argued the platform should be funded as a product rather than as a project.
The problem is that the plan still looks like year one. Four new capabilities a quarter, written by people who are unconsciously pricing their capacity at last year’s ratio. So the quarter opens with four commitments and closes with two, and it does that four quarters in a row. Inside the team this feels like a mystery: everyone is busy, nobody is idle, nothing shipped. From outside it looks much simpler and much worse. The platform team got slower.
The single most useful thing a second-year platform lead can do is stop treating this as an execution problem. It is an accounting problem. You are reporting against a plan built on a capacity number that has not been true for eight months.
Success is what generates the load
The uncomfortable part is that the run cost is not a symptom of having built badly. It scales with having built well.
A road nobody uses generates no questions. A road forty teams use generates questions in proportion to those forty teams, and the better the road is, the more of the estate ends up on it, and the more of the estate is on it the more of the organisation’s production traffic is your bug surface. When you argued that routing around the road is a product signal rather than a compliance failure, the flip side was implicit and rarely stated: every adoption win you booked in year one arrives in year two as a permanent load.
Which means the goal in year two is not to reduce support. It is to reduce support per user, while the number of users goes up. Those are completely different targets and only one of them is achievable.
Total support volume is not under your control, because adoption is not under your control and you spent last year deliberately increasing it. Support per user is entirely under your control, and it is a product problem rather than a staffing one:
- Every question asked twice is a documentation bug. Every question asked five times is a product bug. The five-time question is not answered with a better wiki page. It is answered by changing the thing so the question stops being possible to ask.
- Error messages are your highest-leverage surface in year two. An error that names the fix, in the place where the failure happened, deflects more tickets than any portal will. This is unglamorous work that nobody puts on a roadmap and it has the best return of anything you will do that year.
- Track the deflection, not the response time. A team measuring median time-to-answer is optimising for being a good help desk. Measure instead how many of this month’s questions could not have occurred last month, and whether the ratio of questions to services on the road is falling.
- A support load that grows linearly with adoption is a design verdict. If forty teams generate exactly twice the questions that twenty did, the road is not self-service yet, and no amount of headcount will fix that. It will just hide it for another year.
If the questions-per-service number is flat or falling while the service count grows, the platform is working. If it is flat and the team is drowning, that is the number to put in front of whoever decides your headcount, because it is the only one that distinguishes “we are under-staffed” from “we shipped something that needs a human attached to it”.
The four things that actually eat year two
When I look at where a second-year team’s time goes, it is consistently these four, and only the first one ever appears in a plan.
- The drift treadmill. Base images get CVEs, pinned dependencies age, your CI provider deprecates the syntax your template generates, the cloud provider retires an instance family. This is the cost every path signs you up for as a maintenance contract, now multiplied by the number of paths and paid every single month. A template untouched for a year is a machine for stamping out year-old mistakes, and the org will not notice you keeping it current until you stop.
- Support and interrupt load. Covered above. The thing to note here is that it is the item most likely to be absorbed invisibly, because it arrives as Slack messages rather than as tickets, and Slack messages do not appear in anybody’s capacity model.
- The migrations you now own. In year one, you had no legacy. In year two, every improvement to a road is a change to services other people own, and the difference between the two years is who pays for the move. If you want the fleet to actually converge, you write the change and you open the pull requests, which means a version bump is a project with a tail. This is the same arithmetic that makes closing an old paved road so much more expensive than opening a new one, applied at smaller scale, many times a year.
- The exception and variant backlog. A year of saying yes to reasonable one-offs leaves you with a forked template for the data team, an unsupported option for the mobile pipeline, a security exception with no expiry, and two services that were always going to be moved onto the road “next quarter”. None of this hurt at the time. All of it is now a standing tax on every change you make. Exceptions were supposed to be first-class artefacts that expire, and year two is where you find out whether you meant it.
The point of enumerating them is not to complain. It is that three of these four are invisible unless somebody chooses to make them visible, and no one outside the team will ever do that on your behalf.
Put the run cost in the plan, in public
The fix is embarrassingly simple and almost nobody does it: allocate the quarter explicitly, in a document other people read.
I use three buckets, and I would defend the shape of this more strongly than the exact numbers:
- Run, around forty percent. Keeping what exists working, current and supported. This is not a contingency and it is not slack. It is the first line in the plan, not the last.
- Evolve, around forty percent. Making the existing roads better for the people already on them. Faster builds, better error messages, one fewer manual step, a rough edge in the template that has annoyed everyone for six months. This bucket produces almost all of your year-two goodwill and almost none of your year-two slides.
- New, around twenty percent. One genuinely new capability per quarter, at most. Not four.
Two things happen when this is written down. The team stops experiencing maintenance as an interruption to the real work, because it is now the plan rather than a deviation from it. And the person who funds you sees the actual shape of the job for the first time, which is the conversation that makes a later headcount request possible.
The ratio is also a diagnostic. If new work is still over half your quarter in year two, one of two things is true: you are quietly deferring maintenance and will pay for it with an incident, or year one built something with far less carrying cost than you thought, in which case you should be asking whether the team is sized for what remains. If run is over seventy percent, you are not a platform team any more. You are operating a platform somebody else designed, and that is a staffing or an architecture conversation, not a prioritisation one.
The other failure: inventing a project to prove you are still needed
Now the failure mode nobody writes about, because it is uncomfortable and it happens to the good teams.
A new platform team feels illegitimate because it has no track record, and the fastest cure for that is building something. A second-year platform team has the opposite problem and reaches for the same cure. The roads work. Adoption is fine. The obvious backlog is done. The quarter ahead contains maintenance, a version bump, some error messages, and nothing you would present at an all-hands. And a team of six senior engineers, all of whom are good at building things, is now sitting in front of a plan with no build in it.
So somebody proposes the rewrite. Or the service mesh. Or the internal framework. Or the second control plane, because the first one has “architectural issues”. Or the portal, which is the classic, because a portal always looks like progress in a screenshot. The proposal is technically defensible, it is genuinely somewhat true, and it will absorb a year.
The tell is the same one from year one, asked slightly differently. Not “who asked for this?” but: which number that we already track is this expected to move, and by when? A year-two project that cannot name a number is a project whose real purpose is to give the team something to build. That is a human need and it deserves an honest answer, but the honest answer is not a twelve-month migration paid for out of other teams’ quarters.
The specific version I see most often is the platform team that decides its own platform needs a platform. An abstraction layer over the abstraction layer, justified by flexibility nobody asked for, built to a standard of engineering the problem does not require. It is the complexity tax charged by the people who are supposed to be collecting it.
The review asks a different question now
In year one, the review question is “what did you build?” and you answer with artefacts. In year two, that same answer starts to sound thin, because the artefacts are the same ones as last time and the org has already priced them in.
The year-two question is what did you make cheaper, and how would we know? Which means your evidence changes shape from artefacts to ratios:
- Time to production, measured the same way as your first-quarter baseline. If you stopwatched it in week one of year one, you have the only comparison that matters, and it is worth re-running with the same method rather than a better one.
- Questions per service on the road, over time. The self-service number, described above.
- Share of new services created on the road without you in the room. The honest adoption metric, and in year two it should be close to all of them.
- The maintenance ratio itself, reported openly. “Sixty percent of our quarter went to keeping ninety services current and answering four hundred questions” is a strong sentence, not a weak one. It is also the only way anyone learns that this cost exists.
- The delivery numbers, still read carefully. Deployment frequency and lead time across the estate, treated as a thermometer rather than a target, because year two is exactly when a flat metric starts to attract a dashboard.
And one number to stop reporting: percentage of the estate migrated. It moves slowly, it flatters you early, and it says nothing about whether anything got better this quarter.
When the team should be smaller
The part that nobody says at conferences: a platform team is a product team, products reach a steady state, and steady state sometimes means fewer people.
If the estate has converged onto two or three paths, the workload classes have not changed in a year, support per service is falling, and the run cost is genuinely stable, then the honest read is that you have built the thing. A team of eight that keeps two roads current and ships one improvement a quarter may well be a team of five. That is not a punishment. It is what finishing looks like, and it is a far better outcome than the alternative, which is five engineers finding a way to look busy for eighteen months until somebody less sympathetic makes the decision for you.
How to do it without destroying the team:
- Move people out, do not lose them. A platform engineer embedded into a stream-aligned team is the single best distribution mechanism you have, and it is closer to enabling-team work than to platform work. They take the road’s assumptions with them and bring back the friction you cannot see from inside.
- Say it before it is said to you. A platform lead who names the conditions under which their team should shrink is trusted with the conditions under which it should grow. One who never names them gets both decisions made externally, usually in a quarter when the budget is bad.
- Do not confuse a quiet quarter with a finished platform. Check the queue, check the interviews, check whether people have simply stopped asking because they gave up. Silence is ambiguous. A postmortem nobody filed is not an absence of incidents, and a support queue nobody uses is not an absence of pain.
When this is the wrong answer
The honest off-ramps, because plenty of second-year teams should ignore most of this.
- Year one did not actually happen. If the roads are not built, you are not in year two, you are in a long year one, and the advice you want is about mandates, baselines and the first paved road rather than about steady state. Calendar time is not phase.
- The company is growing fast enough that the shape keeps resetting. Doubling engineering headcount every year means new workload classes, new scale problems and a genuine build agenda for several years running. In that world a forty percent run budget is over-cautious, and the danger is the opposite one: under-building while the org outgrows the platform.
- You are three people and one road. There is no capacity model here, there is a conversation and a shared calendar. Formalising a run/evolve/new split for a team that fits around one desk is the same category error as running Kubernetes for three services.
- A real platform migration is genuinely due. Sometimes the cloud provider is ending a service, the runtime is going EOL, or the year-one design has hit a wall you can prove with numbers. That is a legitimate build year, and the difference between it and the invented project is that you can state which constraint forces it and what happens on the date you do nothing.
- The team is on fire. If people are being paged nightly and the run cost is not maintenance but firefighting, none of this planning helps yet. Fix the reliability first, ideally with a budget that somebody is allowed to spend, and come back to capacity planning when the pager is quiet.
One guardrail for the other direction: a run budget is not a licence to stop improving. A team that spends four consecutive quarters at eighty percent run and twenty percent evolve, shipping nothing new, has not reached a steady state. It has reached managed decline, and the people it serves will notice roughly two quarters before anyone in the team says it out loud.
The bottom line
The second year is where platform teams stop being a project and start being a service, and the transition is silent. Nothing announces it. The roads keep working, the adoption number keeps looking fine, and the plan keeps being written by people pricing their capacity at a ratio that expired months ago.
So do the boring, unglamorous thing. Work out what fraction of the quarter the run cost actually takes and write it into the plan as a first-class line. Chase support-per-user down while the total goes up, and treat the fifth identical question as a bug in the product rather than a gap in the docs. Report ratios instead of artefacts, because “we made it cheaper” is the year-two claim and it needs evidence. Kill the invented project, even when it is technically the most interesting thing on the table. And be the person who can describe, without flinching, what a smaller version of this team would look like and what would have to be true first.
The question the whole year turns on is not what you shipped. It is this: if the team stopped building anything new tomorrow, how long would it take anyone to notice, and what would they miss first? If the answer is “immediately, the roads would rot”, your run budget is real and it is time to say so. If the answer is “nobody would notice for a year”, that is worth knowing too, and it is far better to know it than to spend that year proving it.
If you are running a platform team that has stopped feeling fast and cannot work out why - or you are staring at a year-two plan that is really a search for something to build - that is exactly the kind of problem I help teams think through. Let’s talk.