A Team API describes how others work with a team. It covers owned services, communication routes, work preferences, and known constraints and is maintained jointly.

1. 1

   Mission

   Mission/ownership

   

   Goal

   Produce ownership profile so the core question “What must other teams know to work effectively with this team with minimal disruption?” can be answered with stronger support.

   Inputs for this step

   • Team mission and services
   • dependencies and contact routes
   • work and support data

   Actions

   • Name team purpose, owned services, and boundaries.
   • Record source, rationale, and open uncertainty directly in ownership profile.

   Output

   ownership profile

   ownership profile · source · uncertainty · next decision

   Quality check

   Are responsibilities expressed as services or outcomes?

   Pitfall

   The team API becomes an org chart or promises support the team cannot sustain. Test against real consumer situations, clarify ownership and response routes, and remove unsustainable promises.

   Timing: 10–20 minutes

2. 2

   Interfaces

   Interfaces

   

   Goal

   Produce interaction catalogue so the core question “What must other teams know to work effectively with this team with minimal disruption?” can be answered with stronger support.

   Inputs for this step

   • ownership profile
   • dependencies and contact routes
   • work and support data

   Actions

   • Describe consumer, interaction mode, and contact route per need.
   • Record source, rationale, and open uncertainty directly in interaction catalogue.

   Output

   interaction catalogue

   interaction catalogue · source · uncertainty · next decision

   Quality check

   Is there one clear route for every need?

   Pitfall

   The team API becomes an org chart or promises support the team cannot sustain. Test against real consumer situations, clarify ownership and response routes, and remove unsustainable promises.

   Timing: 10–20 minutes

3. 3

   Ways of working

   Ways of working

   

   Goal

   Produce collaboration rules so the core question “What must other teams know to work effectively with this team with minimal disruption?” can be answered with stronger support.

   Inputs for this step

   • interaction catalogue
   • dependencies and contact routes
   • work and support data

   Actions

   • Agree working preferences, support, and response rules.
   • Record source, rationale, and open uncertainty directly in collaboration rules.

   Output

   collaboration rules

   collaboration rules · source · uncertainty · next decision

   Quality check

   Are commitments realistic and measurable?

   Pitfall

   The team API becomes an org chart or promises support the team cannot sustain. Test against real consumer situations, clarify ownership and response routes, and remove unsustainable promises.

   Timing: 10–20 minutes

4. 4

   Consumer review

   Consumer review

   

   Goal

   Produce validated team API so the core question “What must other teams know to work effectively with this team with minimal disruption?” can be answered with stronger support.

   Inputs for this step

   • collaboration rules
   • dependencies and contact routes
   • work and support data

   Actions

   • Walk through the API with two consumer teams and correct gaps.
   • Record source, rationale, and open uncertainty directly in validated team API.

   Output

   validated team API

   validated team API · source · uncertainty · next decision

   Quality check

   Can consumers find ownership and contact without asking?

   Pitfall

   The team API becomes an org chart or promises support the team cannot sustain. Test against real consumer situations, clarify ownership and response routes, and remove unsustainable promises.

   Timing: 10–20 minutes