TL;DR - A new platform team’s first ninety days almost never fail on technology. They fail because the team, feeling illegitimate, reaches for the fastest available cure and builds something. Ninety days later there is infrastructure, a demo, a roadmap, and no customer, no evidence, and no answer to the only question that will be asked in month nine: what did we get for this? The first quarter has four deliverables and none of them is a platform. A mandate in writing, including what you will refuse. The baseline numbers you can only measure before you have touched anything. The inherited ticket queue read as a requirements document rather than a burden. And one small, painful, unglamorous thing fixed by week six, to buy the credibility that funds the rest. Build path one in the second ninety days, on evidence, with a named partner.
I have been the first hire on a platform team, and I have been brought in to work out why one was about to be quietly dissolved. Those two conversations are usually about a year apart, and what separates them happened almost entirely in the first ninety days. Not the architecture. Not the tool choices. The first ninety days.
Nobody hands a new platform team a definition of done for its first quarter, so the team invents one, and the one it invents is almost always “ship something impressive”. That instinct is completely understandable and it is the single most reliable way to waste the only quarter in which you have the organisation’s patience and none of its expectations.
The clock you are actually on
Here is the thing nobody says out loud when the team is announced: a platform team is funded on faith and reviewed on evidence, and the review date is not on any calendar you can see.
Somewhere between month four and month nine there will be a budget conversation, a reorg, a new VP, or a bad quarter, and someone will ask what the platform team has produced. The question is not hostile. It is the normal question. But it lands badly on platform work specifically, because platform engineering produces second-order results by design. You make other teams faster. Your output shows up in somebody else’s numbers, attributed to them, several months late. That is the job working correctly, and it is also a terrible position from which to defend a headcount.
Which means the strategic goal of the first ninety days is not output. It is to arrive at that conversation with a boundary you agreed in advance, numbers from before you started, one story a developer will tell on your behalf, and a specific proposal for the next quarter. Everything below is in service of that.
The founding mistake: building something to prove you exist
A brand new team feels illegitimate. There is no track record, no catalogue, nothing anyone consumes, and a whole quarter of empty calendar. The fastest available cure for feeling illegitimate is a demo, and infrastructure is a demo you can build without asking anyone’s permission.
So the team stands up the Kubernetes cluster it always wanted. Or it installs Backstage, because a portal looks like a platform in a screenshot. Or it starts the migration that everyone agrees is technically correct. Ninety days later there is real, working, competent engineering to show, and the sentence that kills you at the review is the one you cannot answer: who asked for this?
The tell is simple. If you can describe what you built in detail and cannot name the team that was waiting for it, you have built for yourself. This is exactly the sequence trap I have written about with developer portals, which are earned rather than installed: the catalogue before there is anything to catalogue, the storefront before there are shelves. Ninety days is enough time to build the wrong thing extremely well.
There is a mirror-image failure that is just as common and much quieter. Nothing happens at all. The ops team is renamed, a Slack channel is created, the ticket queue continues exactly as before, and the org concludes that platform engineering is a rebrand. That is adopting the vocabulary and skipping the practice, and by the time the review comes round the honest summary of the quarter is “we changed our name”.
Both failures come from the same root: no one wrote down what the team is for.
Deliverable one: a mandate, including the no
Write your mandate in the first three weeks. Not a roadmap, not a vision deck. A page, and honestly three sentences would do:
- What we own. The capabilities, not the projects. “Build and delivery, runtime, and the default wiring for observability and secrets” is a mandate. “Migrate everything to EKS” is a project.
- What we do not own. The load-bearing half, and the half everybody omits. Application performance. Data pipelines. The legacy billing box. Whatever it is, name it, because the alternative is that your scope is defined by whoever asks loudest on a Friday.
- Who decides when it is contested. There will be a fight about a boundary in month two. Decide now who settles it.
- What happens to the queue we inherited. More on that below, but it belongs in the mandate, because it is the single largest claim on your time and it arrived without anyone deciding it should.
Then do the part that makes it real: get the person who funded the team to say it back to you in their own words. If what they say back is different from what you wrote, that is not a failure of the exercise, that is the entire value of the exercise. You just found out what they actually bought, in month one, instead of in month nine.
A platform team without a written no becomes the team that does whatever it is asked, which is a service desk with a nicer name and a linear relationship between the number of teams it supports and the number of people it needs. The steady state you are aiming for is X-as-a-Service, and you do not drift there. You get there by refusing, on purpose, in writing, the work that would keep you in permanent collaboration mode with everyone.
Deliverable two: the numbers you can only measure now
In month nine someone will ask whether things have improved. “It feels better” loses that argument every single time, and you will not be able to reconstruct the starting point after the fact. The first few weeks are the only window in which you can measure an organisation you have not yet changed. Take it.
Four numbers, all cheap, none of them requiring a platform to collect:
- Time from nothing to production, measured with a stopwatch. Take the pillar’s test literally: stand up a new hello-world service yourself, in week one, using only the documentation a new joiner would find, and record the calendar time and every place you had to ask a human. This is the most useful number a platform team can own, because it is the one metric that is unambiguously yours and unambiguously about the developer experience.
- Where the tickets actually go. Three months of infra, access and support requests, sorted into six or eight crude buckets, with a count and a median wait per bucket. Half a day of work. It will tell you more about what to build than any workshop.
- The four delivery numbers, roughly. Deployment frequency, lead time, change failure rate, time to restore, per team, pulled from what your CI system already knows. Rough is fine and rough is the point. Take the baseline and then put it away: this is a measurement, not a programme, and building a dashboard for it in month one is how you end up with numbers that go green while nothing about how you ship has changed.
- What developers say before you have anything to defend. Eight conversations, twenty minutes each, one question that matters: what is the most annoying part of getting your work into production? Do this in week two. From month four onward you will be defending your own work, and you will never get an unguarded answer again.
None of this feels like working. There is no artefact, no deploy, no demo, and a real temptation to skip it because the team is impatient to build. Do it anyway. It costs about two weeks and it is the difference between a review where you present evidence and a review where you present opinions.
Deliverable three: the queue is your requirements document
Almost every new platform team inherits a ticket queue, because almost every platform team is formed out of the group that was already absorbing this work. The queue is the central tension of the first ninety days and there are two obvious answers, both wrong.
Keep serving all of it and you will build nothing, forever, and the org will correctly conclude that the rename changed nothing. Announce that you no longer do tickets and you will burn every relationship you have inside a week, having taught the whole engineering organisation that the platform team’s first act was to stop helping.
The way through is to treat the queue as two things at once: the largest source of requirements you will ever have, and a capacity problem you have to bound explicitly.
- Categorise before you optimise. You already did this for the baseline. Now read it as a specification. The request that has been filed eleven times by seven people is not an annoyance, it is a fully validated product requirement with a user base attached.
- Bound the interrupt, visibly. One named person on a rotating shift handles the queue, published where everyone can see it, and the rest of the team is genuinely untouchable. Not “we will try to protect focus time”. A named person, a fixed rota, and a manager willing to enforce it. Half-protected time is unprotected time.
- Kill the requests that should not exist. Some fraction of any queue is pure friction with a two-hour fix: an access request that should be a group membership, a config change that should be a self-serve flag, an approval nobody reads. Clearing those is not strategy, but it is free capacity and it is instant goodwill.
- Let the top of the list choose path one. The most repeated request in that queue is your first paved road, and now you can say so with a count instead of an intuition. That is precisely the research that building your first golden path depends on, and the second ninety days is where you build it.
- Report the queue upward every month. One line: this many requests, this many engineer-hours, these three categories. Nobody else in the company will ever make the argument for your funding, and this is the cheapest version of that argument you can produce.
Deliverable four: fix one small painful thing by week six
You cannot spend a full quarter on research. A team that shows up, interviews everyone, and produces a document is indistinguishable from consultants, and it will be treated accordingly. Somewhere around week five or six you need to ship one thing.
Pick it against four rules: it requires no new platform, it requires no migration, it is visible to people outside your team, and it is done in under two weeks. Good candidates are sitting in the queue and in your interview notes already. The CI step that flakes twice a day and everyone reruns without complaining. The access request that takes two days and could take two minutes. The staging environment that is broken every Monday morning. The alert that has paged someone every night for a year and has never once been acted upon, which is a monitoring artefact rather than a signal and can simply be deleted.
The fix is not the point. The point is that the next time you ask a team for two hours of their time to design something with you, they give it to you, because the last time your team touched their world it got better. Credibility is the currency you spend on the second ninety days, and this is how you earn the first of it.
One warning: do not let this become the job. The small fix is a down payment, not a strategy. A team that does nothing but small fixes for a year is a very well-liked service desk, and it will still be dissolved in the reorg.
What not to do before day ninety
The list of things to actively defer, because each one is a genuine good idea at the wrong moment:
- Do not build or buy a portal. You have nothing to put in it. Earn it once you have three or four paths.
- Do not start a migration. A platform migration is a twelve-month commitment being made by a team with ninety days of credibility and no baseline. Whether you need the destination at all is a question you are not yet equipped to answer honestly.
- Do not publish a twelve-month roadmap. You do not know enough, and everything on it will be wrong in a way that is later quoted back to you. Publish the mandate and a ninety-day plan. That is a stronger document precisely because it is smaller.
- Do not choose the exciting tool. The first thing you build sets the default for everything after it, which is the worst possible place to experiment. Boring is the feature.
- Do not launch the cross-cutting programmes yet. Cost attribution, policy-as-code, SLOs: all real capabilities, all of which attach to a paved road you have not built. Cost belongs in the template and a security control needs a road that satisfies it, and without the road both degrade into a tagging campaign and a policy PDF. Build the surface first, then hang the capabilities off it.
- Do not rename yourselves and stop. If the only artefact of the quarter is new job titles, the quarter did not happen.
The review nobody schedules
Here is the highest-leverage twenty minutes of the whole quarter, and it costs nothing: put the day-ninety review in the calendar yourself, in week one, with the person who funded the team.
Four agenda items. The mandate as finally agreed, and what changed from your first draft. The baseline numbers, presented as the starting line rather than as an achievement. The one thing you fixed, what it cost, and who noticed. And the proposal for the next ninety days: one path, one named design partner, one number you expect to move, and what you need in order to do it.
Then ask, explicitly, for the second ninety days. Not for eternal funding. For one more quarter, against a stated outcome.
Two things happen when you do this. You set the terms of your own evaluation instead of being surprised by someone else’s, and the fact that a date exists forces the team to have something on it. This is the same instinct as agreeing an error-budget policy while everyone is calm rather than in the middle of an outage. Decide how you will be judged before anybody is annoyed enough to decide it for you.
When this is the wrong answer
The honest off-ramps, because a lot of teams called platform teams should not run this quarter at all.
- You are eight engineers with four services. You do not need a platform team, you need a shared opinion and a README you all trust. Standing up a platform function at that size is the same category error as running Kubernetes for three services: a structure priced for a scale you do not have. Wait until the inconsistency itself is the problem.
- You were formed to deliver one named project. “Get us out of the datacentre by Q3” is a project team with a deadline, not a platform team. Your mandate is already written and your evidence is already defined. Do the project, ship it, and have the platform conversation afterwards if there is one to have. Running a discovery quarter over a decision that has already been made is pure ceremony.
- You are a team of one. One person cannot run a product with an on-call rotation. You are an enabling function, and the honest version of the role is facilitating mode: make three teams better at something, get out of the way, repeat. Pretending to be a platform of one ends with a single point of failure carrying a pager.
- You inherited a platform rather than a blank page. Different job. Your first ninety days are archaeology and trust repair: which parts are load-bearing, which were abandoned mid-build, and why the previous team lost the room. The baselines still apply and the mandate conversation is harder, because everyone already has an opinion about you. Very often what you have inherited is a platform that was funded as a project rather than as a product and then left to rot, in which case the real deliverable of your quarter is a funding argument rather than a technical plan.
- Nobody will commit past this quarter. If the team’s existence is genuinely under review at the end of the quarter and there is no appetite to discuss the one after, do not run a discovery process. Find the most visible painful thing, fix it well, and be clear-eyed about the fact that you are doing tactical work in a strategic costume. Then decide whether you want the job.
The bottom line
The first ninety days of a platform team are not a construction project. They are the quarter in which you establish what you are for, what you refuse, what the starting line looked like, and that touching your team’s world makes things better rather than slower. Get those four things and the second ninety days can be spent building the first paved road with a real design partner and a real reason. Skip them and you will build something impressive for nobody, and the team will be reorganised out of existence by people who will never quite be able to say what it did.
So spend week one writing the mandate and stopwatching a deploy, not choosing a service mesh. Read three months of tickets like a product manager. Protect the team’s time with a named rota instead of an intention. Fix one embarrassing small thing by week six. Book your own review.
And ask yourself the question that the whole quarter is really about: on day ninety, which developer outside my team will say, unprompted, that something got better? If you cannot name that person, you are building for yourself, and you still have time to stop.
If you are standing up a platform team and want the first quarter to buy you the second one - or you have inherited a team that is nine months in and cannot answer what it changed - that is exactly the kind of problem I help people untangle. Let’s talk.