Pick the Right Team
Type: ReferenceCreated: Last reviewed: Team: Platform
published
Why every doc has an owner
Every doc has an owner_team. Without one, no one's on the hook when it goes stale or gets a bug report — and people change teams, but teams outlive turnover.
The four teams
| Slug | Owns | Examples |
|---|---|---|
platform | Developer infrastructure — the handbook, CI/CD, build tooling, internal apps | Build pipelines, code review automation, internal dashboards, the docs platform |
engineering | Product code — customer-facing features, services, clients | Feature explanations, API references, architecture docs, data models |
cloud | Production runtime — deployment, monitoring, on-call, infrastructure | Runbooks, SLOs, on-call procedures, deployment guides |
security | Compliance and risk — threat models, secure coding, audits | SOC2 / GDPR controls, threat models, security review checklists |
How to pick
A short cascade:
- Is it about running production? →
cloud - Is it about compliance, threats, or audits? →
security - Is it a tool other engineers use? →
platform - Is it product code? →
engineering
Adding a team
Carefully check the implementation and add it in places needed and do the through test. Don't add slugs preemptively — only when a real ownership boundary exists (a team that's actually on-call for a domain end-to-end).