Start with the team that has the most repetitive work. The team that is rebuilding the same pipeline, the same observability stack, the same auth model for every new service is the team that has the highest return on a paved road. Form the platform team from the engineers who are best at building the paved road — the ones who can see the pattern across the existing services and build the template that captures it. Charter the team to ship one paved road, not the whole platform, and measure adoption before scope creep.
Platform Engineering
The platform is a product. The customer is the developer. The job is to make the secure, compliant, observable path the fastest path — and to keep it that way as the underlying ecosystem changes.
On this page
§ 01 ·
What platform engineering is
Platform engineering is the discipline of building and operating the paved roads that development teams use to ship software. The paved roads cover:
- Default templates. The repository templates that produce a new service with the right defaults.
- Default services. The shared services that new services consume (auth, secret store, queues).
- Default deployment pipelines. The CI/CD pipelines that build, test, scan, sign, and deploy.
- Default observability stack. The metrics, logs, traces, dashboards, and alerts that every service inherits.
Everything the development team needs to ship a secure, observable, compliant service, pre-integrated and ready to use.
The platform is a product
The model that has held up is platform-as-a-product. The platform team treats its users (the development teams) as customers. The platform has:
- A roadmap. Planned improvements.
- A changelog. What changed and when.
- A feedback channel. How users report issues.
- A deprecation policy. How old versions are retired.
The platform's success is measured by adoption (how many teams are using the paved roads) and by time-to-first-deploy for a new service.
The two failure modes
The two failure modes that come up most often are:
- The platform is a bottleneck. The platform has a long request queue and a slow review process. Development teams route around it.
- The platform is one-size-fits-none. The paved road does not fit most teams' actual workloads. Development teams route around it.
Both failure modes produce the same outcome: the platform team is paying the cost of building a platform that nobody uses.
§ 02 ·
The paved roads
The paved roads that have held up across the organisations we work with:
Service template
A repository template that produces a new service with the right defaults:
- Observability.
- Security.
- Deployment pipeline.
- Secret management.
- Identity.
- Audit logging.
The template is the paved road; the new service is a fork of the template.
Deployment pipeline
A default CI/CD pipeline that builds, tests, scans, signs, and deploys the service. The pipeline is the paved road; the new deployment is a config change.
Identity and access
A default identity and access model for the service:
- How the service authenticates to other services.
- How it receives requests.
- How it authorises them.
The model is the paved road; the new service consumes it.
Observability
A default observability stack: metrics, logs, traces, dashboards, alerts. The stack is the paved road; the new service is a config change.
Data and integration
A default data model and integration pattern:
- How the service stores state.
- How it publishes events.
- How it consumes events.
The model and pattern are the paved road; the new service is a config change.
The paved roads are not free
They are maintained, versioned, deprecated, and supported. The platform team is responsible for the paved roads; the development teams are responsible for using them.
§ 03 ·
State of the practice
~3-6
Months for a new platform team to go from charter to a useful paved road (varies by team size and scope)
Industry observation
1
Right measure of platform success: the percentage of new services that use the paved roads
NOETRONIQ engagement observation
~50%
Of platform engineering programmes that fail — usually because the paved road is slower than the alternatives
Industry observation (CNCF, HumanOps, others)
§ 04 ·
Questions we get asked
On three properties, in order: (1) adoption — what percentage of new services are using the paved roads, and what percentage of existing services have migrated; (2) developer experience — what is the time-to-first-deploy for a new service, and what is the cognitive load of using the paved roads; (3) operational outcomes — what is the mean time to detection, the change failure rate, the time to recover. The order matters: a platform that scores high on (3) and low on (1) is a platform nobody uses.
Bypassing the paved roads should be possible and should be a conscious decision, not a default. The right answer is a documented exception process: the team explains why the paved road does not fit, the platform team reviews the exception, and the team is responsible for the operational cost of the exception. The exception is logged and reviewed periodically. The paved road is the default; the exception is the audit trail.
The platform team has a feedback channel with the development teams: a regular sync, a public roadmap, a way to request features and report bugs. The platform team measures the developer experience (DORA metrics, time-to-first-deploy, cognitive load surveys) and acts on the signal. A platform team that is not in conversation with its customers is a platform team that is guessing.
§ 05 ·
Patterns we design our practice to avoid
A platform team that is staffed with the engineers who had spare cycles, with no charter, no budget, and no product owner, is a platform team that will be deprioritised the first time there is a real deadline. The platform needs to be funded as a product, with a roadmap, a backlog, and a sponsor. The cost of the platform is the cost of not having every team rebuild the same stack; the value is the time the platform saves.
A platform that is correct but slow is a platform that is bypassed. The paved road has to be the fastest path, not the most compliant path. The compliance is a property of the paved road; the performance is the reason the road is used.
A paved road that does not fit the workload is a paved road that is not used. The platform team has to start with the most common workload and iterate from there. The 80% case is the first paved road; the 20% cases are exceptions. A platform that tries to be everything to everyone is a platform that fails for everyone.
A platform that is scoped, funded, and delivered as a project — with an end date and a hand-off to operations — is a platform that goes stale. The platform needs an operating model: a team that maintains it, a roadmap that prioritises the next paved road, a feedback channel that surfaces the next thing to fix. A platform without an operating model is a platform that is in production for two years and then has to be replaced.
§ 06 ·
Evidence & references
Public frameworks and writing that inform our practice.
Team Topologies
Skelton and Pais, IT Revolution, 2019
The book that made platform engineering a discipline. The four team topologies (stream-aligned, enabling, complicated-subsystem, platform) and the three interaction modes (collaboration, X-as-a-Service, facilitating) are the vocabulary we use for the platform conversation.
Building an Internal Developer Platform from Scratch
HumanOps / Various, 2022-onwards
The case-study collection. The most useful of the recent platform engineering writing because it documents what actually worked (and what didn't) in real organisations. The patterns are not universal, but the failure modes are.
CNCF, 2023
The industry-association framing. The white paper is the most useful for the vocabulary and the taxonomy. The specific recommendations are less useful than the framing.
Accelerate
Forsgren, Humble, Kim, IT Revolution, 2018
The book that established the DORA metrics and the connection between delivery performance and organisational performance. The platform engineering conversation is the conversation about how to move the DORA metrics; the book is the evidence that the metrics matter.
Building a platform team?
If you are weighing a platform engineering initiative, evaluating a paved road, or trying to make an existing platform more than a documentation exercise, we are useful at the boundary between the capability and the implementation. A short conversation is the right next step.
Learn more