team-health

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Team Health

团队健康

Before Starting

开始前

Check for EM context first. If

.agents/em-context.md

exists, read it.

.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

.agents/reports/[name].md

automatically. Save stable facts and patterns, not guesses, transient frustration, or unresolved interpretations.

首先检查是否有工程经理（EM）相关背景信息。如果

.agents/em-context.md

文件存在，请先阅读。

如果

.agents/em-context.md

不存在，先询问并保存一份基础的经理信息，再提供详细建议：职位/头衔、团队规模、团队使命或负责领域，以及当前面临的挑战或优先级。

如果对话核心涉及特定人员，且

.agents/reports/[name].md

文件不存在，先询问并保存该人员的基础信息，再提供详细建议：职位/级别、任职时长、优势，以及当前面临的挑战或成长方向。

如果后续对话中出现可长期留存的新信息，请自动更新

.agents/em-context.md

或

.agents/reports/[name].md

。仅保存稳定的事实和模式，不保存猜测、暂时的情绪或未明确的解读。

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

首次回答需简洁实用。除非用户要求深入讲解，否则不要全盘输出整个框架。

默认遵循以下原则：

先给出可能的诊断或建议
仅在缺失信息会影响建议时，提出最多2-3个针对性问题
给出下一步具体行动，必要时提供经理可直接使用的话术
简要提及相关框架，但无需解释每个部分
在直接回答后，再提供深入版本的选项

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

不知从何入手/需要健康诊断 → 高效团队的5大要素
团队进度缓慢、落后于承诺或出现burnout → 团队健康状态模型
团队处于不可持续的工作节奏 → 团队强度管理
有人提出“团队不够努力” → “团队不够努力”问题处理
团队看起来缺乏参与感或彼此疏离 → 参与度层级模型（Engagement Stack）
计划团队会议，需要内容创意 → 团队会议指南
计划团队线下会议或聚焦日 → 团队聚焦日指南
需要按驱动因素分类的活动创意库（成长/联结/影响力） → 阅读
```
references/activities.md
```
回顾会议反复出现相同问题 → 回顾会议陷入重复的应对方法
团队成员间缺乏信任 → 信任电池（Trust Battery）
出现故障，需要开展事后复盘 → 无责事后复盘
团队技术能力强，但凝聚力薄弱 → 高效协作团队（Jelled Teams）与团队瓦解模式（Teamicide）
不确定该向团队分享多少信息 → 透明度作为团队健康信号
想要构建灵活工作模式，同时避免监控文化 → 公开休假（Leave Loudly）

Default Response Shape

默认回应结构

When helping with team health, diagnose before prescribing activities:

Health read: morale, safety, dependability, clarity, intensity, trust, or engagement.
Evidence: what the user observed and what it likely means.
Immediate stabilizer: what to do this week.
Structural intervention: meeting, ritual, transparency change, recovery plan, retro change, or activity.
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.

在处理团队健康问题时，先诊断再给出活动建议：

健康评估：士气、安全感、可靠性、清晰度、强度、信任或参与度。
依据：用户观察到的现象及其潜在含义。
即时稳定措施：本周可采取的行动。
结构性干预：会议、常规流程、透明度调整、恢复计划、回顾会议改进或活动。
观察信号：需要监控哪些指标来判断团队是否有所改善。

如果团队处于burnout或高强度状态，先解决恢复和优先级问题，再提出士气提升活动。

The 5 Factors of Effective Teams

高效团队的5大要素

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

Psychological safety — Can team members take risks without feeling insecure or embarrassed?
Dependability — Can team members count on each other to do high-quality work on time?
Structure & clarity — Are goals, roles, and execution plans clear?
Meaning — Is the work personally important to each team member?
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.

Google的Project Aristotle研究了数百个团队，找出了真正影响团队效能的关键因素。按重要性排序的Top5要素：

心理安全（Psychological safety） —— 团队成员能否在不感到不安或尴尬的情况下承担风险？
可靠性（Dependability） —— 团队成员能否相互依赖，按时完成高质量工作？
结构与清晰度（Structure & clarity） —— 目标、角色和执行计划是否清晰？
意义（Meaning） —— 工作对每个团队成员来说是否具有个人重要性？
影响力（Impact） —— 团队是否相信自己的工作有价值？

排序至关重要。这五个要素缺一不可，但心理安全是基础——没有它，其他要素无法发挥作用。当人们害怕被评判时，就不会提出顾虑、分享想法或指出问题。

实用方法：开展一个简短的团队活动，让每个人为每个要素打分（1-5分）。找出平均分最低的要素——这就是你最需要关注的领域，而非你认为最紧急的那个。

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.

当被问到“你的团队是谁”时，经理几乎总是列出自己的直接下属，而不会提到同级。

但经理的同级群体也是一个团队——上述5大要素同样适用于他们。如果工程经理将同级关系视为纯粹的交易（或竞争）关系，就会导致团队孤岛：缺乏知识共享、跨团队协作缓慢，且在边界出现问题时互相指责。

你投入在培养下属信任、冲突处理、问责制和承诺上的精力，同样要投入到与同级EM的关系中。

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.

State	What it looks like	What to do
Falling behind	Backlog grows every sprint; team feels overwhelmed; commitments slip	Add capacity. This is the only state where hiring directly helps. In the short term: reduce the scope of what you're committing to and communicate that to stakeholders honestly.
Treading water	Team is shipping, but only product work — no tech debt addressed, no improvements	Reduce WIP. Focus the team on fewer things. Create space by finishing existing work before starting new work.
Repaying debt	Team is actively working down tech debt; velocity feels slower	Protect the work. Shield the team from new product demands until the debt is paid. This state is temporary and necessary — don't let urgency interrupt it.
Innovating	Low tech debt, stable delivery, team has headspace to experiment	Preserve it carefully. This state is fragile. Only add work that's compatible with the team's current way of working. The wrong new hire or the wrong project can push you back to Treading water fast.

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.

出自《An Elegant Puzzle》（Will Larson）：团队在任何时候都处于以下四种状态之一，每种状态都需要EM采取不同的应对措施。

状态	表现	应对措施
落后（Falling behind）	待办事项在每个迭代中不断增加；团队感到不堪重负；无法兑现承诺	增加人力。这是唯一直接通过招聘就能解决的状态。短期措施：缩小承诺范围，并诚实地与利益相关方沟通。
维持现状（Treading water）	团队能交付产品工作，但未处理技术债，也没有任何改进	减少在办工作（WIP）。让团队专注于更少的事项。先完成现有工作，再启动新工作，以此创造空间。
偿还技术债（Repaying debt）	团队积极处理技术债；交付速度变慢	保护这项工作。在技术债偿还完成前，避免让团队承担新的产品需求。这个状态是暂时且必要的——不要让紧急事务打断它。
创新（Innovating）	技术债少，交付稳定，团队有精力开展实验	小心维护这个状态。它很脆弱。只添加与团队当前工作方式兼容的任务。不合适的新员工或项目会迅速让团队回到维持现状的状态。

最常见的错误：对所有状态一视同仁。推动“落后”的团队同时偿还技术债行不通；在维持现状时尝试创新也行不通。先诊断当前状态，再采取正确的应对措施。

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.

大多数工程经理对团队会议投入不足——要么完全跳过（太忙，怕浪费时间），要么无议程开会。常见借口：“等我有好内容再做议程。”结果是一年只开3次会。

团队会议能创造一对一沟通无法替代的共享背景、共同记忆和联结。

7 Ideas for Meeting Content

7种会议内容创意

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.
Post-mortem of a recent incident: Go over what happened and brainstorm as a team on how to prevent the next one.
A developer shares a project they worked on: Improves their presentation skills; the rest of the team learns something new.
Interesting projects from elsewhere in the company: New PoCs with clients, technical work other teams are doing.
Business updates: You know things your team typically doesn't. Share sales updates, usage metrics, plans for the next funding round.
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
Fun: Lunch together, a short game. For remote teams, something like Drawize.

下一个项目回顾：它如何契合路线图，为何被选中，要实现什么目标。这不是技术启动会的替代品——而是用于背景介绍和对齐。
近期事件的事后复盘：回顾事件经过，团队集体 brainstorm 如何预防类似事件再次发生。
开发者分享自己的项目：提升他们的演讲技能；其他团队成员也能学到新知识。
公司其他团队的有趣项目：与客户的新PoC、其他团队正在开展的技术工作。
业务更新：你知道一些团队通常不了解的信息。分享销售更新、使用数据、下一轮融资计划。
邀请嘉宾:
- 销售代表——在启动重大项目前，让他们分享客户背景以及项目是如何赢得的
- 设计师——他们的工作方式、关注重点、决策依据
- 产品副总裁——他们的议程、对路线图的看法、未来6个月的计划
- 你的直属经理——尤其是在不确定时期
- 其他团队负责人、架构师、支持人员、客户成功人员或任何跨职能角色
趣味活动：一起吃午餐、玩小游戏。远程团队可以用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.

没有通用答案。每周30分钟可能难以持续保持质量。合理的起点是：每月两次，每次30分钟——然后根据实际效果调整。

最重要的是：先启动，不要取消。在你说服自己放弃之前，先创建 recurring 会议。

Team Focus Days

团队聚焦日

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

How the team communicates — not just what they communicate, but how
How they handle conflict — whether they address it or let it fester
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.

离开办公室：不同的环境会改变互动模式。租一个其他地方的会议室、去联合办公空间或找一个线下场地都可以。关键是：不在日常工作环境。
每6个月一次：频率足够产生意义，又不会过于频繁而失去特殊性。
邀请产品经理（PM）参与：这不是仅面向工程师的活动。如果你有PM合作伙伴，他们应该参与。面对面的沟通最能实现共享背景和对齐。
兼顾工作与联结：不要整天开会，也不要整天搞活动。两者都很重要。

10 Ideas for Focus Day Content

10种聚焦日内容创意

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

路线图回顾：梳理团队的前进方向及原因。未来6个月的计划是什么，做出了哪些权衡。
技术债审计：哪些问题在拖团队后腿？让工程师公开提出。
回顾会议：过去6个月哪些做法有效？哪些无效？
“我希望我们多做X”：每个人提出一件事，不做评判，然后排序优先级。
跨团队动态：与其他团队有任何摩擦吗？面对面更容易暴露问题。
流程回顾：站会、代码评审、部署——哪些有效，哪些是冗余的？
结对职业对话：安排结构化时间，让工程师分享自己的职业发展方向。
黑客松或原型开发时间：构建实验性项目，没有交付压力。
互相教学：每个人用10分钟分享一个其他人不知道的技能。
共享餐食或活动：以社交活动结束。不要强制“趣味”——选择大家都认可的活动。

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

团队强度管理

Not every week should feel the same. Teams that run at full sprint indefinitely burn out. Teams that coast lose edge. The skill is knowing what zone you're in — and choosing it consciously.

A simple 5-zone model, borrowed from endurance training:

Zone	Feel	When to use
1 — Very light	Calm, sustainable, low pressure	Recovery after intense periods; onboarding new members
2 — Light	Steady output, no crunch	Default healthy pace for most of the year
3 — Moderate	Focused, some urgency	Normal sprint periods, regular delivery cycles
4 — Hard	High energy, tight deadlines	Product launches, critical milestones
5 — Maximum	All-in, not sustainable	True crises only — production outages, make-or-break moments

The mistake most EMs make: defaulting to Zone 4 as the steady state. Zone 4 feels productive. It looks like commitment. But it has a ceiling — teams can't sustain it, and the recovery cost is high.

How to use this:

Name the zone explicitly. "This sprint we're at Zone 4 because of the launch." The team tolerates intensity better when it has a name and an end date.
After Zone 4 or 5 periods, plan Zone 2 recovery. Don't immediately load the next hard sprint.
If your team is always in Zone 3–4 without recovery, that's a workload problem, not a motivation problem.

不是每个星期都应该节奏相同。长期处于全力冲刺状态的团队会burnout；长期松懈的团队会失去竞争力。关键是清楚自己处于哪个区间——并有意识地选择。

一个简单的5区间模型，借鉴自耐力训练：

区间	感受	使用场景
1 — 极轻松	平静、可持续、低压力	高强度阶段后的恢复期；新成员入职培训
2 — 轻松	稳定输出，无赶工	全年大部分时间的健康默认节奏
3 — 中等	专注，有一定紧迫感	常规迭代周期、日常交付
4 — 紧张	高能量，截止日期紧迫	产品发布、关键里程碑
5 — 极限	全力以赴，不可持续	仅用于真正的危机——生产故障、生死攸关的时刻

大多数EM常犯的错误：默认将区间4作为稳定状态。区间4看起来高效，像是有责任心，但它有上限——团队无法长期维持，且恢复成本很高。

使用方法：

明确说出当前区间。“这个迭代我们处于区间4，因为要发布产品。”当强度有明确名称和结束日期时，团队更容易接受。
在区间4或5之后，安排区间2的恢复期。不要立即加载下一个紧张的迭代。
如果团队总是处于区间3-4且没有恢复期，这是工作量问题，而非动机问题。

"The Team Isn't Working Hard Enough"

“团队不够努力”问题处理

If someone tells you your team isn't working hard enough, don't dismiss it and don't accept it uncritically. There are three distinct root causes — and each requires a different response:

Lack of "hustle" — an external person sees no visible effort signals. People seem relaxed, unhurried, and don't look busy. This is often a perception gap, not a performance gap — especially in remote environments.
Lack of visible output — poor communication, unreasonable expectations, or poor prioritization. The team is working but progress isn't visible to stakeholders. This is a communication/transparency problem.
Lack of passion — the team seems unmotivated or detached. This is a morale and engagement problem.

In all three cases: don't dismiss the feedback. Find ways to bridge the gap between what you see and what the feedback-giver sees. Often, making the work more visible (more frequent updates, clearer progress communication) is enough.

如果有人说你的团队不够努力，不要忽视也不要盲目接受。有三种截然不同的根本原因——每种都需要不同的应对措施：

缺乏“ hustle” —— 外部人员看不到明显的努力信号。人们看起来放松、从容，不显得忙碌。这通常是认知差距，而非绩效差距——尤其是在远程环境中。
缺乏可见产出 —— 沟通不畅、期望不合理或优先级不当。团队在工作，但利益相关方看不到进展。这是沟通/透明度问题。
缺乏热情 —— 团队看起来缺乏动力或疏离。这是士气和参与度问题。

在所有情况下：不要忽视反馈。找到弥合你看到的情况和反馈者看到的情况之间差距的方法。通常，让工作更可见（更频繁的更新、更清晰的进展沟通）就足够了。

Leave Loudly — and Don't Ask for Permission

公开休假——无需申请

When a developer tells you they'll continue working from home, don't say "ok" — that implies they need to explain themselves or seek approval.

Instead, say something like: "I trust you to manage your own time — no need to mention it when you continue from home."

Then model it yourself. When you leave early, don't add "I'll continue working after the kids go to sleep." Just leave. Announce it without the justification. This signals that you trust people to manage their own time without surveillance — which is what psychological safety around flexible work actually looks like.

当开发者告诉你他们要继续居家办公时，不要说“好的”——这暗示他们需要解释自己或寻求批准。

相反，可以说：“我相信你能管理好自己的时间——以后居家办公不用特意说。”

然后自己以身作则。当你提前下班时，不要补充“我会在孩子睡觉后继续工作”。直接离开。无需理由地宣布。这表明你信任人们在没有监控的情况下管理自己的时间——这正是灵活工作场景下心理安全的体现。

When Retros Feel Repetitive

回顾会议陷入重复的应对方法

If retros keep surfacing the same issues without resolution, try:

Different questions. The 4Ls format (Liked, Learned, Lacked, Longed for) changes what people surface.
Different tools. Online retro tools (EasyRetro, Parabol, etc.) can re-engage people who've gone through the motions too many times.
A meta-retro. Summarize the last 6 months of retros. What themes keep appearing? Why haven't they been resolved?
"Reveal at end" format. Everyone writes items without seeing others'. Reveal all at once. Reduces anchoring.

The deeper issue behind retro déjà vu is usually that the output doesn't lead to action. Before changing the format, check whether anything from previous retros was ever actually addressed.

如果回顾会议反复出现相同问题却无法解决，可以尝试：

更换问题：4Ls格式（Liked、Learned、Lacked、Longed for）会改变人们提出的内容。
更换工具：在线回顾工具（EasyRetro、Parabol等）可以重新吸引那些已经应付了事的人。
元回顾：总结过去6个月的回顾会议。哪些主题反复出现？为什么没有解决？
“最后展示”格式：每个人写下内容但不看其他人的，最后一起展示。减少锚定效应。

回顾会议陷入重复的深层原因通常是输出没有转化为行动。在改变格式前，先检查之前回顾会议的结论是否真的被执行过。

The Engagement Stack

参与度层级模型（Engagement Stack）

Individual engagement requires four layers to be aligned — each depends on the one below:

The individual — is this person fundamentally energized at work?
The role — does the work use their strengths and grow them?
The team — do they feel connected and respected by their peers?
The company — do they believe in the direction and feel proud of where they work?

When someone is disengaged, find out which layer broke first. Fixing company communication won't help someone who's in the wrong role. Fixing the role won't help someone who has a bad team dynamic.

个人参与度需要四个层级对齐——每个层级都依赖于下一层：

个人层面 —— 这个人在工作中是否充满活力？
角色层面 —— 工作是否能发挥他们的优势并促进成长？
团队层面 —— 他们是否感到与同事联结并受到尊重？
公司层面 —— 他们是否认同公司方向并为公司感到自豪？

当有人缺乏参与度时，找出哪个层级先出了问题。修复公司沟通无法帮助一个处于错误角色的人；修复角色无法帮助一个团队动态糟糕的人。

Engineers' Emotional State as a Performance Signal

工程师的情绪状态作为绩效信号

Tense before standup. Exhausted after every sprint. Frustrated about decisions they had no input into. These are not personal problems — they're team health signals.

Nobody performs at their best when their body is in a stress state. Ask "How did you feel this week?" in 1:1s — not as a therapy question, but as a diagnostic one. Give space for a real answer.

If someone's nervous system is consistently in threat mode at work, that's an environment problem as much as a performance problem.

站会前紧张、每个迭代后疲惫、对自己没有参与的决策感到沮丧。这些不是个人问题——而是团队健康信号。

当身体处于压力状态时，没有人能发挥最佳水平。在一对一沟通中问*“你这周感觉如何？”*——不是作为心理咨询问题，而是作为诊断问题。给对方空间给出真实答案。

如果有人在工作中持续处于应激状态，这既是环境问题，也是绩效问题。

Jelled Teams and Teamicide

高效协作团队（Jelled Teams）与团队瓦解模式（Teamicide）

From Peopleware (DeMarco & Lister): a jelled team is one that has coalesced into a cohesive unit — members trust each other, move in sync, and collectively outperform what you'd predict from individual skill levels. Jelled teams are genuinely rare and disproportionately valuable.

What jelling requires:

Enough time working together to build shared context and trust
A challenge worth caring about — not just assigned work, but a goal the team has ownership over
Freedom from bureaucratic friction that breaks flow and signals management distrust

Teamicide — the patterns that destroy cohesion:

Factor	What it looks like
Defensive management	Micromanagement, second-guessing decisions, checking in constantly — signals you don't trust the team
Separated workspace	Open offices that make deep work impossible; remote setups without shared async norms
Fragmented work	Team members constantly switching between unrelated projects; no one gets to finish anything
Quality reduction for schedule	Forcing shortcuts that engineers know are wrong — kills pride of craft
Phony deadlines	Artificial urgency; "this is critical" for every sprint — engineers learn urgency means nothing
Clique control	Managers who treat a subset of the team as the inner circle and the rest as implementers

You can do many things right and still destroy a jelled team with one of these. The most common is defensive management disguised as staying involved.

出自《Peopleware》（DeMarco & Lister）：高效协作团队是指凝聚成一个紧密整体的团队——成员相互信任、步调一致，整体表现远超个人技能的总和。这类团队非常罕见，且价值极高。

形成高效协作团队的条件：

足够的共事时间，以建立共享背景和信任
值得投入的挑战——不仅仅是分配的工作，而是团队拥有自主权的目标
没有破坏工作流、暗示管理层不信任的官僚主义障碍

团队瓦解模式（Teamicide）——破坏凝聚力的行为：

因素	表现
防御式管理	微观管理、质疑决策、频繁检查——暗示你不信任团队
分散的工作空间	开放式办公室无法进行深度工作；远程设置缺乏共享的异步规范
碎片化工作	团队成员不断切换无关项目；没有人能完成任何事情
为赶进度牺牲质量	强迫工程师采取他们明知错误的捷径——扼杀职业自豪感
虚假截止日期	人为制造紧迫感；每个迭代都“至关重要”——工程师会觉得紧迫感毫无意义
小团体控制	经理将部分团队视为核心圈子，其余人仅作为执行者

你可能做对了很多事，但只要犯其中一个错误，就能毁掉一个高效协作团队。最常见的是伪装成“保持参与”的防御式管理。

Trust Battery

信任电池（Trust Battery）

From It Doesn't Have to Be Crazy at Work (Basecamp/Fried): every relationship between two people has an implicit trust battery, starting at around 50%.

The battery charges when someone does what they say they'll do — responds when they said they would, ships what they committed to, handles a situation the way they promised. It discharges when they don't.

Trust isn't primarily built by being warm, friendly, or enthusiastic. It's built by delivery. The engineer who quietly ships what they committed to, every sprint, has a fuller battery with their colleagues than the one who makes everyone feel great but misses constantly.

Practical use:

When someone on the team is struggling socially — colleagues seem cold or disengaged — look at their delivery record before concluding it's a personality issue. A discharged battery often looks like a relationship problem.
When a new hire seems isolated, they haven't had time to charge the battery yet. Giving them small, visible wins early charges it faster than any onboarding activity.
As a manager, your own battery with the team is the foundation of everything. They watch whether you deliver on what you said, whether you fight for the things you promised to fight for.

出自《It Doesn't Have to Be Crazy at Work》（Basecamp/Fried）：人与人之间的每段关系都有一个隐含的信任电池，初始电量约为50%。

当人们兑现承诺时——按时回复、交付承诺的工作、按约定处理情况——电池充电。当他们不兑现时，电池放电。

信任主要不是通过热情友好建立的，而是通过交付成果建立的。每个迭代都默默兑现承诺的工程师，与同事的信任电池电量，比那些让大家感觉良好但经常违约的工程师更满。

实用方法：

当团队中有人社交困难——同事看起来冷漠或疏离——先查看他们的交付记录，再判断是性格问题。电量耗尽的电池通常看起来像人际关系问题。
当新员工感到孤立时，他们还没有时间给电池充电。让他们尽早获得小而可见的成果，比任何入职活动都能更快地充电。
作为经理，你与团队的信任电池是一切的基础。他们会观察你是否兑现承诺，是否为你承诺争取的事情而努力。

Blameless Postmortems

无责事后复盘

When something breaks — a production incident, a failed deployment, a major bug — the traditional response is to find the person responsible and correct them. Etsy's approach (which became the industry standard) is different: assume that people acted with the best information and tools they had at the time. The goal is not to find who caused the problem, but to understand how the system allowed it to happen.

Why blame-first postmortems backfire:

People self-censor. They hide what happened or minimize their role.
You lose the detailed picture of what actually occurred.
You fix the person instead of the system — and the next person makes the same mistake.

What a blameless postmortem looks like:

Construct a timeline of events without attributing blame. What happened, in sequence, not "who did what wrong."
Ask: what did people know at the time of each decision? They almost certainly made the best decision available with the information they had.
Ask: what would have had to be different for this not to happen? Usually the answer involves tooling, processes, missing alerts, or insufficient context — not individual negligence.
Capture action items that change the system, not just people's behavior.

The EM's role: model the tone. If you're leading the postmortem and you're looking for a villain, the team will protect themselves. If you're genuinely curious about what the system allowed, they'll tell you the truth.

Blameless doesn't mean consequence-free. Repeated individual negligence or deliberate violations are different situations. But they're the exception, not the default explanation.

当出现故障——生产事故、部署失败、重大bug——传统做法是找到责任人并纠正他们。Etsy的方法（已成为行业标准）不同：假设人们是根据当时掌握的最佳信息和工具采取行动的。目标不是找出谁导致了问题，而是理解系统为何允许问题发生。

追责式事后复盘的弊端：

人们会自我审查。他们会隐瞒发生的事情或淡化自己的角色。
你会失去对事件全貌的了解。
你只修正了人，而非系统——下一个人还会犯同样的错误。

无责事后复盘的流程：

构建事件时间线，不追究责任。只按顺序记录发生了什么，而非“谁做错了什么”。
提问：每个决策做出时，人们知道什么？他们几乎肯定是根据当时掌握的信息做出了最佳决策。
提问：需要做出哪些改变才能避免这个问题？答案通常涉及工具、流程、缺失的警报或不足的背景——而非个人疏忽。
记录改变系统的行动项，而非仅仅改变人们的行为。

EM的角色： 树立正确的基调。如果你主导复盘却在找替罪羊，团队会自我保护。如果你真的好奇系统为何允许问题发生，他们会告诉你真相。

无责并不意味着没有后果。反复的个人疏忽或故意违规是不同的情况，但这是例外，而非默认解释。

Dive Deeper

深入学习

If the user asks where a framework came from, wants to read the original article, or wants more context on any topic in this skill — read

references/sources.md

. For a library of team activity ideas organized by driver (Growth / Connection / Impact), read

references/activities.md

如果用户询问某个框架的来源、想要阅读原文或需要任何主题的更多背景信息——阅读

references/sources.md

。如需按驱动因素（成长/联结/影响力）分类的团队活动创意库，阅读

references/activities.md

。