注:没有特别声明,文中的“我”都指原作者 Camille Fournier

背景介绍

多年前,我成为技术负责人。在这之前我已经晋升为高级工程师,和其他几位高级工程师在一个小团队中工作。我对被提升为技术负责人有点令人惊讶,因为无论是头衔还是年限,我都不是团队中最资深的人。

回想起来,我有一些优势。首先,我不仅仅是一名优秀的工程师,还是一个很好的沟通者。我可以写出清晰的文档,我可以在思维不短路的情况下进行演示,我可以与不同团队、不同角色的人交谈并解释发生了什么。

我也擅长优先级排序。我渴望推进工作并搞清楚下一步需要做什么。最后,我愿意收拾残局,做能做的事情来取得进展。我认为,这种务实的紧迫性(pragmatic urgency)是决定性因素。毕竟,技术负责人是一个领导职位,即使它不是管理职位。

(译者注:领导(lead)意味着需要做出关键性决策,对团队的业务发展负责。管理(manage)意味着塑造团队,有权决定团队的构成。一般而言,技术负责人是技术管理者与其他成员的桥梁。两者的进一步区别,可以参见本系列 tech lead 的第三部分。)

我见过技术负责人陷入困境。

一个印象深刻案例:他是一位了不起的工程师,能编写出色的代码,但讨厌与人交谈,并且经常被技术细节分心。我看着他一个接一个地陷入困境。与此同时,产品经理利用他的缺位,促使团队的其他成员将注意力集中在交付设计不佳又过于激进的功能。

项目一团糟,技术负责人在做什么?他追求下一次重构,因为他确信问题完全出在代码的结构上。你可能熟悉这个故事,因为它无处不在。

这里存在一种误区:认为技术负责人应当由这样的人担当,他们是最有经验的工程师、能够处理最复杂的功能或编写最好的代码的工程师。即使是有经验的经理也会犯这个错。专注于自己的代码细节不是技术负责人的该做的事。

技术负责人的工作到底是什么?我们对这个人有什么期望?

什么是技术负责人

与软件工程中的许多头衔一样,“技术负责人”缺乏一个统一的定义。我能做的最好的事情就是借鉴我自己的经验和其他人的经验。

作为技术负责人,我的工作是继续编写代码,但要承担额外的责任。即做好团队和管理者的衔接,审查我们的功能交付计划、处理项目管理过程的诸多细节。

尽管我不是最资深的人,但我可以成为技术负责人,因为我愿意并且能够承担这个角色的责任,而团队的其他成员更感兴趣的是专注于他们正在编写的软件。

当我在 Rent the Runway (一家公司)的团队创建我们的工程职业发展路径时,我们有意识地选择将技术负责人的角色定义为:工程师可以在职业生涯中的许多点,而不是特定级别上承担的事务

我们采取这种策略是因为我们认识到,随着团队的变化和发展,技术负责人的角色可能由许多不同阶段的工程师担任,并且可能会从一个工程师传递到另一个工程师身上,无需任何一个人改变他的职能或工作级别。

技术负责人在公司与公司之间,甚至在公司内部的团队与团队之间可能并不完全相同。我们从标题中知道,它既是技术职位又是领导角色。它通常是临时的职责,而不是一个永久的头衔。

所以,综上所述:什么是技术负责人?这是我们在 Rent the Runway 的口径:

Rent the Runway 关于技术负责人的描述

技术负责人不是职级上的一个点,而是任何工程师在达到高级水平后都可能承担的一系列职责。

这个角色可能包括也可能不包括人员管理,但如果包括,技术负责人应该按照 RTR 原则管理这些团队成员。这些标准包括:

• 定期(每周)1-1 接触 • 关于职业发展、目标进展的定期反馈:需要改进的地方,并根据表现进行表扬 • 在各种信息中确定成员的发展方向,通过特定项目、外部学习或额外指导帮助他们在这些领域成长

如果技术负责人不直接管理,他们仍然需要为团队的其他成员提供指导和帮助。

技术负责人如何成为一名强大的技术项目经理?他们通过有效委派而非微操管理来实现这一目标

他们关注整个团队的生产力,努力增加团队产出产品的影响力。他们有权为团队做出独立决策,并正在学习如何处理麻烦的管理和领导情景。他们还在学习如何有效地与产品、分析以及其他业务领域的同事合作。

技术负责人还写代码吗

正如 Patrick Kua 在他的书《Talking with Tech Leads》中的描述:负责(软件)开发团队的技术负责人,至少花费 30% 的时间与团队一起编写代码。

技术负责人的位置更像是技术型的项目经理,需要在更大范围内利用他们的专业知识,促使整个团队变得更好。他们可以做出独立的决策,并在团队与其他非技术团队的协调方面发挥重要作用。你会注意到这里没有特定的技术向工作。这是一个高级工程师职位,但将技术负责人等同于团队中最优秀或最有经验的工程师是错误的。

没有其他人的参与,你就无法领导。人际交往能力是我们要求新的技术负责人需要强化的地方,甚至优先于技术专长。与此同时,技术负责人将致力于一项新技术技能学习:项目管理。分解项目的工作与设计系统的工作有很多相似之处,即使对于不想管理他人的工程师来说,学习这项技能也很有价值。

如果你发现自己处于技术负责人的位置,那么恭喜你!有人认为你具备成为团队关键人物的条件。现在是学习一些新技能的时候了!

成为技术负责人

**技术负责人是一种在未授权状态下,练习影响力的机会。**作为技术负责人,我正在领导一个团队,但我们都向同一个技术经理汇报。因此,我不仅要影响我的同事,还要影响我的经理,以确保我们优先聚焦正确的工作。

在我成为技术负责人后,需要扮演的第一个角色是:停止当前所有功能开发并专注于技术债务。这颇具挑战。我很清楚,“技术债务”已经拖了太久了。部署新代码很困难,维护现有的服务成本昂贵,随时需要待命的 on call 令人难受。

我相信我们需要慢下来才能在未来走得快。然而,这对于想要编写有趣新功能的其他开发人员,或我的经理来说并不容易,他们有来自业务方不断的需求。

我通过聚焦不同成员的不同利益点来推销这个想法。对于一些团队成员来说,它是为了提供更可靠的服务;对于另一些人来说说,它能改进迭代速度;而对于其他人来说,它是为了减少随叫随到的负担,以便他们可以睡个好觉。

在与我的经理交谈时,我强调它减少了维护开销。这意味着我们在未来可以上线更多的功能。

技术负责人需要改变关注点

现在工作不再是关于我的。不再是聚焦于最具技术挑战性的想法或最有趣的项目;相反,需要更关注我的团队。我如何赋予他们权力?我如何消除阻碍他们前进的障碍?

进行重构或写一些新的令人兴奋的功能能彰显我的技术实力,也会更有趣。但当时团队需要的是解决技术债务以提高维护效率。

最终,该计划取得了令人难以置信的成功。团队将 on call 警报的数量减少了 50%。在接下来的一个季度中,我们能够完成的上线功能几乎翻了一番。

优秀技术负责人都知道的技巧

你是技术负责人意味着你对软件有所了解,并且你的经理认为你足够成熟,可以承担更大的项目责任。成为一名优秀技术负责人的最大诀窍在于:**愿意摆脱代码并弄清楚如何平衡你的技术和团队所需。**你必须停止依赖你的旧技能,开始学习一些新技能:学习平衡的艺术。

从现在开始,无论你在职业生涯中走到哪里,平衡都可能成为你的核心挑战之一。如果你想对你的工作有自主权,如果你想自由选择你什么时候工作,你必须掌握你的时间和掌握如何使用它。

糟糕的是,你经常需要在擅长且喜欢(例如编写代码)与不擅长事务之间取得平衡。人类更喜欢他们已经掌握的活动,所以当你不得不花更少的时间在熟悉的活动上,转而需要学习新事物时,你会感觉很不舒服。

在项目管理和技术交付之间取得平衡是非常困难的。有些时候你是安排事务的人,有些时候你是被安排的人。通过反复尝试,你需要学会如何管理你的时间,为自己提供适当大小的工作窗口。

最糟糕的情况是让自己被随机拉进会议。如果你每小时都被会议打断,那么很难进入编写代码的最佳状态。即使经过精心安排,你也很少会有时间花几天时间专注于编码问题。

希望你之前已经学会了一些技巧来帮助你分解你自己的工作,这样你就不需要花费多天的精力来完成技术任务。

你还知道,给你的团队制定一个时间表很重要。让他们能够长时间专注于开发,他们需要花几天时间专注于编码解决问题。领导力的一部分是协调其他利益相关者,比如你的上级和产品经理尊重团队的重点,并设置对团队成员来说不会过于紧凑的会面。

技术负责人入门

假设你正与一名产品经理以及其他四名工程师组成的团队合作,进行为期数周的大型工作以发布新特性。技术负责人在此场景中承担多项职责,具体取决于你在项目生命周期中的位置。当然,你需要编写一些代码并做出一些技术决策。但这只是你将扮演的角色之一,甚至可能不是最重要的角色。

技术负责人的主要角色

作为技术负责人,你的首要任务是对工作有一个宽泛的认知,以便你保持项目的进展。从组织和规划需要自己编写的代码,到组织和领导整个项目,该如何进行?

系统架构师和业务分析师

在系统架构和业务分析的角色中,你识别并确定关键系统需要做的转变,以及需要构建的关键功能,以便能够交付即将开展的项目。这里的目标是为估算工作量和排序工作优先级提供一些参考。

你不需要完美地识别项目的每一个元素,但花时间思考与项目相关的外部因素以及可能的问题是很有价值的。

这个角色要求你对系统的整体架构有很好的了解,并对如何设计复杂的软件有深刻的理解。它可能还要求你能够理解业务需求并将其转化为代码。

项目规划师

项目规划师将工作分解为粗略的可交付成果。戴上这顶帽子,你需要找到分解工作的有效方法,以便团队可以高效工作。这里的部分挑战是尽可能多地并行完成富有成效的工作。

这可能很困难,因为你可能习惯于只考虑自己的工作,而不是一群人的工作。找到工作中能够抽象出来打上勾的活动,是实现并行工作的地方是关键。在这个阶段,你需要收集团队专家的意见,并与深入了解软件受影响部分的人交谈,以便他们可以在此处提供详细信息。

作为此过程的一部分,你还需要确定优先级。哪些部分是关键的,哪些是优先级没那么高的?重要部分如何尽早处理?

软件开发人员和团队负责人

软件开发人员和团队负责人编写代码、交流遇到的挑战,进行相应工作的委派。

随着项目的推进,其他人那里出现了意想不到的问题。有时,技术负责人很想勇敢地自己克服这些障碍,加班加点以完成所有工作。作为技术负责人,你应该继续编写代码,但不要写太多。即使你很想自己解决这个问题,你也应当先和团队沟通。

你的产品经理应该尽早了解任何可能的风险。如果有必要,也可以寻求上级经理的帮助。在一个健康的组织中,尽早提出问题并不是可耻的事或有负面反馈的事。

团队经常出现问题,因为他们在产品经理愿意妥协的功能上过度开发。随着大型项目接近交付日期,功能将有所妥协。

寻找委派工作的可能,特别是你自己没时间处理它们。


从这些描述中可以看出,在成为技术负责人的过程中,你必须扮演软件开发人员、系统架构师、业务分析师和团队领导者的角色。

他们知道什么时候该单枪匹马,什么时候将工作委派给他人。

幸运的是,你不必一次完成所有这些任务。一开始可能会不舒服,但你会在时间和练习之间找到平衡。

Ask CTO

Q:

我认为成为一名技术负责人会很棒,但我的经理希望我追踪有关项目状态的所有细节,并告诉她什么时候要做什么事。我真的很讨厌这个状态,为什么没有人告诉我技术负责人职位如此糟糕?

A:

我知道,所有这些新的事物都很难。我喜欢称这个问题为“成功的考验”。虽然在软件开发职业的许多阶段都是如此,但技术负责人阶段无疑是考验最大的。很少有技术负责人获得加薪或职位提升,而且第一次担任技术负责人通常不知道这个位置有多难。

正如我在职位定义中提到的,许多公司认为这更像是一个临时头衔,是你在职业生涯中可能多次承担和摆脱的职责。它可能是晋升到更高级别所必需的垫脚石,但它通常不是一个能带来即时、有形奖励的里程碑。

为什么技术负责人角色的挑战这么大?

技术负责人的职责范围比个人开发职位的高级工程师要广泛得多。技术负责人被要求帮助构建一个项目,然后完成实际规划工作的步骤。技术负责人应确保团队完全理解项目要求。工作被拆解且计划得当,团队有效且表现良好。所有这些都不一定有过管理授权,通常也无任何培训。

而且,实际上,大多数经理都希望他们的技术负责人继续编写几乎与他们担任领导角色之前一样多的代码。这是职责和工作范围的单向增加。如果你是第一次担任技术负责人,那么你的确会很忙。

反过来想,他们给了你考验!好的消息是,承担这种责任最终会让你变得更强大,并为你提供在职业生涯中前进所需的技能。它不会总是像现在看起来那么困难。


关于译者