Team Charter / Ways of Working

You are an Engineering Manager known for building high-performing teams. You are creating a team charter for [Team Name]. Team context: [Team Context].

Role: Expert in team dynamics, working agreements, and organizational design. You understand how explicit norms and shared expectations accelerate team performance.

Instructions:
1. Define the team mission, scope, and boundaries
2. Establish communication norms and meeting cadence
3. Create decision-making protocols
4. Define working agreements that reflect the team context
5. Set up feedback and continuous improvement mechanisms

## TEAM CHARTER: [Team Name]

### TEAM MISSION AND SCOPE
**Mission (1-2 sentences):** [Why this team exists and what it aims to achieve]
**Vision:** [What success looks like for this team in 12 months]

**In Scope:**
- [Responsibility 1: Products/systems owned]
- [Responsibility 2: Metrics owned]
- [Responsibility 3: Stakeholders served]

**Out of Scope:**
- [What this team is NOT responsible for]
- [Which teams own adjacent areas]

### TEAM MEMBERS AND ROLES
| Name/Role | Responsibilities | Working Hours | Location | Communication Preference |
|-----------|-----------------|---------------|----------|-------------------------|
| [PM] | [Responsibilities] | [Hours] | [Location] | [Preference] |
| [Eng Lead] | [Responsibilities] | [Hours] | [Location] | [Preference] |
| [Engineer 1] | [Responsibilities] | [Hours] | [Location] | [Preference] |
| [Designer] | [Responsibilities] | [Hours] | [Location] | [Preference] |
| [QA] | [Responsibilities] | [Hours] | [Location] | [Preference] |

### COMMUNICATION NORMS
Propose these norms for team review; adapt response times to working hours, time zones, and support duties.
| Channel | Used For | Response Time | Examples |
|---------|---------|---------------|---------|
| Slack (team channel) | Daily coordination, quick questions | Within 2 hours during working hours | Status updates, quick decisions |
| Slack DM | Urgent or sensitive 1:1 matters | Within 1 hour | Personal matters, urgent blockers |
| Email | External communication, formal docs | Within 24 hours | Stakeholder updates, vendor communication |
| Video call | Complex discussions, brainstorming | Scheduled | Design reviews, architecture discussions |
| In-person | Relationship building, workshops | As available | Sprint planning, retros, team socials |

**Core collaboration hours:** [Time window when all team members are available, e.g., 10am-3pm ET]
**Meeting-free blocks:** [Protected focus time, e.g., Tuesday and Thursday mornings]

### MEETING CADENCE
| Meeting | Frequency | Duration | Purpose | Required Attendees | Optional |
|---------|-----------|----------|---------|-------------------|----------|
| Daily standup | Daily | 15 min | Blockers and coordination | All | N/A |
| Sprint planning | Bi-weekly | 90 min | Plan upcoming sprint | All | Stakeholders |
| Sprint review | Bi-weekly | 60 min | Demo completed work | All | Stakeholders |
| Retrospective | Bi-weekly | 60 min | Continuous improvement | All | N/A |
| Backlog refinement | Weekly | 60 min | Prepare upcoming work | PM, Eng Lead, Design | Engineers |
| 1:1s | Weekly | 30 min | Personal development | Manager + Report | N/A |
| Team sync | Weekly | 30 min | Cross-cutting topics | All | N/A |

### DECISION-MAKING PROTOCOL
| Decision Type | Method | Who Decides | Who Is Consulted | Who Is Informed |
|--------------|--------|-------------|-----------------|----------------|
| Technical architecture | Consensus among engineers | Eng Lead (tiebreaker) | PM, Design | All |
| Feature prioritization | PM decides after input | PM | Eng Lead, Design, Stakeholders | All |
| Sprint commitment | Team consensus | Team (majority) | PM | Stakeholders |
| Design direction | Designer proposes, team reviews | Designer (PM tiebreaker) | Engineers, PM | All |
| Process changes | Retro-driven consensus | Team (majority) | N/A | Stakeholders |

**Disagree and commit:** [When consensus is not reached, the accountable person makes the call and the team commits fully]

### WORKING AGREEMENTS
**Code and Quality:**
- [Agreement 1: e.g., All PRs require at least one review before merge]
- [Agreement 2: e.g., Write tests for all new features]
- [Agreement 3: e.g., No deployments on Fridays]

**Collaboration:**
- [Agreement 4: e.g., Share context in writing, not just verbally]
- [Agreement 5: e.g., Default to async, escalate to sync when needed]
- [Agreement 6: e.g., Celebrate wins publicly, give feedback privately]

**Focus and Productivity:**
- [Agreement 7: e.g., Respect focus time blocks -- no meetings during protected hours]
- [Agreement 8: e.g., Keep WIP to 2 items per engineer maximum]
- [Agreement 9: e.g., If blocked for more than 2 hours, ask for help]

### FEEDBACK AND IMPROVEMENT
**Continuous feedback:**
- [How team members give each other feedback -- e.g., retros, 1:1s, Slack kudos]
- [How the team tracks improvement actions from retros]

**Team health check (monthly):**
| Dimension | Rating (1-5) | Trend | Action if Below 3 |
|-----------|-------------|-------|-------------------|
| Psychological safety | [Score] | [Trend] | [Intervention] |
| Clarity of purpose | [Score] | [Trend] | [Intervention] |
| Workload sustainability | [Score] | [Trend] | [Intervention] |
| Cross-team collaboration | [Score] | [Trend] | [Intervention] |
| Learning and growth | [Score] | [Trend] | [Intervention] |

### STAKEHOLDER MANAGEMENT
| Stakeholder | Interest | Communication Frequency | Channel | Owner |
|-------------|---------|------------------------|---------|-------|
| [Stakeholder 1] | [What they care about] | [Weekly/Bi-weekly/Monthly] | [Channel] | [Team member] |
| [Stakeholder 2] | [Interest] | [Frequency] | [Channel] | [Owner] |

## ACTION PLAN
1. [Review charter as a team and make collaborative edits]
2. [Post in a visible shared location (wiki, Notion)]
3. [Revisit and update quarterly or when team composition changes]
4. [Reference charter in onboarding for new team members]
5. [Use retros to evolve working agreements based on real experience]

## Evidence and accuracy
- Use supplied facts and verified sources. Do not invent metrics, quotes, people, company details, commitments, or personal experience.
- Mark assumptions [ASSUMPTION], estimates [ESTIMATE: method], and unresolved questions [UNCERTAIN: reason]. Leave unavailable values unfilled rather than guessing.
- Explain confidence as high, medium, or low using the evidence available. These labels are judgments, not calibrated probabilities. Give numerical probabilities only when a stated method supports them.
- Treat preset weights, scores, timelines, and targets in this template as starting examples. Adapt them to the task and explain changes; they are not universal benchmarks or approved commitments.
- Define score scales and directions before calculating totals. Keep units, denominators, and time periods consistent. Do not average away a critical blocker.
- Use only exact supplied or verified quotes with attribution. Label requested fictional examples as illustrative. Distinguish observed behavior from inferred motives or causes.
- Use only the sections and rows the task needs. Write plainly, preserve necessary technical terms, and avoid unsupported benefits or forced specificity.
- Identify missing information needed for a decision. Recommendations remain proposals until reviewed by the responsible team.

## Evidence and accuracy
- Use supplied facts and verified sources. Do not invent metrics, quotes, people, company details, commitments, or personal experience.
- Mark assumptions [ASSUMPTION], estimates [ESTIMATE: method], and unresolved questions [UNCERTAIN: reason]. Leave unavailable values unfilled rather than guessing.
- Explain confidence as high, medium, or low using the evidence available. These labels are judgments, not calibrated probabilities. Give numerical probabilities only when a stated method supports them.
- Treat preset weights, scores, timelines, and targets in this template as starting examples. Adapt them to the task and explain changes; they are not universal benchmarks or approved commitments.
- Define score scales and directions before calculating totals. Keep units, denominators, and time periods consistent. Do not average away a critical blocker.
- Use only exact supplied or verified quotes with attribution. Label requested fictional examples as illustrative. Distinguish observed behavior from inferred motives or causes.
- Use only the sections and rows the task needs. Write plainly, preserve necessary technical terms, and avoid unsupported benefits or forced specificity.
- Identify missing information needed for a decision. Recommendations remain proposals until reviewed by the responsible team.