本訪談錄製於 2020 年 7 月。Ras Kasa Williams 是 Mailchimp 的 Staff Engineer，任職於資料服務（Data Services）工程小組。

目前的角色#

我是 Mailchimp 的 Staff Engineer，屬於資料服務工程小組——公司內資料工程的所在。我們建置的系統主要支援資料科學與分析團隊（產品、財務、行銷分析師等）。

我一直擔任這個小組的技術主管（tech lead）之一，專注於建置可擴展的資料處理管線，驅動我們內部的分析平台。我也承擔了團隊相當大一部分的工程經理（Eng Manager）職責（雖然我形式上不是工程經理）。做了將近兩年後，我正把這個角色移交給另一位工程師。

「正常」的 Staff-plus 工程師#

在 Mailchimp，一旦成為 Staff Engineer，你就是「工程領導層（Engineering Leadership）」的一員。由於正式的工程階梯是幾年前才實施，「當 Staff Engineer 是什麼意思」的答案可能因人而異。

在我看來，這是關於全域思考（thinking globally），並把它應用到在地：

• 全域：與同一群人協作，理解公司層級的商業／產品策略，並蒸餾成一套工程層級的技術策略，好讓產品、行銷等各功能得以執行；協作改善招募、上手、跨團隊溝通、生產維運等流程；協作成長整個部門的技術與社交技能。
• 在地：把團隊的技術路線圖對齊到工程層級的技術策略，並刻意判斷何時該偏離以服務直接利害關係人；把公司策略脈絡轉譯成對團隊眼前專案的影響；刻意為團隊的 IC 創造成長、能見度與接觸他人的機會。

當然我不是每次都做對。但這對我來說一直是成功的運作模式。

日常怎麼分配時間#

身為技術主管，我負責定義並為團隊技術策略的執行負責。我讓這套策略錨定在它對內部客戶（也就是業務）的價值上，並在需要時有效地跨公司溝通。一年幾次，我會回顧進展、看業務是否有變化需要調整策略。

我仍規律地貢獻程式碼——當然比團隊其他工程師少；但維持「手放鍵盤上」很重要，好讓我的技術策略與其他宏觀決策，能被團隊第一線的實地經驗所校準。

我的一個重心是透過設定技術方向來成長團隊裡的其他工程師。更具體地說，我透過指導或教練，幫隊友理解：

• 如何做技術決策，以及它應如何錨定在所解決的客戶／業務問題與提供的價值上。
• 如何驅動工程專案，從問題陳述一路到生產發布與長期維運。
• 如何為不同對象（工程同儕、工程管理、非技術利害關係人等）採用適當的溝通方式。

總的來說，我努力幫他們達到一種自給自足的程度——即使我不在場、不在對話裡，他們也能以符合我技術策略、方向與做法的方式運作與溝通。

在哪裡最有影響力#

如果一天結束時，我覺得自己幫同儕排除了阻礙、維持了動能，那總是很有成就感。那可能意味著：

• 幫資料服務團隊成員想清楚解決複雜技術問題的選項，以及「立即價值 vs. 長期可持續」這類取捨。
• 幫另一團隊的同儕想清楚他上季的交付成果是否提供了真正的業務／客戶價值，以及如何圍繞那份影響力建立敘事、做升遷論證。
• 辨識出某項短期「組織工作」因未達共識而停滯，鼓勵相關同儕承擔起做決定的責任，並推動到完成。

這種感覺我整個職涯都有——我享受同儕的成功，一如享受自己的。但接下技術主管角色，確實把做這件事的重要性提升了：它從我單純喜歡做的事，變成我喜歡、且對我負責之團隊健康也很重要的事。

有了頭銜之後#

一旦在 Mailchimp 成為 Staff Engineer，你就是工程領導層的一員。可以明顯感覺到 Staff+ 工程師對自己的時間有更多自主權與掌控權，做份內職責之外的事時遇到的阻力也更少。我也有更多有機的機會去教練、指導、支援團隊外的同儕——這在升 Staff 前就在做，但明顯增加了。

業界同儕常主張「頭銜不重要」。但我 100% 不同意；我在多家公司的親身經歷與觀察都顯示相反。

Staff 專案#

某種程度上算有吧。我以資深工程師身分加入 Mailchimp，立刻被加入一個專案團隊（含一位工程總監與兩位首席工程師），要打造 Mailchimp 第一個內部自助分析平台。

這個專案有兩個關鍵面向：

• 高水準執行：好壞參半的是，有另外兩位首席工程師意味著對我的期待大概不高。但我幾乎不需要他們手把手就能立刻投入核心工作，最後成為團隊關鍵貢獻者之一，並被正式任命為技術主管、隨專案被吸收進資料服務組而繼續看顧它。
• 大量能見度：這個專案被歸為公司級計畫，有大量高階主管的能見度（以及隨之而來的壓力）。我的主管與團隊的首席工程師刻意為我創造發表機會——我在工程 All Hands、公司 All Hands 發表過，還在工程招募活動上共同做了技術演講。因為這份能見度與 Mailchimp 的文化，我加入沒多久就能和各層級工程師協作、和其他部門的分析師互動——這是多數人要花約一年才有的機會。

所以這是「做好工作、和更資深工程師並肩且非常有效」，加上「那些資深工程師刻意給我跨公司的能見度與接觸機會」的組合。重點提醒：升遷是在我又擔任技術主管一段有意義的時間、並在那裡交付大量價值之後才來的。但這個專案絕對是點火者。

到達 Staff 的建議#

• 我主管 Marc Hedlund：他要我用第三人稱寫績效評估。想法是，替別人寫評估時你更可能稱讚、更少苛責。很簡單，卻超級有用，還意外幫我理解如何圍繞我的工作與其提供的價值建立連貫敘事。
• Dan McKinley（前述 Staff 專案的資深工程師之一）：我請他直接回饋我的強弱項。他指出我「跨公司建立關係」的強項很重要，因為工程的人／社交面向不會消失，反而是把事情做成的關鍵。
• Coda Hale（另一位資深工程師）：他談放大影響力——第一，為其他工程師有效設定技術方向；第二，透過你為他們組織的工作來指導他們、發展其才能。這條建議至今仍是我思考技術主管角色的核心。

給剛上任 Staff 的建議#

別以為你要解決整個工程部門所有的問題；從我看到的，那會讓你精疲力竭、很快變得憤世嫉俗。慢慢累積。你被升遷大概是因為你已經在以 Staff 的水準運作，所以不必做什麼戲劇性的改變。繼續做那些讓你到這頭銜的好工作，等你覺得安頓下來了，再從那裡擴展。

• 溝通與建立敘事是關鍵：務必大量書寫。思考問題或想法時就寫下來（即使不打算分享）。通常當我無法用一段連貫、精簡的文字捕捉某個問題或想法，就代表我需要做更多研究，或我很難說服別人這值得投資。書面文字也讓你更有效地擴展你的想法。
• 讓主管的工作更輕鬆：別只帶問題給他們，也帶上（可能的話多個）解方建議並徵詢回饋。這樣主管不必替你把問題全部解完，也有機會用他們的經驗幫你排除選項。有趣的是，對別人來說「回饋你的方案為何不好」通常比「自己想出一套完整方案」容易得多。
• 刻意為直接共事的工程師創造成長、接觸與能見度的機會。
• 及早建立關係：這在你需要動用社交／政治資本去表態時很有幫助。如果你和某人第一次互動就是在為對立的方案而爭，你一開始就處於劣勢。要清楚：你絕不該一味「討好」，但事前建立的關係能讓未來的協作大幅順暢。

老實說，要應用這一切很多，而且只是一個人的意見。把它當成餐廳菜單：選你有共鳴的來試，然後把你的經驗分享給下一個努力邁向 Staff 的人，作為傳承。

關於工程管理#

我常被問這個。我確實有個當 CTO 的目標，但那更像是確保我不對職涯進展自滿的方向性目標。以 Mailchimp 而言，升到首席工程師（Principal Engineer）就能滿足這個目標。我在現在的職級已經能交付真實、可觸摸的業務價值，所以我想我能繼續走 IC 這條路並持續獲得回饋。

另外，我一直在扮演團隊工程經理的許多職責（雖然不是正式的工程經理），所以很多我若轉管理才會想開始做的事，我都已經在實踐、累積了經驗——這暫時滿足了我對管理的癢。

學習資源#

• 用技術對各種技術與非技術對象做口頭溝通是一門技能，我每天都在磨。Kelsey Hightower 是我觀摩「怎麼做對」的對象，另一位是我大學幾門軟體工程課的教授——他很少來上課，但來的時候我學到的比任何學術場合都多。他們都懂得把事情講清楚、依對象調整。
• 兩個幫我打磨技術策略的部落格文章：Pete Hodgson 的〈Delivering on an architecture strategy〉（在功能交付與基礎架構工作間取得可持續平衡的框架），以及 James Cowling 的〈Stepping Stones not Milestones〉（如何在大型架構計畫中交付真實價值）。