DevOps promised that teams would own their software all the way to production. In practice, many teams ended up owning a sprawl of pipelines, cloud accounts and dashboards on top of the product they were meant to build. Platform engineering is the response: a small team builds an internal platform that makes the right way to ship also the easiest way.
Golden paths, not golden cages
At the heart of a good platform are golden paths — paved, supported routes for the common jobs: creating a service, provisioning a database, deploying, getting logs and alerts. Teams can step off the path when they have a real reason, but the path should be so convenient that they rarely want to.
Treat the platform as a product
The platform's users are your developers. That means talking to them, measuring whether the platform saves them time, publishing a roadmap and good documentation, and resisting the urge to build features nobody asked for. A platform that is mandated rather than chosen is usually a sign it isn't good enough yet.
Build observability and cost in
- Standardise telemetry with OpenTelemetry, so every service emits traces, metrics and logs the same way from day one.
- Make cost visible per team and per service — FinOps works best when the people making decisions can see what they cost.
- Bake security in: secrets management, least-privilege access and dependency scanning as part of the path, not a review at the end.
Start smaller than you think
The first version of a platform can be a service template, a shared pipeline and a single page that explains them. Grow it from the most common pain points, and measure how long it takes a new engineer to ship their first change.
This matters most when teams are growing fast or spread across locations — which is exactly when our Cloud, DevOps & Infrastructure work meets our Technology & Product Consulting and our Offshore Development Centre (ODC) teams.