Platform engineering
Definition
Platform engineering
Platform engineering is the practice of building and running internal tooling as a product for the engineers who use it. The team has customers inside the company, a roadmap, and a support promise. It is not a ticket queue with better scripts.
Note the boundary. A platform engineer is the person; platform engineering (PE) is the discipline that person works in, and it is not partner enablement, which shares the same initials.
Hold it apart from its neighbours too. PE is an organisational and technical practice, not the commercial structure of a two-sided marketplace — and not the question of which vendor stack to buy.
Key takeaways
- Platform engineering treats internal tooling as a product with named users and a roadmap.
- Its customers are other engineers, so adoption is voluntary and has to be earned.
- Success is measured in how fast delivery teams ship, not in tickets closed.
- A platform team that cannot say no has quietly become a service desk.
How it works
Platform engineering works by productising the paved path. The team picks a small number of common jobs, builds one supported way to do each, and publishes what it will guarantee. Teams that want a different path keep it, and own it.
| Platform team behaviour | Shared infrastructure desk behaviour |
|---|---|
| Publishes a roadmap | Works a ticket queue |
| Measures adoption | Measures tickets closed |
| Declines one off requests | Says yes to everything, once |
| Owns the default path end to end | Owns the servers only |
| Chosen because it is faster | Used because it is mandatory |
A platform team needs a charter before it needs a tool. Write down which teams it serves, what it will support, and what it explicitly will not — or every passing request becomes in scope.
Treat the platform like any product. That means user research with your own engineers, a visible backlog, release notes, and a deprecation policy people can plan against.
The practice grew out of DevOps, which pushed operations work towards the teams writing the code. Platform engineering is the correction — give those teams a supported default instead of a blank terminal.
Golden paths work because they are optional — if the only route to production runs through you, you stop hearing about problems and start hearing about workarounds.
Funding decides the shape. A platform paid for from a central budget can refuse work, while one funded by chargeback tends to build whatever the biggest payer asks for.
A DevOps engineer usually sits with or near one delivery team. A platform team sits a layer back and serves many teams at once, which only pays off above a certain size.
Where you start depends on where you are. A DevOps maturity model is the usual way to find which parts of delivery are already repeatable and which are still assembled by hand.
Most platform programmes begin inside a wider DevOps transformation, so the platform inherits whatever discipline that programme managed to establish.
You do not have to invent the security content of that path. Published standards give you the practices, and the platform team’s job is making them the default rather than an extra step.
The US National Institute of Standards and Technology published Version 1.1 of its Secure Software Development Framework (SSDF) in February 2022: practices that can be integrated into each development lifecycle, not a separate process.
Developer time is the expensive input, which is what makes the arithmetic work. The US Bureau of Labor Statistics put the median software developer wage at $135,980 in May 2025, with employment projected to grow 10 percent to 2035.
Measure the gap between intent and a running service. Time to first deploy for a new joiner, and time to provision a new service, are the two numbers worth publishing every month.
The hardest part is not technical. Persuading senior engineers to give up their own build arrangements takes evidence, so publish the numbers rather than issuing a mandate.
Examples
Platform engineering shows up wherever many teams ship against the same infrastructure. Banks, government agencies and outsourcing providers all run a version of it, usually starting with one paved deployment path and widening from there.
Regulated public delivery. Defence and civil agencies publish platform patterns centrally rather than letting each programme invent one.
Agencies that do this well publish one approved pipeline with the security checks already wired into it, so a programme inherits its compliance evidence instead of arguing the case afresh.
Shared service providers. An outsourcing provider running delivery for thirty clients cannot maintain thirty toolchains. One supported pipeline per technology family, with client specific settings at the edges, is the usual answer.
Regulated financial delivery. Banks fold security scanning and evidence capture into the paved pipeline, so audit artefacts are produced by the act of shipping rather than assembled by hand afterwards.
Growing engineering groups. Once build scripts have been copied between teams often enough that nobody knows which copy is correct, the first platform charter gets written. The trigger is duplication, not headcount.
Related terms
- Back-end developer: builds the services that run on the platform rather than the platform itself.
- Application support engineer: keeps live systems healthy; the platform changes what they have to support.
- Platform engineer: the individual role inside this discipline.
- DevOps: the culture and practice platform engineering grew out of.
- DevOps maturity model: the assessment that tells you what to build first.
FAQ
What is platform engineering?
It is the discipline of building internal tooling as a product for engineers inside your own company. The platform team owns a supported default path and publishes what it guarantees.
How is platform engineering different from DevOps?
DevOps moved operations work towards delivery teams. Platform engineering gives those teams a supported path so each one is not solving the same problem alone.
Is platform engineering the same as a platform engineer?
No. The engineer is the role; the discipline is the wider practice of funding, staffing and measuring a platform team.
How do you measure a platform team?
Measure adoption and delivery speed, not tickets closed. If teams choose the paved path without being forced onto it, the platform is working. Falling adoption is the earliest warning you will get.
When is a company too small for platform engineering?
Below a handful of delivery teams the overhead usually outweighs the gain. Revisit the question once duplicated build work starts costing real engineering time.
Compare providers with established platform and DevOps teams in the Outsource Accelerator directory.
Independent
