Spotify的失败的球队目标

2020年4月19日(星期日)·LISTEN·FRANSAIS·日本語で·葡萄牙语(巴西)。

在创业文化的所有诱惑力中，很少有比小团队的速度和敏捷更令人向往的了。在公司发展的同时保持这种感觉是一个挑战。2012年，Spotify分享了它的工作方式，并暗示它已经弄清楚了这一点。1个。

2017年，当我在Spotify斯德哥尔摩总部面试产品管理职位时，我很兴奋地看到Spotify模式正在运作。然而，在第一次面试之前，招聘人员让我大吃一惊。她告诫我，不要指望Spotify成为敏捷乌托邦。

在公司规模在18个月内扩大了两倍，达到3000人后，我加入了公司。我了解到，著名的球队模式只是一种抱负，从来没有完全实施过。我目睹了组织混乱，因为公司领导人逐渐过渡到更传统的管理结构。

当我问我的同事为什么没有删除或更新内容以反映现实时，我从来没有得到过一个好的答案。具有讽刺意味的是，许多人认为这些帖子很适合招聘。我不再在Spotify工作，所以我要分享我的经验，以澄清事实。Spotify团队模式失败了，它也会让你的公司失败。

Spotify模型2的合著者和在Spotify工作的多位敏捷教练多年来一直告诫人们不要复制它。不幸的是，真相并没有像人们想要相信的想法那样迅速或广泛地传播。

“即使在我们写这本书的时候，我们也没有这么做。这部分是雄心壮志，部分是近似值。人们真的很难复制一些根本不存在的东西。“。

“当人们看到我们的所作所为，并认为这是一个他们可以复制和实施的框架时，这让我感到担忧。…。我们现在真的很努力地强调我们也有问题。这并不都是‘闪亮的，一切都运行得很好，我们所有的球队都超级令人惊叹’。“

你可以在不到30分钟的时间里阅读和观看原创内容，或者如果你熟悉的话，可以跳到下一节。这是一个简短的总结。

Spotify的团队被称为“小队”，因为它听起来更酷(不是开玩笑)。一组队伍被组织成一个叫做部落的部门。每个团队都打算成为一家自主的迷你初创公司，由一名产品经理担任某个功能领域的迷你CEO。团队中有具有各种专业知识的设计师和软件工程师。其目的是一个团队应该拥有所有必要的技能，而不需要依赖另一个团队才能取得成功。

产品经理有一个传统的管理结构。团队的产品经理向他们部门的产品总监(“部落首领”)汇报工作。设计师也一样。然而，软件工程师是在团队结构之外进行管理的。

“章节领导”管理软件工程师，专门从事部门内特定类型的软件开发。例如，部门内所有团队的所有从事后端API工作的软件工程师将有一位经理，部门内的所有Android移动工程师将有不同的经理。其目的是允许工程师在部门内的团队之间调动，以最好地满足业务需求，而不必更换经理。

由于没有一位工程经理负责团队中的工程师，产品经理缺乏与他们的迷你CEO角色对等的迷你首席技术官(mini-CTO)。没有一个人对工程团队的交付负责，也没有一个人可以在同等级别的责任下协商工作的优先顺序。

当工程团队内部出现分歧时，产品经理需要与团队中的所有工程师进行谈判。如果工程师不能达成共识，产品经理需要升级到团队中有多少工程专业人员的工程经理那里。一个拥有后端、Web应用程序和移动应用程序工程师的团队可能需要至少3名工程经理参与进来。如果这些工程经理不能达成共识，单个团队的问题将不得不升级到部门的工程主管。

当一家公司很小的时候，团队必须做广泛的工作来交付，并且必须频繁地改变主动性。随着公司从初创公司发展到规模扩大，团队中重复的职能转移到致力于通过减少重复来提高组织效率的新团队。团队越多，团队转移主动性的需要就越少。这两个变化都允许团队更深入、更长远地考虑他们范围内要解决的问题。然而，不能保证更快的迭代。团队为了增加关注度而放弃的每一项责任都会成为新的跨团队依赖。

Spotify没有定义跨团队协作的通用流程。允许每个团队拥有独特的工作方式意味着每个团队在协作时都需要独特的参与方式。整个组织的生产力受到影响。

Spotify模式是在Spotify还是一家小得多的公司时被记录在案的。根据安德斯·艾瓦森(Anders Ivarsson)的说法，这本应该是一个由多部分组成的系列。自治进行了第一次削减，但关于调整和责任的部分从未完成。

自主性需要协调一致。公司的优先事项必须由领导层来定义。自主并不意味着团队可以随心所欲。

必须定义跨团队协作的流程。自治并不意味着让团队自行组织每个问题。

如何衡量成功必须由领导力来定义，这样人们才能有效地协商跨团队依赖的优先顺序。

自主性要求负责任。产品管理要对价值负责。团队负责交付“完成”的增量。成熟的团队可以通过阐明业务价值、风险、学习和下一步最佳行动的能力来证明他们的独立性是合理的。6个。

“如果我要做一件不同的事情，我会说我们不应该把太多的注意力放在自治上。

“每次你有一个新的团队，他们都必须重新发明他们应该如何工作的轮子。也许，仅仅是也许，我们应该拥有“最低限度的可行敏捷性”。你就从这个开始吧。你可以自由选择退出，但人们不应该总是选择加入。

“您从什么时候开始插入这个过程？可能已经太晚了。“

“亨里克·克尼伯格谈到我们不太擅长大型项目，我们仍然不擅长大型项目。”

“如果你的工作方式不一致，人们的行动就会更困难。如果人们行动起来更加困难，那么你的工作方式就更有可能不一致。这只会加强，直到突然之间，你们不再真的为同一家公司工作了。你在为这些怪异的亚文化工作。“。

虽然Spotify让团队可以控制他们的工作方式，但很多人对敏捷实践没有基本的理解。这导致团队反复进行流程调整，盲目地希望找到能够帮助他们改进交付的组合。人们缺乏一种共同语言来有效地讨论过程问题，缺乏解决问题的教育，缺乏评估绩效的经验。这并不是真正的敏捷。只是不是-瀑布。

“敏捷教练”是Spotify提供的内部顾问，他们提供团队来教授和建议流程改进。虽然用意是好的，但没有足够的教练来帮助每一支球队。教练与团队的互动时间很少足以跨越项目的完成时间，从而帮助团队评估绩效。更重要的是，他们对任何事情都没有责任。

协作是一项需要知识和实践的技能。管理者不应该假设人们已经对敏捷实践有了理解。

当公司变得足够大时，团队将需要专门的支持来指导团队内部的规划和构建团队之间的协作。计划管理人员可以对计划过程负责。专职项目经理支持团队的方式类似于专职产品经理和工程经理利用各自能力的方式。

大多数企业只能维持少数几个领域的创新。内部流程很少是使一家公司在市场中脱颖而出的主要创新领域。研究过去可以让企业选择更好的创新领域。

优化以便于理解。为了在您的组织中高效工作，每个人必须学习的每一项新知识都应该根据其价值进行评估。

与Spotify的同义词相比，业务单位、部门、团队和经理更有效地沟通组织结构角色和职责，并且不依附于让创建者失望的工作方式。

您可能已经发现了Spotify模型，因为您试图弄清楚如何组织您的团队。不要停在这里。继续研究。Spotify在博客中写道，经受住时间考验的公司领导人写的东西远远多于Spotify。自从有人类以来，人类就一直在试图弄清楚如何合作。工业时代和信息时代改变了一些限制，但研究组织理论的学者们发现了永恒的真理，即人类需要什么才能在集体中取得成功。

事实证明，Spotify在2012年还没有想出如何在大型组织中保持小团队的速度和灵活性。该公司超越了其同名模式，将目光投向外部，寻找更好的答案。你也应该这样。

我的一些建议与Spotify工作方式涵盖的主题相关：

您的产品工程设计组织中有200多人吗？当我在Fitbit工作时，可伸缩的敏捷框架在那里工作得很好。

不到200人？“由Basecamp塑造”是我打算如何构建我的下一家创业公司的方式。

2：Anders Ivarsson和Henrik Kniberg是Scaling Agile@Spotify白皮书的作者。亨里克在2015年澄清了自己的创建者身份：“人们有时似乎会假设是我发明了Spotify模式。嗯，我肯定没有！我只是个送信的。…。Spotify模式是很多人随着时间的推移进行合作和实验的结果，该模式的许多方面都是在没有我参与的情况下发明的。我当然不想把功劳放在涉案人员的头上。“。

4：你可以做得比Spotify模型更好，Joakim Sundén，2017年视频，幻灯片

第5集：Spotify的情况仍然不太好，以及我们是如何试图解决这个问题的，Jason Yip，2017年视频，幻灯片。

如果从4名Spotify员工那里获得2200多字的第一手经验还不够，请阅读Spotify模式是如何在Spotify之外不适用于这些人的。

封面插图灵感来自泰勒·斯威夫特(Taylor Swift)，他知道一些关于球队进球的事情，但没有版权。如果你忘记了2015年，这里有一个关于球队目标的学期检查。

使用Invision Studio、Affinity Designer和Apple Motion设计。实现与顺风CSS，十一，微软VS代码。在Vision中排版，这是我能找到的与Spotify的Gotham变体最接近的免费选择。

喜欢这篇文章吗？考虑订阅Coil。每月5美元会在你喜欢的创作者之间平分，这是根据你花了多少时间欣赏他们的作品而定的。隐私性是内置的。

©2020杰里米·李。本作品采用知识共享署名-ShareAlike 4.0国际许可协议授权。