Team API

The explicit interface a team presents to the rest of the organization: its code and services, documentation, ways of working, and the expectations others can hold of it. Interacting with a team should go through its API, just as using a module goes through its interface.

Why it Matters

Teams are modules in the organization. A clear team API lets others depend on the team without knowing its internals, which cuts coordination cost and applies information hiding at the level of people, not just code.

Signals

• Others know how to request work, what the team owns, and what to expect, without ad hoc interruptions.
• Anti-signals: you must know specific individuals to get anything done; expectations are implicit and constantly renegotiated.

Benefits

Lower coordination overhead, clearer ownership, and interactions that scale without everyone needing to know everyone.

Risks

A bureaucratic "API" that is all process and no responsiveness. Documenting an interface the team does not actually honor.

Tensions

A well-defined team API favors x-as-a-service autonomy but can feel rigid during phases that genuinely need collaboration. Formalizing the interface costs effort a small or new team may not yet warrant.

Examples

A platform team publishes what it offers, how to onboard, and its support expectations, so others self-serve. The boundary mirrors information hiding: internals stay hidden, the interface is what others consume.