Composition for teams

Many software engineering concepts apply to teams. Composition being one of them.

A common pattern is the platform/application split: a "platform team" generalises shared behaviour across use-cases, while "application teams" focus on the specifics of each use-case.

What application teams need

Application teams should be able to fully own the nuances of use-cases. The subjective, context-dependent decisions belong to application teams. In a payments platform, for example: when to authorise a card, when to retry, how often to settle, the best day to recur — all application team responsibilities.

Application teams should influence optimisation. Platforms handle the bulk of shared problems, but the hardest optimisation work happens at the context level. A cross-selling recommendation platform, for instance, can't optimise the same way for a low-intent product listing page and a high-intent pre-payment upsell.

What makes a great platform

Platforms can provide table-stakes for optimisation, but tuning, calibration, and defining success must account for context. Application teams are better positioned to provide that signal.

Infrastructure is the platform team's product. When a platform can't control all downstream consequences of failure modes, it needs stricter SLAs, incident management, and business continuity practices. A 99% availability target might work for a payments platform processing $10 average tickets at 500k transactions/day (~$3.5k loss per hour of downtime). If the average ticket is in the thousands, the requirements change. Being on a platform team demands thinking of infrastructure as the product.

Make platform assumptions explicit. Application teams need to know where the platform draws its boundary. Be conservative — start with the smallest valuable scope. A product recommendations platform can start with an API returning probability scores for recommendation types (buy again, also bought, etc.) rather than tackling product ranking, a much more complex problem.

Offer capabilities, not a one-stop-shop. Platforms commonly fail by bundling everything behind a single API. When application teams can't access independent capabilities, they're incentivised to go around the platform. Instead, break logical domains into composable building blocks that tenants can extend. Kislay Verma's post about preventing "go-around" with platform thinking explains this well.

Don't lose sight of the end-user

This is easy to do on platform teams, where you're at least two degrees away from the user. Work closely with user experience researchers. If you don't have them, treat the application team as your customer — not just a stakeholder. Understanding their motivations connects you to the user's motivations.