How platform teams get stuff done

Pete Hodgson's insight: platform teams don't fail because they build bad things. They fail because they don't understand that adoption is a collaboration problem, not a technical problem. Getting your code into other teams' codebases is critical to platform success, and there's no one-size-fits-all pattern.

The phases matter. During platform migration, product teams often aren't motivated to make changes—they're being asked to shift as part of a broader architectural initiative without getting huge value themselves. You can file tickets (scalable, trackable, but product teams deprioritize). You can do the work yourself (faster because aligned incentives, but only works if product teams trust you with their codebase). Reality? Most platform teams end up doing a combination: file tickets, cajole teams for a while, then roll up their sleeves and do it for the stragglers who are too busy or disinclined.

During platform consumption (the steady state), product teams use your platform capabilities for day-to-day feature work. This is where x-as-a-service shines—teams spin up services using your service chassis, mostly self-service. But getting there requires that you've already built trust, established patterns, and reduced their cognitive load.

The real work isn't the platform code. It's figuring out which collaboration pattern fits the maturity of each team, the phase of adoption, and how much external influence their codebase can accept. Platform teams that treat this as a product and customer problem win. Those that treat it as a technical deployment problem lose.