导读
最近看了某位同事分享了一篇文章，介绍了亚马逊的STO组织模型，我看完对其工作方法论倍感亲切，想到我所在的团队其实或多或少有了STO的工作模式。不管怎样，我认为STO是一种更灵活、更聚焦的工作模式，我本人在部门参与一些专项活动时其实已经有了STO模式的影子：
首先确定一个onwer（可以是研发或产品），然后拉齐各个资源方（产研、设计甚至市场）成立专项小组聚焦到这个专项去做。owner对整个专项负有最大的责任，所有人需要给owner提供必要的输入，owner必须掌握全局的上下文并提供下一步的方向。
因此我尝试对此做个分享，因为原先的谷歌翻译感觉过于生硬，本人尝试做了人肉的翻译和矫正，如果有不当之处还请评论给建议~
以下是译文：
我想分享一下我参与过的最有趣的一次管理实践。在我最近工作的一家公司，我们实施了亚马逊的单线程负责人(STO)模型，团队中的每个人都向一个领导汇报，包括产品经理、设计师、工程师。你可以把STO模型理解为一种更极致的跨职能团队协作模式，为达成任务，这个团队拥有一切所需的支持。
什么是单线程负责人模型？
这个想法来源于亚马逊，基于一个思想就是一个团队在某个时间段只能聚焦于一件事（区别于同一时间内你需要应付到多个任务上）。在亚马逊，每个团队都应该有一个明确负责的领域（如一个产品领域，基于客户的需求），需要时刻对该领域保持关注。这个团队的领导被称为“单线程负责人”(STO)。
最常见的替代STO模型的是我所说的“3 腿凳”模型。在“3 腿凳”模型中，工程、产品、设计拥有各自独立的领导层级。设计师有时也会向产品报告。但你随后可以组建一个由研发总监领导的工程师团队，并配上一个产品经理（通常是一名设计师）。他们两个或三个成为了一个地方领导团队。
在STO模型中，每个人都属于团队的一份子并都向STO汇报。
单线程负责人推动任务的对齐和所有权划分
我们发现在工程队伍和产品经理间缺乏对齐（目标、节奏不一致），我们打算对团队进行重组使得团队在领域所有权的划分上更加清晰。我们有很多前亚马逊员工，包括CEO，他们都认为让团队重组到STO模型上将会使这些问题得到改善。
在之前的一家公司，我注意到在维护产品、设计师、工程师各自单独的层级关系时会出现一些问题，重组经常以不兼容的方式进行。通常是产品沿着一条线，工程师沿着一条线。或者他们将在同一个组织下完成任务，但他们之间缺乏交流，这将导致经常需要一系列跨团队的重组。
在本地团队中，我经常看到工程经理（EM）和产品经理（PM）不能很好地协作，而且往往做的很差。通常情况下他们的经理会尝试提供指导好让他们完成，但在实践中的表现是，这些团队在六个月或更长时间内无法有效地工作。
因此，甚至在我听到STO模型之前，我就已经在提倡这个模型了。
过度到STO模型
转换到此模型需前要先了解到这些问题：如何定义团队每个人角色，如何组织团队，围绕STO我们将安排怎样的会议和组织结构。
其中一个问题就是我们需要决定谁是单线程负责人，是产品经理还是工程经理？这是一个相当棘手的问题，下面是我认为的利弊：
我们有四个团队：两个产品团队，一个代理团队和一个基础设施团队。每个团队都是3-4个人，我们担心这些团队看起来都太小了。我了解到优秀的人事经理们可以利用团队成员的技能来弥补他在专业上的欠缺。然而对于一个缺乏人事管理经验的人来说，弥补该技能的难度更大。一个产品经理一般不太可能具备人员管理、组织的能力，所以我决定让PM向工程部门汇报。这里有个很好的启发，谁是更好的组织者或人事管理者谁就更应该成为STO。理想的技能组合下，一个经验丰富的人事经理也可以担任产品和流程领导者。后来从Ben Bernard 那里得知，这就是亚马逊的运作方式。
经过重组后，我们最终组建了三个更大的团队。我们将工程经理更换为单线程负责人，然后更改了他们的汇报关系。以便每个团队的设计师和产品经理向新的单线程负责人汇报。我担任经理们的经理，使得我成为了所有产品线的单线程负责人，并负责工程、产品和设计。我们有一个高级产品总监，他向我汇报并专注于高级产品战略。
尽管这违反了单线程负责人，我们有一个由3位核心工程师组成的小组，他们在此层级结构之外向CTO汇报。他们被安排到不同团队中，并且大部分时间都在团队中度过。
我们同时进行的其它调整是引入了每周指标审查会议，STO和PM将根据他们跟踪的指标展示他们了解到的新知识，并在他们的领域进行持续的观察。我们设立了每月一次的业务审查会议，其作为高管和当地团队之间沟通的渠道。
每个月的业务审查会议是团队与利益相关者对齐方向的机会，目的是让每个团队在高级产品经理定义的更大战略范围内设定方向。
如何切换到STO模型
我们的结果是好坏参半。
我们的团队在STO模型下快速发展，并成为我生涯里表现的最好的团队。尽管团队的构成有细微变化，但多数的成员来自之前的公司，而团队也已交付了几个不太显眼的项目，当我们进行重组时整体的情绪还是比较低落的。
我相信真正成功的变化有两个方面：一个是团队的新领导班子是一个强大的组合，但似乎STO模型让这个组合更加强大了：
-
STO、产品经理、首席工程师和设计师各方面都表现的很一致，我会从他们每个人身上听到相同的声音，从根本上展现出了同样的观点。他们比我合作过的任何团队都有战略性。
-
他们对自己负责的领域有更强的责任，并开始挑战他们"给予"的一些产品方向。他们成功地将方向聚焦在更重要的事情上，领导也能参与其中去面对那些挑战。
-
团队变得非常有生产力并保持增长，他们开始每隔几周开始向客户交付东西。他们从一开始没有计划地发布单一的版本，到以对客户有用的方式对大型项目进行增量发布，他们经常这样做以至于人们不再关心具体的时间表。但他们还是会一如既往的按时完成，以至于他们通常在几天内完成他们的目标，有时甚至提前。
-
他们的工作呈现出与以前不同的性质，他们不是每几个月交付一个大型的项目，而是会优先对一些小项目进行迭代。他们会从客户那里得到新的输入并制定一个1-2周的小型项目。我相信这会带来更好的服务：他们比以前更关注客户的反馈。
以下是 STO (Alexa Stefanko) 描述她个人的经历：
我爱它，如果我可以永远成为 STO，我会的。它让我变得更好，它让我们的团队变得更好。我感到鼓舞、兴奋、挑战并以一种我以前从未有过的方式投入。我喜欢我的决定产生了明显而切实的影响。我最大的收获是它让我之前的弱点变得不可接受。我的意思是，我的弱点（与 PM 的关系、技术把控、缺乏市场意识）在那个职位上已经不能被容忍。我必须克服所有这些弱点，并迅速将它们变成无害的东西或优势。例如，它教会了我如何与我的 PM 建立良好而富有成效的关系，这是我一直在努力解决的问题。
这也迫使我的领导团队始终保持一致。因为任何事情都经过我，我们能够在一些没有达成一致的假设上互相挑战。我们强制去做对齐意味着我们的团队获得了清晰一致的方向。
虽然我认为我们的数据通常不足（我希望我们更多地去承认这一点），但我喜欢和我们的产品共同经历成功和失败。我对我们的决定充满信心，并且当我们能对错误进行纠正时会更加充满信心。
第二个团队的表现不尽人意，工程经理认为这个新角色极大地肩负了责任，但得不到产品经理的支持。因为他们团队面临的挑战之一是围绕产品方向，这最终成为STO的一大问题。
关于这个团队的 STO 模型，你能说的最好的一点是，它很明显它不起作用。PM最终离开了，情况开始好转。最大的好处是问题比以前能更好被暴露出来，然后EM能即时采取行动来改善此问题。然而，EM报告说整个经历都充满着极大的压力。
STO模型的利弊是什么？
其中一个最大的挑战就是在STO模型下，要求每个人不去关注原本的身份（不管你是工程师还是产品经理）。产品经理和设计师不断存在摩擦，让他们感觉到STO给了他们更少的权利。作为灵长类动物，我们自成为人类之前就已经是权力等级体系的一部分，人们认为汇报层级代表着地位和重要性。STO模型却与此背道而驰，我认为在STO模型中将一直维持这样的特点。例如，你觉得你公司的问题是需要一个更好的产品方向。如果你想招一个经验丰富的产品来解决这个问题，那么让谁在STO模型下接受这个角色可能会受到更多挑战。很多经验丰富的领导者想要有一群人向他汇报，否则会认为他们的权利地位不够“真实”。
整个实验过程中我看到了对STO模型的一些小的阻力大多来自产品经理和设计师。一个产品经理似乎容易将任何问题归咎为STO模型不起作用，最高级的产品经理会根据自己的评判标准评估单线程领导者，然后发现STO缺乏产品相关的能力，因为STO不像他那样专注于产品。STO的工作和工程经理（或产品经理）有很大不同，而且是一个更难的工作。我认为在很多方面像是主管级别的职位，因为你在领导一个更加复杂的组织（你在领导工程师、产品经理和设计师）。和传统的工程经理相比，最大的差异就是在方向设定上，你不能只是一个经理，你必须去领导。
最初会对产品管理者和会议讨论人员这两个角色产生混淆，其中一个问题是：你是否经常邀请STO到会议中参与决策？理想情况下事实并非如此，但这是我们经常听到的问题。我想表达的意思是，产品经理就像技术主管：倾听并了解特定领域的专家。对于产品经理来说，他们是专业人员擅长确定问题的优先级、引导客户、并确保我们了解当前所处的上下文。就像技术主管一样，应该是在他们最深入了解的专业领域做判断。STO和产品经理应该在事情处理上保持一致，而STO是最终负责领导的人。但是产品经理应该是把大部分时间都花在这上面的人，因为他们在团队中担任该职能。
首席工程师 Ben Bernard：“在亚马逊的 3 个不同团队工作并与您再次尝试后，我很清楚团队层面需要非常强大的产品领导力。 这可以来自 STO（在亚马逊经常这样做）或来自 PM。 无论哪种方式，此人都必须对客户及其应用场景最了解，并且最了解产品愿景。 他们还必须能够确定事情的优先级（尽管这可以通过“数据驱动”的文化或团队中的其他领导者来帮助）。”
我们面临的挑战之一是公司足够小，以至于在团队之间划分职责仍然导致每个团队会承担过多。 您可以专注于单一事物的想法（“单线程”想法）并不完全正确，因为每个团队管控的领域都很广泛。
支持 STO 的人对于该模式的成功是非常重要的。如果您对产品经理、技术主管或设计师没有信心，您可能在采用 STO模式后走入到失败的状态，您应该相应地调整您的期望。根据本·伯纳德的说法：“这肯定发生在亚马逊——亚马逊只是解雇了一些人……不试图解决问题，而是人们经常更换角色或离开公司。这对老前辈们产生了一些不好的连锁反应，感觉亚马逊无法留住任何人，并且感觉与公司的联系并不紧密。但是，我认为他们在必要时将相关人员移出团队是一个很好的做法（更高级别的人除外）。如果你有一个团队完成了它的工作，但在链条中的几个点上都有表现差劲的，那么在这个组织中工作就会很糟糕。单线程所有权能促进此问题的解决，因为每个级别都是亚马逊的 STO，有大量宽大处理事情的方式。这导致每个组织都大不相同。例如，AWS 和 Kindle 以拥有不同的工程文化而闻名。这也导致我向其他工程师提出了这样的建议：“除非你在新团队中有朋友并且知道它没有搞砸，否则永远不要更换团队”。
同一时间下我们更多地转向按指标驱动的工作方式，虽然我们看到了指标能带来的良好效果，并且从“指标驱动”中学到了很多东西，但有时感觉有些做作，因为我们拥有的数据量实际上并不是足够科学。召开“指标评审”会议的主要好处是迫使 STO 思考他们的领域并报告它。指标本身似乎不如观察其领域的行为重要。然而，随着时间的推移，我认为我们会变得越来越成熟，并变得越来越受指标驱动。
STO 面临的挑战之一是领导层和 STO 之间的配合。理想情况下，这种工作方式是领导层提供目标，STO 选择项目来实现这些目标。在实践中，当创始人和高管想要高度参与团队的工作时，这在小公司可能很难。在我们的案例中，当地团队并没有完全被赋予自主权，因此他们无法在不被高管授权的情况下完全地做出决策。这种做法违背了 STO 模式的预期，造成了来回的摩擦。
我推荐STO模型么？
我相信 STO 模型比具有独立领导层级的标准“三凳”模型更有效。 但它有缺点，需要更多的纪律来实施和维护，所以我打算把它作为我可以使用的工具，但在大多数情况下不会使用。
下面是我在判断什么时候使用STO模型的因素：
- 理想情况下，您一开始就采用了STO模型。 一旦你已经建立了独立的层次结构，就几乎不可能切换过去，除非你有非常有主见和强有力的领导。 很少有产品负责人或设计负责人愿意放弃他们所有的直接下属。 他们会认为这是职业生涯的限制。
- 我可能不会在更大的组织中介绍这个， 有很多障碍会阻止该模式成功推行，我不会在这个环境下花费我所有的政治资本。
- 对我来说，一个重要的决定因素是公司的工作文化。 如果公司的员工在角色分配上更加灵活，或者更加以客户为中心，那么可以通过 STO 模式取得更大的成功。 文化的灵活性是另一个因素。 如果我相信我可以在很长一段时间内完全塑造组织，我会更倾向于采用 STO 模式。
- 接受结构化的工作文化也会更成功，STO 模式的成功需要良好的标准和良好的流程。
如果采用STO，我会关注这几个方面：
- 我会以不同于工程经理和产品经理的方式雇佣 STO。 您需要具备这些素质的人：真正擅长从无到有创造方向、优秀的人员和流程管理，以及优秀的产品意识甚至产品管理经验。 一个同时具备产品管理和工程管理技能的人是你的最佳人选，但他们很少见。 寻找以组织为中心的产品经理和以产品为中心的工程经理。
- 我会花很多时间谈论人们的角色。 他们将自己视为“产品经理”和“工程经理”，因此跨越这两者的角色会让他们感到困惑。
- 我预计许多经理将不得不挑战角色的转换。 特别是，我将评估他们所担任角色（技术、产品和设计）的实力，并更好地为他们的差距做好相关准备工作。 这是一个非常大的角色转换，许多人可能无法成功，特别是如果他们没有合适的人来支持他们。 有些人可能不会进行过渡，可能需要切换到另一个角色或被管理。
- 切换到 STO 模型需要您为所有职位制定良好的标准。 您需要明确角色的定义和职业阶梯，以便即使他们的经理不是具有专业技能的人也可以公平地晋升。 这些不是先决条件，但如果您实施 STO 模型您将立即投入到这个工作。
我发现得出“STO 模型更好”的结论令人失望，您可能不想实施它。 我认为它向我展示了团队真正去中心化的一些好处：拥有强大的所有权，并且保持一致。 它向我展示了什么是可能的，我发现自己正在思考混合模型，并想知道它们是否可以获取到一些相同的好处。 我想知道的一件事是，对传统的管理方式进行一些修改是否可以获取一些相同的好处。
尝试做一个思考，你也许可以通过结合这些措施来实现一些相同的结果：
-
制定适用于设计、产品和工程的组织理念：包括团队规模、不同专业之间的比例以及团队设计的原则（例如，基于产品领域或客户群），并为此写下简短的规则列表。 例如，其中一个规则可能是所有重组都必须很协调（或者一个组织可以进行重组），并作为一个小组完成。 这是一项相当繁重的工作，而且很容易被忽视，所以我认为大多数组织不会提前这样做， 您可以通过STO模式来完成。
-
使产品经理和设计师能去为组织服务， 产品提供方向、上下文和客户信息，设计提供可用性和实用性。 如果他们中的任何一个都不能让工程经理满意，他们基本上可以与该组织“终止合同”。 举个实际工作中的例子，假设 Lisa 是一个团队的工程经理，她觉得她的团队没有确定足够好的产品方向来有效地完成团队的使命。 她可以告诉产品领导她对自己当前的所做的服务不满意，然后“送回”与她一起工作的产品经理。 然后，产品组织需要尽快提供另一个人，他们可以将该 该产品经理转移到另一个角色或让他们离开。我发现产品经理或工程师如果有能力去终止合同，那么在制定方向上也同样高效。
-
可能有一些方法可以对职责做一些设置，以便 EM 或 PM 对他们的角色有一个更大的视角，这类似于 STO 模型中“你拥有一切”的理念。 我曾经让我的经理告诉我，“这个产品上发生的一切都是你的错。 如果客户支持不佳，那是你的错。 如果你的产品方向不好，那是你的错。 你有责任让这一切顺利进行。” 其中一些问题实际上是一个延伸——我在技术上不负责产品方向， 但用更大的视角去对待角色有助于确保事情能正常进行，即使它不在他们的负责的轨道上。 向人们传达团队的成功才是关键，即使它超出了你的范围，这可能是我们需要更多去强调的。
