当你的团队成为每个不合格 Tech Lead 的非官方支持小组
Source: Dev.to
我经常遇到一种模式，每位我交谈过的资深工程师都会立刻认出它，但没有人写下来，因为写出来就等于在质疑那些掌控你职业生涯的人的决定。
公司从领导层的私人关系网中聘请了一位技术负责人——没有真正的技术审查，也没有征求将要在其下工作的团队的意见——仅仅因为关系。于是组织结构图上突然出现了一个新名字，所有人都必须去适应。
前几周看起来还好，因为新人提问是被期待的。但问题并没有停止。你会发现这位技术负责人并没有在学习；他们真的不懂自己应该负责的技术。他们无法深入审查 PR，帮助开发者调试，或者做出架构决策，因为他们对架构的理解不足以评估权衡。
我已经从事软件开发 25 年，见过这种情况在多家公司上演。接下来发生的事总是一样的。
你的团队开始承担两项工作
资深工程师悄悄开始补位。不是因为有人要求，而是因为工作必须完成，而本该指挥的人做不到。他们：
- 回答技术负责人本该回答的问题
- 做技术负责人本该做的决定
- 进行技术负责人本该进行的代码审查
他们的工作量并没有减少；只是一层看不见的工作被叠加上去。
领导层看不到这一点，因为仪表盘看起来正常。工单在流转，代码在发布，没有出现紧急情况。之所以一切顺利，是因为三个人在做四项工作，但这在任何人跟踪的指标中都没有体现。
责备开始向下流
当出现故障——总会有故障——技术负责人需要解释发生了什么。他们无法从技术层面解释，因为他们并不真正理解技术。解释往往变成“我们被基础设施团队卡住了”“流水线出现了问题”或“需求不明确”，总是把责任指向自己团队之外。
领导层接受这种说法，因为技术负责人是他们的朋友。质疑解释就等于质疑自己的招聘决定，而没人会主动这么做。因此，实际上负责维持系统运行的团队会为他们并未造成的问题背负责任。
静默的离职
这里开始变得昂贵。那些在看着能力较弱的人获得头衔和信任的同时，还要双倍工作的大资深工程师并不会爆发。他们不会发送愤怒的邮件；他们只是悄悄决定离开。
- 第一个人离职，领导称之为正常流动。
- 第二个人离职，开始有人担心。
- 第三个人离职，团队的制度性知识瞬间消失。
那个连代码审查都做不到的技术负责人，现在带领一支太过初级、无法弥补他们的团队。所有事情变得更慢、更容易出错、更脆弱。没有人把这归因于十八个月前的招聘决定，因为叙事已经被改写为“市场艰难”和“好人才难以留住”。
不。好人才其实很容易留住。只要停止把不合格的人放在他们的上司位置上即可。
我称之为风险管理戏剧
组织的组织结构图上有一个技术主管的职位。该职位已经有人担任。架构评审按计划进行。从上面看结构似乎是对的。但实际上没有任何合格的人真正负责技术工作。这个头衔只是为了在组织结构图上填一个格子。实际工作是由那些领导层不知道姓名的人员完成的，因为负责弥合这层差距的人忙于向上管理而无暇向下管理。
我把这种模式称为 Risk Management Theater（风险管理戏剧）：表面上有治理，却缺乏实质内容。组织在上层看起来被管理得井井有条，而在底层却完全没有被管理。关于这一概念的更多内容可参见我的文章 “Risk Management Theater”。
如果你曾经是那个在背后默默把事情维系住，而更不合格的人抢走功劳的人，你并不孤单，也并非幻觉。系统正是故意这样运作的——不是因为有人设计它不公平，而是因为受益者没有动力去修正它。
如果这些内容让你产生共鸣，我写了一章免费章节，讨论了一个相关的模式：每日站会如何从协作工具演变为每日表演，开发者每天早上排练要说的话，以免显得落后。相同的动态，不同的仪式。