為什麼工程師要有大局觀

一個團隊要在A和B兩個軟體中做出選擇。這兩個軟體都擁有必要的功能，但A軟體明顯更容易設置，它就是能發揮作用。B軟體則更難一些：它需要幾個衝刺週期的啟動時間，而沒有人願意等那麼久。

從這個團隊的角度來看，選擇A軟體是個明智的決定。何必要選擇其他東西呢？然而其他團隊寧願他們選擇B軟體。因為事實證明，A軟體會給法律和安全團隊帶來持續性工作，它的認證需求意味著IT和平台團隊將不得不永遠把它作為一個特殊案例。選擇A軟體，即該團隊的區域極大值（local maximum，單個群體的最佳決策），此團隊在不知不覺中選擇了一個對公司整體來說得投入更多時間的解決方案。B軟體對團隊來說只是稍微差一點，但整體上要好得多。額外的兩個衝刺週期將在一個工作季度內得到回報，但這一事實只有當團隊中有人以更具大局觀的視角來觀察時才得以顯現。

為了避免產生區域極大值，團隊需要決策者（或至少是決策影響者）從局外人的角度看見更大格局—同時考量多個團隊的目標，並選擇一條對整個組織或整個企業最有利的道路。

與看到現在的大局同等重要的是，預測你的決策在未來會如何發展。一年後，你會對什麼事情感到後悔？三年後，你會希望你現在就做哪些事情？為了朝著同一個方向前進，各個小組需要在技術策略上達成一致，比如要投資哪些技術、對哪些平台進行標準化等等。這些巨大決定的最終結果可能難以捉摸，而且往往是有爭議性的，所以做出決策的關鍵要點在於能夠分享脈絡資訊，並幫助其他人確實理解。

因此，如果你想做出廣泛的、具有前瞻性的決定，你需要能夠看見大局的人。但是，難道這個人不能是經理嗎？難道不能由首席技術長（CTO）來搞懂所有的「業務事項」，將其轉化為技術目標，告訴下面的人嗎？

在一些團隊中，他們確實可以。對於一個小團隊來說，經理往往可以擔任最有經驗的技術專家，負責重大決策和技術指導。在一個小公司裡，首席技術長可以深入參與每個決定的細節。這些公司可能不需要Staff工程師。但是，管理權限可能會掩蓋技術判斷：即使有更好的解決方案，下屬可能會覺得與經理爭論技術決測是不合適的。而管理本身就是一項需要全身心投入的全職工作。一個致力於成為優秀人事經理的人，很難分配較多時間去瞭解技術發展的最新情況，而任何身處複雜工作情境的管理者，會較難滿足其下屬需求。

那「架構師」呢？在一些公司，「架構師」是職涯階梯中技術軌道上的一個職等。在其他公司，架構師是抽象的系統設計師，他們有自己的職涯路徑，與實作系統的工程師不同。在本書中，我打算將軟體設計和架構視為Staff工程師角色的一部分。

為什麼工程師需要領導跨團隊專案

保持專案進展的一個方法是讓某人對整個專案擁有全部的所有權，而不是這個專案的任何個別部分。甚至在專案啟動之前，這個人就可以清楚界定專案範圍，並建立一個提案。當專案開始後，他們很可能是大方向系統設計的作者或共同作者，也是專案的主要聯絡人。他們秉持高工程標準，以經驗為據預測風險，並提出切中要點的困難問題。他們還會花時間非正式地指導或輔導，或是為專案的各個部分的負責人樹立一個好的榜樣。當專案陷入困境時，他們有足夠的視角來追蹤原因並進行疏通。在專案之外，他們要描述正在發生的事情和原因，向公司其他部門推銷願景，並解釋這項工作將會實現願景，以及新專案如何影響到每個人。

技術專案經理（TPM）難道不能做好這種建立共識和溝通的工作嗎？確實，在TPM的職責上與此有所重疊。不過，總的來說，TPM負責的是交付，而不是設計，也不是工程品質。TPM負責確保專案按時完成，而Staff工程師則負責確保專案以高工程標準完成。Staff工程師負責確保開發出來的系統是強大的，並且與公司的技術環境相輔相成。他們謹慎看待技術債，對任何會成為這些系統未來維護者的陷阱的東西都保持警惕。

經驗不足的團隊成員可能從未見過好的軟體如何被製作出來，或者可能認為生產程式碼是軟體工程中唯一重要的技能。經驗豐富的工程師可以透過指導程式碼和設計審查，提供架構的最佳實踐，以及打造各種工具，使大家的工作更快、更安全，因而發揮巨大的影響力。

Staff工程師是人們的榜樣。經理負責在他們的團隊中建立文化，強制執行好的行為，並確保標準得到滿足。相對地，工程規範是由專案中最受尊敬的工程師的行為而設定的。

Staff工程師雖然不是經理，但仍是領導者

先講重點：Staff工程師是一個領袖角色。Staff工程師通常與部門經理具有同等資歷。Principal工程師的資歷通常與總監（Director）相仿。身為一名與經理職等對應的Staff+ 工程師，你被期待與他們一樣成為「房間裡的大人」。你甚至會發現，你比組織中一些經理更資深、更有經驗。每當出現「應該有人在此時做出行動」的感覺時，這個人極有可能就是你本人。

你一定得成為領導者嗎？中階工程師有時會問我，他們是否真的需要精通「那些軟綿綿的人際關係」才能更上一層樓。難道技術能力還不夠嗎？如果你是那種因為想做技術工作而進入軟體工程領域的人，不喜歡與其他人類打交道，那麼當你在職業生涯中遇到了這堵牆，你可能會覺得不公平。如果你想繼續成長，扎實的技術實力只能帶你走到這裡。完成更大的事情意味著與更多的人一起工作，這需要更廣泛的技能。

隨著你的薪酬增加，你的時間變得越來越昂貴，你所做的工作被期望具有更多價值及更大影響。你的技術判斷需要將業務的現實層面列入考量，並且謹慎思考任何特定的專案是否值得一做。隨著資歷增加，你將承擔更大的專案，這些專案如果沒有合作、溝通和協調，是不可能成功的；如果你不能說服團隊中的其他人相信你的方案是正確的，你那出色的方案只會讓你本人感到沮喪。無論你是否願意，你都會成為一個榜樣：其他工程師會從那些擁有高職等頭銜的人身上瞭解如何行事。所以，噢不，你無可避免地會成為一位領導者。

不過，Staff工程師的領導方式與經理不同。Staff工程師通常沒有直接下屬。雖然他們參與並投入於培養身邊工程師的技術能力，但他們不負責管理任何人的業績或批准假期或費用報銷。他們不能解僱或幫人升職—儘管團隊經理應該重視他們對其他成員的技能和產出的意見。他們的影響力發生在其他方面。

領導力有很多形式，而這些形式可能不會使你立即察覺。它可以來自於設計「快樂路徑」的解決方案，保護其他工程師免受常見錯誤的拖累。它可以來自於審查其他工程師的程式碼和設計，提升他們的信心和技能，或者，領導力也能來自於強調一個設計方案沒有滿足真正的商業需求。教學是一種領導力的形式。默不作聲地提升每個人的實力是一種領導力。設定技術方向是一種領導力。最後，擁有一個明星技術專家的聲譽，能夠大大激勵其他人為你的計畫買帳，因為他們覺得你值得信任。如果上面這些敘述聽起來跟你很像，那麼你猜怎麼著？你是一位領導者。（本文摘錄整理自《Staff工程師之路》第一章，碁峰資訊提供）

圖片來源_碁峰資訊

 書名  Staff工程師之路：獻給個人貢獻者成長與改變的導航指南（The Staff Engineer's Path）

Tanya Reilly／著；沈佩誼／譯

碁峰資訊出版

定價：580元

圖片來源_Squarespace

 作者簡介 

Tanya Reilly

擁有超過20年的軟體工程經驗，目前擔任Squarespace的資深首席工程師，從事架構與技術策略工作。在此之前，她曾任職於Google十二年，負責地球上一些最大的分散式系統。她是LeadDev StaffPlus的組織者與主持人，經常參與會議和主題演講活動。她來自愛爾蘭，現居住於美國布魯克林。