有个现象我一直觉得很有意思：很多技术Leader当了Leader之后，比当个体贡献者时更忙了。

这不正常。

如果你的管理是有效的，你应该比以前更闲才对——因为你把事情分出去了，别人在做。但现实是，大部分Leader的日常是这样的：早上站会听进度，上午review代码，下午排需求优先级，晚上还要处理线上问题。忙得脚不沾地，但回头一看，团队离了你好像啥也干不了。

你以为这是"能者多劳"，其实这是一个信号：你根本没在管人，你还在管事。

管事和管人，不是同一件事的两种叫法

我见过不少刚做管理的朋友，聊起来都说"我在带团队"。但你仔细看他们的工作内容：拆任务、派活、盯进度、review产出、解决技术卡点……这些是管事还是在管人？

都是管事。

区别很简单：管事关注的是"事情有没有做好"，管人关注的是"人有没有成长"。前者是项目管理的范畴，后者才是团队管理的核心。

这个区分听起来像废话，但大部分技术Leader从来没认真想过这个问题。因为在工程师的世界观里，把事情做好就是一切。升Leader之后，自然也觉得"把团队的事情管好"就是管理。

但你仔细想想——你拆的任务越细，团队能自我决策的空间就越小。你盯的进度越紧，团队就越习惯等你来催。你review得越严格，团队就越不敢自己做判断。

你在管事上投入越多，管人的空间就越少。这俩不是互补关系，是竞争关系。

为什么转型这么难

道理都懂，为什么做不到？我认为根本原因不是能力不够，而是"管事"和"管人"提供的反馈机制完全不同。

管事的反馈是即时的、确定的、可衡量的。你写完一段代码，跑一下就知道对不对。你优化了性能，指标立竿见影。你修了一个bug，测试通过了就是解决了。工程师做了很多年这种工作，大脑已经形成了回路：投入→产出→验证，干脆利落。

管人的反馈是延迟的、模糊的、难以归因的。你花了一个下午跟组员深聊，聊完他好像明白了，又好像没明白。你花了两周培养一个人的技术判断力，三周后他还是犯了同样的错。你花了一个月调整团队协作方式，好像有效果了，但又说不清是方式起作用还是正好那个月需求简单。

对于习惯了确定性反馈的工程师来说，这种模糊感是痛苦的。你会本能地想回到管事的状态——因为那里有清晰的反馈，有即时的满足感，有"我能搞定"的掌控感。

所以你会看到一种很典型的模式：Leader嘴上说"我授权了"，实际上每天还是逐个盯PR。嘴上说"让团队自己决定"，实际上方案评审时还是会把自己的想法强加进去。嘴上说"培养人重要"，实际上遇到紧急问题还是自己上。

不是他们虚伪，是他们真的控制不住。管事给的安全感太强了，强到像一个舒适区，你明知该走出去，但每次走到边界还是会缩回来。

更隐蔽的问题：把管事包装成管人

还有一种情况更难识别：你以为自己在管人，实际上只是换了一种方式管事。

比如"一对一沟通"。很多Leader的1v1聊的是什么？本周进度怎么样，那个需求做到哪了，有没有遇到技术困难，下周计划是什么。这跟站会有什么区别？只是从一对多变成了一对一而已。本质上还是管事。

真正的人员管理1v1聊的应该是：你最近感觉怎么样，工作上有没有什么让你消耗特别大的地方，你希望半年后在哪些方面有所成长，我能怎么帮你。这些才是"人"的问题，不是"事"的问题。

再比如"绩效面谈"。很多Leader做绩效面谈时，聊的全是这个季度的产出：做了几个项目，代码质量如何，有没有线上问题。这些是评价事情做得好不好，不是评价这个人成长了多少。

我见过一个挺极端的例子：一个前端团队的Leader，每周跟每个组员做1v1，看起来很用心。但组员私下吐槽说，每次1v1都像是在做周报，Leader问的全是进度和问题，从来不关心他们的想法和感受。做了半年1v1，团队归属感没提升，离职率反而上升了。

用管事的方式做管人的动作，比直接管事还糟糕。因为至少直接管事是坦诚的——"我就是来盯进度的"。用管事的方式假装管人，只会让人觉得你虚伪。

工程师出身的Leader，骨子里还是问题解决者

还有一个深层原因：工程师出身的管理者，习惯把所有东西当问题来解决。

团队有矛盾？解决它。有人成长慢？解决它。有人不认同技术方案？说服他。

但管理中遇到的情况，很多不是需要"解决"的问题，而是需要"容纳"的差异。

有人工作方式和你不一样，不一定需要改。有些人是慢热型，上手慢但一旦掌握了就很稳。有些人喜欢先做再讨论，有些人喜欢先讨论再做。这些不是bug，是性格。

有人成长速度跟不上你的预期，不一定是他有问题，也不一定是你教得不好。可能就是需要更长时间。你硬推，他焦虑，你失望，双方都消耗。

有些人对技术方案有不同看法，这不是在挑战你的权威，而是他真的那么想。你不需要说服他，有时候只需要让他试一下，用结果说话。

把"差异"当"问题"来解决，这是工程师思维在管理场景里最大的误用。工程师的训练是：发现问题，定位原因，实施修复，验证结果。这套方法论写代码无敌，用在人身上经常适得其反。

因为人不是代码，你不能debug别人的人生。

那道看不见的坎

说了这么多，我觉得从管事到管人最难的坎，其实不是学什么新技能，而是放弃一样东西——控制感。

当一个需求来了，你知道怎么实现，也知道怎么做最好，但你不能自己上手，得看着别人用可能不如你的方式去做。当一个技术方案你能一眼看出问题，但你不能直接否定，得引导对方自己发现。当线上出了bug，你五分钟能定位，但你得忍住让组员花半小时去查。

每一刻都在放弃控制感。

这种放弃不是一次性的决定，而是每天每时每刻都在做的选择。起床的时候决定今天不插手那个项目，开会的时候决定让组员先说完再补充，code review的时候决定只提方向性建议不改具体实现。

积累起来的不安感是实实在在的：万一出问题呢？万一质量下滑呢？万一他搞不定呢？

这些"万一"有可能真的发生。一些bug确实会因为你不亲自过问而漏过去。一些决策确实会因为你不参与而不够最优。一些机会确实会因为你不拍板而错失时间窗口。

这就是管人的代价。你用人效提升和团队成长换来了对细节的失控。这笔账划不划算，取决于你算的是什么周期。短期内，管事永远比管人效率高。长期看，一个能自我运转的团队和一个离了你就瘫痪的团队，价值完全不在一个量级。

不是渐进，是跳跃

最后说一个我觉得很重要的判断：从管事到管人，不是一个渐进的过程，而是一个认知上的跳跃。

你可能当了三年Leader还在管事，也可能某一天突然想通了就跨过去了。这个"想通"不是指学会了什么管理工具或方法论，而是你终于接受了一个事实——你的价值不再取决于你亲自做了什么，而取决于你让别人做到了什么。

这个认知转变一点都不容易。尤其是对那些靠技术实力一路升上来的工程师来说，亲手做出东西的成就感是最核心的自我认同。让你放弃这一点，等于让你重新定义"我是谁"。

有些Leader从来没有完成这个跳跃。他们管了五年十年团队，本质上还是那个最能干的高级工程师，只是多了个管理title。团队离不开他们，不是因为管理做得好，恰恰是因为管理做得不够——没有人成长到能替代他们的程度。

这个判断可能有点尖锐：如果你管了三年的团队，离了你还是不能运转，那你不是在管人，你只是给自己找了个更大的键盘来敲。

什么时候你才算真正开始管人了？大概是当你发现，两周不在团队，回来一看项目照跑，质量没崩，人也没跑，你反而有点失落的时候。

那种失落感，就是你跨过那道坎的证明。