managing-yourself

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Managing Yourself

自我管理

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

如何使用此技能

Identify the situation first:

Feeling stuck or wondering if you're doing the EM job right → The 10 Ways EMs Get Stuck (start here)
Things keep going wrong and you feel like the victim → The Drama Triangle
Having lots of bad management days → Why Managers Have More Bad Days
Team seems unmotivated or output is low → Clear the Path
Made a mistake with someone and need to recover → Repair
The same problem keeps coming back no matter how you solve it → Problems vs. Polarities
Your strength as an EM is becoming a failure mode → read
```
references/extended.md
```
— The Dichotomies
Feeling disconnected from the big picture / product → read
```
references/extended.md
```
— Balcony Awareness
Facing unexpected criticism, VP grilling, or a major outage → read
```
references/extended.md
```
— Staying Calm: The BAA Framework
Auditing how your time is split across growth / connection / impact → read
```
references/extended.md
```
— The EM Grid
Maintaining coding skills or staying hands-on → read
```
references/extended.md
```
— The Maker/Manager Mode
Getting feedback on management decisions before acting → read
```
references/extended.md
```
— Code-Reviewing Your Own Decisions
Writing your own performance review → read
```
references/extended.md
```
— Your Manager Delta
Diagnosing low engagement or bad team culture → read
```
references/extended.md
```
— The Inversion Model
Auditing your own time allocation → read
```
references/extended.md
```
— The LNO Framework
Something went wrong and you're figuring out what you missed → read
```
references/extended.md
```
— Extreme Ownership
Team is scared or anxious during a hard period → read
```
references/extended.md
```
— The Leader Absorbs Fear
Anything about your manager, managing up, or senior leadership → use
```
managing-up
```
skill

先明确场景：

感觉陷入瓶颈或质疑自身EM工作表现 → 参考《EM陷入瓶颈的10种常见情形》（从这里开始）
问题不断出现，感觉自己是受害者 → 参考《戏剧三角模型》
频繁遭遇糟糕的管理工作日 → 参考《为何经理会有更多不顺的日子》
团队看似缺乏动力或产出低下 → 参考《清除障碍法》
对他人犯错后需要修复关系 → 参考《修复方法》
无论如何解决，同一问题反复出现 → 参考《问题与极性》
自身的EM优势正在演变为失效模式 → 阅读
```
references/extended.md
```
中的《二分法》
感觉与大局/产品脱节 → 阅读
```
references/extended.md
```
中的《全局视野》
面临突发批评、VP质询或重大故障 → 阅读
```
references/extended.md
```
中的《保持冷静：BAA框架》
评估自身时间在成长/沟通/影响上的分配 → 阅读
```
references/extended.md
```
中的《EM时间分配网格》
维持编码技能或保持实操参与度 → 阅读
```
references/extended.md
```
中的《创造者/管理者模式》
在执行前获取对管理决策的反馈 → 阅读
```
references/extended.md
```
中的《自我决策代码评审》
撰写个人绩效评估 → 阅读
```
references/extended.md
```
中的《经理成长增量》
诊断团队低参与度或不良文化 → 阅读
```
references/extended.md
```
中的《反转模型》
评估自身时间分配 → 阅读
```
references/extended.md
```
中的《LNO框架》
出错后反思自己遗漏了什么 → 阅读
```
references/extended.md
```
中的《极致责任》
团队在困难时期感到恐惧或焦虑 → 阅读
```
references/extended.md
```
中的《领导者承接恐惧》
任何关于直属经理、向上管理或高层领导的问题 → 使用
```
managing-up
```
技能

Default Response Shape

默认响应结构

When helping an EM self-diagnose, be concrete and non-therapeutic:

Pattern: which trap, polarity, bad-day cause, or repair need is showing up.
Cost: how it affects the team, manager, peers, or the EM's own judgment.
Reframe: the more useful interpretation of the situation.
Next action: one behavior to try this week.
Reflection question: what to observe afterward.

If the EM sounds overwhelmed, reduce the advice to one next move rather than listing every framework.

帮助EM自我诊断时，需具体且避免过于偏向心理疏导：

模式识别： 指出当前出现的是哪种误区、极性问题、不顺日子的诱因或需要修复的情况。
影响分析： 说明该情况对团队、经理、同事或EM自身判断力的影响。
重构认知： 给出更具建设性的场景解读。
下一步行动： 提出本周可尝试的一个具体行为。
反思问题： 指出后续需要观察的内容。

若EM表现出压力过大，建议简化为仅一个下一步行动，而非列出所有框架。

The 10 Ways EMs Get Stuck

EM陷入瓶颈的10种常见情形

Most experienced EMs are guilty of at least 5 of these.

大多数资深EM至少会犯其中5种。

1. Ignoring Destructive Behaviors

1. 忽视破坏性行为

What you permit, you promote. The longer you ignore a behavior, the harder it is to address. The developer won't magically change on their own. Now is always the best time to have the conversation, no matter how much time has passed.

你默许的行为，就是在助长它。忽视的时间越长，后续解决的难度就越大。开发者不会自行改变。无论过去多久，现在都是开启对话的最佳时机。

2. Trying to Please Everyone

2. 试图取悦所有人

The instinct to be liked leads to encouraging bad ideas, agreeing to unreasonable deadlines, and avoiding hard conversations. You'll have to learn to disappoint people and stand your ground.

渴望被喜欢的本能会导致你支持糟糕的想法、同意不合理的截止日期、回避艰难对话。你必须学会拒绝他人并坚持立场。

3. Fighting Too Hard for Your Principles

3. 过度坚守个人原则

Not every hill is worth fighting on. Ask yourself "why is this so important to me?" before going to war over something. Some principles are load-bearing; many aren't. (Example: fighting hard over standup attendance at the cost of team morale.)

并非所有原则都值得为之抗争。在发起争执前，先问自己“这对我来说为什么如此重要？”。有些原则是核心支柱；很多则不是。（例如：为了坚持站立会议出勤率而牺牲团队士气。）

4. Not Building Relationships Outside Your Team

4. 未建立团队外的关系

Most EMs focus on two relationships: their manager and the PM. That's not enough. Your team's impact depends on other teams and customers — and that requires a supportive network. Have 1:1s with key people, and do what you can to help them.

大多数EM只关注两种关系：与直属经理和产品经理的关系。这远远不够。团队的影响力依赖其他团队和客户——这需要建立支持性的人脉网络。与关键人物进行一对一沟通，并尽可能提供帮助。

5. Defining Your Role Too Narrowly

5. 角色定义过于狭窄

Every EM has a strength — technical, people, process — and the trap is falling into only doing that. Effective managers fill gaps. Constantly assess what's weakest on the team and invest there.

每个EM都有自己的优势——技术、人际、流程——误区是只专注于发挥该优势。高效的经理会填补团队短板。持续评估团队最薄弱的环节并投入精力改善。

6. Forgetting Your Manager Is Human

6. 忘记经理也是普通人

It's easy to get frustrated when your manager puts you in bad situations or commits your team without asking. They almost certainly did it with the best of intentions. Give them room to make mistakes.

当直属经理让你陷入困境或未征询意见就承诺团队任务时，很容易感到沮丧。但他们几乎肯定是出于善意。给他们犯错的空间。

7. Neglecting Personal Development

7. 忽视个人发展

You become so focused on the day-to-day that you forget to spend time on your own growth — leading to stagnation and burnout. Protect time for it.

你过于专注日常事务，忘记投入时间提升自己——导致停滞不前和 burnout（职业倦怠）。要预留出个人发展的时间。

8. Only Managing Down

8. 仅向下管理

Fighting for your team's ideas even when they don't connect to business goals. Even if you win a 3-month refactor nobody asked for, it'll cost you credibility in the long run.

即便团队的想法与业务目标无关，仍全力争取。即便你赢下了没人要求的3个月重构项目，长远来看也会损耗你的可信度。

9. Only Managing Up

9. 仅向上管理

Following your manager's agenda blindly and saying "management wants this" too many times. Say it too many times, and there will be no team left.

盲目遵循经理的议程，频繁提及“管理层要求这么做”。次数过多，团队凝聚力会荡然无存。

10. Never Managing Up

10. 从不向上管理

Your team's success and recognition depend on your relationship with your management chain. Excellent work goes unnoticed when it's never shared upward. Be the "Minister of Foreign Affairs" for your team.

(Traps #8–10 are explored further in the

managing-up

skill.)

团队的成功与认可依赖你和管理层的关系。出色的工作若不向上汇报，就会被忽视。要成为团队的“对外事务负责人”。

（第8-10种误区在

managing-up

技能中有进一步探讨。）

The Drama Triangle — and How to Exit It

戏剧三角模型——如何跳出困境

When things go wrong, it's easy to fall into one of three roles:

Victim — feels powerless, believes things are happening to them. Focuses on who/what to blame.
Villain — what the victim points at as the cause of all problems.
Hero — provides temporary relief (a manager who "handles it," or mindless scrolling that lets you forget).

Three EM examples of falling in:

PM publicly overpromises without consulting you → you're the Victim, PM is the Villain, you want your manager to be the Hero
CEO tells your manager your team isn't working hard enough → you're the Victim, CEO is the Villain, your spouse validating your frustration is the Hero
Underperforming developer who hasn't improved → you're the Victim, previous manager is the Villain, complaining to a peer at lunch is the Hero

In all three cases, the root cause never gets fixed.

How to exit:

Recognize you're in a victim mindset. Notice not just who the villain is, but also who you're turning to as a hero to relieve the frustration.
Try very hard to see their side. When the PM overpromised: instead of sending the angry Slack message, call them. Ask what made them do it. Often the "villain" is under enormous pressure you weren't aware of.
Focus on the outcome you want, not the problem. The more you focus on the problem, the bigger it becomes. Ask: what outcome do I actually want here? Then work toward it.

The healthier model: Creator, Challenger, Coach. A Creator focuses on what they do want, not what they don't want. Creators still face and solve problems — but in the course of creating outcomes, not in the course of stewing in frustration.

当问题出现时，人们很容易陷入以下三种角色之一：

受害者： 感到无力，认为事情是针对自己发生的。专注于指责他人/事。
反派： 被受害者认定为所有问题的根源。
英雄： 提供临时安慰（比如“处理问题”的经理，或让你暂时遗忘烦恼的无意义浏览）。

EM陷入三角困境的三个例子：

产品经理未征询你的意见就公开过度承诺 → 你是受害者，产品经理是反派，你希望直属经理成为英雄
CEO告知你的经理团队不够努力 → 你是受害者，CEO是反派，配偶对你的情绪认同是英雄
表现不佳的开发者未得到改善 → 你是受害者，前任经理是反派，午餐时向同事抱怨是英雄

在这三种情况下，问题的根源永远得不到解决。

如何跳出困境：

意识到自己处于受害者心态。 不仅要注意谁是你眼中的反派，还要注意你将谁视为缓解挫败感的英雄。
尽力站在对方的角度思考。 当产品经理过度承诺时：不要发送愤怒的Slack消息，而是打电话给他们。询问他们这么做的原因。通常“反派”承受着你未曾知晓的巨大压力。
专注于你想要的结果，而非问题本身。 你越关注问题，它就会显得越大。问自己：我真正想要的结果是什么？然后朝着这个方向努力。

更健康的模型：创造者、挑战者、教练。创造者专注于自己想要的东西，而非不想要的。创造者仍会面对并解决问题——但这是在创造结果的过程中，而非沉浸在挫败感中。

Why Managers Have More Bad Days

为何经理会有更多不顺的日子

One thing nobody warns you about: management has a different emotional profile than individual contribution.

As a developer, bad days are bounded. You write code, you fix bugs, you ship things. Even hard days end with something tangible. If things get really bad, you put on headphones and disappear into the work.

As a manager, that escape doesn't exist. Your mood and your work are the same thing. Three reasons managers have more bad days than they expect:

Guilt. You can't be everywhere. Someone needs more of you than you can give today. This guilt is constant and low-level. It doesn't go away — you learn to work with it.
More interactions means more variance. As a manager, your day is mostly other people. More interactions means more opportunities for misunderstanding, conflict, a conversation that didn't land, feedback that was received badly.
No coding escape. When coding was your job, you could always retreat to a hard technical problem and feel competent. Management doesn't have that. The work is ambiguous, slow, and relational.

What to do when you're having a bad management day:

Two real options — pick one, don't half-do both:

Take the sick day. If you're depleted and not able to show up well — don't. The team is better off without a depleted manager than with one going through the motions.
Go all-in. If you can't take the day off, fully commit to being present. The worst outcome is showing up half-present — checked out, distracted, irritable.

3 red flags that something is wrong (not just a bad day):

You find yourself avoiding a specific person or conversation for more than a week.
You feel resentful toward your team or your manager — not frustrated, but genuinely resentful.
You've stopped being curious about the work and are just executing.

5 root causes when bad days become a pattern:

A hard relationship you're not addressing (see #1 of the 10 traps above)
You don't feel you have enough autonomy — someone is micromanaging you
The work doesn't connect to something you care about
You're not growing — doing the same problems in a loop
You're carrying too much alone and not delegating

None of these fix themselves. Name the one that fits and address it directly.

没人会提醒你这一点：管理工作的情绪特征与个人贡献者截然不同。

作为开发者，不顺的日子是有边界的。你写代码、修复bug、交付成果。即便日子很难熬，最终也会有实实在在的产出。如果情况真的很糟，你可以戴上耳机专注工作。

作为经理，这种逃避方式不存在。你的情绪状态与工作融为一体。经理比预期有更多不顺日子的三个原因：

愧疚感。 你无法无处不在。总有人今天需要你更多的关注，但你无法满足。这种愧疚感持续存在且程度轻微。它不会消失——你要学会与之共处。
更多互动意味着更多变数。 经理的日常大多是与人打交道。互动越多，出现误解、冲突、沟通失效、反馈被误解的可能性就越大。
没有编码作为逃避出口。 当编码是你的工作时，你总能退回到一个有难度的技术问题中，获得胜任感。管理工作没有这样的出口。工作内容模糊、进展缓慢且依赖人际关系。

当你遭遇糟糕的管理工作日时该怎么做：

两种可行选择——选其一，不要两者都做一半：

请假休息。 如果你精力耗尽，无法很好地投入工作——就不要勉强。团队更需要状态良好的经理，而非一个敷衍了事的经理。
全身心投入。 如果你无法请假，就完全专注于当下。最糟糕的情况是半心半意地出现——心不在焉、分心易怒。

三个表明情况严重的危险信号（不仅仅是糟糕的一天）：

你发现自己刻意回避某个人或某段对话超过一周。
你对团队或直属经理感到怨恨——不是挫败感，而是真正的怨恨。
你不再对工作感到好奇，只是机械地执行任务。

当糟糕日子成为常态时的5个根源：

你未处理一段紧张的关系（参见上述10种误区中的第1种）
你感觉自主权不足——有人在对你微管理
工作与你在意的事情无关
你没有成长——一直在重复解决同样的问题
你独自承担太多，未进行授权

这些问题不会自行消失。明确符合自己情况的根源并直接解决。

Clear the Path

清除障碍法

The most common management mistake when a team is struggling: assuming they need more motivation.

Most engineers don't wake up wanting to do mediocre work. When output is low, the question isn't "how do I motivate them?" — it's "what's in their way?"

The obstacle audit: Ask everyone: "What prevents you from doing the best work of your career here?" Classify each obstacle (process, technical, resource, clarity). Fix the top three immediately.

Common obstacles that go unnoticed by managers:

Contradictory directives from different stakeholders
Technical debt that turns simple tasks into nightmares
Approval processes that add days to tasks that take hours
Incomplete requirements that force constant rework

When you remove a real obstacle, throughput improves without any "motivation" effort. The manager's job is closer to bulldozer than cheerleader.

当团队陷入困境时，最常见的管理错误是：假设他们需要更多动力。

大多数工程师不会醒来就想做平庸的工作。当产出低下时，问题不是“我该如何激励他们？”——而是“是什么阻碍了他们？”

障碍审计： 询问每个人：“是什么阻碍了你在这里做出职业生涯中最好的工作？” 将每个障碍分类（流程、技术、资源、清晰度）。立即解决排名前三的障碍。

经理常忽视的常见障碍：

不同利益相关者的指令相互矛盾
技术债务将简单任务变成噩梦
审批流程将耗时数小时的任务延长至数天
需求不完整导致反复返工

当你移除真正的障碍时，无需刻意“激励”，产出就会提升。经理的角色更像是推土机，而非啦啦队长。

Repair

修复方法

You will make management mistakes. You'll give feedback that crushes confidence. You'll commit the team to something without consulting them. You'll lose your temper. You'll drop a promise.

The question isn't whether these happen — it's what you do after.

The managers who lose their best people aren't necessarily the ones who made the most mistakes. They're the ones who never acknowledged them. Who doubled down when wrong. Who let ego prevent them from saying: "I put you in an impossible position. I should have consulted you first. Here's how I'll do it differently."

That kind of acknowledgment — specific, honest, without over-apologizing — builds more trust than never making the mistake would have. It signals that you're safe to work with.

How to repair well:

Name what happened specifically. Don't generalize.
Take responsibility. Don't explain it away.
Say what you'll do differently. Keep it concrete.
Then drop it. Extended guilt-tripping helps no one.

你肯定会犯管理错误。你给出的反馈可能打击他人信心。你可能未征询团队意见就承诺任务。你可能发脾气。你可能违背承诺。

问题不在于这些错误是否会发生——而在于犯错后你怎么做。

失去优秀员工的经理不一定是犯错最多的人。而是那些从不承认错误的人。那些犯错后还固执己见的人。那些因自尊心作祟而不愿说：*“我让你陷入了两难境地。我本该先征询你的意见。以后我会这样改进。”*的人。

这种具体、诚实、不过度道歉的认可——比从不犯错更能建立信任。它表明你是值得共事的人。

如何有效修复：

具体说明发生了什么。不要泛泛而谈。
承担责任。不要找借口。
说明你将如何改进。保持具体。
然后放下这件事。过度的自我愧疚对任何人都没有帮助。

Problems vs. Polarities

问题与极性

Some management challenges keep coming back no matter how well you solve them. That's often because they're not problems — they're polarities.

A problem can be solved once and stays solved. A polarity is a tension between two interdependent opposites that must be managed continuously. Neither pole is the "right answer."

Examples: Speed vs. Quality. Autonomy vs. Alignment. Short-term delivery vs. Long-term architecture health. Individual focus time vs. Team collaboration.

The mistake: treating a polarity like a problem. You "solve" quality by clearing the bug backlog — and a year later the backlog is back. You "solved" the wrong thing. The real work is managing the ongoing tension between speed and quality.

How to manage a polarity:

Name both poles. Resist the temptation to pick one as "correct."
Identify the upsides and downsides of each pole.
Recognize when you're over-indexed on one side — that's when the pressure to swing to the other builds.
Build mechanisms that let you consciously shift between poles rather than lurching between them.

When you catch yourself wondering why a recurring problem keeps coming back, ask: is this actually a polarity I'm trying to solve?

有些管理挑战无论你解决得多么好，都会反复出现。这通常是因为它们不是问题——而是极性。

问题可以一次性解决并保持解决状态。极性是两个相互依赖的对立面之间的张力，需要持续管理。没有哪个极端是“正确答案”。

例子：速度与质量。自主权与一致性。短期交付与长期架构健康。个人专注时间与团队协作。

错误做法：将极性视为问题。你通过清理bug积压来“解决”质量问题——一年后bug积压又回来了。你解决了错误的问题。真正的工作是持续管理速度与质量之间的张力。

如何管理极性：

明确两个极端。不要倾向于认为某一个是“正确的”。
识别每个极端的优缺点。
意识到当你过度偏向某一端时——就会产生向另一端摆动的压力。
建立机制，让你可以有意识地在两端之间切换，而非突然大幅摇摆。

当你疑惑为什么某个反复出现的问题总是回来时，问问自己：这是不是我试图当作问题解决的极性？

Dive Deeper

深入探索

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

references/sources.md

for the full list of source articles (with links) and books.

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

references/sources.md

获取完整的来源文章（含链接）和书籍列表。