As a Software Engineering Manager 你應該要知道的三件事

Kai

Published in

Gogolook Tech

8 min readAug 21, 2020

前言

許多工程師在職涯發展上都會面對到一個選擇，要選擇繼續寫程式的 IC Track（Individual Contributor Track），還是要轉管理職 (Manager Track)？

我有八年的軟體開發經驗，目前待在 Gogolook 第六個年頭了，都是在新創的環境工作。從 Web Front-End 出發後來轉為 Back-End Engineer，於 2019 年開始擔任 Back-end Team 的部門主管身兼 EM 的角色，想透過這篇文章跟大家分享我從 IC 轉職到 Manager track 的心路歷程。

管理就是最大限度地激發他人的潛能和創意
— 彼得杜拉克

我們公司對於主管的 R&R 描述是這樣：

協助成員扮演更好的角色
— 給予成員正式回饋提供能支持和鼓勵部屬的正向成長的工作環境
協助團隊持續成功
— 主管與 Unit Head 與 Product Owner 共同管理中長期的產品目標與產品路徑，識別與積極改善團隊未來可能遇到流程與瓶頸，確保團隊能持續獲得成功
管理團隊專業路徑
— 主管要識別與管理團隊所需的流程、技術、工具或技能，目的是讓團隊成員能有效率的達成團隊目標。
處理團隊溝通問題
— 協助成員進行有效率與有建設性的溝通

然而我一路以來踩雷的心得可以歸納成下面三點：

轉管理不是升職而是轉換跑道
專注於優化流程
管理者的成功來自於團隊成功

轉管理不是升職而是轉換跑道

當我還在 IC track 的時候曾經聽過許多同業說過類似的話，是不是程式開發到一定的程度之後就必須要轉管理自己的職涯才能夠繼續成長？

我更覺得踏入管理職是職涯的二轉而不是升職，因為公司認為身為資深工程師的你有了足夠的專業知識跟經驗，可以透過你所累積的一切更大幅度地影響組織的其他層面幫助他人成功，這是一個角色上的改變並不是單純的升遷獎勵。

這樣的轉變過程可以參考下圖：

Photo by Nikolay Stoitsev on The career path of software engineers and how to navigate it

既然角色改變了我們所被賦予的目標也會跟著改變，世界許多知名的軟體公司在設計他們的 career ladder 的時候都會有類似上圖的設計，在 IC 資深到某個程度的時候切出一條 EM 支線，這就是一個二轉的概念。有興趣的人也可以參考 Square 的 Career Ladder，裡面也開宗明義提到：

Becoming an EM is not a promotion — it’s a different role

管理講的是用科學的方法處理事情，既然是科學那就像是軟體開發一樣需要學習，就像過去我們學習程式語言、資料結構、演算法一樣。

我們得投入時間學習「管理」滿足計畫、組織、規劃、協調、控管這些面向來達成你的角色目標。

所以這跟 IC 是全然不同的專業。

專注於優化流程

剛當上管理者的時候有滿腔的熱血，很想改善過去在 IC track 所遇到的各式問題，像是自己跳下去解以前沒有還的技術債、跟其他工程師一起開發功能之類，自認有足夠的 domain knowledge 一起開發最快。

但後來才發現自己陷入了看到一個問題解一個的窘境，並不夠宏觀的看懂局勢，不夠充分理解自己的角色目標是什麼。

於是我開始從各式的文章書籍以及同行前輩身上吸收許多關於 EM 這個角色的樣貌究竟如何，然後不斷跟老闆討論這樣的角色在我們這樣規模的團隊應該要肩負怎樣的任務？

其中最核心的問題：
— 你想將團隊帶到哪裡去，你希望你的團隊成員在怎樣的環境工作?

創造一個可以讓成員持續成長也持續幫助公司獲得成功的團隊

這是我不斷反覆思考得出的想法。

創造一個環境，透過制度培養員工以及有戰鬥力的團隊。形塑團隊文化才是 EM 應該要努力的目標，而不再習慣將員工的工作都加在自己身上。

關於技術債

我開始將重心放在技術債怎麼會發生，該如何在未來再度避免？而不是單純去解決它們。如果我們現在無法解決該用什麼樣的方式去追蹤，於是就開始導入了 issue tracking 的機制，盡量減少未來我們在系統中發現小精靈卻不明所以的狀況。

Git & Code Review 的使用標準與流程不一

每個工程師對於怎樣叫「完整描述」一件事情有各自的解讀，時常無法有效的告訴其他人「為什麼」你的程式要做這些改動。

於是我開始制定 Git commit message 應該怎麼寫，PR 的 title 跟 description 要符合怎樣的規範，搭配 issue tracking mechanism 讓大家有 convention 可以遵循，而不是去檢討特定的人 description 寫的不清楚。

什麼叫做完一件事

完成一個任務往往有很多種做法，還有完成度的問題。
以撰寫 Http API 為例，把 code 寫完推上去 client 打得到就算做完嗎？沒有 unit test 沒有 API document 可以算是做完嗎？

試著定義好 DoD (Definition of Done)

設計一個 Http API 要具備怎樣的東西算是做完？
設計一個 scheduler 要用怎樣的工具符合團隊維護的規範？
怎樣的 Monitor 機制可以符合 POC 階段的系統以及 OP 階段的系統？
…

透過 EM 主導讓團隊成員針對各項開發流程凝聚出 DoD 的共識來當作團隊規範。

對於 DoD 有意見則應該走一個公開討論修改 DoD 的流程，持續精進團隊對於 DoD 的期望，讓軟體品質可以持續的提升，而不停留在各自堅持己見的泥淖。

定期的 1 on 1

1 on 1 可以幫助 EM 持續了解你的組員目前遇到的各種問題，身為 EM 我應該要如何幫助他們克服困難，排除問題可以讓每個人的產能獲得提升，同時他們也會給你反饋告訴你團隊有哪邊需要改善。

假設某人的 coding style 較為隨性造成其他組員的困擾，可以讓你理解到 convention 的設計還有可以精進的地方。

然後試著聊一些尷尬的問題，因為難得的 1 on 1 時間可以多討論一些你們不能在公眾場合討論的事，比方說可以多聊聊組織或公司哪裡有問題，你覺得問題出在哪？應該要如何改善？或是個人的工作的績效還有哪邊可以做得更好？若只把寶貴的 1on1 時間拿來討論一般的公事，會非常的浪費。

這是一個持續且正向的循環，來讓你針對流程的改善在一條正確的道路上。

辨別適合團隊的人

招募一直是組織很重要的一個環節，畢竟身處軟體公司「人」就是我們最大的資產，如何尋找能力符合預期且認同公司文化與價值的人是一門學問。這時我們就需要跟 HR 一起設計面試流程，來幫助我們尋找適合的人，若沒有好的流程辨識人才，找來不適合的人這對於公司與團隊都是一個非常大的傷害。

所謂的做事方法跟流程其實就是團隊文化很重要的一個環節，我們期望看到怎樣的文化就試著從改善制度跟流程開始做起。

管理者的成功來自於團隊的成功

軟體開發是一項腦力密集的產業，用火車來比喻的話，每個人都是這台高速運轉火車的重要齒輪，身為管理者應該要如何扮演一個好的潤滑劑讓每個人都能順暢的運轉，可以幫助團隊成員發揮他們最大的價值，專心跟著公司的目標一起往前衝刺並且達陣，我想這才是管理者的成功與責任。

結論

在 IC track 跟 manager track 要在意的事與所需要的技能是截然不同的，不同的角色被賦予的也是不同的目標跟責任，所以常常有人說換了位子就換腦袋其實是很必要的事。

好的工程師未必等於好的工程主管，最好抱持著一張白紙的轉職心態踏入會是比較好的選擇，建立好心態入門比起自己擁有怎樣的技術或是管理能力還重要，若心中沒有明確想要達成的目標很容易迷失在路上，也會對於自己究竟要精進技術還是精進管理能力感到困惑。

我才剛二轉不久，在 EM 裡面還是菜鳥一枚，還有許多要學習的地方，希望這些內容能夠對於正面臨轉職困擾或是剛成為管理者的朋友們一點啟發。

感謝我的前老闆 William Yeh 大大給了我一個舞台可以嘗試不同於 IC 的職涯發展方向。

也感謝 Gogolook 對於投入資源培育人才這件事不遺餘力，我才有發表這篇文章的機會。

Gogolook 正在穩定地從新創團隊邁向新創企業，除了 Whoscall 我們也正在努力耕耘金融防詐領域的產品。這條成長的路上還有許多的流程跟制度需要更多志同道合的夥伴們一起來建立，如果你也期望做出很酷的產品，或想跟我們一起打造優良的軟體開發文化，歡迎一起來加入我們的團隊！

https://whoscall.com/zh-TW/careers/joblist/