Solving a Problem That Didn't Exist
Why platform engineering took a decade to become obvious
Part 1 of our Platform Engineering series
By Colin Griffin, Founder and CEO, Krumware
If you've spent any time around modern engineering organizations, you've heard "platform engineering" thrown around a lot lately. If you’ve spent any time around me, you’ve DEFINITELY heard it more than once. It's one of those phrases that gets used constantly and rarely gets explained.
The short answer: We started building platforms in 2016 because we couldn't ship our own software without them, years before anyone called it platform engineering. The problem came first, the name came a decade later, and most organizations still meet it in that order. This post is about where that problem came from.
Ask a room of ten engineers to define platform engineering and you'll get ten different answers. That's not a knock on the industry, it's a sign of how young this discipline still is. And it's why the framing I keep coming back to is a useful place to start:
Platform engineering isn't a new concept. (For most teams) It's a new conversation.
Somebody has always been building the paved road everyone else drives on. What's new is that the work finally has a name recognizable to the people who fund it, which means it can be discussed in terms of business value instead of tooling.
So let me start close to home: how we ended up doing this work in the first place.
How We Got Here
I started Krumware in 2016, long before "platform engineering" was a term anyone used. I came out of critical infrastructure software, building systems that got deployed onto servers owned and operated by customers, and managed by IT teams who weren't the ones who built the software. That's a specific kind of hard. You can write great software and still watch it struggle in the real world because the environment it landed in was never set up for it.
When containers and Kubernetes started to take off, I saw an opportunity to fix some of those problems I had run into as an engineer. So Krumware went all-in early, and the focus became not just writing cloud-native software, but building the tools, processes, and know-how that let other software engineers adopt cloud-native practices too.
That shift exposed a second problem: we couldn't ship our products unless the infrastructure teams at our customers gave us the tools to ship. So we had to develop a practice around that. And it was difficult to sell for a long time, because it felt to the industry like a solution to a problem that didn't exist yet.
Before we could deliver, someone had to build the platform underneath the delivery. So we started building a layer around our software - the tooling that let infrastructure, security, and data teams hand us back an environment we could deploy into. Our first leap into self-service was building software for others to help us build software. Over roughly a decade, solving our own delivery problem became the company's identity.
(If these problems sound familiar, you should check out Epinio)
There's a related idea I come back to often: there's no such thing as a truly unique problem. Nearly every customer challenge we run into is a variation on something already solved somewhere else, which means the real work is turning one customer's pain point into something repeatable rather than solving it once and moving on. Solve it for real, then productize it. That instinct runs through everything else in this series.
Since 2024, I have been a co-chair of the CNCF Platform Engineering Technical Community Group, working alongside people shaping how the wider industry defines this discipline. But that came after a decade of doing the work, not before.
The Problem Platform Engineering Solves
Picture a typical engineering org a few years back: every product team owns its own slice of infrastructure, every team writes its own CI/CD pipeline, manages its own Kubernetes manifests, figures out its own secrets management, debugs its own observability stack. Multiply that by a dozen teams and you get a dozen slightly different, and often quietly broken, ways of doing the same thing.
Developers end up spending as much time wrestling with infrastructure as building the features they were hired to build. That's not really a tooling problem. It's a cognitive load problem: engineers are forced to hold far more operational context in their heads than they should need just to ship code. And the cost compounds. Every new hire absorbs it. Every incident is harder to reason about. Every improvement has to be made a dozen times. Platform engineering emerged directly out of this pain.
What's Coming Up in This Series
If you're new to platform engineering, welcome! You're going to see this term everywhere, and this series will provide the fundamentals (plus a sense of where they come from). If you're already living this every day, stick around. I’m going to get into the details that actually matter, which are the lessons my team and I have learned over a decade of building platforms with real engineering organizations, long before this work had a name.
If you want to know where your organization stands, you don't have to hire anyone to tell you. The CNCF publishes a Platforms White Paper and a Platform Engineering Maturity Model - both free, both vendor-neutral, and both more useful than most of what you'll pay for.
I co-chair the group behind those publications and my standing advice hasn't changed: go find the white paper, go find the maturity model, and assess yourself against them. Then tell us how it went.
Next up: What Is Platform Engineering? A Practical Introduction.
Colin Griffin is the founder and CEO of Krumware, a cloud-native software engineering firm specializing in platform engineering, custom software development, and open-source tooling. He co-chairs the CNCF Platform Engineering Technical Community Group.