Hi Reader!

I’ve scaled three different platform teams, most recently a 100-person org serving 5,000 engineers in a 45k-person company. Lots of legacy, lots of consolidation work, lots of learning what actually works (and what doesn’t).

So if you’re trying to figure out how to structure platform teams at scale, or you’re wondering how much of the conventional wisdom actually holds up, this one’s for you.

Let’s go.

Structure by problem space, not by tool.

My team covered Observability, Delivery (CI/CD), Orchestration, Developer Portal, and Cloud Native. About one PM per space, maybe 100 people total.

My experience working in this area is that the more opinions you have, the more continued fragmentation you create. Platform work needs both product thinking and deep technical knowledge, so the lines blur. I prefer fewer very senior PMs and staff engineers over many mid-level people.

Also, tie team identity to the problem space, not to a specific tool. Very important for continued evolution and not being anchored in existing solutions. Tools change, vendors get replaced. If you’re “the Jenkins team” instead of “the Delivery team,” you’ve already locked yourself into something that won’t age well.

Backlogs stay separate, alignment happens everywhere else.

We did not share backlogs between teams, but we ensured alignment through shared planning, shared milestones, end-to-end demos, and weekly dependency meetings.

A product org is important. This helps with alignment and ensuring that the teams are building one platform that works well, instead of creating a tooliverse. Without product oversight, teams optimize locally and you get fragmentation.

Get the comms right and your work is easier.

I split it into several layers:

• Eng-to-eng: Active Slack channels where teams get timely and pleasant support. Rotate a goalie so people don’t burn out.
• Internal stakeholder mapping: My leads assigned themselves as point of contact for their primary domains, including recurring check-ins (and reporting back to the leadership team on those check-ins). In a large org, this can be very helpful.
• Me as the platform lead: Representing the org in recurring peer meetings.
• PMs doing continuous discovery: Following Teresa Torres’ approach to stay close to customer needs.
• Active outreach: Open demos, visiting other teams’ big meetings, posting in their channels, Customer Advisory Boards. (Newsletters never worked for us though.)

If you build it, you own it.

No dedicated support units. The teams do their own support.

This is the only way to get real push for reducing maintenance burden and creating great documentation. When support becomes someone else’s problem, the feedback loop breaks. It’s a thing (or was it dead, I can’t remember).

Lean senior, because the scope is context-heavy.

Most teams leaned toward senior engineers with a few juniors sprinkled in. The work requires people who can navigate legacy systems, understand trade-offs across domains, and make good calls in ambiguous situations. (This probably depends on your org type and platform maturity.)

Does it work well? We’ve been able to improve the lead times for setting up a backend service and linking it to a database from 5 weeks to 2 minutes. So it’s a yes.

Measure impact beyond developer productivity.

Platform work is more than “developer productivity.” It has direct impact on:

• Security: Less fragmentation equals fewer vulnerabilities. Standards equal safer ways to develop and deliver code.
• Cost: Pure control of licenses and cloud spend.
• Supporting future scale: Readiness for new teams, new technology, M&A, AI.

Regardless of size, don’t limit yourself to delivery metrics. Measure the transformation you’re actually driving.

Thanks for reading. I’d love to hear what challenges you’re facing with platform teams at scale.