沉没或游泳：知道何时放弃 -

2004年1月29日
第1卷，第9期

沉没或游泳，知道何时放弃
戈登·贝尔，微软湾区研究中心

一种诊断方法，可帮助您衡量组织功能障碍——并采取行动

对于新成立的企业来说，生存挑战是无穷无尽的。企业成功应对这些挑战的程度很大程度上取决于组织的性质以及组织内部形成的文化。也就是说，虽然市场规模、技术质量和产品设计显然是至关重要的因素，但公司倒闭通常根植于某种形式的组织功能障碍。为了帮助投资者在灾难发生之前识别出问题的迹象，我在十多年前开始研究贝尔-梅森诊断法，这是一种定量评估方法，包括一套用于检查公司并将其与“理想”组织进行比较的规则。

虽然该诊断法是专门为在新企业中投入资本的人设计的，但对于那些主要以时间、精力和想象力进行投资的人来说，同样可以有效地使用它。事实上，任何考虑加入初创公司或考虑是否留在初创公司的人都可以阅读该诊断法并回答问题，以确定他们心仪的公司是否处于相当健康的状况。

当然，新企业失败的方式有数百种。本文描述了一些特别常见的组织功能障碍形式，并参考贝尔-梅森诊断法来构建每个示例。

高科技企业1 为那些寻找工具来衡量初创组织长期健康状况的人提供了更全面的贝尔-梅森诊断法。风险投资势在必行2 描述了从大型组织内部创建新企业所涉及的更具挑战性的问题。这两本书都定义了成功企业的关键启发法，然后使用它们来描述经常预示即将到来的失败的运营模式。

贝尔-梅森诊断法

贝尔-梅森诊断法在组织发展的四个关键阶段评估企业的健康状况（毫不奇怪，这四个阶段与更为熟悉的产品开发周期中的相似阶段密切相关）

概念
种子
产品开发
市场开发

这四个阶段对应于关键的产品、市场和企业发展里程碑——并且是可衡量且可预测的顺序。更重要的是，对于那些成功地度过这四个阶段的公司来说，还有一个第五阶段，称为“稳态”——这是高科技初创公司变得稳定、牢固、可持续，并且仍然能够持续增长的过程中令人愉快的转折点。

在各个阶段，贝尔-梅森诊断法允许您衡量和以图形方式绘制组织在 12 个相对独立的活动维度中的绩效，即

技术/工程
产品或服务
制造、产品支持和交付
商业计划
市场营销
销售和业务发展
首席执行官
团队
董事会
现金
融资能力
总体管理控制

初创公司在每个维度中都根据从 600 多家公司的经验中提炼出来的良好实践规则进行评估。然后，每个阶段的结果都绘制在 12 维雷达图上，如图 1 所示。

请注意，随着公司从一个阶段发展到下一个阶段，每个维度都会增长，但不一定以相同的速度增长。这是因为在某些发展阶段，不同的维度显得尤为重要。尽管如此，当一家公司到达产品开发阶段结束时，它需要相当全面。

在所有情况下和所有阶段，应用的启发法都是具体且可衡量的。例如，在最早阶段提出的一些问题包括

技术是否可持续？
它可以转化为客户购买的产品吗——还是仅仅是一个功能？
是否需要两个以上的计划突破？
是否已为产品确定了真正的客户？
是否存在经过市场测试的令人信服的购买理由？
是否存在 x 计划（其中 x = 工程、支持、营销、销售和公司发展计划）？

您会惊讶地发现，如此简单的“是/否”问题有多少次被回答为“否！”

将此与“直觉”常识进行对比，这种常识在很长一段时间内指导着投资者和员工的决策，参考了以下著名的经验法则，例如

人，人，人。
市场，产品，团队。
我首先看重愿景。
大浪可以冲起很多冲浪板。

南洋管理公司的经验证明了依赖这些主观观察与采取更定量方法之间的区别。在 1995 年至 1998 年期间，这家风险投资公司进行了 29 次系统分析。3 后来的回归分析表明，实际业务绩效与通过应用贝尔-梅森诊断法揭示的指标之间存在近乎完美的关联。

功能障碍的根源

通常，组织问题源于首席执行官无法组建一个跨越所有关键公司职能部门的有效团队，包括：工程、营销、销售、支持、财务和行政管理。在任何构建新产品或服务的组织中，冲突不可避免地会围绕表 1 中所示的问题产生。冲突通常从产品定义开始，因为通常来自工程背景的营销人员与负责实际设计和构建产品的工程师发生冲突。如果出现重大的质量问题，冲突很可能会蔓延到整个组织——甚至吞噬董事会——因为要评估损失并找出并仔细分析根本错误。

表 1

功能失调的冲突及其参与者

产生冲突的问题	涉及的组织
产品定义	工程/营销
客户/市场细分销售生产力的定义；客户信息	营销/销售
产品定价	财务/营销/销售
产品的交付和/或支持	销售/支持/渠道
解决产品或客户问题	工程/渠道/支持/销售
质量	财务/生产/所有部门
管理部门规模和/或预算	财务/所有部门
裁员	董事会/首席执行官/所有部门

即使没有剧烈冲突的推动，组织功能障碍也可能纯粹基于关键群体之间的不尊重或某些部门领导之间的不信任而发展。虽然团队中的每个人都“喜欢”彼此不是必要的，但他们必须相互尊重，能够并愿意相互沟通，并且围绕一套共同的业务目标牢固地团结在一起。否则，该企业注定要失败。事实上，当严重的 disrespect 在组织最高层变得显而易见时，它可能会造成裂痕，最终将一家价值超过 100 亿美元的公司化为瓦砾，正如数字设备公司倒闭所证明的那样。4

组织冲突本身是健康和自然的——尤其是在工程和营销之间似乎不可避免地产生的紧张关系方面。这种特殊冲突的种子在于，虽然工程团队的目标是开发以前不存在的东西，但营销的目标是满足客户当前的即时需求，同时还要预测他们未来的增长需求。因此，工程产品越陌生和“新”，该产品就越难推向市场。尽管如此，只要管理得当，由此产生的冲突就没有理由升级为消耗公司的问题。

每当产品失败时，大多数功能“失误”都可以追溯到工程或营销的无能，或者仅仅是两者之间缺乏整合。然而，最终，任何这些问题的真正责任都必须由首席执行官和董事会承担，因为他们未能展现必要的领导力来建设性地指导和管理自然发生在职能部门之间的冲突。

以此为背景，接下来让我们看看一些经典的失败情景。如果其中任何一个看起来令人不安地熟悉——尤其是如果它们似乎描述了您目前参与的公司——您可能需要认真考虑您的时间和/或金钱是否得到了最佳利用。

虚幻软件现象

尽管“虚幻软件”这个词似乎与高科技产业本身的历史一样悠久，但我们实际上要感谢图 2 中描绘的公司。可以肯定地说，如果您遇到另一家具有类似情况的公司，请跑——而不是走——朝相反的方向。

在本例中，创始人，包括首席执行官，都来自销售背景。这有助于解释，在台式系统的功能勉强可以生成单一功能产品的时候，这个团队是如何提出了一个规范，要求将多种个人生产力功能结合起来的。尽管他们设法将该计划出售给一群容易上当的风险投资家，但一旦他们试图聘请工程团队来构建产品，他们的问题就开始真正开始了。鉴于管理团队在销售之外的几乎所有组织职能方面的整体经验不足，强大的工程团队无法轻易组建也就不足为奇了。然后，更糟糕的是，当在职工程师挣扎（但未成功）地构建产品时，销售人员已经在外面接订单了。

因此，当我们回顾公司的最终记分卡时，我们发现一个组织有一个合理的产品创意，尽管这个创意无法完全实现。由于经验不足的首席执行官和软弱的董事会掌权，事情开始瓦解，因为公司发现自己无法聘请一支能够构建任何与指定产品略有相似之处的 A 级团队。最后，公司犯下了在没有产品可卖的情况下就配备销售人员的最终愚蠢行为。因此，该公司在拥有产品基础之前就已经完全烧光了充足的现金供应，并且管理团队很快意识到，在任何地方都看不到额外的投资前景。我们都知道接下来发生了什么：公司崩溃了，被扫进了历史的垃圾堆，只留下了“虚幻软件”这个词作为其唯一的真正遗产。

梦想之地：建造它，他们就会来

我们的下一个厄运情景涉及一个经常被讲述的故事——一家以技术为中心的公司，由于缺乏有意义的营销投入而一再未能定义成功的产品（见图 3）。由于开发人员从未被迫考虑实际用户的需求和愿望，因此不可避免地会导致误导性的产品规格。因此，他们只是继续构建一些提供他们自己觉得有吸引力的功能的产品。结果是只有其开发人员才会喜欢的产品。其他人都非常乐意忽略它。

随着公司增加更多销售人员，试图通过蛮力来增加销售额，问题变得更加复杂。不可避免地，公司只会加速其现金消耗率。当然，管理层和营销团队对此负有主要责任，因为他们未能根据仔细研究的市场需求来指定设计参数。但我倾向于责怪工程团队在产品定义时依赖于明显不足（甚至可能不存在）的营销投入。事实上，最终，工程师始终对他们设计产品的成败负责！

创始人疾病爆发

这是另一种可能太熟悉的情景。公司刚刚完成了将有希望的技术转化为工作产品的艰巨任务。当然，这标志着在许多领域大力扩展努力的时候——市场开发、分销、销售、生产和支持是最重要的领域。在某些情况下，董事会成员可能会认为这是他们用“做过这件事的管理专业人士”取代创始人的暗示。

通常，这会使创始人面临浮士德式的交易：他们可以帮助新的管理团队为公司收购或首次公开募股做准备，或者他们可以干脆离开，不带股票。毫不奇怪，大多数人选择留下来等待丰厚的回报。但这并不意味着他们很高兴。事实上，大多数帮助创建公司的核心人物，虽然对公司的成功深信不疑，但也从根本上不愿意将权力让给新人。

因此，由董事会亲自挑选的新任首席执行官最终面临着一项令人羡慕的任务，即创建一个主要由被降级为次要角色的原始创始人组成的新管理团队。这肯定是消极攻击行为和有毒、阴郁氛围的秘诀。因此，新任首席执行官几乎肯定从一开始就注定要失败。公司本身可能很快就会陷入泥潭，因为高级管理人员有意识或无意识地努力破坏新来的外来者。像这样的疾病很快就会蔓延到整个公司文化。任何复苏都可能被证明是极其漫长和痛苦的——在事情最终好转之前，可能会牺牲一批又一批的首席执行官和一些原始创始人。

打了就跑计划

“品牌”企业家，尤其是在硅谷，似乎总是能够获得足够的资本来创办一家新公司——即使只是凭一个明显 marginal 的想法。一旦资金到位，剩下的就是聘请一支经验丰富的雇佣兵团队，他们以前做过所有的事情，并且有能力让企业家迅速重返商业领域。从那时起，游戏计划变得异常简单：生产产品，然后全速准备将公司出售给更大的公司或通过首次公开募股向公众出售。

这张照片有什么问题？只有这一点：虽然受人尊敬的企业家已经创办了三家或更多公司，可能已经为自己和早期投资者赚取了数亿美元，但他们几乎肯定从未设法为股东创建一个可持续的、盈利的公司。也就是说，在事情刚刚开始看起来很有趣之后不久，公司的大部分投资者和几乎所有员工都可能最终成为接盘侠。因此，我在此敦促的注意事项是始终警惕名人企业家。

总结

失败的初创组织，在很大程度上是那些被证明无法应对技术复杂性和技术快速变化，同时作为组织成长的组织。作为技术专家，当试图理解公司的突然倒闭时，我们的本能通常会引导我们寻找设计缺陷或底层技术问题。尽管几乎总是可以找到这些问题，但麻烦的真正根源通常可以追溯到基本的人性弱点和有问题的组织动态。

通常，核心问题被证明是以下任何一项或全部

软弱或过度控制的首席执行官
营销不足（或者，在某些情况下，完全缺乏营销）
无法整合工程和营销

所有这三者——顺便说一句，这三者绝非相互排斥，而且实际上经常被发现是同路人——都根植于不信任。例如，有些公司领导 simplemente 无法放弃某些特定的责任，主要是因为他们不相信其他人能够正确地完成这项工作。有时，这种恐惧是有真实依据的——就像在一个人们已经充分证明了自己的无能的组织中那样。但这并非全部，因为功能障碍甚至可以在最能干的组织中蓬勃发展，这是由于贪婪、自我中心的人造成的，他们根本没有打算在任何时候与任何人分享任何权力、荣耀或奖励。

对于任何考虑在公司中持有（或继续持有）股份的人来说，这一切都归结为识别人性的基本弱点，并理解这些缺陷如何导致功能失调的组织行为。衡量和量化这些公司行为中最能说明问题的行为的能力正是贝尔-梅森诊断法的全部意义所在。如果诊断法揭示了您的组织如何运作的令人不安的景象，那么您如何回应这种洞察力也可能会让您更好地了解自己的全部意义。问

参考文献

1. Bell, C. G., 和 McNamara, J. E. 高科技企业：创业成功的指南。Addison-Wesley, Reading: MA, 1991。

2. Mason, H., 和 Rohner, T. 风险投资势在必行：企业创新新模式。Harvard Business School Press, Boston: MA, 2002, 301–307。

3. 南洋风险投资：见 http://www.nanyang.com.au/。

4. Schein, E. H. DEC 已死，DEC 万岁：数字设备公司的持久遗产。Berrett-Koehler, San Francisco: CA, 2003。

戈登·贝尔是微软媒体呈现研究组的高级研究员，该研究组是该公司湾区研究中心 (BARC) 的一个组成部分。他曾在卡内基梅隆大学教授计算机科学和电气工程，并且是国家科学基金会计算理事会的第一任助理主任。贝尔在多个董事会任职，参与了许多专业组织，并获得了 IEEE 冯·诺伊曼奖章和国家技术奖章。

最初发表于 Queue 卷。1，否。9——
在数字图书馆中评论本文

更多相关文章

Martin Kleppmann, Alastair R. Beresford, Boerge Svingen - 在线事件处理
跨异构存储技术对分布式事务的支持要么不存在，要么操作和性能特征不佳。相比之下，OLEP 越来越多地用于在这些设置中提供良好的性能和强大的 consistency 保证。在数据系统中，日志通常用作内部实现细节。OLEP 方法有所不同：它使用事件日志而不是事务作为数据管理的主要应用程序编程模型。传统数据库仍然使用，但它们的写入来自日志，而不是直接来自应用程序。使用 OLEP 不仅仅是开发人员的实用主义，而且它还提供了许多优势。

Andrew Leung, Andrew Spyker, Tim Bozarth - Titus：将容器引入 Netflix 云
我们相信，我们的方法使 Netflix 能够快速采用容器并从中受益。虽然细节可能特定于 Netflix，但通过与现有基础设施集成并与合适的早期采用者合作来提供低摩擦容器采用的方法，对于任何希望采用容器的组织来说，都可能是一种成功的策略。

Marius Eriksen - 大规模功能化
现代服务器软件的需求很高，需要进行开发和操作：它必须随时随地可用；它必须在几毫秒内回复用户请求；它必须快速响应容量需求；它必须处理大量数据和更多流量；它必须快速适应不断变化的产品需求；并且在许多情况下，它必须容纳一个庞大的工程组织，其众多工程师就像一个大型、混乱厨房里的谚语厨师。

Caitie McCaffrey - 分布式系统的验证
Leslie Lamport 以其在分布式系统方面的开创性工作而闻名，他曾说过：“分布式系统是指您甚至不知道存在的计算机的故障可能会导致您自己的计算机无法使用。” 鉴于这种黯淡的前景和大量可能的故障，您甚至如何开始验证和确认您构建的分布式系统正在做正确的事情？