RunsheetTeam Design

Team API

ComplexityLow

TimeHalf day initial, dann laufend

ParticipantsEin Team plus Stakeholder

FormatWorkshop + async

MaturityEmerging

Prerequisite

What needs to be finished first

Complete firstTeam Charter

Team has basic clarity about purpose, mission and main responsibilities, written or at least jointly held.

Without: Without team self-understanding, Team API becomes collection of activities without clear service logic.

Preparation

What needs to be ready before start

Materials

Team API template (for example from teamtopologies.com); wiki or repository page; list of most important stakeholder teams; current service descriptions; known interface problems; SLA templates.

People / roles

One facilitator (team lead or coach); entire team (engineering, product, optionally operations); one stakeholder representative per important team for validation; scribe for documentation.

Pre-read

Current team responsibilities; known services (APIs, platforms); stakeholder teams with contact paths; existing SLAs or informal expectations; planned roadmap items.

Time needed

Half day (4 h) initial, then quarterly maintenance

Setup

Template with sections: team purpose and mission, responsibilities, non-responsibilities, services, interfaces, service level, communication channels, roadmap, onboarding notes. Wiki page ready.

Core question

The one question this method answers

What does our team offer other teams as service, how do they interact with us, and what can they expect?

Flow

Marker: Sektion

Step	Duration	Action	Hint
1Section 1: Purpose and responsibilities	30-45 min	Team purpose in 1-3 sentences. Main responsibilities as 3-7 bullet points. Non-responsibilities explicit (what we do not do, even if others expect it).	Non-responsibilities are often more valuable than responsibilities. What we do not do clarifies escalation expectations. Avoid vague "we take care of everything" sentences.
2Section 2: Services and interfaces	45-60 min	Per service: name, purpose, consumers, technical interface (API URL, Slack channel, ticket queue), request workflow. Three to eight services typical.	Services are not only APIs. Consulting, reviews, on-call support are services too. Name consumers clearly, otherwise services are provided for wrong audience.
3Section 3: Service level and expectations	30-45 min	Rough SLA per service: response time, availability, escalation path. Expectations for consumers (for example issue template, on-call trigger conditions).	SLAs must be achievable. Better conservative ("response within 2 business days") than aspirational. Unrealistic SLAs destroy trust faster than no SLAs.
4Section 4: Communication channels and escalation	20-30 min	Where consumers report requests, bugs, incidents. Purpose per channel (for example Slack #team-X for questions, Jira for tickets, PagerDuty for P1). Escalation hierarchy for conflicts.	Clear channel separation. "DM me on Slack" does not scale. Prefer public channels, documented histories secure knowledge.
5Section 5: Roadmap and onboarding	20-30 min	Current roadmap section with next quarter focus. Onboarding notes: how can external team start with us (preparation, workshop, documentation).	Roadmap section makes expectation management easier. Visibility over upcoming topics prevents repeated "when do you do X" questions.

Artifact

What comes out at the end

Form

Team API page in central wiki with all sections, prominently linked from engineering-org overview. Visible to all employees. Markdown in repo as second form (for version control and onboarding).

Versioning / ownership

Quarterly maintenance. Change log at end of page. For major changes (new services, changed SLAs), broader communication to stakeholder teams. Check onboarding notes after every new team member.

Tool alternatives

Confluence page with Team API template
Notion database with team entry
Markdown in repo (for example backstage.io plugin)
GitHub Pages with Team API section
Internal wiki with tag structure

team-api-working-template.md

Compact working template for Team API with context, input, output artifacts, and next step.

Team API Working Template

Goal

Describes a team's tasks, services, and expectations as an API.

Context

When and for what do we use this method?

Input

Which data, observations, decisions, or materials are available?

Execution

Short notes along the runsheet.

Output artifacts

Team API document:

Assumptions and open questions

Decision / next step

Owner, date, and success signal.

Example output

Concrete filled scenario, fictional example

team-api-beispiel.md

Concrete filled scenario, fictional example

Team API - Platform Team "Identity & Access", status 2026-05-18

Purpose: We provide authentication, authorization and user lifecycle as platform service for all product teams.

Main responsibilities

SSO integration (Google, Microsoft, SAML)
User Management API
Permission model (roles, permissions)
Audit log for access
On-call for P1 authentication outages

Non-responsibilities

UI components for login screens (product team responsibility).
User onboarding flows (product team).
Compliance audits beyond pure authentication (Compliance Team).

Services

Service	Consumers	Interface	Workflow
Auth API (OAuth2)	all product teams	api.internal/auth/v2	Self-service, docs in /docs/auth
SSO onboarding for new tenants	Sales Engineering	Slack #identity-help	Ticket in Jira, SLA 2 days
Audit log export	Compliance, Security	API + Looker dashboard	Self-service
Permission review (annual)	Compliance	Workshop format	Appointment via Sandra @Compliance

Service Level

Auth API: 99.95% availability, P1 outage response <15 min.
SSO onboarding: response <2 business days, solution <5 business days.
Audit log: self-service, no explicit SLA.

Communication channels

General questions: Slack #identity-help.
Bugs/incidents (not P1): Jira project IDENTITY.
P1 incidents: PagerDuty service "identity-platform".
Escalation: Team Lead @ben, then Engineering Director @julia.

Roadmap Q3/2026

Multi-factor authentication as service (launch August).
API version migration v2 -> v3 (plan document in wiki).
Audit log retention to 7 years (compliance requirement).

Onboarding for new consumers

Read docs in /docs/auth.
Create test tenant through self-service form.
Optional: 30-min kickoff call with @ben (book via Calendly).

Team members

@ben (Lead)
@anna (Engineer)
@marcus (Engineer)
@lisa (SRE Liaison, 50%)

Services listed, but nobody says clearly who should or may use them.

What to do

Explicit consumer list per service. "All product teams" is acceptable, "external partners" needs own section. Clear target group avoids misunderstanding.

Stop criteria

Done signals checkable in under a minute

Team has no clear purpose or service character (for example temporary project team).

Organization has only one team, Team API is overhead.

Team is in storming phase, responsibilities not yet stabilized.

No central wiki or platform for visibility available, document would be hidden.

Quarterly maintenance not feasible, document would age out.

Established service documentation already exists in different format, Team API would create parallel structure.

Finished the runsheet?

Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.

Go to profile More methods