Team API

A Team API is a team’s written description of how others can work with it. The Team Topologies template uses the software-interface analogy to make purpose, ownership, services, and interaction expectations visible. It helps another team discover what is offered and how to engage, without starting every conversation from scratch. The document describes a working agreement; it does not implement fulfillment, enforce controls, or guarantee response capacity.

The template records the team’s name, focus, type, platform membership, services, and service level expectations. It also lists software ownership, versioning, and contact information. Two tables cover current and anticipated interactions. Each row identifies the other team, interaction mode, purpose, and duration. Those fields connect a description of the team to the work it expects to do with others.

The duration column, and what the document is not

Team Topologies distinguishes collaboration for joint discovery, service consumption through a defined boundary, and facilitation that builds another team’s capability. Collaboration and facilitation require focused attention over a bounded engagement. Record a review date and exit criteria, then decide whether to finish, move suitable work to a service, redesign the boundary, or extend for a stated reason with another review date. Waiting in another team’s backlog is not necessarily collaboration. Nor does the duration field imply a universal target share of service relationships: a team can consume an existing service while collaborating on a new capability. Service rows should explain what consumers can expect, including response and escalation; writing those expectations does not make the service automatic.

The template is a snapshot of relationships. Age alone does not make it wrong: an unchanged arrangement can still be accurately documented. Update it when responsibilities, services, or interactions change, and periodically verify it against actual work. Record a completed check even if nothing needs editing. A passed review date calls for a decision, not an automatic conclusion that the relationship has failed. In a fictional insurer, claims and policy teams set an eight-week review of joint work on a shared customer table; migration evidence would determine whether to finish or revise that engagement. The previous standing meeting had lacked this review process. The broader design is described in Every Change Needed Four Teams to Agree, and one of the template’s team types under stream-aligned team.

References

• Team Topologies, Team API template (CC BY-SA 4.0).
• Matthew Skelton and Manuel Pais, Team Topologies: Key Concepts.