本篇訪談錄於 2020 年 4 月。奈爾森·艾爾哈吉（Nelson Elhage）曾任 Stripe 的 Staff Engineer。

我的角色與團隊#

我最近待的公司是 Stripe，做線上金流處理，是一家成長很快的新創，約兩千人，工程約六百人。我離開時技術上其實沒有職稱——如果再待兩個月，我就會是 Staff Engineer，因為他們在多年內部辯論後終於推出了職級制度。

我最後所在的團隊叫「金流架構」（Payment Architecture），由三到四位相當資深的工程師組成。金流是 Stripe 產品的核心，我們負責照看金流的程式碼庫，特別聚焦在財務基礎設施層，打造能支撐 Stripe 現有與未來所有產品線所需的資料模型與抽象。

• 我們研究程式碼結構如何對應到組織結構，包括在一個持續增加團隊、產品、國家與支付方式的快速成長組織中，該如何組織程式碼。
• 架構必須能支撐把「所有權」分散到多個辦公室與時區，這點特別重要。
• 我們推動許多程式碼品質與架構的行動：訂出指標與目標、讓各團隊認領這些目標，再給他們工具協助遷移到新標準。

金流架構團隊介於常設團隊與專案團隊之間。它的職掌不算狹窄戰術型，但也不太可能永遠存在。我們用實驗性的方式演進架構，邊做邊修正做法，希望這個團隊最終能「把自己做到不再需要存在」。

Staff-plus 工程師在做什麼#

Stripe 當時才剛引入職稱，很難很有把握地說。誰是 Staff Engineer 並不公開，但你會從「誰在做最重要、最有影響力的事」大致感覺得出誰是資深工程師。

有幾種清楚的 Staff Engineer 原型：

• 深度技術專案：規劃或打造新的基礎設施。在金流架構團隊之前，我做的是 Sorbet——我們的 Ruby 靜態型別檢查器。我和另外兩位資深工程師花了約一年從零打造，是「高槓桿深度技術工作」原型的好例子。
• 跨領域專案的統籌者：身兼架構師與專案經理，把組織的不同部分拉在一起解決一個大問題。這類問題通常和當前架構或組織不對齊，需要跨許多團隊協作。
• 團隊願景的守護者：與一個或一小群團隊合作，釐清團隊要打造什麼、一到五年後想到達哪裡，然後跨組織建立並傳播這個願景，再著手實現。

日常怎麼分配時間#

金流架構和 Sorbet 兩個角色差很多。Sorbet 比較是「埋頭寫程式」的專案；金流架構仍有一定的寫程式量，因為我們有一套想試驗、也想用來展示理念的具體做法。

• 專案管理：維護任務追蹤、主持每日站會、找出誰需要幫忙或被卡住。
• 溝通黏著劑：橫跨公司與工程組織，尤其和對我們工具與模式感興趣的團隊交流、給建議。
• 技術策略與設計文件：開會釐清技術策略，也花不少時間寫設計文件，指出我們看到的問題並推廣我們認為能解決問題的架構樣貌。
• 對上推銷：向領導層與其他團隊解釋並「銷售」這些想法，藉此設定議程、爭取投資與優先級。

最有影響力的地方#

最容易追溯影響力的絕對是 Sorbet：兩年內，一個三人團隊把 Stripe 從動態型別的程式碼庫，帶到大幅靜態型別化。這影響了全公司六百位工程師每天在編輯器與開發環境中的體驗。

話雖如此，很難斷定那是不是真的最有影響力的專案。也有一種比較模糊的論點是，架構策略的工作長期而言影響更大。

開啟 Sorbet 與金流架構這類團隊，靠的不是官方政策授權，而是高度的組織尊重與信任——你要有足夠份量，才能說服組織把資深工程師從具體專案上抽離一整年去做這些野心勃勃的事。

倡議與優先級#

倡議技術、實務、流程或架構變革，某種程度上隨規劃季節而起伏。優先級最終意味著人力配置，而人力決策發生在規劃期。

規劃季是特別急迫的時期，但我幾乎持續在思考工程層級的優先級——可能是注意到很多工程師遇到的某個問題，或看到某件事拖慢了團隊。這是一條不斷重現的思緒，會週期性地變成急迫的優先事項，那時我就會花時間去倡議成立某個團隊、或去處理某個問題。

贊助其他工程師#

老實說我沒有特別用「贊助」（sponsoring）這個框架去思考，也想不出清楚的例子。一個相近的做法是幫忙引導我不屬於的團隊起步——例如某個團隊成立來接手原本佔用我部分心力的系統，我會以密切的顧問角色和他們合作，提供脈絡與建議。

讓我走到 Staff 的關鍵因素#

我的路徑非常依賴「很早就加入 Stripe」——我大約是第 30 號員工。但我做的、和別人不太一樣的事，是刻意建立橫跨 Stripe 的極廣脈絡與覺察。在只有 15 個工程師時這相對容易，那時能出錯的東西沒那麼多。

• 隨著公司成長，我花很多力氣持續掌握工程組織裡發生的每件事：團隊間的互動、擴展的痛點。我試著保有一種不尋常的全局視角。
• 這讓我知道哪些問題重要、尤其是「隔一層」的重要問題。如果組織的目標是推出某個產品，我有視角看出「它之所以難，是因為某些過去的架構決策，或某個下游系統還撐不起來」。
• 組織變得很大之後，看見這些隔一層的依賴愈來愈難；保持宏觀與系統層級的視角有幫助。它也讓我能把團隊串起來，讓我成為資訊與想法的「路由器」，同時也是提案的發起者。

很多團隊困在自己那一小塊世界，對內部客戶如何整合他們的系統理解不深——因為他們從沒待過自己所支援的內部客戶團隊。我幫團隊帶來「其他團隊實際上怎麼用他們系統」的脈絡，並把他們連結到該去收集觀點的人。

隨組織成長要維持這些脈絡本就很難，但對一個「當公司還小時沒開始累積全局脈絡」的人來說更難。早期加入，你相對於「後來才想逆向工程出架構與組織依賴」的人，有巨大的競爭優勢。

脈絡也可能是包袱#

當我和凱維·麥克明（Keavy McMinn）聊時，她提到一個有趣的點：有時候「看不到完整歷史脈絡」反而有幫助。這點我完全同意。

我會注意到自己走進與某團隊的對話時，準備好要給他們「過去七年每次有人嘗試這件事、又為何失敗」的完整歷史。我得刻意複盤這段歷史，問自己：「這對他們到底有沒有幫助或相關？」

有時候這些資訊沒用。但另一方面，如果有人曾嘗試撞得頭破血流，可能代表某個很難的技術問題還在——指出暗礁有其價值。不過，「有膽再試一次」也很有價值，因為多年過去，我們已經是不一樣的組織了。

關於「Staff 專案」#

我本能地對「Staff 專案」這個概念有點保留，部分原因是我看過的一種 Staff Engineer 原型，是那些不見得自己主導宏大專案、卻是極其有效的「大師與路由器」，讓整個工程組織運轉得更好的人。

我最接近 Staff 專案的東西，大概是我因為「資料模型 Stripe 發布計畫」（Data Model Stripe Release Plan）拿到最後一次晉升。我主導了這個為期六個月的計畫，協調一群團隊處理資料模型的弱點，並以「具轉型性」為願景推進資料模型。

某些方面它其實不是好的 Staff 專案範例：我們做了好工作，但因為多重原因，成果遠不如任何人期望的那麼有轉型性——有些在我掌控內，有些則是問題本身太難、組織根本沒有資源在六個月內解決。這個專案不見得比我其他半年做的工作更好，但它是一個非常顯眼、高曝光的角色，在重要的方面創造了能見度、提升了我在公司的份量。

一個對我很有幫助的建議#

我學到的一課是聚焦與優先級的重要，尤其當你擁有前面說的那種廣泛組織脈絡時。任何時刻你都很容易列出三十件你想做的事。

• 偶爾你可以把這三十件事各推進一點點。這在一段時間內有生產力，但要小心。
• 如果這些是沒人在做、而你認為該做的事，一次挑一件、真正集中火力，會比同時在許多專案上各推一點，運氣好得多。
• 一個重要區分是：這三十件事是否已經有團隊在做。如果已經有團隊在做、只是方向你覺得無效，那麼去幫這些團隊解除阻塞，能取得很大的槓桿。

到頭來你得說：「這些我都希望能做，但我不會全做。今年我挑一兩件，其餘的即使我認為是重大問題，也要刻意先擱著一陣子。」

給剛上任 Staff 工程師的建議#

• 康威定律（Conway’s Law）至上：我極度相信康威定律在引導組織技術架構上的首要地位。
• 投資和工程領導層的關係：經理、總監、副總。在 Stripe，這些人常握有很多隱性權力，因為他們是大家有問題時的第一個對象，也對人力與優先級有很大影響力。和他們有好關係，你才能用想法影響他們，也才能理解他們看到的問題、他們的誘因、以及他們感知到而你沒感知到的問題。與領導層對齊會讓很多事簡單很多。
• 估算能力：我很重視養成「看到一個系統就估算它每秒幾 GB、這份資料要多少儲存」的習慣。不必精準，抓到最接近的十的次方通常就夠用了。

為何走 IC 而非管理路線#

我考慮過，但不太認真。我對自己有相當的理解：至少現在，我不會真的享受那份工作，那麼多互動不是我能持續投入的方式。我偶爾希望自己對它更有興趣，因為我確實把管理視為取得大量權力的途徑；但幸好我有足夠的自我覺察相信——而且我認為是正確的——我不會享受它，因此也不會做得好。

學習來源#

我常被問這題，因為我的通識廣度不太尋常，但我沒有好答案說它從哪來。我對計算、軟體與架構有近乎貪婪的好奇心，讀各種東西，也花在軟體工程 Twitter 上讀連結的時間可能超過健康的程度。

培養一個資深工程師的私人人脈網對我極有價值。當你有私人連結，能得到別人對他們所見問題與所考慮方案的、非常不加修飾的看法。我大多是透過朋友的朋友、甚至一路回溯到學生時代的人脈自然長出來的，不是事後刻意去找的。

技術論文我偶爾讀，但不主動——多半是別人引用或在其他脈絡冒出來時。我不會系統性追蹤或審視近期出版品。不過，對所謂「基礎文獻」有一定掌握，確實很好用。