📖 Business
Team API
Skelton and Pais propose that every team should be treated like a software service — it should have a well-defined, documented "API" that makes it clear what the team owns, what it provides to others, and how others should interact with it. Just as a poorly documented software API causes integration pain and workarounds, a poorly defined team boundary causes organizational friction, duplicated effort, and ownership disputes. The Team API is not a metaphor — it's a concrete artifact that the team writes down, publishes, and maintains.
2
Minutes
2
Concepts
+45
XP
1
How It Works
A Team API consists of four components:
- Code and service ownership — What repos, services, data stores, and infrastructure does this team own? Ownership means full lifecycle responsibility: building, deploying, monitoring, and maintaining. If nobody owns it, everybody will assume somebody else does.
- Communication protocols — How do other teams request work from this team? Is there a ticket queue, a Slack channel, office hours, an on-call rotation? What are the expected response times (SLAs)? How do you escalate? This eliminates the "I didn't know who to ask" problem.
- Documentation — Runbooks, onboarding guides, architecture decision records (ADRs), API contracts, and operational playbooks. If a new team member or a consuming team can't figure out your system from the docs, the Team API is incomplete.
- Interaction modes — Explicitly declare: who does this team collaborate with (and why, and for how long)? Who consumes this team's services via X-as-a-Service? Who is currently facilitating this team? This maps directly to the three interaction modes.
Why writing it down matters: Most team friction comes from ambiguous ownership boundaries. When two teams argue about whose job something is, the Team APIs aren't clear enough. The act of writing forces decisions: "Wait, who actually owns the authentication service?" If the answer is "kind of both teams," that's the bug — fix it by assigning clear ownership in the Team API.
The Team API should be:
- Public — anyone in the org can read it
- Living — updated as ownership and interactions change
- Concise — a single page, not a wiki nobody reads