《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 表單留言唷 : )