写点什么

工程领导者应该优先考虑的 3 大事项

作者:Lilac Mohr

  • 2022 年 4 月 18 日
  • 本文字数:4092 字

    阅读完需:约 13 分钟

工程领导者应该优先考虑的3大事项

当今时代,软件开发过程的几乎每一个方面都在加速,从编程语言的速度不断提升到期望更快的价值交付,工程领导者可能会认为,速度和效率应该是团队在新的一年里的首要任务。事实上,工程团队的敏捷转型已经成为近年来大多数领导者的核心战略。

 

作为工程部的临时副总裁,我很清楚团队面临着快速、准确和高效的压力——这些都是一个强大的工程团队的重要品质。然而,我也意识到,工程工作的格局正在迅速发生变化,在团队文化上投资对于整体成功而言最为重要。

 

在我的职业生涯中,我经历了从个人贡献者到团队领导者再到领导者的领导者的转变。每一次转变都伴随着职责范围和优先事项的变化。在我目前的职位上,我领导着一个由 50 多名软件工程师组成的国际团队,他们在跨职能小组中工作,开发我们的 SaaS 产品。正因为如此,我花了很多精力来思考如何建立一种环境,希望可以实现工程卓越,并使我的团队有能力快速、高效地实现高质量交付。对我来说,这一切都始于培养一种以人为本的文化。

 

彼得·德鲁克的经典名言“策略固然重要,但文化还必须有其他成分来滋养”提醒我们,如果没有成功执行,那么战略上的优先事项就没有商业价值,而要取得成果,组织就需要在员工身上投资。“大辞职潮”已经清楚地表明,保持员工满意度和团队健康应该是企业在未来一年的首要任务。工程领导者需要对个人贡献者和团队的表现有一个 360 度的了解。在此背景下,以下是 2022 年我作为工程领导者优先考虑的三大事项。

重视文化建设

最新的研究表明,科技行业是所有行业中离职率最高的行业之一,特别是在过去的一年中,工程师的流失率非常高。虽然有许多因素导致了这种情况,但我认为,对工程师来说,以闪电般的速度交付成果的压力增加,造成了一种最终不可持续的 “焦虑和倦怠(churn and burn)”的工程文化。

 

季度参与度调查和净值推荐分数(NPS)是滞后的健康指标,在补救基本问题的机会窗口关闭后,提供了即将发生的流失信号。在工作前景方面,工程师们有很多选项——因此,对于工程领者来说,在他们的团队中建设一种独特的、有吸引力的文化非常重要。一个重要的做法是,积极审视你的团队文化,确保工程师们感到被支持、受重视。

 

改善工程文化的一个方法是带着感激之心行使领导之责。这是一个领导者能做出的最有影响力的事情之一。如果你庆祝团队所取得的成就,无论是大还是小,并且公开邀请人们提出持续改进的建议,就可以促成一种给予和接受反馈的强大文化。在 Pluralsight,我们有一个专门用来表达感激之情的 Slack 频道。在 Flow 工程部门,我们已经开始了一个叫做“感恩星期五”的传统,鼓励团队成员发布一位在那周帮助过他们的同事的事迹。这种做法不仅加强了整个工程团队之间的联系,而且还促使我们在日常工作中从团队成员身上寻找优点,并寻求帮助他人的机会。这为我们围绕自己所做的工作进行开放的交流奠定了基础。

 

另一方面,缺乏持续反馈的工程文化会导致灾难。在我的职业生涯中,我经历过这样的情况。最常见的反馈失败是,团队成员唯一一次从他们的领导那里收到反馈是在年度绩效评估时。员工如何看待自己的表现和他们的领导如何看待他们的表现之间经常存在脱节,这会导致令人不快的意外和摩擦。取代过时的年度考评流程,领导者应该与团队成员共同制定绩效协议,定期(最好是每周)检查成果和职业发展目标。

 

由于工程本身就是一种创造性的实践,所以让工程师们从事能够激发他们兴趣并允许他们创新的项目至关重要。这可能还包括为工程师提供时间来提升他们的技能以及从事创造性的项目。此外,领导者应该为工程团队培养一种欣赏、协作和心理安全的文化。这包括在一对一的会议中穿插公开、诚实的职业讨论和满意度检查。开放的沟通渠道将帮助你屹立于工程文化之巅。

把握工程师脉搏

建设强大的工程文化,一部分工作是确保决策是由数据驱动的。事实上,最好的领导者往往是数据驱动型的领导者,他们会用具体的证据来巩固团队。在工程领域,使用数据和指标来衡量团队的健康状况尤为重要。

 

甚至,对于工程领导者来说,团队日常的编程工作有时也像是一个黑盒。这就是为什么我们希望可以清晰洞察开发过程。使用工程指标解决方案来提升团队工作流程的可见性,不仅有助于确保效率和质量,而且还可以帮助你衡量员工的成果和士气

 

关于这一理念,有一个很好的例子。几年前,我车里的电路出了问题,速度表上的指针转得飞快。我惊慌失措。当然,我并不是完全不掌握车速——我可以根据我的直觉,或者我周围的车来估计我的速度,但我缺少了一条关键信息,我需要知道自己有没有超速。缺少数据驱动洞察应该会在高层领导者中引发同样的不安。

 

考虑下工程团队在每天的工作中用到的所有工具——从通信软件到票据系统再到 CICD——想象一下,当其中一个应用程序发生故障时,会出现怎样的混乱。软件工程指标应该在系统/流程列表中占有一席之地,没有它,我们无法管理组织。当然,我们会监控云应用何时出现故障,或者数据库使用量何时意外飙升。那么,监控团队的健康状况,主动了解团队成员是否过度工作并有倦怠的风险,或者环境切换和过多移交是否导致我们的效率下降,为什么不是同样重要呢?如果我们没有合适的度量指标,我们就像在没有速度表的情况下开车,仅仅依靠直觉来做出关键的决策,就没有办法以公正的方式来衡量我们的选择的有效性。不对工程团队的数据驱动洞察进行投资,后果将是错失改善和节省组织资金的机会。

 

宏利公司(Manulife)就是一个在组织层面致力于数据驱动文化的好例子。宏利公司希望建立一种以信任为中心的卓越工程文化,但是他们没有足够的数据来正确地把握工程师的脉搏。他们习惯于查看燃尽率和完成的故事数量,而没有真正了解工程团队实际关注的内容。为了改变这种状况,宏利投资了一个软件工程智能平台,为他们提供连续的信息,让他们可以了解团队在哪些方面表现出色,在哪些方面存在困难。这些数据使宏利公司的工程领导者能够真正了解如何以及在哪里做出有意义的改变。此外,收集到的数据让他们可以使用基于证据的指标来衡量业绩,找到工程团队中隐藏的人才。

 

这就是为什么我们说,至关重要的是,要有持续的健康监控与一套强大的指标,让领导者可以及早识别和解决摩擦,并让他们有一个数据驱动的平台可以查看个人的贡献。像宏利公司一样,我发现,监控工程师的日常工作流程,可以帮助我发现那些可能被忽视的杰出员工。此外,它还能让我看到团队中哪个人可能陷入了挣扎。重要的是,要特别关注那些能够推动员工实现其职业目标的指标,并使你能够消除整个团队的瓶颈。

 

专家们一致认为,优先处理建设性的反馈以及与员工开展一对一的对话,对员工的成长和保留来说至关重要。作为一名工程领导者,你必须经常审视自己的工程师,以确保他们在个人和职业意义上都能茁壮成长。我实现这种数据驱动的领导模式的方法是,在一对一和团队会议上使用 Pluralsight Flow 数据。我发现,这强化了我们的工程文化,因为工程师们借此知道了自己受到领导和同事的重视,所以他们不断地寻找方法来增加他们的影响力,并展示给自己的团队。数据是一个强大的工具,从中可以了解我们的行为及结果,并衡量改进情况。

以人为本

如果说我希望你在读完这篇文章之后能有什么收获的话,那就是没有什么会像人一样重要。每一行代码的背后都有一个人,每一次成功交付的背后都有一个团队。工程领导者只有牢记这一点,并利用各种工具和技术做到以人为本,就可以在今年看到惊人的成果,把他们的同行甩在后面。

 

众多研究表明,快乐的员工更有生产力也会更成功。回想一下,你觉得自己全力以赴工作的时刻。你是否感受到了领导的支持和鼓励?你是否有选择的空间和自主权,用你认为有意义的方式完成自己的工作?你的领导是否承认并祝贺你取得的成就?我大胆猜测一下,对我们大多数人来说,这些都是我们进入最佳工作状态的条件。作为领导者,永远不能忘记,我们在审视团队成员时,应首先把他们视为人而不是员工。

 

我之所以如此坚定地倡导以人为本的领导力,源于我自己的职业生涯。我很年轻的时候就开始做软件工程师,第一次是在 17 岁的时候做实习生,然后在 19 岁的时候找到了我的第一份全职工程工作。作为一名年轻女性,在这个男性主导的软件行业中,我知道自己会成为少数派。但我没想到的是,这会让我感到孤立和孤独。我工作过的初创公司不仅以男性为主,在很多情况下,我实际上是整个组织中唯一的女性。我的许多领导并没有试着去了解我这个人,我们大多数的讨论都是围绕着已经完成的任务和剩下的任务。在职业生涯的前 15 年里,我从未真正感到自己属于这里。我从来没有感觉到有人支持我。如果我想在事业上有所进步,就得自己支持自己。

 

因此,我离开公司 5 年,致力于自己的软件项目,并花时间陪伴我年幼的孩子。当我回到工作时,我工作的公司被 Pluralsight 收购了,一切都变了。我现在所在的公司鼓励团队成员在工作中展现真实的自我,把工作与生活的平衡作为优先事项,并要求领导者将个体作为人而不是资源来支持。我不再感到孤独和不自在。我们的组织致力于向团队成员展示各个层面的支持和联盟是什么样子的。即使是最简单的行为,比如同事在会议上为我腾出时间讲话,也对我的归属感产生了深远的影响。

 

作为一名领导者,重要的是要确保每个人的贡献都可见——所有团队成员都有发言权。在我的职业生涯中,我第一次可以自豪地说,我属于这里。这种文化为我自己和团队带来了实实在在的成果,我们都投入了进去,全力以赴地开心工作。

 

随着“大辞职潮”的持续,2022 年工程团队将继续面临高离职率。虽然一定程度的人员流失在所难免,但对于工程领导者来说,这是他们通过工程文化使自己和团队脱颖而出的机会。不管你是否意识到,你所在的团队都有一种文化。在 2022 年,工程领导者有责任将建立以人为本的文化作为首要任务。


作者简介:

Lilac Mohr 领导着 Pluralsight 的 Flow 工程团队。她热衷于帮助个人贡献者和团队使用数据来构建工程工作背后的人类故事。Lilac 有 25 年的科技行业工作经验,拥有计算机信息系统学士学位和统计学硕士学位。她还写了两本中学数学冒险小说,鼓励女孩们投身于 STEM 领域。

 

原文链接:

The Top Three Priorities for Engineering Leaders in 2022 and Beyond

2022 年 4 月 18 日 18:101428

评论

发布
暂无评论
发现更多内容

TiDB 6.0 新特性解读 | TiFlash 新增算子和函数下推

TiDB 社区干货传送门

6.x 实践

6.0体验:TiKV 重启后 Leader 均衡加速

TiDB 社区干货传送门

管理与运维 新版本/特性解读 6.x 实践

MySQL正常执行的SQL在TiDB中变慢了

TiDB 社区干货传送门

管理与运维 故障排查/诊断

TiDB 6.0 新特性解读 | Collation 规则

TiDB 社区干货传送门

6.x 实践

论分布式数据库TiDB架构的“存”与“算”

TiDB 社区干货传送门

数据库架构设计

内存悲观锁原理浅析与实践

TiDB 社区干货传送门

版本测评 新版本/特性解读 6.x 实践 TiKV 底层架构

TiDB 6.0 Book Rush | TiDB 和 Python 的 CRUD 应用开发实践

TiDB 社区干货传送门

6.x 实践

体验TiDB v6.0.0 之TiCDC

TiDB 社区干货传送门

实践案例 6.x 实践

TiDB 冷热存储分离解决方案

TiDB 社区干货传送门

管理与运维 版本测评 6.x 实践 大数据场景实践

TiDB 6.0 新特性解读 | 离线包变更

TiDB 社区干货传送门

6.x 实践

TiDB 集群一次诡异的写入慢问题排查经历

TiDB 社区干货传送门

故障排查/诊断

初体验之rawkv learner recover灾备切换

TiDB 社区干货传送门

文盘Rust -- 领域交互模式如何实现

TiDB 社区干货传送门

开发语言

TiCDC系列分享-01-简述产生背景及使用概况

TiDB 社区干货传送门

迁移 安装 & 部署 扩/缩容 应用适配 大数据场景实践

TiDB 5.1 Write Stalls 应急文档

TiDB 社区干货传送门

实践案例

一次 TiDB 5.1 Write Stall 问题处理

TiDB 社区干货传送门

故障排查/诊断

TiDB 生态工具 -- TiUniManager(原 TiEM)v1.0.0 体验

TiDB 社区干货传送门

6.x 实践

TiDB HTAP特性的应用场景简析

TiDB 社区干货传送门

数据库架构设计

TiDB 4.0 升级 5.1 二三事——避坑指南

TiDB 社区干货传送门

版本升级

体验 TiDB v6.0.0 之 Clinic

TiDB 社区干货传送门

实践案例 6.x 实践

体验 TiDB v6.0.0 之 TiDB 的数据迁移工具 DM-WebUI

TiDB 社区干货传送门

实践案例 6.x 实践

我和tidb 的故事 - 我们终会在平行世界相遇

TiDB 社区干货传送门

一篇文章说透缓存表

TiDB 社区干货传送门

TiDB 源码解读 新版本/特性解读 6.x 实践

关于HTAP与HSAP

TiDB 社区干货传送门

数据库架构设计

TiDB Lightning在数据迁移中的应用与错误处理实践

TiDB 社区干货传送门

迁移 管理与运维 6.x 实践

基于tidbV6.0探索索引优化思路

TiDB 社区干货传送门

实践案例 6.x 实践

基于tidbV6.0探索tiflash在多标签组合场景下的使用

TiDB 社区干货传送门

实践案例 6.x 实践

TiDB v5.4.0 与 v6.0.0 的 sysbench 性能对比

TiDB 社区干货传送门

性能测评 6.x 实践

用一个性能提升了666倍的小案例说明在TiDB中正确使用索引的重要性

TiDB 社区干货传送门

性能调优 实践案例 应用适配

Let's go, TiCheck!

TiDB 社区干货传送门

监控

排查分析Empty regions 较大原因

TiDB 社区干货传送门

性能调优 实践案例 集群管理 管理与运维

工程领导者应该优先考虑的3大事项_文化 & 方法_InfoQ精选文章