做技术管理这些年,我发现一个有趣的现象:越是成功的技术Leader,越不愿意分享自己踩过的坑。大家都在讲"如何打造高效团队"、"OKR落地实践"、"技术人才培养体系",却很少有人聊那些让人坐立不安的尴尬时刻。

但恰恰是那些尴尬时刻,构成了技术管理的真实底色。

 

当你意识到自己是瓶颈

 

2019年,我负责的前端团队刚从5人扩到10人。团队扩张后的第三个月,我突然发现一个问题:所有人都在等我review代码。

不是他们不主动,而是我在无意识中给自己设置了一个隐形职责——"技术质量守门人"。每个PR我都要亲自看一遍,每个技术方案我都要参与讨论,每个难题组员都会第一时间找我。

表面上看这是负责任,实际上是灾难。

团队的吞吐量被我一个人的工作时间卡死了。更糟糕的是,我发现自己在培养"等待型工程师"——遇到问题不是先思考,而是先找Leader确认。这不是我想要的团队文化。

那段时间很煎熬。一方面我知道必须放手,另一方面又担心代码质量下滑。最让人尴尬的是,当我试图"授权"时,发现自己根本不知道该怎么做。

过去几年里,我习惯了"事必躬亲就能保证质量"的工作方式。现在要求我"不插手也能保证质量",完全是另一套技能。

后来我做了几件事:
- 强制自己review时只看架构和核心逻辑,细节问题交给senior工程师把关
- 轮值code reviewer制度,每周指定两个人负责PR审核
- 建立技术决策文档模板,要求所有方案先写文档再讨论

但最重要的改变是心态:接受团队会犯错,接受质量会暂时波动。这个过程比想象中痛苦,因为你必须眼睁睁看着一些问题发生,而不是提前拦截。

技术管理有个吊诡之处:你越想控制,越容易失控。

 

招错人的代价

 

2017年,我招过一个看起来很完美的前端工程师。

简历亮眼:大厂背景,参与过复杂项目,技术栈匹配,面试表现出色。薪资谈判时我还为争取到这个人而沾沾自喜。

三个月后我开始怀疑,六个月后确认:这是个错误的决定。

不是技术能力问题。他确实能写代码,也确实完成过大项目。问题在于工作方式和团队文化不匹配。

他习惯单打独斗,不喜欢code review,认为讨论技术方案是浪费时间。在大厂时这可能不是问题——有成熟流程兜底,个人能力突出就能出活。但在金融科技公司,尤其是理财业务这种强合规场景,单兵突进是危险的。

更尴尬的是,我发现自己陷入了沉没成本陷阱。

花了这么多精力招进来,总不能三个月就放弃吧?我试图通过1对1沟通、调整工作内容、安排mentor来改变。又折腾了三个月,效果甚微。

最终我做了决定:试用期结束时不续约。

这个决定做起来很痛苦。一方面是自责——明明是我招错人,为什么要让对方承担代价?另一方面是现实压力——团队本来就人手紧张,少一个人项目怎么办?

但我学到了比技能更重要的东西:文化匹配比能力更难识别,也更难妥协。

如果重来一次,我会在面试时更注重考察协作方式和工作习惯,而不只是技术能力。我会让候选人和团队成员一起pair programming,观察他的沟通风格和接受反馈的态度。

招聘不是买彩票,但也永远无法100%准确。所有技术Leader都招过不合适的人,区别在于你多快意识到,多快做出决定。

拖延只会让错误更贵。

 

当你说不出"我不知道"

 

2020年初,业务方提出一个需求:在理财产品详情页接入第三方推荐算法,根据用户画像动态展示推荐位。

听起来很合理。推荐算法能提升转化率,业务有数据支撑,技术上也有案例可循。产品经理在需求评审会上说:"这个业界都在做,我们也该跟上。"

所有人看着我,等我表态。

那一刻我很想说"我需要研究一下",但张不开口。作为技术负责人,如果连业界常见的技术方案都要"研究一下",会不会显得不专业?

于是我说了"可以实现",然后给出了一个看起来合理的排期。

接下来的一个月是灾难。

算法侧的接口文档和我预期的完全不同,前端要做的不只是"接入推荐位",还要处理AB实验、用户标签、实时数据埋点、降级策略。原本以为两周的工作量,最后用了一个半月。

更糟糕的是,因为一开始拍胸脯说"没问题",后续遇到困难时我根本没脸说"超出预期"。只能带着团队硬扛,每天加班到十点,氛围一度很紧张。

那段时间我反复问自己:为什么不能诚实地说"我不知道"?

可能是因为害怕失去权威。技术Leader的title带来隐形压力——你应该知道所有答案,应该能预判所有风险,应该一眼看穿技术实现的难度。

但这是幻觉。

技术变化太快,业务场景太复杂,没有人能对所有问题都有准确判断。当你假装知道答案时,你不是在保护威信,而是在给团队埋雷。

后来我学会了一个技巧:区分"方向性判断"和"实现细节"。

方向性判断是Leader的职责——这个事该不该做,优先级如何,大致风险在哪。但实现细节需要调研,需要团队一起评估。说"我不知道具体怎么实现,需要一周时间调研"不是无能,是负责。

承认不知道,是技术管理的第一步。

 

你无法讨好所有人

 

2021年绩效季,我给团队做评级。

按照公司规定,10个人必须有20%是3.75(优秀),70%是3.5(符合预期),10%是3.25(待提升)。换句话说,我必须选出一个人打3.25。

这是所有技术Leader都会遇到的难题。

团队里没有混日子的人,每个人都在认真工作。有人技术能力强但不够稳定,有人踏实靠谱但缺少亮点,有人进步很快但base还不够高。怎么选?

我花了整整一周时间纠结。把每个人的贡献列成表格,反复对比,试图找到"客观标准"。但越比越发现,任何标准都会伤害某个人。

最后我选了一个相对年轻、技术上确实有短板的工程师。给他打3.25的时候,我准备了长达30分钟的1对1沟通,解释为什么是他,未来如何改进,我能提供什么帮助。

谈话进行得比预想中顺利。他接受了评级,表示理解,也认可改进方向。我松了一口气。

但一个月后,他提离职了。

离职面谈时他很坦诚:"我知道你的判断可能是对的,但我无法说服自己继续待在一个给我打3.25的团队。"

那一刻我意识到:有些伤害是无法通过"充分沟通"消除的。

绩效评级本质上是残酷的。它用数字把人分成三六九等,无论你怎么解释"这只是当前阶段的评价",都无法抹掉那个数字的刺痛感。

作为Leader,你能做的只是尽可能公平,尽可能透明,但你无法让每个人都满意。

这是技术管理最孤独的地方:很多决定注定会伤害一部分人,而你必须承担那个责任。

 

技术决策的两难

 

2022年,团队面临一个技术选型:要不要引入TypeScript?

支持的理由很充分:类型系统能减少bug,大型项目更易维护,招聘时也是加分项。反对的理由也很实在:学习成本高,现有代码迁移成本大,短期内开发效率会下降。

我组织了三次技术讨论会,听取所有人的意见。结果是:团队分成了两派,各有各的道理,谁也说服不了谁。

最后决策落到我身上。

这种时刻很微妙。你知道无论选哪一边,都会有人不满。支持TypeScript的人会觉得"Leader不够前瞻",反对的人会觉得"Leader不接地气"。

我最终的决定是:核心业务模块强制TypeScript,工具脚本和配置允许JavaScript。这是个妥协方案,两边都不完全满意,但也都能接受。

回过头看,这个决策谈不上英明,只是"还算合理"。

但技术管理的真相就是这样:大部分时候你做的不是"最优解",而是"可接受的次优解"。完美方案通常不存在,或者代价太高。

更重要的是,当你做出决策后,必须为它负责。

如果TypeScript迁移过程中出了问题,你不能说"当初我也犹豫过";如果效果好,你也不能说"我早就看到这一步了"。Leader的作用是承担不确定性,而不是甩锅。

 

那些没人教过你的事

 

我在成为技术Leader之前,以为管理就是"带人做事"。实际上管理是一门处理模糊性的艺术。

没人教你什么时候该坚持,什么时候该妥协。
没人教你怎么在"对团队负责"和"对个人负责"之间找平衡。
没人教你怎么处理那些技术之外的问题——情绪、期望、关系、政治。

所有技术Leader都是在尴尬和犯错中学会管理的。

你会犯错,会做出错误的决定,会伤害一些人,会在某些时刻怀疑自己是否适合这个角色。这些都是正常的。

区别在于:有些人在尴尬时刻选择逃避,装作若无其事;有些人选择面对,从中学习。

我经历过的那些尴尬时刻,没有一个是愉快的。但每一个都让我更清楚"技术管理"到底是什么。

它不是权力和头衔,不是指挥别人做事的能力,不是技术上的高人一等。

它是一种责任:当团队遇到问题时,你是那个必须做决定的人;当决定出错时,你是那个必须承担后果的人;当所有人都不知道怎么办时,你是那个必须指出方向的人——即使你也不确定那个方向是否正确。

这很难,很孤独,也很值得。

因为当你看到团队成长起来,看到曾经需要你review每一行代码的工程师开始独当一面,看到团队文化逐渐成型,你会明白:那些尴尬时刻,是你变成合格Leader的必经之路。

管理没有标准答案,只有属于你的答案。