这篇的题目选的有点大,但思来想去,也只有「人性」这个词能涵盖我近期的思考主题了。
这个思考主题,跟我最近看的书有关,跟最近发生的事情有关,跟我自身的成长有关。
看第一本书,让我意识到了 engineer manager 的核心是技术能力,这个点之前也有做主程序的朋友提醒过我,TA 的原话是:当你脱离了技术,就跟项目经理没有区别了。
我的兴趣从来就不在于做单纯的管理,我喜欢跟程序员们一起解决问题,并且通过我的管理能力、领导能力来帮助整个团队达成更高的绩效和幸福感。
做 engineer manager,不代表要做最难的那个功能,而是要通过做一些小的功能,bug fix 来了解项目架构和代码发布流程,找到瓶颈。
看第二本书的时候,作者提到:
于是我开始思考:一个成长型思维的管理者,能改变一个固定型思维的下属吗?
这个问题也许没有标准答案,我目前的想法是:
再来换个角度:一个成长型思维的下属,能改变一个固定型思维的管理者吗?
你可能会问,管理者也可能是固定型思维吗?
正如此前所说,一个人的思维模式是动态变化的,一个管理者可能在他职业生涯的前五年是成长型,但是后来安于现状、害怕犯错、退缩在舒适区,TA 就回退到了固定型思维。
我对于这个问题的答案是:
为了最大化地减少「不必要的紧急任务」,我尝试了很多方法,收效甚微。
我意识到:我无法依赖团队中的成员去做「正确的事情」,我必须要提供做事的方法,培养他们的技能,而不是盲目地乐观和相信他们。
于是我在流程中引入了「里程碑」的概念,当一个任务的复杂度大于等于 5,工期超过一周时,我需要跟接手任务的程序员,一起来捋一遍任务的需求,列出几个关键的节点(比如单元测试完成,第一次代码审核完成等),每个里程碑都有完成时间。
假如错过了里程碑,我就知道这个项目的推进情况不理想,而不是等到最后一刻才被迫进入「紧急模式」。
人是有趣的动物,有些人听到表扬会有加倍的动力做好事情,有些人在失败时需要听到鼓励的话才能振作,我在管理过程中,通常也是以鼓励为主。
最近我发现,鼓励这东西吧,也不是放之四海而皆准。
比如有一个团队成员绩效不佳,并且在自评中给了自己低分,从鼓励的角度来说,管理者应该给个高点的分数提振一下对方的士气。
但是鼓励了之后,第二次绩效评估还是老样子怎么办?
我的想法是:也许这个人在摆烂,TA 知道自己做的不好,并且也在绩效中承认了自己做的不好,此时管理者需要做的不再是「鼓励」,而是提供「血淋淋的事实」。
xx,我看到这次你又给自己评了低分。是的,我也这么认为,而且我给你打的分比你的自评更低一些,我们需要正视这个问题并且着手去解决,你的绩效跟上个周期相比没有明显的进步,你需要在下个周期内作出明显的改变。
管理者一昧鼓励或者粉饰太平,只会让某些人有了「我不需要努力」的借口,而这种情况会影响到整个团队的士气和绩效。
在流程设计的过程中,假如 80% 的人都能遵守并且做到,那么不需要为了给最后 20% 的人提供便利而增加不必要的复杂度。
在培养团队成员的精力花费上也一样,假如总是给最后 20% 的人最多的时间和关注度,这对于其他人来说其实是不公平的。
从管理者自身情绪的角度来说,总是关注短板和最后 20% 的人,会有很强的挫败感和焦虑感,而一个情绪不佳的管理者对于整个团队来说都是弊大于利的。
优秀的管理者应该做到赏罚分明,恩威并施。所有人吃大锅饭,只会把团队的水平降低到短板员工的水平上(因为就算做的多做的好,也跟那个摸鱼的人没有任何区别,大家都不傻,为啥要用爱发电)。
通过自省和关键事件,我很开心地发现了自己的几个弱点,包括:
我很享受这种看透自己的、「顿悟」的感觉。
每当我以为自己做了所有的努力但是结果依旧不理想时,我会有种「山穷水尽」的挫败感。
直到某个瞬间,也许是看了某本书的某段文字,也许是跟某人进行了交谈,总之,我突然看到了,眼前这条看似无解的路,原来是「有解」的。
而且更棒的是,我是那个掌握了「解法」的人。
只要我能针对自己的弱点进行改变,我就可以改变看似无法改变的事情!
我还意识到,每当我感觉自己没有任何问题,错的都是别人时,我就陷入了一种很危险的状态。
因为我看不到自己的盲区和弱点了。
这个时候,我会提醒自己,我必须要想办法获取更多的反馈,我必须要更加用心地去思考和观察自己所做的事情,唯有看到自己的瓶颈,我才能去思考解决方案,直到参悟进入下一个阶段的秘诀。