influence

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Influence

影响力

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

如何使用本技能

Need a specific tactic for an upcoming conversation or meeting → The 5 Methods (pick the one that fits)
Facing objections or resistance you anticipate → Label the Concern
The other person isn't really engaging with your proposal → Get to "That's Right"
Headcount request has been rejected or feels stuck → Getting Headcount: Arguing at the Right Layer
Want to build long-term influence and be taken seriously → The 3 Levels of Positioning
Wondering whether to play politics at all → Politics as a Skill
Default approach to helping vs. extracting in relationships → Giver / Matcher / Taker

As an EM, you persuade constantly: executives to approve projects, leadership for more resources, reports to take on tasks, peers for cross-team help, hiring candidates to join, promotion panels to say yes. The list is endless.

5 methods that work specifically for engineering managers:

需要为即将到来的对话或会议制定具体策略 → 选择5种方法中最适配的一种
预计会遭遇反对或抵触 → 使用标注顾虑法
对方未真正参与你的提案讨论 → 引导对方说出“没错”
人员编制申请被驳回或陷入停滞 → 人员编制申请：在正确层面论证
想要建立长期影响力并获得重视 → 三级定位模型
纠结是否要参与组织政治 → 将政治视为一项技能
人际关系中帮助与索取的默认方式 → Giver / Matcher / Taker模型

作为工程经理，你需要不断说服他人：让高管批准项目、向领导层争取更多资源、推动下属承担任务、请求跨团队协作、说服候选人加入团队、让晋升评审团认可你的下属……这类场景数不胜数。

以下5种方法专为工程经理设计：

Default Response Shape

默认回复结构

When helping with influence, produce a stakeholder plan:

Decision target: what the user wants changed, approved, or believed.
Stakeholder map: who needs to agree, who can block, and who is merely informed.
Best influence move: choose the relevant method and explain why it fits.
Message / script: wording for the next conversation or written ask.
Risk: what could backfire politically or relationally.

If the user is trying to get headcount, start by checking alignment on problem and approach before arguing for people.

在提供影响力相关建议时，需制定利益相关方计划：

决策目标： 用户希望实现的变更、批准事项或需要他人认同的观点。
利益相关方图谱： 哪些人需要同意、哪些人有权阻止、哪些人仅需知晓。
最佳影响力策略： 选择相关方法并解释适配原因。
话术/脚本： 下一次对话或书面申请的措辞。
风险： 可能在政治层面或人际关系层面引发的负面后果。

如果用户正在申请人员编制，先确认问题和解决方案是否达成共识，再论证人员需求。

1. Nemawashi (Going Around the Roots)

1. Nemawashi（绕根法）

Japanese gardening technique for transplanting large trees: gently loosen the roots one strand at a time before the big move.

When to use: Getting a calibration rating, pushing an initiative with multiple stakeholders who will all be in the same room.

How it works: Meet 1:1 with key stakeholders before the main meeting. Choose people with experience and influence. Tailor your case to what each person values — one values technical excellence, another values throughput, another values business impact. Hear their objections early and address concerns. By the time the main meeting happens, you've already built support and the discussion is far less contentious.

这是一种日本园艺技术，用于移栽大树：在正式移栽前，逐一轻轻松动树根。

适用场景： 进行绩效校准评分、推动涉及多方利益相关方的倡议（这些人将同处一个会议现场）。

操作方式： 在主会议召开前，与关键利益相关方进行一对一沟通。选择具备经验和影响力的人员。根据每个人的核心诉求调整你的论证角度——有人重视技术卓越，有人关注交付效率，有人看重业务影响。提前听取他们的反对意见并解决顾虑。等到主会议召开时，你已经建立了支持基础，讨论也会远少得多的争议。

2. Decoy Pricing

2. 诱饵定价

A marketing technique: offer 3 options where one acts as a decoy to make your preferred option look like the obvious choice.

When to use: Headcount requests, asking a peer team for help.

How it works for headcount: Provide three options (Small, Medium, Large) with different outcomes for each, evaluated on dimensions your stakeholders care about (speed, quality, scope). Design it so the option you actually want looks like the best value compared to the others.

Reversed version: When asking a peer team's manager for help, the smallest option should be what you actually need — making it easy for them to say yes.

这是一种营销技巧：提供3个选项，其中一个作为诱饵，让你的首选方案看起来是显而易见的最佳选择。

适用场景： 申请人员编制、请求其他团队提供帮助。

人员编制申请中的操作方式： 提供三个选项（小型、中型、大型），每个选项对应不同成果，并从利益相关方关心的维度（速度、质量、范围）进行评估。设计方案时，让你真正想要的选项相比其他选项显得更具价值。

反向版本： 请求其他团队经理提供帮助时，最小的选项应为你实际需要的内容——让对方更容易答应。

3. Reverse Psychology

3. 逆向心理

Suggest the opposite of what you want, which makes the other person want to do what you really desire.

When to use: Hiring sell-calls with strong candidates; engineers who are resistant to trying new approaches.

How it works in hiring: List real reasons why the candidate shouldn't join your team. This attracts people who are drawn to challenges and want to prove themselves — exactly the people you want.

Example: "Don't join EngProd if you like to stay in your swim lane and wear only one hat."

提出与你真实诉求相反的建议，从而促使对方主动去做你真正希望的事。

适用场景： 与优秀候选人进行入职说服沟通；工程师抵触尝试新方法时。

招聘中的操作方式： 列出候选人不应加入你团队的真实原因。这会吸引那些乐于迎接挑战、想要证明自己的人——正是你需要的人才。

示例："不要加入EngProd团队，如果你喜欢待在舒适区、只专注单一工作内容。"

4. LMDTFY (Let Me Decide That For You)

4. LMDTFY（让我来帮你做决定）

Reverse-delegation: you make the decision and tell the person they can take control back if they object. "Silence is consent."

When to use: Upward influence (getting your manager to delegate decision-making to you), and giving your reports autonomy on low-risk decisions.

How it works upward: "I intend to finalize this hire — let me know if you have concerns, otherwise I'll proceed." Over time, this trains your manager to trust your judgment on a category of decisions.

With reports: Teaches them to drive decisions forward while keeping oversight open. "I intend to deploy this release during my day — leave a message if you disagree."

反向授权：你做出决策，告知对方如果有异议可以收回控制权。“沉默即同意。”

适用场景： 向上影响（让你的经理将决策权委托给你）、在低风险决策中给予下属自主权。

向上影响的操作方式： "我打算敲定这个招聘人选——如果有顾虑请告知我，否则我将推进流程。" 长期坚持，会训练你的经理信任你在某类决策上的判断力。

对下属的操作方式： 教会他们主动推进决策，同时保持监督渠道开放。"我打算在我的工作时段部署这个版本——如果不同意请留言告知。"

5. Engineered Serendipity

5. 刻意制造的意外相遇

Deliberately engineer a "coincidence" to create the right conditions for a hard conversation.

When to use: Cross-team friction that needs a real conversation but would never happen in a formal meeting.

How it works: Find out where/when the other person will be in an informal setting and arrange to be there too. Informal contexts lower defenses and allow real dialogue in a way that a scheduled meeting cannot. It doesn't guarantee results and doesn't force choices — it maximizes the chances of the right conversation happening.

刻意设计“巧合”，为艰难对话创造合适的条件。

适用场景： 需要解决跨团队摩擦，但这类对话在正式会议中永远不会发生。

操作方式： 了解对方在非正式场合的出现时间和地点，安排自己也出现在那里。非正式环境会降低戒备心，让真实对话得以展开，这是预定会议无法做到的。它不能保证结果，也不会强迫选择——只是最大化发生有效对话的可能性。

Politics as a Skill

将政治视为一项技能

"Politics" in engineering has a bad reputation. It's worth reclaiming the word.

Politics, in this context, means: making the things you want to happen, actually happen. Understanding what each stakeholder cares about. Knowing how to frame a conversation for the right audience. Navigating resistance with the least friction rather than the most force.

Mediocre EMs resent politics. Effective EMs learn it. The skill is neutral — it can be used to advance good work or bad work. Your job is to use it to advance good work.

在工程领域，“政治”一词名声不佳，但值得重新定义它的含义。

本文中的“政治”指：让你想做的事情真正落地。理解每个利益相关方的核心诉求。知道如何针对不同受众构建对话框架。以最小摩擦而非最强硬的方式应对抵触。

平庸的工程经理反感政治，高效的工程经理学习政治。这项技能本身是中性的——既可以用来推进有益的工作，也可能被用于不良目的。你的职责是用它来推进有价值的工作。

Giver / Matcher / Taker

Giver / Matcher / Taker模型

From Adam Grant's Give and Take: people approach help and collaboration in one of three ways:

Givers contribute without expecting anything back
Matchers help when they expect to be helped in return
Takers focus on what they can extract from relationships

The counterintuitive finding: Givers are both the lowest AND highest performers. The bottom of most industries is dominated by Givers (who give until they're exploited). The top is also dominated by Givers — because of two effects:

Givers are constantly involved in complex problems (because people want their help), so they learn fastest
When a Giver needs something, people line up to help them — because they've built genuine goodwill

Be a Giver. Set limits on exploitative relationships — but default to helping freely.

来自Adam Grant的《Give and Take》：人们在帮助与协作中通常采用三种方式之一：

Giver（给予者）： 付出而不期待回报
Matcher（对等者）： 在预期得到回报时才提供帮助
Taker（索取者）： 专注于从关系中获取利益

违反直觉的发现：给予者既是表现最差的群体，也是表现最优的群体。大多数行业的底层被给予者占据（他们一直付出直到被剥削），而顶层也被给予者主导——原因有两点：

给予者持续参与复杂问题（因为人们需要他们的帮助），因此学习速度最快
当给予者需要帮助时，人们会主动伸出援手——因为他们积累了真正的善意

做一名给予者。对剥削性的关系设定界限，但默认选择主动提供帮助。

Label the Concern

标注顾虑

From Never Split the Difference (Voss): before someone voices an objection, name it yourself.

"I imagine you're wondering why this is coming up now." "You might be concerned that this adds scope to an already full quarter." "I know this sounds expensive."

Labeling the concern disarms it. When people hear their unspoken worry named, they feel understood — which lowers resistance and opens them to the actual case you're making. If you don't label it and they raise it, you're defending; if you label it first, you're already on the same side.

The technique is especially effective in headcount conversations, architectural proposals, and any situation where you're asking for something the other person has reason to resist.

One warning: the label has to be accurate. A wrong label ("I imagine you think this is risky" when they're actually worried about ownership) creates friction instead of reducing it. When in doubt, keep the label vague: "I know there are concerns about this."

来自《Never Split the Difference》（Voss）：在对方提出反对意见前，先主动说出他们的顾虑。

"我猜你会好奇为什么现在提出这件事。" "你可能担心这会给本已排满的季度增加工作范围。" "我知道这听起来成本很高。"

标注顾虑能化解抵触情绪。当人们听到自己未说出口的担忧被点破时，会感到被理解——这会降低抵触，让他们愿意倾听你的实际论证。如果你不先标注，等他们提出时，你就处于防守状态；而先标注的话，你们已经站在了同一阵线。

这项技巧在人员编制对话、架构提案以及任何你提出对方有理由拒绝的请求时，尤其有效。

注意事项：标注必须准确。错误的标注（比如对方实际担心的是所有权问题，你却标注“我猜你觉得这有风险”）会增加摩擦而非减少。如果不确定，保持标注模糊：“我知道大家对此有顾虑。”

Get to "That's Right," Not "You're Right"

引导对方说出“没错”，而非“你说得对”

From Never Split the Difference (Voss): there's a critical difference between the two responses.

"You're right" means: you won the argument, I'll say what you want so we can move on. It signals capitulation, not genuine agreement. It almost never leads to real change.

"That's right" means: you've just summarized my situation so accurately that I feel understood. It's the response that comes when someone feels genuinely heard — and it opens them to persuasion.

How to get there: listen to what the other person is telling you about their world, then summarize it back to them so accurately that they can't help but agree. Not a paraphrase — a precise articulation of what they care about, what they're worried about, and what they're trying to achieve.

"So the concern is that if we invest in this now, we lose flexibility in Q3, and the Q3 roadmap already has more on it than the team can realistically handle."

When someone says "that's right" — that's when they're ready to actually engage with your proposal.

来自《Never Split the Difference》（Voss）：这两种回应有着关键区别。

**“你说得对”**意味着：你赢了这场争论，我会说你想听的话，好让我们能继续推进。 它代表妥协，而非真正的认同，几乎不会带来真正的改变。

**“没错”**意味着：你刚刚准确总结了我的处境，我感到被理解。 只有当人们感到真正被倾听时，才会给出这种回应——此时他们才会愿意接受说服。

如何实现：倾听对方讲述他们的处境，然后准确地总结出来，让他们不得不认同。不是转述，而是精准表达他们关心的事、担忧的事以及想要实现的目标。

"所以顾虑是，如果我们现在投入资源，第三季度就会失去灵活性，而第三季度的路线图已经超出了团队实际可处理的范围。"

当对方说出“没错”时——他们才真正准备好参与你的提案讨论。

Getting Headcount: Arguing at the Right Layer

人员编制申请：在正确层面论证

Most headcount requests fail not because they're wrong, but because they're arguing on the wrong layer. You're discussing whether to hire when the real disagreement is about something bigger.

Will Larson's hierarchy of alignment — work through these in order:

Do we agree on the problem? e.g., "We're having too many incidents and it's hurting developer productivity and user trust." If leadership doesn't share this problem framing, no amount of headcount justification will land.
Do we agree on the general approach? e.g., "We should invest in improving test coverage and on-call tooling." If they think the answer is process changes, not hiring, you're still misaligned.
Do we agree the team is executing well today? Show metrics: incident trends over time, test coverage trajectory, developer survey data. If they don't believe the current team is capable, more of the same won't seem like the solution.
Then ask for headcount. Only now is the specific request likely to land.

When a headcount request is rejected, diagnose which layer the disagreement is actually at. Arguing harder at layer 4 when the disagreement is at layer 1 wastes everyone's time and erodes credibility.

大多数人员编制申请失败，并非因为请求不合理，而是因为论证层面不对。你在讨论是否要招聘，但真正的分歧在于更核心的问题。

Will Larson的对齐层级——按顺序逐步推进：

我们是否认同问题存在？ 例如：“我们的事故太多，影响了开发者效率和用户信任。” 如果领导层不认可这个问题框架，再多的人员编制论证也无济于事。
我们是否认同大致解决方案？ 例如：“我们应该投入资源提升测试覆盖率和值班工具。” 如果他们认为答案是流程变更而非招聘，你们仍未对齐。
我们是否认同当前团队执行良好？ 展示数据：事故趋势、测试覆盖率变化、开发者调研数据。如果他们不相信当前团队的能力，增加同类人员不会被视为解决方案。
然后再申请人员编制。 只有此时，具体请求才有可能被接受。

当人员编制申请被驳回时，诊断分歧实际出现在哪个层面。如果分歧在第一层，却在第四层反复论证，只会浪费所有人的时间并损害你的可信度。

The 3 Levels of Positioning

三级定位模型

How you and your team are positioned in people's minds determines how much friction you face when you need things: headcount, schedule flexibility, calibration outcomes, cross-team help.

Most EMs try to manage this by explaining themselves to leadership — clarifying challenges, defending the team, lowering expectations. That rarely works. A better approach is to rise to play in the same field.

Level 1: Known — Be Visible

Most EMs fail here. "Doing great work quietly" leaves 90% of the org not knowing you exist. Being known doesn't require networking events — it requires showing up in small ways consistently:

Participate in cross-team projects and company-wide discussions
React to and comment on announcements from other teams
Ask relevant questions in meetings where you don't know everyone
Have your team write release notes rather than you doing it

For your engineers: broadcasting their achievements publicly makes promotions easier. A developer who is known beyond engineering gets approvals faster — even from people who have never worked with them directly.

Level 2: Appreciated — Show Interest

The most underrated lever. Showing curiosity about someone's work and challenges makes you memorable and liked — and liking influences everything from scope negotiations to incident blame.

The new person rule: each week, have at least one conversation with someone you've never spoken to before. Not just from engineering. Start with something personal, then ask about their work and what's challenging for them.

Remember and follow up. Asking "How did that launch go?" two weeks after someone mentioned it is cheap and creates real goodwill. Knowing the names of people's spouses or children and asking specifically — not "how's the family?" — signals that you pay attention.

Level 3: Trusted — Help Others Achieve Their Goals

Trust is built by making people seem good and helping them succeed — not by explaining how good you are. Counterintuitively, the highest performers and most productive people in organizations tend to be the biggest givers.

To do this, you need to know what others care about. Level 2 gives you that. Then act on it:

Support: Don't ignore their requests or redirect to product. When they bring a problem, engage — train their people, do some time in support if needed.
QA: Be proactive about bug fixes; don't make them open tickets you ignore. Help them innovate with new tools.
HR: Volunteer to help with learning & development processes, onboarding programs, or hiring process design. The time investment is small and the reciprocity is high.
Finance: Do what they ask before the deadline. Everyone else is late. Find one operational problem they've always wanted solved and fix it — even a half-day is enough to create lasting goodwill.

The less visible a department is, the more they appreciate being helped. These relationships pay dividends disproportionate to the effort.

你和你的团队在他人心中的定位，决定了你在争取资源（人员编制、日程灵活性、绩效校准结果、跨团队帮助）时面临的摩擦大小。

大多数工程经理试图通过向领导层解释自己来管理定位——澄清挑战、为团队辩护、降低预期。但这几乎没用。更好的方法是进入同一赛道竞争。

第一层：被知晓——提升可见度

大多数工程经理在这一层失败。“默默做好工作”会让公司90%的人不知道你的存在。被知晓不需要参加社交活动——只需持续通过小事刷存在感：

参与跨团队项目和公司范围的讨论
对其他团队的公告做出回应和评论
在不认识所有人的会议上提出相关问题
让你的团队撰写发布说明，而非由你代劳

对你的工程师而言：公开宣传他们的成就会让晋升更容易。一名在工程部门之外也被知晓的开发者，能更快获得批准——即使对方从未与他们直接合作过。

第二层：被认可——展现兴趣

这是最被低估的杠杆。对他人的工作和挑战表现出好奇心，会让你被记住并受欢迎——而好感会影响从范围协商到事故追责的所有事情。

新人规则： 每周至少与一位从未交谈过的人进行一次对话。不局限于工程部门。先聊一些个人话题，再询问他们的工作和面临的挑战。

记住并跟进。两周后问一句“那次发布进展如何？”成本很低，但能建立真正的善意。记住他人配偶或孩子的名字并专门询问——而非笼统地问“家人还好吗”——表明你在用心关注。

第三层：被信任——帮助他人实现目标

信任是通过让他人看起来优秀、帮助他们成功建立的——而非通过吹嘘自己有多优秀。违反直觉的是，组织中表现最好、效率最高的人往往是最大的给予者。

要做到这一点，你需要了解他人的核心诉求。第二层的行动能帮你获取这些信息。然后采取行动：

支持： 不要忽视他们的请求或推给产品部门。当他们提出问题时，积极参与——培训他们的员工，必要时亲自提供支持。
质量保障： 主动修复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 in this skill — read

references/sources.md

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

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

references/sources.md

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