每个技术人员最终可能都会走上管理岗位,从最初的开发 Leader、到部门负责人、甚至到 CTO,这每一个角色的转变,都需要付出巨大的努力去进行思维的转变。最近读的《授权》这本书可以让我们更好地胜任管理这个岗位。
本书的作者马凯特是一名海军军官,全书讲解了作者在 1999—2001 年指挥美国海军圣塔菲号攻击型核潜艇,在一两年的时间里将原本管理混乱、士气低落、倒数第一的圣塔菲号打造成太平洋舰队中凝聚力、战斗力俱佳的舰艇,并赢得很多奖项。
书中以在圣塔菲号上发生的各种事件为例,讲述了很多观点和方法,印象比较深刻的有以下几点:
可以说,大部分的企业以及马凯特领导之前的圣塔菲号潜艇的管理方式都是「领导者-追随者」模式。员工都是听「命令」做事,能把安排的事情按时完成就已经很不错了。
有一次,马凯特下命令将电力推进装置的转速由 1/3 提升到 2/3,命令一层一层地传达到最底层的执行人员,才反馈说电力推进装置没有 2/3 转速。其实在接收第一道命令的人员就知道没有 2/3 转速,但因为是上级下达的命令,即便是错误的,还是照常执行。
我们平时工作中,类似的事情屡见不鲜,所以说在「领导者-追随者」模式下,领导者的能力和眼界就成为了团队的瓶颈,不能充分发挥每个人的才能。
而「领导者—领导者」模式的核心是让员工有充分的决策权决定做什么和怎么做,整本书就是在讲解怎样慢慢转变成「领导者—领导者」模式。
「我计划…」是一种具体的手段,指的是,在汇报工作时,以我计划作为开头,后面接自己准备怎么做,以及可能有什么风险等。目的是为了让员工能主动思考,而不是被动接受。
领导:小王,系统中需要添加日志功能,可以使用 log4? 小王:功能已经实现了 领导:日志能存储到数据库中吗? 小王:现在只能记录到文本中 领导:不同类型的日志有区分吗? 小王:现在只记录在一个文本文件中 领导:……
领导:小王,系统中需要添加日志功能,想想怎么实现? 小王:在 dotNET Core 中,比较流行的就是使用 NLog 和 Serilog,我对比了下两个组件,Serilog 的扩展性更好,有很多的插件可以使用。我计划这样来实现:
领导:好的,按照你的思路先实现一版吧。
上面的例子不一定恰当,但应该能说明问题: 1、领导早安排任务的时候,不能条条框框限制太死,需要给员工足够的空间; 2、员工在汇报时,应该有自己的独立思考,尽可能多的想到各种情况,如果存在多种解决方案时,可以都给出,并给出自己的建议和推荐理由,这样领导只是做下确认就可以了。
当你引进一些全新的、亘古未有的东西时,有些人能够明白,在圣塔菲号上,我们确实有一些军士长马上就明白了,比如沃尔舍科高级军士长和拉森军士长;有些人过一会儿明白了;另外一些人则要花很长时间才能明白。
什么是重要的事情呢?
每个团队成员只有充分理解了公司的愿景、团队的目标,才能将自己的个人发展和此联系起来,实现双赢,但每个人的理解速度有差别,所以需要反复强调,不能嫌麻烦。
比如目前我们团队的目标就是按时交付高质量的迭代版本,那么只要是和团队开会、或私下沟通讨论,都会反复进行强调,直到每个人都能够深刻理解,理解之后才可能愿意更多地去思考,才可能在具体执行的时候更贴近团队目标和公司愿景。
每个人都很习惯做「分内之事」,缺乏思考,长时间下去就会从一个初学者变成一个熟练工,工作 10 年,也就是 1 年的工作经验重复了 10 年。持续思考,总结,提升自己的技能并且能同时朝着团队目标和公司愿景在前进,这样你的能力才会超出你的职责,才有升职加薪的可能。每个人都能如此,团队也就变得强大了。
最近有团队成员和我沟通,说每天都只是在改改 Bug,做一些小功能,感觉没什么挑战,这就是典型的将自己局限在「分内之事」的表现。
再简单的事情也能做到极致,前提是要清楚自己要做什么,在做什么。在开发中最怕的就是开发出来的东西不知道是做什么用的,只是按照要求这样做了。
所以在工作安排或者会议沟通时,需要添加一个环节:反向交底,分配的任务,每个人需要说出自己的理解以及「我计划…」,会议沟通时,也不能最后问一句,大家还有问题没有?然后没人回答,就此散会了,也需要每个人都谈谈个人的理解,每个人都能理解,会也就不白开了。
任何公司都有各种各样的流程,流程是手段不是目的。流程可以帮助我们进行管理,但一定不能受到流程的束缚。
因为潜艇部队并没有将救火作为核反应堆操作人员的训练科目。海军所倡导的理念是:最好的操作应该是由最专业的人员按照标准工作流程进行的。
因为流程规定救火只能是专门救火人员才能进行,所以,在演习的时候,有一个地着火了,结果周围的人全部都撤离。潜艇的走道是非常狭窄的,这些救火的人根本过不去,那边要撤退的人也撤不出来,卡在那儿。然后那边的火越着越大,如果真的是着火的话,就会造成严重的后果。
如果是朝着灭火的这个目的,肯定是离火最近的人拿起灭火工具把火灭掉就可以了。
能够独立思考,才有可能提出质疑,在「领导者-追随者」模式下,每个人都是你说什么我做什么,都认为领导说的是对的,那质疑就无从谈起了。
鼓励质疑是发挥集体智慧的一种手段,领导也不是神,也有会出错的时候,这时如果能够有及时的质疑,就能避免一些错误的发生。
在平时的工作中,因为有各种考核手段,每个人都害怕出错,写程序时害怕出 Bug,那有没有不出 Bug 的程序呢?答案是:有,具体可以看看 Github 上的这个项目:https://github.com/kelseyhightower/nocode 。
当然,那个项目只是个玩笑,只要有代码输出就可能会有 Bug,如果是一个追求卓越的程序员,会想办法去做重构,让代码变得更易读、扩展性更好,在这个过程中可能会出现新的问题,我们应该多思考怎样来解决问题,而不是规避问题的方式来减少错误。
以不断减少错误的方式行事,最后结果就是金玉其外败絮其中,后果终究还是要自己来承担,至今还没有谁能打破墨菲定律。
马凯特通过「领导者-领导者」的管理模式使圣塔菲号有翻天覆地的变化,更厉害的是在马凯特离开圣塔菲号十年内,这里仍然人才辈出,领导力得到了传承,这才是最高境界。
如果领导者总是试图「事事亲力亲为」并依靠自身「人格品性」,他们一旦缺席,将会给组织的表现带来巨大影响。
推行一种新的方式始终是困难的,但不试试怎么知道呢?