2年来，我把团队里一个初级开发晋升到了中级开发，同时给他加了工资，年终奖也比之前高了不少。
很多人经常问：
领导提拔一个人，到底看什么？
我不想讲太空泛的词，比如责任心、执行力、主人翁意识之类的。
我直接讲一个真实案例。
看看这个年轻人做了什么，让我主动去给他争取晋升和加薪。
他是2024年加入团队的。
刚入职的时候，我和大多数管理者一样，先给他安排一些相对简单的需求。
我有个习惯。团队所有任务分配情况，我都会记录。
从2024年一直记录到现在，每个需求是谁负责、完成情况如何，基本都能追溯。
他接到的第一个任务是：
门店物料报损支持撤销功能。
当时他提交的核心代码大概是这样的：
/** * 撤回报损单 */publicvoidcancelLossesDocs(CancelLossesDocsCommandcommand){LossesDocsAggregateRootroot=LossesDocsRepository.findRootById(command.getDocsId());if(Objects.isNull(root)){throwBusinessException.of(ErrorEnum.PARAM_INVALID_VALUE.getCode(),"报损单不存在!");}if(!newSystemGrayProperties.isDocsCancelFlag()){throwBusinessException.of(ErrorEnum.AUTH_FAIL.getCode(),"门店{"+root.getShopName()+"}还未上线该功能!");}// 1. 单据取消root.cancel(command.getUserName());// 2. 同步库存中心this.syncToStockCenterCancel(root);// 3. 更新数据库LossesDocsRepository.updateStatus(root);}我第一次看到的时候，感觉很爽。不是因为用了什么高级技术。而是因为结构非常清晰。
验证参数、执行业务、同步库存、更新数据库。整个流程一眼就能看明白。
这些年我接触过很多年轻程序员。工作两年左右，能把代码写得这么干净的，其实并不算多。
于是我顺手问了他两个问题。
- 第一个：如果单据取消成功了，但调用库存中心接口失败了，怎么处理？
- 第二个：库存中心取消成功了，但数据库更新失败了，又怎么办？
他当年的回答是：
第一个问题不存在。因为这里采用的是DDD的写法，root.cancel()只是修改内存对象状态，并没有立即更新数据库。真正的数据持久化是在最后一步。所以不会出现业务已经提交但数据库还没更新的情况。
第二个问题的话，数据库更新是按照主键更新，正常情况下不会失败。除非数据库本身出现故障。
这个回答在当时是ok的。说明他对自己写的代码是理解的，不是照着模板拼出来的。
当然，我还是给了一个建议。同步库存中心失败时，最好提供补偿机制或者重推工具。这样后续排查和恢复会方便很多。
后来这个功能上线了。一直运行到现在，几乎没有改动过。稳定性非常不错。
接下来，我又陆续给他安排了一些类似的任务。
结果都差不多：
- 交付质量稳定；
- Bug数量很少；
- 出现问题响应很快；
- 态度积极。
对于管理者来说，这其实是一个很重要的信号。
因为只有当简单任务持续做得好，你才有资格接触更复杂的事情。
后来我决定再给他加点难度。我把一个涉及第三方系统对接的项目交给了他。
业务大概是：
门店下单后，需要同步给外部系统，由外部系统负责配送到门店。
从需求评审、技术方案设计，到开发上线，全部由他负责。同时我把他拉进了和第三方技术团队的对接群。让他直接负责沟通。
做过第三方系统对接的人都知道。这种项目比普通需求难得多。
因为第三方是不可控的。
很多问题不是你自己的代码导致的。你必须提前把各种异常场景考虑清楚。
当时我只给了几个方向性的建议：
- 监控和告警一定要到位；
- 充分考虑稳定性和异常流；
- 技术方案先和我过一次。
剩下的事情基本让他自己推进。
后来发生了一件让我印象特别深刻的事情。
第三方给出的方案是：
通过定时任务批量同步订单。
而他在方案评审时直接提出反对意见。他的理由很简单。
这家第三方公司同时服务很多品牌。如果所有客户都通过定时任务集中推送订单，他们的系统很容易在高峰期出现问题。
最终会影响到我们。
他的建议是：
改成实时同步。
产生一张订单，就同步一张订单。成功一单算一单。
我知道这件事以后，立刻支持了他的方案。
并要求第三方增加订单取消接口。我们这边实时推送订单，同时支持实时取消。
这件事情让我对他有了新的认识。因为从那时候开始，我看到的已经不仅仅是一个会写代码的人。而是一个会思考系统整体稳定性的人。
很多开发到了这个阶段，仍然只是执行需求。别人怎么说，他就怎么做。
而他已经开始主动独立思考：
这个方案是不是合理？有没有更好的方式？长期运行会不会出问题？
这种能力非常难得。
到了2025年。我正式提名他晋升中级开发，同时给他加薪2500元，绩效评定A。
因为在我看来，他已经具备了中级开发应该具备的能力。
而到了2026年。
我已经开始把一些大型模块直接交给他负责。
例如：
- 门店排班系统；
- 门店物料制作预估系统；
从设计到落地，基本由他独立推进。我很少再去具体干预实现细节。结果也都做得不错。
所以回到最开始的问题：
领导提拔一个人，到底看什么？
我的答案是：不是看你会多少技术。也不是看你平时是不是很会说话。而是看你能不能持续承担比当前岗位更大的责任。
简单任务做好了，给你更复杂的任务。复杂任务做好了，给你更大的项目。项目做好了，再给你更大的系统。
当领导发现：
你总能把略微超出自己能力范围的事情做好。
那么晋升、加薪、更多机会，往往只是时间问题。