假设你的公司有一个随叫随到的轮转系统。一个人的总是上。一天，您的团队的一名成员收到一个警告，称主PostgreSQL服务器上的磁盘空间将在两小时内耗尽。一小时后，他又收到了一页。30分钟后，磁盘空间耗尽，整个站点宕机。18个小时。好消息是，你的两层架构可以让你的网站和应用保持在线，但你的业务后端已经停止了。你的首席技术官很生气。他说你必须解雇那个随叫随到的工程师。
这是一个困难的局面，但会越来越难。这不是你最优秀员工的失误，你可以指责他们，但最终会用他们的业绩为他们辩护。您的报告在宕机期间是随叫随到的，它不是一个强有力的执行者——而且通常做得并不好。一下子，您就可以对中断进行处罚，触发可能命中注定的终止，并按照您的经理的要求行事。但是这是正确的？你想对你的首席技术官说些什么?
重点不是终极结果:将拉森承担了责任，要求首席技术官解雇他或者他和他的报告保住了他们的工作，工程师得到了更好的培训。这是为了展示管理可以变得多么复杂——以及为什么如果处理得当，这是一个高度道德的职业。以下是拉尔森对首席技术官的瞬间回应背后的一些考量:如果我解雇了这名工程师，我们向团队传达的信息是，我们会毫不含糊地惩罚错误。不管怎样，这位工程师可能很快就会被解雇。如果这是真的，那么现在解雇他就是在用错误的理由做正确的事情。对于所有参与的人来说，我们会完全失去这个信息。如果是这样的话，对团队的伤害会让我觉得领导团队很不舒服。
这种推理模式在哲学文本中比在商业案例中更常见。虽然他的管理方法在招聘和解雇等时刻受到了最多的考验，但它是在10年的成长和领导快速增长的工程团队中形成的。以下是一些最突出的结果:在Digg他聘请并领导了一个由14名基础设施和UI/UX工程师组成的团队，负责整个Digg.com、api和移动应用程序。在超级在他的领导下，SRE和平台工程团队从5人扩大到70多人，而Uber的工程团队则增长了10倍，超过2000人。现在在条纹Larson领导的基金会工程公司负责创建外部和内部的开发工具、数据和基础设施。他的团队共有170名工程师，分布在都柏林、旧金山、西雅图和远程在18个城市。
在这次独家采访中，拉尔森深入探讨了组织设计的两个关键组成部分。具体来说，他分享了他的测量系统大小而且状态工程团队——不仅以高效率和有效的方式，而且以深切的同理心和道德的方法。拉尔森从他的书，一个优雅的难题:工程管理系统(今天发布)将比率和框架引入团队规模的构建、团队的合并和拆分、评估和加速团队的进程。无论是新上任的还是经验丰富的经理，他都为团队设计提供精确而透彻的思考。就让我们一探究竟吧。
为你喜欢的人做正确的事很容易。当它便宜的时候，很容易做正确的事情。只有在困难的时候才重要。
确定团队规模是组织设计的核心
当管理者深入研究组织设计时，他们通常会触及一些抽象的东西，比如使命，来创建和引导一个团队。“许多经理围绕一个有凝聚力、统一的愿景组建团队。谁没有经历过使命宣言的练习，无论是团队还是公司?首先你要说明你想做什么，然后是你想怎么做。”拉森说。不可避免地有人会提起安然公司的价值观——以及看起来像你自己的原则是如何偏离正轨的。然后你就开始工作，很少再去重温那些宣言和原则。”
经理们经常采取的另一条轨道是根据他们面前的产品或技术来设计团队。“有康威定律，它基本陈述了产品反映了组织。这种现象是双向的，”拉尔森说。“与之相反的是，组织是为了反映产品而建立的。但如果你过多地围绕当前的产品或技术进行设计，你就会让自己陷入反复变化的境地，尤其是在产品迭代、发展、衍生或衰落的时候。这可能会让一个团队陷入永久的旋转循环。”
相反，Larson认为组织设计的根本挑战和基石是团队规模。“最有力的工作单位是一个团结的团队。知道如何一起工作，并善于一起工作的人可以完成真正了不起的事情，”拉尔森说。“当经理们过于字面地围绕当前的产品或架构进行设计时，他们会搅乱人们，失去我认为世界上唯一真正可再生的能源:那些真正喜欢并知道如何一起工作的人。”
有很多很棒的导游招聘而且招聘对那些质量但是拉森注意到数量团队中的人员也是关键。当他从支持一个团队转变为支持一个组织时，他充分认识到对团队进行规模调整的重要性。这时，一系列新的挑战和问题出现了:
我们应该有多少个团队?
我们应该为这个计划创建一个新的团队，还是让一个现有的团队来承担它?
这两个团队的界限是什么?
在拉森看来，这些问题都涉及到团队规模——不仅是在组建团队时，也包括在重组、招聘冻结、冲刺和启动时。虽然他承认团队规模没有统一的规律，但拉尔森已经开发了一个框架，解决了他所面临的大多数情况——以及当团队规模过大或过小时会发生什么。
以下是拉尔森自己的剧本，摘录自他的书:
经理应该支持6到8名工程师。
这给了他们足够的时间来进行积极的指导、协调，并通过撰写策略、领导变革等来推进团队的使命。
技术领导经理(TLMs)．支持少于4名工程师的经理往往扮演TLMs的角色，承担部分设计和实现工作。对于一些人来说，这个角色可以充分发挥他们的优势，但这个角色的职业机会有限。要想成为一名管理者，他们需要更多的时间来培养自己的管理技能。或者，为了向员工工程角色发展，他们会发现很难在技术细节上花足够的时间。
教练．支持超过8或9名工程师的经理通常充当问题的教练和安全网。他们太忙了，没有时间积极投资他们的团队或团队的责任领域。在向更稳定的配置过渡期间，要求经理支持更大的团队是合理的，但这是一个糟糕的现状。
经理的经理应该支持4到6个经理。
这给了他们足够的时间进行指导，与利益相关者保持一致，并在组织中进行合理的投资。另一方面，这也会让他们保持足够的忙碌，这样他们就不会为团队创造工作了。
加大．支持少于四个其他经理的经理应该在一段时间内积极学习问题领域，或者从支持工程师过渡到支持经理。在稳定状态下，这可能会导致人们感觉自己没有被充分利用，或被诱惑去干预日常操作。
教练．与支持一个庞大的工程师团队类似，支持一个庞大的经理团队只会让你成为一个解决问题的教练。
随叫随到轮岗需要8名工程师。
对于生产随叫随到的责任，我发现两层24/7支持需要8名工程师。随着拥有自己的呼机的团队变得越来越主流，这已经成为一个重要的规模限制，我试图确保每个工程团队的稳定状态是8人。
共享的旋转．有时有必要将多个团队聚集在一起，以找到8名工程师，实现24/7随叫随到的轮岗。这是实现团队拥有自己的随叫随到轮换的一个有效的中间步骤，但不是一个很好的长期解决方案。大多数人发现，对他们不熟悉的组件随时待命是不成比例的压力。
小团队(少于四个成员)不是团队。
我赞助过不少只有一两个人的团队，每次我都很后悔。再说一遍:我每次都很后悔。团队的一个重要特性是，他们抽象了组成团队的个体的复杂性。少于4个人的团队是一个充分漏出的抽象，他们的功能与个人没有区别。为了解释一个小团队的交付情况，你必须知道每个随叫随到的班次、假期和中断。
它们也很脆弱，一次偏离就很容易使它们从创新转向辛苦维持技术债务。
保持创新和维护。
一种常见的做法是，在现有团队陷入维护泥潭时，组建一个新团队进行创新。过去我自己也这样做过，但现在我已经开始在现有团队中进行创新。这需要深思熟虑的决策和一些勇气，但作为交换，你将获得更高的士气和学习文化，并将避免创建创新者和维护者的两级系统。
将这些指导原则结合在一起，我开发的剧本令人惊讶地简单而有效:
在稳定状态下，团队应该是6到8人。
要创建一个新团队，可以将现有团队增加到8到10人，然后再将其发展成两个4到5人的团队。
永远不要创建空团队。
不要让经理支持超过8个人的工作。
与所有指导原则一样，这是一种帮助思考规模问题的结构，而不是限制每个异常的约束。任何情况的背景都值得仔细研究，但我越来越发现，例外情况的长期成本超过了我曾经认为的它们的优势。
我开始相信把一个组织分成8个部分可以让你看到他们的未来。了解经理的工作量，你就能自信地预测未来。
拉尔森关于团队规模的基本框架不仅导致组织健康，而且还导致更有效和更道德的管理实践。以下是这个系统可以提供的:
清晰的职业轨迹。
“组织中领导的首要目标是分配稀缺物品的使用权。时间和预算经常被提及，但同样稀缺的是管理机会——尤其是经理中的经理角色。假设经理与工程师的比例为1:8，或者经理与经理的比例为1:40。或者每个团队只有几个技术领导，每个组织只有几个工程师。”
“当团队的标准规模确定后，几乎每一个职业机会都会受到限制。会有新的角色类型，但团队会成长，萌芽，这些团队规模的比例会重置。鉴于此，管理者和他们的团队对如何和当一个组织会有管理的机会。这种一致性和透明度对所有相关人员都有好处。结合职业的对话在美国，这种体系为设定职业预期铺平了一条更平坦的道路。”
对每份报告进行有意义的投资．
“在一家快速增长的公司，团队比例会波动。经理们可能会花更多的时间在新员工身上，而不是老员工身上。这是安迪·格罗夫的经典方法高输出管理他说，经理们每周应该花半天左右的时间来撰写每份报告。这不是你真正花的时间与拉尔森说:“每个人都需要有独立的时间来评估、发展和反思自己的工作领域。”“面对面处理报告的最少时间是每周花一个小时和团队中的每个人在一起，尤其是当你是部门经理的时候。然后，根据你的结构，你会有三到四个真正重要的同行，比如一个项目经理合伙人。你将和每一个人相处半个小时。”
现在让我们来计算一下这对一个有8名工程师的经理意味着什么，以及她的日程安排和其他任务是什么样子的。“8个工程师意味着1:1的8个小时。假设你有四个同龄人，你每周和他们相处半小时。现在你需要10个小时。然后是每周的团队会议，比如几个sprint签入和一个更大的团队会议。现在一周工作12小时。当然，你在面试，因为你成长很快。再加上三个小时的面试，你就有15个小时了。然后将会有一个全体员工和跨职能会议，所以我们把人数增加到20人。”
“突然之间，你一周有一半的时间都在开会。对于那些可能也想要思考和做一些事情的人来说，这是一个很高的比例。如果你与一个团队合作了很长时间，你可能会每隔一周将1:1的时间压缩到30分钟，或者将1:1的时间压缩到1小时，”他说。“但当业务快速增长时，总会有沟通和行动的背景，所以我发现，在不造成效率低下和压力的情况下，人们不可能降低承诺。这就是为什么这位经理将团队规模控制在8人以内不仅效率高，而且合乎道德。这段时间对于告知、调整、指导和准备准确、充分地指导和代表他们的工作至关重要。在短期内，减少每份报告的投入或增加报告总量可能是可行的，但我发现，从长期来看，这会侵蚀团队。”
向上移动，腾出空间．
“我们讨论的主要是管理者下属的职业发展道路，但管理者自己也必须花时间发展和获得晋升。管理者通过团队之外的工作来做到这一点，而不仅仅是团队内部和团队内部的工作。有道德的经理只有在团队运作顺利的情况下才会这样做——这是严格控制规模的另一个原因——但仍然需要为整个公司的努力留出时间。”
“对于忙碌的经理们来说，跨公司的工作通常仍然会出现在周末的清单上，但这不应该。当然，经理想要像其他员工一样成长，但是道德经理意识到，她成长到一个新职位对她的员工和组织都是必要的，这样她的角色就会为团队或组织的其他人提供一个开放的机会。”
评估和加速进展
标准规模为团队带来了作为度量单位的一致性，但是团队构建什么以及如何构建需要不同的系统和自己的语言。在下面的框架中，Larson提供了四种不同的团队状态——以及管理者如何识别团队的当前状态，如何在团队状态之间转换时指导团队，以及如何为团队的新状态提供截然不同的支持。以下是拉尔森的系统，摘录自他的书:
一支球队有四种状态
该框架从描述团队及其在周围环境中的表现的词汇表开始。
团队被划分为四个连续的状态:
如果一个团队落后了每周他们的待办事项都比前一周要长。通常情况下，人们非常努力地工作，但却没有取得多大进展，士气低落，用户也表示不满。
一个团队正在踩水，如果他们能够完成关键的工作，但无法开始偿还技术债务或开始重大的新项目。士气更高了一些，但人们仍然在努力工作，你的用户可能看起来更高兴，因为他们知道寻求帮助不会有任何结果。
一个团队在偿还债务的时候他们能够开始偿还技术债务并且开始从债务偿还雪球中受益:你偿还的每一笔债务都会带来更多的时间来偿还更多的债务。
一个团队在创新的时候他们的技术债务一直很低，士气很高，大部分工作都是为了满足新的用户需求。
团队想要从落后来创新，而熵则将它们向后拖曳。每个州都需要不同的策略。
系统修复和战术支持
在这个框架中，团队通过对其当前状态采用适当的系统解决方案来过渡到一个新的状态。作为一名经理，你的职责是为给定的过渡找到正确的系统解决方案，启动这个解决方案，然后尽你所能地支持团队，为解决方案创造空间，让它们发挥神奇的作用。如果您在启动正确的系统解决方案之前跳过到战术上支持团队，那么您将耗尽自己，而没有任何拯救的承诺。
对于每种状态，以下是我发现的最有效的战略解决方案，以及一些关于如何在解决方案实现时支持团队的想法:
1.当球队落后的时候在这种情况下，系统修复方法是雇佣更多的人，直到团队陷入停滞。通过设定用户期望来提供战术支持，围绕你能找到的轻松获胜进行宣传，并注入乐观情绪。需要注意的是，该系统的修复措施是雇佣净新人，增加公司的整体能力。有时人们反而试图从现有的公司获取更多的资源，我对此非常消极。人是不可替代的，一般来说，人最终会在有用的地方结束，所以我对重新分配现有的个人来推动最佳化持怀疑态度。从本质上讲，这种讨论也不可能不政治化，即使每个人都彼此信任和尊重。
2.当摄制组踩水的时候系统修复是巩固团队完成更多事情的努力，并减少并发工作，直到他们能够开始偿还债务(例如，限制正在进行的工作)。从战术上讲，这里的重点是帮助人们从个人的生产力观点过渡到团队的观点。
3.当团队还钱的时候，系统修正是增加时间。一切都已经开始运转，你只需要找到空间，让偿还技术债务的复合价值增长。从策略上尝试找到支持用户的同时还能偿还债务的方法，以避免从用户的角度看消失在技术债务偿还中。特别是对于一个一开始就落后，现在正在偿还债务的团队来说，你的利益相关者可能正在焦急地等待团队开始交付新东西，而你的责任就是防止这种不耐烦导致倒退!
4.创新有点不同，因为你名义上已经到达了连续体的末端，但仍然有一个系统修复!在这种情况下，这是为了在你的团队的时间表中保持足够的空闲时间，团队可以在他们的工作中构建质量，持续创新，并避免回溯。从策略上讲，要确保你的团队所做的工作是有价值的:摆脱创新的最快途径是被视为建立科学项目的团队，这不可避免地会导致团队资金短缺。
我要强调的是，这些修复是缓慢的。这是因为系统积累了几个月或几年的静态，你必须把这些都消耗掉。相反，使这些修复缓慢的相同属性使得它们一旦生效就非常持久!
困难的部分是保持对你的计划的信心——包括你自己的信心和整个组织的信心。在某些时候，你可能想通过重组来摆脱责任，或者可能跳过到一个新的工作，但如果你这样做，你也跳过了你要学习的部分。保持的路径。
管理中最难的部分之一就是等待一个好的选择来导致改变。对于像人类和团队这样的复杂系统，有一个比我们预期的更长时间的滞后。做决定后，给自己和做决定前一样多的耐心。
除了这四个州
拉尔森描述团队及其绩效的系统可能需要实践，但他有一些技巧，可以帮助管理者在他的框架中加快他们的成功。
寻找排水率，而不是拐点。
拉尔森承认进化之间的这四个步骤中的每一个看起来都更像是跳跃式的转变，而不是循序渐进，但这是有原因的:管理者应该给每个过渡足够的时间。“是的，这是州与州之间的巨大跳跃。但这是考虑到团队在两者之间移动时必须有耐心的因素，”拉尔森说。这对经理们来说尤其如此，因为他们可能会做出决定，并期望迅速得到结果。这就是管理团队的可怕之处:成功和失败的区别通常只是对你正在做的事情有信心，并多等一会儿。也许这就是可怕的事情:缺少的成分往往只是时间。”
为了说明这一点，拉尔森举了他职业生涯中的一个例子。“有一次，我们的数据基础设施团队出现了很多中断，我们经常错过sla。我们有一个很棒的团队，但他们感觉压力太大了。感觉没有希望了。他们一直在半夜被传呼。我们做的都是技术性的工作，为什么没有成功呢?“拉森说。“事实证明，我们只需要再坚持两个月，然后事情就发生了转变。回想起来，我们没有考虑到排水技术债务。在情况好转之前，需要对这些事件进行足够的补救。”
人们倾向于寻找拐点并确定因果关系。拉尔森再次接手了这个故事。“作为管理者，我们总是想指出我们做过的一件事。我们推出了这次Hadoop升级，一切都得到了改善。”拉森说。“但事实上，这是我在一段时间内做了几件事的结果，导致‘突然’反转。”
拐点只是一个非常合理的事情的持续执行。通常，伟大领袖的角色不是想出一个绝妙的策略，而是用一个非常基本的策略说服人们坚持到底。
拐点为团队提供了更好的叙述，也更容易跟踪。但拉尔森建议管理人员帮助团队在不同状态之间导航，追踪“流失”的速度或状态之间的滞后时间，而不是局限于任何单一的转折点。
“以从‘偿还债务’到‘创新’为例。我在这里想得最多的是消耗事件。但你不知道有多少事件没有发生，”拉尔森说。“但在停电的情况下，你可以查看真正发生事故的根本原因的时间，以及找到根本原因的时间是否越来越短。你可以开始得到一个代理，看看你是否在消耗这些潜在事件。一旦您有信心坚持到底，就可以把精力放在寻找代理来验证和预测决策的结果何时实现。当一个团队进入一个新的状态。”
员工士气和用户满意度不会同步变化。
在拉尔森的系统中，他注意到团队士气和用户满意度是如何在不同状态之间波动的。一种假设可能是团队和用户满意度一起移动。拉森说:“通常情况下，当你开始做更多的技术工作时，团队会非常有动力，因为他们知道这是必须要做的，但你的用户往往会非常沮丧，因为你在帮助他们方面做得更少。”“这对于早期的状态尤其如此，比如当你的团队处于‘落后’或‘原地踏步’的状态时。比如你需要雇佣10个人来为你的用户提供所需的产品。通常在这种情况下，你需要暂时为用户做更少的工作，以便到达一个你可以为他们做更多工作的地方。”
这可能是一个艰难的讨论——对你的团队和用户都是如此。“如果到目前为止你已经为用户做了很多事情，你就很难解释为什么他们必须等待，特别是当他们依赖于你的时候。但如果你的团队处于‘落后’或‘原地踏步’的状态，那么无论如何都看不到前进的步伐。”拉森说。“在这里，你必须做出艰难的取舍，不做某事。这是一种选择，你可以在今天继续失败，这样你就可以在明天取得成功，而不是无限期地继续失败。这就是为什么经理必须知道如何引导团队在这些状态下过渡。如果她这样做了，用户和她的团队都会相信折衷方案。”
将它们联系在一起
管理者关注于寻找和雇佣高素质的人才是正确的，但他们也应该同样关注他们管理的团队的规模。例如，工程经理应该支持6到8个开发人员，经理的领导应该支持4到6个经理。保持这种一致性不仅对经理和团队有影响——职业道路、时间管理、技能发展——而且对整个组织都有影响。一旦制定了标准的团队规模，管理者就必须衡量并加快团队的进度。团队状态是连续的，从“落后”到“踩水”，从“偿还债务”到“创新”。团队想要从第一种状态爬到最后一种状态，但是熵把他们拖了回去。每一种状态都需要一个不同的管理者采取不同的策略——以及耐心和信心来完成它。总而言之，编制规模框架和工作表现评核制度不仅可使管理工作更有效率，而且更合乎道德。
“有一次我发现自己直接管理着28个人。我没办法在可预测的时间内见到所有这些人，更不用说完成我剩下的工作了。现在回想起来，我挣扎着度过了难关。我找到了几条技术线索，要带走一些管理人员，每周花一个小时和他们在一起。我和其他人谈了一个小时一个月,”拉尔森说。
“对一些人来说，这可能不是一个明显的错误选择。但我发现与我的员工的沟通和环境开始受到影响。我没有能够给予良好反馈的环境。在这种情况下，管理者要么给出糟糕的反馈，要么给出一般性的、指导性的建议。如果你有自知之明，你会退缩，但那样你就没用了。使用标准的团队规模和使用系统来开发团队不仅仅是工具，而且就像管理者的希波克拉底誓言。它承诺不做伤害，有效地建立一个团队而且认真。”
摘录和图表一个优雅的难题:工程管理系统和礼貌的将拉森．摄影的埃弗雷特Katigbak．
