9 steps to platform engineering hell

If you work in DevOps and cloud native, you might have heard that platform engineering is  a new discipline promising to fix the shortcomings of DevOps for enterprise cloud native setups. You might know that it’s focused on building internal developer platforms (IDPs) to enable developer self-service and relieve pressure on Ops teams. Your DevOps friends told you it’s the hot new thing, and if you change your title to platform engineer, you can potentially increase your pay by up to 20%.

However, while platform engineering done right can be a huge boost to your developer productivity and overall engineering velocity, platform engineering done wrong can drag you down into a whole new type of hell. And a surprising number of engineering organizations are mindlessly running full speed down this new staircase to hell. Welcome to the nine steps into platform engineering hell.

Step 1: You Rename Your (Dev)Ops Team to Platform Team But Still Do TicketOps

The hype has finally won over your organization. Management saw platform engineering on Gartner’s hype cycle, and decide to build an IDP and establish your platform engineering team. The enthusiasm is there, but unfortunately, the team composition hasn’t changed much, and are still flooded with tickets and Slack messages. They don’t have time to build a well-designed platform; they’re still just trying to survive.

Step 2: No Mindset Shift to Platform as a Product

The platform team still works with a DevOps mindset and continues to write pipelines and automation for individual product teams. They get too many requests from developers and don’t have the time or resources to zoom out and come up with a long-term strategy to build a scalable IDP and ship it as a product to the rest of the engineering organization.

Step 3: Your Platform Team Builds a Platform for Ops, Not For Developers

More platform engineers are finally hired on the team, all very experienced, with years working in operations. They come together and think hard about the biggest Ops issues they experienced during their careers. They start designing a platform to fix all those annoying issues that bugged them for years, but developers will never use this platform. It doesn’t solve their problems, it only solves Ops problems. By this time, the platform engineering initiative has burned $4 million while adoption remains at zero. 

Step 4: You Replace Old Tech with New Stuff for No Reason

Even more platform engineers are hired, all eager to start building and leveraging all the latest technologies that just popped up on the CNCF landscape. They want to replace Jenkins with GitHub Actions, all existing VMs with Kubernetes, introduce Terraform, and later replace it with Crossplane. Meanwhile, costs keep rising, and productivity continues to suffer.

Step 5: You Think Your Setup Needs to Be Special

Because every team and every organization has unique needs, custom workflows start popping up everywhere. This, in turn, requires more custom integrations on top. Meaning, one minute, you were running a straightforward setup for an average online store selling sneakers. The next, you’re deploying to a highly customized, self-managed hybrid Kubernetes setup. 

Step 6: You Build a Portal Developers Never Asked for

Someone in the platform team heard that developer self-service and portals are the new hot thing. So your team decides to put a portal on top of your existing infrastructure mess, without having ever talked to the developers, and the platform engineering team is surprised that the old “build it, and they will come” attitude doesn’t seem to work. At this point, $8 million has been burned, adoption is still zero, and productivity is free-falling.

Step 7: New Platform Engineering Silos Pop Up Everywhere

Because you’re a large enterprise with inefficient cross-unit communication, mid-management starts several platform engineering initiatives without aligning with each other. Leadership doesn’t intervene, efforts double, communication is not facilitated and gets progressively worse. You end up with five platforms for five teams, most of which don’t work at all. As for adoption? You guessed it, still at zero. And plus, you have now burned through $15 million. Congratulations!

Step 8: You Try to Hide Sunk Costs

VPs, business leaders and unit heads are getting nervous with lots of sunken costs and nowhere to hide. No one dares to say it out loud, but the truth at this stage is that most of the platform(s) would need to be replaced. It doesn’t scale, and it simply doesn’t work.

The company falls behind its competitors, but on paper, everything still looks great. This is thanks to managers who start inventing their own random metrics to make platform performance look good. By now, the few platform engineers who were actually good at their jobs have already left the company. 

Step 9: You Get Fired

So how does it all end? Not well, we can tell you. Maybe you get fired, or the company goes down and dies a slow death. Perhaps it gets acquired by a competitor. Who knows? What we do know is that none of these options are a great way to end.

Sound Dire Enough?

Sadly, we’ve seen way too many enterprises go down this route, and you might even be able to identify which step your own team is currently (and dangerously) heading toward. The good news is that it doesn’t have to be like that. Falling from one hell to the next in perpetuity doesn’t have to be your fate.

So how can you avoid it? Easy. Join the platform engineering community and learn from the mistakes and best practices of other more than 16,000 practitioners. Build your platform as a product and listen to developers. Follow Humanitec’s reference architectures to build enterprise-grade IDPs (on AWS, GCP or Azure).