Two teams in the same industry, building similar products, with similar headcount, can have wildly different delivery capability. One ships a code change to production in under an hour and knows within minutes if something breaks. The other ships once a month, through a change advisory board, and takes a week to diagnose a production incident when one occurs.
The difference is rarely talent. It is almost always the maturity of the software delivery system the team operates inside — the practices, automation, and platform that sit between "code is written" and "code is running safely in front of customers."
That system has a name: DevOps. And the discipline now emerging to make it scale across hundreds of teams rather than one high-performing team has a name too: platform engineering.
What DevOps Actually Is
DevOps is frequently reduced to tooling — a CI/CD pipeline, a Kubernetes cluster, a set of dashboards. The tooling is real, but it is downstream of the actual definition. DevOps is the cultural and technical practice of unifying software development and IT operations so that the people who build software and the people who run it share responsibility for its outcome, supported by automation that removes manual handoffs from the path to production.
The handoff is the enemy. Every manual handoff between a developer, a QA team, a change board, and an operations team is a queue, and queues are where lead time goes to die. DevOps practice systematically removes handoffs by automating what can be automated (build, test, security scanning, deployment) and by giving the team that writes the code the ownership and tooling to run it.
The Core Practices
Continuous Integration. Every developer merges code into a shared branch multiple times a day, with an automated build and test suite validating each merge. This surfaces integration problems in minutes rather than at the end of a release cycle, when they are exponentially more expensive to fix.
Continuous Delivery / Deployment. Every change that passes automated testing is automatically packaged into a releasable artifact (continuous delivery) or automatically deployed to production (continuous deployment). The distinction matters less than the underlying capability: the organisation can release at will, not on a quarterly train.
Infrastructure as Code. Infrastructure is defined in version-controlled configuration (Terraform, Pulumi, CloudFormation) rather than provisioned by hand. This makes environments reproducible, changes reviewable, and drift detectable — the same discipline applied to application code, applied to the infrastructure underneath it.
Observability, not just monitoring. Elite teams instrument systems so that when something goes wrong, they can ask arbitrary questions about why — not just check whether a predefined dashboard is red or green. This is what makes sub-hour MTTR possible at scale.
The DevOps Maturity Model
Most frameworks describe DevOps maturity across four stages, and it is useful for IT leaders to know which stage their organisation actually occupies, as opposed to which stage they believe they occupy.
Stage 1 — Ad hoc. Deployments are manual, infrequent, and treated as high-risk events requiring a dedicated window and a war room. Testing is largely manual. Infrastructure is provisioned by hand and configuration drifts silently between environments.
Stage 2 — Managed. Basic CI exists. Builds are automated, but deployment still requires manual steps and sign-off. Some infrastructure is scripted, but not consistently version-controlled. Incident response is reactive.
Stage 3 — Defined. CI/CD pipelines are standardised across most teams. Infrastructure as code is the default. Deployment frequency increases to weekly or better. Observability tooling exists and is used, though often only by a central platform or SRE team rather than by every engineer.
Stage 4 — Optimising. Deployment is fully automated with progressive rollout (canary or blue-green) and automated rollback on failure signal. Every engineer has self-service access to deploy, observe, and roll back their own service. Platform engineering has industrialised the golden path so that new teams inherit this capability on day one rather than building it themselves.
The jump from Stage 2 to Stage 3 is where most enterprise transformation budget is spent. The jump from Stage 3 to Stage 4 is where platform engineering becomes the determining factor.
The Four DORA Metrics
The DevOps Research and Assessment programme, now part of Google Cloud, has spent over a decade identifying which delivery metrics actually correlate with organisational performance — not vanity metrics, but the four that predict commercial outcomes. Every IT leader responsible for software delivery should know these four numbers for their organisation, cold.
| Metric | What it measures | Elite performers | Low performers |
|---|---|---|---|
| Deployment frequency | How often code ships to production | Multiple times per day | Fewer than once per month |
| Lead time for changes | Time from commit to running in production | Less than one hour | One to six months |
| Change failure rate | Percentage of deployments causing a production failure | 0–15% | 46–60% |
| Time to restore service (MTTR) | Time to recover from a production incident | Less than one hour | One week to one month |
The pattern that matters most for IT leaders: these four metrics move together. Organisations that deploy more frequently do not have higher failure rates — they have lower ones, because smaller, more frequent changes are inherently easier to reason about and roll back than large, infrequent ones. Speed and stability are not a trade-off in mature DevOps practice. They are the same underlying capability, measured two ways.
Platform Engineering — Productising the Golden Path
Platform engineering is the discipline that emerged once organisations tried to scale Stage 4 DevOps practice from one elite team to every team in the enterprise, and discovered that asking every team to build its own CI/CD pipeline, provisioning workflow, and observability stack does not scale — it multiplies cost and inconsistency instead of removing it.
The platform engineering answer is to build an Internal Developer Platform (IDP): a self-service layer, owned by a dedicated platform team, that gives every engineer a "golden path" — a paved, opinionated, pre-approved way to provision infrastructure, deploy a service, and get observability for it, without needing to become an infrastructure expert or file a ticket with a central operations team.
Done well, an IDP treats developer experience as a product with its own users (internal engineers), its own roadmap, and its own success metrics — typically time-to-first-deploy for a new service and the percentage of teams using the golden path versus building their own bespoke tooling. Done poorly, it becomes another centralised bottleneck wearing a self-service label.
Vendor Landscape — Internal Developer Platforms
| Platform | Model | Strength | Best for |
|---|---|---|---|
| Backstage | Open source (CNCF) | Service catalog, plugin ecosystem | Organisations with platform engineering capacity to build on top of it |
| Port | SaaS | Fast time-to-value, low-code portal builder | Mid-size to large enterprises wanting a catalog + workflows quickly |
| Cortex | SaaS | Scorecards, service maturity tracking | Organisations prioritising engineering standards and accountability |
| Humanitec | SaaS | Deployment orchestration, environment automation | Platform teams focused on the provisioning and deploy layer specifically |
| OpsLevel | SaaS | Service catalog, maturity scorecards | Organisations wanting Cortex-like capability with strong integration breadth |
Backstage remains the default starting point for large organisations because of its open-source flexibility and the fact that it originated at Spotify solving exactly this problem at scale — but it requires real platform engineering investment to configure and maintain. The SaaS alternatives trade some of that flexibility for materially faster time-to-value, which is often the right trade for organisations earlier in their platform engineering journey.
What to Do Next
Three questions that reveal DevOps and platform engineering maturity in any organisation:
1. Can a developer deploy a code change to production without filing a ticket or waiting for another team? If the answer is no, the organisation has a process bottleneck that no amount of additional CI/CD tooling will fix on its own — the constraint is organisational, not technical.
2. Do you know your organisation's actual deployment frequency and change failure rate, or only believe you know them? Most organisations that have not instrumented DORA metrics directly overestimate their delivery performance significantly.
3. If a new engineering team joined tomorrow, how long would it take them to have a service running in production with proper observability? In organisations with a mature internal developer platform, this is hours. In organisations without one, it is frequently measured in months — and that gap is rebuilt, team by team, at enormous and invisible cost.
The next post in this category covers Low-Code/No-Code & Citizen Development — the layer where application delivery capability extends beyond the engineering organisation entirely.
