高效的技术负责人

从头开始建立团队所学到的教训

如果你在一个团队待得足够久，你就会成为对某个技术栈非常熟悉的人。正如我们许多人所经历的，“非常熟悉”有时意味着“最后一个编辑过此仓库的人”。一开始，当你一边回答新手的问题，一边完成自己的工作时，可能会感到压力山大。然后某一天，你醒来发现自己成了技术主管。恭喜你！但这意味着什么呢？你是如何从那个“技术熟练”的人转变为指导几个工程师技术开发的人的呢？

第一步是信任你的团队能够完成工作。你可能觉得你自己能更快地完成这些工作，你可能是对的——毕竟，这就是为什么他们让你成为技术负责人——因为他们相信你有这个能力。但这不是技术负责人的思维方式。有一天，你团队中的工程师可以达到你目前的水平，而你的职责就是帮助他们达到这样的水平。这让你可以开始思考更高层次的问题：你可以从整体上分析系统。但你如何帮助你领导的工程师们成长？这就是我希望下面能探讨和解决的问题。

在这里我稍微泛化一下，当然这样可能会有点问题。你团队中的每位工程师都是各具特技的个体，你应该将他们每个人当作个体来对待。

然而，我想提出一个有用的光谱，这是我多年来观察到的工程师们的位置。自信在一边，犹豫在另一边。我想明确的是，这两端都没有绝对的好与坏。我发现有一种倾向，即在应该谨慎处理的时候更倾向于奖励自信。我在支付领域工作了很多年，我相信处理公司资金流动的工程师应对其设计决策的后果保持警惕。优秀的工程师会培养这两种特质，在充分考虑各种选择后，他们会坚定地做决定。

注意：启动问题、打滑、不愿分享

犹豫的工程师是那些希望在提交PR之前确保一切都已解决的人。我注意到这通常表现为两种情况。一种是“启动障碍”问题，即他们在开始之前不断回来询问。这并不总是问题（提问是有益的！特别是对于新工程师而言），但有时会导致迟迟无法开始，或者只是开始得太慢。随着时间的推移，当犹豫的工程师变得更加有效时，他们其实不需要再提问了，但这种问题却会变得更加突出。

这个问题其实有一个简单的答案：让他们自己去琢磨琢磨。说清楚一点，我的意思不是不帮助他们，而是要意识到他们其实已经知道答案了。你可以对他们说类似“我觉得这和你之前做的项目X差不多”的话，然后让他们自己去解决。这里的关键在于，作为技术负责人和技术专家的你，可能比他们更清楚自己的技术水平。

在这里的目标是让那些犹豫不决的工程师更自在地处理模糊性。这也将有助于解决“原地打转”的问题，即这些工程师在最后一步之前卡住了。通常，他们会卡在这个地方，因为他们认为自己找到了一个感觉上不是最优解的答案，并且他们认为自己缺少了一些关键的信息。这种情况有时确实存在，但我发现鼓励他们，让他们知道自己的聪明，并且记录下这些缺口并继续前进是有帮助的。在这种情况下，我也乐于分享我的思考过程，以表明我也并不总是有答案。我希望消除技术领导角色的神秘感，让他们更了解我的工作：我提供技术专长，但并没有水晶球来预测未来。

最后，我发现这些工程师有时也会不太愿意分享他们的工作或在技术讨论中带头。这可能源于他们认为自己仍在学习，还没有准备好承担这样的角色，这种感觉。我会在后面提到这一点，但在适当的时候，让他们站出来。鼓励他们展示他们的工作。比如说，你可以问他们：“你解决了一个复杂的问题，你愿意和大家说说吗？”这其实就是一个领导的基本原则，就是要看到好工作，并给予他们应有的肯定。

我见过极度谨慎的工程师成长为全面发展的技术主管。但这并不是说他们的个性发生了根本性的改变。他们仍然保留了谨慎和好奇的天性，这些特质帮助他们成长起来。但他们明白，并不是所有的问题都能得到满意的解答。因此，他们能够在没有100%可证明的正确性保障的情况下，更放心地为他人提供技术贡献。

当心：沮丧、捷径、过度复杂

另一方面，有些工程师一来就准备迎接世界的挑战。说实话，没有什么比一个中级或高级工程师更能让你的生活变得轻松，他们不仅知识丰富，而且充满自信。

然而，有时候这种自信可能是不必要的（暂时）。即使我们有很多经验，学习一个新的代码库仍然需要时间。根据我的经验，那些几乎不提问的新工程师通常会错过一些东西。风险在于，这些疏忽最终会导致重复工作的挫败感。我见过因为一种完全不起作用的方法而导致PR被全面拒绝，甚至在我外出时因为需要撤回某些内容而产生类似的情况。我能理解这种挫败感，没人愿意重复做相同的工作。

过度自信也可能导致工程任务中走捷径和过度复杂化。这些情况源于工程师假定自己找到的解决方案是最优的。你希望你的团队能够自主做出决定，而不需要你事事亲力亲为，但你要确保这些决定能让项目保持正确的方向。

解决这个问题的第一个方法很简单：鼓励你的工程师们提问。（不过，你也应该鼓励像实习生这样的年轻工程师这样做，但原因不同，因为实习生可能觉得提问会暴露他们不知道的东西。）这也意味着你需要保持对团队成员的开放性，这可能会有些困难。如果你有每日站会的话，利用这个机会鼓励他们与你讨论他们正做出的技术决策。这些更新通常包含一些有趣的内容，这也能让站会更加有趣。

你也可以给他们布置一些“作业”，这么说吧。这并不是多余的活儿。他们想要自己去解决问题，你应该鼓励他们这样做。相反，你可以先做一些前期工作，识别项目中可能的技术难点，并通过“让我知道你的决定/想法”来提示他们。当他们回来时，你可以和他们讨论，确保事情在正确的轨道上。同时这也是向他们传授你作为技术主管的经验的机会。

如果你是一个编写技术文档的团队（虽然每个人都应该这样做，但这又是另一个讨论），那么也鼓励编写一页纸的说明。重点并不是要减慢工程师的工作节奏。重点是要确保对复杂的决策给予足够的思考。在谷歌，我们的一个信条是“尊重机会”，因为我们编写的软件有可能服务数十亿用户。满足用户需求的机会值得认真思考并予以充分的尊重。

最后，即使是自信的工程师，在对的论坛分享对自信的工程师来说也非常有益。这不仅给你提供了发表意见的机会，也让其他工程师有机会提供他们的见解。如果做得好，这会培养一种与同事相互交流想法的文化，并且增长团队的集体知识。这也会避免了孤岛式决策的风险，当一个人独自前行时这种情况可能会发生。

我之前提到过，为你的团队设立论坛来分享是很重要的。通常来说，最常见的团队会议，比如每日站会、演示会和状态会，并不是分享更非正式的工程讨论的好地方。我发现一个非常有效的方法是，每周安排一次专门的团队会议，只邀请工程师参加，不包括项目经理，这有助于团队开始建立一种协作文化。

最初，这次会议很可能会成为你作为技术负责人分享知识的主要场所。你可以分享你在这一周与个别工程师讨论的内容，将其分享给整个团队。随着会议的发展，你还可以鼓励团队中的其他工程师讨论他们所解决的问题，并引导他们分享解决问题的过程和思路。重要的是，虽然你也可以在会议中进行演示，但这让你的团队有机会讨论那些难以通过演示来展示的棘手问题。如果会议进行得当，这将有助于团队成员共享个人掌握的知识，形成团队共同的知识库。你的团队能够记住谁负责了特定的项目，并在以后遇到类似的问题时可以寻求他们的帮助。

重要的是，如果你不知道某个问题的答案，这也可以是一个很好的非正式场合来展开讨论（如果会议快到了）。虽然你作为领导者和专家，这也有助于你的团队意识到他们正在建立自己的专业知识，并且他们可以相互依赖。同时，你可以提供高层次的指导，说明你的API和其他相关组件应该如何构建。总之，每个人都会从中获益。

我一直很高兴在工程职业发展方面提供咨询，并帮助构建高效的团队！如果您有任何问题，请通过 me@ianmundy.com 请随时联系我。