Staff-plus 工程師的角色，很大程度取決於團隊需要什麼，以及這位工程師的強項在哪。就我的經驗，Staff-plus 工程師的職責會隨時間改變；但通常他們的主要焦點是投入對公司有策略價值的專案，同時推動技術設計、提升團隊的水準。 — Diana Pojar
被親戚在派對上逼問「軟體工程師到底在做什麼」的人都知道，要解釋這份工作有多難。而當同事湊過來問「Staff 工程師是做什麼的？」時，許多人的腦袋一片空白。
最直白的答案是：Staff 工程師持續做著讓他們身為資深工程師時成功的那些事——建立關係、寫軟體、協調專案。但這個答案會誤導人。這些任務他們照做，只是以前是工作的核心，現在成了輔助。日常安排會隨原型略有不同，但所有原型有一個共通的基礎：設定與修訂技術方向、提供贊助與指導、把工程脈絡注入組織決策、探索，以及 Tanya Reilly 所說的「當黏著劑（being glue）」。
設定技術方向#
技術無法為自己發聲，需要有效的倡議者代言。就像童書裡的羅雷司（Lorax）為樹木發聲，Staff 工程師為公司的技術發聲。成功推進技術的人務實、審慎，更看重進展的長期趨勢，而不把每個單一決策都當成生死交關的危機。可以把這想成「兼職的技術產品經理」。
設定技術方向的真實面貌，遠比你想像的更關乎「理解並解決身邊組織的真實需求」，而遠不是「優先採用你個人有興趣學的技術」。在早期角色，你或許會把決策往你有動力的技術選擇推；到了資深職位，你首先對業務與組織負責，其次才是自己。
延伸：Joy Ebertz 談促成技術願景
「當我能為一個領域促成技術願景、並讓大家朝那個願景前進時，我覺得最有影響力。我想我們都同意，希望程式碼架構比現在更好、或在某些方面改善。然而我發現，人們常有種模糊的『想要更好』，卻對那個『想要的東西』沒有清楚概念。我喜歡幫這群人對『究竟想到達哪裡』形成共識（就算永遠到不了也沒關係），並想出大致的行動計畫。」— Joy Ebertz
指導與贊助#
有一種流行的英雄式領導想像，聚焦在那些以決策改變公司未來的極高產出個人。但這類敘事多半是公關團隊刻意設計出來的好故事。你更可能透過培養身邊的工程師、而非個人英雄主義，來改變公司的長期軌跡。
最有效的 Staff 工程師會搭配適量的指導（mentorship）與更多的贊助（sponsorship）——直接把你的拇指壓在天秤上，去推進並支持身邊的人。若還沒讀過，Lara Hogan 寫過區分贊助與指導的經典文章〈What does sponsorship look like?〉。
有時人們在職涯階梯上看到「指導」的要求，便機械式地打勾交差，這很可惜——指導是 Staff-plus 角色中最有價值的活動之一。分享你的經驗與建議、並建立持續的關係去理解對方的處境，是高影響力的工作。
延伸：Michelle Bu 談如何衡量影響力
「在現在的角色，當我贊助過的人發出他們已交付成果的公告，或當我看到自己幫忙形塑或轉變了一個工程團隊對某個重要主題的認知模型時，我感到充滿能量。日復一日做著建構與支撐技術這種苦工的，是這些團隊，不是我。我以他們的進展來衡量我的影響力，更重要的是那份進展的方向性，以及他們的工作與公司目標的對齊程度。」— Michelle Bu
提供工程觀點#
高效的組織會簡化例行決策。例如審核潛在企業客戶合約：早期會簽下一些產品與工程團隊難以支援的合約，發生幾次後，審核流程就會納入更多利害關係人，久而久之對的人會在對的時間出現在對的位置。
但即使擅長例行決策的公司，遇到意料之外的決策也常卡關——那種既時間緊迫又重要、連把對的人湊在一起都來不及的決策。組織重組常在缺少能改變結果的寶貴意見下發生；一年才招一次的稀有職缺（如高階主管，或早期公司的 Staff-plus 工程師），面試流程也常漏掉某個重要面向。
Staff-plus 工程師常在意料之外被拉進這類決策的房間，得以在還能改變結果時，把工程脈絡與觀點注入決策。這些在關鍵決策上的短暫發言影響力奇大。只要記得：你代表的是整個工程團隊的利益，而非你自己的。
延伸：Dan Na 談「在場」
「我在高於個別專案與團隊層級的高階工程討論中有一席之地。我們有定期的 Staff 工程會議，討論跨團隊、兼具技術與非技術性質的問題。」— Dan Na
探索#
爬山法（hill-climbing）是一種簡單的最佳化演算法：想像你站在山上想登頂，你原地轉一圈，找出附近最高點走過去；到了再轉一圈、再找、再走，如此反覆便能登上所在的這座山。但如果是在濃霧天，因為看不遠，你可能爬到附近最高點後才發現，稍遠處還有一座更高的山。
爬山法無法解決所有問題，但因為它太有效，許多公司難以採用其他做法——像是消費導向公司難以支援企業級交易，或成熟公司難以與規模較小競爭者的發布節奏抗衡。長期來看，公司要嘛學會探索，要嘛衰亡；這不是可以忽略的挑戰。
單純指派一支精通爬山的團隊去做探索性工作，遠非萬無一失。所以許多公司改採不同做法：找幾位技能廣博、值得信任的個人，撥給一些資源，幾個月後再回來看他們發現了什麼——其中一位往往就是 Staff 工程師。
這不一定是業務問題，也可能是任何公司系統結構上不擅長處理、卻重要而模糊的問題：把基礎設施成本降低一個數量級；找出一套只需六個月而非三年的多區域策略；或者突然發現主資料庫只剩三個月的磁碟空間、又無法升級到更大容量（依作者經驗，這在快速成長的新創公司出奇地常見）。
這是公司所做最有回報、也最有風險的工作。要被託付這種工作需要大量的組織信任——包括獲得業務足夠的尊重，使得萬一失敗，那反映的是問題本身、而非你。
延伸：Ritu Vincent 談探索型工作
「在孵化器裡的現職，我整天都在做原型；但在先前的技術主管角色，我做的事就很雜。」— Ritu Vincent
當黏著劑（Being Glue）#
Tanya Reilly 寫過一篇精采文章〈Being Glue〉，點出成功 Staff 工程師的另一個核心要素：做那些必要卻常隱形的工作，讓團隊持續前進、交付成果。這並不光鮮，但高影響力的組織往往有一位或多位 Staff 工程師在幕後加速最重要的工作、確保它完成。
那麼，你還會寫程式嗎？#
Staff 工程師聚在一起時最先問彼此的問題就是：「你還找得到時間寫程式嗎？」答案當然是——看情況！
- 多數人寫一些，少數人完全不寫，但沒有人寫得像職涯早期那麼多。 偶爾會有純寫程式的一週，但那不是常態；若太常發生，通常是在做「舒適」而非「重要」的事的訊號。
- 即使寫得不多，你會大量閱讀同事的程式碼，並做相當數量的程式碼審查。
延伸引文：三位受訪者談「還寫不寫程式」
Ras Kasa Williams：「我仍規律地貢獻程式碼——當然比團隊其他工程師少；但重要的是我維持著『手放在鍵盤上』的工作，確保我的技術策略（及其他宏觀決策）是被團隊第一線的實際經驗所滋養的。」
Katie Sylor-Miller：「我是前端架構師，但最近寫最多的其實是 SQL，因為我在做大量資料分析。我一直在看效能指標，找出可改善之處，以及哪些是最能同時改善效能與業務指標的問題。我偶爾會寫點 JS 或 PHP，但多半是為了幫團隊排除障礙、或跑些效能相關的小實驗。」
Joy Ebertz：「你越資深，工作就越不關於程式碼。當然，不像人事主管，你仍有很強的技術傾向，甚至到 Principal 你大概都還會寫一些程式。但你爬得越高，工作就越關於指導與培養身邊（乃至更廣）的人、透過建立公司對外的技術品牌來壯大團隊、留意可改進或修正的更大技術趨勢、為團隊或公司設定技術願景，以及為技術債專案爭取資源。」
慢，但值得#
Staff-plus 工作有個貫穿一切的主題：時間尺度更長。職涯早期很容易迷上軟體開發「寫、測、發、重複」的快速回饋循環；而在這個層級，你多數工作是把那個回饋循環換成以週、月、年計的循環。
剛接下 Staff-plus 角色時，這種更長的時間尺度會讓人意外地感到洩氣。身為 Staff-plus 工程師，某些日子結束時覺得自己「什麼都沒完成」是正常的——撐下去！
影響力與個人成長，就活在那些更長的時間尺度裡。作者訪談過的每一個人都希望偶爾能有更多時間寫程式，也都承認有些日子擔心自己沒完成什麼——但沒有一個人後悔轉入現在的角色。