上周和一个刚升 Tech Lead 的朋友吃饭，他半开玩笑说了句："我以前觉得最焦虑的是线上故障，现在发现最焦虑的是打开 Slack 不知道该回哪条消息。"

他不是在抱怨工作量。他困惑的是一个更根本的问题——他不确定自己现在到底该干什么。

这位朋友技术能力没得说，组里最难的问题都是他啃下来的。升职之后，他给自己定的策略很简单：还是干最难的活，顺便把管理的事也带着做了。三个月下来，最难的技术活他还在干，管理的事全是"顺带"——顺带开个会，顺带审批个需求，顺带和产品对个方案。团队产出反而不如他一个人扛活的时候。

这个故事不新鲜。我见过太多优秀的工程师在走上管理岗之后经历类似的挣扎。不是能力问题，是角色切换的认知滞后——你以为只是多了一些职责，其实是在换一个职业。

升的是 Title，丢的是手感

工程师的身份建立在什么上面？解决问题的能力。一个 bug 搞定，一个功能交付，一个性能瓶颈突破——每一个都是明确的、可感知的成就。这种正反馈循环是工程师职业早期的核心驱动力。

Tech Lead 的工作节奏完全不同。你花两天时间帮团队扫清了一个跨组协作的障碍，没有人会说"做得好"，因为这件事本来就不该存在。你花一个下午和产品经理对齐了一个模糊的需求，避免了两周的返工，但那两周的返工不会发生，所以没人知道你避免了什么。

这就是管理工作的第一个认知冲击：你的产出变成了"没有发生的事"。

而更难接受的是，你亲手写代码的时间会断崖式下降。不是你不想写，是时间不允许。你在两个会议中间挤出 40 分钟想写个方案，刚打开编辑器就被拉去处理一个线上报警。一天下来，IDE 里还是那个空文件。这种挫败感是真实的，而且它会持续很久。

很多人应对这种失落的方式是——加班写代码。白天开会，晚上写代码。短期看似乎两不误，长期看这是在用体力和时间掩盖一个事实：你在同时做两份工作，而两份都做不好。

你最大的贡献不再是你写的代码

这是最难接受的一件事。

做 IC 的时候，你的价值和你写的代码直接挂钩。写得快、写得好、写得优雅——评估标准清晰。升了 Tech Lead 之后，一个残酷的换算关系开始生效：你写一行代码的价值，等于一个初级工程师写同样一行代码的价值。但你帮一个初级工程师扫清障碍让他多写十行代码，你的价值就是那十行代码的十倍。

这个道理谁都懂，但做到需要克服一种深层的本能——"我来写更快"。

确实更快。但"我来写"有三个隐藏代价：

第一，你在抢别人的成长机会。一个能解决的问题被你解决了，那个本该解决这个问题的人就少了一次锻炼。每一次你"帮忙"代写代码，都在制造一个更依赖你的团队。

第二，你在制造单点故障。如果你是全组唯一理解某个模块的人，你的休假就是团队的风险。你的病假就是项目的延期。这不是责任心强，这是架构缺陷。

第三，也是最隐蔽的——你在逃避真正的工作。写代码是确定性的、可控的、有即时反馈的。处理人的问题、推动流程改进、做技术规划——这些才是 Tech Lead 该干的事，但它们模糊、缓慢、充满不确定性。很多人潜意识里选择用写代码来逃避这些更难的任务。

我不是说 Tech Lead 不该写代码。在小型团队里，Tech Lead 往往是核心贡献者。但关键是写什么代码——架构决策、关键路径上的核心逻辑、技术难点的攻关——而不是替别人写他们自己能写的代码。

从"我来做"到"我来确保它被做好"

这两个说法的区别微妙但致命。

"我来做"是 IC 思维的延伸。它假设你是最可靠执行者，所有重要的事都应该经过你的手。

"我来确保它被做好"是管理思维。它承认你的角色不再是执行者而是促成者——你的工作是建立让正确事情发生的条件。

具体来说，这个转换体现在几个日常决策上：

代码 Review。 你不再需要 Review 每一个 PR。但你必须确保 Review 流程本身是有效的——有人 Review，Review 的标准是一致的，关键路径的改动经过了足够深的审视。从"每个 PR 我都看"变成"我知道哪些 PR 必须我看哪些可以放心交给其他人"。

技术方案。 你不再需要亲自写每一个技术方案。但你要确保方案评审机制是健康的——参与评审的人有能力提出关键问题，方案的可选方案被充分讨论过，而不是走个过场。从"我来定方案"变成"我来确保做决策的过程是靠谱的"。

线上问题。 你不再需要每次都冲在第一线排查。但你要确保 on-call 机制运转正常，团队的排障能力在提升，事后复盘产出了真正的改进。从"我来修 bug"变成"我来确保这类 bug 以后不会再出现"。

注意这些转换的共同模式：从执行到建设系统。你的产出不再是具体的结果，而是持续产生好结果的系统和流程。

三个没人提前告诉你的局面

第一，你必须学会忍受"失控感"。

做 IC 的时候，你对自己的产出有完全的掌控。代码写得好不好，你说了算。做 Tech Lead 之后，你的产出取决于其他人的执行。你能影响，不能控制。这种失控感会让很多从优秀工程师转型的管理者做出过度干预的事——微观管理、抢活干、不信任别人的方案。

对抗这种本能的方式不是放权，是建立信任。信任不是"我相信你能行"这种鸡汤，信任是具体的——我知道你的技术边界在哪里，你在这个范围内我可以放心，超出这个范围我会介入。这需要你花时间了解每个人的能力和盲区，比写代码枯燥多了，但比微观管理有效一百倍。

第二，你的技术判断比你写代码更重要。

很多新 Tech Lead 担心一个问题：不写代码了，技术能力会不会退化？短期的手感确实会生疏，但有一种能力反而会增强——技术判断力。

技术判断力不是写代码的能力，是在信息不完整的情况下做出正确技术选择的能力。选 React 还是 Vue，用微服务还是单体，引入这个中间件值不值得——这些决策对团队的影响远比你多写几千行代码大。

而技术判断力的来源不是你写了多少代码，是你见过多少种场景、推翻过多少次自己的假设、理解了多少种权衡。一个每天埋头写代码的人和一个每周和技术团队深度讨论架构选型的人，后者的判断力成长更快，哪怕前者写了十倍的代码。

第三，向上管理比你想象的更重要。

这不是拍马屁。向上管理是确保你的团队获得正确资源和方向的过程。

你手下的人看不到的东西——公司战略调整、预算压缩在即、其他团队正在计划抢你们的资源——你需要提前感知并及时应对。一个只会向下管理的 Tech Lead 带的是一支随时可能被组织变化冲散的团队。一个同时能向上管理的 Tech Lead 带的是一支有方向、有资源、有保护伞的团队。

具体怎么做？定期和你的上级同步，不只是汇报进度，而是理解他的压力和优先级。当他的优先级变了，你的团队方向也要跟着调。当你需要资源，你要能用他关心的语言去论证——用业务影响说话，不是用技术理想说话。

不是每个人都要走这条路

最后说一个可能不太讨喜的观点：不是每个优秀的工程师都应该去做管理。

有些人就是更适合在技术深度上深耕，这没有任何问题。问题出在很多公司的晋升体系里，Tech Lead / Manager 是唯一的高阶路径，高级 IC 通道要么不存在，要么形同虚设。这是组织的失败，不是个人的问题。

如果你正在考虑这条路径，我的建议是诚实地问自己一个问题：你愿意用"我写了这个"的满足感，去换"我帮团队做到了这个"的满足感吗？这两种满足感是不同的，没有高下之分，但你需要清楚自己更被哪种驱动。

如果你选择了这条路，那就认真走。最糟糕的状态是人在管理岗位上，心还在 IC 的评价体系里——用代码行数衡量自己的价值，用技术难度评估自己的贡献，用"我比团队里任何人都能写更快"来定义安全感。

那不是 Tech Lead，那是一个带管理帽子的高级工程师。团队不需要你证明你是最强的，团队需要你让他们变得更强。