跳至主要內容
关于晋升的几点感想

关于晋升的几点感想

最近公司晋升季,辅导了几个同学的晋升,于是有如下的几个感想,随便写写。

  1. 工作中,不光要低头干活,还要抬头看路。老黄牛大家都喜欢,但是老黄牛确是晋升最慢的,甚至可能压根不会晋升。

  2. 工作中很多时候在任务分配的时候就注定了谁能晋升了,或者说在任务分配的时候,就注定了哪些人的晋升材料上可以浓墨重彩的描述一些事情了。

  3. 其实Java里面经常将“面相对象编程”,其实在工作中,“面向晋升工作”或者“面向领导工作”也未尝不可呢。

  4. 关于晋升材料

    1. 技术价值:

      1. 横向:质量、效能、成本。
      2. 纵向:能不能、好不好、先进不先进。
    2. 技术同学的晋升材料,还是需要主要讲清楚技术价值。大家晋升的时候很少讲技术价值(质量、效能、成本),更多的还都是在讲业务价值。而这个业务价值,如果换一拨人也大概率这样。甚至很多的时候这些业务价值,极大概率不是因为某些特定技术同学产生的,更多的可能是由于业务运营同学产生的。

    3. 在描述你所做的事情的时候,一定要围绕着:业务问题->业务痛点->技术问题->技术痛点->目标->难点&挑战->策略和思路->动作->技术结果和业务结果。这样才具有逻辑性。

    4. 关于晋升材料中具体言语描述,要经常问问自己,你写的材料和别人写的有啥区别,是否这段材料在其他场景也能使用(如果能使用,则可能写的太宽泛了,不够具体)。

    5. 晋升材料中,如果提太多能力建设的事情,其实很多时候太low了。

      1. 因为大多数人讲不清楚“你做的这个能力建设到底好不好,先进不先进”。评委也很难识别你做的这个事情怎么样。因此如果非要讲能力建设,那么就必须通过业界对标的形式来说明,说明你做的有多好。

        1. 业界对标的时候,可以参见BeafQPS方法论。
      2. 其次能力建设这部分,最好在结果中说明:你建设的这个能力,已经产生了什么技术价值,比如这个能力已经被复用到了xxx地方产生了yyyy结果,这样会好很多。单纯的能力建设太low。

    6. 日常就需要积累关于晋升材料中可能用到的文字描述、图片素材之类的。

  5. 关于Team Goal 或者OKR的编写

    1. 技术同学写的Team Goal或者OKR,是否可以直接被业务同学拿过去直接使用?(如果能直接被复用,则说明写的不是技术价值)比如技术同学和业务同学都在讲迭代效率,那么双方在描述迭代效率上是否会有区别呢?
  6. 如果你是方向负责人、团队负责人,那么要经常考虑你的团队是否投入了太大的精力在业务需求上,是被业务需求(问题)驱动的,还是说你的系统的架构、能力建设已经走在了业务的前面,已经在技术架构、技术贡献上做了足够多的探索。如果一个团队如果一直在做业务需求,那么这个团队的技术同学的独特价值怎么体现,是否随便换一拨人来搞也能ok。

  7. 日常工作中,我们的工作内容需要聚焦。其实对于团队和个人来说都是一样的。

    1. 我们首先需要有一个目标,然后基于这个目标拆解出动作,通过执行这些动作而产生对应的结果。

      1. 但是往往很多时候,我们可能初期有一个目标,但是执行的动作确不是这个目标拆解出来的,导致我们最终将上述流程反过来:拿着动作和结果去反推(或者重新定义)结果。
  8. 体系化是一个很有专业性的描述。我们的经验、能力建设、方法论等的都需要有体系化的整理。

    1. 比如你搞稳定性,你如果搞了很久的稳定性,确没有形成一个很体系化的内容,那么说明你专业性不够强。

xkrivzooh大约 4 分钟方法论经验
"重视日报和周报"

"重视日报和周报"

如果你们公司、项目组要求你们写日报或者周报,请不要抱怨,而且说实话大多数时候你抱怨了也没啥用,该写还得写。 所以转变一下思路,理性对待日报和周报。从我这些年的工作经验来看:「日报和周报其实是一个非常不错和有效的上下级沟通的工具,并且也是下级向上管理的一个不错的渠道」,所以建议认真对待日报和周报,不要把周报写成流水账之类的完全没有任何营养的文章。


xkrivzooh大约 2 分钟post经验
打赏
给作者赏一杯咖啡吧
您的支持将是我继续更新下去的动力
微信微信
支付宝支付宝