Introduction
A few weeks ago, I attended DevOpsCon 2025 with one main goal in mind: to deepen my understanding of Platform Engineering (better late than never, right?). I figured I’d write up what I’ve learned—partly to help cement things for myself, and partly to share some insights with the community.
Fair warning: I’m just the messenger here. What follows is a mix of takeaways from the conference, bits from my own reading, and conversations with folks working in the space. And let’s be honest—much of this is open to interpretation anyway. So take what’s useful, leave the rest, and enjoy the post.
🧱 What Is Platform Engineering Really About?
The CNCF defines Platform Engineering as:
“The activity of designing and developing toolchains and internal work processes that enable the employees of an organisation to be self-sufficient in all software engineering activities.”
Sounds familiar, right? That’s because platform engineering is not entirely new — it’s the natural evolution of what we’ve been doing since the early days of the DevOps movement. Since around 2009, we’ve been building tooling and defining processes that help teams deliver value faster. So why does it feel like something new?
🤔 DevOps vs. Platform Engineering
One reason for this new world is confusion around the idea of “DevOps” as a role. DevOps was always meant to be a philosophy, not a job title — a way of working that empowers developers to manage their own deployments through smart automation and shared responsibility.
Platform Engineering steps in as the discipline that builds and maintains the tools, infrastructure, and workflows that make DevOps possible — especially at scale.
- DevOps focuses on collaboration and reducing lead time for changes
- Platform Engineering builds the scaffolding that makes that speed and self-service possible
You could say:
👉 DevOps is about shipping, Platform Engineering is about elevating the shipper
🚀 Why It Matters Now
Platform Engineering comes with a bold promise:
Accelerate product development, optimize developer experience, and increase value to end users.
It’s no wonder Gartner predicts that by 2026, 60% of software teams will have dedicated platform engineering functions. Whether or not we agree with the numbers, one thing is clear: CTOs and CIOs are paying attention.
That means our journey — investing in platforms, enabling developers, and improving internal experience — is both timely and full of opportunity. It’s a chance to formalize the value we’ve been delivering for years, grow new skills, and yes — play with some new toys while we’re at it.
🧑💻 Building a Platform Mindset
So, what does a platform really look like?
The conversations about Internal Developer Platforms (IDPs) reminded us that an IDP isn’t just a portal or dashboard. It’s any capability that improves developer experience. That might be a deployment pipeline, a self-service config tool, a documentation hub — even a well-maintained Slack bot.
The key is to start small and scale intentionally. Building a huge platform no one uses is a common failure. Instead:
- Identify common developer pain points
- Build lightweight, high-value tools or automations
- Iterate based on feedback and usage
- Grow trust and adoption over time
Sounds simple? So how do we do that? We Treat the platform like a product…
🛠️ Treat Your Platform Like a Product
To do this well, treat your developers as customers and your platform as a product. That means:
- Engaging regularly with your users (engineers)
- Understanding where they lose time and momentum
- Creating “golden paths” for repeatable, low-friction development
- Avoiding handoffs by enabling self-service for things like provisioning, deployments, rollbacks, and monitoring
The ultimate goal? Eliminate single points of failure and DevOps bottlenecks by empowering teams to own their full lifecycle — without needing to rely on manual support, which does mean letting go of somethings..
🦸♂️ Saying goodbye to the superhero complex
Another great takeaway was the discussion about the “superhero complex” — and how it holds back not just Platform Engineering, but development as a whole.
🦸♂️ When we keep flying in to save the day, we’re not encouraging good practices — we’re creating hidden dependencies and unsustainable workflows.
Hero culture isn’t scalable.
If we want to build resilient teams and mature engineering practices, we need to shift away from being the hidden fixers. Instead:
- Make work visible through open forums and show & tells
- Treat platform work like a product, not a ticket queue
- Create space for teams to own their paths and learn from incidents
- Enable self-service, not just support
The best support isn’t saving the day — it’s making sure teams never need saving in the first place.
💰 Why Buy-in is so important
Platform Engineering without buy-in is like building a bridge no one asked for — and then being surprised when no one crosses it.
or
It’s like swimming upstream without a paddle — you can make progress, but you’ll burn out before you reach your destination.
Platform Engineering thrives on collaboration, shared ownership, and feedback loops. Without early buy-in from developers and leadership, it becomes a lonely effort that feels imposed rather than embraced - we’ve all been in this situation, we have a fantastic idea and nobody is biting. You risk building tools no one uses, solving problems no one feels, and becoming a silo within the organization.
The key? Swim with the current.
- Engage with developers early and often
- Treat them as customers of the platform
- Solve real pain points they feel today, not the ones you assume they’ll have tomorrow
- Bring leadership along for the journey with clear outcomes and stories of impact
Buy-in turns upstream resistance into downstream momentum.
🌉 Summary
Platform Engineering is not just a trend — it’s a mindset shift. It’s about elevating how we build, support, and scale internal tooling, while treating developers as stakeholders and investing in their success.
Start small, stay user-focused, and build trust.
The platform is already here — now we make it work for everyone.