多數職涯階梯為公司內的 Staff 工程師定義了一套單一、統一的期望。清楚的角色期望人人受惠，但職涯階梯這個工具，套在「一群人」身上比套在「單一個人」身上更管用。對 Staff-plus 工程師尤其如此——他們的職涯階梯往往用一個稱謂，遮蓋了背後好幾種截然不同的角色。

作者訪談的人越多，這些經驗就越明顯地聚成四種模式。多數公司側重其中一兩種，有一種只存在於數百甚至數千名工程師的公司，也有少數公司完全沒有技術領導模式，把所有資深工程師都推向管理職。在文學裡，反覆出現的角色模式稱為「原型（archetype）」，例如「英雄」或「搗蛋鬼」；用這個詞來標記 Staff-plus 工程師的常見變體很貼切。

四種常見原型#

• 技術主管（Tech Lead）：引導某個團隊的做法與執行，與單一主管緊密合作，有時橫跨聚焦領域內的兩三位主管。
• 架構師（Architect）：對某個關鍵領域的方向、品質與做法負責，結合對技術限制、使用者需求與組織層級領導的深度掌握。
• 解題者（Solver）：深入任意複雜的問題，找出合適的前進路徑。有人長期專注一個領域，有人則依組織領導的指引在各熱點間穿梭。
• 左右手（Right Hand）：延伸某位高階主管的注意力，借用其職權範圍與權威來運作特別複雜的組織，為大型組織的領導者提供額外的領導頻寬。

這套分類法重在「有用」而非「完整」。到目前為止，作者訪談過的每一位 Staff-plus 工程師都能歸入其中一類，只是有些人比其他人更好分類。

技術主管（Tech Lead）#

呈現技術主管原型的故事：Diana Pojar、Dan Na、Ritu Vincent

技術主管是最常見的 Staff 原型，帶領一個團隊或一組團隊的做法與執行。他們擅長界定複雜任務的範圍、協調團隊解決問題，並在過程中排除障礙。技術主管往往承載著團隊的脈絡，維繫團隊成功所需的許多跨團隊、跨職能關係，是產品經理最緊密的夥伴，也是路線圖需要調整時第一個被找上的人。

在職涯早期，他們曾親手實作團隊中最複雜的技術專案；但到了現在，他們預設把這類專案分派到團隊各處——一方面培養隊友，一方面也承認：當技術主管寫程式的時間縮短，團隊的影響力反而擴大。雖然寫得少了，他們仍是為團隊定義技術願景、並在複雜議題上凝聚共識的人。

對許多人來說，技術主管是他們第一次擔任 Staff 工程師的經驗。這背後有幾股力量：

• 技術主管角色傾向在「團隊」概念強烈的公司早早發展，這在採用敏捷方法的公司很常見。
• 技術主管的日常工作與你身為資深工程師時已在做的最為相似，轉換相當直覺。
• 最重要的是，組織大約每八位工程師就需要一位技術主管，使它遠比其他原型常見。

有點令人困惑的是，有些公司把 Tech Lead 當「頭銜」，有些當「角色」。在這份原型清單裡，技術主管是一種運作為 Staff 工程師的方式；但很常見的是有人扮演技術主管角色、卻沒有達到 Staff 級別該有的影響力。你會發現非 Staff 的工程師展現著每一種原型的行為。當一名 Staff 工程師不只是一個角色，而是角色、你的行為、你的影響力，以及組織對這一切的認可，四者的交集。

架構師（Architect）#

呈現架構師原型的故事：Joy Ebertz、Katie Sylor-Miller、Keavy McMinn

Architect 這個頭銜在許多公司已退流行，但架構師「角色」在 Staff-plus 層級依然活躍。架構師對公司內某個特定技術領域的成敗負責，例如公司的 API 設計、前端技術棧、儲存策略或雲端基礎設施。一個領域要值得配置架構師，它必須既複雜、又持久地對公司成功至關重要。

有一種有害的刻板印象認為架構師閉門造車地設計系統，然後把設計丟給別人實作。那確實在某些情況發生，但這麼說會冤枉受訪的架構師們。有影響力的架構師把精力投注在維持對「業務需求、使用者目標、相關技術限制」的親密理解，用這份洞察去辨識並倡議領域內有效的做法，並以他們靠長期展現良好判斷力而贏得的組織權威來推動。

架構師角色傾向在較大型的公司、程式碼庫特別複雜或高度耦合的公司，以及正努力償還初期為追求產品市場契合而累積之技術債的公司中演化出來。有些公司要求架構師持續深入程式碼庫，有些則明確期望架構師不得寫程式碼——兩種模式在不同公司都行得通。

解題者（Solver）#

呈現解題者原型的故事：Bert Fan、Nelson Elhage

解題者是組織信任的代理人，深入棘手問題，持續鑽研直到解決為止。這個角色的人被調去處理組織領導層認定為關鍵、卻缺乏明確做法或執行風險極高的問題。

多數 Staff 級角色需要大量的組織斡旋，解題者則通常處理已被認定為組織優先事項的問題，因此需要做的「組織喬事」相對少。但另一面是，他們通常在問題被控制住後就抽身，這會造成一種短暫過客的感覺，需要細膩的手腕，才不會激怒被留下來維護那個「已解決」問題的團隊。

解題者最常見於把「個人」而非「團隊」視為規劃與所有權基本單位的公司。在這類公司，解題者常取代技術主管而盛行。在傳統上以衝刺為中心管理的公司，你較不會遇到這個角色，直到公司變得夠大或夠久、養出自己那一款技術債為止。

左右手（Right Hand）#

呈現左右手原型的故事：Michelle Bu、Rick Boone

左右手是最罕見的原型，通常在組織達到數百名工程師時才出現，近似於一位不帶直接管理職責的資深組織領導者。Rick Boone 把自己的角色比作《權力遊戲》（Game of Thrones）裡的「國王之手（Hand of the King）」與《白宮風雲》（The West Wing）裡的 Leo McGarry，以資深領導者借來的權威運作。然而借來的權威也帶著義務：必須與那位領導者的做法、信念與價值觀保持深度一致。

這個角色的人會出席其領導者的幕僚會議，透過把重要問題從領導者的盤子上移開，來放大領導者的影響力。這個層級處理的問題從來不是純技術性的，而涉及業務、技術、人、文化與流程的交集。

左右手常一頭栽進某場「火災」，修正做法、把執行分派給最合適的團隊，然後又跳到組織別處的下一場火。這類角色的樂趣在於你只處理最要緊的問題；悲劇則在於，當那些問題解決時，你早已趕往下一個議題。

哪一種適合你？#

思考哪種原型適合你時，先反思哪些工作能讓你充滿能量，再考量公司內有哪些角色可得。

• 所有公司都會發展出對能勝任技術主管者的需求，這使它成為你取得首個 Staff 角色最容易入手的原型。
• 強調個人所有權（而非團隊所有權）的公司常較早發展出解題者；嚴格採行衝刺或敏捷方法的公司則傾向較晚、甚至從不發展它。
• 在近期快速成長的科技公司中，架構師與左右手通常分別在組織達到約一百名與一千名工程師時才浮現。文化 DNA 不同的公司可能更早、有時則永遠不會發展出它們。

成功的關鍵在於保持投入，因此了解哪類工作能點燃你至關重要。技術主管與架構師往往多年與同一批人處理同一批問題，發展出緊密的團隊感與共同目的；解題者與左右手則在火場間穿梭，與合作對象的互動更偏交易性，雖與執行層領導緊密對齊、較易獲得認可，卻常缺乏社群歸屬感。

每一種原型都有人熱愛、覺得深具回報，也有人做得心灰意冷。鎖定一個適合自己的原型固然重要，但也值得記得：在三、四十年的職涯裡，你有足夠的時間去逐一嘗試每一種原型。