研究所時期，身為實驗室的師兄，我必須帶領學弟妹完成各種公民營機構的合作計畫案。那是我第一次接觸到「領導技術團隊」這件事——這件學校不會教的事。
後來，在新創圈打滾，陸續經歷了小工頭、技術負責人、部門主管等身分轉變，甚至也有機會從事跨部門、跨團隊的 Scrum master 及變革推動者。資歷增加，守備範圍不斷擴大，一路走來，跌跌撞撞在所難免。遇到挫折時，不免自問：這真的是我想走的路嗎？我不能只當單純的個別貢獻者 (individual contributor) 就好了嗎？
沒有 mentor 在身邊，得向書籍求教。
書架上不乏經理人職涯發展的忠告。針對經理人與個別貢獻者兩種職涯路線的分野，《彼得・杜拉克的管理聖經》(The Practice of Management) 如是說：
專業人員和經理人一樣，同時肩負「工作」和「團隊運作」的責任。差別：經理人必須為成果負責，因此他必須為別人的工作負責。個別專業貢獻者無論採取單獨工作方式，或是團隊的一分子，也為成果負責，但只為自己的工作成果負責。唯有當其他人了解他的工作成果，並且能運用他的工作成果時，他的工作才能發揮功效。
但是，優秀的專業人員往往不是傑出的管理人才。原因不見得在於專業人員寧可獨自工作，而是他們通常很厭煩行政作業。優秀的專業人員往往對行政管理人員缺乏敬意，他欽佩的是在專業領域中表現比他優秀的人。
企業需要的是為個別貢獻者提供一條與管理職位平行的升遷管道。這些新升遷機會的聲望、重要性和地位應該和傳統管理職位沒有兩樣。專業人員的上司應該有能力協助、教導、指引屬下，他和專業人員的關係應該好像大學的資深教授與年輕教授之間的關係，而不是從屬關係。
至於經理人路線，針對一般領域的經理人，《經理人的一天：明茲伯格談管理》(Managing) 如此提醒：
只會溝通的管理者，從來不會完成任何事情；只會行動的管理者，最後是一人包辦所有事物；只在乎掌控的管理者，可能下面只剩一些唯命是從的馬屁精。
有效的管理者不會在各個角色之間保持完美的平衡，他們雖然無法忽視某些角色，但可以偏向其中幾個角色。管理工作的關鍵在於，把管理的所有面向融入這種動態平衡中。
進一步，針對技術領域的經理人，《領導者，該想什麼？》(Becoming a Technical Leader) 提出犀利的拷問：
我能一面當領導者，一面繼續提升我的技術能力嗎？一個毫無技術背景的人，有可能在技術界成為領導者嗎？一旦成為領導者，我必須犧牲多少技術專業能力？我能得到多少回報？
諸位大師所言極是。不過，資質駑鈍如我，難以直接將如此泛化的建議轉換到軟體技術領域。畢竟在我們這個領域裡，技術深度與廣度皆日新月異，技術選型更迭頻繁，更講究組織扁平以迅速應變，因此，過去那些針對一般領域、甚至一般技術領域的職涯分化發展通則，未必能夠不假思索直接套用到軟體技術領域。
我更期待看到具體建議，而且是專門針對我們這個軟體技術領域而提出的具體建議：
-
軟體研發者，在不同的職涯階段，對於溝通、行動、掌控三個面向，各該保持哪一種動態平衡狀態？
-
軟體研發者，在不同的職涯階段，對於軟體技術能力，該追求或維持到什麼程度？又該如何做到？
-
軟體研發者，面對「經理人」與「個別貢獻者」兩條路線，是否只能二選一？是否都是單行道？
這類疑惑，沒有 mentor 在身邊，實在難以解決。
因此，當我看到 Camille Fournier 寫的《經理人之道：技術領袖航向成長與改變的參考指南》(The Manager’s Path) 這本書，以她從軟體工程師開始，一路做到 CTO，甚至避險基金公司常務董事的豐富經驗，直言不諱道出具體觀點，不禁擊節讚嘆。
這不是一本廣泛適用所有人的管理學書籍，而是一本專門寫給工程經理的工具書。工程管理是一門技術學科，而不是僅僅一套帶人心法。
譬如說，對於尚處於非正式的技術負責人 (team lead) 階段，她建議要專注在：透徹瞭解架構、注重團隊精神、領導技術決策、溝通。到了更正式的工程經理 (engineering manager) 階段，她建議，除了必須增進人員管理技能，萬萬不可忘記繼續維持技術敏銳度：
從我的經驗來看，絕大多數工程部門管理的挑戰都在「工程」與「管理」的交集處。人事管理不容易，我不會低估處理人際關係的挑戰，而這些與人打交道的能力在各行業都吃得開。
然而，工程部門管理的挑戰並不僅止於人員管理的面向。我們管理的是一群技術人員，且我們之中大多數人來自技術專家的職位。我決不會建議非技術專業背景人員管理工程部門！在技術上長年累積的專業有助於獲得團隊的信任，並幫助你領導團隊做出高效決策。當你努力成為一名成功的工程主管，不要低估技術能力的價值。
點出「維持技術敏銳」的重要性之後，她也建議初階技術主管可以這麼做：
當然，你要學會平衡的藝術。當你轉換跑道到管理職時，維持技術敏銳可能是一項艱鉅挑戰。然而，在管理團隊的這個階段，假如你不再維持對程式碼的敏銳度，你將面臨在職涯發展中過早和技術脫節的風險。雖然你日後打算走管理職，但這也不代表你應該放棄技術責任。事實上，我在關於 Engineering Lead 的職位描述中特別提過，我希望這個職位的經理還要負責交付小功能並修復 bug。
可悲的是，某些公司實際上並沒有開出「有一點時間開發程式碼的經理」的職缺。我的建議是繼續維持對技術的敏銳度，直到你真的認為自己夠懂程式碼和系統設計等領域，再決定你是否想轉換到管理職。一旦和程式碼說了再見，重新回到程式碼的懷抱將格外困難。更有甚者，假如你過早與技術脫節，你可能因為技術專業積累的不足，而無法朝更高的管理階層邁進，最終只能止步於中階主管職。
對於逐漸昇到類似工程總監位子的人，她也提出具體建議以盡可能維持技術敏銳度：
幸運的是，對我們來說，還有幾個不需要碰大量程式碼的辦法幫助我們保持手感。對於二級審核人員來說，程式碼審查就是個好方法。假如你更親力親為地建立系統，請繼續關注這些系統，因為你會比大多數人更能牢記技術細節，可以透過程式碼審查和提問來幫助為這個系統工作的工程師。
最後，即使你不大算寫太多 code，我也強烈建議你每週至少有一個完整的半天時間，不要安排任何會議或其他工作，專注在一些富有創造性的追求，比如撰寫關於技術的部落格文章、準備科技大會的演講內容，或者參與一個開源專案。
針對軟體技術領域，「經理人」與「個別貢獻者」兩條路線的取捨，她的觀點是：
一定要記得你有權利更換職涯跑道。人們通常會在某個時候嘗試管理職，然後發現他們不喜歡當主管，兜兜轉轉回歸技術職位。走上管理職，你不是不能回頭，但記得睜大眼睛去嘗試。每個職位角色都有各自的優缺點，自己親自去感受最適合你的那一種。
她也建議如何引導下屬對「經理人」與「個別貢獻者」兩條路線進行探索：
在人們夠格被升職到資深工程師或更高的職等之前，鼓勵他們累積管理或指導經驗。對於大多數公司來說，管理職和技術職的分岔點應該是人們開始展現領導力的階段，無論這個領導力是管理人員還是設計軟體。即便人們負責設計軟體，也會面對人與人之間的互動與需求；出類拔萃的資深個人貢獻者也知道如何管理專案和指導團隊中佔比更多的菜鳥／初階工程師。你可以考慮將指導經驗作為資深個人貢獻者的升職條件。
以上是我從書中信手捻來的幾則精闢見解，書中還有更多精彩內容待你發掘。
我認為，身為軟體研發從業人員，只要你不是自雇者，只要你想在軟體研發組織內，統合團隊力量做一番大事，都值得細讀此書，把此書當作軟體研發者的隨身職涯教練：覆盤總結自身經驗，解決當下問題，凝聚團隊，培訓優秀下屬，並替未來道路預做準備。
這將是能陪伴你很久的一本書。
—— 敏捷魔藥師 葉秉哲 (William Yeh) 2021-02-21