随着规模的不断扩大，公司需要聚集更多的优秀人才，建立更高效的组织，这时只有单一的、从上往下的指令往往是不够的;在公司内部建立一个分布式管理系统，让员工更多参与决策，推动内部信息公开透明，才能应对管理上的更高要求。

■文|张一鸣北京字节跳动科技有限公司创始人兼CEO

我一直都觉得要尽可能招优秀的人，但是把优秀的人聚集起来之后，该怎么做事情？怎么建立一个有效的组织？怎么在公司从小变大的过程中，应对管理上面临的挑战？这也是今日头条在成长过程中，我们常常讨论和思考的问题。现在，我们倾向于“Context，notControl”的解决方案。

先打个比方来解释Context和Control的区别。

计算机有两种处理任务的方式：一种是超级计算机，用一台计算机处理很密集的任务;另一种是分布式运算，让很多机器共同来处理任务，分解任务以及任务所需要的资源。而在企业管理中，有两种管理模式分别跟这两种运算方式类似。

第一种，把CEO当成超级计算机，CEO做战略设计，提出战略计划，逐层分解，之后执行。执行的过程中如果遇到情况，再往上汇报，CEO汇总信息后，再次定下工作任务。这个过程中有审批，有流程，有很多的管理机制。过去，很多企业都是采取这样的方式，主要包括：建构战略和控制流程。

第二种，有更多的人参与决策，让更多的想法自下往上涌现出来，而不是一个从上到下的战略分解。这个过程需要更多人基于Context即上下文做出判断，而不是根据指令来执行。

具体来讲，Context是指决策所需要的信息集合，包括原理是什么，市场环境如何，整个行业格局如何，优先级是什么，需要做到什么程度，以及业务数据和财务数据等等。而Control则包括了委员会、指令、分解和汇总、流程、审批等等。

在我们看来，Control往往会带来一些危险。人类在判断自己的理性控制能力时，总会有一种幻觉，聪明理性的人更是如此，常抱有理性的自负。CEO们往往有过成功的经验，尤其在公司早期已经取得过成功，且CEO没有上级，很少被人“挑战”，容易觉得自己英明神武。

但是大家忽视了一点，行业是不断发展的，你具有的知识虽然丰富，但在行业不断变化中依旧是有限的。有时候，CEO们会误以为自己提出的方法论特别好，模型特别优雅，希望在全公司大范围内推行，但忽略了抽象知识和具体形式之间有差距。理性往往只适合做知识抽象，但对解决具体问题不一定真的有帮助。当然，我们不能全盘否定理性的作用，只是要避免过度放大理性后带来的危险。

自上而下的宏大战略往往都是灾难，业界也发生过不少真实的例子。

比如WindowsVista，这是比尔·盖茨按自己的技术理念力推的项目，计划2003年上线。其理论听起来非常好，非常领先，但是一直到2006年这个项目才真正上线，中间还重构了一次，把目标降低，重新修改了计划，最终才推出去。

乔布斯也犯过同样的错误。第一次离开苹果做NeXT的时候，他提出一个非常理想的计算机模式，包括优雅的操作系统，完全面向对象(ObjectOriented)的语言，但是最终也没有卖出多少台。

中国也有这样的例子，曾经盛大易宝的理念也很宏大，但和当时的文娱行业、互联网带宽，以及政策环境的情况都不匹配，最后失败。

Control除了会带来战略上的问题，还会因为追求控制感而导致企业反应迟钝。我们可以试试把支出、合同、offer全部加起来，算算每天需要审批的文件有多少。假设一天是15个的话，一年就是5000多个。这其中真正有效的有多少，经过认真思考的有多少，还是它们的存在纯粹基于控制感?

相较而言，你的下属或者其他人是不是能够更好地审批?我想是的，因为他们在一线决策，有更充分的外部信息。由于CEO精力有限，大量的审批延时，让很多事情平白增加了一天到两天的时长。

此外，针对公司变大后会出现的问题，还有一种错误的解决方案——过早BU(业务单元)化。这种方案会导致几个问题：

第一，部门间不配合。比如，BU部门自己处理PR(公关)危机，自己招工程师，而不找市场部或技术部的同事，部门之间缺少配合，或者说因为缺少彼此之间的磨合导致配合变得更差。

第二，部门内冗余，专业度降低。比如，单个BU招的工程师标准不够高，而且工程师团队规模不够大，互相学习不够，进步提升不够，导致专业程度下降，内部也变冗余。对于CEO来说，他感觉更像一个承包者，把任务发出去后不参与过程，只要结果。长此以往，企业文化也会变差。

当然有一些例外，如果是相对独立或非常成熟的业务，确实不需要公司内部支持和配合，可以BU化。公司存在的意义就是为了分工和配合，公司内的业务活动，要确保内部合作成本低于市场交易成本。大量不配合的BU，本质就不应该存在于企业内部。

过早BU化是一种比较普遍的错误解决方案。很多公司过早就成立许多子公司，或者拆成很多项目组，甚至进一步把业务独立出去，独立融资。在我看来，这些做法往往都不是很好的解决方案，而是懒惰的解决方案，因为如此就不用解决配合和沟通问题。

相比Control，强调Context的管理模式有什么好处?

第一，分布式运算。让更多人用更多CPU进行运算，让更多人参与决策，利用集体的智慧。作为管理层，做审批决策只花30秒，但别人可以花三个小时，做更多的调研之后进行判断。

第二，可以更快速地执行。不需要层层汇总，不需要在CEO这里排队列等审批，能够更及时地响应。

第三，充分的外部信息输入。在Control的模式中，任何信息都要到CEO这个节点，靠CEO再分发出去。CEO很大程度上变成了公司和外部之间的接口。相比单靠CEO接触外界情况、了解市场行业或者宏观经济，运用Context模式，能让更多的员工、主管直接面向行业，这时信息肯定会更充分，角度也不一样。

第四，参与感会激发创造力。做同样的事情，如果员工知其然，也知其所以然，会比只知道指令，做起来更有意思。这个对发挥员工的创造力也有一定的帮助。

第五，可规模化。Context的建设，表现形式可能是内部的系统，可能是知识共享文档，这些都是可以复用的，是可规模化的。而CEO和管理团队的时间精力有瓶颈，靠拼体力、脑力、耐力来解决，而这些往往没有规模效应。

当然，有时候也需要用Control模式：

一、紧急情况和重点项目。比如，有重大的PR危机，需要快速响应;或者重点项目也是如此，如果竞争对手已经逼进，这个时候进行分布式的讨论，追求自下而上的灵感涌现，是来不及解决问题的，时间窗口很快就过去，所以紧急情况和处理重点项目更需要Control。

二、创新业务和新部门早期阶段。如果一个部门刚设立，或者一个新高管上任，还没有跟公司磨合好，这个时候需要更多的Control。另外，在创新业务的早期阶段，需要更多支持和配备资源的时候，也需要CEO的统一协调，主导进展。

三、不匹配的职位安排。如果某个岗位的人跟公司的理念差距很大，那么他的上级也需要用Control来干预。

为什么公司发展一段时间后会出现这个问题，而公司的早期阶段不会出现?因为在公司早期的时候，CEO一般都是业务的专家。公司业务简单，行业情况简单，CEO可以自己做决策，效率也更高。但随着公司的成长，CEO精力被很多事情分散，PR、融资、外部活动等等，组织管理企业本身也非常消耗管理者的精力。另外，市场环境变复杂，业务多元化，CEO不再是专家，甚至也不是对业务最灵敏的人。我们要求CEO快速学习成长，但人的精力总是有限，总有很多方面是不如创业阶段的时候。

比尔·盖茨20年前是一个优秀的架构师，20多年之后，如果还用他的理念来指导整个大型项目，作用就非常有限了。当然有些企业不存在这样的问题，比如老干妈辣酱，因为他们所处的行业稳定，创新较少，只需要遵守好传统的流程。

总结而言，我认为好的组织包括：

一、优秀的人。企业需要分布式的处理器，而不单单只是一个执行者，每一台分布式计算机都有判断能力，都要聪明。

二、“充分Context，少量Control”的管理模式。每个人有他需要扮演的角色，掌握所有的上下文信息，做出业务决策。在必要的时候，做出少量的干预。

有了以上两点，就能保证组织内的交易成本最小，并且做出高质量的决策。基于这个理念，在我们公司，遇到问题的时候，往往习惯先问Context是不是不够充分，而不是增加Control。比如说某个项目进展出了问题，我们首先不会考虑让更高阶的人来做，而是反过来想，是不是Context不够，是不是没有把行业的情况、业务数据、过去的失败案例分享给执行者。

作为管理者，要想想你做出比他人更好的决策，是因为能力强，还是因为你自己的Context更充分，而与其他员工存在信息不对称的情况。大家仔细观察会发现，有时管理者甚至利用信息不对称来体现自己的价值。所以，在公司内首先要把建设Context这个基础工程做好了，尽管这并不容易，需要大量的沟通、管理和产品技术工作。

从具体操作层面，今日头条做了一些实践，分享给大家：

第一，减少规则和审批。我们不允许部门随便出规定，即便不得不有规则，我们也希望规则非常简单，不允许有长达几页纸、非常难执行的规定。要减少审批，甚至希望尽量不要审批。

第二，组织结构灵活，拒绝领地意识，能灵活调整汇报关系。让大家意识到，汇报关系只是汇总信息一种方式，只要业务需要就可以随时调整。如果我们有一个项目非常重要，可能需要市场部的同事来支持这个项目，那在这段时间里，这个项目的主管也是市场部同事的主管。

第三，弱化层级跟title(标签)。我们鼓励年轻人多提想法。我第一次担任CEO是26岁，我相信我们公司26岁的人有很好的实践经验，受过很好的教育，只要给他们好的Context，他们也能做出好的决策。

为了避免这些形式给基层节点带来压制，我们弱化层级，首先是不允许像“老大”“某某总”“老师”这种称呼的存在，这种称呼一旦出来之后，很多想法就不能涌现出来了，员工可能会倾向于先听听“老师”有什么意见，自己不能先说出来。我们也没有title带来的日常可见的待遇区别，比如什么样的人配备什么样的电脑，什么样的人配备什么样的办公桌，这样也会带来层级感，会影响不同的同事发表意见。

第四，鼓励内部信息透明。我们鼓励群聊，各部门之间充分沟通，不要只跟CEO沟通，也不提倡只有一对一的沟通，我们认为一对一的沟通效率很低。如果有新加入的同事或者高管希望跟我一对一进行沟通，我经常会说你可以抄送给我，但你首先发给其他人，发给需要和你配合的人。

我们让管理层的OKR对下属员工保持公开，让大家知道你在做什么，为什么在做这个事情，其他部门的人在做什么。OKR的制定过程也不是自上而下的分解，而是大家互相之间自己对齐。

看一下上级的OKR，看一下别的部门的OKR，看一下同级的OKR，了解目前公司最重要的任务是什么，这个季度最重要的任务是什么，我做什么能够帮助他们。季度会议也是尽量让相关人员多参与，这并不是一个非常小范围的高管会。我们还会经常举办CEO面对面，在这个会议上回答员工提问，让大家了解公司进展。

第五，做到充分建立Context，需要好的内部系统做支持。我们有将近100个人的内部工具开发团队，做各种工具尝试。比如我们自己开发了OKR系统，并且和内部使用的IM打通，方便大家互相查看。

这些基础工具，第一，可以让人更轻松，第二，可以规模化运用。即使是新人加入公司，也能很快适应OKR系统，能看到内部的资料、从内部获取信息;他也能意识到，他不仅仅有获得信息的权利，也有支持相关工作的责任。在我们看来，这样的实践是把公司当成产品来建设，让公司内部的Context更有效，让这个系统的分布式处理能力更强。

*本文首发于《经理人》2021年01月刊

本文来源：经理人网