In 2024 Gartner predicted that 80 percent of large software engineering organisations would have a platform engineering team by 2026, up from 45 percent in 2022. Google's DORA research suggests the prediction landed. Its 2025 report found 90 percent of organisations using an internal platform and 76 percent running a dedicated platform team.
That second number is the one leaders should be uneasy about. Gartner was talking about large organisations. DORA's figure covers everyone. Somewhere in that gap sit a lot of companies with 20 engineers and a three-person platform team, wondering why things feel slower than before.
A forum thread from March 2026 on tianpan.co captures the mood well. A product leader described platform and DevOps engineers fighting over territory and headcount. A CTO warned that a platform team without a service attitude simply rebuilds the old central IT queue. A designer at a startup of about a dozen engineers asked why they would build anything at all when managed hosting already does the job. All three are right, at different sizes.
The signals that justify a team
Headcount is the obvious trigger, and it is a poor one on its own. In the same thread, a VP of engineering at an EdTech company that grew from roughly 25 to over 80 engineers suggested about 40 engineers as the point where a team pays for itself. Treat that as one person's experience, not a rule. What matters more is what the headcount is doing.
Three signals tend to show up together when a platform team is overdue. Several product teams are solving the same infrastructure problem separately, so you have four slightly different deployment pipelines and three ways of handling secrets. New starters take weeks rather than days to ship their first change, because the setup knowledge lives in a few people's heads. And your most experienced engineers spend a growing slice of their week answering infrastructure questions instead of building product.
The CTO in the thread put a rough number on the third signal: when DevOps engineers are spending more than 60 percent of their time on toil (repetitive manual work that adds no lasting value), something structural has to change. You do not need a survey to check this. Ask your senior engineers to tag a fortnight of their time.
If none of these signals is present, a platform team is a cost looking for a purpose.
When buying beats building
For small companies the honest answer is usually to buy. A managed platform, whether that is a hosting service that deploys straight from a repository or a managed Kubernetes offering with sensible defaults, gives you most of what an internal platform would, built and run by someone else's engineers.
Team Topologies, the book and model by Matthew Skelton and Manuel Pais that shaped much of how the industry thinks about platform teams, has a useful idea here called the thinnest viable platform. Its authors note it could be a single wiki page explaining which cloud services you use and how. Many companies under 40 engineers need exactly that, plus a managed service, and no dedicated team.
A VMware webinar with Kelsey Hightower this March was billed around the pain of do-it-yourself platforms and treating platforms as real products. Building your own is a multi-year commitment to running a product with internal customers. If you would not staff a product that way, do not build one.
Building starts to win when your needs are genuinely unusual (strict data residency, heavy regulation, unusual workloads) or when the managed bills grow faster than the salary of the people who could replace them. Do that sum honestly, including on-call and upgrades.
How to measure a platform team
This is where the turf war usually starts. Finance wants return on investment. Engineers want to talk about developer satisfaction. Both are needed, and neither works alone.
DORA's guidance on platform engineering suggests tracking three things side by side. The first is delivery performance: lead time, deployment frequency, change failure rate, recovery time and rework. The second is developer satisfaction, through simple surveys. The third is adoption, meaning whether teams actually choose the platform and keep using it.
Adoption is the measure leaders underrate. If use of the platform is mandatory, satisfaction scores are your only honest signal. If it is optional and teams still pick it, you have real evidence of value.
For the finance conversation, translate rather than abandon developer metrics. Onboarding time converts to salary cost. Duplicated pipelines convert to hours. As an illustrative example, if ten new starters a year each reach their first production change two weeks sooner, that is twenty engineer-weeks returned, which is close to half an engineer's year.
Stopping it becoming a gatekeeper
The failure mode everyone fears is the platform team that controls approvals, owns the standards and turns every request into a ticket. DORA lists ticket-driven operations and top-down mandates without collaboration among its common platform anti-patterns.
The fixes that came up repeatedly in the forum thread are organisational, not technical. Give platform and product teams shared goals, so one side is not rewarded for building tools while the other is rewarded for shipping features. Rotate product engineers through the platform team for a few months. Build the roadmap with your internal customers rather than handing it to them.
A CNCF blog post from KubeCon Amsterdam in April 2026 made a related point. Diana Todea of VictoriaMetrics argued that who builds the platform shapes who can use it, and that involving a wider range of engineers in design decisions improves adoption. Golden paths (pre-built, recommended ways of doing common tasks) should be the easiest route, not the only permitted one.
The honest caveat
The case for platform teams is weaker than the adoption figures suggest. DORA's 2024 report found platform users were 8 percent more productive individually and 10 percent better at team level, but throughput fell by 8 percent and change stability by 14 percent. The researchers described a pattern where early gains dip before recovering as a platform matures.
So expect a slump in year one. And the practitioner numbers in forums, such as onboarding halved or outages fixed faster, are self-reported by people with every reason to want their platform to look good.
What to do this quarter
Before approving headcount, spend two weeks collecting the three signals: duplicated work across teams, time to first production change for recent hires, and how much senior time goes on infrastructure support.
If the signals are weak, write the thin version. One page, one managed service, one owner. Revisit in six months.
If they are strong, staff the team with a product manager, set adoption and satisfaction targets alongside delivery metrics, and agree with finance now how success will be judged in eighteen months, before the first-year dip arrives.
