Platform engineering: paving the road for your teams
2 June 2026 · 8 min read · Nintech Advisory
Every product team at a company of any size makes the same fifty decisions: how to build a container image, where secrets live, how deployments roll back, what a service needs before it can face production traffic. Left alone, ten teams will produce ten different answers, and the organisation pays for all ten — in onboarding time, in incident response confusion, in security reviews that start from zero every time. Platform engineering is the practice of making those decisions once, well, and packaging them so that the default path is also the good path.
Golden paths, not golden cages
A golden path is a supported, documented, end-to-end route for a common task: 'stand up a new backend service with CI, deployment, observability, and an on-call rota' as a single template rather than a three-week archaeology project. The critical property is that it is paved, not fenced. Teams can step off it — a genuinely unusual workload may need to — but stepping off means taking on the operational burden themselves, explicitly. This is the difference between a platform and a bureaucracy: a bureaucracy blocks the exceptional case; a platform makes the common case so cheap that exceptions become rare and deliberate.
Concretely, a golden path is a set of artefacts: a service template that generates a repo with working CI, a deployment pipeline that already knows about progressive rollout and rollback, dashboards and alerts that exist from the first deploy, and a production-readiness checklist encoded as automated checks rather than a wiki page. When Spotify popularised the term, the insight was not the templates themselves — it was that the paved road had to be genuinely better than going off-road, or engineers would ignore it. A golden path that is slower than doing it yourself is just documentation nobody reads.
Cognitive load is the budget
The economic argument for a platform is not really about duplicated effort; it is about attention. A product engineer shipping a payments feature has a finite budget of things they can hold in their head, and every Kubernetes annotation, IAM policy, and TLS renewal they must understand comes directly out of the budget available for the payments domain — the thing the business actually pays them to be good at. Team Topologies calls this extraneous cognitive load, and reducing it is the platform's entire job: the product team should need to know that deployments roll back automatically, not how.
This framing also tells you what to build first. Instrument where product teams actually lose time — the questions that recur in the infrastructure Slack channel, the steps in 'new service' runbooks that take days of back-and-forth, the incidents caused by teams misconfiguring things they should never have had to configure. The platform backlog should be derived from observed friction, not from what the platform team finds architecturally interesting. A platform team that spends a quarter building a bespoke service mesh while product teams still wait four days for a database is optimising its own satisfaction, not the organisation's throughput.
The platform is a product, and it can lose
The single biggest predictor of platform success is whether the team treats internal engineers as customers who can churn. In most organisations they can: they can shadow-IT their way onto a cloud account, run their own CI, quietly ignore the golden path. A mandated platform with captive users decays predictably — no pressure to be good, so it isn't. A platform run as a product does the unglamorous product work: user interviews with the teams it serves, a public roadmap, adoption metrics tracked honestly, deprecation policies with real migration support, and release notes people can read. If teams adopt the platform because it is genuinely the fastest way to ship, mandates become unnecessary.
This also means the platform team needs product skills it often lacks. Someone must own prioritisation and say no; someone must do the discovery work of watching a product engineer attempt to use the platform and noting where they swear. The failure mode of platform-as-infrastructure-project is a technically excellent system with an interface only its authors can operate. Time-to-first-deploy for a new engineer, and time-from-repo-to-production for a new service, are better health metrics than anything on a cluster dashboard.
Self-service with guardrails, not gatekeepers
The old model — file a ticket, wait for the infrastructure team — fails at scale because the central team becomes the bottleneck for every deploy, every database, every DNS change. The naive fix, handing every team raw cloud credentials, replaces the queue with a compliance and cost incident. The workable pattern is self-service within a bounded envelope: teams provision what they need instantly, but through interfaces that encode policy. Terraform modules that only build encrypted, backed-up databases in approved regions. Admission policies that reject containers running as root before a human ever reviews anything. Budget alerts and quotas attached to the team, not the platform.
The mechanism that makes this work is moving governance from review-time to definition-time. A security review that happens per-deployment scales linearly with deployments; a security property enforced in the paved-road template scales for free. Policy-as-code — OPA, Kyverno, Sentinel, whichever fits the stack — turns 'the security team must approve' into 'the pipeline rejects non-compliant configuration in thirty seconds with an actionable error'. Product teams get speed, security gets consistency it could never achieve through manual review, and the exceptions that do need human judgement get human attention instead of being buried in a queue of routine approvals.
When you should not build one
Honesty requires the caveat: below a certain size, a platform team is a mistake. With five product engineers, a dedicated platform function means 20-40% of engineering capacity building tooling for the other 60-80% — the arithmetic simply fails. Under roughly 20-30 engineers, the right 'platform' is a well-chosen PaaS or managed service, a shared Terraform repo, one opinionated CI template, and a short conventions document. Heroku-style platforms, managed Kubernetes with sane defaults, or a hosting partner exist precisely so small teams do not have to build this themselves.
The other failure is premature abstraction: building the platform before the patterns exist. A platform is a bet that the paved road matches where teams actually want to go, and you can only pave a road you have watched people walk. If your teams have shipped three services, you do not yet know what your golden path should look like — build the third service, notice what hurt, and extract the pattern afterwards. The rule of three applies to platforms as much as to code: the first time, just do it; the second time, wince and do it again; the third time, that is your template. Platforms extracted from real use get adopted. Platforms designed in advance of use get worked around.
Working on something like this? Talk to an engineer.