首页 创业 创业失败指南：如何做垮一家创业公司？

创业失败指南：如何做垮一家创业公司？

作者：紫桐 · 分类： 创业 ·    2024年09月 ·   标签：

成功创业公司的经验都是类似的，但失败的创业，却可能是千差万别的原因。比如决策者错误的判断、过度自信或领导的自恋、甚至过于臃肿的流程……

今天这篇文章，我们尝试整理了一些可能导致创业失败的创业方式，在不知道「怎么做才能成功」的时候，或许知道「不要怎么做」也是一种解题办法。

先从一本看起来跟创业无关的指导手册开始。

1944 年，美国中央情报局 (CIA) 前身的战略情报局 (OSS) 编写了一本《简单破坏现场手册 (Simple Sabotage Field Manual)》，用以协助海外官员在挪威和法国等被占领国家培训「公民破坏分子」。

手册中为潜伏者列出了一些破坏当地公司生产力的方法，其中一些建议至今仍不过时。比如关于「干扰组织和生产」的部分：

  • 坚持所有事情都要走「正规渠道」，绝不允许为了加快决策速度而走捷径。

  • 尽可能频繁且冗长地发表「演讲」，用长篇故事和个人经历来说明你的「观点」，别忘了加几句「爱国」评论。

  • 把所有事情提交给委员会「进一步研究和考虑」，并试着让委员会尽可能臃肿，至少 5 人以上。

  • 尽可能频繁地提出不相关的问题。

  • 对通信、会议记录、决议的措辞斤斤计较。

  • 回顾上次会议已决定的事项，并试图重新讨论这些决定的可行性。

  • 提倡「谨慎」，保持「理智」，并敦促同事们避免可能导致尴尬或困难的匆忙行动。

  • 担心任何决定的适当性——质疑这些行动是否在小组的管辖范围内，或者是否可能与上级政策相冲突。

现在，假设你受雇为一家互联网/AI 创业公司的 CTO，想在不被发现的情况下尽可能长时间地破坏这家公司的生产力。你不能做出一系列明显的错误决定，因为这样很快就会被解雇。我们真正的目标是慢慢地削弱公司的生产力，同时保持表面上的合理和正常。

你需要怎么做？

文章编译自 Erik Bernhardsson 的文章《Simple sabotage for software》，Founder Park 略有增删。

原文：https://erikbern.com/2023/12/13/simple-sabotage-for-software.html

01 

技术：

让技术开发尽可能复杂

  • 加入公司时，要求用 6-18 个月的时间重写核心系统，并把责任推给前任 CTO。

    鼓励每个人使用自己喜欢的语言和框架。

  • 将系统任意分割为多部分，涉及特定功能的系统越多越好。

  • 鼓励复杂的开发设置：至少运行一个有十几个服务的服务网格。

  • 确保生产环境与开发者环境尽可能不同。

  • 尽可能少地发号施令，主张对决策保持极端谨慎，利用任何生产问题作为「刹车」的理由。

  • 为代码变更和常见工作流引入非常复杂的流程，并归咎于「安全」或「合规」。

  • 确保每个任务都在系统中被跟进，并经过至少 5 人的审查、优先排序和签字。

  • 禁止任何超出原任务范围的事项，例如代码清理或其他偶发性改进。

  • 内部开发所有非核心竞争力的东西，并以「避免供应商锁定」为理由。

  • 坚持在所有事物上添加抽象层，使用本身就抽象的供应商，然后再添加额外的抽象层。

  • 鼓励基于极乐观的扩展预期做出技术决策，计划至少比现有负载高出三个数量级。

  • 鼓励系统的共同所有权，确保没人对维护负责。

  • 坚持将几乎所有系统和功能都集中化为「平台」，由专门的平台团队负责。让平台团队人手不足，阻止其他团队开发任何可能属于平台的东西。

  • 让平台团队频繁迭代 API，并要求其他团队尽可能频繁地重构代码以适应最新版本。

  • 雇用「架构师」，要求任何大小变更都要进行「架构审查」。

  • 要求即便是小变更也要进行「安全审查」。

 

02 

产品：

主推大战略、大规划

  • 以学术理由（例如「有偏」或「滞后指标」）忽略有用的指标。

  • 选择与业务价值相关性低且噪声大的虚假指标。

  • 坚持将任何举动都当作「大赌注」，坚持把所有工作做完才上线产品。

  • 认为每个功能都是「必备」的，并且是「版本零（首个版本）」的关键部分。绝不妥协。

  • 制定极其详细的「战略」计划。

  • 频繁转向。

  • 将明显的改进视为「局部优化」。

  • 利用最新趋势来占据资源。启动一个看似合理但空洞的「AI 战略」，在这些方面花大钱请供应商和顾问。

  • 鼓励产品经理将大部分时间花在「战略」和「规划」上。

  • 让工程师和产品经理很难/无法在内部使用产品。

  • 在部门内部把用户视为「愚蠢的」。

 

03 

领导层：

让汇报关系尽可能复杂

  • 将薪酬与头衔挂钩，并将头衔与团队规模挂钩，以激励团队膨胀。

  • 大谈策略、功能或技术复杂性。

  • 进行昂贵的收购以进入新产品领域，并以「协同效应」为由，关闭收购的产品。

  • 在汇报结构中使用大量虚线，让汇报关系尽量复杂。

  • 尽可能让员工向其他团队、地点或职能部门的经理汇报。确保经理没有能力监督他们的下属。

  • 频繁将表现不佳的员工重新分配到其他团队。

  • 将高业绩员工分配到投机性高且交付成果不明确的研发项目上。

  • 任何决策都要开会，无论决策内容多么微不足道。

  • 坚持每个「利益相关者」都要出席会议。

 

04 

招聘：

尽量把合适的人排除在外

  • 创建一个看似客观但实际上主观的招聘流程。

  • 以「文化不适」或其他模糊标准为由拒绝最好的人。

  • 根据「潜力」或「态度」或其他模糊标准雇用最弱的候选人。

  • 招募非常贵的高级领导，并对其承诺大量的人员编制。

  • 使用夸大的头衔和虚构的职位来吸引机会主义者。

  • 雇用高度专业化的「专家」，搞点无关紧要的项目来防止他们辞职。

  • 以专业化为借口，雇用更多专业「互补」的人。

 

05

项目管理：

尽量跨部门合作

  • 要求对任何项目进行非常详细的财务预算。

  • 鼓励尽可能多的团队参与项目，最好在不同地点。

  • 添加仰赖于其他团队工作的新需求。

  • 频繁使用昂贵的代理机构，让项目范围模糊，并将未完成的原型交给内部团队完成。

  • 为其他团队中的利益相关者构建复杂的「自助」系统。

 

执行这些破坏任务并不容易！但如果你能进入竞争对手的战线后方，得到 CTO 的职位，就能实现这些目标。

对于非破坏者（真正的创业者）来说：显然，这其实是在讲如何最大化团队的产出。生产力的问题通常是由无数小问题累积而成，这些小问题本身并不会毁掉生产力。但是，生产力是按对数尺度增长的，也就是说，所有这些问题会以乘法的方式复合累积。

基本上，如果你做了 100 件事，每件事都让生产力降低 5%，你就把整体效率减慢了 131 倍！

唯一能让工程师们满意的方法，就是拒绝那些看起来合理但实际上有害的 100 个小问题，让团队尽可能的专注和高效。

附：如果你还有更多的失败方式，欢迎在评论区告诉我们。

内容原载于: Founder Park

7