你为什么可以被晋升？

本篇文章 2900 字，预计阅读时间为 12 分钟，建议找一个安静的时间阅读，以及隔一段时间翻出来再看。

在任何一家公司，每一个对自己职业生涯有规划的员工都希望在更短的时间内晋升，这意味着更多的关注和资源倾斜，更大的责任和职责范围。当然，与之匹配的收益必然也是同步提高的。

对于晋升这件事情本身，我们应该怎样理解？有哪些误解需要澄清，我们需要做什么准备？今天就花一些时间和大家聊一聊你为什么会被提名晋升，或者晋升成功。

0. 引子

一位工程师作为主力，花了 2 个月开发了一套数据字典系统：数据维护页面、展示页面、搜索功能，关联关系等模块一应俱全……从开发角度而言，项目交付得漂亮，此为背景。但当我询问团队的分析师，这套系统对比以前的 wiki 系统是否更好地解决了大家寻找数据解释的这个难题。然而让我大跌眼镜的是，这么关键的工具，分析师们并不知道它的存在……

我反问研发人员其中原因，他也很委屈：系统上线时，给全员发送了邮件，在工作群里也有提到。我开发完了，我交付完毕了，为什么大家不用？

你所服务的用户，因为思维方式、背景、动机的不同，同样一件事情，他和你的理解可能完全不是一回事。

请读者思考以下三个问题：

1. 你负责产品的最终用户是怎么想的？
2. 你表达的语言，用户听懂了么？
3. 你的产品如果不被接受，更多的是产品的问题还是信息传递的问题？

当然也可以对照一下产品方法论，产品 + 用户 + 场景 + 效率是我们考虑的四个目标：分析师在什么场景下使用你的产品，是否真的提高了他们发现数据的效率？

1. 员工的能力要求

这里不涉及所谓的企业价值观表现和组织能力，是纯粹个人能力的讨论。先快速讨论一下不同层级员工的核心区别：

• 一线员工：他关注的是做什么？（事情的本身，重在执行）
• 高级别员工：他关注的怎么做才能做得更好？（模式的抽象，框架下的预见）
• 管理者：他关注的是为什么要做这个？不做可以么？做了其他的事情是否可以更好地解决这个问题？（关系和结构，顶层设计）

每周你都要反问自己这几个问题：

1. 我对于老板，不可替代的作用是什么？
2. 对接的业务，你只是在被动的支持么？
3. 因为你的存在，哪些执行的结果变的不一样了？
4. 你对你的上下游做了什么，让组织变得更高效了？

答案每个人都会不同，只要你做到任意一点，都会提高你被提名晋升的概率。细节这里不做过多的解释。再给大家另外一个事实讨论：有两个员工晋升答辩，只能晋升一个，你会选择谁？

1. 项目方向是老板定的，公司关键性项目，该员工在执行，项目带来的公司业绩很多。
2. 直接产生的业绩很少，但任务复杂度高，该员工给出了高明的解决方案，且项目完成度很好。

回顾一下前面提到的不同层级员工的差别：第 1 位员工其实只是在忠实的执行，而第 2 位员工表现出了高级别员工该有的基本素质——模式抽象能力，甚至表现出了解决问题的前置能力（你没看错，是解决问题的前置能力）。第 2 种情况在后面一般都会有个更大价值的事情，需要提前梳理和解决一些依赖问题。

要分清楚，到底是项目成就了你，还是你成就了这个项目。切忌把项目的价值等同于自己的价值！搞清楚这个关键点，面试官会选择谁，答案很显然。

2. 价值是如何被创造（浪费）的

我们回到文章开头的那个故事，不管是研发工程师还是数据科学线的工程师，当你做完一项工作的时候，或者交付一款产品的话，下游用户使用这个产品的量越大，这个产品的价值也就越大。反之，你开发完了，但下游用户并没有人去使用，那你不如不做这个事情，因为从个人角度讲，你的时间和精力被浪费了。

我们再从团队管理的视角看一下这个事情：

1. 你做了一件你认为有意义东西，但并没有进行推广，我更倾向于说：你并不知道这个事情的价值有多大，或者说你对整个项目的理解高度并不高。
2. 你开发完产品后并没有做推广，其他团队不知情，做了另外一款类似的东西，公司的研发资源被浪费。
3. 两个关联团队可能发生后续资源的争夺，轻则心存芥蒂，破坏协作氛围，重则双方拆台，相互攻击。

时不时有员工对我抱怨说：为什么我做出了很大的工作业绩，然而大家并不认可我？

牛逼的三重境界：你觉得自己牛逼，别人觉得你牛逼，觉得你牛逼的人牛逼。

小伙，请利用好一切可利用的机会：工作例会、私人交谈、周报……想尽一切办法，反复对你的下游用户兜售观念或已交付产品，直到比你牛逼的人也觉得这个很牛逼为止。

这里分享给大家一个小技巧，如果是小范围沟通的话，你可以让对方复述一遍你的陈述内容，或者你复述对方的陈述事实，这都是很好的工作习惯。

最后，请记住这条准则（比例）：

我们创造价值的 70%来源于协作，30%来源于自己。

不要过高的估计自己的作用，和上下游有效同步信息是创造价值的必备条件。

3. 还有成本

想晋升，想尽办法把个人和组织的收益提高到极致，那从成本角度呢？想象以下情况：

1. 如果你没有留下足够说清楚你工作内容的文档和代码，那么你未来离开之后的潜在补救成本很高；
2. 如果你在关键的节点上掉了链子，那么你会导致你的下游拖慢进度，潜在的人力损耗会很高；
3. 如果你讲不清楚你的产品、你的理念，这个产品后期应用的成本会很高；

你虽然有产出，甚至还不错，但带来了更多的隐性成本，这些未来的损失需要从你的工资中扣除，所以你不应该拿很高的工资。我经常半开玩笑地问富贵论坛团队成员一句话：

如果我接管了一个五倍规模的新团队，你能够成为其中独当一面的 leader 么？

如果不行，你会白白浪费一个 headcount，我为什么不找一个更厉害的员工替换你？回顾一下《亮剑》的经典桥段：李云龙是一个团长，攻打平安县城时，他不小心成了师长。原因是他的每个营，在那样的时间点，不论人数还是装备都已然达到团级配置（还有意大利炮）。既然有一个师的兵力和装备，当然可以攻打平安县城。

我未来必然有恶仗，如果你成长的速度不行，你是负债，对不起，请离开！

4. 我们该如何提高？

不管作为高级员工还是管理者，都需要应用元认知策略来升华自身。不废话，直接列四个重点：

Situational Awareness

看字面意思就大概应该能猜测出来是什么意思，前文讲的故事里和这点关系很强，不再多解释。

Trade-off Analysis

可以译作得失分析或取舍分析。如果是做算法的同学，应该比较清楚是什么意思。不过需要注意的是，实际工作中，我们需要自己定义 alternatives，以及自己定义准则和权重，最终通过评分来考虑取舍，每个事件都不一样。

Second and Third order Effects

二阶和三阶影响，至少有两个层面的意义：

1. 问题背后的问题，以及三阶问题
2. 关键人背后的关键人，以及三阶关键人

第 2 点稍作展开：想象一下，你是研发工程师，你听产品经理的，产品经理听业务方的，业务方听用户的……那问题来了，从职位划分上说，你要忠实地完成产品经理提过来的需求。但你确定只管产品经理的需求，这样做是对的么？多一些提示：关键人并不是自然人，而是特定场景下某些需求的集合。想象一下你的老板在讲项目，老板是关键人（需求集合），这个关键人背后的关键人是谁？

Clear-Hold-Build

清除-维持-重建：这个说法源自于美军的军事战术动作，在伊拉克战争时被广泛讨论和并被接受。其实也很简单，想象一下我们如果要进攻一个区域，首先要清除，再保持住占领，最后构筑自己的军事设施。任何技能知识、管理知识的学习都要经历这三步，千万不要认为自己在某个领域稍稍资深，就可以不按照 CHB 的原则来操作。俗语说的“空杯心态”其实就是 Clear 的意思，但我个人认为 Clear-Hold-Build 体现了全过程，更值得仔细揣摩和执行。

5. 干货

最后来点更干的，当你述职的时候，灵魂七问：

1. 面对新业务时体现出的分解问题的能力？
2. 项目过程中作为高级别员工体现出的协调和统筹能力，比如出现冲突时你的做法？
3. 项目复盘和内部经验推广的能力？
4. 对本部门技术框架的沉淀和总结？
5. 技术上的前瞻性，对团队前进方向的思考和努力，包括对自己的 leader 的影响力？
6. 如何成就下属，或如何成就团队。标志性的结果是什么？
7. 内部效率和外部效率提升的思考和行动，以及结果是什么？

—完—