如何化解管理风格冲突？不同领导风格的协作方法

“有些领导者更像曼哈顿计划，有些领导者更像阿波罗计划。你会在这两种风格之间切换，但整体上更偏向阿波罗计划式。”

我和 CEO 每周一次的散步交流，就这样开始了。这句话来得有些突然，让我一时不知道该如何回应。

这是赞扬，是批评，还是一种客观观察？

琢磨了一会儿，我才逐渐明白：他已经注意到，我们在一些问题上的判断存在分歧，而这些分歧很大程度上源于彼此不同的管理风格。

用阿波罗计划和曼哈顿计划来形容领导方式的差异，是一个颇为新颖的比喻。此后，我一直在思考这两种管理风格的区别，也开始重新审视自己与上级及其他管理者沟通、协作和提供反馈的方式。

阿波罗计划是美国在 20 世纪实施的一项载人登月计划，并于 1969 年首次将人类送上月球。曼哈顿计划则是第二次世界大战期间开展的一项大规模研发项目，目标是研制出第一批核武器。它最初规模有限，后来迅速扩张，参与人数超过 13 万，并投入了巨额资金。

当然，这两个项目都极其复杂，不能简单地概括为某一种管理模式。本文所说的“阿波罗计划式”和“曼哈顿计划式”，更多是一种帮助理解不同领导风格和管理风格冲突的比喻。

在这个比喻中，“阿波罗计划式”领导者更倾向于从一个明确但有限的目标出发，快速行动、逐步验证，并根据过程中获得的信息不断调整方向。

“曼哈顿计划式”领导者则更倾向于围绕一个宏大目标，提前调集大量资源，建立更完整的组织结构和执行体系，并以更高强度推动结果落地。

两种方式都可能成功。真正重要的问题不是哪一种管理风格更好，而是哪一种风格更适合组织当下所处的阶段。

不同管理风格为什么会产生冲突

我职业生涯中最愉快的一段经历，是参与创建一家后来被大型科技公司收购的初创企业。

我是最早加入的十名员工之一。当时，我面临两项核心任务：一方面要从零组建工程团队，另一方面要与创始人共同探索产品方向。

我们的产品愿景非常宏大，后来也通过收购方的一系列企业级产品逐步得到延续和实现。当时，我们希望构建一个面向企业客户的统一管理平台，帮助他们管理复杂的基础设施环境。

围绕这一产品，我们设想了很多能力，包括策略管理、合规治理、成本分摊，以及为企业决策者提供统一的管理入口。

不过，我们也意识到，对于这样一款产品而言，我们进入市场的时间可能略早。客户的需求虽然已经出现，但尚未成熟到足以支撑一款完整平台快速增长的程度。

尽管如此，有一点始终非常明确：我们的目标是成为一家产品公司，而不是一家依靠定制项目和专业服务生存的公司。

为了推进产品开发，同时让刚组建不久的工程团队保持动力，我采取的策略是，先构建一个功能最小、但能够持续扩展的基础框架。

当时，我们已经在开发几个核心开源项目。我预计，这些项目未来会成为云平台的重要组成部分。随后，我们可以在这些基础能力之上，逐步为付费客户增加企业级功能。

采用这种方式，我既能制定一份初步的产品路线图，又能继续与客户交流，收集真实反馈，并让这些反馈指导后续的功能开发。

先打通最小可行的工作流程

我们的核心工作流程围绕一个扩展管理组件展开。

按照最初的设计，平台的大部分功能都将通过独立模块来实现。客户可以从我们的服务中安全地获取这些模块，并将其安装到自己的基础设施环境中。

安装完成后，管理员可以根据企业需求，决定启用哪些模块以及哪些具体功能。

要真正保证整个流程的稳定性和安全性，还有大量细节需要解决。但在最初阶段，我们的目标并不是一次性完成所有功能，而是先打通一条完整的端到端工作流程，并选择一个已有的开源工具作为第一个扩展模块。

明确第一阶段的开发范围，对早期团队来说至关重要。

它可以帮助工程师集中精力，避免在宏大愿景下同时开展过多方向。它也能让团队更快交付一个可运行、可演示、可收集反馈的实际成果。

对于今天的研发团队来说，这类“小步验证”的管理方式也需要工具支撑。比如，借助 PingCode 将团队目标、客户反馈、需求评审、开发测试、发布上线和知识沉淀串联起来，管理者可以更清楚地看到每个阶段的进展和依据，既避免过早建设过于复杂的体系，也能确保试验过程中的数据、决策和经验不会丢失。

与此同时，这套具体的工作流程还为我们的招聘提供了一个清晰的故事。

当时，公司正处于快速扩张阶段，我每周都会花大量时间通过视频会议与潜在候选人交流。

大多数工程师，尤其是从事基础设施软件开发的工程师，都会关心两个问题：

加入之后，我具体要做什么？

这里有哪些真正值得解决的技术难题？

由于产品还没有找到明确的市场契合点，我在招聘时必须同时讲好两个故事。

第一个故事是产品的长期愿景：我们最终希望解决什么问题，建立一个怎样的平台。

第二个故事则必须足够具体：候选人加入之后，接下来几个月会参与什么工作，需要解决哪些实际挑战。

我们的创始人在开源技术领域拥有很强的影响力，这本身确实能够吸引一些优秀候选人。但对大多数工程师来说，创始人的声誉并不足以支撑他们作出职业选择。

他们更想知道，自己每天将从事什么工作，以及能否在这家公司产生真正的影响。

循序渐进与宏大规划之间的领导风格冲突

这种循序渐进、先打基础再逐步扩展的方式，对我当时的目标来说很有效，但它并没有完全满足创始人的预期。

他们很高兴看到项目取得进展，也乐于看到团队不断交付具体成果。

但与此同时，这种产品开发方式与他们过去在海外大型科技公司工作时形成的思维模式并不完全一致。

他们希望团队能够更快构建出更强大、更完整的产品功能，即使他们自己也承认，这些功能可能已经领先于当时的市场需求。

我更关注的是：

我们能否先验证核心工作流程，确保基础架构能够运行，再根据客户反馈逐步增加功能？

而他们更关注的是：

既然我们已经知道最终想要建立什么，为什么不尽快把完整体系构建出来？

这正是两种管理风格之间的典型差异。

偏“阿波罗计划式”的领导者，往往更重视从一个明确但有限的目标开始，通过阶段性成果持续学习。

他们愿意在信息并不完整时启动工作，然后根据真实反馈调整方向。

偏“曼哈顿计划式”的领导者，则更愿意从最终目标倒推所需能力，提前建设完整体系，并集中资源推动团队快速到达目标状态。

两种思路本身都没有问题。

真正的问题在于，团队是否对公司所处阶段、市场成熟度和资源条件形成了共同判断。

管理风格也会影响人才选择

这种预期上的差异，很快延伸到了团队建设和人才招聘上。

和许多初创公司一样，我们公开承诺，希望建立一个多元、包容的工作环境。

作为一名负责工程团队的少数族裔管理者，我非常重视这一承诺。尤其是在我同时承担招聘负责人职责的那段时间里，我希望公司的招聘实践能够真正体现这种价值观，而不是只把它写在招聘页面上。

我的招聘策略，是从更广泛的人才市场中寻找合适的工程师，而不是过度依赖某几家知名企业作为主要人才来源。

海外大型科技公司当然拥有许多优秀工程师，也有不少人符合我们对能力和经验的要求。

但如果一家初创公司的核心团队过度集中地来自同一种组织，它很容易在不知不觉中复制原公司的思维模式、工作习惯和组织文化。

而这些方法未必适合一家规模更小、资源更有限、产品方向仍在探索中的公司。

创始人总体上并不反对我的做法，但他们更倾向于招聘来自海外知名科技公司和开源软件企业的工程师。

这种偏好同样延伸到了工程经理的招聘上。

我更希望寻找那些具备初创公司经验、愿意亲自解决问题、能够适应模糊环境，并能在资源有限的情况下推动工作的管理者。

而创始人则更倾向于招聘来自成熟大型企业的工程经理。

候选人曾经在哪家公司工作，本身并不是问题。

真正的问题是，他们对岗位、资源和组织环境的预期，是否与我们当时的实际情况相符。

尽管我们的创始团队背景十分出色，但现实是，我们并不是一家拥有成熟产品、稳定收入和完整管理体系的大型科技公司。

当时，我们还没有真正开发出一款成熟的商业产品，更谈不上已经找到产品与市场的契合点。

然而，一些候选人对岗位权限、团队规模、资源配置和组织成熟度的预期，明显超出了公司当时能够提供的条件。

有时，我甚至觉得，创始人自己也存在类似的预期错位。

他们希望招聘一位未来能够领导大型工程组织的管理者，却低估了公司眼下真正需要的，可能只是一个能够接住具体工作、带好小团队，并在混乱中稳定推进的人。

招聘当前需要的人，还是未来需要的人

有一次，我希望招聘一位更偏“阿波罗计划式”的工程经理。

当时，我迫切需要将部分一线管理职责委派出去，以便把更多时间投入到招聘、外部合作以及潜在收购等事务上。

我找到了一位非常适合我们当下需求的候选人。

他未必能够随着公司一路成长，最终管理数百甚至数千人的团队。但我非常确定，他能够在接下来的一两年里，为我和工程团队提供很大的帮助。

对我而言，这已经足够了。

初创公司并不总是需要一步到位，招到一个能够解决未来十年所有问题的人。

有时，最合理的决定，是招聘一个能够解决当前阶段最重要问题的人。

但那位更偏“曼哈顿计划式”的 CEO 并不认同。他否决了这次招聘。

我当时非常沮丧。

真正让我感到挫败的，不只是失去了一位合适的候选人，而是我清楚地知道：如果得不到这份管理支持，我就不得不继续承担大量一线工作，而这会限制我在其他关键事务上的投入。

此后，我们又陆续面试了几位更偏“曼哈顿计划式”的管理者。

他们往往拥有亮眼的履历，也熟悉成熟企业的管理方式，但他们对岗位的期望与公司的实际情况并不匹配。

随着这种情况不断发生，我的挫败感也越来越强。

承认判断错误，也是管理能力的一部分

几个月后，在一次一对一谈话中，CEO 主动提起了那次招聘。

他承认，自己现在更能理解我当时的想法，也意识到当初应该允许我聘用那位经理。

他甚至问我，那位候选人是否还在原来的岗位上，我们是否应该再次尝试邀请他加入。

虽然事情已经过去，合适的招聘时机也可能不复存在，但我仍然很感激他愿意反思自己的判断，并坦率地承认错误。

这件事让我更加尊重他。

优秀的管理者并不是永远不会判断失误，而是在获得新信息之后，愿意重新审视自己的决定。

更重要的是，这次经历帮助我们真正理解了彼此的管理逻辑。

我们开始认识到，我们并不是在追求不同的目标，而是对实现目标的路径、节奏和资源配置有不同看法。

随着理解逐渐加深，我们也学会了如何更好地适应彼此。

如何化解不同管理风格之间的冲突

任何组织中的领导者，都可能拥有不同甚至相互冲突的管理风格。

问题并不在于大家的风格是否一致，而在于团队能否识别这种差异，并理解差异背后的判断逻辑。

当管理风格冲突出现时，我们很容易把对方的做法理解为错误、短视、保守或者不切实际。

但很多时候，双方真正的分歧并不在目标，而在于对以下问题的答案不同：

公司当前处于什么阶段？

市场需求是否已经足够清晰？

组织拥有多少资源？

现在更大的风险，是行动太慢，还是投入过度？

团队需要先证明方向，还是应该提前建设规模化能力？

要让这些分歧真正进入可讨论、可执行的层面，团队还需要把目标、任务、责任人和关键节点透明化。通过 Worktile 这类通用项目协作系统，将目标、项目、任务、文档、日历和沟通记录集中起来，可以减少管理者仅凭个人判断讨论问题的情况，让双方围绕同一份事实和进展进行协作。

偏“阿波罗计划式”的领导者通常更重视：

快速启动，小步推进；

通过实际成果验证判断；

在不确定性中持续学习；

根据反馈灵活调整方向；

优先解决当前阶段的问题。

偏“曼哈顿计划式”的领导者则通常更重视：

设定宏大而明确的最终目标；

提前建立完整的系统和组织能力；

集中投入人员、资金和其他资源；

通过严密的分工和流程协调复杂项目；

为未来的规模化发展提前做好准备。

两种管理风格并不存在绝对的优劣之分。

真正重要的是，让领导风格与项目性质、组织能力以及公司所处的发展阶段相匹配。

不同发展阶段需要不同类型的领导者

在公司发展的早期，市场方向还不明确，产品仍需反复验证，团队规模较小，资源也十分有限。

在这种环境下，组织通常更需要偏“阿波罗计划式”的领导者。

他们能够在信息不足的情况下启动工作，通过小规模实验快速获得反馈，并根据实际情况不断调整方向。

他们不会等到所有条件都准备充分后才行动，也不会为了未来可能出现的规模问题，过早建设复杂的流程和体系。

但随着公司逐渐成熟，目标更加明确，团队规模不断扩大，跨部门协作越来越复杂，组织便需要更多偏“曼哈顿计划式”的领导者。

他们擅长调动大量资源，建立稳定的组织结构和执行机制，并推动复杂项目在统一目标下有序运转。

一家成熟企业需要的管理方式，显然不同于一家仍在寻找产品方向的初创公司。

同样，一个已经被市场验证、需要快速扩大规模的项目，与一个仍在探索用户需求的项目，也不应该采用完全相同的管理方法。

不要争论哪种管理风格更正确

在公司的整个生命周期中，这两种领导风格都不可或缺。

优秀的组织不会只选择其中一种，也不会试图把所有管理者塑造成相同的样子。

它会识别不同领导者的优势，理解他们最适合解决什么问题，并在合适的阶段为他们配置合适的职责。

当不同管理风格发生冲突时，最有效的方式不是证明谁更正确，而是共同回答几个问题：

我们现在究竟处于什么阶段？

当前最需要解决的问题是什么？

最大的风险来自哪里？

我们需要先验证方向，还是迅速扩大投入？

哪一种管理方式最适合当下的问题？

当领导者能够围绕这些问题坦诚沟通时，管理风格差异就不再只是组织摩擦的来源。

相反，不同的管理风格能够帮助团队看到彼此容易忽略的风险，让组织在行动速度与长期建设、灵活探索与规模化执行之间，找到更合理的平衡。

真正成熟的领导者，不是永远坚持自己最熟悉的管理方式，而是能够根据组织阶段和问题性质，选择最合适的方式。

有时，你需要像阿波罗计划一样，以明确的阶段目标快速前进，在实践中不断修正方向。

有时，你也需要像曼哈顿计划一样，集中资源，建立体系，以强大的组织能力推动复杂目标落地。

领导力的关键，不是固定地属于其中一种类型，而是知道什么时候该采用哪一种管理风格。