資深工程師的自我檢核清單

在先前的文章中，我們分別談了 《軟體工程師的職涯路徑概覽》 以及《軟體工程師如何在職涯持續成長?》 ，在這期的主題文，我們會更專注在資深工程師這個角色上，更詳細來談要成為資深工程師，有什麼需要具備的軟與硬實力。

我們將會用檢核清單的形式，因此推薦讀者們可以用這個清單來自我檢核，看看自己還有哪些面向需要再多提升。

自我檢核清單

行為面

• [ ] 專注在最重要的事情上
• [ ] 不只從自己角度出發思考
• [ ] 放手授權
• [ ] 確保團隊在對的方向上

技術面

• [ ] 培養出技術深度與廣度
• [ ] 把關團隊的標準
• [ ] 系統性思考
• [ ] 持續探索新技術

行為面詳細說明

專注在最重要的事情上

前 GitHub 首席工程師 Jaana Dogan 先前退休後，最近重回業界加入 Google。先看到她分享一則推文，在談高效主管的共同特徵 (連結) 。

她的原文寫道：

All the effective execs I know had one common trait: They knew their job was to make a few very important decisions, rather than making 100s of small ones. They spent their time developing technical depth to make those decisions. They built and organized their teams accordingly.

如果要用中文理解的話，她的觀察認為，高效率的主管的共同特點是「他們知道自己的工作是做出幾個非常重要的決策，而不是做出數百個小決策」。因此，高效主管會花時間培養技術深度，以做出這些決策。而要成為資深工程師，也需要有這種思維上的轉變。

Jaana Dogan 提到的「做出幾個非常重要的決策，而不是做出數百個小決策」即是一種行為上的區別。如果你總是花大量時間在小的決策上，而沒有留精力給重要的決策，或者沒有花時間培養深度技術來做重要決策，就很難邁向資深。

進一步說，在充滿噪音的現代，能夠準確判別什麼「不該」花時間，並專注在最重要的事情上，會是資深工程師不可或缺的。當能有效判斷，就可以避免出現 Elon Musk 曾說過的 The most common mistake engineers make is optimizing a thing that shouldn’t exist (工程師最常犯的錯誤是優化那些本不該存在的東西)。

不只從自己角度出發思考

在成為資深工程師前會將重心放在自己，但是成為資深後，關注點就不能只是自己，而是要在整個團隊。在 《軟體工程師的職涯路徑概覽》 中，我們有提到，成為資深工程師，意味著要為團隊的成果負責，因此協助團隊成員提升能力、改善團隊成員做事方式來提高生產力，解決團隊遇到的問題，都是資深工程師的範疇。

當不只看自己，意味著要能夠從別人的角度看，包含從團隊成員的角度看。先前聽一位 Google 資深工程師分享，在他剛當上資深工程師時，對於團隊成員犯的錯，總會以質問的角度來看，去一層層追問來釐清問題出在哪。雖然他這樣做是為了團隊好，但因為他這麼做，完全沒有考慮到團隊成員的感受，對方犯錯已經很不好受，還要這樣被質問，變成加倍不好受。

這樣的後果是，團隊的成員開始盡可能避免跟該資深工程師有交集，因為擔心被質問，所以總是會想閃避該資深工程師。這反而導致該資深工程師很難帶好團隊。後來他調整方式，在團隊成員犯錯時，他先去接住對方，用同理的角度讓對方知道，他能懂犯錯時會有的慌張，在處理完情緒後再討論如何避免未來再發生同樣問題，當他這樣同理團隊成員後，反而更能有效帶團隊成長。

從團隊的角度看，要提升團隊成員的整體能力，一個有效的方式，是持續給團隊成員回饋。給回饋時，要切記「在公開場合讚揚，在私下場合回饋」的原則，並且盡可能給建設性的回饋。這是因為給建設性的回饋，意味著跟對方說哪些地方要改進，在公開場合說，有時對團隊成員來說會是傷害，因此推薦盡量私底下約一個 1:1 來給回饋。

不只是給團隊成員回饋，也要主動尋求團隊成員給自己回饋，不論是從工程經理問，或者是從其他工程師問。具體來說，可以適時問其他人「有沒有對我的任何回饋?」。不論是自己給團隊成員的回饋，或者是團隊成員給自己的回饋，請務必確保在回饋之後，有具體的行動方案，不要只停留在回饋，而是要真的在後續改善。

放手授權

成為資深工程師，不代表要把所有事情都攬在自己身上，因為重點是要把事情做好，資深工程師要懂得讓團隊成員有能力來分擔重要的工作。

這樣做有兩個好處，第一個是避免自己燃燒殆盡 (burnout)，畢竟每個人的時間都是有限的，如果有越來越多任務要做，又事事抓在自己手上，一個不小心就會燃燒殆盡。

第二個好處是能避免團隊成員失去成長機會。很多時候，有些資深工程師，因為擔心團隊中的人把事情搞砸，或者是會延後交付，所以資深工程師會想說自己來做比較穩、比較快。但如果從長期的角度來看，這對團隊反而是不利的。如果要讓團隊成員能成長，有時候需要讓成員自己體會過成長的痛；身為資深工程師，比起直接做掉，讓成員練習主導，同時在旁確保不會有無法容許的錯誤，會從長期角度看更有益處的。

更進一步說，在帶團隊成員做技術討論時，即使你已經有觀點，也不要急著先發言。讓團隊成員練習分享自己的技術觀點。過去看過非常多例子，當資深工程師講完話後，其他工程師就都沒有發言，或是不敢發言。這對團隊成長也是有害的，除非是真的非常緊急，不然推薦先預留時間讓團隊成員發言。

在《軟體工程師如何在職涯持續成長?》一文提到的，要讓別人可以取代自己。從資深工程師的角度，要盡可能鼓勵團隊成員、表達對他們的支持，以及創造機會讓成員能取代自己。過去我們看過最好的示範，是在跨部門討論時，資深工程師讓團隊成員當主要分享者，而當進到問答環節，如果團隊成員招架不住才跳出來擋。這樣能創造讓團隊成員練習的空間，但又能確保團隊成員不會因此受傷。

確保團隊在對的方向上

前面兩點分別談了在思考時要以團隊為角度，以及要授權讓團隊做事；然而，從團隊的角度看，還有一點不能忽略的，就是資深工程師要確保團隊在對的方向上。就像產品經理是負責產品的方向，資深工程師會負責團隊中的技術方向，例如要不要換去用某個新技術、要不要做某個重構等，確保團隊都是一齊朝該方向前進。

要確保團隊在對的方向上，一個要點是去問「為什麼我們要做這件事?」，藉此來確保團隊做的事情，是真正能帶來價值的事。

同時，需要確保有清楚溝通該方向。在溝通方向時，不該只是溝通表層，還要讓團隊知道背後的原因。舉例來說，如果要做一個大規模的資料庫遷移，不只要講要做遷移，還要讓團隊知道為什麼這件事情重要，當團隊知道事情的重要性，會更容易齊心朝該方向一起努力。

與此同時，要時時與團隊成員溝通期待，要讓成員知道你對他們的期待到哪裡，並清楚界定團隊中的工程師，每個人該負責什麼、什麼時候該交付。常見的做法，是透過每天的站立會議，來確保團隊有在軌道上；以及每次任何會議後，要有清楚的待辦事項以及負責人。

閱讀更多

在談完行為面向的區別，接著我們會探討在技術面向，資深工程師有什麼區別。 這些問題我們在 E+ 成長計畫的主題文都有更詳細談到，推薦感興趣的讀者閱讀

本文為 E+ 成長計畫的深度內容，截取段落開放免費閱讀。歡迎加入 E+ 成長計畫閱讀完整版本 (點此了解 E+ 的詳細介紹)。