每个人都是领导者的工程团队

原文请参考 An Engineering Team where Everyone is a Leader



作为一个在不同公司工作了十年的工程师，我注意到大多数软件团队通常都有“经理”和“技术领导”或“高级工程师”。这些是决策者，也是所有项目的领导者。很多工程师会去问这些人，“你觉得我应该怎么做?”或者“你能告诉我下一步是什么吗?”人们会请求许可，而不是原谅——当他们在没有这些人参与的情况下继续前进时，他们会被责骂。在这样的环境中，成为技术主管对其他人来说是一个挑战——特别是当现有的技术主管还在团队中时。在更大的公司，我看到有才华的工程师在内部调换团队，以得到另一个团队主管的机会。



当我从工程转到工程管理时，我想建立这样一个团队，每个人都能成为领导者，每个人都能成为所有者。在这个团队中，每个成员都有技能、信心、授权采取主动、做出决定并领导他人。当人们看到问题时，他们会想，“让我来带头解决这个问题吧。”我之所以想这样做，是因为我相信这样做会带来更好的执行力，更快的职业发展，并且，人们会在团队里待得更久。



最初，我的团队有8名工程师，从初级到高级都有。两年后，我有了一个三倍于原来规模的团队，其中大多数人都已经领导了一个重要的项目，并得到了更有经验的领导的指导和支持。职业发展紧随其后，最初的8名员工和一些后来的人都晋升到下一个级别。人员流失率很低，而且人们似乎喜欢留在团队里。



这篇文章是我用来建立一个工程团队的方法和工具的总结，在这里每个人都是一个领导者，通过在团队中轮换项目领导职责。它包括共享我的团队使用的项目管理期望的谷歌文档指南。这也反映了这种方法带来的痛点。我不能主张这种方法在多大程度上可以起作用。但是，根据我的结果，我建议工程主管们（尤其是一线经理们）考虑将其作为一种选择。



灵感

让更多的人来领导一个团队，我的这一灵感主要来自三个方面:个人的渴望、一本书和一个播客。



我个人的渴望是，我开始成为团队项目管理的瓶颈。当我在2016年加入这个团队时，我们很少有曾经领导过大型项目的工程师。我是带着很多经验加入的: 我是Skype的敏捷教练, Skyscanner的团队负责人。我成为了建立一个基本的项目管理框架的人，这个框架在我们的环境中运行得很好。然而，我发现自己同时运行了太多的项目。在优步，我们当时没有项目经理，所以我决定让其他工程师参与进来。作为第一步，我整理了一份工程项目管理指南;然后，我开始指导一些第一当项目领导的人。



启发我打破每个团队一个“主要”技术领导的现状的书是《让船掉头》。这是一个关于海军上校如何将传统的自上而下的操作模式颠倒为由下而上的主动行动，并取得比军队任何其他团队更好的结果的故事。这是一本通俗读物，根据真实故事改编，涉及核潜艇的复杂细节。上校从一件看似小事开始了文化转变。他要求人们以“我打算做(这个和这个)，因为……”来开始他们所有的谈话，而不是等待命令，不假思索地执行命令。



触动我神经的播客是《哈佛商业评论》 IdeaCast对密歇根大学罗斯商学院教授苏•阿什福德(Sue Ashford)的采访，题为《为什么每个人都应该把自己视为领导者》。她谈论自己从共享领导机制中学到的知识，以及采用这种模式的组织如何有效地工作。尤其让我印象深刻的一句话是：”有领导者身份的人越多，在领导过程中你遇到的风险越少。领导过程中遇到的风险越小，就越能形成更多的有领导者身份的人。”



苏接着说，在事情进展迅速、复杂且有许多依赖关系的地方，共享领导机制有很多好处。在这样的地方，采取领导式行动的人比那些等待上下级的人更有效率。她所说的听起来和软件开发完全一样。她提出了一些鼓励这种行为的方法:“每个经理都可以培养身边的领导者。老板的一种策略是在公开场合授予身份”。这加强了我计划采取的方法。



一个项目，一个工程主管

我的团队有8名工程师，当时正在运行2-3个并行项目。我确定的第一件事是每个项目有一个公开宣布的工程负责人。我这样做是为了明确所有权—就像苏•阿什福德(Sue Ashford)建议在公共场合授予领导者身份一样。我想要给项目负责人自主权来做决定—但同时，让他们对这些决定负责。



作为一名工程经理，我要对我的团队交付项目负责。我下放了责任——决定“如何”去做事情——但保留了责任制。如果项目失败了，有人会遇到麻烦，那仍然是我，而不是项目负责人。



设定领导力期望

到目前为止，我是团队中的“项目”负责人。当我和一位经验丰富的工程师坐下来，请他们领导下一个项目时，他们的第一个问题是我对他们的期望是什么。我没有一个直接的答案，所以我要求了一段时间来收集我的想法，我真正想问的是什么。



最后，我完成了在文档中总结期望，由团队进行编辑。我写了第一个版本。然后团队在每个项目之后修改这个文档。大多数的修改是添加和调整。以下是我要求项目完成的七个期望：



1. 合作。 建立协作框架。

2. 里程碑。 将项目分解为里程碑，并对这些里程碑进行估算。

3. 沟通。 与利益相关者沟通项目状态。

4. 风险。 管理和指出风险。

5. 委托。 帮助团队交付和委派（包括向上和向团队）。

6. 激励。 激励团队前进。

7. 质量。 确保发货产品的整体质量和可靠性。



我的目标是设定期望，以避免微观管理。我试图定义我想要的结果，而不是具体的实现。例如，我喜欢运行每日st站会并一直与我的团队这样做。然而，这并不是我作为领导所期待的结果:我只是希望他们能够与团队定期的交流和更新状态。格式和节奏由他们决定。有些团队更喜欢异步更新; 另一些人喜欢一周做三次站会。我添加了他们可以考虑的想法，但明确表示他们可以选择任何他们想要的形式。



指导，然后辅导前几位领导人

最初的几个项目负责人都是经验丰富的工程师，他们要么以前领导过项目，要么观察过其他人领导过项目。我加入了所有的团队状态更新，观察事情的进展。我经常与项目负责人进行事后沟通，给出反馈和建议。在项目的初始阶段，我更频繁地与项目负责人进行一对一的交流，并从其他团队成员那里收集反馈。



在项目的前几周，新的领导开始对他们的角色感到更舒服。他们更主动了，我的角色慢慢地从指导(提供建议)转变为辅导(提出开放式问题)。



通过每周的书面更新来提高透明度和问责制

像我这样的领导者在委派项目领导时面临的一个挑战是确保事情正在朝着正确的方向发展。在失败的项目案例中，我仍然负有责任。然而，为了给项目的发展提供空间，我不希望过多地参与到日常工作中去。我想观察，但不想干涉。



我发现的一个强大的工具是让领导和团队对自己负责的方法，那就是团队每周发送一封简短的状态更新邮件。更新将总结朝向里程碑的进展，这个过程与上次相比有何变化，以及前一周的进展。风险和延误将被明确地提出来，同时还有减轻的计划。此更新将通过电子邮件发送给我、主要利益相关者和所有团队成员。



这个书面更新被证明是一个在发展强状项目领导时的重要工具，。首先，它需要简洁和良好的文字，同时，牢记目标受众—利益相关者。对于任何一个工程领域的领导职位，良好的写作能力是一项关键技能。其次，它迫使项目负责人跳出工程思维模式，并对利益相关者关心的事情产生共鸣。利益相关者通常关心的是里程碑评估，评估已经取得进展的证据。在风险和范围变更的情况下，他们关心哪些范围变对业务有意义。最后，利益相关者经常直接联系项目负责人。这迫使领导者加强他们的利益相关者管理技能。



做好让初级成员来领导一个项目的准备

当最初的几个项目负责人交付他们的项目时，更多的团队成员表达了对领导力的兴趣。我基本上支持让那些过去有过一些技术领导经验的人尝试一下。然而，团队中很多人都没有。如果他们在没有任何经验的情况下开始领导一个项目，我是否会让他们失败？



第一次做项目的领导需要加强领导能力，否则会陷入困境。项目领导需要做很多事情，从促进会议、报告、指出风险、提出缓解策略等。他们可以开始在一个他们没有正式领导的项目上实践这些技能吗?



与现有的项目负责人一起工作，我建议他们将一些领域委派给更多的初级成员，向他们展示如何去做，然后指导他们。例如，一名资历较浅的成员开始促进常规的站会，然后从项目负责人那里得到反馈。经过大量的准备工作之后，并且项目负责人在场提供支持的情况下，由缺乏经验的成员筹备计划中的会议，或者主持某些利益相关者参加的会议。



尽管这些工程师还没有领导整个项目，但他们正在建立所需的力量。更好的是，项目领导加强了他们的指导能力，同时也释放了他们的一些职责，允许他们将更多的精力放在编码或其他高影响力的活动上。



第一次当领导:先当导演，再当导师

许多月后，从未参与过任何项目的第一位工程师似乎已经准备就绪。我宣布这个人将领导这个项目，给他们与我以前的项目负责人相同的高级指导，然后坐下来观察。



项目进展得很糟糕。事情发展到如此糟糕的地步，我不得不请以前的一个项目负责人介入，让项目回到正轨。在经历了错误之后，结果证明是第一次担任项目领导的人发现领导的期望太模糊了。我把这些期望放在一起，是为那些曾经领导过项目的人准备的，我不想告诉他们“如何”做事情。然而，对于没有经验的人来说，告诉他们“如何”是很重要的。



接下来，我开始对初次接触项目的人采取一种更“规范性”的方法。我建议他们按照一定的流程，按照模板启动会议，每日站会，每周发邮件。我让他们首次采取这种方法，在他们的下一个项目中，他们可以更自由地选择他们的方式。在整个项目期间，只需体验一下这些“标准”工具是如何工作的。我将首次项目检查表部分放在此时的指导文件中。



我也确保有一个经验丰富的项目导师指导和支持第一次领导者，帮助他们成功。我向这个有经验的领导明确表示，第一次项目领导者的成功就是他们的成功。到这个时候，已经有几个人成功地领导了项目，所以找到导师并不难。事后看来，这种师徒关系的建立比“规范性”项目管理方法更重要。



领导者团队—高绩效团队

在开始这个过程的大约1.5年的时间里，现在团队中的12个人中有10人曾经领导过复杂的项目，领导过多个工程师组成的团队。回报开始变得更加明显。



团队的洞察能力大大提高。利益相关者开始欣赏并依赖于每周状态更新的电子邮件，并喜欢这些更新所提供的透明性。事实证明，当利益相关者信任团队，并且理解在幕后发生的事情时，意外的延迟更容易处理。



拥有端到端的特性的工程师变得更加可持续，并且在团队中分布得更好。在基于sprint的环境中，大多数工程师倾向于在开发完成后“忘记”某个特性。他们继续前进，开始下一项工作。尽管项目远未完成: 上线、A/B测试和用户反馈仍在进行中—而且所有这些部分都带有额外的项目风险。我们采用了“项目负责人是第一个进入团队，最后一个离开团队的人”的思维模式。当团队的大部分成员都转换到新项目时，项目负责人仍然在工作，查看使用量，确定是否需要修改某些内容。在传统模式中，每个团队一个技术领导，这种设置会耗尽一个领导。然而，持续的轮换使得这种负责制度更加可持续。



团队成员视自己为领导者，即使没有被分配到项目领导的角色。当与利益相关者交互时，他们当场做出决定，通知相关方。请求原谅，而不是许可，成为了常态。这本身不应该是什么大事，因为像老板一样行事是优步的文化价值观。有趣的是，新员工很快就接受了这种领导思维。



最后，团队成员的职业发展一直很好，而人员流失率一直很低。我提到了我是如何成功地获得了晋升—在一起工作的头两年里，所有的原团队成员都获得了晋升。在很多情况下，展示高质量的领导力和指导他人成为高效的领导者是这些成功过晋升的关键原因。可能职业发展有关，很少有人决定离开团队。那些这样做的人，进入了拥有他们更感兴趣的领域的团队，很快也成为了新团队的领导者。



压力和挑战

这个过程并不是一帆风顺的: 困难也接踵而来。



工程师渴望领导是我必须面对的第一个挑战。当我分享了我的计划，我希望看到每个人最终都能领导一个项目时，更多的人表达了兴趣，而不是有领导的机会。尽管我说得很清楚，不是每个人都能领导，但与此同时，有些人开始不耐烦了。这就是我开始建议人们承担部分项目的所有权的地方:具体来说，项目负责人委派较小的部分。



较小的、单人副项目也是我尝试的一个领域。对于那些渴望领导的人，我建议我们把他们较小的工作当作一个项目来对待。我给他们分配了一个导师，让他们组成一个两人团队，并要求他们遵循通常的期望，包括启动、增量里程碑和每周更新。你可能会认为这是多此一举。也许是这样，但是做这件事的人喜欢它—并且在一个小的、不重要的项目上提高了他们的领导能力。



太多的并行的小项目也成为了一个问题。曾经有一段时间，我的团队是成对工作的，跨多个项目，整个工作都是脱节的。为了解决这个问题，我们开始提前做更多的计划。我还尝试“混合和匹配”并行项目，这样更大的和更小的努力将会更好地平衡。



这种方法的主要缺点是计划和资源分配项目的耗时部分。我发现我和我们的产品经理在计划谁将从事什么项目、下一个项目以及谁将担任领导时遇到了瓶颈。起初，我并不介意: 团队成员的回报和专业成长弥补了我在这里多花的一点时间。随着团队的成长，我们将不得不决定是否保留这种结构，保留更小的团队。



“但是我想编程，不想做项目管理……”早期，一些工程师表示担心我让他们做项目管理。“这难道不是项目经理的职责吗?” 他们问。虽然优步确实有技术项目经理，他们管理的是真正的大型项目，涉及数十个团队，但仅仅是获得状态更新就可能需要花上几天时间去询问不同的人。对于团队范围内的项目，我们给出我们自己的建议。



我向他们提出了两种选择:



1. 我们要么让另一个人做项目管理，而他们对如何完成工作没有发言权。或许我们甚至会考虑聘请外部人员—不是工程师。他们没有工程背景，所以他们会要求更频繁的更新，并有更多的定期记录性会议。此外，每当似乎有什么事情被延迟的时候，他们将不得不去找工程师，问他们如何做和做什么可以减少延迟。

2. 或者他们做项目管理——有自主权地做，并学习一项新技能。尽可能少的做项目管理，只要我们有办法知道我们在哪里，我们是否在正轨上。在这样做的同时，他们培养的技能可能非常有用——普遍适用。如果他们加入了一家科技初创公司，最先聘用的几名科技人员都是软件工程师，他们需要有人帮助他们完成项目。或者，如果他们升职了，以后就会有人需要填补技术项目经理的空缺。要是知道怎么做就好了，不是吗?



在这次谈话之后，每个人都选择了选项2。那时，我们所有的项目都很小，足以管理我们自己。到今天为止，我们确实在一些跨部门、跨团队、跨组织的项目中，我们的确依靠技术项目经理，在这些项目中有太多的利益相关者，工程师无法同时进行管理和工程工作。



更高效、更投入的工程团队:每个人都是领导者的团队

我个人非常成功地建立了一个工程团队，每个人都把自己视为领导者—并且有机会锻炼这种技能。除了要增加经理的后勤负担之外，要领导足够多的大型项目，我认为这种方法没有什么弊端。



在我的环境中，对我有效的方法可能对你无效。但请记住苏•阿什福德(Sue Ashford)在共享领导机制问题上的观点:“在一个事物发展比以前快得多的世界里，事物更加复杂，更加雄心勃勃。如果工作是相互依赖的，需要协调与合作，那么共享领导机制就会有很多回报。(……)我们需要人们在更多的地方采取类似领导的行动。