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