前言#

New engineering managers think of the job as a promotion, giving them seniority on engineering tasks and questions. This is a great approach for ensuring they remain junior managers, and unsuccessful leaders at that. It’s hard to accept that “new manager” is an entry-level job with no seniority on any front, but that’s the best mindset with which to start leading. — Marc Hedlund

恭喜你晉升到管理職！你可能已經從 HR 那裡接受了一些管理基礎培訓，也可能有過去優秀的主管可以效法。但現在理論要付諸實踐了。

本章聚焦在管理個別成員。作者的目標是提供管理的基本要素。當你坐上管理職的位置，應該如何思考管理人的基本任務？

在適應管理角色的過程中，你需要找到自己的管理風格。許多人在學習管理個人的同時，還要負責帶領整個團隊。下一章會更多談論團隊層面的挑戰，但重要的是先從個別成員開始——畢竟，你的團隊健康與否取決於每一位成員，而身為直屬主管，你對每個人都有巨大的影響。

管理人的主要任務包括：

• 接手一位新的直屬部屬（direct report）
• 定期舉行一對一會議（1-1）
• 就職涯成長、目標進度、需改進之處與值得表揚之處給予回饋
• 與部屬共同識別學習領域，透過專案工作、外部學習或額外指導幫助他們成長

立即開始新的回報關係#

成為管理者後，首先面對的就是接手直屬部屬。他們可能是你合作已久的人，也可能是完全陌生的人。在管理職涯中，你會反覆經歷新人加入你的團隊。如何快速了解一個人，以便最佳地管理他？

建立信任與默契#

一個策略是提出一系列問題，幫助你了解影響管理品質的個人特質。這些問題可能包括：

• 你偏好公開還是私下被表揚？ 有些人非常討厭在公開場合被表揚，你需要知道這點。
• 你偏好什麼方式接收嚴肅的回饋？ 你喜歡書面回饋以便消化，還是比較能接受非正式的口頭回饋？
• 你為什麼決定來這裡工作？你對什麼感到興奮？
• 我怎麼知道你心情不好或感到煩躁？有什麼事情總會讓你心情不好？ 也許部屬因宗教原因禁食而有時會暴躁，也許他每次 on-call 都會特別焦慮，或者他討厭績效評估季。
• 有沒有你特別討厭的主管行為？ 作者的回答是：跳過或重排一對一會議、疏於給回饋、迴避困難的對話。
• 你有沒有什麼明確的職涯目標是我該知道的，好幫你達成？
• 入職以來有沒有什麼讓你驚訝的事，好的或壞的？ 例如：「我的 stock options 在哪裡？」「說好的搬遷獎金還沒拿到」「為什麼我們用 SVN 不用 Git？」「沒想到自己這麼快就能上手！」

技巧： 更多問題靈感可參考 Lara Hogan 關於此主題的部落格文章。

制定 30/60/90 天計畫#

許多有經驗的管理者會幫助新部屬制定 30/60/90 天計畫。計畫可以包含基本目標，例如熟悉程式碼、修復一個 bug，或執行一次 release。這對新進人員和從公司其他部門轉調的人特別有價值。

• 越資深的人，越應該參與計畫的制定
• 設定清楚的目標，以確認他是否在學習正確的事情
• 這些目標也需要你和團隊的配合，因為很少有東西對新人來說是不言自明的

重點： 有時候你會招錯人。為新人制定一組你認為 90 天內可以達成的預期目標，能幫助你快速發現招聘錯誤，並讓你和對方都清楚需要修正。根據過去的招聘經驗、目前的技術狀態與專案需求、以及新人的級別，制定一套實際的里程碑。

鼓勵新人更新入職文件#

對初階到中階的新進人員，入職過程的一環應該包括為團隊的入職文件做出貢獻。許多工程團隊的最佳實踐是建立一套入職文件，每位新人在熟悉環境的過程中進行編輯，反映自上次招聘以來已更改的流程或工具，或標注他覺得困惑的地方。身為主管，你不一定需要親自帶新人走過這個流程——那可以交給同僚、mentor 或 Tech Lead——但你可能需要建立這個流程，並確保每位加入團隊的人都執行它。

傳達你的風格與期望#

新人需要了解你的期望和風格，就像你需要了解他的一樣。你們彼此都需要做一些調整，但如果新人不知道你期望什麼，他就無法交付該交付的東西。你的期望設定應包含具體事項，例如：

• 你們多久見一次面
• 你們如何分享資訊
• 你多常、何時想要檢視他的工作
• 如果你期望他每週透過 email 發送進度摘要，直接告訴他
• 幫助他理解他應該獨自解決問題多久，在什麼時候該求助（有些團隊是一小時，有些是一週）

從新人身上獲取回饋#

最後一個建議：在前 90 天盡量收集新人對團隊的回饋。這是一個罕見的時期，新人帶著新鮮的眼光進來，往往能看到資深團隊成員難以察覺的問題。但也要記住，處於前 90 天的人缺乏團隊整體的脈絡，所以對他們的觀察要有所保留，而且絕對不要鼓勵他們以讓現有團隊感到被攻擊的方式批評既有流程或系統。

與團隊進行溝通#

Regular 1-1s are like oil changes; if you skip them, plan to get stranded on the side of the highway at the worst possible time. — Marc Hedlund

定期舉行一對一會議#

作者曾與一位同樣擁有豐富管理經驗的 CTO 朋友交談。這位朋友不好意思地承認他不喜歡做定期一對一，因為他自己過去一直覺得被迫和主管做一對一很沒必要。他說：「定期一對一就像你沒事去看精神科醫生，然後被診斷出你有憂鬱症。」

作者承認每個人和每個團隊都不同，需要不同的溝通方式。但如果你不是一位有多年管理經驗的 CTO，你最好先假設自己需要做定期的一對一會議。

排程一對一會議#

一對一的預設頻率是每週一次。作者建議從每週開始，只有在雙方都同意這比需要的更頻繁時才調整。每週的好處：

• 談話頻率足夠高，會議可以保持簡短而聚焦
• 偶爾錯過一週也有緩衝空間
• 如果頻率更低，任何錯過的一對一都必須重新安排，這通常對雙方都是負擔

排程建議：

• 盡量安排在雙方都可能在辦公室的時間
• 避免週一和週五，因為人們常會請長假而錯過
• 作者偏好在早上開會，避免因其他事務導致排程延誤
• 尊重部屬的 Maker’s Schedule（創作者時間表），不要把一對一安排在他們最有生產力的工作時段中間

調整一對一會議#

一對一不是「設定好就忘了」的東西。需要考慮的因素包括：

• 你跟這個人平時互動的頻率如何？ 如果你們經常非正式互動，可能不需要每週的固定時間。
• 這個人需要多少指導？ 剛加入團隊的初階成員可能需要更多時間；但正在推進困難新專案的資深成員也可能需要更多的專注時間。
• 這個人主動向上傳遞資訊的能力如何？ 不擅長向上傳遞資訊的人可能需要更多面對面時間。
• 你和這個人的關係好嗎？ 要小心——有些人假設好的關係不需要太多關注，把所有時間花在問題關係上。但許多人（包括作者自己）即使在良好的關係中也強烈需要定期一對一。不要犯把所有時間花在問題員工身上而忽略明星員工的致命錯誤。
• 團隊或公司目前的穩定程度如何？ 在快速變化或不確定的時期，確保你花時間回答團隊的問題。在不確定時期保持一對一的規律性有助於穩定團隊並減緩謠言的傳播。

不同的一對一風格#

一對一安排好了，但實際該怎麼用？作者見過幾種不同的風格，最有效的類型取決於主管和部屬雙方。

待辦清單會議（The To-Do List Meeting）#

一方或雙方帶著一份要討論的議題清單，按重要性順序逐一處理。提供更新、做出決策、進行規劃。

優點： 遵循「不浪費時間開無意義會議」的原則，確保事情會被推進。也迫使部屬事先思考要討論什麼。一位作者認識的主管使用共享的 Google 試算表，雙方隨時加入議題，在一對一時逐一檢視。

缺點： 有時候會讓人懷疑為什麼需要同步溝通。清單上的東西可能很多都能透過即時訊息或 email 處理。如果採用這種風格，確保清單上的議題確實值得在一對一中口頭溝通。

整體而言，這種風格非常專業且高效，但有時稍顯冷淡。

隨興聊天（The Catch-up）#

作者偏好較流動的風格。她的目標是先傾聽部屬想討論的任何事情，讓會議由對方驅動，給他們空間帶出他們認為重要的話題。她把一對一視為一場創意討論，也是一場規劃會議。

風險： 如果不加以控制，隨興的一對一可能淪為抱怨大會或心理治療。有同理心的領導者有時會讓自己陷入與直屬部屬之間不健康的親密關係。如果你花大量精力聽部屬的抱怨並感同身受，你很可能在讓問題惡化。你不需要有待辦清單，但工作場所的問題需要被處理或被雙方同意擱置，反覆聚焦在八卦與戲劇性事件上幾乎沒有價值。

回饋會議（The Feedback Meeting）#

有時一對一會專門用於非正式回饋與指導。定期舉行此類會議是好的，特別是對初階員工。每季度一次的頻率足夠，不至於讓人覺得你們只在談職涯發展。許多公司會強制執行個人目標設定流程，你可以用這個時間檢視目標進度。

• 對有績效問題的員工，回饋會議應更頻繁
• 如果你正考慮解雇某人，建議記錄這些回饋會議的內容，包括討論的議題和設定的期望，以書面形式（通常是 email）發送給對方

重點： 當有人做了需要立即糾正的事情（侮辱同事、錯過關鍵會議、使用不當語言），不要等到一對一才給回饋。盡快在事發後找到這個人。等得越久，你越難開口，回饋的效果也越差。表揚也是同理——當事情進展順利時，當下就給予讚美。

進度報告（The Progress Report）#

當你管理的是管理者時，許多一對一會是深入他們負責但你沒時間親自了解的專案細節。但如果你只管幾位個別成員，唯一應該用一對一做進度報告的情況是：有人在做一個你沒有親自督導的旁支專案。

如果你們已經密切合作，從他那裡獲取進度報告只是在浪費時間——你聽到的不過是上次站會或專案回顧以來的差異。如果你的一對一經常變成狀態更新，試著要求部屬準備與目前專案狀態無關的問題，或請他們帶問題來問你關於團隊、公司或其他任何事情。對那些真的沒什麼好談的人，可以將此視為減少見面頻率的訊號。

認識你的部屬#

無論你用什麼風格的一對一，留出空間把部屬當作一個人來認識。不是要你窺探他們的私生活，而是展現你關心他們作為個體。讓他們聊聊家人、朋友、嗜好、寵物。了解他們的職涯歷程，問問他們的長期職涯目標。不必只聚焦在下一個技能或晉升，而是展現你願意投資幫助他們——現在和未來。

變換一下#

為了變化，你可以把一對一變成散步會議，或在咖啡廳、午餐時進行。但記住，不做筆記時你可能會忘記重要事項，所以盡量不要依賴這種方式進行關鍵對話。盡可能在私密空間進行一對一，以便自由討論敏感話題。

技巧： 在共享文件中保留筆記，由主管擔任記錄者。為每位部屬維護一份一對一的紀錄文件，包含筆記、要點和待辦事項。這有助於保持脈絡、記住何時給了什麼回饋，也是撰寫績效評估或提供回饋時的重要歷史紀錄。如果會議時打開電腦會讓你分心，就在結束前留時間補充筆記。

好主管、壞主管：微觀管理者 vs. 委派工作者#

Jane 把一個大型專案交給她的 Tech Lead Sanjay 管理，月底前要完成。Jane 擔心時程會延誤，於是開始參加她平常不去的所有站會，直接向團隊成員詢問他們的阻礙。她檢視專案票據並大量留言，甚至重新指派了一些給其他團隊成員。當她發現 Sanjay 和產品經理決定降低某個功能的優先順序時，Jane 決定接手這個專案，告訴 Sanjay 從現在起她來管理日常事務。

結果毫不意外：儘管專案成功交付，Sanjay 告訴 Jane 他不想再當 Tech Lead 了。他變得無精打采，原本的投入和努力被提早離開和會議中沉默所取代。她最好的團隊成員在一夜之間變成了低績效者。

再看 Jane 的同事 Sharell。Sharell 把 Beth 的第一個大專案交給她管理。Sharell 知道這個專案必須準時交付，但她沒有坐進每場會議、追蹤每個細節，而是和 Beth 一起決定 Sharell 應該參加哪些會議，並幫助 Beth 理解哪些細節需要向上報告。有了這種支持，Beth 有信心地推進專案，也知道 Sharell 在她身後撐著。當專案接近尾聲壓力增大時，Beth 主動尋求 Sharell 的幫助來縮減範圍，讓專案準時交付。Beth 帶著更強的信心離開這次經歷，準備好承接更大的專案。

微觀管理的問題#

Jane 和 Sharell 的決策突顯了微觀管理者和有效委派者之間的微妙差異。兩人都試圖將高優先級專案的管理權委派出去以培養新領導者，但 Jane 最終從未放手，反而削弱了 Sanjay；Sharell 則清楚告訴 Beth 目標和職責是什麼，並提供支持和指引幫助她成功。

微觀管理會悄悄地蔓延。一個不能延誤的高壓專案看似有風險，你就介入修正。你委派了某件事，卻發現不喜歡團隊選擇的技術方案，所以叫他們重寫。你強迫所有人在做決定前先來找你，因為他們「就是不能被信任做對的事」。

微觀管理最困難的地方在於，有時候你確實需要這麼做。初階工程師在細節監督下往往表現得更好，因為他們需要那種具體的方向。有些專案脫軌了，你偶爾需要推翻部屬可能帶來重大負面後果的決策。但如果微觀管理是你的習慣、是你帶團隊的預設模式，你最終會像 Jane 一樣，意外地削弱你本該培養和獎勵的人。

信任和控制是微觀管理的核心問題。如果你在微觀管理某人，很可能是因為你不信任任務會被正確完成，或者你想嚴格控制結果以符合你的精確標準。這在優秀工程師轉任管理者時尤其常見——當你的價值從你擅長的事（寫程式）轉移到你還不知道如何做好的事（管理人）時，很容易把部屬當作你的分身。

自主性（autonomy）是動機的重要元素。這就是微觀管理者難以留住優秀團隊的原因。當你剝奪有創造力和才華的人的自主性，他們會迅速失去動力。沒有什麼比覺得自己不能做任何獨立決定、每一項工作都要被主管反覆檢查更糟糕的了。

注意： 委派不等於放任（abdication）。當你委派責任時，你仍然需要在必要時參與以幫助專案成功。Sharell 並沒有拋棄 Beth——她幫助 Beth 理解新角色的責任，並在需要時提供支持。

透過建言有效委派#

身為好的領導者，意味著擅長委派。以下是幾個實用的建議：

用團隊目標決定該深入哪些細節#

當你想微觀管理時，問團隊他們如何衡量成功，並請他們持續讓你看到這些指標。然後忍住手，等一兩週看他們給你什麼。如果他們什麼都沒有分享，那是你可能需要修正方向的訊號，大概意味著要深入更多細節。

作者的哲學很簡單：如果團隊在目標上有進展、系統穩定、產品經理滿意，她很少會深入細節。但這需要有清楚的目標和進度計畫，以及能提供另一角度的產品經理。如果你管理的團隊沒有清楚的計畫，用你想監控的細節幫他們建立一個。你這個月、這一季、今年拿什麼來要求他們負責？如果你回答不了這個問題，第一步是幫團隊建立那些目標。

先從系統收集資訊，再找人問#

身為工程師，我們有一個優勢：系統可以自動推送有價值的資訊。如果你想知道工作狀態，看版本控制系統和票務系統。如果想知道系統有多穩定，訂閱告警、看指標、追蹤 on-call 發生了什麼事。

注意： 最糟糕的微觀管理者是那些不斷索要自己可以輕易取得的資訊的人。可以要求狀態摘要，也可以讓團隊幫你從各種來源篩選最重要的資訊，但要輕柔地觸碰。團隊不會因為花一半的時間幫你收集你自己就能找到的資訊而感到開心或高效。而且記住，這些資訊只是脈絡的一部分，不是全貌，沒有前面討論的目標就毫無意義。

根據專案階段調整關注焦點#

如果你直接管理一兩個團隊，你應該在日常團隊流程（如每日站會）中了解所有專案狀態。不同的細節在不同的專案階段很重要：

建立程式碼和系統的標準#

作者是那種深入技術的管理者，對系統該如何建構和運維有自己的見解。放手對她來說很難，所以她制定了一些指引來幫助自己安心。團隊共同制定基本標準有助於在 code review 和設計審查中溝通，也能去個人化提供技術回饋的過程。

例如：

• 每次變更預期要有多少 unit test
• 技術決策在什麼時候應該由更大的群體審查（例如有人想新增語言或框架到技術棧）

如同設定目標，建立標準幫助人們知道在創造技術時哪些細節是重要的。

以中性到正面的態度對待資訊公開分享#

設想這個場景：Jack 在一個專案上遇到困難，但沒有主動求助。你終於聽說了他的掙扎。

此時，你可以告訴 Jack 他需要更主動地分享進度，即使這意味著承認自己在掙扎。你可以要求 Jack 每天向你更新作為幫助手段，但建議只短期使用這種高度結構化的做法。目標不是用微觀管理來懲罰他未能溝通狀態——那只是在懲罰你自己並妨礙他為自己的工作負責。你的目標是教會 Jack 他需要溝通什麼、何時溝通、如何溝通。

注意： 如果你把一位掙扎中的工程師或專案視為個人或管理者的重大失敗，對方會感受到那份責備和批評。她不會在未來給你更多資訊，反而會繼續對你隱瞞，以避免被責備，直到為時已晚。刻意隱瞞重要資訊是一種失敗，但卡在問題上或犯錯通常只是學習的機會。

學會放手#

長遠來看，如果你不學會放手、委派和信任團隊，你個人會受害。即使團隊不離職，隨著責任增加，你會工作越來越長的時間。如果你已經處在這種狀況，試著限制自己每週的工作時數。

如果你本週只能工作 45 小時，你會怎麼用？你真的會花 5 小時挑剔初階開發者的程式碼嗎？你會仔細檢查一個進展順利的專案的每個小錯誤嗎？還是你會把注意力轉向更大的問題？你會花一些時間關注未來，而不是當下的細節嗎？你的時間太寶貴了，不該浪費；你的團隊值得一位願意信任他們獨立完成工作的主管。

建立持續回饋的文化#

提到績效評估（performance review），你腦中浮現什麼？畏縮？對浪費時間翻白眼？害怕聽到什麼令人驚訝的缺點？還是帶著一點緊張的期待想聽別人怎麼看你？

如果績效評估讓你不舒服，你並不孤單。不幸的是，並非每位主管都認真對待或成熟地處理評估流程。現在你管理人了，你有很大的權力去塑造你的直屬部屬對績效評估的體驗。而這個體驗，遠在評估被撰寫之前就開始了——它始於持續回饋（continuous feedback）。

持續回饋首先是一種承諾：定期分享正面和糾正性回饋。不是把這些評語留到評估週期，而是管理者和同儕被鼓勵在事情進展順利時即時指出，在問題發生時立即提出。

對你作為新任管理者而言，養成持續回饋的習慣：

• 訓練你關注個人，進而更容易識別和培養人才
• 練習與個人進行偶爾棘手的小對話
• 幫助你克服給予一對一表揚或糾正時的尷尬感

持續回饋的步驟#

1. 了解你的人

成功給予持續回饋的第一個前提是對團隊中每個人有基本的了解：他們的目標是什麼？優勢和弱點是什麼？目前在什麼層級運作，還需要在哪些方面改進才能達到下一個層級？你可以透過閱讀他們過去的績效評估來獲得部分認識，但也要坐下來和每個人談談他們對這些問題的看法。這份理解提供了一個基準，讓你在此基礎上構建你的回饋。

2. 觀察你的人

如果你沒在注意，就無法給回饋。作者認為，嘗試持續回饋循環最好的成果，不一定是實際產出的回饋，而是這份努力迫使你開始關注團隊中的每個人。在管理生涯早期就開始這個習慣，趁你可能只管幾個人的時候，幫助你鍛鍊觀察力。

練習首先尋找團隊中的才能和成就。好的管理者有一種天賦，能識別才能並幫助人們從自己的優勢中發揮更多。當然你也要尋找弱點和需要改進的領域，但如果你大部分時間花在讓人糾正弱點上，你的風格會更像是持續批評。

技巧： 給自己設定一個目標：定期識別值得表揚的人。養成正面認可的習慣會迫使你去留意值得讚揚的事情，進而讓你注意到每個人在各種專案中的貢獻。每週至少應該有一件事你可以認可團隊中的某個人。更好的是，每週為每位直屬部屬都找到值得認可的事情。

3. 提供輕量、定期的回饋

從正面回饋開始。給正面回饋比給糾正性回饋更容易也更有趣。作為新任管理者，你不必一開始就跳進指導的深水區。許多人對表揚的反應比對糾正性回饋更好，你可以用讚賞來引導他們走向更好的行為，強調他們做得好的地方。

正面回饋也讓你的部屬在你需要給批評性回饋時更願意傾聽。當他們相信主管看到了他們做的好事，他們會更開放地聽取需要改進的地方。對於明顯的錯誤，最好快速給予批評性回饋；但持續回饋不只是即時糾正，而是在你開始注意到事情不太對勁時就提出來，而不是等到評估週期才進行不舒服的對話。

額外加分：提供指導（coaching）

持續回饋在你將其與指導配對時效果最好。當情境出現時，用指導的方式問人們他們可能會怎樣做得不同。當事情進展順利時，表揚他們，但也提出未來可以更好的建議。基於指導的持續回饋意味著超越簡單的「做得好」，真正深入細節，與直屬部屬形成夥伴關係，共同幫助她成長。

為什麼把指導列為額外加分？因為它不一定是做好工作的核心需求，而且很多時候你既沒有資格也沒有能力為團隊中的每個人提供他們需要的指導。指導對你的初階團隊成員或有晉升潛力和意願的人最為重要。許多人會滿足於做好他們熟悉的工作，只要他們做得夠好，花時間指導他們不是你時間的最佳利用。把寶貴的指導時間留給那些願意接受的人。

績效評估#

持續回饋是實戰型管理者工具箱中的重要工具，但它不能取代更正式的、基於 360 度 的績效評估流程。

360 模型是一種績效評估，除了當事人的主管之外，還包括來自隊友、向他匯報的人、定期互動的同事的回饋，以及自我評估。例如，一位沒有直屬部屬的工程師可能會向團隊中的兩位工程師、她正在指導的新人、以及與她合作的產品經理徵求回饋。

績效評估很耗時，因為你需要從很多人那裡收集和給予回饋。身為主管，你需要把所有回饋彙整後為被評估者撰寫摘要。

績效評估的價值#

• 提供一個寶貴的機會來綜合大量關於一個人的資訊
• 360 度回饋讓你至少能高層次地了解其他人怎麼看你的部屬
• 自我評估讓你了解部屬對自己的優劣勢和年度成就的看法
• 撰寫摘要評估讓你有機會花較長的時間聚焦在個人身上，看到更長時間跨度的全貌
• 這些都應該幫助你看到日常持續回饋中可能忽略的模式和趨勢

績效評估常見的問題#

• 人們沒有得到足夠的時間來優先處理評估撰寫，而且很多人覺得難以下筆
• 我們傾向於記住和過度強調最近發生的事，忘記六個月或一年前的事
• 我們都有各種偏見，傾向透過偏見的鏡頭來評估人——批評某些人的行為，卻對其他人的同樣行為視若無睹

儘管如此，這個流程仍然極有價值，而你身為管理者，有機會讓它變得更有價值或更無價值，取決於你如何對待它。

撰寫和傳達績效評估的指引#

給自己足夠的時間，儘早開始

這不是你能在一小時內草草完成的事。計畫花費紮實、不被打斷的時間來撰寫評估。如果需要的話在家工作。你欠團隊足夠的時間來閱讀收集到的回饋、消化它、好好總結它。建議先閱讀收集到的回饋並做一些筆記，處理一下資訊，然後再嘗試寫完整的摘要。給自己足夠的時間寫完後至少回頭看一遍再提交。

大多數公司期望主管閱讀回饋並在撰寫摘要時將其匿名化，但有些公司有公開流程，原始同儕回饋對被評估者可見且可識別。即使在公開流程中，身為主管你仍應閱讀回饋並將其納入你的評估撰寫。

盡量涵蓋全年，而非只有最近幾個月

如果你全年都保留筆記，這會容易得多。一個策略是保留你一對一的摘要紀錄，包括給出的任何回饋。如果你沒有這麼做，建議你翻閱 email 回顧哪些專案上線了，逐月檢視發生了什麼活動，把自己帶回那個時期的視角。目標是不只認可早期的成就，也認可你從那時起觀察到的成長和變化。

使用具體的例子和同儕回饋的摘錄

如需匿名化同儕回饋，就匿名化。如果你找不到具體例子來支持某個觀點，問問自己這個觀點是否應該在評估中溝通。強迫自己具體化會引導你遠離基於潛在偏見的評估。

花大量時間在成就和優勢上

慶祝成就、談論進展順利的部分、充分表揚好的工作。這不僅適用於撰寫過程，特別適用於面對面傳達評估。不要讓人跳過好的部分直接執著於需要改進的地方——雖然很多人會想這樣做。那些優勢是你決定何時該晉升某人的依據，記錄和反思它們很重要。

談到需要改進的領域，保持聚焦

在最好的情況下，同儕回饋會有幾個清楚的主題讓你可以評論。作者見過的常見主題包括：

• 難以拒絕分心事務，最後幫其他專案而無法完成自己的
• 工作做得好但別人難以合作，在會議或 code review 中過度批評或粗魯
• 難以把工作拆分成中間交付物，無法平衡規劃設計與實際完成
• 跟工程師合作良好但跟其他部門或團隊合作不佳
• 難以遵循團隊公認的最佳實踐，走捷徑或做草率的工作

更常見的情況是你會得到很多零散的回饋。有些人似乎在勉強找話說，有些人則有特別尖銳的印象但沒人附和。尤其在零散回饋的情況下，確認你看到的回饋合理後再傳達。例如，如果只有一個評審者提到工作草率，問題是工作真的草率，還是這位評審者的標準比團隊其他人更高？運用你的判斷力。如果回饋對當事人有價值，就分享它，但不要盲目報告所有怨言。

如果你幾乎沒有有意義的改進回饋怎麼辦？這表示這個人已經準備好被晉升或接受更有挑戰性的工作。如果她在當前層級表現穩定但還沒準備好晉升，回饋應該指出她需要擴展的一兩個技能以獲得晉升資格。有些人可能永遠不需要晉升到下一個層級，但科技業的特性是技能需要不斷更新以保持競爭力，所以你也可以聚焦在新的技術學習機會。

避免重大意外

在評估傳達之前適當設定期望。如果某人在各方面都表現不佳，評估不應該是他第一次收到這個回饋。同樣，如果某人最近剛被晉升，你可能需要讓她有心理準備，她將以更高的標準被評估。

排定足夠的時間討論評估

作者通常在評估安排的前一天下班時給當事人一份紙本評估。這讓他們有機會在家閱讀，然後帶著準備好的想法來開會。即使他們已經讀過，作者仍會逐一走過每個部分，從優勢和成就開始。再次強調：不要讓他們跳過優勢直接看需要改進的地方。許多人不習慣被長時間表揚，但跳過那個部分會削弱其在強化和鼓勵他們才能方面的價值。

有些評估會用量化評分來總結，例如 1 到 5 分或等值的文字描述（「未達標」、「達標」、「超標」）。如果你必須這樣做，預期這對任何沒拿到最高評分的人來說會是評估中最難討論的部分。根據作者的經驗，人們對被告知「僅達標」會感到不舒服，特別是職涯初期的人。準備好深入解釋評分的原因，包括如何達到更高評分的具體例子。

培養成員的職涯發展路徑#

作者最關鍵的一次晉升發生在金融業。金融界有一種奇特的頭銜分配方式，源自合夥制模式，通常只有幾個「公開」頭銜：Associate、Vice President、Managing Director 和 Partner。VP 頭銜是一個關鍵的跳躍——獲得它意味著這個人已經證明自己值得在公司建立長期職涯。因此，多快拿到 VP 頭銜是未來成功的強烈訊號，而晉升是一個複雜的流程，每年只進行一次，由資深管理者主導。

作者的主管向她解釋了兩次這個流程：第一次是作者自己的 VP 晉升，主管帶她走過所有需要收集的材料——交付的專案，以及領導力的跡象和超出直屬團隊的工作。第二次是她為自己的部屬準備晉升材料。他們收集了各種證據，甚至包括這位候選人因擔任樓層消防員所獲得的表彰信。兩次晉升都成功了，作者認為至少部分原因是她的主管/mentor 完全知道如何玩這場遊戲。

你在晉升中的角色#

如果你是管理者，你將在團隊成員的晉升中扮演關鍵角色。有時候你可以直接決定誰晉升，但更常見的是晉升會被你的管理層或委員會審查。所以你不僅需要知道誰值得晉升，還需要為他們的晉升建立案例。

典型的流程：每年幾次檢視團隊成員，考慮他們的職級，問自己——有沒有人接近下一個層級？對初階員工來說，答案通常是肯定的。現在大學畢業生在工作的頭幾年通常至少會晉升一次，因為他們經常以「升不上去就走人」（up or out）的層級被招進來。

以一個例子說明：Famous BigCo 以 E2 級招進大學畢業的工程師（E1 保留給實習生）。公司政策是：在 E2 級待了兩年仍沒有晉升跡象的工程師，在公司沒有未來。E2 到 E4 級都有這個政策，但到了 E5，你可以永遠待在那裡。

所以如果你的團隊都是 E2 和 E3，你需要每幾年就讓他們準備好晉升。幸運的是，這通常很直接——只要你不阻擋他們晉升，流程會推動他們前進。你對這群人的工作是確保他們在學習估算自己的工作、大致在估算時間內完成、並從錯誤中學習。晉升的證據通常來自他們獨立完成的專案或功能、參與 on-call 輪班或其他支援工作、以及在團隊會議和規劃中的參與。

了解你公司的晉升遊戲規則#

現在你進入管理層，重要的是了解你公司的遊戲規則。每家公司的晉升流程都有自己的變化，而你大概是因為經歷過它才到這個位置。如果你不知道怎麼做，問你的主管：

• 這些決策是如何做出的？
• 你需要多早開始準備晉升材料？
• 每年的晉升名額有限制嗎？

當你學會了遊戲規則，作者鼓勵你對團隊相當透明。當成員表達想晉升但還沒有強力案例時，告訴他們晉升流程是什麼，幫助他們理解可能需要改變什麼。

識別晉升型專案#

你也應該準備好開始識別值得晉升的專案，並把這些專案分配給接近晉升的人。你身為主管，處於辨識團隊即將面對什麼的好位置。視工作分配方式而定，你可以直接指派這些專案，或鼓勵人們主動承擔對他們來說是挑戰目標（stretch goal）的專案。留意團隊成員可以伸展和成長的機會。

資深成員的職涯發展#

當團隊變得更資深時，這項工作開始改變。許多人不會持續晉升超過某個層級，至少在同一家公司或團隊內不會。展示更高層級所需的領導力或影響力廣度的機會越來越少。有時你對此無能為力，只能把他們推薦給公司其他部門的領導者進行指導。即使失去他們會讓你心痛，他們可能在另一個團隊甚至另一家公司中面對新挑戰會更好。

許多公司期望你在晉升之前就在下一個層級行事。這個做法是為了防止 Peter Principle（彼得原理）——人被晉升到他們不勝任的層級。它也表示團隊中有空間容納另一位在那個層級運作的人。在思考團隊的職涯發展時要記住這點。如果團隊沒有成長潛力是因為沒有空間讓人在更高層級工作，這可能是你需要重新思考工作方式的訊號，讓個人有機會承擔更大的責任。

挑戰：開除績效不佳的員工#

任何管理者必須面對的最困難的事情之一，就是因績效不佳而開除員工。

這個話題很難寫，因為開除員工的行為在很大程度上由 HR 部門主導，即使在小公司也是如此。好的一面是，你作為管理者會有一套流程和程序可以遵循。

績效改善計畫（PIP）#

許多公司在聽到員工績效不佳時，會要求你為當事人撰寫一份 Performance Improvement Plan（PIP）。這是一組明確定義的目標，當事人必須在固定期限內達成。如果她達成了，就解除計畫，一切安好；否則就被解雇。

視公司而定，PIP 可能確實是努力挽回員工的舉措，但通常計畫的撰寫方式使當事人不可能在規定時間內達成目標——它只是一種慷慨的方式，讓人在被解雇前有時間找下一份工作。

開除的前置作業#

無論你公司的程序是什麼，指導某人離開的過程應該遠在任何績效改善文件交到 HR 之前就開始，也遠在實際開除行為之前。管理的基本規則之一是不意外原則，特別是負面的意外。你需要了解一個人應該交付什麼，如果沒有做到，就要儘早且經常地讓她清楚知道她沒有達到期望。

理想情況是你清楚知道她應該做什麼工作，如果她沒做，你可以說：「你沒有做 X、Y 和 Z。請多做這些。」當然，現實很少這麼簡單。

保留回饋紀錄的重要性#

在任何 HR 活躍且需要標準績效改善計畫的環境中，你都需要有負面回饋的紀錄才能解雇某人。如果你沒有 HR，作者建議你仍然以書面形式給予人們明確的改善回饋，附上改善的時間表，並讓他們以書面方式（email 就可以）確認收到。這不僅在法律上保護你，也幫助你公平對待員工。

注意： 不要把你不願意失去的人放上改善計畫。大多數聰明的員工會把這個正式警告視為組織不適合他們的訊號，並盡快離開。作者曾聽過一個故事：一位優秀的工程師在有人抱怨他退出了一個專案後，被他的主管突然放上了 PIP。而這位主管之前沒有注意到情況，而且曾批准這位工程師將注意力轉移到其他地方。這份計畫除了毒害工程師對主管和公司的所有善意之外，什麼都沒做到。這位工程師很快就辭職了，儘管他輕鬆地達成了改善計畫的目標。

自我評估#

• 你是否已為直屬部屬安排了定期的一對一會議？
• 你上一次跟部屬談職涯發展是什麼時候？如果超過三個月，能否確保在下一次一對一中安排？
• 你上週有給部屬回饋嗎？上次在團隊面前公開表揚是什麼時候？
• 上次有人做了需要糾正的行為是什麼時候？你花了多久才給出糾正性回饋？你是私下還是公開給的？
• 你是否曾收到過感覺浪費時間的績效評估？它缺少什麼才能讓它更有價值？
• 你收到過最有用的績效回饋是什麼？它是怎麼傳達給你的？
• 你知道你公司的晉升流程是怎麼運作的嗎？如果不知道，能否請人帶你走一遍？