The evolution of platform engineering

Looking back: The landscape in 2018

To appreciate how much DevOps and platform engineering have evolved, it’s helpful to set the scene in 2018 — a moment that, though not so long ago, feels like a different era in technology.

Outside the world of software, 2018 was a year of momentous shifts: the launch of 5G, the implementation of GDPR across the EU, Tesla’s leadership dramas, the rise and fall of cryptocurrency darlings and Microsoft’s acquisition of GitHub. For many, 2018 was also the year when printing metal with 3D printers became a reality and virtual reality was inching its way into the mainstream.

Inside the world of software, though, a quieter revolution was underway. DevOps, once more of a cultural idea than a discipline, was beginning to crystallize into a codified engineering practice. Influenced by the publication of The Phoenix Project by Gene Kim, Kevin Behr and George Spafford — and books like Continuous Delivery from Jez Humble and Dave Farley — DevOps matured from a set of disruptor techniques into the backbone of modern software delivery.

What changed? The industry moved past theory. Organizations became serious about flattening silos, visualizing value streams and finding friction points in their delivery pipelines. These weren’t just ideas — they made a huge difference for teams on the ground.

Real world DevOps: Automation in aerospace

Let’s talk about what this looked like in practice.

Back in 2018, I worked for a large US defense contractor, responsible for managing the software platform that supported multiple drone types — each with its own quirks and complexities. The deployment process was excruciatingly manual and paper-driven: teams navigated binders full of installation manuals, SSH’d into terminals, installed packages by hand and hoped that network connections to update servers didn’t fail.

The goal was to turn around a grounded drone in 14 days or less. In reality, it was often 30, 50 or even 60 days before everything was done and the drone could fly again. This was the opposite of agility.

But as DevOps thinking started to blossom, we asked a simple question: what if we automated the code build, test and deployment with CI/CD pipelines and configuration tools like Ansible and Puppet?

It wasn’t smooth sailing at first. We wrangled unusual languages, open-source tools (to save on license costs) and sometimes ran up against sheer organizational inertia. But the results spoke volumes: over a year and a half, turnaround time dropped from weeks to under 24 hours — a sea change in operational capability.

However, this automation tsunami brought new problems: pipeline sprawl. We ended up with 900+ self-hosted Jenkins runners, each its own snowflake. The next challenge was consolidation — giving power and autonomy to developers without losing control or drowning in operational complexity.

The birth of platform engineering

It was around this time that the seeds of platform engineering were being sown — at ThoughtWorks and across the industry. Inspired by conversations with folks like Martin Fowler and by ThoughtWorks’ own Evan Bottcher (whose 2018 article became a touchstone), we started thinking about what makes a good platform.

Four core principles stood out:
 

• A compelling internal product: The platform itself must be genuinely useful and appealing to its internal users.
   

• Autonomous delivery teams: Developers should be able to build and ship with minimal handoffs — a move away from “ticket ops” culture toward real self-service.
   

• Reduced coordination: The platform should reduce the friction and overhead of cross-team coordination, not increase it.
   

• Outcomes over outputs: The focus is not just on what the platform provides, but on how it accelerates business outcomes.
   

In other words: platform engineering wasn’t about spinning up shiny new internal portals or collecting tools for their own sake. It was about delivering real leverage for delivery teams, helping them move faster, more safely and with greater autonomy.
 

Key shifts since 2018: Four pillars of change
 

So what’s changed since 2018? Here are four major shifts that have defined the new era of platform engineering:
 

1. Self-service has evolved (again)
 

Remember when the front door to IT was a ticket queue? Need a GitHub repository, a bit of infrastructure or a test environment? Fill out a Jira or ServiceNow ticket and wait.
 

Today, the expectation is for genuine self-service — where developers (and sometimes other stakeholders) can discover, request and provision the resources they need instantly, using well-designed APIs and interfaces.

But there’s a vital nuance here: self-service should be specifically for tasks like onboarding, infrastructure provisioning and basic service requests. Incidents and feedback are still best handled in ITSM tools.

2. Product thinking for platforms has taken center stage

For too long, platform initiatives were project-led: build a new Java starter, add some pipeline templates, create a Terraform library — then hope developers glue it all together.

Now, leading organizations organize their platforms by “jobs to be done.” They provide bundles of capability that hang together as coherent product offerings. Instead of piecemeal tools, they offer integrated experiences — “here’s everything you need to deploy a Java app to production, tested, observed and compliant.”

Crucially, these capabilities come with Service Level Objectives (SLOs) and Service Level Agreements (SLAs) baked in. Developers can trust that if they adopt the platform, they get real guarantees about what will happen and when. This is the heart of product thinking: aligning the platform’s capabilities with developer needs and business outcomes, measured and managed just as with any customer-facing product. 

For more on how meaningful metrics can can drive significant outcomes in software engineering, don’t miss our “Software engineering metrics that matter" on-demand webinar. 

3. Operating models are more business-driven

Initially, many organizations let platform teams drive operating models in isolation, often over-standardizing and dictating approaches in a command-and-control fashion.

Now, more mature organizations flip this model: the business goals drive platform design, not the other way around. Is the enterprise a conglomerate of units that need coordination (like a retailer with supply chain, POS and customer experience teams)? Or is it a single, focused operation (like an airline)? Or is the business replicating a model at scale (like a hotel chain)?

The amount of standardization, autonomy, harmonization and integration the platform provides should be dictated by the business context and desired outcomes — not by abstract architectural ideals.

A key insight here: harmonization doesn’t mean lock-in — it means providing the pavement and guardrails so product teams can move fast with the confidence of support and guidance.

4. The developer success model

As platforms increasingly resemble internal SaaS products, many organizations are embracing “developer success teams.” Like a vendor’s customer success organization, these teams actively engage with internal developers, smoothing onboarding, gathering feedback and ensuring the platform’s capabilities continually meet evolving needs.

Just as Salesforce wants stickiness with its enterprise customers, a successful platform team wants stickiness with its engineers. This transition is cultural as much as it is technical.

The challenge of scale: Legacy, M&A and platform sprawl

No discussion of platform engineering is complete without grappling with the reality of legacy systems, mergers and acquisitions. Most enterprises, even fast-growing startups, eventually face the challenge: after a merger or acquisition, two (or more) beloved platforms must coexist. A “rip and replace” approach is rarely wise — or feasible.

It’s okay to run multiple platforms in parallel as you carefully migrate teams and capabilities, provided you’re intentional about the process and make steady progress. Platform consolidation journeys often take years. The key is not to rush — measure twice, cut once and keep the focus on delivering value throughout.

Case study: Experimentation as a gateway to platform maturity

Here’s a concrete example from airline clients: Product teams often complain that platform teams are slow to adopt new tools or frameworks. Sometimes, impatient teams spin up “shadow IT,” building their own ‘mini-platforms’ outside the collective standard.

Rather than resisting this entirely, mature platform organizations create safe “sandboxes” for experimentation. If, for instance, a team wants to adopt Gradle over Ant for builds, the platform team lends support, evaluates outcomes and — if it works — extracts and hardens the new capability for wider use. This collaborative model allows innovation to bubble up, shortens implementation timelines (sometimes by months) and keeps everyone moving in the same direction.

The ever-changing technology landscape

The technology toolkit has exploded. In 2018, the Cloud Native Computing Foundation (CNCF) had around 40 projects under its umbrella. Today, that number exceeds 250, creating opportunities and headaches in equal measure. Wise platform teams carefully curate their stack based on real needs — not hype — and resist the urge to adopt new technologies for novelty’s sake.

The next frontier: AI-infused platforms

Looking ahead, a major “elephant in the room” is the integration of AI into the platform experience itself. The way developers interact with platforms is poised to change — from code and APIs to conversational interfaces, visual workflow designers and even prompt-driven interaction.

The challenge (and the opportunity) is to make the experience layer of the platform radically more accessible and adaptive, so capability is at everyone’s fingertips — not just the highly technical.

Wrapping up: Lessons learned

Platform engineering has grown from a scrappy movement rebelling against ticket-driven ops to a sophisticated discipline centered on product management, developer experience and business alignment.

A few key takeaways:

• Automation is only the starting point. True transformation happens when you treat the platform as an internal product, obsess over developer outcomes and build trust across teams.
• Self-service, standardization, and experimentation aren’t opposing forces; they’re all critical to scaling delivery in the enterprise.
• The operating model must be driven by what the business is trying to accomplish — not by architectural dogma.
• Continuous feedback — through structures like developer success teams and experimentation sandboxes — keeps the platform relevant and sticky.
• Finally, the ground is always shifting. From ticket queues to AI-driven interfaces, the goal remains the same: help teams build and deliver value faster, safer and with confidence.

As we look to the future, the core lesson is simple: platform engineering is never “done.” It’s a living, evolving ecosystem. The more we embrace change, listen deeply to our users and remain ruthlessly focused on outcomes, the more enduring our platforms — and our organizations — will become.

This blog is based on Rickey's keynote from PlatformCon 2025, 'Platform engineering's coming of age - Lessons from 2018 to 2025.'