每個技術人員最終可能都會走上管理崗位，從最初的開發 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，如果是一個追求卓越的程序員，會想辦法去做重構，讓代碼變得更易讀、擴展性更好，在這個過程中可能會出現新的問題，我們應該多思考怎樣來解決問題，而不是規避問題的方式來減少錯誤。
以不斷減少錯誤的方式行事，最後結果就是金玉其外敗絮其中，後果終究還是要自己來承擔，至今還沒有誰能打破墨菲定律。
總結
馬凱特通過「領導者-領導者」的管理模式使將聖塔菲號有翻天覆地的變化，更厲害的是在馬凱特離開聖塔菲號十年內，這裏仍然人才輩出，領導力得到了傳承，這纔是最高境界。
如果領導者總是試圖「事事親力親爲」並依靠自身「人格品性」，他們一旦缺席，將會給組織的表現帶來巨大影響。
推行一種新的方式始終是困難的，但不試試怎麼知道呢？