/team -- Optimize the Team
Pillar 5 of The Five Pillars. Assesses team health and recommends where to invest next.
When to invoke
- Standing up a new team
- After a reorg, a departure, or a stretch of turnover
- As a recurring (quarterly) team-health check
What it checks
- Stage -- is the team forming, storming, norming, or performing? What evidence supports that read (conflict patterns, delivery consistency, onboarding friction)?
- Player quality -- does each role have the direction, tools, and peer support to do A-player work? Where is someone set up to fail by circumstance rather than ability?
- Momentum -- is there a recurring rhythm of progress reporting and realignment, or does the team only get attention when something breaks?
Inputs
Team health doesn't live in an API either -- triangulate from what's available:
- Direct signal -- 1:1 notes, retro notes, or a short set of questions asked directly (pasted in or relayed by the user)
- Indirect signal from the repo -- commit/PR distribution (
git shortlog -sn, review turnaround time, bus-factor concentration) as a proxy when direct signal isn't available; call out that it's a proxy, not a substitute for asking people - History -- recent reorgs, departures, or onboarding noted in project memory/notes, since stage often resets after any of these
Example output
Team health -- Atlas team
Stage: Storming. Evidence: two conflicting PR review styles causing repeated re-review cycles; a new hire (8 weeks in) still routes all questions through the tech lead instead of peers.
Player quality: The new hire is set up to fail by circumstance, not skill -- no assigned onboarding buddy, and the one person who could mentor them is the same overloaded tech lead.
Momentum: No recurring team retro; the last one was 3 months ago, right before the new hire joined.
Highest-leverage action: Assign an onboarding buddy other than the tech lead this week -- it addresses both the "set up to fail" finding and starts spreading review load off one person.