career-development

职业发展

开始之前

先检查 EM 背景信息：

1. 如果 .agents/em-context.md 存在，请先阅读
2. 如果提到了某个人，请查找 .agents/reports/[name].md——其中可能包含此人的级别、目标和成长历程
3. 使用这些背景信息——只询问尚未涵盖的信息

如果 .agents/em-context.md 不存在，请先询问最基本的经理档案，并在给出详细建议前保存：角色／职务、团队规模、团队使命或负责领域，以及当前挑战或优先事项。

如果对话的核心涉及某个具体人员，且 .agents/reports/[name].md 不存在，请先询问此人的基本档案，并在给出详细建议前保存：职务／级别、任职时长、优势，以及当前挑战或成长领域。

如果对话之后揭示了可长期参考的新背景信息，请自动更新 .agents/em-context.md 或 .agents/reports/[name].md。保存稳定的事实和模式，不要保存猜测、一时的挫败情绪或尚未厘清的解读。

回复风格

首次回复应简洁实用。除非用户要求深入探讨，否则不要一次性罗列整套框架。

默认做法：

• 先说明可能的判断或建议
• 只有在缺失的背景信息会改变建议时，才提出最多 2-3 个有针对性的问题
• 给出下一步具体行动，并在有帮助时提供经理可直接使用的措辞
• 简要提及相关框架，但不要逐一解释所有部分
• 先给出直接答复，再询问用户是否需要更深入的版本

---

如何使用此技能

• 此人目前处于什么发展阶段／当前影响力如何？ → 影响圈模型
• 直属下属一味关注某个具体职称或时间表 → 泰山法
• 某人的成长似乎停滞了 → 成长的真实面貌
• 不确定在职业发展对话中该说什么 → 开展职业发展对话
• 正在决定是否应现在推动晋升 → 晋升准备度与晋升时机

---

默认回复结构

在提供职业发展建议时，制定经理可直接使用的计划：

1. 当前成长情况： 此人目前看起来处于什么水平。
2. 下一步成长方向： 接下来需要展现哪类影响力。
3. 对话问题： 下次职业发展 1:1 中要问什么。
4. 创造机会： 项目、曝光度、指导、所有权或职责范围。
5. 设定预期： 如何说明时间安排、所需证据和晋升限制。

不要承诺晋升。要区分“已准备好成长”与“组织有空缺且有充分证据”。

---

影响圈模型

这是思考工程师当前所处位置及未来发展方向的一种实用框架。影响力会向外扩展，形成同心圆：

个人 — 精通自身专业技能，稳定交付成果。编写优质代码、处理值班任务并出色完成工作。这是基础。

团队 — 让团队变得更好。帮助新成员融入团队，有效审查他人的代码，提供有用的反馈，并在队友需要时提供支持。如果他们不在，团队会明显感受到。

团队群组 — 推动跨团队工作。领导跨职能计划、参与招聘，并影响涉及多个团队的架构决策。他们的影响力超出所在团队。

公司 — 推动整个组织的成果。制定技术方向、提升多个团队的能力，并影响整个工程组织的工作方式。

如何在职业发展对话中使用此模型：

• 判断工程师目前稳定地在哪个影响圈发挥作用。
• 要进入下一个层级，需要扩大影响力，而不只是提升当前影响圈内的技能。
• 晋升依据应建立在下一个影响圈上，而不是在当前影响圈中做得更好。

一位编写代码出色、却从未帮助队友成长的高级工程师，在个人影响圈中表现出色，但尚未进入团队影响圈。需要弥补的是这一差距，而不是进一步提升技术深度。

塔山法

工程师（和经理）常常认为，职业发展会沿着直线前进：工程师 → 高级工程师 → Staff 工程师 → Principal 工程师，或工程经理（EM）→ 总监 → 副总裁（VP）。这会让人只盯着沿着一条阶梯最快晋升的路线。

现实是：高级职位既需要能力，也需要公司有相应需求。你可能完全胜任 Staff 工程师的职位，但眼下没有需要你负责的 Staff 级问题。这个职位必须存在，而且在你准备好时正好需要有人填补。

塔山模型：荡向下一根藤蔓，而不是目的地。 塔山不会规划穿越丛林的路线——他抓住眼前可用的藤蔓，荡到尽可能远的地方，然后再寻找下一根。职业发展也是如此。

与下属讨论职业发展时，可以这样做：

• 帮助他们确定下一步要荡向哪里，而不是制定 5 年计划。
• 横向调动或“绕道”进入不同领域，往往能拓宽经验，为日后跃升至更高级别、产生更大影响打下基础。
• 执着于在某个具体日期获得某个具体职称，通常适得其反——合适的机会必须存在，强求只会造成糟糕的结果（例如，跳槽到一家需要该级别人才的公司，但自己实际上还没准备好）。

---

成长的真实样貌

成长并非一条连续的直线，而是由一段段突飞猛进的时期和巩固期交替组成。工程师正在成长的迹象：

• 他们正在解决略微超出当前舒适区的问题
• 他们开始自行做出以前会向上级请示的决策
• 他们正在把学到的知识教给别人
• 他们负责的范围正在扩大

成长停滞的迹象（以及应对方法）：

• 问题相同、工具相同，没有挑战——给他们安排更难的任务
• 技术能力在提升，却没有建立人际关系或影响力——安排他们参与跨团队工作
• 反复犯同样的错误——这是反馈不足，而不是成长不足；先解决反馈问题

---

如何进行职业发展对话

许多经理觉得职业发展对话让人不自在，因为他们认为这类对话事关重大。以下是一些原则：

先询问，再建议。 “你觉得未来一年怎样才算有所成长？”比“这是我觉得你应该做的事”更好。这样通常能更清楚地了解他们真正想要什么，而他们的想法可能与你的假设大相径庭。

区分“他们想要什么”和“公司需要什么”。 如果两者不一致，就坦诚说明。如果有人想转任 Staff 职位，但团队没有 Staff 级的问题，就直说——并帮助他们思考这意味着什么（换个团队、换家公司，或调整时间安排）。

具体说明差距。 “你需要展现更多领导力”毫无帮助。“我看到的差距是，你还没有在项目中推动与产品经理（PM）和设计团队达成一致——你仍在等待需求，而不是主动塑造需求。”这才是他们可以采取行动的建议。

做好记录。 职业发展对话结束后，把讨论内容写下来并分享给下属。记忆并不可靠。书面记录能让双方共同承担责任。

---

晋升准备度与晋升时机

经理常常会把两个不同的问题混为一谈：

这个人是否已准备好晋升？——他们是否持续以更高一级的水平开展工作？他们是否有在该级别产生影响的持续记录，而非偶尔表现出色？

现在是否适合推动晋升申请？——是否有晋升名额或预算？评审周期是否即将开始？是否有足够的书面证据？相关决策者是否足够了解这个人？

两者都必须成立。在一个人尚未准备好时推动晋升，会损害你的信誉，甚至可能让对方的发展受挫。等对方准备好后拖得太久，则会损害信任，还可能导致人才流失。

原则：在培养这个人的同时，就开始准备晋升申请——记录影响、提高曝光度、准备具体案例。不要等到评审时才匆忙准备。

深入了解

如果用户询问某个框架的来源、想阅读原始文章，或想进一步了解此技能中的任何主题，请阅读 references/sources.md，其中列出了所有来源文章（含链接）和书籍。

---

相关技能

• 1on1s — 持续职业对话的主要场所
• performance-reviews — 晋升案例在评审时提出；前期准备工作在这里打好基础
• managing-high-performers — 高绩效员工需要成长挑战来保持投入
• management-transitions — 就管理是否适合工程师提供建议