本篇訪談錄於 2020 年 3 月。丹·納（Dan Na）是 Squarespace 的 Staff Engineer 兼團隊主管。
我的角色與團隊#
我是 Squarespace 的 Staff Engineer。Squarespace 是打造漂亮線上形象的一站式領先平台：網站、網域、線上商店、行銷工具、預約等。我同時是國際化平台（Internationalization Platform）團隊的團隊主管，負責打造與維護 Squarespace 各產品跨國際化的基礎原語，讓工程師用我們的工具與函式庫做出在地化產品。
Staff-plus 工程師在做什麼#
Staff-plus 工程師的日常職責因人而異，取決於你的確切角色，以及職責如何對應到組織裡。
身為團隊主管，我對團隊的產出——無論商業或技術面——負完全責任：
- 商業面：我花很多時間和公司各團隊與職能開會（產品、策略、客戶營運等），確保有盡可能多的輸入，來驗證團隊的路線圖反映公司最重要的優先級。
- 技術面：我常在審查技術文件，或站在白板前替團隊進行中的工作劃定範圍。我的角色已從親手寫程式，演變成更多對架構決策與部署策略提出探問。
一個諷刺是：身為 Staff Engineer，我實際寫的程式比當非 Staff 時少很多。這不是這個角色的普遍真理，但在我團隊的脈絡下，關掉 vim、轉為更策略／監督的角色，是我時間的最高槓桿用法。我很幸運，團隊本身已由很棒的工程師組成，所以我具體的程式碼貢獻對產出沒那麼關鍵。
Squarespace 有許多 Staff-plus 工程師不是團隊主管，寫很多程式；有些人專注在工程流程與文化。整體而言，Staff-plus 的職責高度依脈絡而定。
最有影響力的地方#
我在高於個別專案與團隊層級的工程討論裡有一席之地。我們有定期的 staff 工程會議，討論跨團隊、技術與非技術性質的問題。
舉個假想例子：我會很自在地在這類會議上，提出我認為工程 onboarding 流程的不足。像 onboarding 這種主題很難歸屬到某個特定團隊，但「沒有正式所有權」不代表它比較不重要。
我認為 Staff-plus 的一項關鍵責任，是願意承接所有促成（或阻礙）工程產出的事，這既包含技術策略，也包含文化。
至於改變了什麼：日常中，我的頭銜在對話一開始就賦予高度可信度。我不是在提倡「頭銜重於想法」的文化，但如果說它沒幫我推進或升級一些以前較難推動的議題，那是騙人的。
倡議變革#
我其實不太用「類別」去想倡議這件事。我大多只是希望我們的工程團隊與產品盡可能做到最好，並處理經驗告訴我能幫上忙的事。幾個例子：
- #connect-engineering：我剛加入時公司正經歷巨大的員工成長，我注意到除非剛好一起做專案，否則很難認識其他團隊的人。於是我建了一個 Slack 房間，用 bot 每兩週隨機把工程裡兩個人配對去喝咖啡。這個房間已經幫人配對喝咖啡超過兩年。
- 工程管理讀書會：我從個人經驗知道工程領導角色可能讓人感到孤立，也從同事口中聽到那種孤單。於是我和幾位同儕辦了非官方的工程管理讀書會，開放給團隊主管與工程經理。現在有兩個自組讀書會、各約 10 人，替新手與資深領導者提供互相支持的安全空間，回饋非常正面。
平心而論，這兩個例子都不需要 Staff-plus 頭銜。但我確實認為，當一個有效的 Staff-plus 工程師，一部分就是像在意技術缺口一樣在意文化缺口。
晉升到 Staff 的過程#
我以 Senior Software Engineer II（低 Staff 一級）被聘進來，幸運地落在一個做高影響專案的團隊，能立刻貢獻。專案最難的部分正好是我已熟悉的問題空間——跨程式碼庫的大範圍改動——我提案、做原型、最終出貨了一套我認為能讓公司更有勝算的替代架構。那成了我們的前端翻譯系統，我在工程部落格寫過（Building a System for Frontend Translations）。
我也負責新翻譯系統的溝通與教育：在內部會議報告架構、寄相關的專案進度郵件。把這項技術貢獻，和一些有意義的文化行動（其他內部報告、#connect-engineering 等）綁在一起，我的經理就有了很好的晉升理由，並獲得工程總監們的同意。
給剛上任者的建議#
沿職涯階梯往上，是一個「被迫在意比以前更多事情」的累加練習。在意更多事情很難。
- 一個簡單的例子：實習生在意他能在三個月內做出的功能一小塊；正職工程師在意那個功能的整個生命週期；團隊主管／經理在意組成一個產品的整套功能；總監在意其組織擁有的整套產品……以此類推。
- 階梯每往上一階，就意味著你在意「多一層抽象」，同時仍在意你當前層級以下的所有層。
Staff 工程角色也類似：你離開特定技術領域的舒適圈，走進更一般的問題領域——工程本身。身為領導者，你離開潛在的技術舒適圈，進入「影響工程產出的一整套挑戰系統」。哪些是掉進團隊所有權裂縫之間、最拖累工程團隊的大問題？那些現在都是你的問題，外加你技術領域的所有問題。
所以 Staff 雖是個令人嚮往的頭銜，也伴隨顯著增加的責任。無論你願不願意，你現在都是領導者。
贊助其他工程師#
我認為贊助（sponsorship）是任何資深角色的關鍵責任，對任何工程組織的成長都很重要。定義因人而異，對我來說一個具體做法是提供曝光機會：
- 讓較資淺的隊友有機會擁有並在更大的會議上報告自己的工作。
- 主動找剛出貨很棒功能的團隊，替工程部落格寫文章。
- 鼓勵我在 #connect-engineering 喝咖啡認識、有獨特經驗或觀點的人做內部報告。
- 確保會議不被少數大聲的人主導，並徵詢在場每個人的意見。
- 在大型 Slack 房間公開讚許剛做了很棒但大家沒看到之事的人。
拉臘·霍根（Lara Hogan）有一篇很棒的實務文章：What does sponsorship look like?
為何走 Staff 路線#
有，而且我至今仍積極考慮管理。我知道把兩條階梯想成互斥比較方便，但我不這麼想。我仍享受出貨程式碼與帶團隊，我認為能在高水準上兼做兩者，對長期工程成功至關重要。
Charity Majors 有篇很棒的文章 The Engineer/Manager Pendulum，我推薦一讀。她主張「管理職涯 vs 工程職涯」是假二分法，花時間在兩個角色間交替會讓你兩者都更好。這符合我的經驗：我是更好的經理，因為我知道在一個規劃糟糕的專案裡當 IC 有多痛苦；我也是更好的 IC，因為我知道專案走偏時該如何、何時拉警報。
打造軟體最重要的策略技能之一，是收斂到務實決策的能力。我一再看到的失敗模式是：產品經理帶著商業需求來，工程師帶著技術反對來，雙方都不願讓步。能同理兩邊誘因、駕馭這股張力，是把事情做成的唯一辦法，而培養這種同理最好的方式，就是兩張椅子都坐過。
具體回答這題：我加入 Squarespace 前的上一份工作是工程經理。我熱愛當工程經理，但想保持技術敏銳，所以接了 IC 角色，後來被晉升為 Staff。
學習來源#
在工程領導的脈絡下，兩本書特別突出：
- 《High Output Management》（Andrew Grove）：我此生最愛的工程領導書。每年我都會從書架拿起它，然後不小心又重讀一遍。書中許多想法深刻形塑了我對工作與領導的看法：「衡量一個經理的標準，是他底下組織的產出」「授權不是放棄責任」，以及工程／管理槓桿的概念等。談工程領導的戰術面，我至今仍認為 Grove 這本最好。
- 《Resilient Management》（Lara Hogan）：領導的人性面。我有荒謬的好運，2013 年在 Etsy 展開紐約科技生涯，Lara 是我第一位工程經理。她是拆解與處理「駕馭情緒與個性、培養心理安全、贊助同事」這些最難之事的大師。在她底下直接工作近四年，她絕對貨真價實、言行如一。
非書籍方面：我訂閱並享受閱讀 Will Larson 的 Irrational Exuberance，他常以高度務實與策略性的視角寫工程管理。我最近也發現並喜歡上 Marty Cagan 的 Insights Blog，主要因為產品領導是我較不熟、想多學的領域。
我的榜樣是這些年來密切共事的一些很棒的同事。我在 Etsy 和 Daniel Espeset 並肩坐了四年，學到無數關於「把技術執行與文化影響耦合起來」的東西。看 Lara 倡議並實現整個工程組的薪酬平等，我學到很多。看現在的同事如 Tanya Reilly 建立並演進我們的工程流程以匹配不斷成長的規模，我也學到很多。最激勵我的，是那些我親眼見證、不論路上遇到什麼摩擦，仍有勇氣讓公司變得更好的人。