Gartner's latest numbers say 80% of software orgs will have a dedicated platform team by end of year, up from 55% in 2025. That's not a trend. That's a phase change.
I've been watching this happen in real time at Citrix, and across the enterprise infrastructure world more broadly. The shift isn't really about new technology. It's about admitting that "you build it, you run it" doesn't scale past a certain org size without shared tooling underneath.
What broke
The original DevOps promise was beautiful: tear down the wall between dev and ops, give teams full ownership, let them move fast. And it worked great for small organizations. A team of 8 can absolutely own their CI/CD pipeline, their Kubernetes config, their observability stack.
But when you have 40 teams, each building their own deployment pipeline with slightly different conventions, you get a mess. Spotify's internal research found developers spending 30-40% of their time on infrastructure tasks unrelated to the product they're building. I've seen the same thing. Engineers who should be shipping features are instead debugging Terraform state, wrestling with Helm charts, or figuring out why their staging environment drifted from production.
The cognitive load problem is real and it compounds. Every new tool, every bespoke pipeline, every team-specific convention is another thing to remember. At a certain scale, shared responsibility starts meaning nobody's responsible.
What platform engineering actually is
Strip away the hype and it's straightforward: a dedicated team builds and maintains a self-service layer that other teams consume. Pre-approved infrastructure, standardized CI/CD, built-in security guardrails, observability out of the box. Developers get a golden path that's fast and safe. They can still go off-road, but most of the time they don't need to.
The key word is "self-service." This isn't the old centralized ops team that was a bottleneck on every deploy. It's a product team whose customers happen to be other engineers. They run user research, they track adoption metrics, they iterate on the developer experience just like a product team iterates on customer experience.
Companies reporting results from this are seeing 30-50% faster deployments and meaningful drops in developer time spent on undifferentiated infra work.
What this means for TPMs
If you're running programs that touch infrastructure - and at Citrix, most of mine do - platform engineering changes the coordination model.
The old model: each team owns their infra end-to-end, and I spend time making sure their deployment practices don't conflict. Team A's canary rollout doesn't stomp on Team B's database migration. Their monitoring stacks produce compatible data. Their release schedules don't create impossible testing windows.
The new model: the platform team provides the paved road, and my job shifts toward making sure the platform actually serves the teams that depend on it. That's a different kind of dependency management. Instead of N teams each with their own infra dependencies, you have N teams depending on one platform team. The coupling is more visible but also more concentrated. If the platform team ships a breaking change or falls behind on a feature request, the blast radius is everyone.
I've started treating our internal platform like a vendor dependency. SLAs, roadmap visibility, escalation paths. It sounds heavy-handed, but when 12 teams depend on the same deployment pipeline, you need the same rigor you'd apply to an external service.
Where I think this goes
The next step is AI-augmented platforms. I'm already seeing early versions: natural language commands to provision infrastructure, AI agents that debug pipeline failures, predictive scaling that adjusts based on deployment patterns. 94% of enterprises in a recent survey said AI is essential to their platform strategy.
But the fundamentals don't change. You still need clear ownership. You still need to treat developers as customers. You still need a TPM who sees the dependency graph and keeps things moving. The tools get better. The coordination problems stay human.