1.13 指导、辅导与知识分享

概述与动机

支撑你系统运行的知识，早在写进 wiki 之前就已经存在于人们的脑海中。总有人知道为什么支付重试逻辑写得如此古怪，总有人记得那个绝不能重复运行的迁移脚本，总有人一眼就能嗅出糟糕的数据库索引。当这个人离职、休假，或者仅仅是忙得无法答疑时，这些知识就随他们一起消失了。指导、辅导与知识分享，是有意识地把这些知识从个人头脑中转移出来、汇入团队共享血脉的工作，让组织随时间变得更聪明，而不是不断遗忘自己学到的东西。

本章讨论的是培养人才、传播专长的实践：资深工程师如何培养初级工程师，某种技艺周围的社区如何形成，教学如何融入日常工作而不是事后附加。它与几个相邻章节紧密相关。第 1.3 章定义了这些实践所帮助攀登的职业阶梯，第 1.8 章涵盖了为你带来新同事的招聘与入职，第 1.10 章衡量健康的知识流动所保护的效能，第 1.11 章则涵盖了资助与奖励这项工作的管理技艺。在技术层面，第 2.5 章的代码评审与第 2.7 章的文档，是你手中最强大的两种教学载体。

对于大型团队而言，知识分享不再是锦上添花，而是结构性的风险管理。巴士系数为一，意味着一个系统只有一个人理解，这是一场等待辞职信触发的潜在故障。企业会在数百个服务和长期存在的平台上感受到这一点。政府组织感受得最为深刻，因为它们要运行数十年之久的系统，由轮换的公务员和承包商维护，并且有义务确保面向公民的服务在其建造者离开很久之后依然可理解、可维护。在这些场景下，教会你的同事不是慷慨之举，而是制度记忆与连续性的机制本身。

关键原则

区分指导（mentoring）、辅导（coaching）与举荐（sponsorship）；一个人三者都需要，且它们不是同一种行为。
把知识分享当作真正的工作，为其预算真正的时间，而不是下班后才做的事。
主动应对巴士系数风险：任何关键系统都不应只有一个人理解。
让教学成为职业阶梯中可见、受奖励的期望，而不是压在慷慨者身上的隐形税负。
优先选择那些能在完成工作的同时顺带传递知识的实践，例如结对与评审。
培养资深与 staff-plus 级工程师成为放大器，他们的影响力来自提升他人，而非仅凭个人产出。
让知识分享的设计支持异步与书面进行，使其能够跨越距离与时区留存下来。

建议

区分指导、辅导与举荐

这三个词常被混用，而这种混淆会耽误人的职业生涯。指导（Mentoring）是分享经验与建议：经验更丰富的人帮助经验较少的人应对技术与职业问题，提供后者尚未获得的视角。辅导（Coaching）则不同。教练不会直接给你答案；教练通过提问帮助你找到自己的答案，从而培养你解决下一个问题的能力，而不必依赖教练。指导说的是”在那种情况下我是这么做的”。辅导问的是”你看到了哪些选项，如果你分别尝试会发生什么？”

举荐（Sponsorship）是人们最容易忽视的一种，但它对晋升最为关键。举荐人会在你不在场时，为你花费自己的信誉：把你推荐给有挑战性的项目，在晋升时为你举荐姓名，在校准会议上为你的工作辩护。指导与辅导培养一个人；举荐则推动这个人前进。关于职业发展的研究反复发现，比起建议，举荐才是把人推向资深职位的关键，而最需要举荐人的那些人（来自代表性不足群体的人，见第 1.12 章讨论）恰恰是默认情况下最不容易获得举荐的人。在你的团队里，明确说出这三种行为的名字，并确保你的资深员工三者都在做，而不只是停留在前两种较为轻松的行为上。

建立结构化的入职伙伴制度

第 1.8 章让新工程师走进大门；而最初的几周决定了他们能否茁壮成长。为每一位新人指派一位入职伙伴：一位同级同事，而非其经理，其明确职责是回答”傻问题”，解释未成文的团队规范，并成为一个安全的第一联系点。让这成为一个真实的、有名有姓的角色，并为其划出时间，而不是一个抱有希望的事后想法。入职伙伴会向新人展示哪里”埋着地雷”：哪个服务很脆弱，该在哪个频道提问，部署实际是怎么做的，而不是文档上写的那样。

一个良好的伙伴制度会带来双重回报。新人更快达到生产力，也更早产生归属感，而归属感是预测他们是否会留下来的最大单一因素。入职伙伴通常是中级工程师，这也是他们第一次以较低风险的方式体验培养他人，是他们自身成长为资深工程师道路上的一级台阶。轮换这个角色，避免让少数几位慷慨的人始终承担；并给伙伴一份轻量级清单，这样新人的体验就不会完全取决于他们抽到了谁。

培育实践社区与行会

实践社区（community of practice）是一群共享同一门技艺并聚在一起共同发展它的人：跨越各团队的前端工程师、关心数据库的人、无障碍倡导者。有些组织称之为行会（guild）或分会（chapter）。它们跨越了第 1.2 章所讨论的团队边界，使知识能够横向流动，即便组织架构图只把人纵向连接起来。行会制定共同标准，一起评审棘手的问题，整理出最佳实践模式，并为专家们提供一个超越其所在小队的专业归属地。

其失败模式是实践社区沦为一个没人想参加的例行会议。要让它们保持活力，就给它们真正的工作和真正的权力：让测试行会拥有测试标准的制定权，让前端行会选择组件库。轮换主持人，使该群体不依赖于某一位倡导者。保留书面章程与可检索的决策记录，让行会产出持久的成果，而不只是会议一结束就蒸发的对话。

举办内部技术分享会、便当会与闪电演讲

定期举办的内部演讲系列，是你能进行的性价比最高、回报最大的知识投资之一。便当会（brown bag）是一场非正式的午餐时间演讲，由某人讲解自己所学到的东西。闪电演讲（lightning talk）是严格限时五分钟的演讲，把门槛降得足够低，以至于第一次演讲的人也会主动报名。这些形式既能传播具体知识（新的缓存层如何运作），也能传递更微妙的东西：它们把教学正常化，让隐藏的专家浮出水面，并为人们提供一个低风险的舞台，去锻炼晋升所依赖的演讲能力。

让这个系列可持续，而不是靠英雄式的坚持。录制演讲，让分布各地及未来的同事都能观看，维护一个带索引的录像与幻灯片库，并轮换组织职责，以免某位热心人耗尽热情后系列就此终结。偶尔邀请外部演讲者带来新鲜观点。大声庆祝第一次演讲的人，因为”这里人人都会教学”这一文化信号，比任何一场演讲的内容本身都更有价值。

把文档当作教学，并守护知识的连续性

文档不是归档任务；它是能超越当下、超越作者本人而持续发挥作用的教学。操作手册、架构概览、“我们为什么这样构建”的说明，正是你教会一个你永远不会见面的人（包括三年后你自己团队的那个版本）的方式。第 2.7 章讲述如何把文档写好；这里要强调的是动机层面的意义。每一篇持久留存的文字，都会降低你的巴士系数，因为写进一篇好文档中的知识，不会因为任何一次离职而被带走。

有意识地应对巴士系数风险。找出只有一个人理解的系统，把每一个都当作需要消除的风险：让那个人写出概览，让另一个人结对走一遍代码，并轮换处理下一次变更的人。有些团队会进行一场刻意的”度假测试”，让某个系统的专家真正不可联系，逼团队在没有他们的情况下运作，从而准确暴露出哪些知识被危险地集中在了一个人身上。目标是让任何关键系统都不再依赖某一个可能辞职、生病，或者只是忘记的人的记忆。

用结对与聚众编程作为知识转移手段

结对编程（Pair programming），即两位工程师在一台键盘前共同解决一个问题，是两个人之间转移知识最快的方式之一，因为这种转移是实时且有上下文的。聚众编程（mob programming，也称 ensemble programming）把这一做法扩展到一整个小团队共同处理一件事。两者都不仅仅关乎产出的代码。它们悄悄带来的收益是，专长、约定与判断力会作为完成工作的自然副产品，从一个人传播到另一个人，而无需任何人专门安排一次培训会议。

有意识地为其教学价值而使用这些方法，而不是把它变成任何时候所有工作都必须遵循的强制规定。让新人在第一次做真正的变更时与老手结对。在棘手的、高巴士系数的子系统上进行聚众编程，专门确保有不止一个人在理解它之后离场。跨团队结对，以播下一种新实践的种子。结对与聚众编程也会改善第 2.5 章所讲的代码评审，因为大部分评审实际上已经实时完成了；它们还会提升第 1.1 章所讲的心理安全感，因为在同事面前把想法说出来、犯错，都变得正常。

培养 staff-plus 级工程师成为放大器

在资深工程师之上，第 1.3 章的阶梯继续延伸到 staff、principal 和 distinguished 等职位，统称为 staff-plus 层级。一位出色的 staff-plus 工程师的典型特征是杠杆效应：他们的影响力较少来自自己亲手写的代码，更多来自他们能在多大程度上提升周围每个人的效能。他们设定技术方向，为其他团队清除障碍，指导下一代资深工程师，把一个好点子变成整个组织都会采纳的实践。放大器（force multiplier）指的是那种存在本身就能让团队总产出大于个体产出之和的人。

有意识地培养这些人，因为他们不会凭空出现。给你最优秀的工程师安排需要靠影响力而非孤身奋战就能完成的职责范围：负责一项跨团队计划，带领一个行会，同时指导好几位资深工程师。在绩效评审中明确奖励这种放大器行为，否则你会无意中教会你最优秀的人：只有个人产出才算数，于是他们会囤积问题，而不是培养他人。一位只以个人提交量来衡量的 staff 工程师，是一个被你亲手解除了武装的放大器。

把它写进阶梯、时间预算与指标中

只靠善意维系的知识分享，会被下一个截止日期碾碎。把它变成结构性的东西。把指导、教学与知识分享写进职业阶梯，作为随级别提升而增长的明确期望，让达到资深级别真正要求培养他人，也让做这项工作的人能在晋升时拿出实证。为它预算真正的时间：每周固定留出一部分时间用于行会、演讲、文档与指导，像保护 on-call 值班一样保护它。如果教学永远只能在偷来的时间里完成，那么只有有空闲时间的人才会去做，这既不公平，也不可持续。

谨慎地衡量这种流动的健康状况。跟踪一些先导指标，例如每个关键系统的巴士系数、文档覆盖率与新鲜度、从入职到首次有意义贡献所需的时间，以及演讲与行会的参与广度。第 1.10 章警告不要把人简化为一个可被操纵的单一数字，这个警告在这里同样完全适用：这些信号是一个对话的起点，用来讨论知识危险集中在哪里，而不是一张排行榜。它们应该引发的问题是”如果哪个系统的唯一专家离开，我们受的伤害会最大”，然后你打算怎么办。

为远程与分布式知识分享而设计

当你的团队像第 1.9 章所假设的那样越来越多地跨越时区时，曾经承载知识传递的走廊对话就此消失。你必须有意识地替代它。默认采用书面与异步的形式，因为录制的演讲、可检索的决策记录、维护良好的 wiki，能触达在你醒着时正在睡觉的同事，而同步的白板会议却会把他们排除在外。书面知识是包容性的知识；它不会偏袒那些恰好与你工作时间或办公地点相同的人。

投资于可发现性，因为没人能找到的知识，就等于你没有这份知识。一个强大的、能搜索你的文档、录像与决策的搜索功能，比再开一次会议更有价值。录制并索引每一场演讲。把远程屏幕共享结对当作常态。为实践社区创建明确的虚拟空间，让分散各地的专家能够互相找到彼此。那些把分布式知识分享做得好的组织，都是那些不再把办公室当作真正知识来源、转而把书面记录当作事实来源（source of truth）的组织。

权衡取舍：利与弊

投资于指导和知识分享会占用本可用于功能开发的时间，这种张力是真实存在的。下表诚实地列出了主要的选择。

实践	优点	缺点
结对与聚众编程	快速、有上下文的知识转移；缺陷更少	两人或更多人处理一项任务；短期内感觉更慢
实践社区 / 行会	横向知识流动；共享标准	可能退化为例行会议；需要真正的权力才能存续
内部演讲与便当会	成本低，让专家浮出水面，培养演讲者	组织工作会耗尽倡导者；出席率可能下滑
文档即教学	超越作者本人持续发挥作用；降低巴士系数	缺乏所有权就会过时；写作需要真正的时间
结构化入职伙伴制度	更快上手，更强归属感，伙伴自身也会成长	拖慢伙伴自己的工作；质量因人而异
明确的阶梯与时间预算	让教学变得公平且受奖励	增加流程；如果粗糙地度量，可能沦为勾选清单

核心的权衡是短期吞吐量与长期韧性和能力之间的取舍。让两位工程师结对处理一项任务，今天看起来产出减半，但它换来的是第二个理解该系统的人、更少的缺陷，以及更快的未来工作速度。为知识分享预算每周一天，看起来是速度上的损失，但它换来的是一个不会遗忘、不会因某人离开而停滞、并培养而非耗尽自己人才的组织。解决这一张力的方法是有意识地取舍：把投资花在巴士系数最高、且有人准备好成长的地方，而不是在所有地方强制推行每一种实践。成本永远是可见且即时的；回报是真实的，但会延后到来，这正是它需要明确保护的原因。

与团队讨论的问题

如果我们哪个关键系统的唯一专家明天辞职，我们受的伤害会最大，我们正在为此做什么？ 大多数团队从未诚实地绘制过这张图，这意味着答案往往是在一次真实的辞职中才被发现，而那正是最糟糕的时刻。拿出你的重要服务清单，逐一列出每一个能自信地对其做出重大变更的人。当这份名单只有一个名字，或者一个都没有，你就发现了一个具体的、可以处理的风险，而不是一种模糊的担忧。接下来的行动是明确的：让那位专家写出概览，让第二个人结对完成下一次变更，并轮换所有权，让理解得以扩散。一个能够说出自己有哪些单一专家系统、并展示出为每一个系统降低风险的计划的团队，已经把巴士系数从一种焦虑变成了一个受管理的组合。
指导、教学与知识分享在这里是真正受奖励的，还是只是被口头称赞？ 一个声称重视培养他人的组织，和一个真正为此晋升员工的组织之间，存在巨大的落差，而你最优秀的工程师能精准地读出这种落差。拿出你上一轮晋升和绩效评审记录，问一问有多少认可流向了放大器行为，又有多少流向了个人产出。如果诚实的答案是，那位默默指导了三位初级工程师、并写下人人依赖的文档的人，晋升速度比独自交付了一个亮眼功能的人更慢，那你就是在训练你的人停止教学。你想要的证据是：教学作为一项真正的期望被写进阶梯，为它预算了时间，并且至少有一次最近的晋升，其主要理由就是培养了他人。
知识在这个团队里实际上是如何流动的，它能触达远程、新入职或性格安静的人吗？ 每个团队都有真实的知识传递路径，而这些路径往往是隐形且带有排斥性的：在走廊里做出的决定、只存在于某位资深员工私信里的上下文、只有和对的人一起吃午饭才能学到的规范。拿出一件新人最近需要学习的重要事情，追溯他们究竟是怎么学到的，然后问一问，一位远程同事或一位性格内向的人是否会以同样的方式学到它。如果你的知识主要通过同步的、面对面的、非正式的渠道流动，那你正在系统性地不利于第 1.9 章和第 1.12 章告诉你应当纳入的那些人。目标是转向书面的、可检索的、异步的知识流动，无论地点、任期或提问声音大小，都能触达每一个人。
这个团队里谁获得的是举荐（sponsorship）而不只是指导（mentoring），这种模式是否悄悄地与谁长得像现有领导层相吻合？ 举荐（）在某人不在场时为其花费自己的信誉（）是真正把人推向资深职位的行为，而它最常被默认给予那些与现有资深人员相似的人。对于一个大型团队来说，这会累积成一条逐年收窄的领导力管道，而每个人却都坚称这个流程是公平的。拿出过去两轮的挑战性项目分配、晋升提名和校准辩护记录，指出是谁为谁发声；这种模式通常一看就能发现。与之相竞争的考量是，举荐人挑选的是他们亲眼见过做出出色工作的人，这在感觉上是任人唯贤，但结构上却偏袒那些最先获得可见工作机会的人。在企业与政府环境中，晋升决定必须经得起公平性审查，对公共机构而言还必须经得起公众问责，因此一种始终流向同一类人的、未被记录的举荐模式，既是一种公平性失败，也是一种审计风险。你想要的结果是，有意识地举荐那些资深员工凭本能不会选中的有能力的人，并且追踪得足够充分，能够证明这条通道正在变宽。
当下一个紧迫的截止日期到来时，我们第一个砍掉的会是什么，会不会正是我们发誓要保护的知识分享时间？ 教学、文档、行会与结对都要占用今天就能看见的时间，而回报却要等到以后才会出现，这使它们成为任何一次赶工中最容易被下意识牺牲的对象。对一个大型组织而言，如果每个团队在压力下都悄悄削减知识分享，其总体效果就是一个机构恰恰在压力最大的时候停止了学习。拿出过去两次交付赶工，诚实地追溯指导时间、演讲系列和文档在其中的遭遇。与之相竞争的考量是真实存在的：有时候截止日期确实必须优先，假装不是这样只会消耗信誉。你在检验的是：这段时间是否像 on-call 值班一样被保护（默认受到保护，只能通过明确的、可问责的决定被牺牲），还是仅仅在幻灯片里被保护。在系统要运行多年的企业与政府场景中，为了赶上一个季度末的日期而牺牲知识连续性，是在用一项持久的负债换取一次短期的胜利，而应该有人为这笔交易签字负责，而不是任其在无人负责的情况下悄然发生。
我们的实践社区真的拥有些什么，还是只是我们为了让自己感觉重视技艺而召开的会议？ 一个拥有真正权力的行会（拥有测试标准的制定权、选择组件库、整理经批准的模式）会把知识横向传播到组织架构图从未连接过的各个团队；一个没有任何权力的行会会退化成一个人们会拒绝的日历事件。对于一个大型团队而言，这是让一个只被发现一次的解决方案触达每个人、而不是被反复糟糕地重新发明十几次的主要机制，因此它的健康状况是一个直接的效率问题。拿出每个社区的章程、最近三项决策，以及出席趋势，问一问如果它明天停止开会，真的会有什么东西受损；如果诚实的答案是什么都不会，那你就有了一个僵尸社区。与之相竞争的考量是，真正的权力意味着真正的问责，以及更慢、更有争议的决策，一些领导者会抵触把这种权力让渡给一个跨部门的群体。在拥有众多团队、供应商和长期存在的平台的企业与政府场景中，一个有章程、有可检索决策记录的社区，也是你在跨组织和跨合同边界保持标准一致且可审计的方式，这是临时拼凑的协调做不到的。

行业视角

初创企业。 只有寥寥几名工程师、跑道又短的情况下，风险不在于流程，而在于维持系统运转的那套东西上巴士系数为一。跳过行会和正式的阶梯；取而代之的是，让创始工程师们每当触碰关键子系统时就结对工作，并在午餐时间举行五分钟的闪电演讲，让教学成为一种廉价的习惯，而不是一套项目。你唯一持久的投资，是为任何只有一个人理解的东西，在那个人休假之前而不是之后，写一份简短的操作手册和架构说明。

小型企业。 没有专门的学习与发展职能、预算又紧张的情况下，把知识分享当作可以购买或借用的轻量级结构，而不是自己搭建的东西。依靠一份简单的入职伙伴清单、一个共享 wiki 和录制的走查演示，而不是一套配有专人的指导项目，并优先使用你已经拥有的工具，而不是引入新平台。这里的自建还是购买（build-versus-buy）决策通常是购买一个可检索的文档工具，把稀缺的时间花在保持它的更新上，因为一个陈旧的 wiki 比没有 wiki 更糟。

企业。 在众多团队和长期存在的平台之间，问题在于横向知识流动与治理：拥有对标准真正权力的实践社区、写进职业阶梯的指导与放大器影响力、像 on-call 值班一样受保护的时间预算，以及按关键系统跟踪的巴士系数，作为一个受管理的风险组合。把入职伙伴制度、带索引的演讲库、文档即交付物标准化，让一个团队找到的解决方案能够触达所有团队，并像审计其他运营风险一样审计知识健康状况。

政府。 系统在轮换的公务员和承包商手中运行数十年，因此知识连续性是一项法律与问责义务，而不是锦上添花。采购应当把文档、决策记录和操作手册当作与代码同等重要的合同交付物，交接过程应当让即将离开的员工与新加入的员工结对，让理解在权限被撤销之前完成转移。实践社区让标准在各部门和供应商之间保持一致，而可检索的书面记录，正是让面向公民的服务在其最初建造者离开很久之后依然可理解、可维护的关键。

案例

初创企业。 一家十二人的初创公司发现只有一名工程师理解计费系统，而她即将休一个月的育儿假。他们把这当作一次消防演习来对待：她花两天时间写出一份架构概览和一份操作手册，然后带着一位同事结对完成接下来三次计费系统的变更。他们开始了一个每周的闪电演讲午餐会，任何人都可以用五分钟讲讲自己学到的东西，这很快就发现一位平时安静的初级工程师对他们的可观测性技术栈有着深刻的理解。在一个季度内，没有任何关键系统的巴士系数还是一，互相教学的习惯也成了团队工作方式的一部分，而不是任何人需要强制执行的政策。

企业。 一家拥有数千名工程师的全球性银行，为每个主要学科都运营着正式的实践社区：后端、前端、数据、安全。每个行会都拥有自己标准的制定权，整理经批准的模式，并维护一个可检索的知识库，因此一个团队找到的解决方案能够传播到所有团队，而不是被反复糟糕地重新发明。Staff 和 principal 级工程师会明确根据他们的放大器影响力接受评估，指导是职业阶梯中资深级别的一项明确期望，每一位工程师都有受保护的知识分享时间。内部技术分享会都被录制并索引，让身处任何时区的工程师都能向另一个时区的专家学习。结果是专长在一个庞大的组织中横向流动，没有任何一个团队的离职能困住一项关键能力。

政府。 一家国家税务机构维护着必须运行数十年的系统，由多年来轮换的公务员和承包商负责维护。知识连续性是一项法律与运营上的必要之事，因此该机构强制要求将详尽的文档、决策记录和操作手册作为与代码同等重要的交付物，并在交接期间让新入职员工与即将离开的员工结对，使理解在人员离开之前完成转移。实践社区让标准在各部门和供应商之间保持一致，结构化的指导帮助职业公务员成长为掌握着制度记忆的资深技术角色。当一份合同结束或一位官员退休时，系统依然可理解、可维护，因为该机构从一开始建造系统时，就把教会下一任守护者当作其中的一部分。

商业案例：动机、投资回报率与总拥有成本

知识分享的回报体现为风险的降低、上手速度的加快，以及人才与专长的留存。最清晰的一条线是巴士系数风险：一个单一专家系统是一项未被定价的负债，而这个人离开的代价（一场没人能修复的故障、一次没人理解的代码重写、数月的重新摸索）远远超过提前分散知识的适度成本。更快的入职速度同样是可以直接衡量的。你为新员工缩短的每一周达到生产力所需时间，都是一周本该带来困惑、如今却创造价值的薪酬，并且会在你招聘的每一个人身上成倍累积。

留存是数字变得可观的地方。替换一名工程师的成本，在招聘、入职和生产力损失上，相当于其年薪的相当一部分，而人们离开的往往是那些让自己停止成长的组织。指导、辅导与举荐是你手中最强的留存杠杆之一，因为它们让人感受到被投资，并为他们提供一条清晰可见的前进道路。采纳它们的成本主要是受保护的时间加上轻量级的结构：预算好的时间、一个演讲系列、行会章程、一份伙伴清单。忽视它的代价会随着知识集中、文档腐朽，以及你最具潜力的导师们跳槽去那些愿意培养他们的组织，而悄悄累积。要向领导层证明这一点，把知识分享与他们已经在关注的指标联系起来：入职时间、留存率、专家不在场时的事件恢复能力，以及第 1.10 章讲的效能度量。

反模式与陷阱

英雄文化： 奖励那个力挽狂澜的孤胆专家，这会悄悄激励人囤积知识而不是传播知识。
指导变成无偿加班： 期望教学发生在偷来的时间里，结果只有有空闲时间的人才会去做，慷慨的人则会精疲力竭。
举荐缺口： 自由地给出建议，却只把真正的信誉花在那些看起来像现有领导层的人身上。
僵尸行会： 实践社区沦为没有权力、没有产出、出席率不断下滑的例行会议。
文档剧场： 只为打勾而写一次文档，然后任其腐朽，直到它带来的误导多于帮助。
巴士系数为一，却被忽视： 明知一个系统只有一个专家，却什么都不做，直到那个人真的离开。
用可操纵的数字衡量教学： 把指导变成一场指标竞赛，产生活动却没有真正的知识转移。
以办公室为中心的知识： 让重要的上下文只存在于走廊和私信中，把远程、新入职和性格安静的同事排除在外。
放大器工作得不到奖励： 只根据个人产出晋升，教会你最优秀的人：培养他人是一种职业错误。

成熟度模型

第一级，启动（Initiate）： 知识分享是偶然且个人化的。关键系统常常巴士系数为一，入职全凭自己摸索，指导完全取决于个人的善意，一旦有人离开，专长就随之离开大楼。
第二级，发展（Develop）： 一些实践已经存在，但在各团队之间并不一致。一个小队有入职伙伴制度，另一个偶尔办个技术分享会，文档质量参差不齐，指导只惠及主动寻求的人，但没有任何东西被预算、被期望或被衡量，一切都靠少数倡导者的努力维系。
第三级，标准化（Standardize）： 知识分享在全组织范围内被文档化并强制执行。指导与教学是有受保护时间支撑的明确阶梯期望，实践社区拥有标准的制定权，入职伙伴制度和演讲系列在各处都是常态，而不只是零星存在，文档是一项被维护的交付物，每个团队都遵循相同的期望，而不是各自发明一套。
第四级，管理（Manage）： 知识健康状况被度量，并依据基线数据加以控制。每个关键系统的巴士系数、文档覆盖率与新鲜度、从入职到首次有意义贡献所需的时间，以及演讲与行会的参与广度，都被持续跟踪；单一专家系统被当作一个受管理的风险组合，配有降低风险的计划和截止日期；举荐与放大器影响力会被审查其公平性，而不是被想当然地认为公平；知识分享时间通过明确的、可问责的决定得到保护，而不是被悄悄砍掉。指标开启的是关于知识危险集中在哪里的对话，而不是排行榜。
第五级，协同（Orchestrate）： 教学被持续改进，并整合到整个组织之中，并随条件变化而调整。结对、聚众编程、举荐与放大器式成长都是常态并受到奖励；知识以书面形式在各团队、供应商和时区之间自由流动；第四级的度量指标为一个常规的改进循环提供输入，该循环重塑实践、重新平衡教学精力的投向，并淘汰不再奏效的做法；没有任何关键系统依赖于某一个人的记忆。

讨论思路

你的团队中有哪一个系统巴士系数为一，本月能采取的、把它变成二的最小具体步骤是什么？
你的职业阶梯是否真的要求培养他人才能达到资深级别，还是只是顺带提了一句？
团队中谁正在做着上一轮评审未能识别或奖励的隐形放大器工作？
一位远程或新加入的同事最近一次错过了某些在场资深同事靠耳濡目染吸收到的知识，是什么时候？
你的资深工程师是在举荐他人（为他们花费真正的信誉），还是只停留在给建议？
如果你最好的导师明天离开，教学这项实践还能延续下去吗，还是它完全只存在于那一个人身上？

关键要点

指导、辅导与举荐是三种不同的行为；一个人三者都需要，而举荐是最需要它的人最常被剥夺的那一种。
主动应对巴士系数风险：找出你的单一专家系统，并通过文档、结对和轮换为每一个系统降低风险。
优先选择那些能在完成工作的同时顺带转移知识的实践，例如结对、聚众编程、代码评审和文档即教学。
让教学结构化：把它写进职业阶梯，为它预算真正的时间，奖励放大器行为，并在不被操纵的前提下衡量知识健康状况。
让知识分享的设计做到书面化、异步化、可发现，使其能够经受住距离、时区，以及任何一个人离开的考验。

参考文献与延伸阅读

Etienne Wenger, Communities of Practice: Learning, Meaning, and Identity
Will Larson, Staff Engineer: Leadership Beyond the Management Track
Tanya Reilly, The Staff Engineer’s Path: A Guide for Individual Contributors Navigating Growth and Change
Camille Fournier, The Manager’s Path: A Guide for Tech Leaders Navigating Growth and Change
Sylvia Ann Hewlett, Forget a Mentor, Find a Sponsor: The New Way to Fast-Track Your Career
Andrew Hunt and David Thomas, The Pragmatic Programmer: Your Journey to Mastery
Kenneth S. Rubin, Essential Scrum: A Practical Guide to the Most Popular Agile Process
Woody Zuill and Kevin Meadows, Mob Programming: A Whole Team Approach