成为 Tech Lead 时：我是如何平衡编码与教练

原文链接：Becoming a Tech Lead: How I’ve Balanced Coding with Coaching

在拥有许多小型团队的工程组织中，培养能够成为成功的工程师，以及有效导师的 Tech Lead 非常重要。根据公司、 团队或个人的不同，在实践中看起来有很多变化。在HubSpot，我们对 Tech Lead（TL）的定义明确指出：他们应该将大部分时间花在产品上，而不是人。

Tech Lead 负责新工程师的入职，并帮助他们在自己的角色中脱颖而出。但仅此一点不应该是 Tech Lead 的全职责任。那么，为什么新 Tech Lead 的普遍抱怨的是，他们没有足够的时间来编码呢？

在服务型领导与保持富有成效的个人贡献者之间取得平衡可能很难。我花了很多时间来适应它。在我担任 Tech Lead 的第一年里，我从经理那里学到的指导性口头禅是：努力成为其他人的力量倍增器。这意味着要找到一种方法，用于大幅提高同行的效率，以便随着时间的推移获得红利。当你赋予你的团队权力时，你不仅可以收回你作为个人贡献者的时间，而且你的队友也会自己做出惊人的事情。

任何团队的情况都没有灵丹妙药。这些是一些对我有用的学习，可以帮助你重新成为成功的个人贡献者，以及有效的领导者。

教你的团队钓鱼

成为 Tech Lead 之后不久，我意识到我正在接近我的团队的每一个问题，好像我有责任为他们找到答案。我已经接受了仆人式领导的想法。正如您可能想象的那样，这涉及到每个非平凡的问题都会花费大量时间。

为什么你会默认会花时间，来调查一些事情——而它们可以教你聪明的队友为你做？

如今，我试图成为街道地图，而不是司机。我很快就会承认，当我不知道某些事情时 - 通常是 - 但我会描述我接下来要做什么，或者组织中的其他人能够做什么救命。我可能会在这两个人之间进行介绍，或者在一个新工具中提供即兴速成课程，以帮助他们解决问题。

我是这种策略的粉丝，因为它与提出问题的人保持问题和解决方案的所有权。随着时间的推移，您的团队成员也具有指数优势：

• 他们学习如何使用工具，来回答他们自己的问题（指标、监控、调试、内部工具等）
• 他们学习如何咨询新资源，其中有许多其他未来问题的答案（代码搜索、内部维基、知识库、外部文档等）
• 他们在公司里结识新朋友，并建立新的关系

在这一点上，我的队友拥有我没有的各种技能和知识。考虑到我需要花时间自己学习所有这些东西，团队和我们的产品要好得多，因为我没有坚持在他们做之前吸收相同的知识。教导团队捕鱼，并授权他们使用他们可以使用的工具来解决问题。这对于帮助团队扩展，并取得更好的成果至关重要。

忘记 Atlas 的作用

在希腊神话中，阿特拉斯（Atlas）是被谴责将地球与天空分开的上帝。在规模小得多的情况下，我看到 Atlas 和 Tech Lead 在像我这样的团队中的角色有一些相似之处。

作为一名 Tech Lead，我很高兴看到我的团队投入到令人兴奋的新功能，有趣的技术挑战和他们表达的职业兴趣。当我们演示新功能或获得大的性能提升，并且我的队友负责 100％ 的代码时，它对我来说是一种刺激。（这些是我希望我团队的天堂。）

实际上，我工作的产品领域每周都有相当多的中断任务。它们是无计划的，可能是时间敏感的，并且通常没有明确的解决方案。这些可能是客户报告的支持问题，可靠性问题或公司其他团队的内部请求。（那是我觉得，有必要保护我的团队的地球。）

我团队的一位工程师最近告诉我，她有机会在学习使用新框架，并将其应用于重大的重新设计工作时，她享受到了多少。对于那些听说过生产力规则的人来说，它应该是相当熟悉的，开发人员需要长时间不间断的时间，才能发挥最大效果。

听说，谁会想要用 bug 打断这个人？这种方法的最终缺点是，自己承担所有笨拙的工作，可以迅速转变为无休止的追赶游戏。你可以为你的团队提供他们需要专注于更大问题的沉默，但你如何能够抽出时间来解决你自己的项目，从战略角度思考，并帮助你的队友成长？

这是我一直在想的事情，但我发现将每个传入的问题，与每个团队成员的技能和专业知识相匹配是有帮助的。如果他们已经熟悉相关代码，那么它们应该是一个更容易的上下文切换，以便他们在方便的时候留出他们的主项目。如果时间和带宽允许，我甚至会将问题传递给不熟悉问题的工程师，作为他们分支的机会。

如果我有疑问，在点击 Jira 中的“分配”之前，我会明确地问，“嘿，你有时间在接下来的 1-2 天内，看看这个支持问题吗？” 这里的目标是开始一个关于优先级、紧迫性，以及对下一步应该做什么的期望的透明和协作的讨论。

我的主要目标是保持维护的痛苦，使每个团队成员有责任提供高质量的工作。该团队将期望他们能够做出改变。他们也会在以前与他们合作的事情上寻求帮助，所以花时间真正理解代码，而不是发送 bug 驱动的修复，以符合每个人的利益。

最后，我还认为，偶尔感受到这些类型的压力，符合团队的最佳利益。当存在大量漏洞或积压的技术债务时，让团队中的每个人拥有这些东西，也会让他们感到满意，并感受到清理旧的混乱所带来的所有权。

团队需要时间来积累技能和信心，共同处理可能出现的任何中断。然而，如果他们的团队中的工程师，从未被要求拥有他们的工作、切换环境或解决他们的舒适区之外的事情，那么这对 Tech Llead 来说将是一个难以吸取的教训。从长远来看，试图扮演 Atlas 的角色是一种不值得承担的负担。与团队分享会更好。

分享你的宠物石

作为工程师，我们喜欢解决难题。在一个新问题上拿出霰弹枪，并花时间秘密思考如何解决它，可能是非常诱人的。虽然在理智上令人满意，但这并不是让事情做得好或很快的方法。以下示例显示了一个有趣的谜题如何激励他人。

在过去几个月中，我们注意到我们的 Java 项目需要更长时间才能构建。即使我们将项目的构建从 Jenkins 迁移到 Blazar，这应该给我们一个很好的推动，但我们的项目仍然存在问题。然而，在长时间等待最重要的情况下，手头的问题优先于搭建构建时间，因此具有讽刺意味的是：没有得到它所需要的关注。

目前没有时间，但希望构建速度更快，我将所有细节都删除，并将它们放入我们团队的 GitHub 存储库中的 issues 中。我回到我正在做的事情，并认为我会在下雨天回到这个问题上。

那一天在未来出现了，因为我团队的工程师悄然注意到了。两周后，他花时间调试问题，而没有被提示这样做，并且在我们的构建时间内完成了整整 10 分钟。这让他赢得了团队的感激之情，速度的提升使我们更有成效。

如果我囤积了我对这个问题的了解，那自然可能不会发生这种情况。在这种情况下，被动地详细说明一个高影响力的问题，就是激励这个人解决问题所需要的。最重要的是，问题比我决定保留给自己的问题早得多。

我确保在团队可以看到它们的地方，提交类似问题的详细信息，例如 GitHub 或者我们的 Trello 板。在我最近与团队沟通的努力中，我已经开始向团队发送简短的季度回顾，以及预览我们最大的项目，还有我们关心他们的原因。每当有时间向我的团队中的某个人提供新任务时，我通常会发现它已经很熟悉了，他们可能已经有了如何处理它的想法。

自由和公开地分享有关团队挑战的知识，将有助于团队的整体准备，并以更及时的方式完成工作。而且，你知道吗？我不会错过那些宠物岩石。

编码更多，更少担心

一开始，平衡责任与有效的个人贡献可能会让人无法理解。最重要的是，考虑一下你可以做些什么来投入时间，从而导致力量倍增。通过将您的工作重点放在团队的自主权，所有权和沟通上，我希望您会发现，随着时间的推移，您需要花费更多的时间进行编码，而更少的日常团队开销。