The platform team's second act

Platform teams have a predictable first act. A few senior engineers, tired of watching every product team solve deployment badly, are chartered to pave the road: golden paths, shared CI, one blessed way to get a service to production. The first act usually succeeds, because the problems are concrete and the customers are desperate.

The second act is where the genre splits into comedy or tragedy, and it begins the day the platform team's roadmap stops being derived from other teams' pain. The warning signs are consistent enough to list. Product teams open tickets instead of pull requests. The platform's abstractions acquire mandatory fields that exist for the platform's convenience. Migration deadlines arrive by email. Someone says "our customers" with air quotes.

The term of art for the healthy version, popularized by Team Topologies, is "platform as a product": internal customers who could in principle go elsewhere, treated as if they actually could. The phrase is easy to put on a slide. The practice has a sharper test: when a product team builds around the platform, is the platform team's first instinct curiosity or enforcement? Workarounds are reviews. A paved road that people leave is telling you where it should have gone.

Funding models drive more of this than architecture does. A platform funded as a cost center must justify itself with adoption numbers, and mandated adoption is the easiest number to manufacture; a toll booth is born. A platform funded like a product, with something resembling a P&L of engineering hours saved, can afford to let a team stay on the old path while the new one earns its migration. I have watched the same engineers behave both ways under the two models. It was never about the engineers.

There is a measurement trap in the second act as well. The DORA research gave the industry defensible delivery metrics, and platform teams adopted them as proof of value: deploys per day up, lead time down. Useful, but those are outcomes the product teams produce on the platform, not properties of the platform. The platform-shaped questions are duller: how long does a new service take to reach production, how many teams hit the golden path without a conversation, what fraction of migrations finish on the promised date. Those numbers survive an executive review without a footnote.

The second act ends one of two ways. The comedy: the platform grows boring, teams stop thinking about it the way nobody thinks about municipal water, and its engineers complain, correctly and proudly, that their best work is invisible. The tragedy: the platform becomes a department, with a steering committee, a request queue, and a generation of product engineers whose formative platform experience is waiting. Both endings are chosen years earlier, in the funding model and the first mandated migration. Very little about organizations is deterministic, but this comes close.