Platform Engineering Team Setup
Standing up a platform team that 200 engineers actually want to use
A late-stage enterprise client
A 200-engineer enterprise was drowning in ticket-driven infrastructure. Every new service meant a four-week wait for Terraform, IAM, observability, and CI/CD setup, and every team had quietly built their own version of the missing platform. Leadership knew they needed a platform team, but the previous attempt had ended with a 'platform' nobody used. I came in to design the team's charter, hire the first three platform engineers, and ship the V1 of the internal developer platform: a Backstage portal, a service-template generator, and golden paths for the three workloads that covered 80% of new services.
Representative architecture study. Patterns, trade-offs and approach reflect engagements I take on; specific metrics and clients are illustrative.
Results
What changed, in numbers
The metrics the engagement is measured by.
<1 day
Service Setup
from 4 weeks
92%
Adoption
of new services in 6 months
18%
Capacity Recovered
of product engineering
+54
Platform NPS
after one quarter
Challenge
What was broken
The org had outgrown manual infra work but couldn't get a platform team off the ground. Engineers were spending 30% of their time on plumbing, not product. A previous attempt at a platform had failed because it shipped abstractions nobody asked for, and the trust deficit was real. Whatever shipped next had to land hard with product teams from day one.
Solution
The shape of the fix
A small, focused platform team with a clear charter, a Backstage portal that engineers actually opened, and golden paths that took new-service setup from four weeks to under a day. The platform shipped with paying internal customers from day one, no abstractions without users.
Approach
How I tackled it
The concrete moves that took the project from broken to shipped.
Ran a two-week discovery interviewing 25 engineers across product teams to define the actual top pain points
Wrote a platform charter with explicit non-goals so the team wouldn't drift back into ticket-taking
Hired three platform engineers with a deliberate mix of strong infra, strong DX, and strong empathy for product teams
Shipped a Backstage portal as the entry point, with service catalog, ownership, and on-call wired in on day one
Built a service-template generator so a new microservice came with CI/CD, IaC, observability, and SLOs in 15 minutes
Codified three golden paths (web service, async worker, data pipeline) and ran two paid-pilot teams through each before opening it up
Outcomes
What shipped, and what it changed
Measured results from the engagement, told as a story rather than a scoreboard.
Reduced new-service setup time from 4 weeks to under 1 day end to end
Drove platform adoption to 92% of new services within 6 months of launch
Recovered an estimated 18% of product engineering capacity by retiring infra toil
Cut mean-time-to-first-deploy for new hires from 11 days to 2 days
Established platform team NPS of +54 across product engineering after one quarter
Stack
Technologies used
Linked entries open the technology page with related studies, playbooks, and notes.
Services
How I helped
The specific services involved in this engagement. Each links to a deeper breakdown.
Lessons
What I would tell the next team
The takeaways I carry into every similar engagement.
A platform charter with non-goals matters more than the goals, that's what stops drift back into ticket-taking
Ship golden paths with paying internal customers, never abstractions in search of users
Backstage is a starting point, not a deliverable, the value is in the templates and integrations you build into it
Related
Other studies you might recognize
Engagements with overlapping problem shapes, industries, or stacks.
Have a similar challenge?
If any of this looks like the project on your desk, the conversation is the cheapest part. You can also browse other enterprise work or the full service list.