《横向领导力》与重读《矛盾论》《实践论》：没有职权时，怎么推动你认为对的事

参考书籍：罗杰·费希尔、艾伦·夏普《横向领导力》(Getting It Done)；《毛泽东选集》第一卷《实践论》《矛盾论》（重读，只取实操部分）。 目标读者：想往架构师、CTO 方向走的工程师——你会发现越往上走，越多的决策要靠影响力而不是职权推行，尤其跨团队架构治理。 阅读目标：回答两个真问题——没有职权时怎么推动人（横向领导力）；冲突和路线之争里怎么判断往哪推（矛盾论）。前者管组织动员，后者管方向判断。

这是情商系列的第三篇。第一篇（《情商》+《被讨厌的勇气》）管自己：觉察情绪、划清课题；第二篇（《关键对话》+《非暴力沟通》）管对话：保住安全感、把评判翻译成观察。这一篇管的是前两篇都解决不了的事——当你判断一件事是对的、但没有职位赋予你推它的权力时，怎么办。

关于毛选部分要先说一句：2017 年我写过一篇《程序员学屠龙术》，那篇是把《实践论》《矛盾论》当认识论总览读。这次重读换了一个更窄、也更狠的读法：只把两论当"识别主要矛盾"的裁决工具用。团队冲突、技术路线之争、技术债该不该还——本质上都是"当前阶段的主要矛盾是什么"的问题。

一、《横向领导力》:权威不在场时的领导

1.1 这本书的前提：等领导来协调，是最贵的协作方式

费希尔是哈佛谈判项目的老教授（《谈判力》的作者之一），这本书回答的问题非常具体：在一个你没有汇报关系的场合——跨部门项目、技术委员会、开源社区——怎么让一群人协作起来把事做成。

书里先破了一个普遍幻觉：“我不是领导，所以领导力不是我的事。“费希尔的反驳：横向协作场景里根本没有领导，“等领导来拍板"这个选项的代价被严重低估了——

• 领导的信息带宽有限，他用三十秒拍的板，质量受制于他掌握的信息量；
• 上交决策的同时，也上交了方案的 ownership——“老板定的"是执行阶段最好用的免责理由；
• 等你有了职权再学领导力，就像等起火再学消防。

1.2 方法骨架：先修自己，再带别人

横向领导力不能直接从"影响他人"开始，书里给了一条严格的次第：

flowchart LR
    A["第一步: 修好自己<br/>五个个人技能<br/>目标、思考、学习<br/>专注、反馈"] --> B["第二步: 明确共同目标<br/>把 我的方案<br/>变成 我们的问题"]
    B --> C["第三步: 影响他人<br/>三招: 提问、作答、示范"]
    C -.->|"别人不买账时<br/>回来继续修自己"| A
    style A fill:#FFD700

五个个人技能里，对工程师最有增量的是思考这一环——书里给了一个四象限思考框架，任何协作僵局都可以往里装：

这个框架的价值在于：僵局通常是因为各方在不同的象限里喊话——有人在讲数据，有人在讲行动，听起来是争论，实际是错频。

1.3 踩坑故事一：发通知推规范，响应率是零

第一次做跨团队架构治理时，我的打法是"把事做对”：调研两周，写了一份二十页的接口规范文档，评审通过，然后发全员通知：“自 X 月 X 日起，新接口按此规范执行。”

一个月后执行率接近于零。

用四象限复盘：我在自己的脑子里完整走过了数据→诊断→方向→行动，然后只把最后一环（行动）发给了别人。其他团队看到的不是一个共同问题的解法，而是一份从天而降的约束——他们没有经历诊断过程，自然没有这个方案的情感账户和认知账户。

第二次换成横向领导的打法：先不提方案，用提问开场，一对一问了六个团队的接口人同一个问题：“你们现在的接口对接，最疼的点是什么？"——收获超出预期：四个团队提到的痛点就是我的规范要解决的，但从他们自己嘴里说出来的问题，才是他们的问题。规范内容改了不到 20%，执行率反过来了。

影响力的本质转换：从"我的方案"到"我们的问题”。 方案可以更好，但问题必须是共同的。

1.4 踩坑故事二：等领导拍板，等来一个两边都不满意的三十秒

两个组对服务拆分边界有分歧，我判断这是"需要更高层信息才能定的事”，于是把两个方案写成材料上交，等 CTO 裁决。

材料在领导队列里躺了两周（他有更要紧的事），终于排到，他用三十秒拍了一个折中方案：边界按组织隶属关系切。两边都不满意——技术上是错的，但谁也没有动力再争，因为"老板定的”。

半年后这条边界成了全系统调用链最深的重灾区。

费希尔书里有一句话我这次是真读懂了：横向问题尽量横向解决，上交领导的决策质量受限于领导的信息带宽。 领导拍板的价值不在"他更懂”，而在"他能让争议终止"——这是兜底机制，不是首选机制。首选机制是把争议双方摁在同一张四象限表前面，把数据象限先填满。大多数技术争议，数据填满之后自己就消解了。

1.5 踩坑故事三：复盘文化推不动，直到我把自己摆上解剖台

我曾想在团队里推"故障复盘不追责"的文化，写了流程文档、开了宣讲会，响应寥寥——大家嘴上说好，真出故障还是甩锅现场。

转折点是我自己搞砸了一次发布之后。我没有按惯例低调处理，而是写了一份公开的复盘文档，开头就是决策时间线：我在哪个节点掌握什么信息、做了什么错误判断、当时的替代选项是什么。把自己摆上了解剖台。

效果出乎预料：那次复盘之后，第二个、第三个复盘开始出现，而且质量越来越高。这就是费希尔三招里的第三招——示范（modeling）。提问是让别人思考，作答是给出你的思考，示范是直接做出你希望别人做的行为。三招里示范成本最高、威力最大，因为人们不怀疑你说的是否正确，他们怀疑的是你自己是否照做。

二、重读《矛盾论》《实践论》:裁决工具化

2.1 《矛盾论》的裁决四步

这次重读，我把《矛盾论》压缩成一个在技术争议现场可以当场跑的分析流程：

flowchart TD
    A["列出当前所有矛盾<br/>技术 vs 业务、质量 vs 速度<br/>新框架 vs 存量系统"] --> B["找出主要矛盾<br/>此刻真正限制系统产出的<br/>是哪一个"]
    B --> C["抓矛盾的主要方面<br/>这对矛盾里<br/>哪一方当前起主导作用<br/>撬动它才能改变局面"]
    C --> D["标注阶段性<br/>主要矛盾会转化<br/>今天的正确决策<br/>下个阶段可能就是错的"]
    D -.->|"阶段变化后<br/>重新分析"| A
    style B fill:#FFD700
    style D fill:#FFB6C1

每一步对应《矛盾论》的一个核心概念：列矛盾（矛盾的普遍性）、找主要矛盾、抓矛盾的主要方面、标注阶段性（矛盾的发展与转化）。这套东西听起来抽象，落到技术裁决上极其锋利，看下面的故事。

2.2 踩坑故事四：技术债之争，吵了三次会都没吵对地方

团队为"先还技术债还是先赶业务需求"吵了三次会。还债派列代码腐烂清单，业务派列交付承诺，双方论据都很充分，会议每次都卡在平局。

第三次会后我用矛盾四步重新拆了一遍：

1. 列矛盾：代码质量 vs 交付速度、重构风险 vs 线上稳定、团队技术热情 vs 业务方耐心；
2. 找主要矛盾：当时真正限制产出的是什么？不是代码烂——而是交付速度已经连续两个迭代不达标，业务方的信任濒临破产。信任破产的代价大于一切技术债；
3. 抓主要方面：在"质量 vs 速度"这对矛盾里，当前的主导方面是债务中直接拖慢交付的那一部分——烂代码很多，但只有反复改动、反复出 bug 的三个模块真正在吞噬交付速度；
4. 阶段性：信任修复之后，主要矛盾会转化回代码质量，届时再还其余的债。

决策随之清晰且可辩护：冻结新需求两周，只还那三个模块的债（这是矛盾的特殊性——不是所有债都值得还，还错地方的还债也是浪费），其余债务登记入册排期。两个月后交付恢复，业务方信任回升，剩余债务在后续迭代按计划清偿。

这个案例里矛盾论真正教会我的是：技术裁决不是评判"哪个方案更好"，而是识别"当前阶段的主要矛盾是什么"——方案没有绝对优劣，只有是否对准当前主要矛盾。 还债派和业务派都没错，他们只是各自对准了不同阶段的矛盾。

2.3 踩坑故事五：框架选型之争，主要方面根本不是技术

一次选型评审僵持不下：A 派支持沿用现有框架（稳），B 派支持引入新框架（长期收益大）。双方列的 benchmark、生态对比、社区活跃度，全是技术维度的论据，谁也说服不了谁。

用"矛盾的主要方面"切进去：这对矛盾的表面是"两个框架的优劣"，但当前起主导作用的方面是什么？我列了下双方的实际约束，答案浮出来——是团队对新框架的熟悉度。B 派的三个人玩过新框架，A 派没有人碰过。学习曲线风险，而不是框架性能，才是这个决策真正的支配变量。

看清主要方面之后，决策反而容易了：给两周时间，B 派出一个人带 A 派做新框架的概念验证，用团队真实的学习速度数据来定——而不是用网上的 benchmark 来定。两周后数据出来，团队自己动手做完 PoC 的那天，争议其实已经结束了。

技术争议僵持不下的信号，往往是双方都在论证次要方面。 主要方面一旦显形，多数争议会自己消散。

2.4 《实践论》：没有调查，就没有发言权

《实践论》的认识循环，这次重读我把它画成了工程里的决策循环：

flowchart LR
    A["实践<br/>调研、试点、动手"] --> B["感性认识<br/>一堆碎片事实"]
    B --> C["理性认识<br/>抽象出规律和判断"]
    C --> D["再回到实践<br/>拿判断去做决策"]
    D -->|"结果检验认识<br/>错了就修正"| A
    style C fill:#FFD700

两条实操推论：

• **“没有调查就没有发言权”**放在技术评审里就是：没看过代码、没跑过压测、没找当事人聊过的人，意见权重应当打折。评审会上嗓门最大的意见经常是调查量最小的；
• 认识必须在实践里检验——所以推规范不要先写完美文档再全面铺开，先在一个组试点，拿数据，修正，再推广。我在第一篇情商笔记里写的人际复盘、第二篇里的会前利益假设，本质都是这个循环的人际版。

三、两本书合流：一个管方向，一个管动员

缺了前者，横向领导力会变成高效的错误——动员能力很强，方向是歪的；缺了后者，矛盾分析会变成孤独的正确——判断很准，但只有你一个人信。方向判断和组织动员，是"影响力"这件事的两条腿。

四、配套练习：主动认领一次"得罪人"的事

理论读完，这个阶段的实修作业只有一道：主动认领一个有人反对、但你判断为对的技术决策（偿还某块技术债、统一某个接口规范、砍掉某个半成品项目），完整走一遍下面这个剧本：

flowchart LR
    A["第一步: 私下沟通<br/>裁决前一对一<br/>听懂每个反对者的<br/>真实顾虑"] --> B["第二步: 争取盟友<br/>让关键人的意见<br/>提前进入方案"]
    B --> C["第三步: 会上裁决<br/>用矛盾分析陈述理由<br/>明确代价和推翻信号"]
    C --> D["第四步: 事后安抚反对派<br/>承认损失 不推翻决策"]
    D -.->|"全程记录<br/>写成一篇人际 ADR"| A

每一步的要点，都是前面三篇笔记的工具在实战里汇合：

1. 私下沟通：用的是关键对话的"从心开始"和非暴力沟通的"观察而非评判"。反对者在会上说的话是立场，私下说的才接近利益——故事二里那些"回头再说"，一对一的时候往往有真东西；
2. 争取盟友：就是毛选统一战线的工程版——裁决前让关键人的意见进入方案。方案里有他的一句话，他在会上就是你的盟友；这不是搞政治，是让方案吸纳真实约束；
3. 会上裁决：陈述结构用矛盾四步——当前主要矛盾是什么、为什么这个方案对准它、代价是什么、什么信号出现时该推翻。最后一条最值钱，它告诉反对派：这不是我的面子，这是一个可验证的赌注；
4. 事后安抚反对派：回到《被讨厌的勇气》——安抚是承认对方承担了损失（“这个决定让你的组多背了两周工作量，我记着”），而不是推翻决策也不是假装没有代价。课题分离：做对决策是我的课题，消化失望是他的课题，但承认损失、记在账上，也是我的课题。

成不成，这一遍走下来都是教科书级的一课——成了，你收获一套可复用的推动剧本；败了，人际 ADR 里会留下一次完整的归因记录。

五、我的思考和感悟

1. 裁决者挣的不是"判断正确"的钱，是"判断正确之后还能推行"的钱。 技术判断力决定你能不能看清主要矛盾，横向领导力决定看清之后局面会不会动。我身边技术判断一流、推行能力为零的人不少，他们的共同遭遇是：正确的意见被无视，然后抱怨组织愚蠢——抱怨组织愚蠢，是用课题上交的方式逃避自己的课题。

2. 重读毛选最大的变化，是读懂了"阶段性"三个字的分量。 2017 年第一次读《矛盾论》，读出来的是热血——抓主要矛盾，大刀阔斧。这次读出来的是沉重——主要矛盾会转化，意味着今天无比正确的决策，明天可能就是主要障碍。两年前我认为绝对正确的技术选型，今天就在还债清单上躺着。这不是当年错了，是阶段变了。裁决者必须习惯一件事：你的每个决策都自带保质期。

3. “没有调查就没有发言权"是对评审文化最狠的一条建议。 技术会议里意见的质量分布，和发言者的调查量分布高度相关——但和职级、嗓门、口才几乎无关。把"你调研过吗"变成评审会的合法问题，会议质量会立刻改观。

4. 争取盟友不是搞政治，但拒绝争取盟友一定是搞砸。 工程师对"会前串联"有本能的道德洁癖，觉得方案好就该在会上赢。现实是：会上才第一次听到方案的人，默认反应是防御——这和信息量无关，和安全感有关（第二篇的场）。会前一对一不是阴谋，是给对方消化信息的时间。

5. 三篇笔记合起来的完整链条：先能觉察自己的情绪（第一篇），再能在对话里听懂别人（第二篇），最后能在没有职权的情况下推动局面（第三篇）。这个顺序不可颠倒——自我管理是影响力的信用基础，听懂他人是方向判断的信息基础。

六、行动清单（12 周版）

参考与延伸

• 罗杰·费希尔、艾伦·夏普《横向领导力》，核心章节：五个个人技能、四象限思考法、影响他人的三招（提问、作答、示范）。
• 《毛泽东选集》第一卷《实践论》《矛盾论》。重读建议：别从头读到尾，带着一个正在僵持的真实争议去读，读一段就往里套一次。
• 旧文衔接：《程序员学屠龙术》——那篇是两论的认识论总览，本篇是两论的裁决工具化，建议按"总览→工具"的顺序读。
• 系列前两篇：《情商》与《被讨厌的勇气》（自我觉察与课题分离）、《关键对话》与《非暴力沟通》（安全感与语言精度）。

• 读书笔记

• 横向领导力
• 毛选
• 矛盾论
• 实践论
• 读书笔记
• 领导力
• 个人成长

方糖猫（大可）

18 年后端架构，现在独立做 AI 产品。这里记录 AI 视频、AI Agent 与工程实践。