本篇訪談錄於 2020 年 4 月。黛安娜·波亞（Diana Pojar）是 Slack 的 Staff Data Engineer。

我的角色與團隊#

我是 Slack 的 Staff Data Engineer，也是資料平台（Data Platform）團隊的技術主管。我在 2016 年 2 月加入 Slack，是資料工程團隊最早的工程師之一，深度參與打造許多讓資料能長期分析的工具與基礎設施。我剛加入時，團隊才剛決定用 Thrift 當日誌格式；當時任何人想取得洞察，都得在生產環境 MySQL 資料庫的唯讀副本上排 cronjob。

• 資料工程團隊的目的：讓公司任何人（資料科學、工程師、產品經理等）都能存取資料，用來計算洞察、驅動商業決策或打造新功能。
• 資料平台團隊的重點：打造可規模化運作的服務與框架，賦能所有需要處理或使用資料倉儲的人。
• 我們擁有的東西：暴露任務／表／欄位血緣與一般 metadata 的 Data Discovery 服務、事件日誌結構，以及消費事件並在資料倉儲中以原始表暴露它們的管線。

Staff-plus 工程師在做什麼#

Staff-plus 工程師的角色，很看團隊需要什麼、也看該工程師的強項在哪。他們的職責會隨時間改變，但主要焦點通常是：投入對公司有策略價值的專案，同時推動技術設計、拉高團隊水準。我看過的 Staff-plus 工程師大致落在兩類：

• 偏深度（專才）：通常是特定領域的專家，多數時間花在寫程式或寫技術設計文件，為專長領域裡極難的問題找解方。例如 Slack 有位 principal engineer，主要熱情就在偵測與修復效能問題。
• 偏廣度（通才）：通常和領導團隊更緊密合作，影響組織或全公司的技術願景，改善流程與文化。因為廣度，他們更有彈性，能依公司優先級在工程組織的不同領域工作。

就我個人而言，目前我更享受也更偏廣度。今年到目前為止，大約 50% 時間花在技術領導、和大家討論我們該聚焦哪些較大的技術投資；另外 50% 花在指導、審查程式碼、寫程式、跳進 incident 修關鍵問題等。這個比例每季都會變。

最有影響力的地方#

我個人感受最明顯的，是那些在我晉升／改頭銜前沒和我共事過的人，對我的信任與尊重顯著增加。

擁有頭銜，和一個人影響組織／公司路線圖與優先級的能力強烈相關——基本上你得以進到「事情發生的那個房間」。

我能參與打造對公司成敗有直接影響的東西，倡議並參與這類專案，是早期角色做不到的。我也能拉抬更資淺的人、讓他們的聲音被聽見。Staff+ 頭銜帶來別人沒有的特權，我試著用它來幫團隊與同儕升級。

倡議技術與文化變革#

我相當多的時間其實花在倡議技術方案、流程、架構或文化變革——不只是寫程式。我持續參與許多團隊的技術設計審查，尤其那些要打造依賴資料工程工具與服務的系統的團隊。

有一個我很珍惜、也自認在組織裡發揮了顯著作用的領域，是 Incident 管理與分析。我和公司的韌性（resilience）團隊合作改善 Incident 分析流程；在我的資料工程組織內，我大力推動 on-call 的期望與結構，同時採納公司的 Incident Response 架構。

贊助其他工程師#

贊助（sponsoring）對我其實是重要的一環，我專注於和許多共事者建立很棒的關係，也強烈相信我們需要互相拉抬。在我走向 Staff、對抗自己冒牌者症候群的旅程中，我有幸與很棒的人共事，他們贊助我、對我的成長影響巨大——約書亞·威爾斯（Josh Wills）、史丹·巴布林（Stan Babourine）、波格丹·加薩（Bogdan Gaza）、崔維斯·克勞福（Travis Crawford）是長期以來我的導師與榜樣。指導與幫身邊的人成長一直對我很重要，而 Staff+ 角色有別人沒有的特權與權力，我盡力用它去幫助並升級身邊的人。

晉升到 Staff 的過程#

我以中階工程師身分加入 Slack，一年後升 Senior。當 Senior 時，我有機會做多個具組織／全公司影響的專案，很多直接關係到公司商業指標怎麼計算，這對公司準備上市至關重要。

在 Senior 待了兩年後，我的經理告訴我，我已經在下一個層級運作，他相信有很強的理由，計畫替我提報晉升。

走到 Staff 的關鍵因素#

回頭看我還是資淺工程師時的感受與想法，走到 Staff 最主要的因素其實是：真心相信「你做得到」，別讓冒牌者症候群獲勝。

• 刻意的職涯選擇：我一向試著對職涯選擇很有意識，每年都花點時間思考自己在做什麼、想聚焦哪些成長領域。這讓我退一步評估現況、問自己是否還在成長、思考新機會。
• 加入從零起步的團隊：2015 年底我決定離開 Twitter 時，發現 Slack 正要組建資料工程團隊。能從零打造與設計系統、服務與框架讓我非常興奮，這個獨特機會確實促成我走到 Staff。例如我做的第一個大專案，把生產 MySQL 約 25% 的負載移到資料倉儲，替公司省下數百萬美元。
• 身邊的人：我很幸運團隊裡有很棒的榜樣與導師。我加入時是一個非常資深團隊（其他人都是 Senior Staff）的第 4 人，這激起我證明自己屬於這裡的渴望。在每個專案累積指導、能見度與技術品質的紀錄，也助我走向 Staff——我不把工作只當工作，而是對每個專案與問題投入很多熱情。

關於「Staff 專案」#

沒有，我沒有被指派的「Staff 專案」，那也不是 Slack 晉升流程的一部分。Slack 有職涯階梯描述每個層級的期望與影響範圍，到 Staff+ 層級，範圍開始從「組織級影響」擴展到「全公司級影響」。

我一向試著挑戰自己、尋找在組織裡驅動改變與影響的機會。我認為最有影響、也最助我走向 Staff 的專案，是參與思考並實作「公司商業指標（例如 ARR）如何計算」的技術設計，確保這個流程可靠、可規模化，最重要的是可重現。這在 Slack 完成上市準備時是關鍵行動。

對我有幫助的建議#

讓你走到 Senior 的那套，不會讓你走到 Staff+。要理解：Staff+ 工程師的工作與責任遠不只寫程式。理解這個角色在你公司、也在整個產業的期望很重要，因為公司之間存在差異。

• 和你的經理或更資深的同儕合作，找出能挑戰你、擴大你工作範圍的專案。
• 對我極有幫助的是，我開始更投資於發展自己的領導與溝通技巧。
• 我也開始用不同方式框架某些事：當我開始感到壓力或對自己能力沒把握，那往往是我在成長、踏進一個充滿成長機會領域的訊號。

給剛上任者的建議#

• 走到 Staff 帶來很多責任，你應該永遠當同儕的強力倡議者。
• 身為 IC，執行與親手做通常是「容易」的事；真正難的，是在組織裡驅動改變與影響。
• 在 Staff 任期的不同時刻，你可能會發現自己聚焦在不同事情上，這沒關係、也是預期中的。Staff Engineer 該做什麼，沒有單一乾淨的定義。

為何走 IC 而非管理路線#

這其實是我每隔幾年就問自己的問題。每次自省，目前的答案都是「不」——我不想當經理。我太愛寫程式了，也強烈相信要當成功的經理，你不該寫程式，而該全心成長你的團隊。即使愈資深、寫程式的時間會愈少，我仍太喜歡參與技術決策與思考技術方案，不願放棄這份親手做的經驗。

不當工程經理，不代表你不能影響與幫助別人成長。身為 Staff+ 工程師，即使你不是經理，你仍需要許多核心管理技能，我發現讀管理書籍極有幫助。我甚至認為這兩個角色雖在各自平行的軌道上，卻比大家想的更靠近。

未來某個時點，這個問題的答案可能會改變，那也沒關係。

學習來源#

我大量使用 Twitter，但主要是消費者，追蹤許多科技圈的人——通常是我在研討會看過、或共事過、內容和我相關的人。不分先後包括：Camille Fournier、Lara Hogan、Josh Wills、Vicki Boykis、David Gasca、Julia Grace、Holden Karau、John Allspaw、Charity Majors、Theo Schlossnagle、Jessica Joy Kerr、Sarah Catanzaro、Orange Book。

我也愛讀書（每年約讀 50 本），從去年起會替讀過的每本書在 Goodreads 留下小小書評。幾本我覺得有用的：

• Thanks for the Feedback
• Radical Candor
• The Manager’s Path: A Guide for Tech Leaders Navigating Growth and Change
• Leadership and Self-Deception: Getting Out of the Box
• The Coaching Habit: Say Less, Ask More & Change the Way You Lead Forever
• First, Break All the Rules: What the World’s Greatest Managers Do Differently
• The Courage To Be Disliked
• Give and Take: A Revolutionary Approach to Success
• Mistakes Were Made (But Not by Me)

這不是完整清單！