#95: Why your platform is failing

Hey there! Welcome to Platform Weekly, your weekly cast into the fire of Mt. platform engineering. Every week on Friday, we talk about the wide world of the platform engineering universe and share best practices, lessons, and news.

This week's newsletter is on one of the most important topics in platform engineering right now.

Why your platform is failing

There is a reason why of the dozens of platform engineers, from junior to director, who have joined the first official platform engineering course so many are asking one question, “why isn’t my platform working?”

Let’s dive in.

You don’t need me to tell you again that platform engineering has been taking the software engineering industry by storm. Promising lots of great things like better DevEx and real developer self-service. No more waiting times and no more TicketOps. Standardization by design and improved DORA metrics. Faster time to market, while also improving governance and security. The list goes on, and on and on.

That’s why the list of engineering organizations turning to platform engineering is constantly growing. They want to “move faster without breaking things” and “enable true DevOps”, true “you build it, you run it” at scale. And that’s why PlatformCon went from 10k to 100k views in 2 years, and that’s why this newsletter has over 100k subscribers.

So why is it that I end up on calls with desperate platform teams every week telling me their platform initiatives are failing?

It’s not for lack of trying. But so many of these teams are simply missing foundational concepts, best practices, and frameworks to help them navigate the landscape and structure their initiatives. Let’s break it down.

There are 5 main reasons platform initiatives fail:

1. Lack of a clear platform design and how all the essential components fit together. Reference architectures are your friend here. 20% of speakers at PlatformCon24 speakers used these templates to showcase their IDPs.
2. Starting to build the house from the door instead of from the foundation. They’re often focusing on the front end because they need a quick win for their manager. When long term it’s the backend that delivers the value.
3. Everything, everywhere, all at once. Some teams use the ref archs to plan out their IDP accurately. Then they try to build it and roll it out all at once. That’s a guaranteed recipe to fail at getting stakeholder buy-in. You’re trying to do too much, too fast and you’ll lose momentum and your platform before it even gets started. Think Minimum Viable Platform (MVP) first.
4. Thinking tooling is the issue. It almost never is. Platform engineering is a cultural transformation and that’s how you should approach it. You need to align your initiative to the vested interests of the different stakeholder groups and bring them on the journey with you. Not try to figure out which tools you’re going to implement.
5. Lack of product mindset. Just rebranding your existing DevOps team to a platform team without focusing on a mindset shift risks that they will approach building an IDP like they do most other things: as a one-off project. A successful IDP is built and iterated on continuously, as a product. Developers are your end customers, listen to them.

The orgs that are winning at platform engineering are winning big. And those who are losing are making often avoidable mistakes. We’ve got an amazing community with loads of practitioners, we have courses diving into all this stuff, and all the resources you need to be rolling out a platform that your developers will love (and actually use).

You’ve just gotta do it.