本篇訪談錄於 2020 年 3 月。喬伊·埃伯茨（Joy Ebertz）是 Split.io 的 Senior Staff Software Engineer。

我的角色與團隊#

我是 Split.io 的 Senior Staff Software Engineer，在我們稱為 COE 的團隊做後端。Split 是功能旗標（feature flagging）與實驗框架，我們讓客戶在 CI/CD 中把「部署」與「發布」分開，並支援 A/B 測試。我的團隊負責 web 應用大部分的主要商業邏輯，從資料儲存到 API 都包含在內；另有獨立團隊專注於實驗那一側（包括其中細緻的統計），所以我們能更專注在主平台。

日常怎麼分配時間#

我還算新人，仍在定義自己的角色——這也是資深角色迷人之處。目前我還在 ramp up，大約一半到四分之三的時間，像這裡任何工程師一樣做我所屬 scrum 團隊的任務。其餘時間，我參與對話、和其他工程師一起定義較長期的架構與策略：

• 未來的 API 與平台策略、授權框架的發展方向、拆分並解耦我們的 build 等。
• 我最近接下後端 chapter 的領導，和另一位工程師共同帶領，一起彙整後端技術願景、排定技術專案優先級、主導標準討論。
• 我也持續在部落格定期寫作、在研討會演講。

最有影響力的地方#

當我能促成為某個領域設定技術願景、並讓大家朝那個願景前進時，我感覺最有影響力。

• 我們都同意希望程式碼架構更好、有所改善。但我發現大家常只有「想要更好」的模糊感受，卻沒有清晰的目標圖像。
• 我喜歡幫大家對「究竟要到哪裡」達成共識（就算永遠到不了也沒關係），並想出大致的行動計畫，這樣大家才朝同方向前進。
• 有了清晰的目標，我們能和產品協作把它排進優先級。即使整件事永遠排不進來，知道怎麼到那裡，讓我們能慢慢做出朝那方向靠近的改動。

例如，如果我本來就在動某個檔案，能順手做幾個讓我更接近願景的微調，我就會做。沒有那個願景，這些微調永遠不會發生。但光有願景不夠，我們需要每個人理解並內化它——當每個人都把這些小改動當成日常寫程式的一部分，突然之間大家就都在朝共同目標努力。

主人翁意識#

現在和我更資淺時最大的差別，是我的主人翁與責任感。我一向願意反駁、推動改善；但更資淺時，我常直接假設某件事是別人的問題。

現在，全都是我的問題。我可能選擇不優先處理某事，因為我認為它沒別的重要；也可能選擇委派或轉交給別人——但我仍視它為我的問題。我不再假設別人會處理某件事。我仍非常相信「挑選你的戰役」，我不會什麼都做，那太多了；但我也不會假設別人會做，所以只要值得做，就得靠我去做、或轉交給別人。

倡議變革#

是的，以上全部。在現在的角色，倡議是我工作很大一部分。身為工程師我也在 scrum 團隊貢獻，但我工作有很大一部分是留意我以前見過的陷阱、或更大的問題模式。我把工作看成讓整個工程更有效率——透過技術、架構或流程——但絕不該為改變而改變。多年來我倡議過很多事，從重寫 email 通知系統、重新思考測試，到重做好幾套授權框架。

贊助其他工程師#

是的。一旦你到了任何較資深的角色，只要你願意善用它，這就一直是你角色的一部分。

• 有時贊助是大事——推薦人去領導專案或帶團隊。
• 但很多贊助是小事——鼓勵一個對自己有點沒把握的人、把他們的成就展示給平常接觸不到的更資深者、找方法把你的工作委派給能從中獲得成長機會的人。

我認為當一個「不贊助的 Senior Staff 工程師」是可能的，但我不確定能不能當一個「很棒的」Senior Staff 工程師卻不贊助。贊助是我們成長身邊人最有力的方式之一，而成長他人是我們角色最重要的面向之一。

晉升到 Staff 的過程#

我第一個 Staff 頭銜是在 Box 拿到的。

走到 Staff 的關鍵因素#

地點對我大概沒太大影響。學歷在我較資淺時對拿到面試幫助很大，但之後（至少直接地）就少多了。對我而言最大的三個因素是：公司、能見度、機會。

• 公司：我發現待在快速成長的新創真的幫了我。我加入 Box 時工程約 30 人，八年後離開時是數百人，而大部分成長在前半段。這讓我進入一個較小的工程環境，能真正認識環境、人與程式碼；接著因為在成長，對有動力、願意承接的人來說有很多領導機會與技術挑戰。機會隨我一起成長，同時身邊也有夠多人可以學習（我之前在一個只有 2 到 4 人的迷你新創，那裡真的沒有這種條件）。
• 能見度：就是找到某種方式讓自己被知道。如果你做了很棒的工作卻沒人知道，到了晉升時就會被跳過。而且愈資深，你工作的一部分就變成指導與教導他人、幫公司建立技術品牌——這些依定義都是可見的。對我而言，我在 Slack 討論區很活躍、盡量回答問題；大量寫部落格、在內外部演講；也活躍於公司的科技女性社群，讓我和工程各處的人建立連結。
• 機會：對我特別有幫助的一個，是加入 API 標準委員會。一開始我有點猶豫，因為不覺得自己是 API 專家，但讀了幾本（短的）REST 書、加上先前做過的各種 API 工作，我掌握得相當扎實。這個群組的強大之處在於它橫跨工程許多團隊，讓我有機會和很多不同工程師共事（也帶來前面說的能見度），並讓我有清楚可指的東西來證明我在影響他人、是個為品質而戰的人。

關於「Staff 專案」#

我其實沒有真正的 Staff 專案。晉升時，我約六個月前才從管理轉回 IC，所以向領導層引用了一些我管理時期的表現。當時我（從技術面）帶領 Box 一個很小的團隊做跨公司協作專案，需要理解另一家公司開發團隊的需求，並想辦法在滿足需求下盡量少造。我也是工程全域 API 工作小組的成員，負責建立與維護 API 標準，同時還有幾個 side project。這些都對晉升的不同部分有貢獻，合起來幫我證明我能展現他們期望的所有面向。

對我有幫助的建議#

例如，我是超級內向的人，不特別喜歡和陌生人交際，我極不擅長與陌生人建立人脈。但我擅長寫作、也樂在其中。我用公開部落格的寫作認識了本來不會遇見的人、獲得更廣的曝光——我確信這比去參加許許多多聚會收穫更多。

另一個較戰術的重點，直接關係到 Box 寫晉升案的流程：

• 在你確定準備好晉升之前，就先把晉升案寫好：這讓你看見哪裡可能有缺口，給你很具體可著手的東西（或者你會驚喜地發現自己比想的更早準備好了）。
• 非常清楚缺口在哪：委員會讀晉升案時，所有案子都會很正面，沒人晉升時說自己壞話。所以委員會不是在找負面的東西，而是在找「沒被說的」——空白在哪？什麼被迴避或帶過？從這角度看你的案子，補上那些。
• 講你的故事：晉升案有帶引導問題的模板，但尤其在較高層級，每個人都不一樣、也不該一樣。別只回答問題，先想你的長處是什麼、你的超能力是什麼、你的故事是什麼，再想辦法把故事塞進提示裡。把最好的長處放進去，整體案子會強得多。

如果我沒繞道去做管理，也許會更早到 Staff。話雖如此，我不後悔——我學到很多關於人怎麼思考、組織怎麼運作、大專案怎麼排優先級的東西，這些持續幫助我在 IC 軌道上工作，也很可能助我進一步升到 Senior Staff。它可能拖慢了我到 Staff 的時間，但對下一級我反而不確定——我認為很有可能，沒有這段經歷我會在 Staff 待更久。

給剛上任者的建議#

你愈資深，工作就愈不是關於程式碼。當然，不像人事經理，你仍有很技術的傾向，即使到 principal 你也很可能還是會寫一些程式。但你爬得愈高，工作就愈變成指導與成長身邊（與更廣）的人、透過建立公司公開技術品牌來壯大團隊、注意可改進或修正的較大技術趨勢、幫團隊或公司設定技術願景、為技術債專案爭取資源。它變得更多是看見更廣的事、並讓別人上船。突然之間，溝通、領導與說服比以前更重要。

為何走 Staff 路線#

我在 Box 期間中段管理了約一年半，發現我討厭它（我部落格有專文談這個）。話雖如此，我發現在多數公司，管理和 Staff+ 角色其實有很多重疊：兩者都需要指導他人、領導、說服人的能力，都需要想得更大、更關注長期——技術與人皆然。我不打算重回管理，但管理期間我學到很多，這段經驗實際上在我晉升到 Staff 及以上時幫了我。

學習來源#

我不太追隨特定某個人，而是從身邊幾乎每個人身上學習與獲得靈感。我列幾個，但老實說我從無數不同層級的人（包括許多比我資淺的人）身上學到東西。

• 一位經理：每次我帶著問題去找他，他總是反問我：「你覺得你該怎麼做？」到後來，我不必真的找他，就能聽見他叫我直接給某人回饋、或叫我自己想辦法修好某事。他真正教會我：身為經理他願意支持我，但如果我能靠自己做到，我會學得最多、成為最好的自己。他教我為每件事承擔責任。
• 一位 principal 工程師（對照點）：後來教我不需要試著什麼都自己做。學會承擔責任後，我開始忘了我並不孤單。當然我聽過大家談委派，但聽說、或用 sprint 任務去想是一回事；委派「把某事排進優先級」、委派「替團隊想出技術願景」、委派「追蹤某項行動」，是另一回事。
• 一位風格衝突的同事：她解決問題的方式和我太不同，有時把我逼瘋——我覺得顯而易見時她要求釐清，我以為大家都同一頁時她要求詳細解釋。但她也是我共事過最聰明的工程師之一。和她合作讓我體會到：不同風格不僅能一樣好，有時把兩種相衝的風格湊在一起，會得出比我們各自都更好的結果。她能在我以為顯而易見的東西裡找到漏洞——她有時把我逼瘋，但我們一起完成了一些了不起的事，我也因此變得更好。