沒有明文期待，也沒有列在任何地方當正式要求，但大家心照不宣：你要完成一個 Staff 專案才會升上去。我想不出哪個 Staff 升遷是不含一個很強的專案的——通常是多人專案，而該工程師是技術主導（Tech Lead）。—— 里圖·文森（Ritu Vincent）
一個反覆出現的說法是：要走到 Staff-plus，你得先成功完成一個「Staff 專案」——一個複雜、重要到「完成它就等於證明自己是 Staff」的專案。這說法再流行，若你真在追 Staff-plus，重要的是戳破它的神話，回到走過這條路的人的真實經驗。
簡短版答案：大多數工程師在達到 Staff 的過程中並沒有完成 Staff 專案，但有相當比例的少數人有，尤其是在同一家公司內部一路成長升上去的人。沒完成的人，通常要嘛是在較長期間累積成功紀錄、沒有單一收官之作，要嘛是換公司才拿到頭銜。
以下從三個角度切入：沒做 Staff 專案的人、有做的人（含它未如計畫收尾的情況）、以及如何辨識並著手你的 Staff 專案。
不需要 Staff 專案#
問到有沒有 Staff 專案時，有些答案相當乾脆：喬伊·艾伯茲（Joy Ebertz）說「我其實沒有 Staff 專案」；黛安娜·波賈（Diana Pojar）說「沒有，我沒有被指派的 Staff 專案，那也不是 Slack 升遷流程的一部分」。
也有人對這概念本身存疑。
尼爾森·艾爾哈吉（Nelson Elhage）說：「我本能上對『Staff 專案』這種想法有點戒心，部分原因是我看過的一種 Staff 原型，是那種不見得親自跑大專案或做大事、但就是極其有效的『大師與路由器』，讓整個工程組織運作得更好的人。」
另有像丹·納（Dan Na）或達米安·申克爾曼（Damian Schenkelman）繞道工程管理而達成的人。達米安描述自己如何略過：「因為我在 Auth0 的成長方式，我算是『跳過了那部分』。身為新創的總監，我有機會技術主導很多重大關鍵的計畫，但沒有一個特定、明確的 Staff／Principal 專案。」
可見任何告訴你「非做 Staff 專案不可才能到 Staff-plus」的人都錯了——通往頭銜的路很多，其中一段工程管理經歷尤為常見。
需要 Staff 專案#
不過也確實有很多公司要求（或非正式地強制）內部升遷須有 Staff 專案，因此許多人真的會接下一個作為角色轉換的一部分。
案例：兩種 Staff 專案的樣貌
里圖·文森描述她在 Dropbox 的經驗：早期 Dropbox 是個人下載安裝的消費產品。推出 Dropbox for Business 後，出現「個人與工作帳號同時運作、免登出即可切換」的需求。初版在巨大時間壓力下寫成，跑多個 Dropbox 行程（個人一個、商務一個）。她的 Staff 專案是讓單一 Dropbox 行程能同時登入多位使用者——難點在於它從核心（kernel）一路貫穿到使用者介面，她必須理解 Dropbox 系統的每一層。原估六個月，最後花了十八個月，佔用桌面客戶端團隊大量資源好一陣子。
拉斯·卡薩·威廉斯（Ras Kasa Williams）則以資深工程師身分加入 Mailchimp，立刻被編入一個要打造第一個內部自助分析平台的專案團隊（含一位工程總監與兩位 Principal 工程師）。有兩位 Principal 在，對他的期待或許不高，但他幾乎不需帶就能上手貢獻核心工作，到最後成為團隊關鍵貢獻者之一，並被正式任命為技術主導，隨專案併入他所屬的 Data Services 工程組。
很少公司會把 Staff 專案要求寫下來，它更常是升遷會議上才被提起的「軟性關卡」，有時連主管和當事人都措手不及。最可靠的揭露方式是「十拿九穩」的升遷沒過——但那並不好玩。幾乎一樣可靠、卻不那麼令人沮喪的，是在嘗試升遷之前很久，就維護資料包並持續取得回饋。
為什麼你該做一個 Staff 專案#
把關與評估之間的界線有時很難劃清，Staff 專案正處在這片模糊地帶。承接一個規模龐大的專案、駕馭其中的不確定、並成功交付，是區分出「已達 Staff-plus 影響力」的人的有效方式；但同樣清楚的是，很多人沒做這種專案也達到了 Staff-plus。
作者的建議是：即使不做 Staff 專案也能到 Staff-plus，它仍是難得的自我成長機會。這種專案會以其他 Staff 級工作無法比擬的方式，把你撐大、逼你成長。凱維·麥克明（Keavy McMinn）說，她主導並架構過幾次這種「解決棘手工程問題、對公司有大影響」的專案，雖然沒直接帶來升遷，卻帶來職涯進展——那些經驗、知識與信心讓她能以不同方式定位自己，甚至公開演講、或知道「我做過 X，而且能再做一次」。
這類專案雖各不相同，但有幾個共同特徵解釋了它們為何如此能撐大你：
- 複雜且模糊——職涯早期你拿到的是定義良好的問題，但越往上會越常遇到定義不清或未定義的問題。Staff 專案往往從一個界定粗糙、卻複雜而重要的問題開始（例如只有一句「公司老舊的單體正拖垮產品開發」），你得從這模糊、甚至可能錯的斷言中，找出可行的具體路徑。
- 利害關係人眾多且分裂——最簡單的專案一開始就對問題與解法有組織共識，但你的 Staff 專案可能兩者皆無：管理層視為存亡風險、多數工程師卻覺得「夠好了」；或大家都同意有問題、卻對做法（走服務化還是重新投資單體）強烈分派對立。
- 有名有姓、失敗要緊的賭注——它重要到資深領導會在全組織或全公司大會上提起，意味著大家會緊盯你的工作，任何失敗都極為顯眼——成功也一樣顯眼。
若符合這些，它大概就是 Staff 專案。它們相當令人緊張，而這正是它們如此能鍛鍊人的原因。
如何取得 Staff 專案#
決定要做只是第一步，你還得取得專案，而這取決於你的管理鏈是否夠信任你、願意賭你會成功。歸結為三個因素：
- 與領導層保持一致（策略見〈進入關鍵場合〉與「與權威保持一致」）。
- 被認為具備該問題所需的技術能力，這需要你有能見度。
- 公司剛好有解決 Staff 級問題的迫切需求——這較不在你掌控中，可能需要點耐心。
到底該不該追一個 Staff 專案？#
- 若你想在現公司內部升遷、且先前沒擔任過 Staff 或管理職，你很可能需要做一個 Staff 專案來確立自己在該層級。
- 其他情況下，你多半不需要。
無論是否被要求，這類專案都是你能找到最具挑戰性、最能把你撐大成更好工程師的工作。短期為了搶頭銜，避開它們或許是最優解；但長期為了自我成長，它們無可取代。