Having worked on a platform team for over four years, I want to offer up some defining facets and mental models for successful platform teams.

Velocity drivers

Platform teams are velocity drivers for product teams. This is the easy piece of the platform puzzle in terms of prioritization. A platform:

• Takes the worst 2-3 things plaguing developer experience and fixes them,
• Takes the best 2-3 things the best product teams are doing and makes them generally available to all teams,
• Repeats.

The worst things come first because they are easy to measure. Run a developer survey every six months. If developers are still complaining the most about those 2-3 things, you haven't done enough to solve them yet.

The best things are harder to figure out. You have to find the right role models on the product side. These are the teams providing the best business outcomes under their remit. Sharing those teams' learnings and practices more broadly would take away from their work, so the platform needs to understand what the best teams are and what they are doing.

Following this repetitive process, developer velocity at the company can move forward at a predictable and rapid pace.

Filling gaps in the big picture

The relationship between product and platform are weighted by incentives. A proper understanding of incentives underpins the difference between success and failure of a platform team.

We can perceive product teams in a rather reductionist view:

• Product teams want to deliver more business value that makes money.
• Product engineers are rewarded for minimally-viable completion of short term business objectives.

This leaves so many gaps for platform teams to fill:

• Security
• Reliability
• Documentation
• Testing
• Cost optimization
• Learning better engineering practices, etc.

Product teams want to minimize their time spent on these types of things and will prioritize delivering above everything else.

This means the platform team:

• designs the baseline development standards such that common product work isn't dead before arrival due to engineering constraints,
• chooses which things are easy and which are hard because product teams will always converge on doing the easiest thing (also known as the golden path),
• burns down the worst things which hold many teams back from delivering that they cannot resolve themselves (or some teams have and the solution has not been disseminated) because product teams will not prioritize this work unless it presents a clear value to them over the value of any other work they can think of.

Platform teams hold the big picture view of these incentives playing out and the artifacts they generate. Platforms optimize on covering the gaps which result from product team incentives.

Absorbing the right complexities

Platforms home complexity. There is the code and systems certainly but also domain expertise and subject matter that platform teams provide so product teams can stay focused.

Product teams don't want to hold any complexity once it has delivered its initial value and does not have a path forward for compounding returns. Without a counter-balance, platform teams would home everything. The backstop to this is the Rule of Three. No single product team can have a platform team. Teams of anything less than a 1:3 ratio of platform and product folks are not platform teams. The platform team needs to see an aggregate of teams repeating the same things successfully before coming to assist.

People who like proactive approaches tend to dislike the Rule of Three. Platforms are inherently reactionary. Anything else is a waste or dead-end. Product teams are the ideation source which will rapidly validate things faster than any platform team should. There's no reason to give half-baked, bad ideas the platform treatment/scrutiny.

Platforms take the complexity they absorb seriously because product teams don't:

• As products grow and have high expectations, product teams try to use platforms as complexity bearers. Platform teams must hold a hard line and push product teams to be properly staffed. Borrowing platform engineers for product work never implies a transfer of complexity to the platform.
• An individual product team's attempt to offload complexity to a platform is always an attempt to unload things which lack business value (their failures). Platform teams must hold a hard line and have the product team cope with or unwind their mistake.

Platforms can offer advice to product teams. Multiple teams need to prove out a solution before the platform team takes responsibility beyond consultation.

A product team should not make a platform system from the outset. The product team should focus on product success, their specialty, and the platform success of that solution will flow and be reworked or rewritten by the platform team when it has been validated.