技术圈里有一种情绪基本上心照不宣。就是觉得做管理的人每天开会、汇报、做PPT不干实事。懂技术的时候还好一旦脱离一线时间久了讲话开始飘方向开始虚还喜欢对具体的技术问题指手画脚。这种感受做过几年研发的人大概都有过。先说一个很真实的场景。一个数字芯片项目前端设计完成开始进入后端流程。这时候出现了一个问题模块A负责人时序已收敛signoff完成 模块B负责人我们的接口需要A再改一版 现在的输出延迟不满足我们的建立时间 tSU required : 1.8ns tSU provided : 1.4ns ← gap: 0.4ns两个模块负责人都觉得自己是对的。A说我已经signoff了动我要重新跑全流程。B说不改我这边没法收敛。这个僵局技术上双方都有道理。这时候需要有人来做一件事在没有完整信息的情况下做出一个让项目能继续走下去的决定。这就是管理在做的事。管理的核心工作从来不是开会本身。开会、汇报、PPT这些是信息传递的形式不是管理的本质。管理的本质是在资源有限、信息不完整、各方利益不一致的情况下让事情能推进下去。这比解一道timing violation难得多。timing violation有工具有报告有明确的slack数字告诉你差多少。管理面对的问题往往连”差多少”都没法量化。需求模糊、进度压力、团队状态、上下游协调——这些变量同时存在还在动态变化。技术问题的答案通常是确定的对就是对错就是错。管理问题没有标准答案只有在当时的约束条件下相对更合理的判断。当然“不懂技术瞎指挥”这件事确实存在。一个完全脱离技术判断的管理者拍出来的决策可能是灾难性的。比如在时序还没收敛的情况下拍板说”两周后必须流片”完全不考虑工程实际。但这不是管理这件事本身的问题是这个管理者没做好。好的技术管理者判断力的核心依然是技术准确性。只是这个准确性不再体现在他自己能不能写出那段约束脚本而是体现在他能不能听懂两个工程师的争论判断出谁的方案风险更低。# 他不一定自己写得出来 set_output_delay -max 1.8 -clock clk [get_ports if_data] # 但他要能判断这个改动影响范围多大 # 重新跑后端流程要多久和流片节点冲不冲突这个判断需要对技术有真实的理解只是表达方式不同了。做研发的人不喜欢管理还有一个隐藏原因。技术工作的成果是可见的代码在那里仿真结果在那里时序报告在那里。管理工作的成果很多时候是隐形的——一个项目顺利推进大家可能觉得”本来就该这样”一场可能爆发的冲突被提前化解没人知道有这回事。管理做得好的时候最大的特征就是什么都没出问题。这种隐形性让做技术的人很容易低估管理工作的复杂度。技术和管理不是高下之分是两种不同的工作模式。技术是在确定性的框架里追求极致的准确。管理是在不确定性里追求相对合理的推进。两种能力都难只是难的地方不一样。真正把技术做透的人在某个阶段会自然开始理解管理在处理什么。因为系统越复杂人的因素就越不可忽视。
