本篇訪談錄於 2020 年 9 月。史蒂芬·萬（Stephen Wan）是 Samsara 的 Staff Engineer。

我的角色與團隊#

我是 Samsara 的 Staff Engineer。四年前我加入時公司才成立一年、約 50 名員工；如今公司超過一千人，工程團隊分布在灣區、亞特蘭大與倫敦。

• 剛開始我們還沒真正組成團隊，約十位工程師做任何冒出來的事。九個月後人數翻倍，圍繞當時幾個核心產品組成產品團隊。
• 我短暫帶過一個產品團隊，接著轉到剛萌芽的基礎設施組，開創前端基礎設施團隊。多年來我逐漸往下沉，也在後端與可觀測性系統待過。
• 現在我在基礎設施與平台（I&P）組，多數時間和開發者體驗團隊在一起，打造工具維持我們全端開發流程的生產力。

Staff-plus 工程師在做什麼#

我們多數 Staff+ 工程師是專才角色，不是 web 基礎設施就是裝置韌體。我算落在多數，但我們 Staff 工程師的工作很多樣，很難說誰是「正常」的。

• 對照 IC 與管理雙軌，Staff 被視為等同總監（director）的角色。Staff 工程師可選擇參與許多通常保留給經理的流程：受邀參加跨工程的總監會議；至少在 I&P，我們參與路線圖規劃與管理層同步；最近也開始讓 Staff 工程師參與部分晉升校準會議。
• 這種存取層級給人一種「兩邊都踩一腳」的感覺。這角色和 Senior 層級差異夠大，不太算純「個人」貢獻程式的角色；但也和更以人為重的管理軌很不同。

在 Will 的 Staff 原型裡，我的角色大概介於解題者（Solver）與技術主管（Tech Lead）之間。對我而言部分樂趣正是每 6 到 12 個月跳進不同角色、和不同群人深入系統的不同部分。

日常怎麼分配時間#

依日子變化很大。目前我試著把週二、週四訂為會議日，好讓其餘時間有專屬的專注時段。

• 會議日：和密切共事者的 1:1、staff 會議，也和人配對做程式碼與設計審查，或較開放的設計討論。
• 專注日：進入調查模式，找出當前問題並為未來專案鋪基礎——哪些系統需要投資？團隊執行得如何？我們該為哪些即將到來的變化做準備？這是更廣義的「塑形」。

回頭看，這種聚焦和我 Staff 之前的角色不同：不是在個人層級直接做某專案或團隊，而是以更寬的鏡頭、更長的期限為中心。值得一提的是，我很難保證超過一天連續寫程式的時間；當我們考量工程路線圖頻寬時，我不被計入，不過我仍試著每週至少留一天寫點程式。

在微觀層級，我維護一份叫「what is stephen doing?」的文件，以小時為粒度驅動我的工作。主區塊是當週，另有些未來週的提醒。每週一我重新開始——上週沒開始的項目直接刪除，很少能存活到下週。這種「預設刪除」的意圖幫我保持聚焦、不至於太分散。我曾長期試著養一份「待辦後備清單」，但它主要的效果是讓我焦慮：多數後備項目一個月後反正會被刪、且未完成。

倡議變革：SLO 的故事#

是的。具體技術或方法論每季不同，但倡議終究佔我很大一部分時間。小的方面，我幫忙寫過文化文件——我們如何看待設計文件、程式碼審查、程式碼所有權規則等。

較大的例子，是我花了幾季幫產品團隊採納服務等級目標（SLO，Service Level Objectives）。

當時我們有相當成熟的功能與客戶群，但衡量正常運行時間的方式仍很原始。故障時很難掌握客戶影響，因為我們缺乏溝通用的區分與定義（「多少百分比客戶受影響？讀寫都是嗎？這是故障還是既有 bug？」），即使有大量指標與儀表板可看。

引入 SLO 當然需要新的工程工作，但我猜這專案我大部分時間花在寫文件、和人交談、以顧問式的方式和團隊合作。我們希望大家能端到端理解可靠性目標：如何定義、故障時如何談論、系統中如何衡量、隨時間如何追蹤、變不健康時如何反應。這種深度的東西，需要大量的傳達與反覆打磨才能滲透進去。

一如我們多數的大型「遷移」，讓多個團隊採納 SLO 是迭代來的：先在單一團隊試用新工具、給予高強度支援，再想清楚給組織其餘部分的廣泛傳達。我認為我的關鍵角色，是既能和工程師在「我到底怎麼用這個」的具體層級談新工具，也能說服總監級的人相信「用 SLO 語言溝通」值得他們投入。這個模式在我當 Staff 的多數專案都成立：我的角色終究是在各組之間斡旋、把一項變革推銷給整個組織。

少寫程式後如何掌握真實狀況#

我每週投入一些時間寫程式、做程式碼審查，即使只是提個小 bug fix。我試著參與其他 IC 每天經歷的同樣儀式——程式碼審查、翻文件、故障情境等。

當然這不足以在腦中維持高保真的模型——跨太多團隊發生太多事，追不完。其餘就是大量刻意尋求回饋、第一手聽別人的經驗。

我也試著把回饋迴路烘進組織。我幫忙讓我們開始做每半年的開發團隊調查，混合關於技術系統與工程文化的問題。這些調查的回應對「由下而上地感受組織氛圍」超級有幫助。

贊助其他工程師#

是的。我試著刻意「把我的狀態交出去」、退一步，讓別人建立起專業。

在組織層級，我認為有辦法結構性地贊助他人、把工程師推向主題專家的位置。例如去年底我引入一套新的分散式追蹤系統：我們核心 web 應用由多個後端系統驅動，多年來系統間的資料流變得更難理解、頁面效能受損，我們需要工具把自己挖出來。

我之前做過早期版本的效能工具，那些系統的知識大多卡在我腦中。新專案裡，我一個具體目標是讓更多人上手。光在系統設計中打好技術基礎不夠：專案裡的隊友未來好幾年得擁有那塊專業。實務上，這意味著我花更多時間和「即將成為追蹤系統擁有者」的人討論、配對，遠少於直接貢獻程式或設計。當我們和一個產品團隊做 beta 測試時，我會推另一位工程師去做銷售話術、想清楚 demo、或幫團隊 onboard。

如今這套追蹤系統被廣泛使用、完全由我們的 SRE 與可觀測性組管理。當時和我合作的人，現在是效能問題的首選對象。

在更個人的層級，總有些小地方我能把別人輕推到聚光燈下。贊助機會可以從小處開始——尤其和職涯較早期的人合作時，我可能建議他們承接新系統設計中更多未知的部分、寫份新文件的草稿、或在全組會議上 demo 我們的成果。

那個小小的推可能就是某人啟動所需的全部，但有時它也順勢流進指導與配對的機會。有些事（像第一次做投影片）在你做過幾次之前會覺得無從下手。在那裡，贊助與指導兩面都感覺很有影響力。要抓到對的位置也有些張力：我們想把人培養到能擁有更多、做系統決策的位置，同時又想在「這些決策怎麼做、我們要往哪去」上保持對齊。這是苦工——要做到不把關卻又得到令人滿意的結果，很花心神。

晉升到 Staff 的過程#

我加入公司時我們沒有 IC 頭銜。2019 年初我們引入分級時，我被定級為 Staff。

我認為「身為團隊早期工程師」給了我很大優勢。那段歷史在給我過去決策的脈絡上作用巨大——知道我們踩過哪些坑、幫新專案落在好位置。每個成長階段，我們都會加更多層的人與管理，就會有一段「重新學習」組織如何運作的時期，隨時間團隊範圍收窄、只看得到拼圖的一小塊。把大部分工程歷史裝在腦中，不僅幫我跨這些分界連起碎片，也讓我在「不再直接合作的組織部分」保有個人連結上搶得先機。這種廣度自然有助於看出什麼對組織最有影響。

走到 Staff 的關鍵因素#

我的背景較不傳統——我念電機工程而非資工，且沒念完就輟學。那個缺口逼我更多靠自學，也留給我很多冒牌者症候群。早期我因為沒有「對的資歷」而面試失敗很多次。那種冒牌者感讓我真的很想盡量多學，來掩蓋我害怕自己不懂的東西。

• Stripe 實習：輟學前那個夏天我在 Stripe 實習。或許戴著玫瑰色眼鏡回憶，我記得被那裡的工程文化激勵——對客戶體驗的高度專注、對打造技術達成目標的興奮。那經驗深深影響我希望職場帶給人什麼感受。
• 小新創的全職：離校後我在一家更小的新創全職，其實不太知道自己在幹嘛。那段時間業務有點漂移，但我幸運地和有心、喜歡指導的資深工程師密切共事。在那裡我對「想學什麼」有很大彈性，對我好、對公司大概不太好。
• 電腦營教學：高中時我在電腦營教了幾個暑假，教學齡兒童基本電腦素養。那種教學心態確實留給我更多同理，去理解人們如何理解並與電腦系統互動。

加入 Samsara 時，這些經驗給了我清楚的感覺——我希望工作是什麼感受；而身為早期員工，給了我塑造那條路的影響力。最後一塊拼圖是我在 Samsara 的頭三年，有幸和許多有心的合作者共事。我今天許多工作習慣、心智模型與言行舉止，都能輕易回溯到那些人。沒有他們的影響，我無法想像自己會在職涯的這個位置。

關於「Staff 專案」#

沒有，我沒有指定的 Staff 專案。回頭看，這些年有些專案或許累積成等同一個大 Staff 專案的東西，但那不是我們在定級時明講的。

作為一種概念，我對這種單一聚焦的專案抱持懷疑，擔心它會把人推進「英雄心態」——而我們真正想珍視的，是能「建造」組織、而非「扛起」組織的工程師。我會更興奮於看見隨時間的迭代改善與一致執行：一份有心工程的長期紀錄。我很高興 Samsara 似乎同意這評估，我們的職涯路徑文件談的更多是這種一致執行，而非單一長征型專案。

給剛上任者的建議#

• 習慣大量講話：Senior 到 Staff 一個大的階變，終究是對「人」的聚焦：調和相互競爭的優先級、釐清誤解、讓大家同一頁。即使通常沒有直屬部下，Staff 工程師是在技術與人「雙系統」中工作，最大的影響來自同時影響兩者。

為何走 IC 路線#

2016 年，我記得和經理初次談過 IC vs 管理路線。當時我覺得職涯還早，想繼續投資核心技術經驗。之後我每年左右重新評估一次，總得到同樣結論——我還沒做完技術面「弄髒手」的事。那段時間我做的許多工作圍繞著替公司的人打造開發體驗，這些努力把我推去做更像 Staff 的工作，我就自然從那裡進展。

學習來源#

我傾向珍視「用淺白語言談複雜主題」的作品，虛構與非虛構都是。

我記得讀到小說家村上春樹先寫他第一本小說的英文版、再翻回日文，作為形塑表達風格的方式。他說：「我只能用簡單、短的〔英文〕句子寫。這意味著，無論我腦中的想法多複雜、多繁多，我甚至無法照它們湧現的樣子寫下。語言必須簡單，我的想法得以易懂的方式表達。」寫軟體是完全不同的領域，但這份心情契合我很珍視的溝通信條：腦中有理解只是一半的戰役——能表達那份理解一樣困難、一樣有價值。

我愛讀真正深入某技術領域的部落格與論文。這些年我一再回訪的幾個：

• Bob Nystrom 談程式語言的文章
• Vyacheslav Egorov 談編譯器與 V8 內部（Chrome 的 JS 引擎）的部落格
• Brandur 談各種系統主題的部落格
• Nelson Elhage 的 Accidentally Quadratic
• Vicki Pfau 談開發 GameBoy Advance 模擬器的部落格
• fail0verflow 談主機架構與 exploit 的部落格與演講
• Bungie 談打造與製作初代 Halo 遊戲的工程出版品

最後，近兩年我最愛的一些非虛構讀物，是關於 BART 的歷史、Xerox PARC 的歷史、以及現代日本文化的概覽。在每個小眾裡，我都覺得歷史與脈絡引人入勝——看似微小、獨立的事件與決策，如何最終匯聚成今天世界運作的樣子。