字节与美团的管理18：为什么字节靠中台取得了早期成功？美团却完全没有中台？
我自己的业务，到底应不应该中台化呢？
怎么像字节一样，解决中台管理的常见问题？

1、
最近看到不少文章说阿里的中台，说阿里组织架构调整之后，曾经的中台不复存在了。
其实，
阿里是说中台说得最多的。
但是，要真看“中台的程度”，字节才是最中台的。
我还真没见过比字节更中台的企业！
虽然字节自己不把他们叫做中台。

中台的定义，是本该负责增长、利润等指标的业务部门，不再负责一部分工作了。
这部分工作的操作权限，让业务部门交给中台。
业务部门要想做，必须提需求给中台、让中台来完成。
于是，
当大量不同业务部门，把同样的需求提给同一个中台时，这个中台只用做一遍，就可以支持所有业务。
公司造一个轮子，所有车都能用。

在疫情之前，字节在很多年里，整个公司虽然并行着今日头条、抖音、TikTok、火山、西瓜、懂车帝等等多条业务线。
但是，整个公司真正的大部门，就三个部门：
增长、商业化、技术支撑。

任何一个业务线，你总要做增长吧？
那好，你是不能自己组团队的。
必须找到整体的增长部门，增长部门给你干。
增长部门，会在自己部门内专门为你的业务线设置一个小团队，帮你做好增长。

当我知道这样的组织划分后。
我的第一反应是——那业务负责人干啥？
增长是公司整体的增长部门做的、变现是公司整体的商业化部门做的、技术支持是公司整体的技术部门做的，每条业务线主要的问题不就是增长后变现吗？
那业务负责人还有啥权限？还需要干啥？
我得到的回应是：
“业务负责人是有点尴尬，感觉更像是项目经理和协调者……”

中台到这种程度，按道理说，常见的情况会是：部门之间的墙极厚、很难沟通，业务没有权限，与中台之间的协调就足以让一切努力全白费，想做啥都很难推下来！
所以，除了字节之外，没有企业选择中台得这么彻底。
但是，
恰恰是这样的中台化得配置，在疫情之前，让自己的一串app取得了成功！

为什么呢？

2、
第一点，字节的中台，管理方式和大多数的中台不太一样。

常规的中台设置，确实会带来巨大的沟通、协调问题。
对于大多数有中台的企业——
背指标的是业务。
业务要做什么，要吭哧吭哧找中台提需求。
可是，
中台又不了解你的业务，需求常常做出来，和业务理解的、想要的，总有各种意料之外的不对劲。
中台同时要支持那么多部门的需求，这事儿你一个业务部门说紧急、说对你多重要，和中台自己的规划未必一致，哪怕一致，对中台也未必重要，就得等排期，常常因此错过了机会、输掉了竞争。

于是，
业务背着数据指标，干着急。
主要靠汇报讲故事的中台，常常并不在意业务的诉求，也不会对业务起到有效支撑——反正业务的数据指标和中台的年终奖没啥关系。

字节的中台设计上，有效规避了这个问题。
关键就在于——
不能只让业务背数据、干着急。
得让中台的人、负责开发工具人也背数据。
有指标压力，中台才容易被准确评价、才会在数据压力下不得不接地气、不得不真的为业务考虑把业务做好。

而之所以字节能让中台背数据。
也在于字节在“业务”与“中台”的切分点上，与常见的中台设计截然不同。
他没有把切分点，分成“运营背增长”、“运营中台做工具”。
而是索性把整个增长、整个商业化，变成了一个大中台。

直接背数字、自己做工具。
于是，
为了实现指标，中台必须接地气。
为了节约成本，中台必须抽象出通用工具，解决重复造轮子的问题。

而且，
对于每个业务，在中台内部，也是专人专用的。
一个人支持抖音，做抖音的增长，在很长时间就只能做抖音的增长。
就不会因为要同时做多个部门的需求，导致啥事儿都得排期。

不过，
又背数据指标、又是专人专用，那这个增长中台，和业务自己有一个增长团队有啥差别呢？
有差别！
这个差别，恰恰就是字节的中台成功的地方。

3、
第二点，字节如何发挥中台的优势。

就以增长部门为例吧。
在现实中，要做好增长、使得增长效率远远领先于竞争对手，是个技术活儿！
比如：
抖音要增长，得有人投放吧，做好投放、理解并学会利用各个渠道的规则，是个技术活儿。
一度，字节的产品很爱做预装，与渠道建立关系、做好预装，也是个技术活。
在appstore维持好评率、不断提升好评数，是技术活儿。
判断用户最适合的分享时机，促使裂变完成，还是技术活儿。

这一个个技术活儿，要想做好，都需要漫长的时间。
有人搞明白、理解应该怎么做，需要时间。
做出来、写完代码、开发出工具，还是需要时间。

整个公司统一的增长中台，比起各个业务独立的增长部门，最大的好处就在这里——
如果每个业务都有增长部门，当A业务做成了，B业务需要增长时：
B业务的人想要找A业务的人学习经验，A业务想着“你做好了不就把我比下去了？”
未必肯教。
就算肯教，B业务的人仅仅通过学习，也很难学到A业务的水平。
你要想从A业务调人走？A业务肯定不放。
你要想说，A业务你已经写过一遍代码了，能不能花点时间包成通用工具，让其他业务都用上，A业务只会说“凭啥？”

但是对于字节，所有增长的人都在同一个大部门里。
今日头条做成了，现在抖音需要增长团队。
抖音的增长指标，也会被压在同一个增长部门。
这个增长部门为了指标，自然会调今日头条的增长人员去抖音。
让做过的团队，直接再做一遍！
经验100%继承，质量0损失！

今日头条的业务负责人如果想拦着，
说：他在我这儿干得好好的，咋说调走就调走了呢？
不好意思，你拦不住。
于是，
抖音起手，团队的增长经验就远远比同行竞品丰富。
都是直接干过一遍、且干得足够好的人。
自然更快、更强。

当需要增长部门支持的业务越来越多时，
为了减少技术的重复投入、提高人效，增长部门自然将一个又一个通用模块做成了SDK。
于是，
再做任何一个新app时，几个SDK一插入，字节直接就比竞品领先了好几年的代码量。

统一的增长大部门，保证了经验的充分共享、人才的自由流动、和通用工具的积累。
这就是中台的价值。

在不少领域，
字节的增长团队都曾经发现，他们的竞争对手们过了5年，才意识到、并开始做字节5年前早已玩儿得很充分的增长动作。

4、
同时，
字节的中台，还带来了一个巨大的好处。
就是“不怕业务负责人离职！”
反正增长、商业化都有独立的部门，经验、资源都在部门里！
能力都沉淀在公司。
业务负责人走了，对业务的影响远不像大多数公司那么大。

这也导致了字节的一个独有现象。
正常情况下，一个有影响力的产品诞生，我们总能说出“谁是这个产品的负责人”、“XXX一手缔造了这款产品”。
只有抖音，没有“功勋负责人”——
如此成功，却没有人能说得出，到底谁是缔造了抖音的业务负责人。
似乎也确实没有这么个人。
在抖音的快速发展期，抖音负责人几乎一年多就换一个。

这也是因为，
在字节的组织下，对于抖音这样的业务，业务负责人真没那么重要。

不得不说，这样的组织，抗风险能力也更强。

5、
一直到2020-2021之前，字节都是这样的组织形态。
增长、商业化、技术支撑，三个“中台”性质的部门，承担了公司内绝大多数的业务职责。
这些部门就好像是三块积木，即插即用。
要做新业务了？
拿积木一拼就得。

那会儿，字节的成功业务，基本也都是同样几块积木拼成的。
都是内容app。
都要买量，都基于算法推荐，都要变现、靠变现能力支撑买量。
这些积木不用太调整，大体拼起来，80%就够用了。
而因为每一块积木积累的经验、工具、代码。
这些成熟的积木们一拼，
在能力上就已经是一个对手难以企及的高起点。

6、
但是，中台也带来了一些问题。
比如：
业务负责人干嘛呢？
没啥权限，确实尴尬。
当业务需要积木们做出调整时，业务部门总是没有足够的权限、更难驱使增长等部门做出调整。
当哪怕增长部门同意配合业务做调整，调整的代价也更高——代码都在SDK里，SDK牵一发动全身，要改，咋也得等个排期、得处理好对其他业务的影响。

沟通成本的增加和灵活性的降低，是中台化不得不付出的代价。
只不过，
当字节主要的产品都是内容产品时，统一增长部门带来的效率优势，远远大于灵活性降低的负面影响。

而美团，就走向了与字节截然相反的对立面。

7、
美团走向了另外一个极端。
美团是完全事业部制的，几乎所有职能都是拆碎在事业部里，由事业部负责人自己组建、自己负责。
哪怕有一些“中台”，那也是事业部内自己建立的小中台。

拆开的好处是什么呢？
所有人都像业务负责人负责，业务负责人想怎么干、就能怎么干！
不存在跨部门沟通，都是下达个指令的事儿。
业务负责人的意志，会被完全贯彻。
充分授权，足够灵活。

而美团这个事业部拆碎的程度，也远远高于其他公司——
比如，
大多数公司，至少政府关系（GR）这样的部门会是集团统一的吧？
技术也得是统一在CTO麾下的吧？
美团不是。
美团连GR都是独立在各个事业部的。

于是，拆开成事业部导致的很多问题，在美团就比在大多数公司更加严重：
重复造轮子是必然的。
数据整合的难度，也在意料之中。
比较有意思的是政府关系部门：当每个事业部都有独立的GR时，需要与美团对接的政府部门也会被搞糊涂——“昨天你们美团的人不是刚来找过我吗？哦，那个是到店的？那你们是？你们是到家的？你们到底谁说了算呀？”
政府也烦。

另一个拆碎的问题，是对业务负责人的高度依赖。
大量动作，都要依赖于业务负责人的判断和协调。
但是，
好的业务负责人太难找了。
特别是美团上市后，原有的业务负责人有不少离职。
这就是另一个故事了。

8、
美团这么选择背后的逻辑是什么呢？
为什么字节选择了最充分的中台，美团完全没有中台，却都取得了成功呢？

其实，“要不要中台”、“要多中台”都取决于业务！
业务形态，决定了需要什么样的组织形态。

中台本质上解决的是重复造轮子的问题。
几个部门都要用到同样的轮子时，中台可以使得造轮子的成本降低、总速度加快。
但是，问题是，中台的代价是会失去个性、灵活性，业务与中台之间的沟通成本也会增加。

中台，
本质上是牺牲灵活性、牺牲差异化，来换成本降低和快速复制。

企业经营中所面临的每个选择都是这样，没有只有好处没有坏处的选择。
每个选择，都既有好处、又有坏处。
于是，
就要基于自己的业务情况，去找到“好处大于坏处”的选择。

字节的“充分中台”，与美团的“几乎完全不中台”，主要的原因就在于业务差异——
字节主要的业务，都是同一种内容app。
同样的几块积木，就足以适应绝大多数需要。

美团的不同业务之间，则差异太大了——外卖的配送、优选的仓库管理和货损控制、零售的选品与促销——每个业务的核心复杂环节都各不相同，增长逻辑也差别巨大。
更何况，美团的每个业务，都面临着虎视眈眈的竞争对手，竞争对手们也差异巨大。
这种时候，
保证对不同市场和业务形态的充分适配，保证对竞争对手动作的灵活响应，给业务负责人更充分的授权，就成为了效率最高的组织形态。

9、
也是因为这个逻辑，后来，字节也不再存在统一的增长部门。
增长职能被拆到了各条业务线。
这也是因为，字节不再只有内容业务了。
教育，是服务驱动的。
游戏，是质量驱动的。
飞书，更是2B，需要靠销售驱动增长。
原有的积木，拼不上去了。
原有的增长人员，经验也并不适用于这些多样的业务类型。
业务的增长必须差异化，业务不再能接受灵活性的损失，于是，字节拆开了自己的增长部门。

10、
最后，
这其实是我觉得合理的“中台”逻辑。
中台与否，取决于“业务差异”，当业务差异不大、可以套上同样的积木和轮子时，中台的价值是更大的。
反过来，当业务差异巨大、业务必须保证灵活性时，千万不要在这个地方搞中台。

如果要搞中台。
也可以学字节，试着调整一下“中台”与“业务”之间的切分点，使得中台也可被数据考核。
中台会变得好管理很多。

世界上，从不存在“最好的组织形态”，只存在“最适合某种业务的组织形态”。
所以，
我一直觉得，当年“中台”的潮流，和现在“反中台”的潮流，同样荒谬。