本訪談錄製於 2020 年 5 月。Bert Fan 是 Slack 平台團隊（Platform team）的資深 Staff 工程師（Senior Staff Engineer）。

目前的角色#

我是 Slack 平台團隊的資深 Staff 工程師。我很幸運在 Slack 推出 App Directory 後不久加入，因此有機會參與把 Slack 平台演化成今天的樣子。

我的工作很難一概而論，但目標始終如一：讓開發者能在 Slack 之上打造東西，使我們客戶的工作生活更簡單、愉快、有生產力。例如建置新的平台功能、改善 API 效能、寫文件，以及和夥伴、內部整合者、第三方開發者合作，確保他們能做出有影響力的軟體。

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

在 Slack，Staff-plus 工程師做的事極其多樣，取決於你在公司哪個部分、團隊的組成與規模，以及業務對你的需求。他們常是專案的技術主管——幫忙寫技術規格、向各利害關係人收集回饋、與設計和產品密切合作決定要建什麼、領導技術實作；也指導其他工程師、改善面試流程與工程文化、開發工程流程與工具、為重構與技術債提供技術方向。

Staff-plus 的核心就是賦能他人做出更好的工作——當一個力量倍增器（force multiplier）。

我的角色包含以上這些，但我傾向較少聚焦於特定技術，更多關注技術「使能」了什麼。所以我可能花時間做幾乎肯定會被丟掉的概念原型，或蒐集某使用者流程的使用指標好理解如何改善系統。我常在 Slack 平台上建 app，讓自己對開發者體驗保持誠實，也主動在別人的平台上建東西看看什麼有效、什麼無效。我寫的程式碼比公司其他工程師更少進到生產環境，而我對此完全沒問題。

有了頭銜之後#

過去一年我做了很多產品點子的實驗，有些演化成平台的實際功能。我獲得這個機會，一部分是因為我透過成功交付的其他專案建立了信任，但擁有 Staff-plus 頭銜似乎確實賦予我在選擇做什麼上多一點彈性。

好壞參半的是，我也進了很多以前從沒進過的策略與規劃會議。如果你曾想知道從領導視角看「香腸是怎麼做出來的」，或許先想想你是否真的想知道。

少寫程式後，如何掌握真實情況#

我找到的最好方法，是和公司各處的工程師定期做一對一，並花大量時間傾聽。

如果你花時間發展出「工程師覺得能對你誠實」的關係，你能學到很多關於工程現況的事。身為 Staff-plus 工程師，你對別人賺多少錢或下次升遷沒有實質影響力，所以只要你讓自己容易親近，工程師反而能對你更坦率。

到達 Staff 最重要的因素#

我來自相當有特權的背景——大學拿到資工學位、沒有債務或學貸，而這買到的一部分，是「不必擔心房租或找不到工作就能離職」的彈性。我把這份彈性轉化為對工作地點更挑剔、更有策略。

我知道多數人沒這個選項，但對我而言，能做我覺得有意義、我自己會用、我認為對世界有正面影響的事很重要。

這不是任人唯才制（meritocracy），你的專業人脈很重要。我像大家一樣在公司官網投履歷拿到工作，也曾靠尷尬地寫 email 給幾年沒聯絡、但我尊敬且知道他們也尊敬我的經理而拿到工作。我們身處一個「怎麼花時間」選項極多的產業，如果你夠幸運有彈性與特權去選擇，卻不定期評估自己在做什麼，就是虧待了自己。

到達 Staff 的建議：運氣、時機與工作#

我聽過最好的建議是：到達 Staff 往往是運氣、時機與工作的組合。這是我觀察並親身經歷過的一連串事件：

1. 和你的主管發展出彼此隱性信任的關係，誠實直接地告訴他們你想要什麼。建立這種信任需要你成功交付他們交辦的事。
2. 因為主管信任你，當他聽到對公司有重大影響的專案時，會倡議讓你來領導。或者你得自己找到／創造一個專案並倡議它——這難得多，但仍可行。
3. 成功交付這個專案。
4. 專案對公司產生重大影響。
5. 因為你成功交付了有重大影響的專案，倡議把你升到 Staff 很容易，你主管也樂意這麼做。

你應該看得出運氣與時機如何影響這個簡單計畫：如果你和主管處不來？如果主管離職或升遷？如果你在一個拿不到有趣專案的部門？如果專案注定失敗？如果專案成功卻毫無影響？這些都可能發生，沒有通用建議能克服它們——除了：有時你就是永遠不會被升遷，你該對自己誠實、辨識出你正處於那種情況。那時，唯一升遷之道可能是離開公司去做別的。你日後或許能以更高職級「迴力鏢」回到這家公司，但就像一段重訪的失敗關係——你是還想在那裡，還是包袱太重、永遠行不通？

給剛上任 Staff 的建議#

工程界有個玩笑：很多人入這行是因為不喜歡和人講話——但要當個有效的 Staff 工程師，你很可能會花大量時間和人交談。

職涯早期你能靠寫出越來越好的程式碼來進步，但某個時點你大概該轉向「和別人合作得更好」。信任別人並給他們做技術決策的自由（即使是你不同意的決定！）、理解別人的動機、學會給困難的回饋、知道何時該挑戰——這些都是有用的技能。

如果你還沒有，試著成為別人想共事的工程師。每家公司都有幾位工程師，是你一旦離職就會想繞過禁止招攬條款去再度合作的人。成為別人眼中那樣的工程師，會為你的職涯解鎖很多扇門。

關於工程管理#

職涯早期我曾跟主管說擔心自己某天得轉管理，他說：「別擔心！我們公司有管理與 IC 兩條軌，IC 軌有對應最高管理職的等價角色，所以你永遠不必為了往上爬而轉管理。」

這技術上為真，但現在對我顯而易見的省略是：在很多公司，管理軌比工程軌清晰得多。工程階梯爬得越高，可效仿的範例越少、也顯得越遙不可及——當你深究，會發現某人拿到頭銜是因為公司被收購、他是某程式語言或框架的作者、或他為公司解鎖了數千萬美元營收。

我很多同事因各種理由轉了管理，我懷疑其中一個理由正是我描述的「更明顯、更可靠的進展」。但我強烈相信那不該是你的主要動機。如果你能看到主管的行事曆，看看他們一週開多少一對一——那是你會享受的行程嗎？寫程式的渴望不是非黑即白，因為有既寫程式的技術主管兼經理職，也有從不寫一行生產程式碼、整天泡在 Google Docs 或 Dropbox Paper 的 Staff-plus 角色。但在我的職涯裡，我從沒得資遣人、否決別人升遷或寫績效評估——我知道自己想在硬幣的哪一面。