《The Staff Engineer’s Path》成為催化劑吧！單位時間高輸出的工程師之路︱閱讀筆記
A Guide for Individual Contributors Navigating Growth and Change
💡 Contents:
· 五年後，你期望成為什麼樣子？
· 技術能力點滿，就能在 Staff+ Engineer 職涯通行無阻嗎？
· 除了回答問題之外，多講一些
· 成為催化劑吧！
· 結語：有人應該要……，通常，你就是那個「有人」「五年後，你期望成為什麼樣子？」
這個經典面試問題，相信很多人都準備過 — 準備過面試時的標準回答。前陣子組織大風吹，跟新主管 1-on-1 會議時，再次討論了這個問題。當然，還是多多少少參雜一些標準答案。在新環境安頓下來，日常穩定之後，偶爾會想著這個問題 —「五年後，想要成為什麼樣子的工程師？」
美國科技公司中，軟體工程師一般在 Senior engineer 後有兩條路 — 管理職，以及 Staff+ engineer。本書用 Staff+ 統稱 Senior 之後走技術開發的職涯，包括 Staff、Senior staff、Principle engineer，本文也一併用 Staff+ 概括非管理職的職涯。
因為管理職要講很多話，對上對下有一大堆的溝通，所以在面對這個問題時，不管是這次對主管的回答，或是在腦中的自問自答，常常自然而然導向「應該會往獨立開發發展吧，因為英文沒母語者好」。
某一天，突然意識到這個想法很不優，怎麼會因為技不如人而選擇一條路，而不是因為想要走這條路而選擇這條路，對這條路真的了解嗎？想起了以前曾經存在清單中的《The Staff Engineer’s Path》，默默地從 Amazon 電子書城按了下載。
技術能力點滿，就能在 Staff+ Engineer 職涯通行無阻嗎？
作者用了一本書的篇章討論 Staff+ engineer 的職涯，打開之前也已經預想到，90% 是否定的吧，很好奇作者會怎麼討論這個議題，促使我繼續看下去。
時間很貴的 Staff+ Engineer，aka 單位時間輸出高的價值人物
升上了 Staff+ engineer 好開心，薪水提高了，公司支出更多了，代表 — 你很貴，如果一樣一天工作八小時的話，這也代表— 你的時間很貴。「當一個獨立開發的工程師能走到這個位置嗎？」這是我在開啟本書前，最想看到作者回答的部分。
擁有提高「團隊」單位時間產出的能力
除非是神人中的神人，否則個人單位時間輸出有它的天花板，承認吧，極限大概就是那樣。對公司的角度而言，比起「個人」單位時間有多少產出，更在乎的是「團隊」單位時間有多少產出。從政策上的決定是否啟動專案、專案走向，至執行上的解決瓶頸、減少新人上手時間、減少維護成本，這些都是長期而言幫助團隊單位時間產出的項目。
Glue Work — 那些不被重視的「雜事」
Being Glue 是我認識作者 Tanya Reilly 的第一篇文章，非常推薦給花時間在寫說明文件、幫助新人上手、回答別組問題時徬徨的你。有些事情雖然知道有人要做，對團隊是有益的，但也知道這些事情無法寫在年度績效考核上，或是在績效考核中不太起眼，因為看起來「貢獻」好像比不上完成了新功能、效能提高了多少百分比這種技術上的貢獻。
讀到 Staff+ engineer 的價值在於他能提高團隊產出之後，腦中的結突然打開了 — 說明文件可以幫助釐清架構，好讓要做 2.0 版本的時候，更容易站在這一版的基礎上；幫助新人快速上手等同於幫助一個人馬上有生產力，這個人即更快投入團隊輸出；回答別組問題可以幫助別組釐清我們組已做的事，減少重工時間，時間即可以花在別的地方，提高公司單位時間輸出。如果把層次從個人提升到團體的話，就不會覺得這些是雜事，而是對團隊有幫助的事。
念頭轉換後，做這些 Glue Work 時變的心甘情願，因為知道這是對團隊輸出有幫助的事，不再有趕快結束，趕快去做在技術上能顯示貢獻項目的想法。當然，執行 Glue Work 時還是有時間比例分配的問題，如果有這方面的煩惱的話，非常推薦看看 Being Glue 這篇文章。
不太寫 code 的高輸出工程師
作者對 Staff+ engineer 的定義為領導者的角色（a leadership role），只是領導的不是人，而是專案。跟管理職不一樣的在於不用管人，沒有人要對你 report，不用跟組員一對一定期開會。跟 TPM（Technical Program Manager）是合作關係，兩者都是要確保專案順利送出，差別在於 TPM 著重在確保專案「準時」完成，Staff+ engineer 著重於確保專案「高品質」的完成，包含工程品質、架構設計、維護成本、確保系統穩健、沒有產生技術債（technical debt）、不會製造一堆陷阱給未來。
所以，這個角色很貴，投資時間的時候，如果要寫程式，要馬花在最難，要馬花在解決瓶頸，或是將一坨混亂理清，當事情是可控的時候，就是傳遞給其他同事接手的時候了。通常也會花很多時間在一開始的系統設計，骨幹歪了，後面要長的好也很難，方向歪了，再怎麼前進也不會到達目的地。就像一名駕駛一樣，規劃最佳的道路，繞開障礙物，帶領著專案前進。
除了回答問題之外，多講一些
Staff+ engineer 是個「知道」很多的角色，大至專案的規劃、專案的藍圖，小至怎樣才算好的程式品質、為什麼當初決定這樣寫這段程式。如果這些知識都停留在腦海裡的話，那就只是個個人收藏品罷了，怎麼把這些知識輸出給團隊，帶來好的影響，是一門很大的學問。
給 Review Comments 時，多講一些「為什麼」
“Teaching means sharing understanding, not just facts.”
給 review comments 時，除了要「做什麼」，多講一些「為什麼」。譬如說這邊比起用 int，用 uint32 更好，因為…；這個 function 比起這樣寫，拆成兩個更好，因為…。有些建議表面上其實都可以，沒有照 review comments 做也不會壞掉，因為效能的關係，因為維護的關係，因為一致性關係，你寫下了這些 review comments。把原因講清楚，對方也會改的比較心甘情願，更有這一行的「sense」，更重要的是，下次遇到類似的事情，就會一次到位了。
面對較 Junior 的同事問問題，不讓他覺得自己笨是你的責任
“If you’re talking with someone more junior than you, it’s kind of your responsibility to make it not awkward.”
Staff+ engineer 的價值在於能夠提高團隊輸出，當管理職多分配一名人力給這個專案時，協助新人快速上手，了解來龍去脈，是這個角色的責任，新人上手的越快，團隊越快開始提高輸出。
當一個產品運行三年以上，它背後的原始碼，規模通常很大，許多決策常常是因為歷史造成的原因。比起讓新加入專案的同事獨自 trace code，主動分享一些文件（還有文件的哪裡已經過時，可以跳過不用看）、哪裡是主程式、哪裡是主要檔案，更能讓新人快速上手。面對問題時，不讓他覺得自己問的問題很奇怪，是講者的責任。臉上的表情、應對的反應，都有可能影響到對方下次敢不敢再問問題，尤其是剛出社會的同事。
想想自己剛出社會的腦袋，多主動講一些來龍去脈，和適時的反問這樣有解決疑惑嗎？或許他根本不是想問這個問題，但他不敢再多問一些，怕佔用資深工程師的時間，又回頭去自己埋頭苦幹，一個小時後，看見他小心翼翼地回頭來問剛剛很想接續問的問題，才忽然意識到，原來他想問的是這個，剛剛一個小時就是不必要的浪費。
成為催化劑吧！
催化劑般的 Staff+ engineer
Staff+ engineer 如同催化劑一般，催化著新人的融入時間、同儕的技術成長、專案的進行。如果秉持著一天工作八小時的話，一個人的時間相當有限，如何將這些好的影響淵遠流長地影響個人、團隊、組織，長期提高團隊輸出，將是這個角色該思考的事情。
建立 Common Sense
當覺得一些行為很沒常識的時候，不要想著怎麼這麼沒常識，而是要反思這些常識好在哪。如果思考後確定是好的行為的話，下一步該思考怎麼建立這些常識，對長期合作才是良好的關係。
“If you can stay calm and constructive and avoid casting blame, other people will too.”
最好的情況是，到了揮揮衣袖離開的那一天，不管是離開專案，離開部門，或是離開公司，好的影響力仍然持續發酵中，那就是成功的扮演這個角色了吧。
結語：有人應該要……，通常，你就是那個「有人」
“Whenever there’s a feeling of “someone should do something here,” there’s a reasonable chance that the someone is you.”
你就是那個「有人」
Staff+ engineer 是領導者的角色，對於專案，沒有什麼那不是我該負責的事情。當你覺得怪怪的，有人應該要去查查清楚的時候，通常 —你就是那個「有人」。不過這不代表任何事情都要親力親為，一般是分派誰去做哪些事，這代表的是沒有什麼置身事外的事情，看到什麼說什麼，哪些工程常識想要改變，你可以想辦法去改變，聽到同事 A 不經意說的一句話可能傷害同事 B，你是可以幫助解決疙瘩的最佳人物。只要是對整體團隊輸出好的，都不是雜事，只要是對團隊輸出不好的，都不能視而不見。
“If you see something, say something”.
軟體工程師之路
本書從許多面向探討 Staff+ engineer 職涯上會遇到的情境，看這本書時，常常會想起自己身邊的同事 — 活歷史般又樂於分享的同事、總是笑臉迎人讓人很敢問問題的同事、得到解答時總是花式感謝，讓我增加自信的同事、看到哪裡對長期而言維護困難，會主動提出的同事（即使現在沒時間解決，但依舊會提出，列在團隊的待辦清單）。更有意識地記住哪些是有益的行為，到了相同情境，期許自己也執行這些有益的行為。
因為不喜歡溝通，所以走技術職？
最後，回到一開始的自問自答 — 「應該會往獨立開發發展吧，因為英文沒母語者好」，「因為我內向，不喜歡花很多時間跟別人溝通，所以不走管理職」，「因為我喜歡一人從頭到尾自己來，所以走技術職」。這些因果算是完完全全被擊破了，Staff+ engineer 的價值在於他的輸出能提高團隊輸出，專業知識勢必是必須的，然而除了專業知識之外，討論專案、決定架構時說服別人為什麼選擇這個架構、了解瓶頸並提出解決瓶頸的方案、將自己腦袋裡的東西帶給團隊，都需要溝通能力。除非安於現狀，沒有想繼續往前的意思，否則想在美國繼續發展，英文不是能躲避的問題。
好久沒有深度閱讀一本書了，感到衝擊，正視衝擊，處理衝擊，在這個人生階段能遇到這本書真好，再過個幾年，多經歷一些情境，回頭來翻翻這本書，應該會有更多的感觸吧。推薦給，正在工程師之路發展的你，在思考要往技術或是要往管理發展的你，又或著是想要面對「五年後，你想成為怎麼樣的工程師？」這個問題時，有更多感觸的你。
- 書名：《The Staff Engineer’s Path: A Guide for Individual Contributors Navigating Growth and Change》
- 作者：Tanya Reilly
- 出版日：2022/09/20
- Amazon 連結
－2023.05.07。
想敲碗什麼樣的內容，或資訊有誤/欲補充的話，歡迎在下方留言讓我知道，不好意思公開的話，也歡迎在Google 表單留言唷 : )
