北京
“所有拉取請求都需要我審批。”這句話，正在讓無數技術領導者變成自己最厭惡的瓶頸。Mirek Stanek 在回顧自己從頂尖工程師到管理者的轉變時，對這類看似合理的控制動作做了不留情面的拆解：我們靠寫出更干凈的代碼、更優雅的架構和真正可運行的方案爬上梯子，可一旦站在團隊之上，這套賴以晉升的專長，立刻轉變為負債。
Stanek 是在一次關于工程領導書籍的調研中，聽到最多人提起《翻船》（Turn The Ship Around）。這本書前美國海軍艦長 David Marquet 接管太平洋艦隊表現最差潛艇“圣塔菲”號的故事，讓他反復琢磨一個困惑：為什么我們人數更少的小團隊，反而比大群精英跑得快？這些年他推動過品控到品保的轉型、從豎井團隊到跨職能團隊、從固定的大爆炸發布變成持續交付、從碼農養成產品工程師，但始終缺少一個能串起所有變革的共同邏輯。
Marquet 的“領導者-領導者”模型，恰好補上了這個缺口。這個模型的顛覆之處，在于它直指一個多數技術領導人不愿承認的事實：當你要求每行代碼都必須經你審核、每次部署方案都得先讓你過目，你并沒有在保障質量，而是在系統性地制造“習得性無助”。團隊停止獨立思考，因為你替所有人判斷；創新原地踏步，因為所有決定都在等你；只要你去休假，整個交付鏈路就可能搖搖欲墜。你不是質量守門員，你只是一個會寫代碼的決策單點。
Stanek 把這種模式稱為“領導-跟隨”的陷阱：領導用一身技術本領不斷釋放指令，團隊只需要跟隨。而“領導者-領導者”要做的恰恰相反——把決策權還給應有的人。這并不是放棄質量標準，而是把代碼審查從“一個人的簽字”變成群體技術對話，讓工程師重新擁有對方案的自主判斷。當每個人都是自己那份工作的領導者，團隊才不會在核心離開時出現功能性解散。
谷歌的“氧氣計劃”（Project Oxygen）曾對高效管理者的特質排過序。結果很耐人尋味：長期以來被技術管理者奉為護身符的“技術專長”，在八項關鍵行為里墊底。排在前面的，是成為一位好的教練——能傾聽、能提問、能幫人理清思路，而不是替人寫代碼。這與Marquet在潛艇中推行的“用‘我打算……’代替‘請求許可’”的溝通機制，幾乎遙相呼應。
這就是說，當我們從工程師被提拔為領導者，跨過的并不是一道“技術更精”的門檻，而是一道身份轉換的急彎：繼續用寫代碼的方式領導，等于親手把團隊鎖在自己一個人的能力上限之下。而改走“領導者-領導者”的路，則意味著要學著少給答案，多讓團隊自己找到答案——哪怕一開始，這會讓你感覺自己不再像當初那個無所不能的工程師。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
