Photo by fauxels on Pexels
I spent a good chunk of 2023 arguing with a VP of Engineering about whether our company "needed DevOps or Platform Engineering." It was the wrong question. By the time we shipped our internal developer platform in early 2024, I understood why: DevOps is a culture, and Platform Engineering is a discipline. Conflating the two is like confusing Agile with Scrum — one is a philosophy, the other is a set of tools and practices you use to live it.
In 2026, this distinction matters more than ever. Engineering organizations are larger, cloud bills are more painful, and developer cognitive load has crossed a threshold where good engineers are leaving not because the work is hard, but because the friction is intolerable. Platform Engineering is the answer to that friction. This post is everything I know about making it work.
DevOps Told Us What to Value. Platform Engineering Tells Us How.
Platform Engineering is the discipline of designing and building toolchains and workflows that enable self-service capabilities for software engineering organizations. The platform team's customer is the internal developer. Their product is the Internal Developer Platform (IDP).
DevOps, by contrast, is a cultural and organizational movement aimed at breaking down silos between development and operations teams. It doesn't prescribe a specific toolchain or team structure. DevOps told us what to value — collaboration, automation, fast feedback, shared ownership. Platform Engineering tells us how to operationalize those values once the org gets big.
Here's the practical difference. A company practicing DevOps might have every team owning their own CI/CD pipelines, their own Kubernetes configs, their own security scanning setup. That works when you have five engineers. It breaks down when you have five hundred:
- Every team reinvents the same wheel.
- Security standards drift across repos with no single owner.
- Onboarding a new developer takes three weeks because they have to learn fifteen different internal systems.
Platform Engineering centralizes that undifferentiated heavy lifting. A dedicated platform team builds and maintains the golden paths — the opinionated, supported, well-documented routes for doing common development tasks. Other teams can deviate if they have a good reason, but they don't have to. The default path just works.
The "You Build It, You Run It" Trap
Amazon's "you build it, you run it" principle was genuinely influential. It gave teams ownership and accountability. But taken too far, it means every product team is also an infrastructure team, a security team, a compliance team, and a tooling team. That is not sustainable.
In my experience, teams that fully "run it" burn roughly 40% of their sprint capacity on operational overhead that has nothing to do with their actual product. On a 10-person team costing you around $150,000 per month fully loaded, that 40% is $60,000 a month spent on plumbing instead of features. Platform Engineering gives you the ownership benefits of DevOps without forcing every developer to become a part-time platform engineer.
The Numbers I Actually Track
When I pitch a platform investment, I don't lead with architecture diagrams. I lead with time and money. Here is the before/after from the org I built our IDP in.
| Metric | Before IDP | After IDP |
|---|---|---|
| New service to production | ~9 days | ~40 minutes |
| Developer onboarding | 3 weeks | 4 days |
| Ops overhead per team | ~40% of sprint | ~12% of sprint |
| Cloud spend (monthly) | $100,000 | $78,000 |
That cloud number is worth translating: standardizing on golden-path templates with sane defaults cut waste by about $22,000 a month — roughly $264,000 a year — because engineers stopped over-provisioning instances "just in case." On a $1,000 team bill, expect a similar ratio: something like $200 back in your pocket every month once idle resources and one-off configs disappear.
How to Actually Build One Without a Two-Year Project
The biggest mistake I see is treating the platform like a product with a distant launch date. It isn't. Ship a thin slice, get one team using it, iterate. Here is the order that worked for us:
- Pick one painful, common workflow. For us it was "spin up a new backend service." Not glamorous, but every team did it monthly and hated it.
- Templatize the golden path. One command that scaffolds the repo, wires up CI/CD, adds observability, and applies security scanning by default.
- Make the paved road easier than the dirt road. If your platform is more work than doing it by hand, adoption dies. The default has to be the lazy option.
- Measure adoption, not features. Track how many teams voluntarily choose the golden path. That single number tells you whether you built a product or a mandate.
Why Developer Experience Is the Real KPI
A platform team's output is not uptime. It's the reduced cognitive load of the engineers who use it. The clearest signal that we got it right wasn't a dashboard — it was that senior engineers stopped filing Slack tickets asking how to deploy, and junior engineers shipped to production in their first week without a hand-hold.
Treat your internal developers like paying customers. Run surveys. Watch where they get stuck. If nobody wants to use your platform, it doesn't matter how elegant the internals are.
Bottom Line
Don't frame this as "DevOps or Platform Engineering." You need both. DevOps is the culture that makes shared ownership possible; Platform Engineering is the discipline that keeps that ownership from crushing your teams once you scale past a few dozen engineers.
If I were starting over tomorrow, I'd resist the urge to hire a big platform team on day one. I'd take two strong engineers, ship a golden path for the single most annoying workflow in the company, and let voluntary adoption prove the case. The budget conversation gets easy once you can point to $22,000 a month in recovered cloud spend and engineers who onboard in four days instead of three weeks. Build for the developer sitting next to you, measure whether they actually use it, and grow from there.
Comments
Post a Comment