In 2024 I created the LEAD podcast with my good friend Geert van der Cruijsen. In this podcast we explored the various aspects of building an engineering culture. We made quite some episodes. With guests and without guests. And I thought it would be a great idea to share some of these stories combined with my insights from these episodes on this blog. All credits do not go to me. They go to Geert as well, and to our guests. And of course to Xebia, the company I work for, for making this possible.
When I first heared the phrase “DevOps is dead. Long live platform engineering.” I was actually a bit surprised. It is something that’s been floating around at conferences, on blogs, in vendor pitches the last year or so, and it made me think. I’ve been a big supporter of DevOps. The principles made sense. The results were real. So hearing that it was “dead” felt like the industry was ready to throw away something we just barely got right.
But after talking it through with Geert, the conclusion wasn’t so dramatic. DevOps isn’t dead. It’s just evolving. And maybe that’s a good thing.
The problem isn’t DevOps. It’s how heavy it’s become
When DevOps first became popular, the goal was clear: break the silos. Get development and operations to work together. Let teams take full ownership of what they build, from idea to running system. It worked. It still works. When you give teams that responsibility, they make better decisions. They care more about reliability. They feel more connected to what they deliver.
But we’ve also seen the other side. Not every team is equipped to take on all those responsibilities. The list of things a modern team needs to handle keeps growing. Cloud infrastructure, CI/CD pipelines, monitoring, security, compliance, cost tracking, networking, provisioning. It’s a lot. And even if you have smart, motivated people, it’s not realistic for every team to be great at all of it.
So we started seeing cracks. Teams struggling to get their environments running. Developers overwhelmed by tasks outside their core focus. Platforms built by developers who never wanted to think about infrastructure. That’s not a failure of DevOps. That’s just reality catching up with the vision. And on top of that. The industry started calling everything DevOps. Really watering down the true meaning of the word.
Platform engineering doesn’t kill DevOps. It supports it
This is where platform engineering comes in. Not as a replacement, but as an enabler. The whole point of platform engineering is to reduce the cognitive load on teams. To help them focus. To let them keep owning their applications without needing to reinvent the wheel every time.
A platform team builds internal products. Templates, services, and tools that help other teams move faster. Instead of every team setting up their own infrastructure for an API, the platform team builds a standard approach. Instead of every team managing their own firewall rules through tickets and waiting three days, the platform team builds a self-service interface that takes care of it in minutes.
But here’s the important part: the platform is optional. The team using it still owns their app. They can extend the templates. Or choose not to use them at all, as long as they stay within the broader boundaries set by security or compliance. That’s not top-down control. That’s support with autonomy.
What makes a good platform team
We talked a lot about this in the episode. A good platform team doesn’t push their tools onto others. They act like a product team. They have users. Those users are the developers and engineers building business features. So the platform team listens to them. They look for the pain points. They ask where time is being wasted. And they build solutions to solve those problems.
That sounds obvious. But it often goes wrong. I’ve seen too many platform teams form out of old operations teams. They rebrand, but keep doing the same thing. Lots of tickets or equivalents, long lead times, tight control. That’s not a platform. That’s a new bottleneck.
Instead, a good platform should act like any other cloud service. Easy to use, well-documented, with clear value. If teams don’t want to use it, that’s a sign something’s off. And if they do want to use it, they should be able to contribute to it too. Internal open source is a great model here. The platform team owns the code, but other teams can submit improvements or add what they need. That keeps things flexible and prevents the platform from becoming stale or irrelevant.
Start with the problems, not the tools
If you’re thinking about building a platform team, don’t start by picking a tool or copying what someone else did. Start by talking to your developers. Ask them where they’re losing time. What tasks feel repetitive. What’s blocking them from moving faster.
Maybe it’s setting up new environments. Maybe it’s getting approvals for security changes. Maybe it’s building the same CI/CD pipeline over and over again. Whatever it is, start there. Fix one thing. Then another. Measure the impact. Keep talking to the teams. Keep improving.
And don’t build everything all at once. You can start small. You probably already have what you need. Git, pipelines, some YAML files. Use what’s there. Build something that works. And when that works, then maybe you can invest in a portal or more advanced tooling.
So, is DevOps dead?
No. Not at all.
DevOps is still the goal. Teams owning what they build. Fast feedback. End-to-end responsibility. But we’ve learned it’s not enough to just say “you build it, you run it” and expect everyone to figure it out on their own.
Platform engineering is one way to support that model. It gives teams the tools and standards they need to succeed. It removes some of the overhead. It creates guardrails without taking away control.
In the end, DevOps and platform engineering are not opposites. They go together. They solve different parts of the same problem. One sets the mindset, the other supports the execution.
So no, DevOps isn’t dead. It’s just growing up. And like all things to need to grow. It needs a bit of love and attention.
The original Episode
If you want to listen to the original episode, you can listen to this
The Road to ALM 