Bernard：那我好奇問一下，我們有幾個校友碰到以下的狀況：離開 AC 後，當個工程師三年，被主管要求當主管。在台灣如你當工程師到某種程度，工作表現不錯，老闆覺得這兩、三個人可以給你管，或是你可以幫忙去找人。但我們的校友都會有些猶豫，不知道要不要選擇「管理」這條路。他們都很享受當一個工程師，也覺得如何能專注繼續寫 code 就好了。

請問 iCook 有純技術的的 career path 嗎？或是你建議會怎麼去建議怎麼去探索這個事情？

Richard：平心而論說，當「主管」沒有比較好。我如果是一個工程師，難道到某個年紀我就要當自動主管嗎？也不一定。從工程師到管理者，這是一個 career change。很多人沒有意識到這個問題。像傳統企業可能會覺得，從一個專員科員，慢慢的就要晉升為主任。但我覺得在
工程師的世界該不是這樣的。

就像我剛剛講的，工程主管一定是最會寫程式的嗎？不見得，我覺得所謂的工程管理，它有另外一門學問在。如果回到個人的話，我過去會認為「轉職工程師」的人可能不適合當工程主管，但我最近反而覺得是相反。轉職的人其實蠻適合的，因為如果是從其他行業轉職到工程師的人，可能跟其他人比起來，有更多的 soft skill。

用剛才的例子，「要不要升級 Vue 3.0」，真的是個「技術 (technical)」的議題嗎？不見得。我認為很大的部分時我們有沒有辦法說服整個團隊去改變。因為團隊裡面一定有些人覺得麻煩：「我的套件用得好好的為什麼去做這個？又不是什麼 security issue ，我為什麼要升級？」

用另一例子：大家寫 JavaScript，但可能比較大的團隊開始想轉成 TypeScript。

又或是選擇編輯器。公司裡有些人用 vmin ，有些人用 Sublime Text，又有些人用 Visual Studio Code。如果你今天是公司主管，那你要不要統一都用 Visual Studio Code？公司如果原本沒有這樣子的規劃，然後你忽然說要做統一，這樣你要說服的人會非常多，要化的力氣也非常大。所以像這種情況，其實溝通能力遠比技術能力重要。你怎麼去跟管理層爭取、你如何跟團隊取得共識。其實這些才是當主管的工作。

Bernard：也就是說，如果你在考慮是否要當主管，你要去真正瞭解所謂「主管」的工作內容。技術問題只是其中一個題目。每一個決策它有不同非技術、需要思考的點。當你要換一個技術、換一個工具時，你可能需要思考對產品、對公司的影響，又或是要去跟誰建立共識。這些都是非技術的題目。要選擇是否要當主管，就要看你是否對這些題目有興趣。

最後，我想問問，當建立好團隊後，Richard 現在的焦點是什麼？