Platform Engineering
Building internal products that reduce the cognitive load on delivery teams — with self-service as the property that separates it from a service desk.
Definition
Platform engineering builds and operates the internal capability that delivery teams consume without needing to talk to anyone: pipelines, environments, observability, deployment, infrastructure provisioning.
Its purpose is reducing cognitive load so that stream-aligned teams spend their capacity on the domain rather than on infrastructure.
The property that determines success
Self-service. A platform that provides capability teams use themselves removes the handoff. A platform that performs work on request is a functional team with a new name — it preserves the handoff, accumulates a queue, and becomes the organisation's delivery bottleneck.
The symptoms of the failure mode are unmistakable: a backlog of one-off requests, teams waiting days for a change they cannot make themselves, and shadow infrastructure built to avoid the wait.
The primary deliverable: a paved road
A fully supported, opinionated path — templates, pipelines, infrastructure modules, standard libraries, observability wired in — that is the easiest way to build and run a service.
Teams follow it because it saves them work, so compliance, security and operational practice arrive as side effects of convenience. That is the only form of governance that survives deadline pressure.
Leaving the road must be allowed and must cost something: off-road teams own their own pipeline, monitoring, on-call tooling and compliance evidence. That is not a punishment; it is the honest cost.
When to invest
Not immediately. In a small organisation, delivery teams do the platform work, and that is correct.
The signal: the same infrastructure problem being solved repeatedly, badly and inconsistently, consuming capacity that should go to the domain.
The measures
Voluntary adoption, plus delivery outcomes for teams on the platform against those who are not: lead time, deployment frequency, change failure rate, time to first deploy. That comparison is the evidence that justifies the investment.
Failure scenarios
- The ticket queue.
- Building what the platform team finds interesting rather than what teams need.
- Mandated adoption, which destroys the quality signal and the incentive to improve.
- Owning too much, becoming a bottleneck by scope.
- No documentation, so the platform is usable only by people who can read its source.
Interview question
"What distinguishes platform engineering from an internal operations team?"