techlead

Tech Lead Toolbox

给新 Tech Lead 的五个建议

原文链接:Five pieces of advice for new technical leads

在您的上一个项目中,成功交付了一些令人惊叹的代码后,您的经理为您提供了一个新角色,一个 Tech Lead!但是,这是什么意思?如果您不编码,您可以做些什么来帮助团队?

如果这听起来像你,首先,祝贺你!在 Rally 中,我们将 “Tech Lead” 的角色与 “团队经理” 分开,虽然他们可能经常由同一个人担任,但今天我们只关注谈论前者。在 Rally Health 任职期间,我有机会参与各种各样的项目,从团队中的唯一工程师,到令人惊叹的工程师团队的技术负责人,到几个项目的主管。每个人都有自己的能干。在这些转型中,需要最大的心理转变的转型是从开发人员(又称为 “个人贡献者”)转变为 Tech Lead。

不出所料,我经常从同事那里得到问题,询问我是否对想要制作或正在进行类似过渡的人有任何建议,并发现自己会遇到类似的主题。

如果有什么我尝试向我合作的团队宣传(如果你问他们可能有点太频繁),那就是正确的文档和知识共享是成功项目的关键。本着这种精神,我记录了我在 Rally 中与新 Tech Lead 讨论的五个共同主题,希望它能帮助其他人寻求类似的跳跃。另外,我在每个部分的底部添加了一个 “TLDR”(太长不读),专门对于那些只有 140 个字符或更少共享情感的注意力范围的人。)。

1. 你的工作不再是“你”了。

我不能强调这一点。通常在关于这个主题的博客文章中,您会看到类似的建议,围绕自我训练,不再使用 “我” 这样的代词,并在所有的沟通中有意识地用 “我们” 来替换它们。这是一个很好的建议,但它只是暗示你应该关注的是什么。

您现在负责一个项目和(可能)一个工程师团队。您不再单独负责编写代码,而应该努力使那些代码成为可能。您每天的主要关注点应该是弄清楚如何让您的团队免于分心、积极主动和高效。如果您为您的团队提供他们所需的方向和跑道,您就可以让他们自信地设计和交付成功的解决方案。

幸运的是,如果您正在阅读本文,您将获得一些个人贡献者/工程师的经验,并且您知道如何提供帮助!想想你直接参与的最后一个项目。是什么让你无法有效地完成工作?是什么导致你浪费时间走错了实施路径或兔子洞?你觉得这个项目失去了什么?

回答这些问题是成为优秀 Tech Lead 的关键。注意您的团队停滞在锁定需求,上下文切换以使会议无效,或由于办公室政治,或项目模糊而变得失去动力的时候。这些都是您介入并帮助团队关注的机会。优秀的领导者应该始终在项目的边缘工作,使他们的团队更加成功。

TLDR:专注于解锁和支持您的团队。在路径畅通时,赋予他们权力并信任他们去交付。

2. 保持积极态度并发展关系

您的团队以及公司内的其他领导者,都希望您能够确定项目的基调和进度。没有人愿意在一个每个人都生气、失败或沮丧的团队中工作,如果你的团队对其他人好斗,也不会做任何事情。保持积极和协作的态度不仅是团队生产力的关键,更重要的是不在其中。每个项目都会充满挫折和潜在的陷阱。您的态度和方法可以将这些问题从士气低落的问题,转变为团队建设挑战。

花时间与整个公司的其他团队和人员建立关系。在 Rally 中,我们喜欢在个人和他们的经理之间,以及同事和同事之间定期举行 “一对一” 会议,以帮助促进这些关系和对话。作为领导者,您始终专注于团队的目标。但是,您还应该注意这些目标如何影响公司内部的其他人,他人如何看待项目,以及其他项目或工作如何影响或使您的团队受益。

如果另一个团队听到你的团队做的一些事情,并希望在他们的团队中使用,同时建立在两个团队的利益之上,那么如果你的团队被视为不合作或好斗,他们是否可能会这样做?

如果来自其他团队的人,建立了与您的团队正在进行的工作,而不知道或合作的类似服务或库,会发生什么?最终这两个项目将发生冲突,工作将被丢弃或重复,导致浪费时间和精力。请注意(尽管我不愿意这么说),你的团队目标与其他致力于解决类似问题的团队之间的“协同作用”。尽早合作或定义边界,将在以后节省重复和麻烦。

TLDR:不仅在您的团队中,而且在其他领导和团队中培养积极的态度和协作关系。它将在未来的合作中获得回报。

3. 自信地讲道为什么;好奇地问

让我们谈谈领导一个新项目,以及如何尽早和经常让您的团队参与进来。

作为 Tech Lead,您有责任了解团队正在开展工作的“大局”。事先进行研究,并尝试深入研究,同时获得您知道团队将要问的一些难题的答案。现在,当团队开始工作时,解释(有信心!)目标是什么,最重要的是,为什么它重要以及它将对业务产生什么影响。

如果您的团队了解工作的重要性和工作内容,则可以让他们对工作负责,对工作感到自豪,并在实施过程中做出更相关的决策。您应该基本上将项目及其目标出售给团队。如果您对项目及其影响不感兴趣,您的团队为什么会这样做?

一旦你给团队提供了关于原因的背景信息,现在你需要团队对 “如何” 进行调整。我发现,最好的方法是使用建议的实现,或团队可以讨论的高级流程图(我喜欢流程图)开始对话。请记住,您有依赖关系的上下文,以及是否需要涉及其他团队或服务(您事先调查过,对吧?)。为技术实施提出一个起点,或 “方向” 以获得解决方案。它不必详细或解决所有问题,但让团队中的每个人都与方向保持一致是关键。

然后,您的团队应该感到很舒服,提出不同的解决方案,或制定更详细的计划来实施。不要防守你提出的方向。目标是让团队提出一个他们可以轻松执行的计划,并为这个对话提供一个起点。随着这些讨论的继续(或解决方案到位后),请确保与团队一起验证——它如何满足您所列出的目标,并确保您了解您感到舒适的详细程度。

在此之后,您应该提出足够的问题并充分了解实施计划,以便您可以自信地与其他团队讨论(他们应该向您寻求任何依赖性问题)。相信您的团队可以提供详细信息,但要驱动它们并了解方向。

TLDR:在启动项目时,将项目“出售”给团队,提出技术指导以开始讨论,并了解最终方法,以便能够轻松地向其他人解释。

4. 定义团队流程并推动标准

任何运作良好的工程团队的目标之一应该是,他们高效并且彼此负责。要做到这一点,作为 Tech Lead,您应该尽早帮助定义流程和团队标准,以便为团队提供有关期望的指导。

您可能会考虑尽早定义的事物类型的示例:

  • 团队中代码约定的标准是什么?
  • 是否有可以遵循常规开发任务的标准流程?
  • 如何发布、通讯和处理?
  • 对单元测试、发布测试和负载测试有什么期望?
  • 如何处理代码审查以及在合并代码之前,必须经过什么步骤?
  • 最重要的是:所有这些都记录在某个地方吗?

您的团队将专注于执行功能并解决代码中的问题。如果您和团队已经同意并定义了开发标准,那么它将使团队保持同样的节拍,并允许每个人彼此保持相同的期望。

例如,如果您看到团队正在讨论 REST API 路径的结构,请抓住机会提出他们同意的团队标准,并将其记录下来!现在每个人都对应该为手头的工作做些什么一致,文档可以帮助新团队成员预先确定团队的期望。(奖励:这将有助于减少未来工程师的适应时间!)

除了开发标准之外,不要害怕定义有用的过程。记录完成任务(例如,发布,产品支持或API升级)的可重复的一组步骤,将有助于事情顺利进行,并允许一致的容量规划。如果团队成员预先制定了标准或流程,他们可以更准确地确定工作所需的时间。

当然,这并不意味着永远不可能从这些标准中进行创新或推导,但是当它存在时应该是由团队讨论和商定的有意识的决定,因为这个过程正在发生变化,而不是无意中膨胀超出范围的事情。

TLDR:预先定义质量和流程标准,以便团队可以相互保持责任并进行相同的节拍。详细的文档和一致性是王道。

尽早沟通状态,避免意外

既然您已经定义了项目,并且您的团队正在运行,那么下一步是什么?Tech Lead 最重要的角色之一就是要注意并引导团队,走向迫在眉睫的最后期限。在 Rally 中,项目的 Tech Lead 预期将与产品和项目管理方面的同行合作,以正确领导团队。预计三者将共同决定团队的下一个优先事项,确定技术计划,确定工作规模,最后汇总并传达交付时间表。

一旦启动,团队的领导者正在进行沟通并让利益相关者根据承诺的计划向项目进展情况进行更新,这一点至关重要。项目经理将成为此项目的主要联系人,但作为技术领导者,您需要与状态保持同步,并确保项目计划能够反映工作的实际情况。

在 Rally 中,我们将项目状态与表示项目相对健康的颜色进行通信。绿色表示一切按计划进行,如果项目出现意外转弯或可能偏离轨道,则为黄色,如果项目有可能无法完成其当前轨迹,则为红色。与所有指标一样,我们鼓励所有潜在客户发出消息,并记录事实,而不是人们想要听到的内容(参见:Sam Freund 的博客文章)。为项目传达黄色或红色,并不一定是坏事。

当一个项目明确没有时,向绿色发出信息是一件坏事。

如果您的项目朝远问题前进,那么必须实现它,跟踪问题并提出计划。我鼓励与我一起工作的 Tech Lead——出现问题就尽早发出消息,但总是计划如何让它重回正轨。传递红色状态以及回到绿色的具体计划,远比 “自己解决” 来说是一种更有用的沟通。它允许其他利益相关者,了解他们可以为您和您的团队提供帮助的领域。如果您以这种方式主动发送消息,那么基于您团队工作的依赖关系或业务可交付成果的人应该不会感到惊讶。即使存在问题,每个人都会意识到并应该帮助项目取得成功。

如果你发现你的团队,处在一个他们不可能成功的地方,那么尽早升起指示这个问题的标志,并定义一个计划或路径来解决它。在这种情况下,您的团队永远不应该等到截止日期前,再提出时间线或范围问题。Tech Lead 应与产品和项目管理方面的领导同行合作,使利益相关者了解进展情况,在项目偏离轨道的情况下,通过(例如)重新调整项目期望,要求更多的团队成员提高项目速度,帮助解决潜在的交付失误。或者在他们成为截止期的拦阻者之前解除阻塞。基本上,与你的同事一起跟踪你的团队的进展,并清楚地传达状态。如果项目偏离了正轨,那么就要传达这个状态以及您正在采取(或计划采取)什么行动使它回到正轨上。即使你还没有一个完整的解决方案,让利益相关者了解你的计划是什么,也会让他们尽可能地提供帮助。保持所有相关人员之间的一致性将得到回报。

TLDR:一旦项目进展,请密切关注范围和进展,并在沟通中保持诚实和清晰。尽早提出问题但始终有解决问题的途径。避免给利益相关者带来意外。


就是这些!虽然所有这些提示,可能与每个组织或团队无关,但我发现他们应该对任何希望跳到 “Tech Lead” 的工程师具有建设性。当你承担这个新角色和责任时,请记住首要的是提出问题并获得所需的支持。单独行动可能很有吸引力,但是您的组织正在帮助您成长和学习。找一个导师或组织中的某个人,你觉得他们很自在地提出问题和 “橡皮避免” 解决方案。定期与他们安排时间。您会惊讶地发现,您所面临的问题或困难经常被其他愿意提供建议的人分享和解决。