履歷重構暨面試技巧

技術專案經理轉管理職,如何補上授權與衝突處理的證據

首頁 / 案例 / 技術專案經理轉管理職,如何補上授權與衝突處理的證據

本篇為去識別化的方法示例,人物、產業細節與數字皆經改寫,不代表成果保證。委託人是一位在軟體公司擔任技術專案經理約八年的工作者,連續投遞部門主管職缺,進到面試卻總在第二關止步。以下用對話還原的方式,呈現我們怎麼找出他其實早就做過、卻從沒說出口的管理證據。

委託前:履歷上全是交付,看不到帶人

某位技術專案經理來找我們時,帶著一份內容紮實的履歷:主導過多個系統上線、管理過數百萬元的專案預算、準時交付率很高。問題是,他應徵的是研發部門主管,而招募方的回饋幾乎一樣:「專案能力很好,但看不出管理團隊的經驗。」他很困惑,因為他每天都在跟工程師、設計師與業務協調,怎麼會沒有管理經驗?

我們讀完履歷後發現,他所有的成果句主詞都是「專案」,而不是「人」。例如「帶領跨部門團隊如期完成系統改版」,這句話讀起來是專案管理,招募方無法判斷他在其中是否分配過工作、是否處理過績效問題、是否曾在衝突中做出取捨。對主管職來說,這些才是核心能力。

真正的問題:他把管理行為歸類成了「協調」

真正的問題不是缺乏經驗,而是他把自己做過的管理行為,全部歸類為專案經理的協調工作,所以寫履歷時自動略過。技術專案經理通常沒有正式的人事權,他們習慣說「我只是協調,不是主管」,這種謙虛在同職位轉換時沒問題,但要升到管理職時,就會讓關鍵證據消失。

我們在第一次文字訪談中問他:「你有沒有遇過某個工程師進度一直落後,而你必須處理的情況?」他回答:「有啊,但最後是他的主管處理的。」我們追問:「那在他主管介入之前,你做了什麼?」他想了一下,才說出他曾經把那位工程師負責的模組拆成兩半,一半交給另一位資深工程師,並且每天花十分鐘跟落後的那位對進度。這就是授權與績效介入,只是他從沒這樣稱呼它。

介入步驟:用四種情境問題挖出事件

為了系統性地找出證據,我們設計了一組情境問題,請他針對過去三個專案逐一回答。每題都要求他寫出當時的具體人數、時間與結果,不接受「通常」「一般來說」這類概括回答。

  1. 授權:有沒有哪件事你原本可以自己做,卻刻意交給別人?你怎麼挑人、交代到什麼程度、何時檢查?
  2. 衝突:有沒有兩個人或兩個部門意見相左、需要你做決定的時候?你聽了哪些資訊、最後怎麼決定、誰不滿意?
  3. 績效:有沒有人表現不如預期?你在什麼時點發現、先做了什麼、有沒有升級給他的主管?
  4. 培養:有沒有人在你的專案裡被你帶起來?他原本做不到什麼、後來做得到什麼?

這一輪下來,他寫出了十四個事件。我們再用三個標準篩選:他本人是否做了關鍵決定、事件是否有可觀察的結果、他是否願意在面試中被深入追問。最後留下五件,其中兩件授權、兩件衝突、一件培養。

交付物:證據句與可以講八分鐘的故事

交付物分成兩部分:改寫後的履歷,以及五個事件的面試故事稿。履歷上我們在每段經歷的前兩條,加入以人為主詞的成果句;故事稿則依照情境、判斷、行動、結果、反思五段寫成,每則約可講三到八分鐘,並附上面試官可能的追問與回應方向。

  • 授權證據句範例:「將支付模組拆分交由兩名工程師分工,建立每日十分鐘進度確認,原本落後約三週的時程在一個月內追回。」
  • 衝突證據句範例:「在設計與後端對資料格式爭執兩週後,召集雙方以使用情境逐項評估,決定採折衷方案並書面記錄理由,後續未再出現同類爭議。」
  • 培養證據句範例:「帶領一名初階工程師從只負責單一功能,到半年後獨立負責一次小型版本上線。」

我們特別在故事稿中加入「如果重來會怎麼做」的段落。管理職面試官很在意反思能力,一個只講成功、不講失誤的故事,聽起來像背稿。他在衝突事件中承認,自己當時拖了兩週才介入,太晚了,這段反而成為面試中最被肯定的部分。

模擬面試時,我們以文字方式扮演面試官連續追問。第一輪他講授權故事講了不到一分鐘就結束,因為他習慣只報告結果。我們請他補上「為什麼挑那位資深工程師而不是另一位」,他才說出自己考慮過對方手上的工作量、對該模組的熟悉度,以及兩人過去合作是否順利。這段選人的判斷,正是管理職面試官最想聽的東西。練習三輪之後,他能在追問下自然補出決策理由,而不是臨時編造。

過程中的取捨:沒有人事權的事件要怎麼說

最大的取捨在於措辭分寸。他沒有正式的考核權,如果履歷寫「管理五名工程師」,面試官一查證就會發現不符,反而傷害信任。我們最後的原則是:寫實際做了的行為,不寫沒有的職權。例如寫「分配工作並追蹤進度」,而不是「直屬管理」;寫「向其主管提出調整建議並獲採納」,而不是「進行績效考核」。

另一個取捨是刪減技術成果。原履歷有大量系統架構與工具的描述,這些對技術職很重要,但對管理職是次要資訊。我們刪掉約三分之一的技術細節,他一開始很不捨,覺得那是自己最驕傲的部分。我們的說法是:技術深度可以在面試中被問到時再展開,履歷的篇幅要留給招募方最不確定的那件事。

事後可以回頭檢查的驗收點

履歷重構的成果很難用單一數字衡量,所以我們在交付時就列出幾個可以自行檢查的驗收點,讓委託人在後續投遞中判斷方向是否正確。

  • 面試中被問到的問題類型是否改變:從技術與專案流程,轉向帶人與決策。
  • 第二關面試是否能完整講完至少兩個管理故事,而不是被中途打斷改問技術。
  • 招募方回饋中是否仍出現「看不出管理經驗」這類評語。
  • 投遞的職缺中,進入第二關以上的比例是否比過去提高。

他在後續兩個月的面試中回報,問題明顯轉向團隊管理與衝突處理,而且他能在被追問時說出具體人數與時間,不再支吾。這些是他個人的經驗,是否錄取仍取決於職缺條件、市場時機與其他候選人,不能把結果歸因於單一文件。

從來沒帶過人時,改寫救不了你

挖掘隱藏的管理證據有前提:你必須真的做過那些事。如果過去的角色完全是個人貢獻者,從沒分配過工作也沒處理過人的問題,那麼再怎麼改寫都只是包裝,面試一深入就會露餡。這種情況下,比較誠實的路徑是先在現職爭取帶小型專案或帶新人的機會,累積半年到一年的實際事件再轉換。

另外,若目標職缺是大型組織的高階主管,需要的是預算、組織設計與人才策略的證據,單靠專案層級的授權與衝突事件並不足夠。銘望顧問所的履歷重構服務會在第一次訪談就判斷差距屬於「有事件但沒寫出來」還是「根本還沒有事件」,前者可以改寫,後者則需要先誠實面對時間。

← 回到案例總覽

補充閱讀:以下內容用於說明本案例的判斷邏輯、交付方法與適用限制,不代表任何特定人物、企業、物件或職缺的保證結果。

後續追蹤:先確認變化,再決定要不要擴大

完成「技術專案經理轉管理職,如何補上授權與衝突處理的證據」的第一輪處理後,我們不會立刻把所有資源投入同一個方向,而是安排一個短週期回看。回看時只問三件事:原本要解決的問題是否變得更清楚、使用者是否能按照文件完成下一步、哪一個假設最容易被新資料推翻。若三題中有一題沒有答案,就把它列為下一輪的主要工作,不用用更多宣傳文字掩蓋。

追蹤表會把訊號分成領先指標與結果指標。領先指標可能是詢問內容變得具體、文件往返次數下降、面試回答能對應職缺要求,或團隊開始主動提供缺少的證據;結果指標則必須依案件目的另行定義,不能因為瀏覽量、詢問量或一次成功就直接推論長期成效。所有指標都要寫出觀察期間與限制。

如果結果沒有如預期,先回到問題定義與資料品質,不先責怪執行者。可能是條件尚未成熟、責任邊界不清、來源不完整,也可能是原本選錯了比較對象。能夠清楚說出「目前不知道」與「下一個怎麼查」,本身就是可靠交付的一部分。

後續若要擴大,先選一個最小範圍做對照,明確記錄開始時間、適用對象與停止條件。若沒有對照,就不能把同一期間的自然變化全歸因於本案。若需要外部平台、第三方資料或個人敏感資訊,也要先確認權限與保存期限,不以繞過登入或擴大蒐集來換取方便。

本案保留了可停止、可修改、可重新啟動的節點,讓決策者可以在新資訊出現時保有選擇權。這也是銘望顧問所處理案例時的基本原則:不製造無法驗證的承諾,先把現況、限制、證據與下一步說清楚。