manager-dot-dev/manager-skills/team-health

Team Health

Before Starting

Check for EM context first. If .agents/em-context.md exists, read it.

If .agents/em-context.md does not exist, ask for a minimal manager profile first and save it before giving detailed advice: role/title, team size, team mission or ownership area, and current challenge or priority.

If a specific person is central to the conversation and .agents/reports/[name].md does not exist, ask for a minimal profile for that person first and save it before giving detailed advice: title/level, tenure, strengths, and current challenge or growth area.

If the conversation reveals durable new context later, update .agents/em-context.md or .agents/reports/[name].md automatically. Save stable facts and patterns, not guesses, transient frustration, or unresolved interpretations.

Response Style

Keep the first answer concise and useful. Do not dump the whole framework unless the user asks for depth.

Default to:

• State the likely diagnosis or recommendation first
• Ask at most 2-3 targeted questions only if the missing context changes the advice
• Give the next concrete action and, when useful, exact wording the manager can use
• Mention the relevant framework briefly, but do not explain every part of it
• Offer a deeper version only after the direct answer

How to Use This Skill

• Don't know where to start / need a health diagnostic → The 5 Factors of Effective Teams
• Team is slow, behind on commitments, or burning out → Team Health States
• Team is running at an unsustainable pace → Managing Team Intensity
• Someone said "the team isn't working hard enough" → "The Team Isn't Working Hard Enough"
• Team seems disengaged or disconnected → The Engagement Stack
• Planning a team meeting and need content ideas → Team Meetings
• Planning a team offsite or focus day → Team Focus Days
• Want a library of activity ideas (Growth / Connection / Impact) → read `references/activities.md`
• Retros keep surfacing the same issues → When Retros Feel Repetitive
• Team members don't seem to trust each other → Trust Battery
• Something broke — need to run a postmortem → Blameless Postmortems
• Team is technically strong but cohesion feels fragile → Jelled Teams and Teamicide
• Unsure how much to share with the team → Transparency as a Team Health Signal
• Want to model flexible work without creating a surveillance culture → Leave Loudly

Default Response Shape

When helping with team health, diagnose before prescribing activities:

1. Health read: morale, safety, dependability, clarity, intensity, trust, or engagement.
2. Evidence: what the user observed and what it likely means.
3. Immediate stabilizer: what to do this week.
4. Structural intervention: meeting, ritual, transparency change, recovery plan, retro change, or activity.
5. Watch signal: what to monitor to know if the team is improving.

If the team is in burnout or high-intensity mode, address recovery and priorities before suggesting morale activities.

The 5 Factors of Effective Teams

Google's Project Aristotle studied hundreds of teams to find what actually makes them effective. The top 5 factors, in order of importance:

1. Psychological safety — Can team members take risks without feeling insecure or embarrassed?
2. Dependability — Can team members count on each other to do high-quality work on time?
3. Structure & clarity — Are goals, roles, and execution plans clear?
4. Meaning — Is the work personally important to each team member?
5. Impact — Does the team believe their work matters?

The order matters. All five are necessary, but psychological safety is foundational — without it, the others don't activate. People don't raise concerns, share ideas, or flag problems when they fear judgment.

A practical way to use this: run a short team exercise where each person scores each factor (1–5). Look at where the scores are lowest. The lowest factor by average score is your most important focus area — not the one that feels most urgent to you.

Your Peer Team Matters Too

When managers are asked "who is your team?", they almost always list their direct reports. Never their peers.

But a manager's peer group is also a team — and the same five factors apply to it. Engineering managers who treat peer relationships as purely transactional (or competitive) create the conditions for silos: no knowledge sharing, slow cross-team coordination, and blame when things go wrong at the boundaries.

The same trust, conflict, accountability, and commitment that you invest in building with your reports — invest it with your peer EMs too.

Team Health States

From An Elegant Puzzle (Will Larson): teams exist in one of four states at any given time, each requiring a different response from the EM.

The most common mistake: treating all states the same. Pushing a "Falling behind" team to also repay debt doesn't work. Trying to innovate while treading water doesn't work. Diagnose the current state first, then apply the right response.

Team Meetings

Most engineering managers underinvest in team meetings — either skipping them entirely (too busy, afraid of wasting time) or running them without an agenda. The common excuse: "I'll create one when I have something good to say." The result: 3 meetings a year.

Team meetings create shared context, shared memory, and connection that 1:1s can't replace.

7 Ideas for Meeting Content

1. Review the next project: How it fits the roadmap, why it was chosen, what you're trying to achieve. Not a substitute for a technical kickoff — this is for context and alignment.

1. Post-mortem of a recent incident: Go over what happened and brainstorm as a team on how to prevent the next one.

1. A developer shares a project they worked on: Improves their presentation skills; the rest of the team learns something new.

1. Interesting projects from elsewhere in the company: New PoCs with clients, technical work other teams are doing.

1. Business updates: You know things your team typically doesn't. Share sales updates, usage metrics, plans for the next funding round.

1. Bring a guest:

• A sales representative — before starting a major project, have them share context on the customer and how the project was won
• The designer — how they work, what matters to them, what guides their decisions
• The VP Product — their agenda, how they see the roadmap, the next 6 months
• Your own manager — especially during periods of uncertainty
• Other team leaders, architects, support, customer success, or any cross-functional role

1. Fun: Lunch together, a short game. For remote teams, something like Drawize.

Cadence

There's no universal answer. Weekly 30 minutes is probably too much to sustain with quality. A reasonable starting point: 30 minutes, twice a month — then adjust based on how it's going.

The most important thing: start, then don't cancel. Create the recurring meeting before you talk yourself out of it.

Team Focus Days

The difference between great and average teams often shows up in three places:

1. How the team communicates — not just what they communicate, but how
2. How they handle conflict — whether they address it or let it fester
3. How connected they feel to each other as people, not just coworkers

Team Focus Days are a structured way to work on all three. The concept: take the team out of the office for a full day, twice a year, with a mix of work and connection.

The Format

• Outside the office. A different environment changes the dynamic. Renting a meeting room somewhere else, going to a co-working space, or finding an off-site venue all work. The point is: not your usual setting.
• Every 6 months. Frequent enough to be meaningful, infrequent enough that it stays special.
• Include the PM. This is not an engineering-only day. If you have a PM partner, they should be there. Shared context and alignment happen best in person.
• Mix work and connection. Not all day in a meeting room, not all day at an activity. Both matter.

10 Ideas for Focus Day Content

1. Roadmap review: Walk through where you're going and why. What's coming in the next 6 months and what trade-offs were made.
2. Technical debt audit: What's slowing the team down? Let engineers name it openly.
3. Retrospective: What worked in the last 6 months? What didn't?
4. "I wish we did more of X": Each person names one thing. No judgment. Then prioritize.
5. Cross-team dynamics: Any friction with other teams? Surfaces better in person.
6. Process review: Standups, code review, deployments — what's working, what's overhead?
7. Career conversations in pairs: Structured time for engineers to share where they're headed.
8. Hackathon or prototype time: Build something experimental. No pressure to ship.
9. Teach each other: Each person does a 10-minute share on something they know that others don't.
10. Shared meal or activity: End with something social. Not mandatory fun — something chosen together.

Transparency as a Team Health Signal

What you share (and don't share) with your team shapes their trust in you and in the company.

Don't be a shit umbrella. Managers who shield their teams from every difficult reality think they're protecting people. What they're actually doing is creating a team that's perpetually surprised by bad news and has no way to prepare or respond. Some information is genuinely confidential. But most "bad news" should be shared.

The disappointment frontier. Share information that your team will eventually learn anyway — about roadmap changes, reorgs, financial pressures, strategy shifts. If they find out from someone else, or after the fact, you've damaged your credibility. Better to share early, even if the news is uncertain.

Share the financial situation. Developers who understand how the business is doing make better decisions — they understand urgency, scope, and trade-offs. You don't need to show spreadsheets. But "we had a strong quarter and we have runway to invest" vs. "it's been a tough few months and we need to be efficient" changes how people think about their work.

Think of it like a ship: everyone on a ship knows if it's sinking. The crew doesn't need a board meeting to understand the situation. Give your team enough context to be crew, not passengers.

Share the roadmap draft. Before priorities are finalized, share what's being considered and why. People can handle a draft. What they can't handle is being handed a finished plan they had no visibility into.

Managing Team Intensity