本文介绍了 Spotify 的矩阵式组织架构，通过项目和职能的矩阵式组合，可以灵活调配人员，迅速捕捉新业务机会，打造灵活、创新的组织架构。原文：The Spotify model: how to create, dissolve, and remix teams to be more dynamic and more innovative

管理传统层级式组织时，最具挑战性的部分之一如何迅速抓住新的机遇，尤其是那些需要利用团队之外的技能组合的机遇。在 Spotify，我们的组织模式使我们能够轻松组建、解散和重组团队，而对个人或管理人员的影响几乎可以忽略不计。这让我们具备了强大的能力来应对无论是短期还是长期的机遇。

过去的情形

在微软和 Adobe 担任经理期间，每当出现需要重新调配团队或为现有团队增加额外职责的情况时，我总会感到棘手。

这类情况时常会出现，比如业务拓展机会，或者与其他产品的整合，通常需要多个专业团队做出配合的努力。

而整合将会造成混乱，因为团队必须改变现有计划，并围绕新的挑战进行协调，同时还要继续朝着现有目标迈进。鉴于团队内部的人力和资源都是由团队内部人员管理的，而经理们仍需负责完成现有任务，所以往往很难激励他们去支持新的工作。

在这种情况下，组建一支新的团队往往是一种解决办法，但这种办法并不总是适用于长期或永久性的项目，因为这实际上是对现有团队管理者的惩罚，并且还需要为新团队寻找一位新的临时管理者。

现有组织还存在另一个问题，那就是如何处理那些项目已被取消的团队。

如果这个团队是表现优异的团队，可以尝试让团队去解决新问题，这个新问题或许与他们的技能和经验相匹配，或许不然。也可以解散这个团队，根据各个团队的需求来分配成员到新团队中，而不是依据个人偏好来进行分配。也可以让员工自己在公司里寻找新职位，如果他们未能成功完成这一任务，那么可能会面临裁员。

这些解决方案最终不仅会惩罚团队成员，还会惩罚他们的管理者，而且这种惩罚往往是由超出他们控制范围的因素导致的。在一个力求创新（这种行为本身就包含了一定程度的失败）的组织中，这传递出了一种与勇于尝试和冒险相悖的信息。

Spotify 如何重组团队

在 Spotify，我们希望打造一个能够人员配置灵活应变、团队组建适应性强的组织架构。

我们认为失败对于学习和创新而言至关重要，因此并不希望解散团队成为一种惩罚手段。我们早在两年前就实施了这一新的组织模式，并一直沿用至今。在这段时间里，技术团队人数从 250 人增加到超过 600 人。工程办公室从三个增加到五个，团队数量也从 30 个增加到超过 70 个。

我们致力于组建全栈式、自主化的团队，这些团队围绕明确而清晰的使命而构建。我们的预期是，一旦团队使命得以完成，这个团队就会解散。

为此，新的团队不断组建，而旧的团队则不断解散，其成员会组建新的团队或者加入现有团队以补充人员。我们并未为这些团队设立正式的管理者职位，而是决定让团队共同承担完成其使命的责任。

采用这种模式后，更换团队成员并不意味着要更换经理，解散团队也不会让经理四处寻找新的工作机会。

我们确实坚信经理应承担起导师的角色，指导下属工作，因此我们有浓厚的管理文化，这种文化只是以矩阵式而非层级式的方式表现出来而已。

为何职能部门负责人（Chapter Lead）比传统管理者更有效

我们的技术经理被称为职能部门负责人，通常负责在其更大的组织内管理特定范围的开发人员，例如移动开发者或后端开发者。一个职能部门负责人通常会在组织内的多个团队中拥有直接下属。

对于个人而言，更换团队是常见的事，但更换经理则较为少见。由于每个团队都要负责其整个技术栈以及所有平台，所以可能会有来自多个职能部门的成员。

举个例子，我所在组织的搜索团队就由来自五个不同职能部门的成员组成：后端部门、移动端部门、键盘和鼠标（桌面端和网页端）部门、敏捷教练部门以及测试部门。此外，还有一个产品负责人和一位用户体验设计师，他们均属于产品部门（该部门的组织方式较为传统）。

职能部门负责人并不直接负责交付成果。相反，他们需要合理安排团队人员配置，与团队成员合作，帮助他们成长，并且与产品负责人和敏捷教练合作，确保团队能够协同高效工作。

由于职能部门负责人能够了解多个团队的情况，通常能够识别出短期或长期的技能需求，并且有权解决这些问题。

有时，这意味着临时调换两个团队中的两名开发人员，以满足特定技能需求。有时意味着将一名开发人员调到另一个团队，以应对短期人力需求。这也意味着，如果需要处理新的任务，各职能部门可以共同组建新团队，从组织内的现有团队中抽调人员来负责该任务。

这种模式对个人而言的好处在于，有很多机会参与新项目或学习新技能，因为会有新的项目定期推出。

何时以及如何对团队进行重组与整合

这种重组并非在整个技术团队中始终保持不变。我们确实有几支长期稳定的团队，专注于产品的特定功能，但即便这些团队也会根据短期或长期的需求将人员进行调配。在组织的某些部分，特别是基础设施团队，往往专注于短期项目，并且更频繁的组建新的团队。这些团队在完成项目后就会解散。

如果我们认为某个团队的任务已不再必要，也会解散该团队。这种情况通常是因为该团队自身未能履行其任务所致。我们对这些结论的重视程度与项目成功完成的程度一样高，因为我们重视“失败”项目所带来的经验教训。将失败视为宝贵经验教训来庆祝，能够激励人们勇于冒险、勇于尝试和勇于创新。

通过努力构建一种既能保证个人稳定性（包括其直属经理和所在部门），同时又能保持组织灵活性和适应性的模式，我们找到了理想的平衡点。这种模式使我们能够将“以敏捷为先”的价值观延伸至团队所完成的工作之外，扩展到整个组织层面。使我们能够专注于创新，并利用那些行动较为缓慢的组织难以应对的机会。

有几家公司试图对我们的模式进行调整，但有一点必须明白：我们的组织模式本身是灵活多变的，会不断变化和发展以满足组织的需求。我们具体的操作方式并不那么重要，重要的是其背后所蕴含的价值观和理念。

如果你希望获得一个充满活力的组织所带来的种种益处，那就需要构建与自身组织的价值观相契合的体系。我认为，核心要求就是赋予团队自主权和决策权。如果无法做到这一点，那么就应该考虑调整现有模式，以消除障碍和瓶颈。

你好，我是俞凡，在 Motorola 做过研发，现在在 Mavenir 做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI 等技术始终保持着浓厚的兴趣，平时喜欢阅读、思考，相信持续学习、终身成长，欢迎一起交流学习。为了方便大家以后能第一时间看到文章，请朋友们关注公众号"DeepNoMind"，并设个星标吧，如果能一键三连(转发、点赞、在看)，则能给我带来更多的支持和动力，激励我持续写下去，和大家共同成长进步！