Platform engineering is the discipline of designing and building tooling and infrastructure that reduces cognitive load on software development teams. Instead of every development team managing their own CI/CD pipelines, security scanning, deployment processes, and observability setup, a platform engineering team builds shared infrastructure that gives developers a standardised, self-service way to deploy and operate their applications.
The goal is not to centralise control. It is to move complexity off development teams so they can focus on building product rather than managing infrastructure.
Gartner predicted that by 2026, 80% of large software engineering organisations would have established platform engineering teams. The CNCF Platform Engineering Maturity Model documents adoption patterns from the cloud-native community. ThoughtWorks has featured platform engineering as a key trend in multiple Technology Radar editions. The discipline is no longer emerging. The question is not whether to invest in platform engineering. It is how to do it well.
For a broader view of how platform engineering connects to engineering operations strategy, the Engineering Operations Guide covers the full picture. This guide focuses specifically on platform engineering: what it is, how to build it, and how to measure whether it is working.
The problem platform engineering solves
In a growing engineering organisation, there is a predictable pattern. Five development teams each build their own CI/CD pipeline. They make different choices: different tools, different security configurations, different deployment patterns. When a new engineer joins, they have to learn whichever setup their team uses. When a security vulnerability surfaces in a base image, five teams fix it separately. When someone wants to understand how the whole system deploys, there is no single answer.
This is the cognitive load and fragmentation problem that platform engineering addresses. The term cognitive load in this context comes from Team Topologies (Skelton and Pais, 2019), which identified three types: intrinsic (inherent to the work), extraneous (unnecessary overhead), and germane (building understanding). Platform engineering reduces extraneous cognitive load: the overhead of managing infrastructure that is not differentiating work for the teams carrying it.
The DORA State of DevOps research consistently shows that teams with good tooling and infrastructure that reduces toil show higher deployment frequency and lower change failure rates. Platform engineering is the organisational mechanism for delivering those conditions at scale.
What an internal developer platform is
An internal developer platform (IDP) is the product that a platform engineering team builds and maintains. It sits between the underlying infrastructure (cloud providers, Kubernetes clusters, security tooling) and the development teams, providing a self-service interface for the most common development operations: deploying a service, creating a new repository with standard configuration, setting up monitoring for a new component, or running a security scan.
The defining characteristic of an IDP is self-service. A developer can do what they need to do without filing a ticket, waiting for the platform team to respond, or learning the details of the underlying system. The platform team's job is to make the right thing the easy thing.
The most widely adopted open-source IDP framework is Backstage, originally built by Spotify and donated to the CNCF. Backstage provides a software catalog, a developer portal, and a plugin system for integrating with existing tools. It is not the only approach, but it is the starting point for most mature IDP implementations.
Golden paths and paved roads
A golden path (also called a paved road) is a pre-built, opinionated workflow for a common development task. The platform team builds it, validates it, secures it, and makes it available as a self-service option. Development teams use it instead of building their own approach from scratch.
A golden path for deploying a new microservice might include:
- A service template with standard directory structure and configuration
- A pre-configured CI/CD pipeline with security scanning already integrated
- Default observability setup (metrics, logging, tracing) pre-wired to the organisation's monitoring stack
- Infrastructure-as-code templates for the most common deployment patterns
- A documented runbook template for incident response
The critical design principle: golden paths must be genuinely faster and easier than the alternative. If a developer can get a new service running in 20 minutes using the golden path but navigating the IDP takes 45 minutes, they will route around the platform. Adoption rate is the primary signal that a platform is delivering value.
Platform engineering team topology
Team Topologies defines four fundamental team types: stream-aligned teams (building product), enabling teams (helping others adopt new practices), complicated-subsystem teams (owning specialist components), and platform teams. Platform teams exist to reduce cognitive load on stream-aligned teams by owning the infrastructure and tooling complexity.
The relationship between a platform team and the development teams it serves is explicitly defined as a product relationship: the platform is a product, the development teams are its customers, and the platform team's job is to make its customers more productive.
The most common mistakes in platform team structure:
- Treating the platform team as an infra ticket queue. If the platform team exists to process requests, it is a bottleneck, not a platform. The output should be self-service capabilities, not completed requests.
- Building for the platform team's preferences rather than developer needs. Platform tooling that reflects what the platform engineers find interesting, rather than what development teams need, sees low adoption.
- Under-resourcing platform teams. Three platform engineers serving 50 development teams cannot build and maintain a platform that meaningfully reduces developer toil. The ratio needs to make the platform team's commitments achievable.
The CNCF Platform Engineering Maturity Model
The CNCF Platform Engineering Maturity Model defines four maturity levels: Provisional (ad-hoc, individual tooling decisions), Operational (basic shared tooling with manual processes), Scalable (self-service tooling with automation), and Optimising (platform as a product, with feedback loops and continuous improvement).
Most engineering organisations between 50 and 200 engineers are at Provisional or Operational. The transition to Scalable is where most of the value is captured. It typically requires three things: a dedicated platform team, a defined IDP (even a simple one), and a feedback mechanism for development teams to influence platform priorities.
Moving from Provisional to Operational in one meaningful capability (standardising CI/CD pipelines across all teams, for example) delivers more value than making small incremental improvements across many capabilities simultaneously. Depth before breadth.
How platform engineering improves DORA metrics
Platform engineering creates the conditions that make DORA metric improvement possible at scale. A development team working in isolation can improve its own deployment frequency. A platform engineering team can raise the deployment frequency floor across every team it serves.
Deployment Frequency: Standardised CI/CD pipelines with integrated security testing mean every team has a production-ready pipeline by default. Teams using golden paths typically reach deployment frequency targets faster than teams managing their own pipelines, because the bottlenecks (security gates, environment setup, configuration) are solved once and shared.
Lead Time for Changes: Self-service deployment, pre-approved infrastructure templates, and automated compliance documentation reduce the time between a code commit and a production deployment. Teams on a mature IDP tend to have shorter lead times than teams without one because the non-development work in the pipeline is automated rather than manual.
Change Failure Rate: Consistent testing standards, pre-validated infrastructure configurations, and platform-managed base images (updated centrally) reduce the surface area for deployment failures. When every team deploys the same way, failure patterns are easier to identify and fix platform-wide.
Mean Time to Restore: Centralised observability, shared runbook templates, and platform-managed rollback capabilities reduce time to detect, diagnose, and restore. Teams using a common observability stack can share incident context across services in a way that teams using different monitoring tools cannot.
For the full DORA metrics framework including benchmarks and improvement strategies, see the DORA Metrics Guide.
Dev toolchain unification
Toolchain fragmentation is the problem platform engineering addresses most visibly. In organisations that grew quickly or through acquisition, the typical situation: some teams use GitHub, some GitLab, some Bitbucket. Some deploy to AWS, some to GCP. Some use Datadog for observability, some use Grafana, some have nothing. Each team made reasonable decisions in context. The accumulated result is a toolchain that no single person fully understands.
The platform engineering response is not to force standardisation across everything at once. It is to standardise the interfaces that development teams interact with most frequently, and let the underlying tooling converge over time.
The IDP layer becomes the consistent interface: regardless of where a service runs or which monitoring tool a team uses, developers interact with the same portal, the same deployment workflow, and the same observability views. Standardisation at the interface layer is far less disruptive than standardisation at the infrastructure layer, and it delivers most of the cognitive load benefit.
The priority order for toolchain unification typically follows developer interaction frequency: CI/CD (every commit) before infrastructure management (every deployment) before observability (every incident) before everything else. Start where developers spend the most time.
Platform engineering and engineering intelligence
A mature platform engineering function needs visibility into whether the platform is actually delivering value. The metrics that tell you whether the platform is working are the same metrics that measure engineering delivery performance overall.
The Scrums.com engineering intelligence platform tracks DORA metrics, deployment frequency, cycle time, and change failure rate across teams. For platform engineering teams, it provides the measurement layer to answer: are the teams on our golden paths outperforming teams that are not? Is platform adoption correlated with better delivery metrics? Which parts of the platform are delivering measurable value?
Without this measurement layer, platform engineering investment is difficult to justify and difficult to prioritise. With it, platform teams have the data to make the case for the next capability, retire what is not being used, and demonstrate impact in terms engineering leaders and executives care about.
Where to start
Most platform engineering programmes that fail do so because they tried to build the entire IDP before delivering any value. The teams that succeed follow a narrower starting point and expand from there.
- Map the top five sources of developer toil. Run a developer survey or structured interviews. Ask: what takes longer than it should? What do you do repeatedly that should be automated? What decisions do you make every project that should have a standard answer? The answers give you the starting point for golden path development.
- Standardise CI/CD for one team first. Pick the most receptive team, build a standardised pipeline with security scanning and compliance documentation, and measure before and after. This creates a proof of concept, a reference implementation, and champions inside the engineering organisation before you scale.
- Build a minimum viable IDP. A minimal IDP might be a Backstage instance with a software catalog and one or two golden paths. It does not need to cover everything. It needs to be genuinely useful to the teams who use it, and it needs a feedback mechanism so you know what to build next.
- Establish DORA metric baselines for teams on and off the platform. You need this data to justify continued investment and prioritise which capabilities to build next. Teams on the platform should show improving metrics over time. If they do not, the platform is not solving the right problems.
- Treat the platform as a product. Run regular developer satisfaction surveys. Maintain a public roadmap that reflects developer priorities. Measure adoption of each golden path and retire the ones that are not used. The platform team's success metric is whether development teams choose to use the platform, not whether the platform exists.
Frequently asked questions
What is platform engineering?
Platform engineering is the discipline of designing and building internal developer platforms (IDPs) that reduce cognitive load on development teams by centralising toolchain complexity. A platform engineering team owns the infrastructure, CI/CD pipelines, security tooling, and observability stack so developers can deploy and operate services without needing deep expertise in every underlying system.
What is an internal developer platform?
An internal developer platform (IDP) is a self-service layer built on top of infrastructure and tooling that gives developers a standardised way to deploy, manage, and monitor their applications. It abstracts the complexity of Kubernetes, cloud infrastructure, CI/CD configuration, and security policy so developers interact with a consistent interface. Backstage (originally by Spotify, now CNCF) is the most widely adopted open-source IDP framework.
What is the difference between platform engineering and DevOps?
DevOps is a cultural and organisational philosophy that breaks down silos between development and operations. Platform engineering is a specific implementation pattern where a dedicated team builds shared tooling that makes DevOps practices accessible to all development teams at scale. Platform engineering operationalises DevOps by providing the golden paths, templates, and automation that make good practices the easy default.
How does platform engineering improve DORA metrics?
Platform engineering improves all four DORA metrics. Standardised CI/CD pipelines and golden paths increase Deployment Frequency. Automated security testing and self-service deployment reduce Lead Time for Changes. Consistent testing standards and pre-validated infrastructure reduce Change Failure Rate. Centralised observability and automated rollback reduce Mean Time to Restore.
What is a golden path in platform engineering?
A golden path is a pre-built, opinionated workflow for a common development task that a platform team has validated, secured, and made available as a self-service option. A golden path for deploying a new microservice might include a service template, a pre-configured CI/CD pipeline, default observability setup, and security scanning already integrated. Developers use the golden path instead of configuring each component themselves.
How do you measure whether platform engineering is working?
The primary measures are the DORA metrics tracked across the teams the platform serves: Deployment Frequency, Lead Time for Changes, Change Failure Rate, and Mean Time to Restore. Secondary measures include platform adoption rate (what percentage of teams use golden paths versus custom tooling), time to first deployment for new services, and developer satisfaction scores.
