第 2 章 三张地图

作为 Staff 工程师，你需要开阔的视野。每当你应对一次故障、主持一场会议，或者给被指导者提建议时，你都需要了解与你共事的人，以及事情的利害得失。当你提出一项战略或推动一个项目时，你会希望理解你的组织是如何运转的，以及一路上可能遇到哪些困难。而且，除非你能跳出日常琐事，看清大家应该去往何方，否则你无法就该做什么工作做出好的选择。

在第 1 章中，我们拉远视角，从全局审视了 Staff 工程师是什么、组织为什么需要他们。我们定义了一些有助于理解 Staff 角色的公理，然后我邀请你开展一次调查，拆解你自身角色的几个方面：你的汇报链、你的范围、你的工作偏好，以及你当前的主要关注点。如果你此前对自己的工作还没有一个全局认识，希望现在你已经有了。但如果你徒步旅行过，或者在一座陌生的城市里找过路，你就会明白，知道你自己站在哪里只是开始。找准方向还意味着要了解你的周遭环境。

呃，有人带地图了吗？

在本章中，我们将通过绘制几张地图来描绘你的工作和组织的全局。地图会因用途不同而呈现不同的形式：比如，你不会试图在同一张地图上同时标注海拔、选区和地铁线路。所以，与其把我们掌握的所有信息叠加成一张密密麻麻、无法阅读的图，我们将着手绘制三张不同的地图。它们不会是完美的模型，但它们是有用的工具，可以帮助你思考工作，并就以下问题问问自己：你身在何处，你的组织如何运转，以及你们所有人究竟想做成什么。

你可以把这当作一次思维练习——只是一个用来思考工程组织的比喻——也可以真的动手画出这些地图。和同事对照笔记，看看你们在哪些地形和兴趣点上看法不一，这可能会很有启发（也很有趣）。

下面是我们最终会得到的三张地图：

定位地图：你在这里

我们先从你在更大的组织和公司中的位置开始。上一章我们讨论了你的范围，但要真正理解这个范围，你需要看到它之外有什么。边界上有什么？当你把视角拉得很远时，你所在的这块世界和其他地方相比有多大？可以把它想象成新闻台在主持人身后投出的那种地图，提醒你某个地方在哪里，并把它放到上下文中。

你之所以需要定位地图，是因为当你深陷某项工作之中时，很难客观地看待它。除非你能保持一定的视角，否则你所在小组的关切和决策会显得比放在更大尺度上看时更重要。所以我们会尝试一些获得这种视角的技巧。你要对自己诚实：在你关心的项目中，哪些会真正出现在公司的大地图上，哪些则要一直放大到底才能看到。

地形图：了解地形

第二张地图讲的是如何在地形中穿行。如果你要横穿一片土地，对前方的情况了解得越透彻，你就能走得越远、越快。在这一节，我们会看看地图上的一些危险：沿着组织断层线分布的峡谷和山脊，出现在谁也想不到的地方的古怪政治边界，以及大家都在想方设法避开的难缠人物。如果前方有流沙，有需要提防的海怪，或者有一片布满前人被晒得发白的骸骨、无法穿越的沙漠，你会希望在出发之前就把它们清清楚楚地标出来。

尽管有种种危险和困难，你可能会发现已经存在一些可通行的道路。发现这些道路包括：理解你的组织的“性格”以及领导者喜欢的工作方式，弄清楚决策是如何做出的，并找出正式的和“影子”的组织架构图。

藏宝图：X 标记宝藏所在

第三张地图有一个目的地，以及通往那里的路线上的若干站点。它展示了你要去哪里，并列出了旅途中的一些停靠点。航程也许危机四伏，但只要有地图，你就能看出自己是否在一步步接近那个巨大的红色 X。

揭开这张地图意味着要从长远着眼，评估你的工作的目的。每个项目本身就是一个目标吗，还是只是通往真正目标路上的一个里程碑？有时你会发现根本没有目的地，或者有好几个互不相容的目的地。当没有人宣布宝藏是什么，或者大家对如何到达那里意见不一时，Staff 工程师可以通过制定愿景或战略、做出决策，或者以其他方式为组织绘制一张全新的藏宝图，来产生巨大的影响。不过我说得有点超前了。现在我们关注的是揭示已有的全局。创造一个新的全局会在第 3 章讨论。

驱散战争迷雾

这三张地图其实早已存在于你的组织中，只是被遮蔽了。当你加入一家新公司时，全局的大部分对你来说完全是未知的。开始一份新工作，很大一部分就是建立上下文、了解新组织如何运转，以及弄清楚每个人的目标。可以把它想象成电子游戏里的战争迷雾：在你尚未探索的地图区域，你看不到有什么在等着你。当你四处侦察时，你会驱散迷雾，更清楚地看到地形，了解周围有什么，以及是否有狼要来骚扰你的村民。你可以着手揭开这三张地图中被遮蔽的部分，并想办法让这些信息易于他人理解。例如：

• 定位地图可以帮助你确保与你合作的团队真正理解他们在组织中的目的、他们的客户是谁，以及他们的工作如何影响他人。

• 地形图可以帮助你凸显团队之间的摩擦和缝隙，并打通沟通的渠道。

• 藏宝图可以帮助你确保每个人都清楚地知道自己要实现什么，以及为什么。

地图的某些部分可以通过日常学习来驱散迷雾，但另一些部分则需要你有意识地去探索。本章的一个核心主题是“知道事情”有多重要：持续掌握上下文，对正在发生的事情心中有数。知道事情既需要技能，也需要机会，你可能要努力一段时间，才能开始看到你原本没有看到的东西。

我们先从技能说起。疫情期间，我在爱尔兰乡下待了几个月，经常和住在那里的朋友们一起去大自然中散步。起初，我以为该看的我都看到了：一丛毛地黄或一棵橡树，这些醒目而美丽的东西。但我的朋友们看到的比我多。他们会在一摊我根本不会多看一眼的泥地前停下来，指出松貂的脚印。他们会挑出我只当是普通杂草的叶子，告诉我它们美味又带着胡椒味，是采集者的宝贝。就连孩子们也能看到小花，或者扑向一片我会径直走过的野草莓。为什么他们能看到这一切，而我却看不到？因为他们学会了留心，而且他们知道自己在找什么。

留心意味着对影响你的项目或组织的事实保持警觉。而这意味着要持续地从周围的噪声中筛选出信息。如果你能训练自己的大脑说出“这很有意思！”，并记住以后可能用得上的事实，你就会开始为你的地图添加细节，并培养综合新信息的能力。

哪些事实是有用的？任何能帮助你或他人理解工作的上下文、在组织中找到方向，或朝目标推进的东西都是。下面是一些例子：

• 一场关于即将到来的营销攻势的公司全员大会演讲，可能暗示着一波你还没准备好的巨大流量高峰正朝你袭来。

• 你的总监让你接手一个你没时间做的项目，但你知道组织里哪些高级工程师已经准备好迎接锻炼能力的机会。

• 公司优先级的转变可能意味着，一个你曾经考虑过但被搁置的平台，已经变成了一项绝佳的投资。

• 你的数据库刚刚消失了，而你记得收到过一封关于网络维护的邮件。

随着时间推移，你会习惯组织里消息的传播方式，以及你应该关注什么。你会知道哪些邮件需要读、哪些会议需要参加。如果你的大脑天生不善于记住这类信息，我建议你给自己定个挑战：把以后可能有用的事实记下来，只是为了养成留心的习惯。把收集上下文看作工作中需要培养的一项技能。

但仅仅留意只能带你走这么远。如果你接触不到影响你工作的决策和讨论，留心也无济于事。虽然你也许每天都能接触到源源不断的会议、邮件，以及 Slack 上那些令人懊恼的 @here 消息，但还有大量其他信息，除非你知道它们存在，否则你根本无从索取。你如何才能进入“事情发生的房间”？我会在本章分享一些策略。

定位地图：获得视角

随着你资历的增长，要产生真正的影响，就意味着要能把你的工作放到更大的上下文中，并认识到你的观点深受你所处位置的影响。（图 2-1 给出的视角也许有点太大了。）

图 2-1. 银河系的定位地图（银河系原图由 Jean Beaufort 提供，CC0）。

当然，与你共事的其他每个人也都有他们自己的观点：他们的“你在这里”标记位于地图上的其他地方。如果你想做出好的决策，你就需要能够从其中一些其他视角来看问题。

你在任何一个领域里沉浸得越久，对你范围内工作的细微之处了解得越多，它在你眼中就会变得越丰富、越复杂。随着你对人、问题和目标的理解加深，你会越来越专注于它们。这种专注带来了深度和理解，但也伴随着一些风险，对 Staff 工程师来说尤其如此。

下面我们来看其中的四个风险。

优先级排错

当你周围的每个人都关心同一组事情时，很容易放大这些事情的重要性。相比之下，你们小组之外存在的问题可能开始显得简单或不重要。这就是为什么你会看到团队做出我在第 1 章谈到的那种局部最优决策：局部最优开始让人觉得真的很重要。你盯着自己小组的问题越久，它们就越显得特殊、独一无二，值得用特殊、独一无二的方案来解决。有时候它们确实如此！但真正全新的问题并不常见。如果你先查一查已有的做法和现成的解决方案，你就能少花时间重新发明轮子。

失去同理心

人很容易过度专注，忘记世界其他部分的存在，或者开始认为其他技术领域和你那丰富、微妙的领域相比不值一提。这就像你开始透过鱼眼镜头看世界：眼前的东西被放得巨大，其他一切都被挤到边缘。你可能会对其他团队正在做的工作失去同理心：“他们解决的那个问题很简单，我一个周末就能搞定。”

你使用的词语，你选择解释哪些、默认哪些，以及你认为别人出于何种动机，都会受到你视角的影响。这就是为什么工程师与非工程师沟通会如此困难。图 2-2 讲述了一个熟悉的故事：我们是多么容易误判别人对你所在领域的了解程度。

失去同理心也会在故障中表现出来：团队可能沉迷于问题中有趣的技术细节，忘了还有用户在等着系统恢复上线。

图 2-2. 人很容易在“别人知道什么”这件事上失去视角（来源：https://xkcd.com/2501，作者 Randall Munroe）。

对背景噪声充耳不闻

如果说一种失败模式是你们团队的关切显得比其他所有人的都重要，那么另一种恰恰相反：你根本不再注意到问题了！如果你几个月来一直在绕着同一个乱糟糟的配置文件或者有毛病的部署流程打转，你可能会习以为常，以至于不再把它当作需要修复的东西。同样，你可能没有注意到，一件起初只是有点烦人的事情已经慢慢变得更糟。也许一个问题已经濒临危机，但你甚至不再注意到它，因此你无法客观判断自己需要多快做出反应。¹

忘记工作是为了什么

身处自己的筒仓，可能意味着你与公司其他地方正在发生的事情失去了联系。如果你们小组最初承接某个项目是为了实现一个更大的目标，那么即使这个目标已经不再重要，或者已经通过其他方式解决了，这个项目可能仍在继续。如果你只做项目中属于自己的那一小部分，就很容易不再去想这个项目是为了什么。你可能会滑入这样一个世界：每个人都做着自己的一小部分，没有人觉得自己要对最终结果负责。你也可能忽视了自己所做之事的伦理问题，发现自己在做一件如果退后一步、通盘考虑就不会真正认可的事情。

看得更大

打开公司的组织架构图，看看你的小组和其他你关心的小组在哪里与组织的其他部分相连。当你扩大地图的可见范围时，你自己的小组可能会显得小得多，你的“你在这里”图钉可能会显得离核心地带很远。但没有视角，你就无法做出有影响力的工作。在这一节，我们会看看其他一些看清更大全局的技巧。

采取局外人视角

多年前，当我还是某个基础设施团队里最新的成员时，几周后我的同事 Mark 评论说：“我在介绍我们的系统时，你脸上会露出一种表情……”我当然觉得有几个老旧的系统需要替换，但我没意识到自己把观点如此清楚地（而且无礼地！）写在了脸上。两年后，得益于团队的辛勤工作，架构得到了极大的改善。我们为这些工作感到自豪。我觉得它相当不错！直到一个新人加入，然后……把观点相当清楚地写在了脸上。那时，我已经成了团队的局内人。我需要一个更新的“新人”来帮我重新看到问题。

当团队里的新人看到一团纠缠的架构或者一堆技术债时，他们没有任何历史背景。正如我的同事 Dan Na 所说，新人总能看到问题。他们没有经历过那些渐进的变化和温水煮青蛙，他们看到的只是情况本来的样子。没有先入之见，他们可以自由地四处看看，然后问：“这里到底发生了什么？这些东西有哪个是管用的吗？”

警告

新人的身份并不是当混蛋的许可证。事后诸葛亮地说一句“这太糟糕了！他们为什么不直接……”是很容易的。但要保持谦逊，假设事情之所以是现在这样，都有充分的理由。Amazon 的首席工程师群体在其社区信条中承认了这一点：“尊重前人的成果”。

刚加入时是你获得彻底局外人视角的最佳机会，但作为 Staff 工程师，你应该努力一直保持这种视角。你需要能够像自己不属于这个小组那样审视它，并诚实面对你看到的东西。你们的技术决策是否只对那些忘了团队之外还有一个世界的人才说得通？如果你们全都停下手头的工作，要过多久其他人才会注意到或在意？你们是否沉迷于技术，忘了最初的目标是什么？*一切都还好吗？*接下来的四节会提供一些像局外人那样看问题的技巧。

走出回音室

当你发现自己身处一个回音室，遇到的每个人都持有同一套观点时，与其他小组的同行建立联系，发现他们的一些观点就是……不一样，可能会让你大吃一惊。

在技术栈底层的基础设施岗位上待了十多年之后，我第一次与产品工程团队合作时受到了巨大冲击。他们行动很快，敢于冒险，认为打造客户喜爱的功能至少和这些功能的坚如磐石的可靠性一样重要。我们之间的争论动摇了我一些根深蒂固的信念，让它们变得更加细致入微。

主动结识其他小组的同行，是你工作的重要组成部分。与其他 Staff 工程师建立友好的关系。做到你们可以彼此说真话，而且不会引起争执，因为你们已经积累了足够多的善意。这包括理解其他团队对你们小组持有的任何负面看法——如果你开始看到他们的意见中合理的部分，你会做出更好的工作。把其他 Staff 工程师看作你的团队，就像你所属的任何一个团队一样。

同样的原则也适用于跨组织的情形。在图 2-3 和图 2-4 中，我把每位 Staff 工程师的范围描绘为单个小组，把每位首席工程师的范围描绘为一个组织。虽然实际结构会有所不同，但重点在于成为比你自己的团队或小组更大的事物的一部分，这样你就能更客观地看待每个人在做什么。

图 2-3. 一个软件工程组织的示例。这里的每个小组都包含多个团队。在这家公司，每位 Staff 工程师的范围都是单个小组，他们认为自己既是所在小组的一员，也是一个更大的 Staff 工程师虚拟“团队”的一员。

图 2-4. 一家公司内部的多个工程组织，每个组织都有一位 Staff 工程师。每位首席工程师都属于自己的组织，但同时也是首席工程师虚拟团队的一员。

走出工程领域：与产品同事、客户支持、行政人员等建立关系。如果你的工作影响到他们，或者他们的工作影响到你，就去友好地了解他们的观点。这会让你以一种全新的方式思考什么对你的部门或业务是重要的。

什么才是真正重要的？

与非工程师交朋友还从另一个方面有益于你的视角：作为工程师，很容易沉迷于技术。但技术只是达成某种目的的手段。归根结底，你在这里是为了帮助雇主实现其目标。你应该知道这些目标是什么。你应该知道什么是重要的。

一家初创公司对“什么重要”的定义，会不同于一家庞大的科技巨头或一家本地非营利组织。成熟的产品与早期的产品会有不同的需求。有些目标，以及由此而来的某些项目，比其他的更重要。图 2-5 展示了一个让你觉得是宇宙中心的项目，在更大的全局中可能远没有那么重要。排序会随着时间变化，所以要理解此时此刻什么重要。如果你的客户因为你的产品缺少竞争对手已有的核心功能而大批流失，那现在可能不是力推偿还技术债的时候。如果一切顺风顺水，而且你预期会有增长，那这可能正是确保基础牢固的好时机。

图 2-5. 正确看待你的项目。那次升级也许是你们组织最重要的工作，但着眼更大全局的人不会认为它重要。

公司的目标不止于它明确提出的目标和指标，还包括“继续存活”“有足够的钱给所有人发工资”以及“拥有良好的声誉”。我的同事、Squarespace 工程运营负责人 Trish Craine 把这些称为“永远成立的目标”。这些是公司的需求，它们如此显而易见，只有在面临危险时才会真正被说出来。你的组织提供的产品或服务应该能用。客户应该愿意使用它。部署它不应该慢得令人痛苦。既要了解明确的目标，也要了解隐含的目标。

提示

随着时间推移，公司的优先级会发生变化，地图的某些部分又会被迷雾笼罩。为了及时了解什么是重要的，要留意你所在小组和其他小组的全员大会，申请与你上级的上级进行跨级一对一沟通，并找机会与客户或依赖你的团队当面交流。如果你不了解你的工作为什么重要（或者是否重要）的业务背景，就去问。

也要留意目标何时发生变化，因为这可能意味着你的范围或关注点应该随之改变。你不在做最重要的事情也没关系，但你做的事情不应该是在浪费时间。如果你无法向自己解释为什么你正在做的事情需要一位 Staff 工程师，那你可能在做错误的事情。

你的客户关心什么？

Honeycomb 的 CTO Charity Majors 经常分发一种贴纸，上面写着：“用户不开心时，几个 9 都不重要。”这里的“9”指的是服务等级目标（SLO），这是衡量系统可用性的一种常见机制。“三个半 9 的可用性”意味着服务在 99.95% 的时间里都在正常运行。SLO 很有用，但正如 Majors 指出的，它们并不能说明全部情况。因为“可用”的含义是由谁来定义的呢？

Mohit Suley 是一位工程经理，曾任 Microsoft 首席工程师，他讲过他的团队如何追查并联系那些导致他们的搜索引擎 Bing 无法访问的不可靠 ISP。出问题的并不是 Bing，但正如 Suley 所说：“用户不会区分 DNS 服务、ISP、你的 CDN 或者你的端点，不管它们是什么。归根结底，就是有一堆网站能用，一堆网站不能用。”你需要从用户的角度来衡量成功。（如果你的客户是公司内部的其他团队，这一点同样适用！）如果你不了解你的客户，你就无法真正看清什么是重要的。

你的问题以前被解决过吗？

Amazon“尊重前人的成果”这一信条中包含一个提醒：“许多问题本质上并不新鲜。”如果你在创造新东西之前先研究一下别人已经做过什么，你就会想出更好的解决方案。

记住，你的目标是解决问题，而不一定是写代码去解决它。在构建新东西之前，花时间了解已经存在的东西——无论是在组织内部还是外部。²

行业视角

了解业内其他人是如何解决你正在处理的问题的。你偏爱的出版物和资源取决于你的兴趣，下面是一些我认为在架构、技术领导力和软件可靠性方面很有价值的资源。我很喜欢 LeadDev 和 SREcon 会议，会尽量多参加。LeadDev 有一个（在本书写作时）新开设的会议专题，叫作 StaffPlus。我主持过他们的一些活动，所以我不能完全客观，但我认为它非常出色！

在线交流方面，我喜欢 Rands Leadership Slack：其中的 #architecture 和 #staff-principal-engineering 频道都是宝藏。LeadDev Slack 的 #staffplus 频道在活动期间也非常活跃。

我订阅了每月一期的 InfoQ Software Architects’ Newsletter，以及 VOID 报告和 SRE Weekly。我还会读 Raw Signal 通讯，每周获取一些经理视角的观点。我也总是热切期待每季度一期的 Thoughtworks Radar。

无论你身处哪个领域，都会有它自己的出版物。用它们来保持视角，发现你需要时可以深入探索的新想法。它们也会帮助你持续学习。

地形图：在地形中穿行

定位地图给你视角，但你无法靠它导航。你需要另一张地图：一张展示地形的地图。

地质学家研究板块构造，即地球岩石圈的巨大板块（见图 2-6）如何随着时间推移相互挤压运动，形成山脉和海沟，引发地震和火山活动。团队构造也有类似的特性。当职责领域彼此碰撞时，它们就形成了一片组织地形，其中有重叠和冲突，也有山脊和裂谷。

图 2-6. 地球主要构造板块简图（改编自：Scott Nash，公有领域，https://oreil.ly/UdeNz）。

重组可能会打断那些需要紧密合作的小组之间的沟通。负担沉重的团队可能会固守阵地、竖起壁垒。一位新的高层领导可能引发一场地震，一夜之间重塑整个地貌。在组织中穿行（见图 2-7）需要一张地形图。

图 2-7. 一位在复杂地形中穿行的 Staff 工程师。

崎岖的地形

我们来探讨一下，如果你在没有详细地形图的情况下出发执行任务，会遇到哪些困难。

你的好主意得不到响应

• 在需要变革这件事上判断正确，连成功的一半都算不上。你必须让别人相信你是对的，更难的是，让他们在乎你是对的。这意味着要知道如何在组织中积累势能：弄清楚谁能为你的想法提供支持或帮助它传播，以及你如何才能让它冲过终点线、变成“现实”。

不到地方，你就不知道哪里难

• 许多看似显而易见的旅程中，都有某个关键节点，没有人想出过如何越过它。你也许正试图攀登一座曾经难倒过许多人的悬崖。Staff 工程师往往能越过经验较少的工程师无法越过的障碍，你也有可能在别人失败的地方取得成功。但如果你知道以前大家在哪里受阻，你就可以另辟蹊径，或者先解决问题中最难的部分，这样其他人就会相信这个项目值得他们投入精力。

• 一切都要花更长时间

  • 除非你了解组织是如何运转的，否则本应简单直接的决策会拖上几个月甚至几个季度。组织规划周期的机制也会影响你。一年中有些时候，更容易争取为新项目配备人手，或者号召所有人支持某个目标。如果你在季度工程 OKR 刚刚定下之后立即宣布一项举措，你将面临一场艰苦的战斗，可能要等一个季度才能看到朝目标迈进的任何进展。

理解你的组织

工程师有时会把组织方面的技能贬为“政治”，但这些技能是优秀工程实践的一部分：考虑作为系统组成部分的人，清楚自己在解决什么问题，理解长期后果，并在优先级上做出权衡。如果你不知道如何在组织中穿行，每一项变革都会困难得多。

在这一节，我会介绍一些驱散迷雾、理解公司地形的方法。首先是评估你们文化的几个方面，包括哪些东西会被记录下来、信任程度有多高、人们是渴望变革还是对变革犹豫不决，以及新举措从何而来。这些认识会帮你对一段普通的旅程建立预期：推进起来会容易吗？之后，我们会看看地形图上会出现的一些障碍和捷径。

文化是什么样的？

每当我面试求职者时，他们的第一个问题往往是：“这里的文化是什么样的？”我过去常常难以回答：从哪里说起呢？关于组织文化的大部头著作已经写了不少。不过现在，我认为大多数时候人们真正想问的是这些问题：

• 我会有多大的自主权？

• 我会感到被接纳吗？

• 犯错会是安全的吗？

• 影响到我的决策，我能参与吗？

• 在我的项目上取得进展会有多难？

• 这里的人……你懂的……友善吗？

公司文化并不是决定这些问题答案的唯一因素：个人和领导层也是其中一部分。但组织确实有它们各自独特的“性格”，所以我们来谈谈文化。

如果你的组织发布过价值观或原则声明，这能帮助你看出领导者最关心什么。但这些价值观是一种愿景：公司真正的价值观体现在每天实际发生的事情中。

为了更深入地了解你们公司的工程文化，下面有几个问题，你可以问问自己，或者和同事一起讨论。其中大多数问题没有对错之分。如果你们公司完全偏向某一个极端，你会很难施展；但在两极之间，有很大的成功空间。

保密还是开放？每个人知道多少？在保密的组织里，信息就是货币，没有人会轻易把它送出去。每个人的日历都是私密的。Slack 频道只能受邀加入。通常，只要你开口，就能获得某样东西的访问权限，但你得先知道它存在！当所有信息都只按需知晓时，就更难想出有创意的解决方案，也更难真正理解为什么某些东西行不通。

在开放的组织里，你能访问所有东西（甚至是凌乱的初稿！）。你可能会因为要选择看哪些信息而产生决策疲劳。你可能不知道哪些文档是正式的、需要采取行动，哪些只是早期的想法。而且信息开放可能会引发更多风波：糟糕的想法更难被悄悄否掉。

了解围绕分享的文化预期至关重要。在一个把知识锁起来的文化里，如果你把老板私下告诉你的事情转述出去，你就会失去老板的信任。在一个更开放的公司里，如果你隐瞒信息，或者不确保每个人都知道发生了什么，你会被认为是在搞政治或不值得信任。

口头还是书面？哪些东西靠口耳相传，哪些会被写下来？决策涉及多少书面写作和评审？在一些公司里，在走廊上的一次交谈中做出重大决策是常态，或者你的同事构建了一个巨大的新功能，你直到它上线（或者你因它而被呼叫）时才知道。在另一些工作场所，每次软件变更都要有正式的规格说明、需求、签核和审批清单，你可以预料一行代码的改动要花上一个季度。

幸好，大多数工作场所都介于两者之间。如果你们偏爱快速交谈，那你花时间把决策写下来可能会遭到抵触——而超过一页的设计文档根本没人看。规模更大、更成熟的公司往往对变更更加审慎。如果你在这样的公司，却没有创建变更管理工单或设计文档，你就会显得马虎、不负责任。我待过的一个团队有一顶牛仔帽，谁最近做了什么有点太“狂野西部”的事，帽子就会出现在谁的桌上。这是一种亲昵的调侃，但也是一个很好的提醒。

自上而下还是自下而上？举措从何而来？在一个完全自下而上的文化中，员工和团队觉得自己有权做出决策，并推动他们认为重要的举措。然而，当这些举措需要更广泛的支持时，它们就会放慢速度。如果各团队在方向或优先级上意见不一，缺少一个中心“决策者”可能导致僵局。

另一方面，在一家完全自上而下的公司里，人们会发现选择举措、果断行动要容易得多。不过那些决策不会是最好的，因为它们缺少本地的上下文。工程师们很可能会觉得受到控制，也没有能力在变化出现时做出反应。

Staff+ 工程师应该相当自主、能自我驱动，但要确保你的组织也认同这一点：如果你的经理希望由他来批准你把时间花在哪里，那么你不去沟通汇报就可能引发冲突。如果你习惯了征求许可或接受分派下来的工作，而你换到了一家自下而上的公司，你会被视为缺乏主动性，也很难把事情做成。

如果你知道你的组织通常如何运作，你也就会知道，是该先把你的想法带给一线的同行实践者、争取他们的支持，还是该先去说服你所在部门的总监。

快速变化还是审慎变化？年轻的公司往往会迅速做出决策，突然转向去尝试新机会。随着公司规模变大、历史变长，它们改变航向需要的时间也更长。“快”的组织可能会对承担一个长期项目（比如一次为期两年的迁移）的想法感到排斥。“慢”的组织则会错失那些唾手可得的改进机会。

根据你所处的环境，你需要以不同的方式来包装你的举措。如果你所在的地方行动如闪电，你会想要一条能立即展示价值的渐进路径。在更审慎的环境中，你需要表明你已经把整个计划考虑周全了。这也与口头文化和书面文化密切相关。

走后门还是走正门？不同小组的人之间如何交流？信息和请求可能有正式的渠道，但你们的社交文化还会增加非正式的渠道。如果大家跨团队关系友好，有问题时他们会直接发私信，喝咖啡时也会交流想法。³

如果一个小组的工程师可以直接去找另一个小组的对口人聊聊，那么做出涉及两个团队的决策就会容易得多。在有些地方，真正把事情办成的唯一途径，就是通过后门渠道和团队里的某个人搭上关系。如果更常见的做法是提一张工单然后等待，或者把合作想法沿着管理链往上送，直到你和另一个团队有一个共同的经理，那么一切都会花更长时间——但也会更可预测、更公平。

了解在你的组织中什么被认为是常态。如果每个人都严格只走正式渠道，那么不按顺序提问会被认为是无礼的，人们会因为你插队而对你评价不佳。如果后门渠道是办事的常规方式，那你可能会为了等一个回复等上一个月，而本来你只需要和那个一直在公司宠物邮件列表上欣赏你猫咪照片的人聊一聊就行。

排满还是有空？每个人有多少时间？如果团队人手不足、超负荷工作，那么任何不在现有产品路线图上的新想法都很难找到立足点——最快、最省事的回应就是不认真看请求，直接拒绝。在这种情况下，能够在不需要大量投入的前提下腾出时间的举措，会让你产生最大的影响。你最有可能成功的时候，是你可以独自完成或只需要一点帮助，而不需要让一群忙碌的人承诺做任何新事情。

不忙的团队看起来似乎更容易合作，但它们有另一个问题：没被排满的工程师很少会长期保持这种状态。如果有大量空闲时间，很可能正在出现一场寒武纪大爆发：各种相互竞争的新奇基层举措纷纷冒头，每一个都只有少数忠实拥趸。如果你选择一个初生的项目，帮它冲过终点线，并说服其他人也团结在它周围，你会产生更大的影响。

流动还是固化？权力、地位和声望从何而来？你如何赢得信任？一些组织，尤其是学术界以及大型的老牌公司，有着明确的等级制度：同一群人，以相同的格局，一起逐级晋升，在沟通、决策以及分配“好项目”方面有一套相当固定的结构。每个人就像晶格中的一个节点：只要你周围的人在往上走，你也会往上走。这类群体中的资深人士常常会说，他们从没刻意追求过晋升：他们待在原位，拿到一个项目，得到群体的支持，轮到他们时就获得了晋升。

这种等级制度对于那些年轻、小型、拼劲十足、自称某种精英体制的公司来说是大忌。我们实际一点：成功仍然取决于能否获得机会和举荐，因此它在很大程度上受到刻板印象偏见、内群体偏袒以及其他认知偏差的影响。（更多内容请参阅网站 Is Tech a Meritocracy?。）“流动”的公司为你改变自己在结构中的位置提供了更多空间，但你可能得多努力争取一下才能获得晋升。你可能会在不同小组之间流动，寻找高影响力的工作，以便按自己的节奏晋升。如果你坐等别人给你分配项目，你会等很久。

在晶格结构稳固的团队中，至关重要的是了解你在等级中的位置，并知道什么时候轮到你接手一个能带你更上一层楼的项目。如果你提议接手一个已被内定为别人晋升项目的工作，你会惹恼别人——我有一个朋友试过这么做，据说他们的老板看他们的眼神“就好像我提议去偷银餐具一样”。

试着用图 2-8 中的滑块图来思考这七个属性如何影响你的组织的运作方式。如果你想推动文化变革，通常是有可能的——只要你下定决心努力——随着时间推移把滑块往某个方向推一推。至少要知道它们所处的位置，这样你就能避开一些与主流文化背道而驰的陷阱。

图 2-8. 大多数公司在这些属性上都处于中间某处。

权力、规则，还是使命？

这里有另一个审视你们文化的视角：你们的领导者认为什么是重要的？社会学家 Ron Westrum 在他 2005 年的论文《组织文化的类型学》（“A Typology of Organisational Cultures”）中写道：

领导者通过他们的象征性行为以及奖惩，传达他们认为重要的东西。这些偏好随后成为组织员工全神贯注的事情，因为奖励、惩罚和资源都跟随领导者的偏好而来。与这些偏好保持一致的人会得到奖励，不一致的人则会被搁置一旁。大多数在组织中待了很久的成员本能地

知道如何解读时代的信号，而不懂的人很快就会付出昂贵的代价。

Westrum 用三个类别对组织及其对信息流动的影响进行了分类（见表 2-1）：

病态型

一种低合作的文化，以权力和地位为目标，人们囤积信息；用 Westrum 的话说，就是“专注于个人的权力、需求和荣耀”

官僚型

一种以规则为导向的文化，信息通过标准渠道流动，变革很困难；Westrum 写道，这里专注的是“规则、职位和部门地盘”

生机型

一种以使命为导向、高信任、高合作的文化，信息自由流动；Westrum 称之为“专注于使命本身”

表 2-1. Westrum 组织类型学模型：组织如何处理信息（Ron Westrum，“A typology of organisational cultures”，BMJ Quality & Safety 13, no. 2 (2004), doi: 10.1136/qshc.2003.009522）。

DevOps 研究与评估（DORA）小组（现为 Google Cloud 的一部分）已经证明，强调信息流动的高信任文化有着更好的软件交付绩效。越来越多的软件公司以拥有生机型文化为目标，这并不奇怪。这意味着鼓励协作的跨职能团队、从无责事后复盘中学习、鼓励实验、承担经过计算的风险，以及打破筒仓。如果你的组织是这样运作的，你分享信息、推进工作都会更容易。

如果你知道你的工作场所是以权力、规则还是使命为导向，你会发现把事情做成更容易。对人们愿意在多大程度上分享信息、相互合作、花时间提供帮助、支持新想法有所感知，能让你在穿越地形时更安全、更少受挫。如果你知道自己身处官僚体系，那么提前规划、遵守规则、尊重指挥链，你会更容易成功。如果你身处病态型组织，你会少冒风险——冒风险时也会给自己留好后路。推着小车走过鹅卵石路，要比走在平整的路面上更困难。如果你知道路会很颠簸，你就会预留更多时间，也不太会因为局面中那些你无法控制的方面而恼火。

留意兴趣点

这把我们带回到地形图。理解组织文化能让你大致知道一段普通的旅程会有多容易或多困难。但要导航，你还需要了解障碍、旅途中的难点以及捷径。下面是我所了解的一些组织地形中的兴趣点。

裂谷　公司的板块构造可能会在团队和组织之间形成裂谷。例如，图 2-9 描绘了一道可能出现在以产品为中心的软件工程团队和为他们提供服务的基础设施、平台或安全团队之间的峡谷。各个群体的文化、规范、目标和期望以不同的方式演变，造成了隔阂，使沟通、决策和解决争端都变得困难。

图 2-9. 基础设施组织与产品工程组织之间的裂谷。

即使在一个组织内部，也可能形成较小的裂谷。每个团队所界定的职责边缘很少能完美对齐，项目工作和信息可能会掉进团队之间的缝隙里。

堡垒　堡垒是指那些似乎铁了心要阻止任何人完成项目的团队或个人。也许你需要他们的批准，却约不到他们的时间。又或者他们是守门人，似乎在还没弄清你要什么之前就认定你的想法很糟糕。虽然有些堡垒是小暴君，但大多数都是出于好意。他们把关是因为他们在乎。他们在努力保持代码或架构的高质量，确保每个人的安全。

要穿过堡垒的大门，你可能需要带上一位守门人尊重的人给你的支持信物，或者知道放下吊桥的口令。（常见的口令包括：证明你已经化解了所提变更的所有风险，完成冗长的检查清单或容量评估，或者对文档里海量的评论逐一给出令人满意的回复。）另一个选择是一场旷日持久的血战：你在每一点上据理力争，并把其他人拉进战斗——即使赢了，也可能是一场惨胜，让你几乎后悔做过尝试。或者你可以放弃，绕远路避开堡垒，这会让你的旅程更复杂，你也失去了守门人本可以分享给你的智慧。

争议领土　以一种能让每个团队自主工作的方式来划定团队边界是非常难的。无论你的 API、契约或团队章程有多明确，总不可避免地会有一些工作，被多个团队都认为归自己所有，而在这些争议中周旋可能让人觉得有风险。

我曾经参与过一个项目，需要把一个关键系统从一个平台迁移到另一个平台。迁移这个特定系统只占我项目的不到 5%，所以我不想在上面花太多时间——但当我寻找负责它的人时，我碰了壁。这个系统的所有权分散在三个团队之间，每个团队负责其行为的不同方面。没有人能告诉我把它迁移到我们的新平台上是否安全。每个小组都说：“据我所知是安全的，但你还应该问问……”然后指向下一个团队。没有一个能代表整个系统的负责人，我只能兜圈子，试图建立足够的上下文来说服自己迁移会成功。（结果没有成功。让三个团队在回滚上达成一致的过程也不怎么好看。）

当两个或更多团队需要紧密合作时，如果他们对要去往何处没有同样清晰的认识，他们的项目就可能陷入混乱。缺乏一致可能导致权力斗争和白费力气，因为双方都试图在技术方向上“取胜”。团队职责的重叠会让情况更糟，使决策复杂化，浪费每个人的时间。

无法穿越的沙漠　在你努力实现目标的过程中，有时会碰上一场别人认为不可能打赢的仗。这可能是一个规模实在太大的项目，或者一个政治上一团乱麻、总以某位高层的否决告终的局面。不管是什么，以前都有人尝试过，而任何再次挑战它的提议都会遭遇泼冷水和倦怠。

这并不是说你不应该尝试！但你应该有足够的证据，说服自己和他人这一次会有所不同。如果你挑起的是一场可能打不赢的仗，最好在开始之前就心里有数。

铺好的路、捷径和远路　致力于提升工程师效率的公司，往往会建立流程，确保做某件事的官方方式也是最简单的方式。例如，按照一份自助式检查清单来确保一个新组件可以安全地投入生产。如果你足够幸运，有一些这样简单、定义清晰的路径，那就弄清楚它们在哪里，然后使用它们。

不幸的是，并非所有的路都铺得很好。我们都曾长时间试图以官方方式解决一个问题，直到有人告诉我们通往成功的秘密小径：没有文档的搜索功能，能帮你开账号的管理员，或者 IT 部门里唯一会回复私信的那个人。有时候，官方方式恰恰是大家都学会了不要用的方式。图 2-10 展示了一条铺好的路，它并不通往人们真正想去的大多数地方；人们转而走那些老路。如果你不知道组织里的这些羊肠小道，一切都会花更长时间。但当你学会它们时，团队可能会要求你不要把它们写进文档：他们坚持说，大家应该走新路，而新路很快就会变得更好。

图 2-10. 新铺的路很漂亮，但人们真正想去的大多数地方都在沼泽深处。

你的地图上有哪些兴趣点？

你的地形图上还应该有什么？有没有你可能一脚踏空的意外悬崖？有没有一些行为或沟通风格，在别的公司或团队完全没问题，在你们这里却被认为是无礼的？有没有你以为应该存在、实际上却没有的护栏？有没有容易喷发的区域，或者会给自以为站在坚实地面上的人带来地震（或突然重组）的领导者？地方政治又如何——哪些团队由君主统治，哪些由议会治理？哪些处于无政府状态？谁和谁在交战？

试着画出你自己的地图。记住，制图本质上是政治性的：你选择把什么画进去，也透露了关于你的一些信息。留意你把什么放在了地图的中心，以及你倾向于站在哪一边。

由于重组、收购、个人性格，以及在某些情况下纯粹是彼此看不顺眼的人，组织最终会形成各种奇怪的形状。如果你想出了我没想到的障碍、信息通道或其他地貌，我很想听听。⁴

决策是如何做出的？

观察信息和观点如何在公司中流动，看它们如何出人意料地变成既定计划，是一件很有意思的事。突然间，每个人都在用一个新的缩写，或者持有某种特定的观点，而你很难看出这是从哪里来的。一个曾经被寄予厚望的项目，现在被认为很可能会失败而遭到冷落。每个人都对微服务感到兴奋，或者他们已经不再追捧微服务、转而对无服务器感到好奇，又或者他们认为模块化单体才是务实的常识。一个团队今年获准招更多人，另一个团队则没有。所有这些决策是怎么发生的？有发过备忘录吗？

有些决策似乎是从对话中自然浮现的，没有人真正宣布过已经做出了决定。另一些则更正式地发生，但是在你不在场的房间里。如果你有很多想法，看到别的举措落地生根，而你的却没有，可能会很沮丧。他们为什么不听你的提议？⁵ 事实是一件我们很多人都难以释怀的事：在方向上技术正确只是开始。你还需要说服其他人——而且你需要说服对的人。

如果你不了解你的组织或公司是如何做出决策的，你就会发现自己无法预见或影响这些决策。你也可能会发现，你以为自己对下一步该做什么与大家持有相同的看法，结果突然间所有人都在倡导另一条路。如果你总是觉得自己被蒙在鼓里，这就说明你不了解决策是如何做出的，以及谁在影响它们。

“房间”在哪里？

影响你和你范围的决策每天都在发生，如果你一再被它们惊到，会很不舒服。你至少应该对这些决策从何而来有所感知，而且你很可能也想对它们施加一些影响。我们先从正式渠道和做出重大决策的官方会议说起。

你能接触到哪些决策，取决于你在组织层级中所处的位置。其中有些决策不可避免地会在公司中比你更高的层级上做出。你可以通过汇报链或其他渠道，确保相关信息传达到那些房间，从而影响这些决策。但也有一些决策直接在你的范围内做出，你会希望尽可能参与其中。如果你看过音乐剧 Hamilton，你会记得 Aaron Burr 渴望进入“事情发生的房间”。正如 Burr 告诉我们的，不在房间里的人“对他们被交换掉的东西没有发言权”。虽然有时局外人视角会有帮助，但这次不是。如果你想设定技术方向或改变本地文化，你就需要成为做决策的那个群体的局内人。

弄清楚决策是在哪里做出的。也许有一个每周的经理会议，本意是做组织层面的决策，却经常对流程或技术方向发表意见。一位总监可能倾向于在与直接下属的例会上制定计划。一个中央架构小组可能有一个 Slack 频道，他们在里面就前进的道路达成共识。如果你看不清组织是如何运作的，就请一位你信任的人带你梳理一下某个特定决策是从哪里来的。（要讲清楚你不是在反对这个决策，只是想了解组织的内部运作。）

注意：可能根本就没有“房间”。在最极端的情况下，重大的技术决定可能是在与最高领导的一对一沟通中做出的，也可能本意是完全自下而上地产生（因此往往根本做不出来）。⁶ 但如果对于你感兴趣的那类决策，确实存在一个“事情发生的房间”，那就弄清楚它是什么、里面有谁。

申请加入

一旦你发现了一个做出重要决策的会议，想参与其中是很自然的。但你需要一个令人信服的理由，说明为什么应该让你参加。这似乎显而易见，但你的理由应该关乎对你的组织的影响，而不是对你个人的影响。无论你的同级经理们多么喜欢你，把被排除在外说成对你的职业发展不利，都不太可能改变他们的想法。要展示让你加入会如何让组织更好地实现目标。展示你能带来什么现在还没有的东西。准备一套清晰的说法，说明你为什么需要参与，练习好你的要点，然后去申请加入。

你可能会遇到一些阻力。往一个群体里加人，对已经在里面的人来说很少是没有代价的。任何会议每多一个人，都会让它变慢、讨论时间拉长，并降低与会者展露脆弱或直言不讳的意愿。如果这个群体已经习惯了一起工作，每个新人都会重置原有的互动模式；在某种程度上，与会者不得不重新学习如何一起工作。

如果你确实收到了邀请，别让任何人后悔邀请你。Will Larson 的文章《进入房间》（“Getting in the Room”）强调，除了为房间增加价值，你还需要降低让你参与的成本：有备而来，发言简洁，做一个善于协作、摩擦小的贡献者。如果你让这个房间做决策或快速分享信息的效率降低了，你就不会再被邀请了。

如果你没能进入房间，别往心里去，尤其是在那些还在摸索 Staff+ 工程师到底是做什么的、还没有接受这是一个领导角色的组织里。在他们想清楚这件事之前，与其抱怨没被邀请，不如友善待人、把工作做好，这样你会有更大的影响力（也更像一位领导者）。理解现状，保持友善，并且正如我在第 1 章所说，永远不要做个混蛋。

还有一些房间你就是不应该进去。如果你明确走的是个人贡献者通道，你通常不应该参与关于薪酬、绩效管理以及其他管理通道事务的讨论。你可以向你的经理或总监提供影响这些决策的信息，但采取行动是他们的事。如果重大的技术决策和那些经理之间的对话在同一个房间里进行，你可以建议把这些议题拆分到不同的会议中。

最后，记住你想进入的房间所拥有的权力可能比你想象的要小。多年前，我惊讶地发现，一群总监并不认为他们的意见有多少分量；他们很沮丧，因为无法影响往上两级那些真正的推动者和决策者的决定。原来还有一个我从未想到过的“房间”。在那之上可能还有其他房间！对于你申请进入的是什么，要有现实的认识。

影子组织架构图

以上就是正式的决策过程。如果你理解了这一点，你就会对组织如何形成观点、决定做什么有很多了解。但不可避免地，还有大量其他影响在起作用，其中有些从表面上看完全说不通。非正式的决策并不遵循基于层级或职位头衔的规则。这些东西当然有分量，但还有更多因素在起作用。

了解谁是官方的技术领导者固然重要，但了解他们听谁的、如何做出决策同样重要。如果你们基础设施组织的总监 Jan 看起来完全支持你的想法，然后突然冷淡下来，这是怎么回事？如果你留心观察，就会发现 Jan 在做任何决策时的第一步都是去问问 Sam，他 10 年前就加入了团队。Sam 的资历并不算特别高，但如果 Sam 认为某件事是个坏主意，你就永远不可能让 Jan 支持它。当你刚加入一个组织时，这些影响力的脉络并不是一眼就能看出来的，所以一个好的早期做法是交几个朋友，问问组织是如何运作的。

Brian W. Fitzpatrick 和 Ben Collins-Sussman 在他们的著作 Debugging Teams: Better Productivity Through Collaboration 中描述了“影子组织架构图”：权力和影响力借以流动的不成文结构。影子组织架构图能帮助你了解谁是群体中的影响者，而它很可能与实际的组织架构图并不相同。这些影响者正是在变革发生之前你需要说服的人。

作者们识别出了两类人：“联络者”，他们认识整个组织中的人；以及“元老”，无论级别或头衔如何，他们仅凭待得久就拥有影响力。这些人很可能对什么行得通、什么行不通有很好的把握，而那些真正拥有级别和头衔的人在做决策时很可能会信任他们，依赖他们的良好判断。如果你能获得他们的认同，你就取得了很好的进展。

让你的地形图保持最新

我在前面谈到让定位地图保持最新有多重要。让地形图保持新鲜则更加重要。实地情况会迅速变化，你以为自己知道的事情会不再成立。在普通的一天里，你可能需要知道：

• 你依赖的一个团队换了新的负责人。

• 你一直在等的一个项目最终不做了。

• 季度规划即将开始。

• 一个有用的新平台即将上线。

• 你的产品经理即将休长假。

需要跟进的信息很多。但这些你都需要知道，所以你需要知道该关注什么。下面是一些保持信息更新的方法：

自动化公告列表和频道

专门用于分享新设计文档、通报故障或链接变更管理工单的频道，能让每个人轻松地从高层了解正在发生的事情。如果这类频道还不存在，而你觉得它们会有用，可以考虑创建它们。

深入现场

精益制造领域的人谈论 gemba（现场），意思是走进生产车间，看看事情实际上是如何运作的。找到一些途径，与你周围团队正在做的工作保持联系。形式可以是偶尔结对完成一些改动、管理故障，或者为一个你想深入了解的系统做一次部署。离技术太远不仅会减少你的上下文，还可能削弱你的技术可信度。（第 4 章会详细讨论这一点。）

潜水旁观

我在 Rands Leadership Slack 上问过大家是如何做到“知道事情”的，一个共同的思路是：关注那些并不完全保密、但也未必是给你看的信息。这包括查看资深人员的日历，浏览你没参加的会议的议程或纪要，以及——一个我从没想到过的方法——查看按创建时间倒序排列的完整 Slack 频道列表，这样你就能看到有哪些新项目正在启动。

留出阅读时间

在文档文化成熟的公司里，计划和变更通常会附带 RFC、设计文档、产品简报等。你可以快速浏览以获取一些基本上下文，或者在日历上安排时间深入阅读。

与领导层保持沟通

你需要会把事情告诉你的盟友和支持者。经常与他们沟通，听听幕后的最新动态，并确保你的思路与领导者的思路仍然一致。

与人交谈

出去喝杯咖啡聊聊天，不只是愉快的关系建设——它还是上下文的绝佳来源。如果你真想获得视角，就去和工程以外的人聊聊：产品、销售、市场、法务等等。如果你在打造一款产品，就和客户支持的同事交朋友：他们比你更了解你所创造的东西。也要和行政人员交朋友。行政人员聪明、足智多谋、人脉广泛。他们知道正在发生什么，而且往往是公司里最有意思的人。去交朋友吧。

“我不知道该怎么和人交谈”

许多工程师对任何带有“社交拓展”味道的东西都很反感。这让我们想起 80 年代那种油腻的权力午餐。（还是只有我这么想？）但社交拓展不必是功利或龌龊的。如果你去了解别人、待人友善，分享信息和互相帮助自然会随之而来。

如果你不知道如何和某人开启对话，一个简单的切入点是提个问题，对他们的工作表现出兴趣，或者（真诚地）称赞他们身上某个你欣赏的地方。⁷ 大多数人都乐于谈论自己的工作或优先事项，大多数人也乐于解释他们感兴趣的某样东西是如何运作的。闲聊是一项可以学会的技能，它会在你的整个职业生涯中带来回报。（如果你交谈的对象比你更初级，那么让气氛不尴尬在某种程度上是你的责任。）

如果地形仍然难以穿行，那就做一座桥

拖慢技术组织的问题，最常见的是人的问题：团队之间不知道如何沟通，没有人觉得自己有权做出某些决策，以及权力斗争。这些都是难题！当你往地形图上添加信息时，你可能会发现一些地方让你忍不住想潦草地写上“此处有龙”，然后发誓绕道而行。但 Staff 工程师往往可以通过去到别人都不敢涉足的地方，让这片危险的领地对其他所有人来说变得更容易通行，从而产生最大的影响。

Westrum 模型强调了“搭桥”（见图 2-11）的重要性，即在组织中那些否则会存在巨大信息鸿沟的部分之间建立联系。你对地形了解得越多，就越容易弥合鸿沟：发出那封没人发的邮件总结，介绍两个一个月前就该交谈的人认识，或者写一份文档展示各个项目之间如何关联。

图 2-11. 当季度规划还遥遥无期时，Staff 工程师可以建立联系，弥合两个组织之间的鸿沟。

Google 的 DevOps 网站建议预先搭建桥梁：“找出组织中某个你不理解其工作（或者其工作让你感到沮丧，比如采购）的人，邀请他们喝咖啡或吃午饭。”

在可能的情况下，把你的工作范围界定为跨越构造板块，涵盖某个系统或问题领域的全部，而不仅仅是属于单个团队的那一部分。这样，你就能接住那些正在被遗漏的工作，调解冲突，并帮助就正在发生的事情形成一个统一的叙事。当有重大变更被提出时，你会有足够的上下文来说“是的，这次迁移是个好主意”，或者“不，我们还有工作要做”。

藏宝图：提醒我一下，我们要去哪里？

到目前为止，我们已经画了两张地图。定位地图显示我们在哪里。地形图显示我们如何在组织中穿行。但我们要去哪里？这就是第三张地图的目的（见图 2-12）。

图 2-12. X 标记了宝藏埋藏的地点！现在你只需要到达那里。

藏宝图为我们讲述了一个引人入胜的故事：我们要去哪里，以及为什么想去那里。让我们去冒险吧！

追逐闪亮的东西

我在本章前面谈到，你需要越过你们小组的局部问题，对周围的世界保持视角。在时间维度上你也需要同样的视角。人很容易过度关注短期目标，比如当前的功能发布或者 App Store 上最新的一条差评。但要想得更大一些。你想到达哪里？你做这一切是为了什么？需要说明的是，我并不是说你不应该寻求短期的胜利。但只考虑短期目标会带来局限。如果你只考虑短期：

让所有人朝着同一个方向前进会更难

如果团队不知道大计划，要么他们会走到错误的地方，要么每个决策都会冗长、复杂、充满讨论。有时候，绕开困难意味着要走一条迂回的路。每个人都应该非常清楚，在那个里程碑之后需要进行怎样的航向修正。

你做不成大事

如果你的团队一直专注于解决局部问题和痛点的短期项目，你们就无法解决那些需要多个步骤的更大、更长期的问题。团队之外的人可能也看不清你们现有项目的价值。

你会积累冗余

如果团队不知道要去哪里，他们有两个选择。他们可以试图保持足够的灵活性，以支持未来的每一种状态，结果造出过于复杂、难以维护的方案。或者他们可以做局部决策，冒着这样的风险：他们的方向与其他所有人都不一致，他们的方案会变成一个奇怪的边缘情况，其他所有人都不得不绕着它走。

你会出现相互竞争的举措

在一个依赖基层或自下而上举措的组织中，可能会有好几个人试图围绕完全不同的方向凝聚热情。他们都在努力做正确的事、让大家保持一致，但最终的结果却是混乱。

工程师停止成长

只关注短期目标，会限制你思考和定义工作的方式，也会限制你对那些落在任务缝隙之间的工作承担多少责任。如果团队试图完成一个大项目，他们就必须找出已分配任务之间的空白，并想办法填补，在此过程中培养技能。一个习惯于围绕短小、定义清晰的目标进行迭代的团队，不会为更大、更难的项目练就肌肉，也无法讲清楚他们为什么做了他们所做的事情。

着眼长远

如果每个人都知道自己要去哪里，生活就会变得轻松。一路上就不需要保持紧密的步调一致。每个团队可以更有创意地找出自己的路线，对他们要到达那里需要解决的问题有自己的叙事。他们不太可能走错路，而且会有足够的信息来做决策，减少他们需要做的对冲以及需要承担的技术债。他们可以庆祝沿途的胜利，同时记住还有一个长期目标，真正的庆祝要等到达那里之后才会到来。

你为什么要做你正在做的事？

我经常使用的一个类比是许多策略游戏中的科技树，比如 Civilization（《文明》）。⁸ 万一你还没有在这款出色的游戏上，呃，投入过多得离谱的人生时光，我来解释一下它是怎么玩的。你扮演一个文明的统治者，努力建立一个帝国。你走向伟大的道路包括积累科学知识，所以在游戏过程中，你可以选择研究各种技术。可供研究的技术构成一个有向图（见图 2-13）。一开始你可能会研究陶器和狩猎之类的东西，但随着游戏推进，你的技能会层层叠加。在 Civilization 中，不研究桥梁建造和蒸汽机，你就无法修建铁路。而没有物理学和工程学，你就无法研究蒸汽机。所以在游戏中会有这样一个时刻：你正在研究物理学，但你的真正目标是修建铁路。在你建好桥梁、研究出蒸汽机、并给你的列车长们订购小帽子之前，你都不会获得真正的胜利。（很遗憾，最后那一步其实并不存在。）除非你记得自己打算去哪里，并持续朝它努力，否则你永远坐不上火车。

图 2-13. Sid Meier’s Civilization II 科技图的一部分，由 Microprose/Activision 制作（来源：http://www.civfanatics.com）。

当你选择投资某项技术时，往往是因为它是通往其他东西的路上一个无法绕开的步骤。你构建一个新的服务网格，不是为了享受构建服务网格的乐趣；你构建它是为了让你的微服务框架更易用，因为你想让新服务能够快速搭建起来，因为你希望团队能更快地发布功能。真正的目标是缩短产品上市时间。当你知道真正的目标时，你就可以退后一步，评估任何提议的工作是否能让你更接近它。

分享地图

驱散战争迷雾、揭示旅程的真正目的地可能需要花些时间。一旦你确实理解了它，不要只留给自己。这意味着要把这个故事讲给别人听，让他们理解它为什么重要。你的故事应该展示你们在哪里、要去哪里，以及为什么一路上要采取这些步骤。如果有需要了解的海怪或捷径，你可能会想把它们标出来——但不要加入任何干扰信息。让人很容易看清正在发生什么。地图应该描述宝藏——也就是给出一个清晰的成功定义——这样每个人都知道自己的目标是什么。

看到自己在取得进展是很激励人的，但令人意外的是，人也很容易忘记自己曾经在哪里，甚至可能觉得自己毫无进展。作为手握地图的人（见图 2-14），你处于一个很好的位置，可以展示每个人都在接近目标（如果没有，就修正航向）。既要讲述你们要去哪里，也要讲述你们从哪里来。

图 2-14. 既要讲述你们要去哪里，也要讲述你们曾经在哪里、已经取得了多少进展。

如果藏宝图仍不清晰，也许是时候画一张新的了

如果每个人都在依据同一张藏宝图工作，那么你在这方面的工作就完成了。但如果你发现存在多条相互竞争的路径，或者根本没有计划，你可能需要帮助大家选择一个目的地。有时候，你只需要写一份简短的总结，说明你在哪些地方看到了困惑或不一致。通过把事实讲清楚并分享出去，你就迫使这场对话（或者也许是争论）公开化。但是，在问遍所有问题、梳理了 Civilization 的科技树、鼓励意见相左的人相互交流，并且认真思考之后，你可能仍然会得出结论：实际上还没有人选定一个长期目的地，或者存在多个相互竞争的目的地。

在这种情况下，再驱散地图上的战争迷雾也不会有更多收获了：是时候创建一张新地图了。这正是下一章的全部内容。

你的个人旅程

在结束本章之前，我们来谈谈你的旅程。作为 Staff 工程师，你可能需要更长的时间才能看到工作的影响。这意味着讲述这些工作的故事更难，但也更重要。当你回顾过去时，你应该有一个叙事：你当时想实现什么，结果如何。你和你的小组一起完成了什么？当你展望未来时，你也应该有一个故事：你想做成什么？你当前的工作如何为这个目标做出贡献？

一旦有了这个叙事，即使是小任务也会成为一个更大故事的一部分。任何一周的工作可能都说明不了什么，但你这个月、这个季度、这一年做了什么？你是否在接近某个宝藏？为了理解你的旅程，你还需要一张地图：路线图。我们会在第 9 章画出它。

小结

• 练习有意识地寻找更大全局、看清正在发生什么的技能。

• 在上下文中理解你的工作：了解你的客户，与小组之外的同行交流，理解你的成功指标，并弄清楚什么才是真正重要的。

• 了解你的组织如何运作，以及其中的决策是如何做出的。

• 建立或发现能让你所需信息流向你的路径。

• 弄清楚每个人的目标是什么。

• 思考你自己的工作，以及你的旅程是什么。

1. 有一个流行的比喻叫“温水煮青蛙”：如果你把一只青蛙扔进一锅开水里，它会跳出来；但如果你把青蛙放进冷水里，非常缓慢地升高温度，你就能把水烧开、把青蛙煮死。它常被当作警世故事，说明渐进的变化会变成常态，我们可能在毫无反应的情况下滑向灾难。当我得知真实的青蛙并不会这样——它们会直接跳出来！——我真是松了一口气。放过那些可怜的青蛙吧，不过这个比喻还是有用的。 ↩

2. 这也是为什么设计文档应该有一个“考虑过的替代方案”章节；我们会在第 5 章更多地讨论设计文档。 ↩

3. 兴趣相投的 Slack 频道、社交俱乐部和员工资源小组（ERG）都是认识他人、在整个组织中建立联系的绝佳方式。向我公司 #crosswords 频道的朋友们致意，他们每天都会分享自己做《纽约时报》填字游戏的用时；也向 #women-in-engineering 频道的参与者们致意，他们会为每位成员的成功喝彩。 ↩

4. 如果你身边有五年级的小学生，我推荐和他们讨论一下地貌。他们非常擅长回答这样的问题：“如果峡湾是一个关于人们试图合作的比喻，它会是什么？”（两个团队合作做了一个大项目——一条冰川——但他们彼此生气了，项目融化了，只剩下底部的水。现在你知道了。） ↩

5. 没有明确所指的“他们”常常可以作为一个关键词，提醒你正在信息不足的情况下行事。如果你发现自己有这样的想法，请再确认一下你说的“他们”是指谁。如果是“整个组织”，那这就是你问题的一部分。要准确了解你需要说服的是谁。我会在本章后面更多地谈到官方决策者和“影子”组织架构图。 ↩

6. “Coordination Headwind: How Organizations Are Like Slime Molds”是一个关于自下而上协调的失败模式的精彩演讲。 ↩

7. 称赞你欣赏的东西，但请不要告诉你的同事他们长得好看！一般来说，只称赞对方自己选择去做的事情。一份写得很好的 RFC、一场顺畅的会议，或者一个很酷的桌面玩具，都是可以称赞的。 ↩

8. Civilization 现在已经出到第六代，是一款已经存在了几十年的策略游戏。它使用战争迷雾，你必须在长期投资和短期投资之间做出好的决策。我推荐玩 Civilization 来理解 Staff 工程的方方面面。就跟你的老板说这是做研究。 ↩