不知道這部門主管的專業，是不是真得如此不堪，但類似的描述，在一般工程師的口中，倒是常常聽到，相信不會是個案。 有沒有想過，從不同的視角，解讀的方式也許會大相逕庭？部門間溝通需要彈性，這有助於整體團隊合作效能。但主管不堅持己見，以全局為重的作法，也有可能被誤解為態度軟弱，不懂為自家團體多做爭取，總是退縮，加重自家人工作負荷。我們且試著以公司的立場來看，會比較嘉許以團隊合作為優先的團隊，還是以自身福利與工作量為優先的團隊？ 主管對內要求技術專業，或許會被懷疑只是唱高調，但可比得過且過的主管好多了吧。舉個例子，曾看過一些機構團隊，覺得應付工作要求已綽綽有餘，但實際上不重視公差控制，設計時從不用工具軟體精算公差，導致經常得在產線進行二次重工。這樣的隱形成本，即使外界非專業人員看不出來，主管卻得要有擔當推動改善，增加產品競爭力，才對得起主管這職位。 團隊若成長到一定規模，容易出現三個和尚沒水喝的毛病，這時管理就顯得非常重要。主管職責包括盡力了解團隊，發現潛在問題，並協助所屬人員不斷成長。非關工作的個人對話，的確有助於建立關係增加互信，但職場實務上，主管與所屬員工間的關係，並不見得一定得是好友，不常聊天也算正常。（就像同事間共事，也不見得得先當好友啊） 好的公司自然會成長，16年前後相信已有很大的不同。建議換過角度，重新想想再做決定，終究適應變革始終是職涯上的重要課題。

會這樣問，猜想您的狀況應該是，多半對現有工作不甚滿意，但也還沒到完全過不下去的程度；另一方面，找到的新職位雖輕鬆了些，但對福利和發展方面仍有些顧慮。 試著換個思考的面向，（且先不考慮運氣這回事）如果能爭取多一些職位的選擇權，裡頭總會找到在福利和文化上都比較適合的吧? 如此就不必總是在糾結魚與熊掌的問題。或者說得更露骨些，不必一直屈就於不太滿意的雞肋選擇。甚至機會都有可能自己來敲門拜訪。 想要能夠如此，這道路簡單的說，就是累積實力抬高自己身價。憑藉年資累積的“資深”只是稱謂，不見得代表在業界的實力，換工作不見得能拿到原有待遇。不妨仔細觀察看看，非常優秀的PE會提出什麼創意的改善措施、能如何提昇稼動率？公司都會有歷史，查查看前人的成就、專利、獲獎勵記錄，應該就能明白努力成長的方向在那裡。 總而言之，提升職能是不二法門。建議您要常常盤點，履歷上能多出那些擲地有聲的記載，這才是職涯選擇上該優先考慮的項目。福利、壓力，相較之下，比較不是可以單靠自己來追逐的。 共勉。

先做簡答：是的，您該高興有這樣的機會。 組織管理的實務上，從內部拔擢新幹部時，藉由代理新職務一段時間，觀察績效再扶正，這是經常套用的模型。其實這麼做對各方都好，不見得是單純摸頭壓榨。 且試著理解看看，假設啊，真的只是假設啊，您初次嘗試管理工作，薪水也直接調升，但萬一短期內沒能適應好，部門運作不順，想想上層主管會怎麼做？若是減薪降職，您丟了面子，甚至於一氣之下走人，將成兩敗俱傷之局；若是置之不理，單位績效不好看、基層士氣低落，也是難收拾。 那如果先給機會試試呢？真能不適應時，調整工作內容就好，算是平調，比較沒面子問題，這樣對大家衝擊都小一點。如果順利漸漸適應，從代理階段變成正式職位（此時當然該加薪），則皆大歡喜。 此刻，您可以與上層溝通，代理主管的期間長短，轉正的標準，該設定個目標吧？ 不同組織文化裡，這期間的確會有蠻大的差異，但一般來說，建議可以是三到六個月，最長最好別超過一年。 直接攤牌，要求調薪行不行？得先要衡量您對新工作的把握度而定，也要視上層的風險管理風格。這是比較不建議的做法，成的機率難料，也可能留有後遺症（造成事事計較的負面印象）；萬一不成，到手的機會也許也不一定抓的牢。

您列出的三項，不是需要擇優的選項，更像是三種情境、面向，互不衝突，也不會同時發生，但是都該考量。 1. 跳槽。先問自己要追逐的目標為何，現有環境的養分還夠不夠，適應新環境勝算還行嗎？其實不管是換工作或換公司，對職涯發展來說，都再正常不過，有好機會就把握。噢，別只看薪水，職能成長最為重要的。 2. 爭取主管職位。如果公司的文化，是由技術能力強的當主管，那該做的和第1項差不多，先問問現在成長的環境好不好，自己夠不夠努力？實力未到，想爭取也是不容易。重點在於不斷追求卓越，這才是不把路走窄的關鍵。記得同時培養自己的Leadership. 如果公司重視在工程背景外，還要加上管理能力，那就多吸收多學習吧，同時發展這兩種能力。一般來說，若真要需擱置技術能力成長，好更專注於管理職能，這樣的分水嶺，大致出現在十年以上資歷，通常會是位於組織裡第二層以上的主管，近期應該不需為此操心。 3. 轉職 PM。這可是換跑道啊，好壞難料，先問問自己，對這角色有沒有熱情再考慮，因為沒有工作是不辛苦的。其實工程背景轉行選擇不少，何止PM，當業務能更了解產品，當FAE能更理解客戶等，但這些都不該是換跑道的主要理由，每一種專業都要耕耘才有收穫，別幻想靠工程背景就能輕鬆應付。 共勉

試著這麼想，自動化測試的目的是什麼? 引入自動化測試，是否有助於讓產品品質驗證的過程，變得快一些、好一些、省一些? 如果這些影響都是正面的，自動化對於測試工作，則幾乎是必然的選擇，對嗎？ 自動化測試會完全取代人工嗎? 短期內應還不至於，由其是需要深度思考的測試方案設計，不只是驗證該有的功能都有，更要防範不該有的異常都能被攔下來。但是，關於測試的執行，在趨勢上非自動化的比例，的確只會越來越少。 有危機意識，非常值得鼓勵，這是進步的動能。管控ODM，不常執行測試工作，不見得是退化，重點還是要看個人的價值在那裡。若只是安排人力、資源、時程，要警惕能力的成長，是否在一段時期後遭遇瓶頸。若走驗證的技術職涯，可多涉獵 Validation Architect 職能。若走計畫管理的技術職涯，可多跨界延伸到(design quality相關的)Quality PM職能，或是(manufacturing quality相關的)NPI PM之類的職能。若走管理職涯，得多充實人事管理、組織管理、Leadership 相關職能。 共勉

主管的心態的確該改，但可能不是您原先想的 "調適"。 除非是只掛名但不需擔負責任的閒差，要不然 "選/育/用/留" 是當一個主管的份內職責。員工離職要看成常態，就像組織的新陳代謝一般，接著就是招募、培育、適才任事的新循環，這些都算主管的日常工作，該要認分的做好。寄望員工永不離職，以減輕主管工作負擔，基本上不切實際。 離職的個案大多數不是問題，但高離職率則是該被檢討的問題。如果公司裡的其他團隊相對穩定，如果前朝主管任內員工相對穩定，如果組織在前些年比今年穩定，那主管是不是該設法找出原因、並提出改善方案? 心態上別說 "留不住人也不是我的問題呀，為什麼都要檢討主管呢？" ，建議要改成當責心態，早點戒除這種 "打工仔主管" 的想法。 如何當責? 如果是公司環境面的因素，試著向上層建議改革；如果是部門間協同作業的困擾，要帶頭溝通；如果是組織內部規範未能與時俱進所造成，該領導改變；如果是員工觀念不正確，自然是強化教導的工作。如果是員工無法適任導致，經輔導後仍成效不彰，祝福他就好。 拉高一個層級來看，評量部門的重點還是在於運作的績效，也就是看產出與交付的品質、效率、成本，主管得讓 KPI 愈來愈好。至於人員的異動，並不見得一定是壞事，有時反而成為推動革新、讓部門產出更好績效的契機。(當然啦，若因缺工導致產出低落，要做危機處理。) 相對的，若只一味追求人員穩定不離職、組織安定，短期內的確能讓運作順暢；但長期來看，則要小心運作績效成長停滯，這可是部門主管會遭檢討的大麻煩。 共勉

可以理解您辛苦了，但試著超越自己，不執著於直覺的反應，改用不同視角看職場問題，常常能有更多收穫。 1. 您可知道，一位主管，面對專案計畫進度延遲，會做些什麼? 肯定要找 "相關" 同仁們檢討改善，但也許是採個別面談的方式。您感受到的片面責難，不見得是全貌，因為此種情形下， Project PM 若並不被要求改進，只能說是業界罕見的個案吧 (意思是，不太合理，在正常情形下不太可能)。 2. 計畫執行靠團隊合作，每個成員除了完成自己責任範圍，還要相互照看，提醒夥伴們注意問題。甚至於緊急時，即使不屬自己職則，只要能幫助到成果順利產出，仍需主動補位協助夥伴。這個重要觀念叫做 "當責" ，Accountability。想想棒球比賽裡，游擊手與內野守備員的合作，不難理解勝率高的團隊該怎麼互動。不要過於關注，"不公平、我吃虧了" 這些情緒。 3. 且撇開廣義的職責不談，單獨看份內工作，身為 Product PM，把產品規格 "移交" 給 Project PM，就已經完成任務? 產品需求定義，是專案計畫成功的基石，其質量要求沒有最高只有更高。若陳義過高、不盡合宜，或是含糊籠統，後續執行風險也高。要在市場競爭力、與專案執行力之間，取得平衡，永遠是項挑戰，需不斷取得回饋淬鍊。給您一個建議，放棄 "移交" 這種觀念，很深入地探索，您開立的 Product Specification ，在後續專案開發中，是怎麼被應用的。這將有助於您建立 Lesson Learnt 循環，持續提升專業能力。 共勉

現職是約聘，通常得採騎馬找馬策略，別放棄更好的機會。只是，機會要多久才會來 (拿到正職 Offer Letter) ，誰也不知道，所以現在就可以開始搜尋。 目標若是 Architect，光學會怎麼用 Cloud Service 可能是不夠的，不論您學會多少種，這些技術的進入門檻並不算高。(話說回來，您不妨注意一下那幾種 Cloud Service 的市占率，這通常也意謂著工作機會的多寡) 那麼高檔次的架構工程師，該具備什麼本事? 想想，如果要在 AWS / Azure 做選擇，利弊得失 (Trade-off) 怎麼比較? 如果要保留擴充性，讓服務於未來可同時架在三大家雲服務上，系統 Layer 該怎麼切割 (可參考 Agile DIP 原則)，框架(Framework)要怎麼設計 (可參考 Architecture Design Pattern) ? 如果要把 OT 端 Edge Computing 接軌到雲端服務，Solution Architecture 有哪些 (可參考 Enterprise IOT) 如果要再加入 AI training / inference 之類當紅的應用，流量、運算能力的瓶頸會在哪裡? 總結來說，入門端重在應用 (現有的 API 或 Open Source)，可以從訓練開始；專家級更著重於解決非功能性需求 (non-functional requirements) 帶來的挑戰，也就是靠架構來處理軟體裡 -itilities 的問題。(以上這些關鍵字，在網路上查詢，都有豐富資源。) 您顯然是會思考的人，近40年的職涯很長，若能早些知道未來要去哪裡、要接受那些挑戰，對於路徑的選擇，應該會越來越清晰。(相對於您的目標，輕易放棄知名 SI 的歷練機會，從宏觀角度來看，有些可惜，下次可要慎思。) 祝 順利

常常聽到新手主管有類似困擾，員工不主動積極怎麼辦? 成因很多元，建議要先仔細觀察評估，別急著下結論。有不小的機率，在於主管做得不夠好。(終究，主管有考績的生殺大權在手，甚至可淘汰不適任員工。) 通常先評估，員工的績效表現，是否與其職等相符? 主管(您)的期待，是否與員工的職等相符? 比方說，要求資淺的助理，要能應付困難的突發危機，或者從不顯眼的數據中看出潛在風險，自然有些困難。這時員工不是不為，而是不能。先弄清楚是意願的問題，還是能力的問題。 若表現不完全符合期待，該優先套用的模型，是"績效管理"，先別管什麼態度是否積極，也別談什麼專業尊重。務必讓員工非常清楚的知道，做得不夠好的地方到底在哪裡，要達成什麼明確事項才叫及格。其實許多員工的管理問題，主管也要攤上很大的責任，最常見的就是主管把 "期望 (Expectation)" 說得抽象含混模糊，甚至沒說。若只是內心希望員工"主動"，即使主管不說也能察言觀色，知道該做什麼，這有些屬不切實際的期待。舉例來說，可以要求員工於呈現數據、繪製表格時，每頁一律分析解讀並論述。沒依照 SMART 準則，說清楚什麼叫 "主動"，主管自己要加油；員工沒依照要求解讀數據，這叫摸魚打混；寫出來的分析不夠精闢，這是程度不足猶待學習。 相對職能未達能自主放飛程度(Delegation Mode)的員工，其產出績效的關鍵，主要在於主管指揮是否足夠精實(符合PDCA模型)。主管先說清楚期望，接下來的責任，則是提供支持(例如經常指導、回饋)，積極協助員工改善績效。 若表現符合其職等的期待，有交辦都能做好，那就可以來研究為何 "意願消極"。有時侯是老兵現象，同樣的事做久了生煩，給些新差事，就會有很大改變。有時候是環境面的問題，例如升遷不公、賞罰不分、缺乏挑戰、文化不佳、勞逸不均、下情難以上達...等，主管得探索並設法改善。 若表現超越其職等的期待，則是組織的寶藏資產，尊重、授權，不必太介意 員工個人 "積極" 這面向。但仍然要定期做職涯面談，不要總視為理所當然。至於團隊整體是否積極，通常靠主管主動推動，這也經常背當成管理職人員的 KPI。主管的價值，在於提升團隊產出績效，發展員工職能。遇到主動稱職的團隊，只能說是運氣好，不能當作管理能力好。 照說，您這一階管理 (First-Line Management) 的問題，非常典型，應該會優先請益您的上階主管，而提問的內容，多半是執行您主管建議時，所遭遇的困難才對。據此大膽假設您的組織，因是新創部門，管理的資源也許不那麼充足，所以多說了些道理，嘮叨了些，尚請海涵。惟此處篇幅有限，多看看些管理書籍，將能對團隊運作模型，早些建立正確認知。

重新梳理一下您的描述，您目前的工作相對單純，只要靠自己一人之力，即可完成上級交付的任務，最近得到了一個新的"機會"，未來預計工作範圍擴大，需指揮2-4人，共同完成較複雜的任務。通常這種角色，稱做 Technical Leader。另外，您同時得到了另一個"機會"，負責經營管理 2-4 人的小組織，缺人時要找人，平時要教導培育新進，考評他們的績效，並督促團隊做出最大貢獻。通常這種角色，稱做 Team (People) Manager。而您覺得伴隨這兩個"機會"而來的挑戰太大，也曾看過些失敗的前例，索性以個性不適合為理由，傾向選擇留在現有舒適圈，放棄這 "機會"。 有沒有出息，屬於情緒化的標籤，且先擱置。但要緊的是，您有沒有熱情在技術職涯 (Technical Track) 上，從目前的資深工程師，歷練成長為主任工程師 (或技術經理之類的職稱)，還是打算從此原地踏步? 另外，您想不想擴充範圍，含括管理職涯 (Mangerial Track) ，學習對後進的選育用留能力? 的確，即使有熱情，相對的能力不見得很快能跟上，就會像許多先例一樣，遇上一段蠟燭兩頭燒的瓶頸。但如果熱情不夠，遇到挫折很容易選擇打退堂鼓，導致前功盡棄。所以，先讀上述說明，充分理解這機會是什麼，在意識清楚的情境下，做出自己的決定。如果決定接受挑戰，請先相信若一時做不好，只是能力還沒到位，保持謙虛歷練學習、並咬緊牙關堅持就對了，成功的先例當然不在少數。當你學會情境領導、有效授權，就可望脫離兩面不討好的壓力鍋。 另外有個建議，如果因為個性不想接管理職，或許可以找您的主管討論，先只擔任技術職的 Technical Leader，但暫不接任 Team Manager? 跨度縮小，挑戰也變得比較有把握克服。 許多公司支持 Dual Track Career Development, 在技術職上一路做到 總工程師 或 Chief Architect 或 CTO，也挺不錯的啊。事實上，先成為一個成功的 Leader，再轉任 Manager，這條職涯的路將會平順得多。 完全拒絕這些"機會"，也不算是什麼罪惡，不過是您在 Work-Life Balance 上做的選擇而已。但請同時想想，在 Life 這一頭，是否要加碼些什麼。 如果只在 Work 這端單方面退縮，生命的精彩度上來看，也許有點可惜。 共勉