{"id":4612,"date":"2025-07-10T12:17:40","date_gmt":"2025-07-10T12:17:40","guid":{"rendered":"https:\/\/www.aviator.co\/blog\/?p=4612"},"modified":"2025-10-09T13:01:02","modified_gmt":"2025-10-09T13:01:02","slug":"platform-engineering-wont-save-you","status":"publish","type":"post","link":"https:\/\/www.aviator.co\/blog\/platform-engineering-wont-save-you\/","title":{"rendered":"Platform Engineering Won’t Save You"},"content":{"rendered":"
\"Platform<\/figure>\n\n\n

Platform engineering has been labeled the evolution of DevOps, the foundation of developer productivity, the solution to delivery bottlenecks, and what could have been the hottest trend in the software industry right now, if it weren\u2019t for AI.<\/p>\n\n\n\n

But most of what\u2019s being labeled “platform engineering” today is a mix of old ideas, sometimes just with a fresh coat of paint. The official definition<\/a> of platform engineering is: <\/p>\n\n\n\n

\u201c…the discipline of designing and building toolchains and workflows that enable self-service capabilities for software engineering organizations in the cloud native era. Platform engineers provide an integrated product, most often referred to as an \u2018internal developer platform,\u2019 covering the operational necessities of the entire life cycle of an application.\u201d<\/p>\n\n\n\n

But what is platform engineering, really? <\/h2>\n\n\n\n

We\u2019ve spent years building platforms that are still used today<\/strong>, so we decided to sit down and discuss our opinions on platform engineering, including why companies fail and where we\u2019re heading in the next five years. We invite you to read this summary of our ideas and then watch the videos of our conversation embedded below. <\/p>\n\n\n\n

DevOps is Alive and Well<\/h2>\n\n\n\n

We\u2019ve lost count of how many people claim DevOps is dead<\/strong>. It\u2019s not. The definition<\/a> of DevOps is \u201cthe union of people, processes and products to enable the continuous delivery of value to our end users.\u201d Platform engineering is a very small subset of DevOps.<\/strong><\/p>\n\n\n\n

In fact, this conversation about “DevOps vs. platform engineering” is a bit of a red herring. What matters isn\u2019t the team\u2019s name, whether it is called the platform team, developer experience, engineering enablement or something entirely different. What matters is its function.<\/p>\n\n\n\n

If you\u2019re helping developers ship software with less friction<\/a>, congratulations, you\u2019re already doing some form of platform engineering. At its core, platform engineering is simple: It\u2019s about developers building tools for other developers to make it easier for them to do their jobs.

Platform engineering, or whatever we call it, means asking ourselves every day:<\/p>\n\n\n\n

\n

How do I make it really easy for developers to do their work and really difficult for them to make mistakes?<\/p>\n<\/blockquote>\n\n\n\n

That sounds straightforward, but it\u2019s not. Because making things easy and mistake-proof at the same time is conflicting. <\/p>\n\n\n\n

We\u2019re Not Building a Platform. We\u2019re Building a Product.<\/h2>\n\n\n\n

What matters is this: Are developers\u2019 jobs better now than before the platform team existed?<\/strong> If the platform team can\u2019t answer that with confidence, the platform is not delivering. Do we track whether developers’ lives have improved since we started?  Do we know why our team exists? If the reason is \u201cto improve the tooling we built last year,\u201d that\u2019s not enough.

This is where most organizations fall flat: they don\u2019t treat the platform like a real product. And that’s exactly what it is.<\/p>\n\n\n\n

Internal platforms are products with real customers: our developers<\/strong>. If we wouldn\u2019t ship a half-baked feature to an external user, why would we think it’s fine to push a set of tools on developers and require their use, whether they know how to \u2014 or even need those tools at all?<\/p>\n\n\n\n

\n

Platform teams need product management, customer feedback, usage telemetry and maybe even \u2014 brace yourself \u2014 internal marketing.<\/p>\n<\/blockquote>\n\n\n\n

Yes, marketing. Even Angry Birds needed marketing! <\/p>\n\n\n\n

When we worked on the platform team, we gave out T-shirts and stickers, ran lunch and learns, and did internal roadshows. We were very transparent with our intentions, open to feedback and very much part of the community. The platform team can\u2019t exist in an ivory tower, just tossing out instructions to everyone. <\/p>\n\n\n\n

\n