Team Charter Template

A Team Charter defines who a team is, what they do, and how they work together. It creates alignment, clarifies boundaries, and serves as a reference point for decision-making. Every team should have one.

Why Use Team Charters?

Benefits:

Aligns team on purpose and priorities
Clarifies scope and boundaries
Establishes working norms
Reduces ambiguity and conflict
Helps new members onboard faster

When to create or update:

New team formation
Significant team restructuring
Annually as a refresh
When scope or mission changes
After a team retrospective identifies need

The Template

markdown

# Team Charter: [Team Name]

**Version:** [1.0]
**Created:** [YYYY-MM-DD]
**Last Updated:** [YYYY-MM-DD]
**Approved By:** [Manager/Leadership]

---

## Team Identity

### Team Name

[Official team name]

### Team Mission

[1-2 sentence statement of why this team exists and the value it provides]

### Team Vision

[Where is this team headed? What does success look like in 2-3 years?]

### Team Slogan/Values (Optional)

[A memorable phrase or set of values that capture team identity]

---

## Team Members

| Name | Role | Responsibilities | Time Allocation |
|------|------|------------------|-----------------|
| [Name] | [Title/Role] | [Key responsibilities] | [100% / 50%] |

### Roles and Responsibilities

**[Role 1]:**
- [Responsibility]
- [Responsibility]

**[Role 2]:**
- [Responsibility]
- [Responsibility]

---

## Scope

### What We Own

*Systems, services, and domains this team is responsible for*

- [Owned area 1]
- [Owned area 2]
- [Owned area 3]

### What We Don't Own

*Explicitly out of scope to avoid confusion*

- [Not owned 1]
- [Not owned 2]

### Interfaces with Other Teams

| Team | Interface | Nature of Interaction |
|------|-----------|----------------------|
| [Team 1] | [What we share] | [Dependency type] |
| [Team 2] | [What we share] | [Dependency type] |

---

## Goals and Metrics

### Team OKRs (Current Quarter)

**Objective 1:** [Objective]
- KR1: [Key Result]
- KR2: [Key Result]

**Objective 2:** [Objective]
- KR1: [Key Result]
- KR2: [Key Result]

### Key Performance Indicators (KPIs)

| Metric | Target | Current | Dashboard |
|--------|--------|---------|-----------|
| [Metric 1] | [Target] | [Current] | [Link] |
| [Metric 2] | [Target] | [Current] | [Link] |

### Service Level Objectives (SLOs)

| SLO | Target | Measurement |
|-----|--------|-------------|
| [Availability] | [Target] | [How measured] |
| [Latency] | [Target] | [How measured] |

---

## Working Agreements

### Communication

**Primary channels:**
- [Channel]: [What it's used for]
- [Channel]: [What it's used for]

**Response expectations:**
- [Channel]: [Expected response time]

**Escalation:**
- [How to escalate and when]

### Meetings

| Meeting | Purpose | Frequency | Duration | Attendees |
|---------|---------|-----------|----------|-----------|
| [Standup] | [Purpose] | [Frequency] | [Duration] | [Who] |
| [Planning] | [Purpose] | [Frequency] | [Duration] | [Who] |
| [Retro] | [Purpose] | [Frequency] | [Duration] | [Who] |

### Development Practices

- **Code review:** [Process/expectations]
- **Testing:** [Standards]
- **Documentation:** [Expectations]
- **Deployment:** [Process]

### Decision Making

*How we make decisions as a team*

**Individual decisions:**
[What can individuals decide alone]

**Team decisions:**
[What requires team discussion]

**Escalation:**
[When and how to escalate]

---

## Norms and Values

### Team Norms

*How we agree to work together*

1. [Norm 1]
2. [Norm 2]
3. [Norm 3]
4. [Norm 4]
5. [Norm 5]

### Conflict Resolution

*How we handle disagreements*

[Process for resolving conflicts]

### Feedback

*How we give and receive feedback*

[Feedback norms]

---

## On-Call and Support

### On-Call Rotation

**Rotation type:** [Schedule type]
**Hours:** [Coverage hours]
**Escalation path:** [Who to escalate to]

### Support Responsibilities

[What the team supports and how]

---

## Resources

### Documentation

- [Wiki/docs link]
- [Runbooks link]
- [Architecture docs link]

### Key Links

- [Repository]
- [Dashboard]
- [Incident management]
- [Backlog/project board]

---

## Appendix

### Team History

[Brief history of the team]

### Charter Changelog

| Version | Date | Changes |
|---------|------|---------|
| [Version] | [Date] | [Changes] |

---

*This charter is a living document. We review and update it [frequency]. Questions? Talk to [contact].*

Complete Example

markdown

# Team Charter: Platform Team

**Version:** 2.1
**Created:** 2024-01-15
**Last Updated:** 2025-10-01
**Approved By:** James Lee (VP Engineering)

---

## Team Identity

### Team Name

Platform Team (also known as "Platform Engineering" or just "Platform")

### Team Mission

**Enable product teams to ship faster by providing reliable, scalable, and developer-friendly infrastructure and tooling.**

We exist to multiply the effectiveness of every engineer at Acme Corp. by handling the complexity of infrastructure so product teams can focus on customer value.

### Team Vision

By 2027, every product team at Acme Corp will be able to:
- Deploy to production in under 10 minutes with confidence
- Scale automatically without platform team intervention
- Debug production issues using self-service tools
- Maintain 99.9% availability without being infrastructure experts

### Team Values

**"Pave the roads, don't build the cars"**

We build platforms, not products. Our success is measured by how well product teams can move, not by what we build ourselves.

- **Developer Experience First** - If it's hard to use, we failed
- **Reliability is a Feature** - Boring is beautiful
- **Automate Everything** - Manual processes don't scale
- **Teach, Don't Rescue** - Enable self-service over support tickets

---

## Team Members

| Name | Role | Responsibilities | Time Allocation |
|------|------|------------------|-----------------|
| Sarah Chen | Engineering Manager | Team leadership, stakeholder mgmt, people | 100% |
| Alex Rivera | Senior Engineer | Tech lead, system design, mentoring | 100% |
| Mike Johnson | Senior Engineer | CI/CD, developer tools | 100% |
| Jamie Park | Engineer | Kubernetes, infrastructure | 100% |
| Lisa Wang | Engineer | Observability, monitoring | 100% |
| David Kim | SRE | On-call lead, incident response | 50% (shared with SRE team) |

### Roles and Responsibilities

**Engineering Manager (Sarah):**
- Team health and performance
- Hiring and career development
- Stakeholder communication
- Roadmap prioritization
- Budget and resource planning

**Tech Lead (Alex):**
- Technical direction and architecture
- Code review standards
- Technical decision making
- Cross-team technical coordination
- Mentoring and technical growth

**Senior Engineers (Mike, Alex):**
- Lead complex technical projects
- Design and architecture
- Mentor junior engineers
- On-call rotation
- Technical documentation

**Engineers (Jamie, Lisa):**
- Feature development and maintenance
- On-call rotation
- Documentation
- Support and incident response

**SRE (David):**
- On-call leadership
- Incident response
- Reliability improvements
- SLO management

---

## Scope

### What We Own

**Infrastructure:**
- Kubernetes clusters (production, staging, dev)
- Cloud infrastructure (AWS accounts, VPCs, IAM)
- Database platforms (RDS, ElastiCache, managed Postgres)
- Message queues (Kafka, SQS)
- CDN and edge (CloudFront)

**Developer Tools:**
- CI/CD pipelines (GitHub Actions, ArgoCD)
- Local development environment (Docker Compose, Tilt)
- Internal CLI tools
- Feature flag infrastructure

**Observability:**
- Metrics platform (Datadog)
- Logging infrastructure (Datadog Logs)
- Tracing (Datadog APM)
- Alerting and on-call (PagerDuty)

**Developer Experience:**
- Service templates and scaffolding
- Documentation platform (internal wiki)
- API gateway (Kong)
- Secrets management (AWS Secrets Manager)

### What We Don't Own

- **Application code** - Product teams own their services
- **Business logic** - We provide infrastructure, not product features
- **Data pipelines** - Data Platform team
- **Security tooling** - Security team (we collaborate)
- **QA environments** - Shared responsibility with product teams
- **Vendor relationships** - Except for infrastructure vendors

### Interfaces with Other Teams

| Team | Interface | Nature of Interaction |
|------|-----------|----------------------|
| Product Teams | Platform services, support requests | Provider → Consumer |
| Security | Security scanning, compliance | Collaboration |
| Data Platform | Kafka, database access | Shared infrastructure |
| SRE | On-call, incidents | Shared responsibility |
| DevEx | Developer tools, onboarding | Collaboration |

---

## Goals and Metrics

### Team OKRs (Q4 2025)

**Objective 1:** Improve deployment experience
- KR1: Reduce average deploy time from 25 min to 10 min
- KR2: 95% of deploys succeed on first attempt (up from 87%)
- KR3: Zero manual interventions required for standard deploys

**Objective 2:** Increase platform reliability
- KR1: Achieve 99.95% platform availability (up from 99.9%)
- KR2: Reduce mean time to recovery (MTTR) from 45 min to 20 min
- KR3: Zero P0 incidents caused by platform issues

**Objective 3:** Improve developer self-service
- KR1: 80% of support requests resolved via documentation (up from 60%)
- KR2: Launch self-service database provisioning
- KR3: Reduce support ticket volume by 30%

### Key Performance Indicators (KPIs)

| Metric | Target | Current | Dashboard |
|--------|--------|---------|-----------|
| Platform Availability | 99.95% | 99.92% | [Link] |
| Deployment Success Rate | 95% | 87% | [Link] |
| Mean Deploy Time | <10 min | 25 min | [Link] |
| Support Tickets/Week | <20 | 35 | [Link] |
| Developer NPS | >50 | 42 | [Link] |
| MTTR | <20 min | 45 min | [Link] |

### Service Level Objectives (SLOs)

| SLO | Target | Measurement |
|-----|--------|-------------|
| Platform Availability | 99.95% | Uptime of core services |
| API Gateway Latency | p99 < 50ms | Kong metrics |
| CI Pipeline Time | p95 < 15 min | GitHub Actions metrics |
| Deployment Time | p95 < 15 min | ArgoCD metrics |

---

## Working Agreements

### Communication

**Primary channels:**
- **#platform-team** (Slack): Team discussions, async standups
- **#platform-support** (Slack): Support requests from other teams
- **Email**: External vendors, formal communication
- **GitHub**: Code reviews, technical discussions

**Response expectations:**
- Slack (team channel): Same business day
- Slack (support channel): Within 2 hours during business hours
- Code reviews: Within 24 hours
- Urgent/pages: Within 15 minutes

**Escalation:**
1. Post in #platform-support
2. If urgent, @mention on-call engineer
3. If P0, page via PagerDuty

### Meetings

| Meeting | Purpose | Frequency | Duration | Attendees |
|---------|---------|-----------|----------|-----------|
| Standup | Sync, blockers | Daily 9:30am | 15 min | Full team |
| Sprint Planning | Plan next sprint | Bi-weekly Mon | 1 hour | Full team |
| Backlog Grooming | Refine backlog | Weekly Thu | 30 min | Full team |
| Retrospective | Continuous improvement | Bi-weekly Fri | 1 hour | Full team |
| 1:1s | Individual check-ins | Weekly | 30-45 min | Manager + report |
| Architecture Review | Design reviews | Weekly Wed | 1 hour | Senior+ engineers |
| Stakeholder Sync | Cross-team alignment | Monthly | 30 min | Sarah + TLs |

**Meeting norms:**
- Meetings start on time; if you're late, catch up async
- Cameras on for standups and retros (optional otherwise)
- Come prepared (read pre-reads, have updates ready)
- No laptops in retros unless note-taking

### Development Practices

**Code review:**
- All changes require 1 approval (2 for infrastructure changes)
- Reviews should be done within 24 hours
- Use conventional comments (nit:, question:, blocker:)
- Prefer small PRs (<400 lines)

**Testing:**
- Unit tests required for all new code
- Integration tests for critical paths
- Infrastructure changes tested in staging first
- Load testing for performance-sensitive changes

**Documentation:**
- ADRs for significant technical decisions
- README for every service
- Runbooks for operational procedures
- Update docs as part of PR (not after)

**Deployment:**
- Deploy to staging → verify → production
- Feature flags for risky changes
- Deployments during business hours (exceptions need approval)
- Rollback plan required for database migrations

### Decision Making

**Individual decisions:**
- Implementation details within approved designs
- Bug fixes and minor improvements
- Personal work prioritization within sprint

**Team decisions (discuss in standup or sync meeting):**
- Architecture changes
- New tool adoption
- Process changes
- Prioritization trade-offs

**Escalation (bring to Sarah or leadership):**
- Scope changes affecting roadmap
- Cross-team conflicts
- Resource/hiring decisions
- Vendor contracts

**Decision record:**
- Significant decisions documented in ADRs
- Decisions announced in #platform-team

---

## Norms and Values

### Team Norms

1. **Bias toward action** - When in doubt, try something. Perfect is the enemy of good.

2. **Assume positive intent** - Most miscommunication comes from lack of context, not malice.

3. **Be kind, not nice** - Give honest feedback. Avoiding hard conversations isn't kind, it's negligent.

4. **Document as you go** - If it's not written down, it doesn't exist. Future you will thank present you.

5. **Take care of yourself** - Sustainable pace. Take PTO. Don't burn out.

6. **Help others succeed** - Answer questions in public channels. Share knowledge freely.

7. **Own your work** - See problems through to resolution. Don't throw things over the wall.

8. **Question everything** - "We've always done it this way" isn't a good reason.

### Conflict Resolution

1. **Talk directly** - Address issues with the person involved first
2. **Assume context is missing** - Ask questions before making accusations
3. **Focus on behavior, not character** - "The code review was late" vs "You're unreliable"
4. **Involve manager if stuck** - It's not failure to need help resolving conflict
5. **Disagree and commit** - Once a decision is made, support it even if you disagreed

### Feedback

- **Give feedback early and often** - Don't save it for reviews
- **Be specific** - "The deploy doc was clear and well-organized" > "Good job"
- **Use SBI format for constructive feedback** - Situation, Behavior, Impact
- **Request feedback proactively** - "What's one thing I could do better?"
- **Feedback is a gift** - Receive it with gratitude, even if you disagree

---

## On-Call and Support

### On-Call Rotation

**Rotation type:** Weekly rotation, Monday to Monday
**Hours:** 24/7 with follow-the-sun support (David covers APAC)
**Escalation path:**
1. Primary on-call (15 min response)
2. Secondary on-call (backup)
3. Sarah (EM) for P0 incidents
4. James (VP Eng) for critical business impact

**On-call expectations:**
- Respond to pages within 15 minutes
- Document all incidents
- Handoff context at rotation end
- Identify and file follow-up tickets

### Support Responsibilities

**How to get support:**
1. Check documentation first (#platform-docs)
2. Search #platform-support for similar issues
3. Post question in #platform-support
4. If urgent, @platform-oncall

**SLA for support requests:**
- P0 (production down): 15 min response
- P1 (significant impact): 2 hour response
- P2 (degraded/workaround available): 1 business day
- P3 (questions/improvements): Best effort

---

## Resources

### Documentation

- **Team Wiki:** https://wiki.acme.com/platform
- **Runbooks:** https://wiki.acme.com/platform/runbooks
- **Architecture Docs:** https://wiki.acme.com/platform/architecture
- **ADRs:** https://github.com/acme/platform-adrs

### Key Links

| Resource | Link |
|----------|------|
| Team Backlog | https://jira.acme.com/platform |
| Main Repository | https://github.com/acme/platform |
| CI/CD Dashboard | https://github.com/acme/platform/actions |
| Monitoring Dashboard | https://app.datadoghq.com/dashboard/platform |
| On-Call Schedule | https://acme.pagerduty.com/schedules/platform |
| Support Channel | #platform-support |

---

## Appendix

### Team History

- **2022 Q1:** Platform team formed from DevOps and portions of Backend team
- **2022 Q4:** Kubernetes migration completed
- **2023 Q2:** Took over CI/CD from individual teams
- **2024 Q1:** Added observability to scope
- **2025 Q1:** Team expanded from 4 to 6 engineers

### Charter Changelog

| Version | Date | Changes |
|---------|------|---------|
| 1.0 | 2024-01-15 | Initial charter |
| 1.1 | 2024-07-01 | Added observability scope |
| 2.0 | 2025-01-15 | Major update: new OKRs, team growth |
| 2.1 | 2025-10-01 | Q4 OKR update, refined norms |

---

*This charter is reviewed quarterly in our planning meeting. Suggestions welcome anytime in #platform-team or directly to Sarah.*

Charter Best Practices

1. Create It Together

The team should write this collaboratively. Don't hand down a charter from above.

2. Be Specific

"Good communication" is meaningless. "Respond to Slack within 2 hours" is actionable.

3. Keep It Visible

Post it where the team can find it. Reference it in onboarding.

4. Review Regularly

Quarterly reviews keep the charter relevant as the team evolves.

5. Use It

A charter that sits in a drawer is useless. Reference it in decisions and retrospectives.

A team charter isn't a contract—it's a conversation. It makes implicit expectations explicit and gives the team a shared foundation to build on.

Team Charter Template