Day 52 · 2026.07.11

规模化领导:从"管人"到"管系统"

主题:Scaling Leadership·4 个原则
"What got you here won't get you there." — Marshall Goldsmith
本期的命题:把 5 个人带好和把 50 个人带好,不是同一件事的放大版,而是两种不同的工作。5 个人时你靠亲力亲为和高频接触产生影响;50 个人时你亲手碰的每件事都在稀释你的杠杆。规模化的真正痛点是四个"看不见的漏水点":注意力不够分(还想管人,其实该管系统)、组织结构在悄悄决定架构(Conway 定律)、你的话每过一层就衰减一次文化不会自动复制。本期四个原则逐个补漏——把你从"最忙的人"变成"让别人做对事的人"。
PRINCIPLE 01

从管人到管系统:你的产出=组织的产出 From Managing People to Managing Systems

杠杆系统思维授权
规模化的第一次心智切换:你的产出不再是你亲手做的事,而是你的组织加上你影响到的相邻组织的总产出。别再问"我今天做了多少",要问"哪件事能撬动最多人的产出"——一个高杠杆动作(招对人、修好流程、讲清方向)胜过十件亲力亲为。
"A manager's output = the output of his organization + the output of the neighboring organizations under his influence." "经理的产出 = 他所辖组织的产出 + 他能影响到的相邻组织的产出。" — Andy Grove,《High Output Management》Ch.3
情境:BigCat 团队从 6 人扩到两组共 16 人,你还是每个 PR 都想 review、每个事故都亲自上。下属开始绕过你,因为"等 BigCat 有空要三天"。
✗ 还在管人(不可扩展)

"这个设计等我周五 review 完再合。" "线上出问题叫我,我来看。" "这个决定我拍。"
—— 你成了瓶颈。你越勤奋,团队越依赖你,扩得越大越堵。

✓ 改为管系统(可扩展)

把"我"换成"机制":"我不再逐个 review PR。定三条必须我看的红线(改 schema、动鉴权、跨团队 API),其余你们两两互审。"

"事故不再等我——写一份 on-call runbook 和升级路径,谁值班谁先决策,事后一起做 blameless review 改进系统。"

"我这周的产出不是写代码,是把这两个机制立起来——它们会替我 review 一整年。"

  • 这事只有我能做吗?还是我"最快/最放心"所以抓着不放?(后者=该授权)
  • 我在解决"这一个问题",还是在建"以后此类问题自动解决"的机制?
  • 我这周有没有做一件撬动 10 人以上产出的事(招聘、流程、方向、去阻塞)?
  • 如果我消失两周,团队会卡在哪?那个卡点就是我下一个要系统化的地方。
  • 我日历里"亲手做事"和"提升组织能力"的比例,随规模在变吗?
  • 把"忙"当"有价值"。规模化后,你最忙的时候往往杠杆最低。
  • 授权=甩锅。授权是给出决策权+上下文+安全网,不是把烂摊子扔出去不管。
  • 只授权任务不授权判断。下属长不出决策肌肉,你永远是瓶颈。
Female Leader's Note 规模化时最容易被无视的是"胶水工作"(Tanya Reilly《Being Glue》)——把项目粘合起来的协调、文档、跨组对齐。它正是把组织从 6 人扩到 16 人必需的系统工作,却常被当"打杂",且不成比例地落在女性头上、不进晋升材料。对策:显性化为系统产出——说"我建立了跨组发布协议/事故流程",而非"我帮大家协调了一下"。是架构,不是打杂。
习作:列出你本周亲手做的 5 件事,逐个问"这能撬动几人产出"。把杠杆最低的那件,这周授权或系统化掉。
思考题:我抓着不放的那件事,究竟是因为别人做不了,还是因为放手会让我觉得自己"没用了"?
PRINCIPLE 02

组织设计:你画的组织图,就是你将来的架构图 Org Design — Conway's Law Is Not Optional

Conway 定律Team Topologies认知负荷
组织结构不是行政问题,是技术架构问题。系统的形状会不可避免地长成团队沟通结构的镜像(Conway 定律)。所以设计团队边界=提前设计软件边界:想要什么样的架构,就先组织出什么样的团队;并让每个团队的职责不超过它的认知负荷(Team Topologies)。
"Any organization that designs a system will produce a design whose structure is a copy of the organization's communication structure." "任何设计系统的组织,其产出的系统结构,都会复制该组织的沟通结构。" — Melvin Conway,《How Do Committees Invent?》1968
⚠ 反模式:一个大组扛所有 12 人 · 1 个经理 · 3 条产品线 认知过载 · 谁都不 own · 决策堵 经理 1:12 → 无法深度 1:1 ✓ 拆成"流对齐"小队 6+6 · 各 own 一条价值流 端到端负责 · 边界=API 边界 经理 1:6 → 1:1 有质量 该拆分的信号(命中 2 条就该动) · 一个经理直接下属 > 8 人 · 站会一半人在听与己无关的事 · 改一个功能要协调 3+ 人 · 没人能说清"这块谁 own" · 团队认知负荷 > 能承载的域 · 交付前置时间越来越长
情境:你的 12 人组扛着三条产品线,速度越来越慢。老板问"要不要加人"。
✗ 只加人不改结构

"对,我们缺人,再招 4 个。"
—— 沟通路径数按 n² 涨,12 人→16 人协调成本翻倍,速度不升反降(Brooks 定律)。

✓ 先设计边界,再谈人数

"问题不是人手,是边界。三条线耦合太紧,改一处动全身。我提议拆成两个 stream-aligned 小队,各端到端 own 一条价值流,中间用清晰 API 契约解耦。"

"拆完每队 6 人、认知负荷可控,再判断哪队真缺人——很可能只缺 1 个,不是 4 个。组织设计先行,招聘是结果不是起点。"

  • 我想要的架构长什么样?团队边界是否已照它来切?(Conway 逆用)
  • 每个团队能否用一句话说清"我们 own 什么"?说不清=边界糊。
  • 团队认知负荷是否超载?(域太多、依赖太杂 = 该收窄或拆)
  • 拆分后,跨队协作走的是清晰接口,还是"人肉对齐会"?
  • 加人之前,我是否先问过"是结构问题还是人手问题"?
  • 为了政治画组织图。照某人势力切团队,架构就长成畸形,债留给工程师还。
  • 无限扩单个组。1:12 的经理做不了有质量的 1:1,也扛不住深度技术判断。
  • 拆了组不给清晰边界。没有 API 契约的拆分=把耦合从代码挪进会议室。
  • 频繁重组。每次重组都要付 3-6 个月适应税,别当廉价工具。
习作:画出你团队当前的沟通结构图,再画出你系统的架构图,叠在一起看——哪里错位?那就是 Conway 定律在收你的税。
思考题:我上一次组织调整,是为了让架构更健康,还是为了摆平人的问题?如果是后者,代价谁在付?
PRINCIPLE 03

沟通的稀释:你说一次,一线听到的是第七手 Communication Dilution — Say It Until You're Sick of It

过度沟通书面化context
信息每过一层就衰减一次,等传到一线,你的"清晰方向"已面目全非。规模化领导必须接受一个反直觉的事实:你以为说得太多了,员工才刚好听清。对策两条——重复到自己都腻,以及把关键决策写成结构化文字,让它不依赖口口相传。
"We don't do PowerPoint... Instead, we write narratively structured six-page memos. We silently read one at the beginning of each meeting." "我们不用 PowerPoint……而是写结构化叙事的六页备忘录,每次开会先安静读一遍。" — Jeff Bezos, Amazon 2018 致股东信
你(原意):"Q3 聚焦稳定性,功能让路" 经理层:"Q3 优先稳定性,功能也别落太多" 组长:"稳定性重要,但功能进度照排" 工程师听到:"好像都要,那按老样子干" 每过一层,取舍被磨圆一次 —— 到底层,"聚焦"消失了
情境:你在 all-hands 讲了"Q3 聚焦稳定性",两周后发现一个组还在猛加功能。
✗ "我不是讲过了吗"

"我 all-hands 明明说了聚焦稳定性,你们怎么没听?"
—— 讲一次≠传到位。责怪一线,只会让人以后更不敢承认"没听清"。

✓ 冗余 + 书面 + 让对方复述

写下来:一页"Q3 方向备忘",明确列出不做什么(这是取舍的关键,最容易被磨掉)。发到每个渠道。

反向确认:"用你自己的话说,这季度我们为了稳定性放弃了什么?"(让对方复述取舍,而非点头)

重复:同一条方向,在 all-hands、周会、1:1、Slack 至少讲 5 次,措辞可变、内核不变。你腻了,一线刚入耳。

  • 关键决策,我是否落成了文字(不是只在会上口头说)?
  • 我的方向里,"不做什么"是否和"要做什么"一样清晰?
  • 我是否让下级用自己的话复述过一次,以检测走样?
  • 同一条重要信息,我是否在 ≥3 个渠道、≥5 次重复过?
  • 坏消息我是否亲自、尽早、直接传达,而非让它层层过滤变味?
  • "讲过一次"就以为传到了。规模越大,一次触达率越接近于零。
  • 只讲做什么,不讲不做什么。没有取舍的"聚焦"传到底就变成"什么都要"。
  • 怕重复显得啰嗦。你对信息的厌倦度,远高于员工的熟悉度——继续重复。
  • 坏消息让 HR/邮件代传。过滤层会把它变形,团队还记得你"没敢自己说"。
习作:选一条你以为团队都懂的方向,随机问 3 个一线成员"用你的话说这是什么",对比他们的答案和你的原意——差距就是稀释率。
思考题:当信息走样时,我的第一反应是"他们没听",还是"我没传到位"?这个归因方向,决定我会不会一直踩同一个坑。
PRINCIPLE 04

文化的规模化:文化是你不在场时,大家怎么做决定 Scaling Culture — What Happens When You're Not in the Room

文化身教制度化
10 人时,文化=创始人的影子,靠亲身感染就能传。100 人时,你影子照不到的人占多数,文化只能靠制度承载——你奖励了什么、惩罚了什么、招了谁、放走了谁、容忍了什么。价值观墙上的字不算数,你的行为和你的激励系统才是真文化。
"Culture is how a company makes decisions when you're not there. It's the set of assumptions your employees use to resolve the problems they face every day." "文化,就是你不在场时公司如何做决定;是员工用来解决日常问题的那套默认假设。" — Ben Horowitz,《What You Do Is Who You Are》
情境:团队价值观写着"质量第一"。但上季度一个赶工上线、埋了技术债却按时交付的人拿了最高绩效;另一个坚持修债、延期一周的人被打了"进度慢"。
✗ 口号与激励背离

你在 all-hands 继续讲"我们重视质量"。
—— 团队看的是绩效结果,不是你的 slides。真实文化已被写成"嘴上质量第一,实际赶工得赏",下季度所有人都会赶工。

✓ 用行为和激励定义文化

对齐激励:公开表彰那位修债延期的人——"他做了正确但不讨好的取舍,这才是我们说的质量第一。"让被奖励的行为=你宣称的价值观。

设计文化载体:把"质量"制度化进系统——code review 门槛、技术债预算、事故 blameless 复盘。文化不能只靠感召,要能在你不在场时自动运转

  • 我上次晋升/表彰的人,是否真的体现了我宣称的价值观?(激励=真文化)
  • 我们容忍的最差行为是什么?那就是团队真正的行为下限
  • 价值观是否落成可执行的机制(招聘标准、review 规则、仪式),而非只是海报?
  • 新人入职 30 天内,靠什么具体做法习得文化,而非"耳濡目染"?
  • 一个我不在场的决策发生时,我敢不敢预测团队会怎么选?敢=文化已落地。
  • 以为写下价值观=有了文化。文化是你奖惩什么,不是你贴了什么。
  • 容忍高绩效的"混蛋"。留下一个违背价值观的明星,等于告诉所有人价值观可用业绩买断。
  • 指望文化自然扩散。过了 50 人,不设计的文化会长出你没想要的样子。
  • leader 自己破例。你的每次例外,都是对全体的一次文化"再培训"。
习作:列出团队上季度被奖励和被冷落的各 2 人及原因,对照你宣称的价值观——真实文化和口号一致吗?不一致处,就是下季度要修的激励错配。
思考题:我最近一次为了"结果"对违背价值观的行为睁只眼闭只眼,是什么时候?团队从我的沉默里学到了什么规则?

深入思考

"从管人到管系统"会不会走过头,变成只碰流程、不碰人的冷漠管理?
会,这是真实的 trade-off。系统化解决"可重复、可标准化"的问题;但人的动机、信任、职业焦虑无法被流程承载,恰恰需要你亲自在场。健康做法是分层:把可标准化的(review 规则、on-call、决策流程)系统化,腾出的精力加倍投入不可系统化的——高质量 1:1、职业对话、信任修复。系统是为了让你有余力做只有人能做的事。走偏的信号:你开始用"看数据/看流程"回避跟具体的人谈具体的难处。
小团队(<10 人)是不是根本不需要这些,硬套反而官僚?
大部分是的,别过早优化。10 人以内,高频接触足以承载文化与沟通,强行搞六页备忘录、正式组织设计只会拖慢速度。但有两件事值得提前做:一是把关键决策写下来的习惯(成本低,是未来抗稀释的地基);二是激励与价值观对齐(10 人时的错配,扩到 50 人会放大成灾)。其余的组织设计、正式沟通机制,等你感到"话传不到"时再上——那个痛点通常出现在 15–25 人之间。
Conway 定律说架构镜像组织,那到底是先定架构还是先定组织?
用"逆 Conway 操作"(Inverse Conway Maneuver):从目标架构反推组织结构,主动把团队切成你希望系统长成的样子,让定律为你所用而非收你税。但要诚实两点:一是这需要架构意图足够清晰,早期探索阶段架构没定,别急着固化组织;二是重组代价高,这招只适合值得长期押注的架构方向,不适合频繁微调。原则:架构方向清晰且想长期投入时,用组织设计去"锁定"它。
大厂里 tech lead manager 常常无权决定组织结构,这套还有用吗?
有用,但要换成"影响"而非"决定"的玩法。你改不了 org chart,但能改事实上的协作边界:定义清晰的 API 契约、明确谁 own 什么、设跨组接口人——这些"软组织设计"不需要 HR 批。同时,把你观察到的结构性问题(Conway 错配、认知过载、1:12 带不动)用交付前置时间的数据讲给有权改结构的人听,你就从"承受结构"变成"影响结构"。向上讲清"这是结构问题不是努力问题",本身就是高杠杆动作。