How the shift towards internal developer platforms is revolutionizing software delivery velocity and reliability.
The DevOps Fatigue Problem
The DevOps movement gave us CI/CD pipelines, infrastructure-as-code, and shared ownership of the production system. It was a revolution in software delivery. But as organisations scaled, a new problem emerged: the cognitive burden placed on individual developers became unsustainable. Every engineer was expected to be an expert in Docker, Kubernetes, Terraform, Prometheus, and a dozen other infrastructure tools in addition to their core domain expertise. This led to what industry analysts began calling 'DevOps fatigue.'
What Platform Engineering Solves
Platform engineering is the organisational discipline of building and maintaining an 'Internal Developer Platform' (IDP) — a curated set of self-service tools, templates, and workflows that abstract away infrastructure complexity and allow product engineers to focus on writing business logic.
An IDP typically provides: a service catalogue (we use Backstage) with golden path templates for creating new services, a self-service environment provisioning system, a standardised observability stack pre-wired to every new service, and an automated compliance scanning pipeline integrated into the CI/CD flow. The result is an engineer who can go from idea to production-ready service in hours, not days.
The Golden Path and Paved Roads
The central concept in platform engineering is the 'golden path' — an opinionated, well-maintained set of tools and practices that the platform team recommends for the most common use cases. The golden path is not a mandate; engineers can deviate from it for legitimate technical reasons. But it is the path of least resistance, and it encodes the organisation's accumulated knowledge about how to build reliable, secure, observable services.
Paved roads extend from the golden path to accommodate the legitimate edge cases. A team building a high-performance data processing pipeline might need to deviate from the standard web service template. The platform team works with them to build a paved road variant that still maintains the security and observability standards while accommodating their specific requirements.
Measuring Developer Experience
Platform teams must quantify their impact to justify investment. The DORA metrics (Deployment Frequency, Lead Time for Change, Mean Time to Recovery, Change Failure Rate) provide the standard framework. A mature platform engineering function should be driving deployment frequency towards multiple times per day, lead time towards under an hour, and MTTR towards under an hour.
Beyond DORA, we recommend collecting qualitative feedback via regular developer experience surveys (the SPACE framework provides a useful structure) and tracking platform adoption metrics — what proportion of new services use the golden path, what is the ticket volume to the platform team, and what is the time-to-onboarding for a new engineer.
Building the Platform Team
The platform team should be staffed with engineers who have both strong infrastructure expertise and a product mindset. They are building a product — their customers are the other engineering teams. They need to run a backlog prioritisation process, do user research (talking to the engineers who use their platform), and make product decisions with limited resources.
A common mistake is staffing the platform team entirely with infrastructure specialists who are disinclined toward the product and empathy work that makes a platform truly excellent. The best platform engineers are generalists who care deeply about developer happiness.
