从工程师到 Tech Lead 的疑惑与挑战

18 个月前，我被提升为团队的技术主管，担任高级全栈工程师。

从某种程度上来说，我的日常工作并没有什么改变：甚至在获得这个头衔之前，我就已经开始审查代码、分配任务，并负责支持和指导我的团队成员了。
另一方面，团队对我的角色的认知以及我对 Tech Lead 的期望发生了很大变化。

我性格坚强，但又有些粗鲁，我真心喜欢帮助和指导别人，但有时我也很容易直言不讳（而且情绪激动）。如果说作为同行开发者，直言不讳是可以接受的，那么作为领导，你就必须更加谨慎了。
我立刻意识到，我必须提升自己的人际交往和沟通技巧。

此外，正式负责管理人员迫使我重新考虑我的个人贡献者角色以及我对其他团队成员的期望。

我的领导之旅才刚刚起步，但过去的18个月已经充满了挑战、疑惑和学习。我在这里分享这些，希望能给所有想成为技术主管的人一些建议，也希望能从经验丰​​富的主管和经理那里获得一些反馈和建议。

产出与结果

个人贡献者和技术主管之间的主要区别在于产出和结果之间的差异。这对我来说仍然有点难以接受，但Yan Cui - The Burning Monk 的这篇文章确实让我大开眼界，并在我的领导力之旅之前和期间一直陪伴着我。

我们或许曾经是忍者程序员、10 倍速开发人员、编程摇滚明星，但事实是，既然我们现在是技术领导者，我们编写的代码就会减少，相信我，我们的效率也会降低。但是，正如上面链接的帖子所总结的那样：

通过帮助 10 名工程师提高 10% 而产生的影响将比您个人的最大产出高出一个数量级。

问责与责任

我是极端所有权的坚定信徒和倡导者。

作为一名工程师，我始终致力于按时完成任务并遵守预算。交付无错误且高质量的代码，预测问题并提出解决方案。

作为技术主管，我感到自己对团队成员所做的每一件事都负有责任。

事情不必如此。

每个团队成员都要对自己的工作内容和工作方式负责。
他负责实现的功能。

如果你不信任你的团队成员，并且觉得要对他们写的每一行代码都负责，你最终会陷入事无巨细的管理。
这对你和你的团队都不利。

对你来说，是因为你被细节所拖累，无法专注于你的目标和团队目标。
对你的团队成员来说，是因为你阻碍了他们真正承担责任，在工作中表达自我，学习和成长。

当然，如果发生了不好的事情，你可能会被追究责任（你不应该把责任全部推到你的团队身上），但是承担责任和承担责任之间有很大的区别。

绩效和团队速度

团队中表现最佳者和表现最差者之间的差异可能很大。（查看我在本文中提到的钟形曲线）

由于上述产出和责任问题，我们可能会倾向于尝试提高标准并要求每个人都按照我们的标准努力工作。

尽管提高标准、设定高目标和严格要求对某些人来说可能充满挑战和激励，但对另一些人来说却可能令人精疲力竭并产生相反的效果。

我们必须学习并接受这样一个事实：人们有不同的技能、不同的学习曲线、不同的动力和动机、不同的生活目标。

接受差异。
认可每个人的努力。

再次引用崔岩的话：

你的目标并不是让每个人都变得像顶尖表演者（或变得像你），而是让他们成为更好的自己。

你可以向他们展示如何更好地（或正确地）编写代码，如何更快地学习，你可以指导他们。你可以以身作则。

但你不能也不应该期望每个人都能像你一样以同样的方式和速度接受改变。

如果你想走得更快，就必须放慢速度

作为一名贡献者，这的确是事实。如果你想变得更快，你必须学习和练习，这可能会让你暂时变慢。但只要你坚持下去，你就会受益匪浅，并意识到自己变得多么快。
简而言之，三个字：磨砺你的斧头

作为领导也是如此：这不仅是因为你当然仍然需要适应新事物、新主题、新的工作方式以及组织工作和会议的方式。更是因为你需要为团队成员留出时间。

你需要时间与人交谈。
你需要了解他们的需求。
你需要尊重他们的节奏。

沟通时不要操之过急。要精准，要有耐心，让对方理解你的信息，要认真倾听。
不要急于在第二天就把所有技术知识都传授给对方。

我以为，如果我把我所知道的一切都以研讨会、午餐会、集体代码评审、结对编程和排序等形式灌输给大家，他们就能学得更快，编程技能也会更快更好。
但这种想法错了。
所有这些都可能让人不知所措。困惑和不安全感可能会在团队中蔓延，而不是提高绩效、动力和团队精神。

就像运动一样，你可以大量锻炼和训练，不断挑战自己的极限，但你也必须给身体休息一天，尊重肌肉所需的再生时间。否则，你非但不会变得更强壮、更快，反而会变得更虚弱，更容易受伤。

留出时间来吸收所学知识，让人们理解和接受变化（范例，过程），以便显示进步。

克制住想要加快速度的冲动。耐心等待。
你的努力终将收获成果。

如果他们不这样做...就接受它。

你的行为的成果

有一天，我与工程总监讨论了我的一些担忧，他提到了《薄伽梵歌》：

“你有权决定你的行为，但你无权决定你行为的结果。为了行动而行动。”

一开始我并没有真正明白这一点，所以在我们聊天之后，我对此进行了一些研究。

重要的是行动本身，而不是行动的结果。你必须做正确的事。也许你力所不及，时间所限，也未必能有所收获。但这并不意味着你停止做正确的事。你或许永远不知道你的行动会带来什么结果。但如果你什么都不做，就不会有任何结果。

我必须说，我并不完全满意这句话，用在领导（或教导）他人身上。因为在我看来，“行动的成果”更多指的是回报而非结果，但我完全同意我们应该做正确的事，无论结果如何。

而且，我猜我的主管想表达的观点是：

专注于你能控制的事情——也就是输入。让输出自然而然地显现出来。

尽你所能。给予他人你的指导、你的知识和你的支持。即使他们没有领悟，你也不必太自责。

对行动的数量和质量要有耐心，但对行动的回报要有耐心。

这引出了下一个同样具有哲学意义的观点，

改变源于内心

你不能强迫人们改变。

当然，你可能在团队中拥有一些权威和权力，但反复强调这一点几乎没有什么帮助。
当然，在某些情况下，你可以采取纪律处分——谴责甚至解雇某人……但这绝不是一个好的领导/经理处理挑战或冲突的方式。

再次强调，这里的关键是分享您的愿景并以身作则。

以身作则

尤其是在技术层面仍然很强的领导岗位上，我们必须成为最佳实践、积极性和积极态度的典范。
我们应该分享我们的知识，并展示如何（或必须如何）完成工作。

带路，不要牵着他们的手去那里（更不要推他们或拖他们！）

指导、支持、赋能、做决定、引导他人、倾听他们的心声，最重要的是，如果他们需要时间来消化我传授的一切，请耐心等待。
这听起来工作量很大！

绝对地！

这就是为什么，其中最重要的一点是，

学会授权

这可能因公司而异，甚至因团队而异，但作为一名技术主管，你很可能仍然在编写大量代码，或者至少负责代码架构、实现设计和代码审查。
当某些功能变得非常关键，或者生产环境中出现严重的错误时，你亲自参与其中是很正常的。不过，通常情况下，可能会有多个优先级最高的任务。

作为团队中最有经验的人，你觉得必须照顾好所有人。
但同时处理多项任务从来都不是好事，要学会委派。
把那些高优先级的任务分配给你的团队成员，指导他们并提供建议，但不要直接一个人包揽所有事情。

抵制接管任务的冲动。是的，你可能会更快，甚至可以编写更好的代码，但你正在剥夺团队成员学习、提高、变得更加独立和增强主人翁意识的机会。

这就是我们要说的，对于我们经验丰富的高级工程师来说，晋升到技术领导职位所面临的最困难的事情之一可能是，正如在这个令人惊叹和鼓舞人心的演讲中提到的那样：

允许团队成员自由地做比你做得更差的工作

我知道，这很难，这很糟糕（而且有点傲慢），但这是事实。

这并不意味着放松警惕并放弃质量，只是接受这样一个事实：为了更大的利益，为了项目，为了保持高昂的积极性并保持心理健康，你必须接受其他有经验或经验较少的开发人员可以做得足够好。

用项目符号进行简单的回顾（当事情变得艰难时，我仍然会不时大声地读给自己听……）

• 你有责任，他们也有责任
• 听
• 要有耐心
• 慢慢来
• 使人们能够
• 代表
• 以身作则
• 让他们按照自己的节奏学习
• 让他们犯错
• 要有耐心
• 关注你对团队的影响，而不是单一任务的产出
• 尊重差异
• 让他们做得比你更糟
• 你无权享受你的行动所造成的成果。
• 要有耐心

照片由Alfred Aloushy在Unsplash上拍摄