Building a Platform Engineering Team From Scratch

Building a platform engineering team from scratch means starting with a single, high-friction developer workflow to fix rather than a broad mandate, and hiring two or three engineers who can turn that fix into a reusable, self-service capability the rest of engineering adopts voluntarily because it is faster than the alternative, not because it was mandated.

What Platform Engineering Actually Is, and Is Not

Platform engineering is the discipline of building internal tooling and self-service infrastructure that lets product engineering teams ship faster with less cognitive overhead about the underlying infrastructure — not a rebrand of DevOps, and not a team that owns every deployment on other teams' behalf. The distinction matters because a platform team that ends up doing deployments for other teams, rather than building the tooling that lets those teams deploy themselves safely, has quietly become a bottleneck with a new name, and undermines the entire reason to build the function.

A useful platform team produces internal products — golden-path templates, self-service infrastructure provisioning, standardised CI/CD pipelines, observability defaults — that other engineering teams adopt because they are genuinely better and faster than building it themselves, not because policy requires it. If adoption of what the platform team builds requires a mandate rather than being the obviously easier path, that is a signal the product is not yet good enough, not a signal that engineering needs to be told to comply.

When You Are Actually Ready for One

Standing up a dedicated platform team too early is a common and expensive mistake — a small engineering organisation with a handful of product teams does not have enough deployment and infrastructure variety yet to justify a team whose entire job is building shared tooling; the product engineers can still reasonably own their own infrastructure directly. The signal that you are ready is not headcount, it is friction: multiple product teams independently solving the same infrastructure problem in slightly different ways, onboarding new engineers taking noticeably longer because there is no standard starting point, or infrastructure and deployment work regularly pulling product engineers away from feature work for days at a time. When that friction is visible and repeated across more than one team, the investment case for a dedicated platform function is real.

The First Hires and What They Should Build First

• Start with two to three senior engineers who have shipped production infrastructure themselves — platform engineering credibility depends on the team having done the job it is now standardising, not just designed it
• Pick one, and only one, high-friction workflow to fix first — new service provisioning, CI/CD standardisation, or environment setup are common starting points because nearly every team hits them
• Build the first version as a genuinely optional self-service tool, not a mandated migration — let the value sell it to the first team that tries it voluntarily
• Instrument adoption from day one, using time-to-first-deploy for a new service and time-to-onboard a new engineer as the metric that proves or disproves the investment
• Resist the urge to build a broad internal developer platform before the first narrow workflow has real, voluntary adoption

The Golden Path: Your First Real Deliverable

The concept of a golden path — a fully supported, opinionated, default way to accomplish a common task such as spinning up a new service, deploying to production, or setting up observability — is the most effective first deliverable for a new platform team, because it is concrete, has an obvious before-and-after, and does not require boiling the ocean. Design it so the default path is also the easiest path: a new engineer following the golden path should reach a working, observable, production-ready service faster than they would by assembling the pieces themselves, even if they know the infrastructure well. That speed differential, not a mandate, is what drives adoption.

Measuring Whether the Platform Team Is Working

The right metrics for a platform team are the ones product teams feel directly: time from a new service being proposed to it being deployed to production, time for a new engineer to ship their first change, and the percentage of new services built on the golden path voluntarily rather than migrated onto it under pressure. A platform team that cannot point to improving numbers on these fronts after two or three quarters, regardless of how much internal tooling it has shipped, has built infrastructure nobody asked for or needs — the test is always adoption and measurable speed, not activity.

A platform engineering team earns its existence one adopted workflow at a time, not through an upfront mandate. Start narrow, prove the golden path is genuinely faster than the alternative, and let that first success, not an org chart change, be what justifies the next hire.