Newshot 
Why platform teams fail (and AI makes it worse)
14 November, 2026
I've spent the better part of a decade working with and adjacent to platform teams across companies of varying size and maturity. The same mistakes keep showing up. The companies, stacks, and org charts differ, but the dysfunction is the same. And generative AI is accelerating the cycle.
This post is a collection of observations about why platform teams fail, drawn from the ones I've watched do it.
The firefighting trap
Every platform team I've seen fail has followed the same trajectory. They start with ambition: a roadmap, a vision for developer self-service, maybe even an internal developer portal on the horizon. Then production breaks. An incident pulls two people off roadmap work. Then another. Then the team is permanently in reactive mode, triaging tickets, patching config drift, and debugging other teams' deployments.
Within six months the platform team is an ops team with a fancy name. The roadmap stalls. The backlog grows. Engineers in product teams stop asking the platform team for help because the turnaround time is too slow, so they build their own solutions. Which creates more drift. Which creates more incidents. Which pulls the platform team further into firefighting.
Breaking out of this cycle requires leadership that can say no to reactive work and protect time for proactive investment. I've rarely seen this happen without executive sponsorship. A platform team that reports three levels down from anyone with budget authority will always lose the prioritisation battle to "production is down right now."
Getting that sponsorship means spelling out the cost of not investing. "We'll save X hours per team per sprint" is more compelling than "we want to build a developer portal."
Golden paths and guardrails are not the same thing
I think a lot of platform teams conflate these two concepts, and the confusion causes real damage.
A golden path is a product: the supported, pre-built route for a common task, like a starter template for a new service. It earns adoption by being faster to use, more secure by default, and better documented than the alternative. If engineers aren't using your golden path, mandating it won't help. Talk to the people who chose not to use it, find out why, and make it better. That's product management work.
Guardrails are policy. Secrets should never be committed to a repository. Container images must come from an approved registry. These aren't suggestions. They apply globally, across all pipelines, regardless of whether a project started from a golden path or was generated by an AI at 2am on a Tuesday.
The problem shows up when teams try to enforce golden paths like guardrails (creating resentment and workarounds) or treat guardrails like golden paths (making security optional and adoption-dependent). Get the distinction right and a lot of downstream problems disappear.
Generative AI is making this worse
Generative AI is undermining platform teams that haven't proven their value.
A developer can now ask Claude Code to scaffold an entire service in minutes. A Terraform module, a Dockerfile, a CI pipeline, a Lambda function with API Gateway in front of it. Done. It works. It deploys. And at no point in that workflow did the developer discover that their platform team already provides a security hardened starter template for exactly this use case.
I've watched this happen. The platform team spent months building a golden path and nobody used it because it was easier and faster to generate something from scratch. The generated version worked fine on day one. By month three it was a maintenance burden, because it had never been built to the organisation's security and compliance standards and nobody was keeping it in line with them.
If your golden path can be outpaced by a prompt, you have a discovery problem. And discovery problems become relevance problems fast.
It also raises the stakes on guardrails. When any engineer can skip the golden path with a prompt, guardrails are the only thing that still applies to everything that ships. A team whose security lives only in its templates has no security for generated code.
Discovery looks different when coding agents do the scaffolding. An agent doesn't browse a Backstage catalog. It reads an AGENTS.md or SKILL.md file. It calls an MCP server to find out what templates and tools are available. Today's developer portal might be a well-structured, machine-readable catalog rather than a React app with a search bar. If the agent knows the starter template exists, it can start from that instead of from nothing, and the golden path is the path of least resistance again.
Most platform teams I've worked with haven't thought about this at all. They have no portal, no catalog, not even a README that lists what's available. The golden path exists in someone's head or buried in a Confluence page nobody reads.
The skills gap
Someone has to build and maintain that catalog, and this is where many platform teams have an uncomfortable problem. They're staffed with people who are excellent at infrastructure but have little experience building software products.
I don't say this as a criticism. It's an observation about how the industry has evolved. DevOps as a discipline attracted people who are deeply skilled in Terraform, Kubernetes, networking, and CI/CD pipelines. These are valuable skills. But platform engineering asks something different. It asks you to build tools, abstractions, and interfaces that developers actually want to use, which is software development and product design. And the consumer of those interfaces is now as likely to be an agent as a human.
None of this means replacing infrastructure-focused people. Platform engineering needs a blend of infrastructure expertise and software development capability. Some organisations get there by embedding software engineers into the platform team. Others partner with product teams to build the developer experience layer. Either works. Pretending the gap doesn't exist doesn't.
Shipping without buy-in
I've seen platform teams build solutions in isolation and ship them to the wider engineering group without ever socialising the decision. No RFC. No input from security. No conversation with the teams who'll actually use the thing. Then they're surprised when adoption is low or when security raises concerns three months later.
That's a failure of alignment more than technology. Platform work touches everyone. A new deployment pipeline, a change to how secrets are managed, or a migration to a different container orchestrator all have blast radius. They affect security posture, developer workflows, and on-call rotations.
The teams that get this right treat cross-functional alignment as a first-class activity. They write proposals. They get security involved early, so requirements are baked into templates and guardrails instead of bolted on at a review gate. They present to engineering leadership before building. It's slower. It's also how you avoid building something that gets quietly routed around by the people it was meant to serve.
When platform teams shouldn't exist yet
Not every organisation needs a dedicated platform team, and a headcount threshold won't tell you whether yours does. A better test is whether you can staff the team with enough capacity to do proactive work. A platform team that spends all of its time patching, triaging, and unblocking deploys is doing ops, whatever its Slack channel is called.
The premature platform team pattern usually looks like this: two or three engineers get pulled off product work and handed responsibility for infrastructure, CI/CD, security tooling, developer experience, and cloud cost management. That's five jobs. They can either keep the lights on or build golden paths. They cannot do both.
So they firefight. And the rest of the org starts building around them because they're a bottleneck. The platform team slows everyone down instead of speeding them up.
If you can't give a platform team enough people and enough mandate to spend at least half their time on proactive, product-oriented work, you're better off embedding platform thinking into your engineering culture: a senior engineer who champions conventions, writes the initial templates, and sets up the guardrails. The team comes later, when you can resource it to succeed.
What actually works
The platform teams I've seen succeed treat their work as a product, bring security along from day one, protect time for proactive work, and hire people who can build software as well as run infrastructure. They also know when to say "not yet," because building before the org has the pain to justify the investment creates the very dysfunction it was meant to prevent.
AI changes none of that, but it shortens the time you have to get it right. Engineers used to route around a weak platform team over months. Now they can do it in an afternoon. The teams that stay relevant will be the ones whose golden paths are the first thing an agent finds, and whose guardrails catch whatever it builds when it doesn't.
Hey there! 👋
I'm Will Dady (pronounced day-dee), a technology leader from Melbourne Australia with over 20 years of experience in the industry.
I am passionate about coding, IT strategy, DevOps and cloud platform engineering.