管理公司需要那么多的CxO吗？管好3种机器就够了

最近，我被各家公司折腾出来的日益复杂的组织方式给烦死了。尽管这种活动因阶段各异，在很多情况下领导团队扩张到数量较大（超过6人）时，往往就会变成两个执行团队（C团队和E团队），CEO就会陷入到无休止的困扰之中，无法抽身出来从公司整体层面考虑事情，这当中的挑战和复杂性我还可以说上1000字。

最近我看到了自己投资的一家公司推出了一个组织架构，它的简洁性和才华令我驻足。我并不喜欢那家公司CEO给它贴的标签，但是很喜欢它所蕴含的智慧。

它正好有3个类别。从我3岁那年开始3就是我喜欢的数字。尽管我脑子里面可以记住3件以上的东西，但当一样东西只有3点属性时，我发现自己总能一下子就记住，并围绕着那3点组织自己的思考，这已经成为我的第二天性了。

如果你还记得我的 魔数3 那篇文章，你马上就会知道我说什么。或者如果你听说过我在20多岁时跟强迫症作斗争的故事的话，你就会知道数字是我关键的精神支柱，而这个数字就是3。

我把握从那位CEO那里看到的组织架构抽象为3种机器（The Three Machines）。虽然这个可以应用到任何规模的公司，但最适合的还是第一款产品推向市场的公司，或者正在靠一组产品快速扩张的公司。

这3种机器分别是： （1）产品机器（2）客户机器（3）公司机器。

如果那你退后一步思考一下处在我上面所描述阶段的公司的所有活动，就会发现它们属于这三种机器之一。然而，大多数领导团队并没有这种对应。相反，在很多情况下，传统的领导团队往往是一位CEO加上一堆的VP（工程副总裁、产品副总裁、财务副总裁、人力副总裁、营销副总裁、客户关怀副总裁、运营副总裁等等），每一个往往都冠以令人自我膨胀的CxO头衔（CTO、CFO、CPO、CMO、COO、CRO……），或者在VP和SVP（以及EVP）之间进行人为的划分。

不管这些头衔结构如何，CEO的控制范围总是随着公司扩张而不断扩大，然后是在VP或者CxO的层级补充更多的人进来。随着这一趋势延续以及CxO的补充，最终会出现C-Team和E-Team（包括非CxO在内）两支团队。每个人专注的是特定的职能（财务、营销、销售）以及传统范围。

在一些情况下，当组织动态碰壁之后往往会引发组织架构上的实验性调整。仍旧活跃的合弄制（Holacracy）就是相对较新的趋势之一。我从第一次听说这个东西时就不喜欢合弄制，甚至连尝试一下都是拒绝的，宁愿看看别人尝试的效果如何。2013年，Nick Wingfield在纽约时报写了一篇题为《微软大修，以苹果的方式》的文章，这篇后来被广泛引用的文章，跟现在已经非常出名的，反映了Amazon、Google、Facebook、微软、Orcale以及苹果不同组织架构的一幅图很像。

围绕着这个话题，过去几年我展开了数百场的对话。但是从来都没有感到满意或者甚至觉得特别舒服的方案，直到我最近发现了3种机器。

我目前的假设是，如果你是CEO，请让你的组织聚焦于这三种机器上。产品、客户以及公司。然后，让一位直接下属管其中一个。如果你有一支规模偏小的领导团队（比如说公司目前只有3位创始人加4名员工），作为CEO你可以带一支团队，但是不要超过1支。随着团队的壮大（可能超过20人），希望你有足够的领导人才来让一个人管一支团队，但要意识到如果某人作为某个机器的领导管理低效的话，你就得顶替掉他的角色（要么炒掉，要么重新分配角色）。

假设你有足够的领导团队，可以让每台机器都有一位关键领导。然后就围绕着每一种机器来组织公司的领导。头衔怎么定没关系，但是层级很重要。自然地，产品机器你会有产品领导或者工程领导，客户机器你会有销售、营销或者运营领导，而公司机器会有财务或者行政领导。

但这并不意味着你的工程VP就是你的产品和工程VP。这几乎是不行的——你希望要把这两种职能分开。但你的产品VP或者工程VP或者CTO可以负责产品机器，而其他的职能VP要向他汇报。你可能也不想把你的销售VP、营销VP和客户关怀VP职能合并成一个销售、营销和客户关怀VP了事。但如果你有一位Chief Review Officer（管理客户评价）的话，你可能就搞定了。这能不能见效要取决于CRO能意识到自己负责整个客户机器的运作。

这套理论我才折腾了几个星期，所以目前的考虑还是有欠周到的地方的。比方说，我并不认为这就意味着CEO只能有3个直接下属了。但可能是有的。或者，在一些情况下，在特定规模下是这样的。我还没有关注到这在整体层级方面意味着什么。我还没有认真思考过存在多条不同的产品线时又该如何运作。我不知道这会不会要对职责进行大幅调整。

但是我的确有好几家公司都是明显专注于这三种机器的。是，它们是处在不同的规模点，有着不同的正式层级。在接下来几个月的时间里，我会按照这个视角来审视我投资的每一家公司，探索一下这张组织方式可以怎么做，应该怎么做。确定这个假设是否经得起验证。