How platform engineering became a discipline

Much has been written about platform engineering but few know how it actually evolved. We’ve been in the incredibly rewarding situation of having had a front row seat to it all. This is the untold story of how we learned platform engineering the hard way by rolling out platforms in the trenches and later generalized our learnings to form a discipline. 

With the dawn of cloud computing,  elite teams at Netflix, Google, and Spotify quickly learned that just handing out cloud accounts to developers does more harm than good. They soon realised the need to build internal products to structure their development workflows. At that point there was no shared language, no transferable methodology, and certainly no playbook for the rest of us. The practices existed in isolated pockets, the discipline however did not.

We've spent the last eight years in the trenches, rolling out production platforms across Fortune 50 companies, government entities, and enterprises spanning pretty much any industry you could think of from mining to manufacturing and  telco to finance. From Silicon Valley to Ulaanbaatar. There were no frameworks to follow. Every implementation was first-principles problem-solving where failure had real consequences: delayed product launches, security breaches, millions in wasted infrastructure spend, or teams simply routing around the platform entirely.

Eventually, we'd solved the same problems enough times that patterns emerged. We stepped back, codified what actually worked in production, and built the infrastructure to transfer that knowledge at scale. That's how a practice became a discipline.

Something was in the air

By 2018, the seeds were everywhere. Manuel Pais and Matthew Skelton were writing Team Topologies, articulating how team structures and cognitive load shaped software delivery. DevOps practitioners were grappling with the tension between autonomy and standardization. Site Reliability Engineers at Google had proven that you could operate at massive scale with the right abstractions. Cloud providers were making infrastructure programmable in ways that fundamentally changed what was possible.

The ideas were circulating, but they were fragmented. The situation we found ourselves in, almost by accident, was rare. The products we had developed were used to build these early internal platforms. And because our customers needed help rolling them out, we found ourselves building platforms with and for them, in wildly different contexts. 

Out of pure interest to share and learn from others (And as a bit of  a side quest), the Platform Engineering Community was started. What began as a way to share knowledge and ask questions with other practitioners has since become a true, and global community of over 270,000+ people. Their titles may be different, but their work is that of the “platform engineer”. 

Both happened almost by coincidence and suddenly we had the implementations, the scar tissue from dozens of large-scale rollouts, and the community data from surveys, conversations, and case studies flowing in from every corner of the industry.

We're deeply grateful for that confluence. It gave us the opportunity to do something that isolated teams could have never done alone: look across contexts and identify what was universal versus what was specific. To move from "this worked for us" to "this is why it worked, and here's how to adapt it."

Learning the hard way

The early implementations were brutal. We made mistakes, shipped things that didn't get adopted, built interfaces that users hated, and learned the hard way which abstractions were actually helpful versus which ones just obscured complexity without removing it. But each failure taught us something that couldn't be learned from the sidelines.

We realized quickly that organizations were drowning in cognitive load. Engineers spent more time navigating tribal knowledge, waiting for tickets, and coordinating across silos than actually building features. Every team reinvented solutions to the same infrastructure problems. Maintenance costs exploded as bespoke setups accumulated. Onboarding new engineers took months because nothing was standardized.

After enough implementations we started experiencing déjà vu. The European defense contractor, the mining operation in Australia, the regulated and afraid government entity, the  telecom provider operating in challenging infrastructure conditions: they all kept running into the same issues. The surface details were different, but the underlying dynamics were identical. We weren't looking at dozens of unique problems. We were looking at one problem with local variations, the absence of a designed production system.

The platforms that succeeded all did similar things, regardless of industry or scale. They provided standardized execution paths that worked reliably. They externalized knowledge from individuals into tooling and documentation. They created explicit interfaces between specialized teams rather than ad-hoc coordination. They built system-level reliability so individual failures didn't cascade. They enabled a non-linear scale where improvements benefited everyone.

When we realized these patterns, we started codifying them. Not as theoretical frameworks, but as things that could actually help us in our day to day to make the people we serve more successful. The methods and approaches we came up with had to hold up in reality, they couldn’t be things that look great on paper. 

So we went to work coining the defining terms ("Internal Developer Platform" for instance was coined in our small Berlin office on a therapeutics chair). To describe what these systems actually were, we documented golden paths, we built defining reference architectures that captured what we were seeing work across contexts.  Those reference have since been downloaded over 100,000 times. The primary image seen by over 4 million people. More than the visual aid, the language mattered. It allowed practitioners to talk about what they were building in ways that transcended their specific tool choices or organizational structures.

From practice to discipline

By the time we launched PlatformCon, which has since become the largest conference in the industry, something had shifted. The demand for platform engineering expertise far exceeded the supply of people who'd actually built platforms in production. Organizations were hiring "platform engineers" who'd read blog posts but never made a golden path work under real constraints.

But pattern-matching without understanding the underlying principles is dangerous. You can copy the structure of a golden path without grasping the subtle design choices that make it actually useful versus just another abstraction layer. You can implement a developer portal without understanding how to design interfaces that blend into engineers' existing workflows rather than creating yet another place they're forced to visit.

We'd accumulated enough knowledge from real implementations that we could teach not just what to build, but why certain approaches worked and others didn't. So we built Platform Engineering University to systematize that knowledge transfer. Over 2,000 practitioners have now been certified in methodology that's been validated across hundreds of production rollouts. And over 10,000 have taken a specialized course on an area of platform engineering. We became one of the largest entities globally delivering training and advisory in the space, not because we set out to build a training empire, but because the gap between demand and expertise was so enormous.

The community data kept flowing in, refining our understanding. We could see which patterns held across industries and which were context-specific. We could identify failure modes before organizations hit them. We built analytical and research capabilities to continuously validate and evolve the frameworks. Each new implementation fed back into the methodology, each cohort of practitioners brought new edge cases, each survey revealed where the discipline was maturing and where gaps remained.

What emerged was something bigger than any single organization or implementation. Platform engineering became a proper discipline with shared language, proven patterns, certification standards, and a global community of practice. The reference architectures, the mental models, the design principles that guide platform work today, much of that foundational work emerged from this ecosystem.

What’s next

Platform engineering is no longer a niche practice at elite tech companies. It's becoming the operating system of the modern enterprise. As organizations move into the AI-native era, platform engineering has emerged as the fundamental layer for AI's success in the enterprise, because AI agents need the same reliable, standardized interfaces that human engineers do, perhaps even more so.

The discipline has also expanded far beyond its origins in application development. Security, observability, data engineering, FinOps, compliance, all of these are being absorbed into platforms with standardized workflows. The platform engineers now find themselves responsible not just for developer experience, but for entire pillars of enterprise IT.
The patterns are proven. The methodology is battle-tested across industries and scales. The community is mature and global. The question now isn't whether platform engineering matters, but how organizations adapt it to their specific contexts and how the discipline continues to evolve as the demands on it grow.

After all these years we realized the responsibility we shoulder was getting too big to run a pure “community” operation. We had to level up how we analyse the space and provide impact and insights that continue to serve platform engineers of all colours well. 

This is what we are doing with Weave Intelligence, a research analyst for the era of platform engineering. We’re excited about where this all goes from here and delighted to serve you on your journey. The work of turning practices into disciplines is never finished. It just moves to the next frontier.