本篇訪談錄於 2020 年 5 月。狄米崔·佩特拉什科（Dmitry Petrashko）是 Stripe 基礎設施主管的技術顧問（Technical Advisor）。
我的角色與團隊#
我是 Stripe 的 Staff Engineer，兼任基礎設施主管的技術顧問。我目前的「團隊」是整個 Stripe 基礎設施，負責 Stripe 的基礎設施服務——運算、網路、儲存、資料庫、資料工程、效能與效率、可觀測性服務、開發者工具。我們的工作讓 Stripe 工程師能專注於產品。
我「長出來」的團隊是開發者生產力（Developer Productivity），打造產品開發時用的流程、工具與核心函式庫，包括測試框架、linter、typechecker、build 工具、漸進 rollout 用的函式庫等。我從那個團隊（當時還是單一團隊）的工程師起步，最終成為那一組的 Pillar Tech Lead（PTL）。
Staff-plus 工程師在做什麼#
在 Stripe，Staff Engineer 不是一個「角色」，而是一個層級，對應到對影響力、溝通、人與專案領導技能的期望。Staff 工程師擔任不同角色，我目前的是技術顧問（TA）。
- 技術顧問（TA）：我與 Foundation 主管 Rahul Patil 緊密搭檔，目標是提前研究關鍵主題、深入關鍵議題（設計、程式碼、分析）、腦力激盪技術行動項、協助緊急技術追蹤、為蒐集資料而在程式碼埋點等。這個角色是為了擴充 Rahul 的頻寬與策略思考，但不直接做技術決策。
- Pillar Tech Lead（PTL）（通往 TA 的墊腳石）：隨著 PTL 變多，期望更清晰：
延伸：PTL 的職責定義
- PTL 幫團隊做出彼此協調、也和 Stripe 其他組技術決策協調的技術決策。Stripe 團隊多數技術決策自己做，但有經驗的 PTL 能幫忙微調以達更好結果。當團隊間就技術議題無法達成共識時，PTL 也扮演仲裁者。
- PTL 引導 Stripe 的技術方向，就「哪些是最重要該解決的問題」提供意見，並設定解決它們的高階技術路徑。
- PTL 代表其組織對其他 PTL 發聲，也把別處做的技術決策帶回自己合作的團隊，以創造對齊。
- PTL 為其他工程師創造承接有影響力專案的機會，並幫他們成功。
這兩個角色（PTL 與 TA）相似之處在於：都與工程經理搭檔、分享對使用者需求與可用工具的洞察，而工程經理更了解 Stripe 全域的非技術限制（例如人力限制）。
日常怎麼分配時間#
完美的一週，我會把週一、週三、週五放在會議或工作組（1:1 或團隊會議，協作短期與長期計畫與策略），週二和週四則獨自寫程式。現實中，依當時團隊需要，可能開更多會或寫更多程式。若我要啟動新專案，通常會先來一週少開會：專注在專案簡報、想通設計、交付物／里程碑、安全性／可靠性意涵；接著一週在公司內部推廣提案、處理回饋。
雖然有時很難擠出時間寫程式，但我認為這很重要——它讓我維持與工程的強連結，並成為 PTL 該扮演的、業務需求／優先級與工程限制之間的橋樑。
最有影響力的地方#
Staff 工程師，尤其是 PTL，常幫忙為新專案設定方向。當一份提案立意良善、也解決真實需求，但起草團隊缺乏經驗或脈絡去寫好計畫時，我能幫忙改進它，就特別有影響力：
- 有了結構良好的計畫，可以大幅縮小範圍卻取得大部分價值，從而更早展現影響。
- 或者，看出這份提案處理的用例比團隊原先預想的更多，把專案重新聚焦到團隊未知的用例上，會帶來更大的業務影響。
兩種情況下，我都是透過賦能其他工程師來感到有影響力。
拿到頭銜後才做得到的事#
沒有。Stripe 刻意讓 Staff 徽章不成為進入新機會的關卡，我相信我們做得不錯，PTL 角色也是如此。我們選擅長代表他人意見的工程師當 PTL。即使在我成為 PTL 之前，前一任 PTL Paul Tarjan 也總確保我的觀點被呈現。
倡議變革#
我被聘來的明確任務，是把型別檢查引入 Stripe 的 Ruby。這包括和 Nelson、Paul 一起設計並實作 typechecker Sorbet，並培養使用它的文化。
Sorbet 早期，我們依 Stripe 最需要的用例仔細選擇要加哪些功能。我相信我們成功涵蓋了 Stripe 對型別系統的多數用例，同時保持簡單。一個型別系統與文化很容易為複雜而複雜、變得精英主義；我很高興我們的努力避免了「從無型別擺盪到光譜另一端」。
如今在技術顧問角色，我倡議會帶來超額影響的變革，最常見於 Stripe 的可靠性、可擴展性、安全性與生產力——可能是改變資料分片／儲存的方式，或改變變更管理的方式。
最大的不同是：不像 Sorbet 我在專案待了好幾年，現在我會盡快找到／培養一個人來接手專案——在組織買單、有了帶清楚里程碑與受控風險的計畫之後。我會持續與推動這些重要專案的人頻繁 check-in，幫忙緩解風險、找出更快交付的機會，因此我的參與只在專案早期可見。
少寫程式後如何掌握真實狀況#
當 PTL 時，我每週至少有幾天寫程式，和團隊其他工程師緊密合作、持續互相學習。當技術顧問後，我寫程式的機會不如當 PTL 時多，大多在 code-yellow 情況才寫。但這個角色的成功取決於有好洞察與深厚工程理解。為此我和內部客戶交談，緊盯設計，尤其是我支援的團隊系統的失敗閾值與失敗模式。
- 全公司工程師調查：開發者生產力組辦的調查，用來找出最阻礙工程師生產力的東西——也許某個工具自上次調查後變慢、或某用例使用者成長卻支援不佳。這調查很少發現我們不知道的事，但是相對優先級排序的好工具：我們能比較多少人抱怨什麼、據此排優先級。
- 隨機併桌吃飯（Covid 封城前）：我會隨機加入 Stripe 的晚餐桌，問三個問題：你在做什麼？什麼讓它難？基礎設施團隊能怎麼幫？
延伸：隨機併桌與 DevProd Assembly
併桌成了很棒的工具，有兩個作用：1) 把我連結到使用者、幫我發現他們的需求；2) 幫緩解尚未被支援團隊的不滿——透過類似這樣的對話：「是的，我同意做 X 能幫你，那現在我們一起看看該停做什麼來騰出空間。」對方常會發現，雖然希望我們處理他們的痛點，卻不希望以「我們把現有專案降級」為代價。
在我逐步卸下 PTL 角色時，我建立了現在叫 DevProd Assembly 的組，聚集開發者生產力團隊的領導者。每位成員被期望和 2 到 3 個產品團隊建立高信任關係、每月訪談他們，並與 Assembly 其他成員彙整回饋。
贊助其他工程師#
雖然贊助其他工程師不是 Staff 工程師的必要條件，但我相信它有助於當一個成功的 Staff——透過為他人創造機會、幫他們成功，你能交付更多影響。是的，有多個專案我幫忙劃定範圍、啟動、降險，同時幫忙培養一個人在我轉去下件事時接手。
指導（mentorship）與贊助（sponsorship）有別，我兩者都做。指導是幫人成長、交付影響；贊助是幫一個人進到能展現「交付更大影響」能力的位置。和團隊工作時，我試著幫人做一些略出他們舒適圈的專案，這是我在贊助他們，然後我可以指導他們幫專案成功。
晉升到 Staff 的過程#
我不是以 Staff 工程師被聘進來的，我在 Stripe 被 uplevel 兩次才到 Staff。兩次 uplevel 都類似：Stripe 是在員工已經在下一個層級運作相當一段時間後才 uplevel，藉此調整「他們往後被期望持續在該層級運作」。
走到 Staff 的關鍵因素#
依重要性遞減排序：
- 聚焦於對業務與公司的影響。
- 具協作性：透過加入會議／工作組，你應該幫忙達成更好的結果。
- 技術知識。
對我個人而言，在拿到 Staff 前需要變好的是第二項。我已經在交付影響、也被視為技術諮詢的對象；我需要改善溝通與協作技能，才能有建設性地幫到我團隊以外、可能第一次見我、雖立意良善卻未必有最佳交付計畫的人。一個對我有幫助的技巧是：會後立刻在私訊裡徵求回饋，尤其在不太順利的會議後。 這讓我學到我做了什麼可能讓別人在會中不自在，有幾次，真誠地問「怎樣能更好」甚至補救了一場已經開砸的會議。
公司、教育與地點的影響#
- 公司：我很感激 Stripe 有這麼多創造影響的機會，這確實幫了我。
- 教育：我剛好拿了一個非常實用的博士（研究如何打造快速且可維護的編譯器），幾乎完全轉化為適用於我工作的知識：幫公司規模化工程。雖然它幫了我很多，但我認為運氣成分很大——我剛好在對的時間加入對的實驗室（Scala3 誕生條件成熟時，我在實驗室待得夠久不太「菜」，卻又夠早、還沒完全定下我研究的方向）。我不確定會不會建議別人念博士：務實地說，我許多朋友用完成博士所需的同樣四年多，在 Stripe／Google／Facebook 打造系統，學到的也一樣多。話雖如此，博士對我是換地點的好工具。
- 地點：我從瑞士來美國加入 Stripe，從俄羅斯來瑞士加入最好的資工博士班之一，從烏克蘭去俄羅斯就讀前蘇聯最好的大學之一。每次搬遷我都在玩「地理套利」：我尋求逃離「我是最頂尖之一」的地方，到「我會是平均水準」的地方。有些地方我不是首選候選人，藉由加入那裡的人、向他們學習，我成長很多。我很難說美國 vs 歐洲哪個對職涯更好，但從經驗我肯定：換地點幫我成長很多。
關於「Staff 專案」#
事後回答這題對我很難。就我所知，Sorbet 夠大到能當我的 Staff 工程師專案，但因為有 Nelson 和 Paul，我們彼此緊密又快速地合作，很難把專案的成功歸給特定個人而非整個團隊。
延伸：Sorbet 團隊如何自然分工出所有權
專案進行到第一次績效評估時，我們三人都收到回饋：該有更好的方式來界定哪個影響是哪個人的成果。我很想說下次績效評估沒遇到同樣問題是刻意作為的結果，但我認為不是：專案只是自然進入一個大很多的階段，我們不再需要「在同樣 10 個檔案裡快速迭代」，自然導致我們有了更清楚、更大的所有權領域。
我成了「內部架構／子型別」的人，也是「和使用者談」的人；Paul 成了「改程式碼讓 typechecker 喜歡」的人；Nelson 顯然更懂 Stripe 其他系統怎麼運作，因此幫忙把工具和它們整合。這些都發揮我們的強項：我有 typechecker 的先前經驗（我博士就做這個），Paul 對程式化 codemod 極有本事，Nelson 對系統整體很懂、且在 Stripe 待得夠久夠早、幾乎懂每個系統。到專案這階段（穩定化、rollout），這些都成了巨大領域，因此更容易讓一個人當某領域的 DRI（直接負責人），其他人偶爾協助。
Sorbet 之後，我還在短時間（六個月）內交付了幾個有影響力的專案，我相信這封住了我拿到 Staff 層級的關鍵。但若要選一個，我仍會選 Sorbet，因為它範圍龐大——技術與文化兼具。
對我有幫助的建議#
- 在學界和 Martin Odersky 與 Ondrej Lhotak 共事，幫我理解複雜系統如何協同運作、以及如何把它講清楚。
- Brian Goetz 幫我理解，一個簡單卻堅固、能承受廣泛採用與設計的系統背後有多少工作。
- Paul Tarjan 讓我看見調整溝通風格、以帶來對所有相關方都有建設性結果的重要。
給剛上任者的建議#
至少在 Stripe，Staff 工程師做非常不同的領域。務必和你的匯報鏈就「你該達成的影響是什麼、以及達成路上你被允許妥協哪些事」達成共識。清楚溝通你在做哪些妥協、以及為什麼。
為何走 IC 路線#
過去每次考慮管理，我都問自己與周圍的人：「這會是帶來更多影響的方式嗎？」到目前為止，每次答案都是「似乎不會」。話雖如此，我發現向很棒的管理者學一些管理技能（我的情況是 James Iry、Scott MacVicar、Will Larson、Christian Anderson、Shane O’Sullivan），即使在個人貢獻者角色也有巨大好處。