本訪談錄製於 2020 年 3 月。Ritu Vincent 是 Dropbox 的 Staff Engineer。

目前的角色#

我是 Dropbox 的 Staff Engineer。其實我曾是 Dropbox 的 Staff Engineer，離開去了另一家新創，幾個月前才回來，因為 Dropbox 開了一個很有趣的機會——啟動一個內部孵化器（incubator），在公司內培養創新。Dropbox 在檔案同步領域已是強品牌，但現在競爭越來越多，我們需要拓展新產品。這個孵化器直接和 CEO 合作，是個很小的團隊。

我在 Dropbox 待夠久、和很多人建立了緊密連結，所以他們向我推銷這角色時聽起來很好玩。我也當了幾年經理、有點手癢想再寫程式了。孵化器有兩部分：

• 經典孵化器：全公司工程師可提案、拿資金加入計畫，每隔幾個月透過展示產品市場契合度或其他進展來續資，目標是讓成功專案畢業成獨立的事業線。
• 常駐「偵察（scouting）」團隊：長期屬於孵化器、不斷從內部生成點子、以高度自主運作。我是這團隊兩位工程師之一。

這和我以前做過的任何事都很不同，也是我想加入的原因——是個巨大的典範轉移。老實說頭幾個月既好玩又挫折，因為當你的主要目標是很快試很多注定多半無疾而終的新點子時，很難衡量明顯的影響。我得學會用更長的時間尺度思考影響力——不是我今天交付什麼，而是我能影響公司未來交付什麼。

Dropbox 的兩種 Staff 工程師#

• 技術主管（tech lead）：做很多協調、為團隊設計工作、花時間驅動專案。我最初成為 Staff 時就是這個側寫——帶一個約八人的團隊，驅動一個十八個月的專案，那專案有很多依賴、很多棘手部分。我得掌控專案周邊的溝通，並想辦法把專案切片分配給團隊，既幫他們成長又把專案做完。
• 專家（specialist）：在特定領域深度專精，例如 Python 之父 Guido van Rossum。專家接下極複雜、往往沒別人能有效接手的專案並自己執行。專家比技術主管少。

有些專家從業界招募進來（像 Guido 和 ML 團隊很多資深人士），但很多專家其實是本土培養的。這或許和 Dropbox 相對較晚推出頭銜有關——讓人們有更長時間在我們的技術裡累積深度脈絡。

日常怎麼花時間#

在孵化器的現任角色，我整天都在做原型。但在先前的技術主管角色，我做很多不同的事：

• 我有寫程式，但寫得不多，也許 20% 的時間。我是桌面客戶端領域的技術主管，花很多時間協調專案、提供指引。
• 我也花很多時間和招募（recruiting）合作——這是因為我有興趣才做，不是被要求的。例如設計專門的面試流程、主持 debrief 與候選人篩選，也做很多多元化（diversity）計畫。這也是我職涯中多次嘗試工程管理的原因之一，因為我享受參與組織成長。

在哪裡最有影響力#

• 工程職級的大改版：2017 年，我是少數幾位被選來做工程職級刷新的個人貢獻者，其他人幾乎都是總監或經理。我很自豪，因為新階梯影響了 Dropbox 每一位在工程、產品、設計工作的人。深入思考「公司成長如何改變角色與職責」也很有意思，這和我日常職責很不同，把我大幅推出舒適圈。
• 我的 Staff 專案：技術上非常複雜，也給了我幫團隊很多人成長的機會。多年後，有離職的工程師寫信告訴我，因為那個專案他們變得多有自信、學到多少。

倡議與推動改變#

身為技術主管，我花很多時間倡議改變。我會跳進很多架構與技術討論，即使在不直接屬於我專長的領域，因為人們似乎信任我的直覺。我認識很多有絕佳技術直覺、卻沒有 Staff 頭銜的工程師，但頭銜確實把「擁有那種直覺」形式化了。

我偏好讓將要擁有某專案的團隊做關於它的最終決定。在我腦中有非常清楚「正確決定」的情況下，我會試著引導團隊走向那個決定，而不是進去說「這就是正確決定」。

贊助其他工程師#

我絕對把自己視為贊助者。執行是我工作中最有成就感的部分之一——我愛建東西——但我也一直愛幫別人成長。當我看到我非正式指導或幫過的人後來做出很棒的事，我真的很自豪。

身為 Staff 工程師，尤其身為女性 Staff 工程師，我覺得很多人仰望我。管理職涯路上似乎有多得多的榜樣，所以我試著把「當榜樣」納入我的職責，而不是只埋頭寫程式。我尤其想幫有冒牌者症候群的人。常有人來跟我說「我不知道怎麼跨出下一步」或「我不知道怎麼成為 staff 工程師，所以我要去當經理」，我想幫他們理清自己的路。身為 Staff 工程師，可見且讓人能來問這類問題，是這角色重要的一部分。

頭銜帶來的信心#

沒有頭銜時，也沒有什麼我做不到的事，但頭銜確實給了我信心。

升上 Staff 的過程#

Dropbox 在我加入一段時間後才推出對外頭銜。第一個有頭銜的評估季，只給了極少數工程師 Staff 頭銜，那時他們還在校準。我是在第二個評估季拿到 Staff 的——那時我已當技術主管一陣子，主管和我都覺得我明顯在以 Staff 水準執行。我們有在評估週期前過一遍新的職涯層級定義來找出任何落差，但整體很順利。

到達 Staff 最重要的因素#

• 能見度：一大部分來自做很多工程職責之外的事。例如某年夏天我幫招募跑實習計畫，和跨團隊一大堆實習導師合作，加上 Dropbox 的實習梯次很大，最後幾乎讓我在整個公司都有了能見度。招募工作也有幫助——如果你每月主持數十場招募 debrief、驅動招募與校準對話，你會和工程部門每個人互動。我也幫忙上手，給新進者做核心工程簡報。
• 有贊助者：我和主管關係極好，和越級主管（skip-level）關係也很好，我想這也扮演了重要角色。

有些公司會稱這類工作為「膠水工作（glue work）」，但它在 Dropbox 被領導層高度重視——領導層與許多很資深的工程師都深度參與這些努力（尤其招募），並不被當成膠水工作。話雖如此，光靠它不會讓我到 Staff。關鍵是找到「有文化影響」與「有技術上夠強可展示的東西」之間的好平衡。

Staff 專案#

沒有明文期待，也沒列在任何地方作為正式要求，但大家心知肚明：你要完成一個 Staff 專案才會升遷。我想不到任何一個不含很強專案的 Staff 升遷，通常是該工程師擔任技術主管的多人專案。

到達 Staff 的建議#

職涯早期，我的直覺是要那些我覺得能執行得好的專案，而不是更有模糊性、能推我成長的專案。我得到的建議是把自己推出舒適圈、去要團隊裡最難的專案。要到達 Staff，你必須知道並做到超過你目前所知的。重要的是永遠往前推、別怕要那些你覺得對自己太難的東西。

這和冒牌者症候群綁在一起——你可能在絕對確定會出色之前不想嘗試任何事。但你得對「你可能會摔得慘（crash and burn）」這件事感到自在。那沒關係，你就是得去試。

給剛上任 Staff 的建議#

常有人來問我「接下來該做什麼才能到 Staff？」我告訴他們的其中一件事是：對你的主管超級開放誠實地說出你想從職涯得到什麼。我早期在一對一犯的錯，是跟主管說我以為他們想聽的話，而不是我真正的感受。

他們會問我對某項工作有沒有興趣，我會納悶他們為何這麼問、是想要我接嗎？所以即使沒興趣也說有興趣。或他們問專案進行得如何，明明糟透了，我卻為了不讓他們失望而說「還好」，而不是說我需要幫忙。

某個時點我意識到，你的主管真的和你同一隊。他們在找方法讓你成長、有生產力、快樂、成為你能成為的最好工程師。和主管建立有效關係（包括讓他們贊助你）的方式，就是對他們超級誠實開放。這在我自己當上經理後特別明顯，因為我希望團隊每個人都成為 Staff 工程師並升遷，我想找理由升他們。

關於工程管理#

我確實蠻常在兩邊擺盪，因為我對階梯兩側的很多事都有興趣：我對培養人有興趣、很喜歡和招募合作、是那種真的享受面試的工程師、喜歡理解團隊如何成長。但我也真的很喜歡寫程式，管理一陣子後就想回到程式碼裡玩一下。

一旦開始指導與管理，我對職涯成長的看法就很不同了。身為經理，你對人力配置、績效評估有非常明確的職責；Staff 工程師的職責則很模糊、各公司不同。這種圍繞 Staff 角色的模糊，導致許多本會更快樂地留在工程的人做了橫向轉管理的選擇。這正是為什麼把更多關於 Staff 角色的資訊放出來讓人閱讀，如此有價值。

學習資源#

我讀很多，但很休閒。對我最有影響的，是有很多我視為導師的人——通常是朋友、前主管、共事過的人。我有不少和過去共事、了解我、我信任的人固定每月的午餐、咖啡與晚餐約會。正是那些關於職涯挑戰與成長的對話，把我帶到職涯現在的位置。