Templates you can paste into a doc today

# 1:1, {{name}}, {{date}}

## Their topics (first 20 min)
- 
- 

## Goals & growth
- Current focus:
- Skill stretch this month:
- Blockers:

## Feedback (both directions)
- Appreciation:
- Request / experiment:

## Delivery & priorities
- Top commitments until next 1:1:
- Risks I should know:

## Notes / decisions
- 

## Next check-in
- Date:
- Follow-ups (owner):

# Hiring scorecard, {{role}} ({{level}})

## Mission of the seat (6-12 months)
1. 
2. 
3. 

## Must-have vs teachable
| Skill | Must-have | Teachable | Notes |
| --- | --- | --- | --- |
| | | | |

## Attributes (score Strong / Mixed / Weak)
1. Problem decomposition, signals:
2. Code / craft quality, signals:
3. Collaboration, signals:
4. Ownership, signals:
5. System design judgment, signals:
6. Communication, signals:

## Loop design
- Screen:
- Work sample / coding:
- Design:
- Collaboration:
- Hiring manager:

## Calibration notes
- Bar for this level:
- Common false positives to avoid:

# Leveling evidence, {{name}} → {{target_level}}

## Scope of impact (last 2-3 cycles)
- Outcomes delivered:
- Ambiguity handled:
- Influence radius (team / multi-team / org):

## Evidence bullets (outcome → how → result)
1. 
2. 
3. 

## Feedback from others
- Peers:
- Cross-functional partners:
- Manager notes:

## Gaps & plan
- Gaps vs target level:
- Support / stretch work:

## Decision
- Ready now / ready with conditions / not yet:
- Conditions or timeline:

# ADR {{number}}: {{title}}

- Status: Proposed | Accepted | Superseded
- Date:
- Deciders:

## Context
What forces are in play (quality attributes, constraints, incidents)?

## Decision drivers
1. 
2. 

## Options considered
### Option A
- Pros:
- Cons:

### Option B
- Pros:
- Cons:

## Decision
We will…

## Consequences
- Positive:
- Negative / debt accepted:
- Follow-ups / fitness checks:

# Debt item, {{name}}

- Owner:
- First seen / last incident:
- Systems touched:

## If we do nothing
- User / revenue risk:
- Engineering drag (estimate):
- Blast radius:

## Investment options
| Option | Effort | Outcome metric | Residual risk |
| --- | --- | --- | --- |
| Full fix | | | |
| Mitigate | | | |
| Accept | 0 | | |

## Recommendation
- 

## Decision & review date
- 

# API review, {{service}} {{api_name}}

## Consumers & use cases
- 

## Resources & operations
- Naming matches domain?
- Pagination / filtering / sorting?
- Idempotency for writes?

## Errors & auth
- Error codes documented?
- Authn/z boundaries clear?
- Audit / tenancy?

## Compatibility
- Versioning strategy:
- Additive vs breaking changes:
- Deprecation policy:

## Operability
- SLOs / rate limits:
- Observability (metrics, traces):
- Rollback / dual-run plan:

## Decision
- Approve / revise / reject:

# Incident, {{title}}, {{date}}

## Severity & impact
- Started / detected / mitigated / resolved:
- User impact:

## Timeline (UTC)
- 

## What helped / what hurt
- 

## Contributing factors (systems, not villains)
1. 
2. 

## Action items
| Action | Owner | Due | Status |
| --- | --- | --- | --- |
| | | | |

## Follow-up comms
- Who was informed:
- External note needed?

# Priority stack, week of {{date}}

## Capacity (engineer-days)
- Available:
- Meetings / support tax:
- Net:

## Ranked outcomes (no ties)
1. 
2. 
3. 

## Explicitly not this week
- 

## Risks & asks
- 

## Stakeholder note (3 bullets)
1. Progress:
2. Risk:
3. Ask:

# Compensation conversation, {{person}}, {{date}}

## Role & level
- Scope next 6 months:
- Level / band:

## Package (facts only)
- Base:
- Bonus / equity:
- Other:

## Market / internal equity notes
- 

## Message structure
1. Excitement about role/impact
2. Package clearly
3. What is flexible vs fixed
4. Questions

## If the answer is no / not now
- Constraint:
- Next review window:
- Non-monetary support:

## Follow-ups
- 

# PIP outline, {{name}}, start {{date}} end {{end_date}}

## Prior feedback trail
- Dates / themes:

## Gaps (observed, with examples)
1. 
2. 

## What “meets” looks like
1. 
2. 

## Support provided
- Coaching:
- Pairing / scope:
- Training:

## Check-ins
| Date | Focus | Notes |
| --- | --- | --- |
|  |  |  |

## Outcomes
- Met / not met:
- Next step:

# Team AI norms, {{team}}, {{date}}

## Encouraged
- Drafting updates from notes you verify
- Brainstorming options / test ideas
- Summarizing long docs you still read

## Not allowed without extra review
- Final hiring or performance decisions
- Unreviewed production code from AI alone
- Pasting secrets or private personal data

## Review rule
If you would not sign your name under it, do not ship it.

## Tools approved here
- 

## Examples of good use
1. 
2. 

# Team topology one-pager — {{team}} — {{date}}

## Mission (one sentence)


## Team type
- [ ] Stream-aligned
- [ ] Platform
- [ ] Enabling
- [ ] Complicated-subsystem
- Why this type:

## Streams / services we own
1. 
2. 

## What we explicitly do not own


## Neighbors and interaction modes
| Neighbor | Actual mode | Desired mode | Notes |
| --- | --- | --- | --- |
|  | Collaboration / XaaS / Facilitating |  |  |

## Platform or service expectations (if applicable)
- Docs:
- SLO:
- Support path:
- Versioning / deprecation:

## Cognitive load risks
- 

## Next topology experiment (30 days)
- 

# Capacity plan — {{team}} — {{quarter}}

## Outcomes this quarter
1. 
2. 

## Demand (engineer-weeks)
| Stream | Work | Est. weeks | Notes |
| --- | --- | --- | --- |
| Product |  |  |  |
| KTLO / support |  |  |  |
| Debt / platform |  |  |  |
| Hiring / onboarding |  |  |  |
| **Total demand** |  |  |  |

## Supply
- People (FTE): 
- Weeks in period: 
- Focus factor (0.6-0.75 typical): 
- Minus PTO / leave / ramp: 
- **Available engineer-weeks:** 

## Stability reserve
- % or weeks held back: 
- Why:

## Scenarios
### Stay flat
- What ships:
- What slips:
- Risks:

### +1 hire (role: )
- What changes by when:
- Ramp assumptions:

### Scope cut (if hire denied)
- Cuts:
- Communication plan:

## Will not do this quarter
- 
- 

## Decision asked of leadership
- 

# Team OKRs — {{team}} — {{cycle}}

## Mission (stable)
 

## North star metric (if any)
- Metric:
- Definition / source:

## Objective 1
**O:** 

| Key Result | Baseline | Target | Source | Counter-metric |
| --- | --- | --- | --- | --- |
|  |  |  |  |  |
|  |  |  |  |  |

## Objective 2 (optional)
**O:** 

| Key Result | Baseline | Target | Source | Counter-metric |
| --- | --- | --- | --- | --- |
|  |  |  |  |  |

## Standing KPIs we watch (not OKRs)
| KPI | Threshold / SLO | Owner | If red we… |
| --- | --- | --- | --- |
|  |  |  |  |

## Will not do this cycle
- 

## Capacity link
- Available engineer-weeks:
- Risks:

## Mid-cycle check (date)
- On track / at risk / off:
- Learning:

# Team setup charter — {{team}} — {{date}}

## Mission (one sentence)


## Non-goals


## Size and composition
- Headcount:
- Two-pizza / cognitive load check: pass / fail / mitigate how:
- Seniority mix notes:

## Streams / services owned


## Explicitly not owned (consume as XaaS)


## Neighbor interaction modes
| Neighbor | Mode | Notes |
| --- | --- | --- |
|  | Collaboration / XaaS / Facilitating |  |

## Communication system
- Source of truth:
- Decision log:
- Status rhythm:
- Interrupt / on-call path:
- Cross-team ask path:

## Working agreements
- 

## Success metrics
- OKR cycle link:
- KPI set:

# Handover contract — {{work-title}} — {{date}}

## Owner (end-to-end)
- Name:
- Backup:

## Context (why now)


## Outcome (definition of done)
- User / system result:
- Quality / operability bar:

## Non-goals


## Constraints
- Time:
- Dependencies:
- Risk / compliance:
- Performance / SLO:

## Breakdown (value slices)
1. 
2. 
3. 

## Decision rights
| Decision type | Owner decides | Consult | Approver |
| --- | --- | --- | --- |
| Local implementation |  |  |  |
| Interface / API contract |  |  |  |
| Scope change |  |  |  |
| Launch / rollback |  |  |  |

## RACI matrix (required in checklist)
R = Responsible (does the work) · A = Accountable (one per row) · C = Consulted · I = Informed

| Activity | Eng owner | Tech lead | Product | Partner team | Other |
| --- | --- | --- | --- | --- | --- |
| Problem framing / design |  |  |  |  |  |
| Implementation |  |  |  |  |  |
| Code / design review |  |  |  |  |  |
| Launch / rollout |  |  |  |  |  |
| Comms to stakeholders |  |  |  |  |  |
| Rollback / incident response |  |  |  |  |  |
| Success metrics / validation |  |  |  |  |  |

Rules: exactly one A per activity. Lead should not keep A on every row after handover.

## Checkpoints (risk-based, not hourly)
| When | Artifact | Who |
| --- | --- | --- |
|  | Design note / ADR |  |
|  | Mid-slice demo |  |
|  | Launch readiness |  |

## Support from lead
- I will:
- I will not (no longer owning):

## Escalation red flags
- 

## Teach-back (owner fills)
- Problem in my words:
- First slice:
- How I get unblocked:

## Handover checklist (all should be yes before lead steps back)
- [ ] Outcome + quality bar written
- [ ] Non-goals written
- [ ] Context links complete
- [ ] End-to-end owner (+ backup if needed)
- [ ] RACI matrix filled (one A per activity; owner can explain C vs I)
- [ ] Teach-back passed
- [ ] Decision rights table filled
- [ ] Risk-based checkpoints booked
- [ ] Interfaces / rollout / rollback named
- [ ] Lead support boundaries set
- [ ] Escalation red flags listed
- [ ] Operability (logs/metrics/alerts/runbook) included if production-facing
- [ ] Done = how we know it worked (metric / test / user check)

## Handover metrics (track 3-5)
| Metric | Definition | Baseline | Target / watch | Source |
| --- | --- | --- | --- | --- |
| Time-to-first-progress |  |  |  |  |
| Checkpoint hit rate |  |  |  |  |
| Lead interrupt rate |  |  |  |  |
| Blocker age (median) |  |  |  |  |
| Re-decision rate |  |  |  |  |
| Owner confidence (1-5) start → mid |  |  |  |  |
| Quality counter-metric |  |  |  |  |

## Review dates
- Mid-checkpoint:
- Closeout:

# Feedback loop design — {{loop-name}} — {{date}}

## Loop type
- [ ] People
- [ ] Delivery
- [ ] Product
- [ ] Operations
- [ ] Other:

## Problem (why this loop)
What open loop pain are we fixing?


## Anatomy
| Part | Design |
| --- | --- |
| Sensor (signal) |  |
| Cadence |  |
| Who looks |  |
| Comparison (intent / threshold) |  |
| Decision forum |  |
| Actuator (who changes the system) |  |
| Memory (where learning lives) |  |

## Action rule
If signal is red / off target, we will:


## First two-week experiment
- Start date:
- Success = one real decision or change:
- Owner:

## Loop health metrics
| Metric | Definition | Current | Target |
| --- | --- | --- | --- |
| Action completion rate |  |  |  |
| Repeat signal rate |  |  |  |
| Decision latency |  |  |  |
| Owner clarity (% actions with one name) |  |  |  |

## Anti-patterns to avoid
- 

# Servant leadership — 30-day practice — {{team}} — {{start-date}}

## Intent (one sentence)
How I will serve this team so they are stronger without me in every detail:


## Week 1 — Listen
| Person | Protect | Change | Stop |
| --- | --- | --- | --- |
|  |  |  |  |

Themes:


## Week 2 — Remove one blocker
- Blocker:
- Owner of fix:
- Done when:

## Week 3 — Hand over one stream
- Stream:
- Owner:
- RACI / checklist green? Y/N
- Coaching checkpoints:

## Week 4 — Close one feedback loop
- Loop (people / delivery / product / ops):
- Sensor → decision → change:

## Weekly scorecard (1-5)
| Week | Team ownership | My interrupt load | Hard feedback given | Credit shared | Notes |
| --- | --- | --- | --- | --- | --- |
| 1 |  |  |  |  |  |
| 2 |  |  |  |  |  |
| 3 |  |  |  |  |  |
| 4 |  |  |  |  |  |

## Not servant (watch list)
- [ ] Saying yes to infinite scope
- [ ] Avoiding conflict
- [ ] Doing all hard tasks myself
- [ ] Withholding context as power