首页 > > > 你为什么可以被晋升?
本篇文章 3100 字,预计阅读时间为 12 分钟,建议找一个安静的时间阅读,以及隔一段时间翻出来再看。

在任何一家公司,每一个对自己职业生涯有规划的员工都希望在更短的时间内晋升,这意味着更多的关注和资源倾斜,更大的责任和职责范围。当然,与之匹配的收益必然也是同步提高的。
对于晋升这件事情本身,我们应该怎样理解?有哪些误解需要澄清,我们需要做什么准备?今天就花一些时间和大家聊一聊你为什么会被提名晋升,或者晋升成功。
一位工程师作为主力,花了 2 个月开发了一套数据字典系统:数据维护页面、展示页面、搜索功能,关联关系等模块一应俱全……从开发角度而言,项目交付得漂亮,此为背景。但当我询问团队的分析师,这套系统对比以前的 wiki 系统,是否更好地解决了大家”寻找数据解释“的这个难题。然而让我大跌眼镜的是,这么关键的工具,分析师们并不知道它的存在……
我反问研发人员其中原因,他也很委屈:系统上线时,给全员发送了邮件,在工作群里也有提到。我开发完了,我交付完毕了,为什么大家不用?
你所服务的用户,因为思维方式、背景、动机的不同,同样一件事情,他和你的理解可能完全不是一回事。
请读者思考以下三个问题:
当然也可以对照一下产品方法论,产品 + 用户 + 场景 + 效率是我们考虑的四个目标:分析师在什么场景下使用你的产品,是否真的提高了他们发现数据的效率?
这里不涉及所谓的企业价值观表现和组织能力,是纯粹个人能力的讨论。先快速讨论一下不同层级员工的核心区别:
所以,每周你都要反问自己这几个问题:
答案每个人都会不同,只要你做到任意一点,都会提高你被提名晋升的概率。细节这里不做过多的解释。再给大家另外一个事实讨论:有两个员工晋升答辩,只能晋升一个,你会选择谁?
回顾一下前面提到的不同层级员工的差别:第 1 位员工其实只是在忠实的执行,而第 2 位员工表现出了高级别员工该有的基本素质——模式抽象能力,甚至表现出了解决问题的前置能力(你没看错,是解决问题的前置能力)。第 2 种情况在后面一般都会有个更大价值的事情,需要提前梳理和解决一些依赖问题。
要分清楚,到底是项目成就了你,还是你成就了这个项目。切忌把项目的价值等同于自己的价值!搞清楚这个关键点,面试官会选择谁,答案很显然。
我们回到文章开头的那个故事,不管是研发工程师还是数据科学线的工程师,当你做完一项工作或者交付一款产品时,下游用户使用这个产品的量越大,这个产品的价值也就越大。反之,你开发完了,下游用户并没有人去使用,真不如不做这个事情。因为从个人角度讲,你的时间和精力被浪费了。
我们再从团队管理的视角看一下这个事情:
时不时会有员工对我抱怨说:为什么我做出了很大的工作业绩,然而大家并不认可我?
牛逼的三重境界:你觉得自己牛逼,别人觉得你牛逼,觉得你牛逼的人牛逼。
小伙,请利用好一切可利用的机会:工作例会、私人交谈、周报……想尽一切办法,反复对你的下游用户兜售观念或已交付产品,直到比你牛逼的人也觉得这个很牛逼为止。
这里分享给大家一个小技巧,如果是小范围沟通的话,你可以让对方复述一遍你的陈述内容,或者你复述对方的陈述事实,这都是很好的工作习惯。
最后,请记住这条准则(比例):
我们创造价值的 70%% 源自于协作,30%% 来源于个人。
不要过高地估计自己的作用,和上下游有效同步信息是创造价值的必备条件。
想晋升,想尽办法把个人和组织的收益提高到极致,那从成本角度呢?想象以下情况:
你虽然有产出,甚至还不错,但带来了更多的隐性成本,这些未来的损失需要从你的工资中扣除,所以你不应该拿很高的工资。我经常半开玩笑地问团队成员一句话:
如果我接管了一个五倍规模的新团队,你能够成为其中独当一面的 leader 么?
如果不行,你会白白浪费一个 headcount,我为什么不找一个更厉害的员工替换你?
回顾一下《亮剑》的经典桥段:李云龙本来是一个团长,但攻打平安县城时,他却不小心变成了师长。原因是他的每个营,时时刻刻都保持着持续变强的状态,人数还是装备都达到团级配置(还有意大利炮)。既然有一个师的兵力和装备,自然可以去救嫂子,去打平安县城。
我未来必然有恶仗,如果你成长的速度不行,你是负债,对不起,请离开!
不管作为高级员工还是管理者,都需要应用元认知策略来升华自身。不废话,直接列四个重点:
Situational Awareness
看字面意思就大概应该能猜测出来是什么意思,前文讲的故事里和这点关系很强,不再多解释。
Trade-off Analysis
可以称为得失分析或取舍分析。如果是做算法的同学,应该比较清楚是什么意思。不过需要注意的是,实际工作中,我们需要自己定义 alternatives,以及自己定义准则和权重,最终通过评分来考虑取舍,每个事件都不一样。
Second and Third order Effects
二阶和三阶影响,至少有两个层面的意义:
第 2 点稍作展开:想象一下,你是研发工程师,你听产品经理的,产品经理听业务方的,业务方听用户的……那问题来了,从职位划分上说,你要忠实地完成产品经理提过来的需求。但你确定只管产品经理的需求,这样做是对的么?多一些提示:关键人并不是自然人,而是特定场景下某些需求的集合。想象一下你的老板在讲项目,老板是关键人(需求集合),这个关键人背后的关键人是谁?
Clear-Hold-Build
清除-维持-重建:这个说法源自于美军的军事战·术动作,在伊拉克战争时被广泛讨论和并被接受。其实也很简单,想象一下我们如果要进攻一个区域,首先要清除,再保持住占领,最后构筑自己的军事设施。任何技能知识、管理知识的学习都要经历这三步,千万不要认为自己在某个领域稍稍资深,就可以不按照 CHB 的原则来操作。俗语说的“空杯心态”其实就是 Clear 的意思,但我个人认为 Clear-Hold-Build 体现了全过程,更值得仔细揣摩和执行。
最后来点更干的,当你述职的时候,灵魂七问:
来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/69949510/viewspace-3148212/ ,如需转载,请注明出处,否则将追究法律责任。