虚从一次Code Review开始第四周周一早上陈钊做了一件已经很久没做了的事——打开IDE认真看代码。起因是小李上周提了一个PR改动量不小涉及到支付模块的核心链路。按照陈钊以前的习惯这种级别的PR他至少要审查半小时逐行过一遍关键逻辑。但那天他只看了五分钟。不是没时间周一上午相对来说清闲一些他完全可以拿出半小时来。但他发现了一个让自己不安的事实——他看不进去了。不是代码写得不好。小李的代码风格一向规整变量命名、模块拆分、注释都挑不出大毛病。问题出在陈钊自己身上。那些曾经像母语一样熟悉的代码结构现在看过去他觉得自己像是在读一篇外语文章——每行代码都认识但连起来就是反应不过来意思。他盯着一段涉及分布式事务的处理逻辑看了两分钟脑子里突然冒出一个念头“如果我还在一线写代码这段逻辑我会怎么写”他想不出来。不是真的想不出来是他不确定了。以前他有笃定的技术判断力——“这里应该用TCC而不是SAGA”、“这个场景用消息队列比直接调用更合适”——这些判断来得自然、迅速几乎不需要刻意思考。但现在他发现自己开始犹豫了。不是技术退步了而是他已经太久没有沉浸在具体的技术细节里那种直觉性的判断力在钝化。这种感觉让他觉得——虚。不是慌不是忙不是压也不是尬。是一种更深层的、关于自我价值的不安全感“我还是一个技术人吗”这种虚不只你一个人有先说一个事实几乎所有从技术岗转到管理岗的人都会经历这个阶段。这不是错觉也不是矫情。它有清晰的心理学根源。当你做了几年技术你的职业认同是建立在技术能力上的——“我是团队里技术最强的人之一”、“遇到技术难题找我准没错”、“这段代码只有我能改”。这些认同构成了你职业自信的地基。当你成为管理者之后这个地基开始松动。你的日常从写代码变成了开会、沟通、协调、决策。你花在技术上的时间断崖式下降从原来每天6-8小时变成可能每天不到1小时。你的技术判断力没有消失但它失去了持续喂养的养料开始像没有锻炼的肌肉一样逐渐松弛。与此同时你的管理技能还在成长期还没有建立起足够的新自信来替代旧的。结果是——旧的自信在消退新的自信还没长出来中间就出现了这个虚的阶段。这是一个正常的、可预期的过渡期。但正常不等于无害。如果虚的状态持续太久会有两个后果第一、你开始回避技术讨论。在技术方案评审会上你越来越少发表意见因为你怕自己说错。你越来越依赖团队里技术最强的人来做技术判断而你自己变成了一个纯粹的传声筒——上级说什么你转达什么团队做什么你汇报什么。第二、你开始怀念写代码的日子。不是因为你真的想回去写代码而是因为你怀念那种我能搞定一切的确定感。管理者的世界充满了不确定性而代码的世界是确定的——跑得通就是跑得通报了错就是报了错。这两种后果如果同时出现都会让你的管理角色空心化。一个不参与技术判断的管理者不是在管技术团队是在管一个技术外包组。管理者需要的技术能力和工程师不一样在解决这个问题之前先搞清楚一个问题管理者到底需要什么样的技术能力很多人把这个问题想简单了。他们以为保持技术能力就是继续写代码于是拼命挤时间写代码结果两头都顾不上——管理没管好代码也写得断断续续。管理者的技术能力和工程师的技术能力是两种不同的能力。工程师的技术能力是深度能力 我能把这个模块写到最优、我能把这段逻辑调试到完美、我对这个系统的每一行代码了如指掌。管理者的技术能力是判断能力 我能判断这个技术方案是否合理、我能识别潜在的技术风险、我能在多个技术选项中做出正确的取舍。深度能力需要大量的时间沉浸——每天写代码、调bug、看日志。判断能力需要的是广度视野和持续的信息输入——你知道业界在做什么、你知道团队在用什么、你知道每个技术选项的利弊是什么。管理者不需要亲自写代码但必须保持对技术的判断力。举个例子同样是面对一个要不要上微服务的决策工程师会想“怎么拆服务、怎么做服务发现、怎么处理分布式事务、怎么做链路追踪……”管理者应该想“我们现在的团队规模和技术能力真的需要微服务吗上微服务的ROI是什么如果上了团队需要多少人、多长时间、多少资源这些资源的投入和当前业务需求的优先级怎么排”前者是技术深度后者是技术判断。两者都很重要但管理者更需要的是后者。保持技术判断力的四个实践搞清楚了需要什么之后接下来的问题是怎么做。以下四个实践是很多技术管理者验证过的、可以在有限时间预算内保持技术判断力的方法。实践一参加技术方案评审而且要真的参与这不是让你坐在评审会上当听众而是让你带着问题去。每次技术方案评审前花十分钟快速看一下方案文档。你不需要理解一行设计但你需要问三个问题这个方案要解决什么问题 业务目标是什么有没有更简单的方案 是不是过度设计了风险在哪里 如果出了问题影响面有多大这三个问题不需要你亲自写代码但需要你对技术有基本的判断力——什么样的方案是合理的、什么样的复杂度是不必要的、什么样的风险是不能接受的。如果你在评审会上问不出这三个问题说明你的技术判断力在退化你需要加大投入。实践二定期做技术巡检——不需要写代码但需要看代码每周或每两周给自己留30到60分钟专门看团队的代码。不是看bug修复和小改动而是看核心模块的架构变更、关键链路的重构、新引入的技术栈。你需要关注的不是这段代码写得对不对而是团队的代码质量在变好还是变差有没有在积累技术债新引入的技术是否被合理使用这些信息不会自动跑到你面前。你需要主动去看才能保持对团队技术状态的整体感知。实践三保持一个技术雷达——知道业界在做什么你不需要追逐每一个新技术但你需要知道大的趋势和方向。具体的做法关注3-5个你关注的技术领域的高质量信息源——可以是技术博客、GitHub trending、行业技术大会的议题清单、你信任的技术团队的公开分享。你不需要每一篇都深入阅读但你需要扫一眼标题和摘要。这样当团队里有人提出我们是不是该用Rust重写这个服务的时候你不至于一脸懵——你知道Rust适合什么场景也知道重写一个服务的成本和风险。技术雷达不是让你成为技术专家是让你保持不至于被忽悠的底线。实践四偶尔亲手做一个小项目或小改动注意这里说的不是在团队的核心系统上写代码。很多管理者会犯一个错误——他们觉得保持技术能力就是继续在团队的主力系统上写代码。但这样做有两个问题一是你的代码质量可能不如以前毕竟不天天写了影响团队标准二是你在主力系统上写代码会让团队困惑——“这个PR是该由你来提还是不该你提”更好的方式是给自己找一个小项目。可以是一个内部工具、一个自动化脚本、一个side project。不需要多复杂但需要让你亲手写代码、亲手调bug、亲手经历从写到跑通的完整过程。这个过程的目的是让你保持手感能力——不只是判断力还有那种打开终端、敲下命令、看到结果的本能反应。手感不需要天天练但不能完全丢。一旦丢了想捡回来要花的时间比你想象的长。陈钊的实践清单周一上午陈钊在笔记本上写下了四个问题上周的技术方案评审会我认真看了方案吗——没有。总监催得急我匆匆扫了一眼就让团队过了。这两周我看过团队的代码吗——没有。小李的PR我还是因为出了问题才看的。我最近有没有关注过技术动态——好像看了几篇公众号推文但都是标题党没什么营养价值。我上一次亲手写代码是什么时候——貌似很久了想不起来了。四个答案都让他不太舒服。但他没有让自己沉浸在我怎么变成这样了的情绪里。他拿起笔给自己写了一个技术判断力维护计划每周必做参加至少一次技术方案评审提前10分钟看方案文档准备3个问题花30分钟做一次技术巡检——看这周的核心代码变更每两周必做花1小时浏览技术信息源更新自己的技术雷达每月必做亲手做一个小的技术项目或改动保持手感他把这个计划贴在了工位旁边的白板上。不是因为觉得自己做不到而是因为他知道——如果不写下来这些事永远不会被排进他的日程里。管理者的时间永远是别人的只有你自己写下来的东西才有可能属于你。他又想起了上周老赵给的那个反馈“你得学会拒绝。”学会拒绝不合理的需求是一种能力学会拒绝时间的碎片化侵蚀也是一种能力。保持自己的技术判断力从保护时间开始。转身还没有完第四周接近尾声的时候陈钊回顾了一下晋升技术管理者的这一个月。从第一天坐在那个熟悉的工位上不知道该做什么到现在陈钊经历了一次初步的转身。他翻开笔记本看到了从第一天到现在自己记下的那些东西第一周慌——坐在那个熟悉的工位上不知道该做什么。第二周忙——每天回两百多条消息开四到六个会真正写代码的时间少得可怜知道自己在做什么但没有节奏。第二周下班前压——一次线上事故上级的电话让他意识到向上管理的本质不是汇报是让上级放心。第三周尬——茶水间里小张那声变了调的钊哥让他明白关系的转型不是自然而然就会发生的。第四周虚——看代码看不进去了他开始怀疑自己还是不是一个技术人。这五种情绪不是弱点是信号。每一种情绪都在告诉他你正在成长。慌告诉你你需要重新定义自己的角色。忙告诉你你需要管理自己的时间和精力。压告诉你你需要学会和上级建立信任。尬告诉你你需要重新建立人际边界。虚告诉你你需要找到管理语境下的技术存在感。陈钊站在办公室的窗边看了一眼窗外的天。天色渐暗但远处的写字楼还亮着灯。他想起第一天的自己——坐在那个位置上像个新入职的实习生一样手足无措。现在回头看四周好像很长又好像很短。他打开了手机在备忘录里写了一句话“转身不是转身离开是转身面向另一个方向。原来的路还在只是我换了一个看它的角度。”合上手机他看了一眼工位旁边白板上的那张清单——每周评审、每周巡检、每两周雷达、每月手感。还有那张更长一些的每月1v1、团队沟通期望说明、小周onboarding计划、消化老赵学会拒绝的反馈……清单越来越长但状态越来越好了。不是因为什么都解决了。是因为他开始知道——管理这件事没有顿悟的时刻是一周一周地碰到问题、解决问题一个问题一个问题地积累判断力和信任。回头看的时候才发现自己已经渐渐走了很远。这是第一季的最后一篇但不是这个故事的最后一章。第二季方向——让团队交付正确的结果。下期预告《第二季导读方向——让团队交付正确的结果》 ——初步站稳了跟脚之后下一个问题是我在带着团队往哪儿走第二季我们将从需求评审开始沿着一条从接需求到交结果的完整链路拆解技术管理者的第一核心命题——方向。S1E5 完 | 约4300字
