Code review时指出一堆问题，会议上列举各种风险，设计评审时质疑架构选择——这些都是常态。大家都觉得这叫专业，叫严谨，叫对项目负责。

见过太多技术leader，张口就是"这个设计有问题"、"那个实现不够优雅"、"timing为什么还没收敛"。说的都没错，但问题是，整个团队的氛围会变得很压抑。新人提个想法，还没说完就被怼回去；有人熬夜解决了个bug，得到的反馈是"这本来就该做好"。久而久之，大家不敢尝试新东西，不愿意主动担责，能少说就少说，能躲就躲。

芯片项目本来就够难了。timing不收敛要返工，verification coverage跑不上去要加case，后端congestion解决不了要调floorplan。每个环节都在和各种问题死磕，压力大到让人怀疑人生。这种时候，如果连队友都不给点正向反馈，那这活儿还怎么干下去？

很多工程师习惯了靠道理说服别人。觉得只要逻辑清晰、论据充分，就能让对方接受自己的观点。

验证工程师连着加班一周终于把corner case覆盖全了，这时候一句"辛苦了，这波coverage提升很关键"比十句"这是你的本职工作"有用得多。后端工程师费了老劲把某个module的timing收敛了，一句"这个module确实难搞，能搞定不容易"比直接扔下一个module有效得多。

鼓励和夸赞不是在放低标准，而是在给人动力。芯片研发这行，技术难度摆在那里，标准该多高还是多高。但完成同样的任务，有人愿意主动往前冲，有人只是机械地完成KPI，区别就在这里。那些被认可、被看见的人，会更愿意投入，更愿意承担责任，甚至更愿意帮助别人。

当然，夸也不是瞎夸。"你真厉害"、"你太牛了"这种空话没人爱听。真正有效的鼓励，是看见别人具体做了什么，认可那个努力的过程。前端工程师为了降低功耗重构了整个模块，那就夸"这次重构思路很清晰，功耗降了不少"；DFT工程师想办法优化了扫描链插入，那就说"这个优化很有想法，减少了不少面积开销"。这种具体的认可，比泛泛而谈的表扬管用一百倍。

有意思的是，越是技术强的人，越容易忽视这一点。可能是觉得夸人显得不够专业，也可能是觉得指出问题才是在帮对方进步。但现实恰恰相反：那些既能指出问题、又懂得鼓励人的leader，带出来的团队往往战斗力更强。因为大家知道，犯错会被指正，但做得好也会被看见。

芯片项目动辄几十人、上百人的团队，每个人都在负重前行。一句到位的认可，可能就是压垮骆驼的稻草和让人咬牙坚持的区别。

毕竟，道理谁都懂，但能让人愿意继续拼下去的，从来不只是道理。