為什麼我會主動幫一個年輕工程師加薪、升遷？
2年來，我把團隊裡一個初級工程師晉升到中級工程師，同時也幫他加了薪，年終獎金也比之前高了不少。很多人經常問：
主管提拔一個人，到底看什麼？
我不想講太空泛的詞，比如責任感、執行力、主人翁意識之類的。
我直接講一個真實案例。
看看這個年輕人做了什麼，讓我主動去幫他爭取升遷和加薪。
他是 2024 年加入團隊的。
剛入職的時候，我和大多數管理者一樣，先給他安排一些相對簡單的需求。
我有個習慣。團隊所有任務的分配情況，我都會記錄。
從 2024 年一直記錄到現在，每個需求是誰負責、完成情況如何，基本都能追溯。
他接到的第一個任務是：
門店物料報損支援撤銷功能。
當時他提交的核心程式碼大概是這樣的：
Java 代碼解讀複製代碼/**
* 撤回報損單
*/
public void cancelLossesDocs(CancelLossesDocsCommand command) {
LossesDocsAggregateRoot root =
LossesDocsRepository.findRootById(command.getDocsId());
if (Objects.isNull(root)) {
throw BusinessException.of(
ErrorEnum.PARAM_INVALID_VALUE.getCode(),
"報損單不存在!"
);
}
if (!newSystemGrayProperties.isDocsCancelFlag()) {
throw BusinessException.of(
ErrorEnum.AUTH_FAIL.getCode(),
"門店{" + root.getShopName() + "}還未上線該功能!"
);
}
// 1. 單據取消
root.cancel(command.getUserName());
// 2. 同步庫存中心
this.syncToStockCenterCancel(root);
// 3. 更新資料庫
LossesDocsRepository.updateStatus(root);
}我第一次看到的時候，感覺很爽。不是因為用了什麼高級技術，而是因為結構非常清晰。
驗證參數、執行業務、同步庫存、更新資料庫。整個流程一眼就能看明白。
這些年我接觸過很多年輕工程師。工作兩年左右，能把程式寫得這麼乾淨的，其實並不算多。
於是我順手問了他兩個問題。
- 第一個：如果單據取消成功了，但呼叫庫存中心 API 失敗了，怎麼處理？
- 第二個：庫存中心取消成功了，但資料庫更新失敗了，又怎麼辦？
他當年的回答是：
第一個問題不存在。因為這裡採用的是 DDD 的寫法，root.cancel() 只是修改記憶體物件狀態，並沒有立即更新資料庫。真正的資料持久化是在最後一步。所以不會出現業務已經提交但資料庫還沒更新的情況。
第二個問題的話，資料庫更新是按照主鍵更新，正常情況下不會失敗。除非資料庫本身出現故障。
這個回答在當時是 ok 的。說明他對自己寫的程式是理解的，不是照著模板拼出來的。
當然，我還是給了一個建議。同步庫存中心失敗時，最好提供補償機制或者重推工具。這樣後續排查和恢復會方便很多。
後來這個功能上線了。一直運行到現在，幾乎沒有改動過。穩定性非常不錯。
接下來，我又陸續給他安排了一些類似的任務。
結果都差不多：
- 交付品質穩定；
- Bug 數量很少；
- 出現問題回應很快；
- 態度積極。
對於管理者來說，這其實是一個很重要的訊號。
因為只有當簡單任務持續做得好，你才有資格接觸更複雜的事情。
後來我決定再給他加點難度。我把一個涉及第三方系統對接的專案交給了他。
業務大概是：
門店下單後，需要同步給外部系統，由外部系統負責配送到門店。
從需求評審、技術方案設計，到開發上線，全部由他負責。同時我把他拉進了和第三方技術團隊的對接群，讓他直接負責溝通。
做過第三方系統對接的人都知道，這種專案比普通需求難得多。
因為第三方是不可控的。
很多問題不是你自己的程式導致的。你必須提前把各種異常情境考慮清楚。
當時我只給了幾個方向性的建議：
- 監控和警報一定要到位；
- 充分考慮穩定性和異常流程；
- 技術方案先和我過一次。
剩下的事情基本讓他自己推進。
後來發生了一件讓我印象特別深刻的事情。
第三方給出的方案是：
透過排程任務批次同步訂單。
而他在方案評審時直接提出反對意見。他的理由很簡單。
這家第三方公司同時服務很多品牌。如果所有客戶都透過排程任務集中推送訂單，他們的系統很容易在高峰期出問題。
最後會影響到我們。
他的建議是：
改成即時同步。
產生一張訂單，就同步一張訂單。成功一單算一單。
我知道這件事以後，立刻支持了他的方案。
並要求第三方增加訂單取消 API。我們這邊即時推送訂單，同時支援即時取消。
這件事情讓我對他有了新的認識。因為從那時候開始，我看到的已經不僅僅是一個會寫程式的人，而是一個會思考系統整體穩定性的人。
很多工程師到了這個階段，仍然只是執行需求。別人怎麼說，他就怎麼做。
而他已經開始主動獨立思考：
這個方案是不是合理？有沒有更好的方式？長期運行會不會出問題？
這種能力非常難得。
到了 2025 年，我正式提名他晉升中級工程師，同時幫他加薪 2500 元，績效評定 A。
因為在我看來，他已經具備了中級工程師應該具備的能力。
而到了 2026 年。
我已經開始把一些大型模組直接交給他負責。
例如：
- 門店排班系統；
- 門店物料製作預估系統；
從設計到落地，基本由他獨立推進。我很少再去具體干預實作細節。結果也都做得不錯。
所以回到最開始的問題：
主管提拔一個人，到底看什麼？
我的答案是：不是看你會多少技術。也不是看你平時是不是很會說話。而是看你能不能持續承擔比目前職位更大的責任。
簡單任務做好了，給你更複雜的任務。複雜任務做好了，給你更大的專案。專案做好了，再給你更大的系統。
當主管發現：
你總能把略微超出自己能力範圍的事情做好。
那麼升遷、加薪、更多機會，往往只是時間問題。
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
