Why Your Company's Platform Engineering Is Probably Broken

Look, I'm just gonna say it: everyone's speedrunning platform engineering right now, and most of them are absolutely eating it. 🎮

Ajay Chankramath (CEO of Platformetrics) and Nic Cheneweth (Principal Technologist at ThoughtWorks) just dropped some real talk about why companies keep fumbling the platform bag, and honestly? It hits different when you realize how many orgs are making the exact same mistakes.

The Backstage Graveyard Is Real

So here's what's actually happening out there. Companies are yeeting themselves into Backstage implementations like it's going to magically fix all their DevOps problems. Spoiler: it doesn't.

Chankramath's been talking to clients who've been on the "Backstage journey" for years and have basically nothing to show for it. One ed-tech company he mentioned? Three years in, still struggling. And this isn't some edge case—it's the pattern.

"When I talk to a lot of these clients, a lot of these newer clients in my current role, one thing I find is there are so many people are getting started on Backstage," Chankramath explains. "Everybody wants to get started on Backstage, but the number of people who are really finishing that journey and really getting something out of it seems to be really really low."

Cheneweth has a perfect term for what goes wrong: Backstage becomes a "crap magnet." Companies treat it like the platform itself instead of what it actually is—a UI layer. They pile everything into plugins, skip the architectural work underneath, and then wonder why it doesn't scale.

Think of it like building a gaming PC but spending all your budget on RGB lighting while running a Pentium processor. Sure, it looks sick, but you're still getting 12fps in Cyberpunk.

The Real Problem: Architecture Debt Compounds Fast

Here's where it gets interesting. Both Chankramath and Cheneweth hammer on this point: cutting corners early doesn't save time—it multiplies your problems exponentially.

"There's value in experimenting and finding out what those teams actually need before investing in it," Cheneweth says. "But if you don't have if you literally don't have the time to implement it right? Why do you think you're going to have the time to fix it later?"

This is the trap companies keep falling into. One team needs something. Leadership wants fast results. So the platform team duct-tapes a solution together with the promise they'll "do it right later." But later never comes because now you're supporting that janky implementation AND trying to scale it.

It's like that meme where someone's holding up a crumbling foundation with their bare hands going "this is fine." Except it's not fine, and now you've got fifty developers depending on your shaky infrastructure.

Control Planes: The Actual Foundation That Matters

So what should companies actually be doing? According to Cheneweth, everything needs to be API-first from the jump. And I mean everything.

The idea is simple but powerful: build control planes that wrap your cloud provider APIs (AWS, Google Cloud, Azure, whatever) with standardized interfaces. Developers get guardrails and golden paths for common use cases, but they can also break out and go direct to the cloud provider when they need something specific.

Cheneweth uses this perfect plumbing analogy: "I got a 1-inch pipe, I need to go to a ¾-inch, I can just get a step down thing, you know, because there's a set of conventions and standards that they can follow."

Kubernetes is their go-to for building these control planes, and not because it's trendy. The reconciliation loop—that constant checking of "is this what the user asked for?" and "has it drifted?"—is battle-tested by probably the largest open-source community in infrastructure.

"Rather than rebuild all that by hand and try to achieve that same level of resiliency," Cheneweth explains, "it's like let's just use it for what it is."

They're literally deploying control planes where developers don't even know Kubernetes is running underneath. They're not containerizing apps—they're using K8s as the orchestration backbone for infrastructure provisioning. That's the kind of architectural thinking that actually scales.

Product Mindset > Just Shipping Features

The other major thread running through their conversation: internal platforms need product thinking, not just engineering thinking.

Companies absolutely nail this with external products. They obsess over user experience, gather feedback, iterate constantly. But internal platforms? Totally different story. Platform teams just try to ship something—anything—that technically works, without thinking about whether it's actually good to use.

"A lot of organizations have never really thought about it that way," Cheneweth points out. "And so they've never sort of developed a sense of looking at something and saying, 'Well, that's a terrible product experience' when they're delivering it to internal customers."

Chankramath breaks down the transformation pattern he's seeing: standardize first (create those golden paths), then orchestrate (automate the workflows), then contextualize (adapt for your specific industry—fintech vs telecom vs whatever). Skip steps and you're building on sand.

The Pipeline Ownership Red Flag 🚩

Here's a quick litmus test for whether your platform engineering is cooked: who owns the CI/CD pipelines?

If your answer is "the platform team," you've already lost. Chankramath is brutally clear on this: "If you think that pipelines are owned by platform engineering, you have already failed."

Developers need to own their own pipelines. ThoughtWorks literally pioneered continuous integration with CruiseControl specifically for developer concerns, and then somehow the industry memory-holed that and turned CI/CD into something platform teams control.

When developers own their pipelines, you remove massive amounts of friction. When the platform team owns them, you've just created a bottleneck and negated half the point of having a platform in the first place.

The Measurement Gap Nobody Talks About

Companies want to measure their platform success, so they immediately jump to DORA metrics. But Chankramath sees this as another mistake—it's too far removed from the actual problems.

"Organizations even struggle to measure that because they tend to jump into DORA metrics and things like that which is a giant leap from where their problems are to the how the manifestation of those problems," he explains.

You need to break down the basics first. Are your APIs actually being consumed properly? Are developer touchpoints unified or scattered? You can't optimize deployment frequency if your developers can't even figure out how to deploy in the first place.

What Actually Matters

After 30+ minutes of conversation, the core message is pretty straightforward: stop treating platform engineering like a sprint and start treating it like infrastructure that needs to last.

Invest in the architectural foundation—control planes, API-first design, proper domain boundaries. Let developers own their pipelines. Think like a product team, not a feature factory. And for the love of all that is holy, don't assume Backstage is the platform itself.

The companies getting this right aren't necessarily the ones with the fanciest tools or the biggest budgets. They're the ones who understood that cutting corners on architecture just means you pay interest later—with compound interest that'll absolutely wreck your scaling plans.

Your platform is infrastructure. Build it like infrastructure. Not like a hackathon project you're gonna "fix later."

---

Tyler Nakamura is Buzzrag's Consumer Tech & Gadgets Correspondent, covering the intersection of developer tools, infrastructure, and the technologies shaping how we build software.