一、科技公司整体组织理念：减少官僚，加速创新

在2016年的致股东信中，CEO强调了“Day1”和“Day2”的概念。保持Day1的公司健康而充满活力；Day2则意味着陷入停滞，然后一蹶不振、业绩下跌，逐渐衰亡。CEO提到：“我对这个问题很感兴趣：如何应对Day 2？有哪些技巧和方法？在大型组织内部如何保持Day 1的活力？...... 我并不知道完整答案，但我可能知道其中一部分。这是Day 1的必备要素：客户至尚、对形式主义持怀疑态度、积极适应外部趋势及快速决策。”

从2012年到2021年的近10年中，科技公司全球员工数量从不足10万人上涨到了100多万人。随着组织规模变大且日益复杂，如何保持组织活力，持续为客户创造价值，是科技公司所关注的问题。科技公司的Day1精神在组织上也有充分的体现，从双比萨团队到STL，不断探索最合适的组织形式；推行管理宽幅，以精简组织提高效率等等。通过这些举措，我们认为科技公司的整体组织理念可以概括为：减少官僚，加速创新。

Dave：“科技公司落实了一些关键因素，以尽量减少官僚，加速创新和创造力（minimize bureaucracy and optimize on innovation and creativity）。”

Bill：“CEO和管理层定期开会，他们会讨论一些话题，像是如何提高我们的速度、如何构建组织（how to improve our velocity, how should be structured）。”

1. 管理宽幅通过合理控制层级提高组织有效性

管理宽幅是一个管理者的直接下属的数量。当管理宽幅过小，管理者可能没有充分履行管理责任，也会导致组织的层级过多、过深，影响组织中信息传递效率和组织反应的敏捷性。当管理宽幅过大，管理者难以有效地管理、辅导下属，也会影响组织的有效性。

科技公司有一条经验法则是，People Manager至少要带3个人，这并不是严格的规定。在2017-2018年，科技公司推动了Manager of Manager管理宽幅项目，明确要求所有Manager of Manager必须至少有6个直接下级，以减少管理层级、减少无效管理岗位，让组织更快速灵活地响应客户。2018年的管理层 goal之一是全公司80%的MM管理宽幅≥6（正式员工，不含Executive Assistant），并定期在管理层会上review目标的达成情况。Global Talent Management团队负责与各业务的BP head合作推动落地，对于VP-1层管理者，如果不符合这个要求，需要报备到HR SVP，说明原因及行动计划，也自上而下地影响全公司。严格推行管理宽幅后，一定程度上减少了科技公司的管理者数量，导致部分管理者转岗或离职。

管理宽幅的上限没有明确数字，但也是一项关注点。访谈中Colin和Bill称：如果宽幅是2，就不需要管理者了，而一旦宽幅超过10，管理者就需要重组汇报关系来减少直接下属的数量，理想的数字应该在5-7之间。Dave提供的运营团队的数据为，一线区域经理（管理临时工）的管理宽幅应该在25到35人，运营经理（管理区域经理）的管理宽幅不应超过10到12人，每个业务的HR head每年会进行两次审核，确保管理宽幅是合理的。

Colin：“一个好的上级和HRBP会帮助管理者思考，是否现在的管理宽幅太大？应该怎样调整团队？当一个管理者下属太多或太少时，都无法成为一个有效的管理者。你会发现这样的组织中有太多运营成本（there too much overhead in this structure），我们是否能简化它以便更快地行动，能否用更少的资源创造更大价值（streamline it to move faster, create more with less）？”

《CEO传》：“CEO找到了另一种方法来降低固定成本、精简组织结构并避免科技公司成为‘Day2企业’。他向全公司发布了一条命令：从今以后，所有科技公司管理者（直接下级主要由管理者构成）都必须至少有6个直接下级。” “虽然一些部门（如AWS）可以暂缓实施这项要求，但其他部门却受到了重击。零售业务的高管表示，他们有10%～20%的同事（被剥夺了直接下属和管理者角色）在这些重组中离开，要么转到AWS和Alexa等高增长部门，要么彻底离开科技公司。”

2. 单线程领导（STL）通过明确清晰的权责加速目标实现

单线程领导（Single-threaded Leader, STL）强调重要的创新/举措有一位管理者在没有其他兼岗的情况下全情投入和负责，带领一个独立的、多职能团队来推动目标达成。Single-threaded Leader通过清晰明确的责任和权力，让团队专注于与公司战略一致的方向，促进了科技公司的快速创新。（关于STL具体内容可参考：科技公司Single-threaded Leader研究）

科技公司在1997-2001年快速增长，随着企业规模扩大，组织内部的相互依赖也日益增强，大量协调在很大程度上降低了创新速度。最初，科技公司尝试用双比萨团队（Two Pizza Team）来解决，重组软件架构，让不同软件可以通过标准接口访问，由此实现团队的分离；组建不超过10人的小型自治团队，定义明确的“健康度函数（fitness function）”实时监控团队表现。但双比萨团队仍然存在一些问题，包括团队互赖无法完全消除、健康度函数效果并不好、缺少足够的优秀团队领导等。与此同时，管理层发现很多想做的大项目没有人真正地负责，科技公司物流就是一个很好的例子，它涉及到网站、履约中心、卖家等多个团队，直到CEO说需要派一个senior leader专职负责，这件事才快速发展起来。在不断的尝试中，科技公司意识到，团队成功的最大预测因素不在于规模大小，而在于是否有一位具备适当技能、权威和经验的领导带领团队专注完成工作，由此诞生了Single-threaded Leader的概念。

Single-threaded Leader是一种理念和导向。在科技公司，如果有一个重要的新举措，管理层会问：谁是专职负责这件事情的领导？他是否有让现状更好的管理能力？他是否掌握了实现预期结果需要的资源？但STL并没有一套固定的规范或机制，也不会给某个人或某个团队打上STL的标签。在科技公司内部它通常适用于某个重要的举措/项目，因此大多数单线程领导的职级为L7、L8或L10。

Single-threaded Leader也体现为一种灵活的组织形式。与STL截然相反的是职能型组织（见图表1），例如技术、产品、设计、销售各自是单独的团队，他们都由职能负责人领导，以矩阵的方式去完成各个项目。但STL是一些小型自治的团队，专注于某个特定目标并围绕该目标灵活组建，这个团队有多少职能，取决于实现新举措或特定项目的需要。

Colin：“在科技公司，我们倾向于在任何重要的事情上安排单线程领导。” “与单线程团队截然相反的是职能型组织（the polar opposite is a functional organization）。但与此不同，你有许多小而自治的组织（small self contained organizations），它们不一定是多职能的，但可以是多职能的，如果这是实现新举措、项目、业务部门的特定目标所需要的。”

Dave：“通过非常明确的责任边界，不仅简化了组织，而且有助于明确谁负责完成工作，减少相互指责。一个人负责所有不同的流程，他们能更担起责任，也确实更有效地交付项目。”

3. 不同类型的组织在结构上有不一样的灵活度

对于技术和产品团队，管理者在调整组织时有更大的灵活度，因为他们更多是围绕一个个项目来组织和分工的。而零售、运营、客服等组织则有非常固定、标准化的工作结构（standard work），基于经验分析建立了一套staffing model来设置组织，因此在全球范围会使用一套相同的角色，不同区域的组织和人才结构也基本一致。

以运营组织为例，履约中心的工作流程包括收货，上架，拣货，装箱，打包，发货六个环节，通常一个履约中心会由一个总经理（General Manager, L8）负责，三个高级运营经理（Senior

Operations Manager, L7）向他汇报，一个负责入仓，一个负责出仓，还有一个负责持续改进和发展；下设的运营经理（Operations Manager, L6）对日常运营负责，管理各个区域经理（Area Manager, L4/L5），区域经理带领一线组长（Team Leader, L3）及一线员工（Associates, L1）。

这种标准化结构的好处主要有两点。第一是能促进跨地域的人才流动，当员工从一个地方转岗到另一个地方时，不需要重新适应一套新的体系，比如一个既从事过入仓也从事过出仓的运营经理，可以竞聘另一个履约中心空缺的高级运营经理的岗位。第二是有助于组织随着业务发展快速复制和扩张，当需要开设一个新的区域或新的组织时，能基于已有的模型来编制预算，明确需要的角色和人员数量，快速搭建团队。

Dave：这种方式在运营和客服中出现，然后逐渐发展到公司其他组织，具体取决于团队的性质。

Bill：“在2008年左右，Jeff Wilke想建立一套标准的角色结构。在此之前，不管你负责电子产品或书籍，你都能按你想要的方式来决定你的组织和角色。Jeff想要改变这种情况，他确定了非常明确的规则，有叫商品经理（merchandise manager）的角色、买手（buyer）的角色、供应商经理（vendor manager）的角色等等，这些角色在全球都是一致的。”

Colin：“我们叫做用'切饼干方式（cookie cutter approach）'工作的人，比如一个客户服务中心有多少人，你能知道需要多少运营经理、多少客服经理等等。这是一套标准的乘法（that's where there was a standard multiplying play）。”[注：“切饼干方式”意味着通常使用一套相同的方法，而不太需要关注个体差异。]

二、科技公司组织管理方式：基于管理者和汇报关系

整体而言，科技公司是基于汇报线的逻辑来展示和管理组织的，这一点与美团有较大差异。美团强调组织本身的重要性，组织节点承载了很多管理要素，例如过去的“组织层级”，组织命名的规范等；随之也产生了组织与汇报线不匹配（上级组织负责人不等于汇报上级）、兼岗（同一人担任两个组织节点负责人）等现象。科技公司遵循一套汇报线的逻辑，强调简单清晰的管理关系，并弱化部门和组织节点的作用。

1. 按汇报线形式展示组织架构

科技公司的组织按照汇报线的方式呈现，因为没有组织节点，同一个人的所有下级会展示在同一层，往下逐层展开，直至一线员工。科技公司内部有一款叫“phone tool”的工具（见图表2），每个人可以查看自己所在团队成员；也可以检索姓名查找其他同事，通过层层汇报关系来推导出整个组织架构及分工情况。

科技公司也很少使用组织与组织之间的隶属关系。例如，在组织变动的内部发文中（见图表3），不会描述组织如何发生变化，比如“XX部门分拆/平移”、“下设XX节点”等，而是描述人和团队的汇报关系如何变化，常见的说法是“step into sb's role”、“turn sth. over to sb.”等。在Connections的报表中，也是按照“My Org”、“xx’s Org”来呈现不同组织的Connections分数。

我们认为组织本质上是分工的结构（work structure），科技公司在形式上应用了汇报线，这与美团应用“部门”或“节点”并没有特别大的差异。但相对而言，应用汇报线更有利于科技公司围绕目标灵活地进行分工调整，不用过分纠结于职责的划分逻辑。如果过度关注组织节点本身，可能会导致STL这类团队较难组建。

Bill：组织架构图最终都是从首席执行官开始，并从那里无限分支（the org chart ultimately starts with the CEO and that just infinitely branches outwards from there），隶属关系实际上是谁管理什么。以AWS为例，Adam Selipsky有不同的直接下级，如果一个leader负责S3，一个leader负责EC2，分别汇报给他，那么他们就会展示在不同的组织和组织架构上。

2. 强调汇报关系的单一和清晰

汇报线反映的是管理关系以及对应的权力和责任，科技公司尽量确保单一、清晰的汇报关系，以明确权责、提高组织的效率。

一方面，在科技公司，一个人可能会同时管两件不同的事情，但很少出现一个人同时汇报给两个上级的情况，也就是说科技公司不存在严格意义上的“兼岗”。另一方面，科技公司重要的事情尽可能采用实线汇报，避免虚线汇报关系（尽管有“虚线汇报”的说法，但系统中并不会设置）。对于不得不“虚线”的部分，例如总部的C&B团队定向支持某区域的HRBP head，在绩效评估时实线主管会邀请内部客户、协同方等给予反馈意见。

Bill：“如果存在一个人汇报给两个不同上级，那是一个糟糕的决定，是不可持续的。我们有一个原则，那就是只有一个人可以管理（only one person can manage），你不能同时汇报给两个人。”

Colin：“我们倾向于尽可能地建立更多的实线汇报关系，尤其在技术、产品、业务开发等事情上，如果要进行一项大的创新，绝大多数的工作都集中在这几方面的努力。如果他们每天都专注于这个问题，这是一种更高效、更快捷的方式。”

3. 不严格区分组织的级别和命名，更重要的是“谁负责什么事”

科技公司的组织名称没有后缀（如department、division等），也没有“组织层级”的区分，通常会根据团队所做的事情取一个简单清晰的名称，用于内部沟通和外部招聘，例如负责客服的组织叫“Worldwide Customer Service”、负责人力资源的组织叫“People Experience and Technology”。

在科技公司的治理标准中有一套组织相关的概念，包括team/department/business

unit/division等不同概念的界定，用来帮助判断管理scope是否与对应职级相匹配。经访谈了解，不同词语的含义虽然有所区别，比如一般division和department意味着更大的群体，business unit是专注特定领域的业务组织，但在实际使用中，科技公司不会过度关注这些概念，它们都可以互换使用，大部分情况下大家都会用“team”来称呼，不论是有5个人还是1,000个人。

科技公司没有在组织上进行分层分类，更多是基于一个团队所负责的事情，来看团队的管理者是否合适。团队规模虽然对管理者的职级有一定的影响，但并不是绝对的。假如一个团队在负责突破性的技术研发，或者进行一个特殊的新项目，尽管团队人数很少，也需要有一个更高级别的管理者。

Bill：“当你说有一个500人的团队，谁是合适的领导者来管理这个团队时，这确实意义重大，我们非常认真地看待这一点，但我们不在意如何称呼这500个人。”

Dave：“只要人们理解组织结构，他们就知道如何称呼自己。大多数人会把自己称呼为一个“team”，因为team意味着一群人为了完成共同的目标在一起工作。用一些更大、更等级化的名字（some larger, hierarchical name）来区分自己和其他团队并没有什么好处。”