致公司管理者：团队规模至关重要，不同阶段不同策略

管理者经常采用的另一个方法是根据他们当前所有的产品或技术设计团队。

假定你公司随时都有员工值班，出现任何意外都会有人及时出现解决。但有一天，团队的某位成员收到一个警告，说PostgreSQL主服务器上的磁盘空间将在两小时内耗尽。然后30分钟后，磁盘空间耗尽，你的整个站点就会宕机。公司的首席技术官十分生气，他让你必须解雇那个随时待命的工程师，以表明你对这件事情的态度。

这件事情的关键不在于最终的结果：威尔•拉尔森（Will Larson）承担了责任，并要求首席技术官解雇那名工程师或者拉尔森将他留下来了，并加强了对工程师的培训。以上的案例是想告诉大家管理工作其实很复杂。以下是拉尔森对首席技术官的反应所做的分析：如果我解雇了这位工程师，向团队传达的信息是，我们会毫不含糊地惩罚犯错误的员工。如果真的这么做了，其余员工肯定会对此事有看法，当然他们也不会把这些看法直接告知我。如果是这样的话，将会给团队带来严重的创伤，而我之后在管理团队时也会觉得很不舒服。

这种推理模式更可能出现在哲学文本中，而不是商业案例中。尽管他的管理方法在招聘和解雇等方面受到了最严峻的考验，但这些方法是从他10年的管理经验中归纳总结出来的。他的管理方法是有一些亮点可寻：在Digg，他雇佣并领导了一个由14名基础设施和UI/UX工程师组成的团队，他们负责整个Digg.com、API和移动应用。在Uber，他领导并将SRE和平台工程团队的规模从5人扩大到70多人，把Uber的工程团队规模扩大了10倍，达到2000多人。现在在Stripe，拉尔森领导着Foundation Engineering，创建适用于外部和内部的开发工具、数据和基础设施。他的团队共有170名工程师，分布在都柏林、旧金山、西雅图等18个城市。

在这次独家采访中，拉尔森深入探讨了组织设计的两个关键组成部分。具体来说，他分享了自己用来衡量工程团队的规模和状态的系统：不仅以一种高效的方式，还以一种含深刻同理心和道德的方法来管理工程团队。拉尔森引入比例和框架来构建团队规模、合并和组建团队，以及评估和加速团队发展。他为经验尚浅和经验丰富的管理者们提供了全面的团队设计思路，内容如下：

确定团队规模是组织设计的核心

当管理者深入研究组织设计时，他们往往执著于一些抽象概念，比如用于创建和定位团队的使命。“许多管理人员围绕着凝聚力，统一的愿景组建团队。不管是团队还是公司都要清楚地知道自己的使命。首先，使命需包括你想要做的事情；其次是你想要怎么做才能达成使命，“拉尔森说。“但当你开始工作时，却很少会重新审视这些原则。“

管理者经常采用的另一个方法是根据他们当前所有的产品或技术设计团队。“康威定律表示，产品反映了组织。可反过来说也成立，组织的构建是为了反映产品。如果你围绕当前的产品或技术进行设计，那么你就要为未来不断发生地变化做好准备，特别是产品迭代，演变，衍生或消失等情况，以便让你的团队处于一个永久循环的状态。“

相反，拉尔森认为组织设计面临的最大挑战是确定团队规模。“最强大的工作单位是有凝聚力的团队。知道如何一起工作并且在一起工作的人可以真正获得成功，“拉尔森说。“当管理者围绕当前的产品或架构进行设计时，会导致人员流失，失去那些真正热爱并且知道如何共同合作的人。”

大多数招聘指导信息都强调团队中人员的素质，但拉尔森注意到团队中人员的数量对于正确行事至关重要。当他从支持团队转向支持组织时，他充分认识到调整团队规模的重要性。

一个团队应有六到八名工程师

这使他们有足够的时间通过编写策略、领导变革等来积极指导、协调和推进团队的使命。也能对其组织进行合理的投资。

实现随叫随到的换班需要八位工程师

八名工程师组成一个团队，是实现随时有人待命的最佳选择。随着拥有自己寻呼机的团队越来越成为主流，这已经成为一个重要的规模限制，我努力确保每个工程团队的人数稳定在8个。

小型团队（少于四名成员）不是真正的团队

我赞助过不少只有一两个人的团队，每次我都后悔。重申：我每次都后悔。团队的一个重要特性是它将团队每个成员的复杂性抽出并重组，少于四个人的团队实则和个人无异，因为抽象泄漏（本应隐藏实现细节的抽象化不可避免地暴露出底层细节与局限性）会带来一系列问题。要了解小团队的交班情况，你必须了解所有的班次、休假和请假。而且这样的团队也很脆弱，但凡有一个人离开就会轻易地将它们从创新团队转变为劳务性团队以维持技术债务。

将创新和维护结合在一起

常规的做法是启动新团队进行创新，但却在维护现有团队方面出现了问题。我自己之前就是这么做的，但我现在已经开始在现有团队中进行创新。这样做的确需要勇气和决心，但作为交换，你将鼓舞团队的士气和增强团队学习氛围，并避免创建一个由创新者和维护者组成的两级系统。

职业发展清晰化

“在组织中，管理人员的主要目标是分配对稀缺事物的访问。时间和预算经常被提及，但没有实际能参与管理的机会，一切都是徒劳。建议将主管和工程师的人数比例设定在1:8；再上一级的主管和工程师的人数比例设定在1:40。或者保证每个团队只有少数技术主管和几位工程师即可，”拉尔森说。

“当团队的标准规模得到确定时，那每个岗位的上升空间基本也就确定了。但随着团队的发展，团队的规模需要重新制定，就会有新的职业角色出现。鉴于此，管理人员及其团队应清楚地了解晋升机会如何以及何时会在组织中出现。这种一致性和透明性为所有参与者信服，该系统为设定职业期望铺平了道路。“

每次汇报都有深远的意义

“在快速发展的公司中，团队人员的比率将会波动。比起花在终身雇员上的时间，管理人员可能会花费更多时间在新员工身上。Andy Grove的High Output Management中的经典方法显示，管理人员每周应在听取汇报上花费大约半天的时间。这不单单指你听汇报的时间，还包括了管理者用于审查、思考这个人工作状态的时间，“拉尔森说。“听取团队中每位成员的汇报所花费的最短时间应是每个人每周一小时，尤其是你成为部门经理后。然后，根据团队现有的结构，你会从中发现三四个比较优秀的小伙伴，比如项目经理合作伙伴。你会再花半个小时和他们每个人聊聊。“

现在让我们计算一下这对管理着八位工程师的主管来说意味着什么。“首先，八位工程师表明每周需用八小时。假设其中四个员工你很满意，还需额外花半小时。那么，你一共需要用10个小时来做这件事。然后加上每周一次的团队会议，那每周最多12个小时。当然，还需加上面试的时间，比如三个小时，那就是共计15个小时。可能还需参加一些类似于跨部门的会议和公司会议，这样加起来就是20个小时左右，”拉尔森说。

“你突然发现，一周有一半的时间都在开会。对于一些想把时间花在思考和行动上的人来说，这个时间比例太高了。如果你已经在团队中工作了很长时间，你可能会把上述的1小时缩短到30分钟；或者是将听取汇报的次数改为每隔一周一次，每次每位员工1小时。”但是当团队业务快速增长时，就存在需要去沟通并采取行动的情况。这也就是为什么我还没有发现人们可以在不降低工作效率和增加压力的前提下，能不按照上述时间成本来进行管理工作。所以，团队管理者不仅要提高工作效率还要确保团队规模达到八个人。“

晋升需面向全体人员

“我们主要讨论的是普通员工的职业发展道路，但管理者本身也必须抽出时间来发展并获得晋升，这就要求管理者不仅要做好团队内部的管理工作，自己所管理团队之外的工作也需认真对待。而只有在内部团队运作顺畅的情况下，才有精力去处理自己团队之外的公司事宜。这也就是为什么需要控制团队的规模，”拉尔森说。

一个团队的四种状态

落后：如果每周他们积压的工作都在增长，那么团队就会落后。通常情况下，如果人们努力工作后没有看到进展，士气就会低落，用户提出的不满就是一种信号。

维持现状：如果一个团队能够完成手上现有的关键工作，但却无法开始偿还技术债务或开始做重要的新项目，他们的状态有所改进但还是存在问题，因为这基本算是在原地踏步而已。人们仍然在努力工作，所以士气有所上涨；用户的满意度也有所提高，因为他们已经知道去哪里寻求帮助。

偿还债务：一个团队在能够开始偿还技术债务时偿还债务，并开始从债务偿还的雪球中受益：你偿还的每一笔债务都会使你有更多时间偿还更多债务。

创新：当技术债务持续保持在较低的状态且大部分工作都能满足新用户的需求时，团队士气就会高涨。这表明团队正处于创新阶段。

系统修复和战术支持

在此框架中，团队通过为其当前状态采用适当的系统解决方案，来过渡到新的状态。作为管理者，你的责任是为给定的转换确定正确的系统解决方案，启动该解决方案，然后尽可能地为团队提供支持，为该解决方案创造空间以实现其魔力。

对于每种状态，以下是我发现的最有效的战略解决方案，以及有关如何在该解决方案取得成果时支持团队的一些想法：

最困难的一点是要对计划有充足的信心，其中包括你自己的信仰和组织的信仰。在某些时候，你可能希望通过重组来调整问责制，或者可能去寻找一份新工作，但如果你这样做，你就会失去一个学习的机会。所以，坚持下去！

拉尔森承认，这四个状态的演变存在跳跃性，但这是有原因的：管理者应该给每个转换足够的时间。“是的，各个状态之间的跳跃性有点大。但这是因为团队在这四个状态之间移动时必须具备足够的耐心，“拉尔森说。“对于那些可能做出决策并期望快速取得成果的管理者来说尤其如此。这是管理团队的可怕之处：成功与失败之间的区别往往只是需要你对自己正在做的事情有信心，并学会等待；需要的可能就只是时间。”

工作士气和用户幸福感步调无法一致

在拉尔森的系统中，他指出了团队士气和用户幸福感如何在各个状态之间波动。“通常当你开始做更多的技术工作时，团队士气会高涨；但是你的用户往往会因为你能给他们提供的帮助变少而感到沮丧。”拉尔森说。“特别是早期的两个阶段。例如，当你的团队处于'落后'或'停滞不前'的状态时，你需要额外雇佣10个人来运送用户需要的东西。通常在这种情况下，你们为了将工作做得更好，为用户带来长远的利益，只能暂时性减少给用户提供服务了。

如果你是为了用户的长远利益考虑，可你要怎么跟用户解释自己需要等待的事实呢？尤其是当用户特别依赖你的时候，用户为什么要为此付出代价呢？但是，当你处于落后或者停滞不前的状态时，你不继续进步，也是一种不负责的状态。所以，你必须要权衡，作出正确的决定。你是选择今天失败，但努力后明天就能获得成功呢？还是选择无限期地失败下去？这就是为什么管理者必须知道如何引导团队过渡到下一个状态。

总结

管理者的确应该专注于寻找和雇用优质人才，但他们同样也应该关注所管理团队的规模。例如，工程经理应该管理六到八名开发人员，高级经理应该管理四到六名经理。保持这种统一性不仅会对管理者和团队产生积极影响还会影响整个组织。一旦确定了标准的团队规模，管理者就必须做好权衡并加快团队的发展进程。让团队从“落后”到“原地踏步”，“还清债务”再到“创新”。团队希望从第一个状态爬到最后状态，但是熵会拖累它们。每个阶段都要求管理者采取不同的策略。总的来说，规模框架和绩效评估系统不仅能增强有效性，还是一种符合道德的管理实践。

“曾经我发现自己直接管理了28个人。在有限的时间里，我根本无法监管到每个人，更不用说完成其他的工作了。我找到一些技术主管来协助我管理，每周花一个小时和这些主管们呆在一起，而每个月花一个小时和剩下的员工谈话，”拉尔森说。“采用标准团队规模和使用系统开发团队能让你快速有效地建立起一个团队。”

Tags： 团队管理 管理者手册 高绩效团队建设

说明： 本文版权归原创作者所有，如有侵权请联系我们删除。转载时须注明出处、保留官方微信、作者和原文超链接。如转自 极创客（微信号：jichuangke）字样。