你为什么可以被晋升?

nicevoice 2023-12-28 AM 42℃ 0条

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

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

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

1. 引子

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

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

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

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

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

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

2. 员工的能力要求

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

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

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

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

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

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

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

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

3. 价值是如何被创造(浪费)的

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

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

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

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

牛逼的三重境界:你觉得自己牛逼,别人觉得你牛逼,觉得你牛逼的人牛逼。

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

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

最后,请记住这条准则(比例):

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

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

4. 还有成本

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

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

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

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

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

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

5. 我们该如何提高?

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

Situational Awareness

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

Trade-off Analysis

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

Second and Third order Effects

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

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

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

Clear-Hold-Build

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

6. 干货

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

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

扫描二维码,在手机上阅读!
标签: 职场

非特殊说明,本博所有文章均为博主原创。

评论啦~