多层上下文 (Layers of Context)

原始链接: https://lethain.com/layers-of-context

最近我和一位资深工程师（Staff-plus）聊天，他正苦恼于无法影响其他团队的同事。每次他提出一个方案，他自己的团队都同意，但其他团队的人总是反对并打回。他想知道为什么别人总在否定他的方法。后来，我和他的同事们聊了聊他们最近的几次分歧，发现问题在于：这位工程师的提案缺乏全局背景（上下文）。他很难在多个不同的上下文层面上思考问题。

所有复杂的问题都涉及多个上下文层次。举个具体的例子：如果有团队想在公司的技术栈中引入一门新编程语言（比如 Erlang 或 Elixir），不同层面的人会怎么看？我曾两次遇到这种情况：一次是在 Yahoo!，我的团队负责人引入了 Erlang，让安全和工具团队非常头疼；另一次是在 Uber，一个团队想用 Elixir 来实现他们的服务。

以下是不同层面的上下文视角：

项目研发团队的视角：
- 需要解决多台服务器协同工作的问题。
- Erlang 和 Elixir 拥有构建分布式系统的优秀工具。
- 团队里刚好有经验丰富的 Erlang 工程师，其他成员也很激动能学习一门新语言。
开发者体验与基础设施团队的视角：
- 支持整个研发部门的预算是固定的。
- 每多支持一门新语言，对常用语言的投入就会减少。这会让基础设施团队显得效率低下，因为多语言维护实际上就是会降低效率。
- 研发团队总承诺"引入新语言后产生的额外工作我们自己担着"。但基础设施团队听多了这种话，结果往往是当那些团队重组后，新语言的工具维护就变成了基建团队的烂摊子。所以他们认为，无论研发团队保证得多好，新语言项目最终都会成为基建团队的负担。
工程领导层的视角：
- 希望把"创新预算"花在对用户有价值的问题上，而不是用来引入和现有工具差不多效果的新技术。
- 手里预算很紧，希望能把钱最大化地花在产品研发上，同时不影响稳定性和效率。引入新语言与此目标背道而驰。
- 希望招聘和培训流程标准化，因此编程语言越少越好。
- 以前吃过亏：团队试图引入新语言，最终却因为缺乏基础设施的支持而导致项目停滞。

这两次经历让我深受启发。第一次遇到时，我觉得引入新语言是个好主意；第二次遇到时，我的视角变宽了，我坚决反对了这个决定。而在我现在作为高管的角色中，引入新语言根本没得商量，因为这违反了我们的工程战略。

中级产品工程师忽略基础设施视角的某些部分是正常的，中级基建工程师不了解产品视角的某些部分也是正常的。但要成为一名成功的资深（Staff-plus）工程师，你必须能够跨越这些上下文层次去感知和推理：既要看到产品视角，也要看到基础设施视角，还要理解（或主动去了解）领导层的视角。

如何跨越不同的上下文层次？

在任何岗位上，你都会缺乏某些关键的上下文信息，从而限制你对周围环境的理解。理想情况下，你的同事或经理会花时间向你解释这些背景，但现实中他们往往不会。比如，我花了很长时间才弄明白公司的财务计划是如何与我们的规划流程挂钩的，很大程度上是因为从来没人给我解释过。大家通常都深陷在自己的上下文层面中，根本没意识到别人可能完全不了解。

如果你想培养跨层面的感知能力，以下是我发现最有效的一些方法：

保持好奇心，少些固执己见： 当别人说的话让你觉得莫名其妙时，几乎总是因为你缺乏他们那个层面的上下文。当你对别人的观点感到困惑时，不要急着去说服他们，而是试着去挖掘他们背后的背景信息。你的职位越高，这种心态就越有价值。
进行团队轮岗： 如果你做平台研发，可以和经理商量，去使用你们平台的产品团队工作三个月。每隔几年这样做一次，能帮你理解不同团队如何看待同一种情况。
参与销售电话和查看客诉工单： 跳出纯工程的视角，直接去了解终端用户，这是跳出你日常思维局限的有力方式。
在不同类型的公司和行业工作： 深耕一个领域（比如金融科技或电商）有很多好处，但在职业生涯中体验几个不同的行业同样有价值。看到其他行业的运作，能让你更好地理解你当前所在行业的独特之处。去大公司看看能让你明白创业公司的特别之处，反之亦然。
建立广泛的人脉网络： 发展广泛的同行网络是最简单的方法，可以借用他人辛苦积累的经验，又不用卷入公司内部的利益纠葛。多去探究"为什么你在某个问题上的观点可能是错的"，而不是找理由证明自己是对的。

做这些事情需要时间。老实说，我花了整整十年才真正擅长感知和驾驭不同的上下文层次。这也是我在早期试图向更高管理层晋升时，阻碍我前进的最大短板。

热情可能会蒙蔽你的双眼

就像许多基础的领导技能一样，"跨层次思考"听起来很直白，但很多人在执行时却很困难。最常见的原因是缺乏好奇心，但最难克服的障碍其实有些反直觉：太在意了。

我见过很多非常聪明的工程师，他们极度渴望用某一种特定的方式解决问题------这种方式在他们自己的上下文层面里绝对是完美的------以至于他们完全看不到其他层面的存在。例如，我曾和一位高级工程经理共事，他因为没得到晋升而一直很不满，同时还威胁说：如果不引入他偏爱的某款笔记工具，他就要辞职。当时我们公司的笔记已经散落在多个知识库中了，再引入一个新的只会让知识更加碎片化------这在我们的开发者效率调查中一直是排名前三的痛点。但这个人对这款特定的笔记工具深信不疑，对其他层面的问题完全视而不见。

作为曾经也在这个问题上苦苦挣扎过的人，我发现分三个阶段来处理问题非常有价值：

专门集中精力去理解对方的视角。
进入"学术评估"模式，极其努力地从纯理智、客观的角度去思考这个问题。
只有在完成前两步之后，我才把个人的情绪和偏好带入决策中------我到底认为哪种方法最好？

这种方法的目的不是要摒弃我的感受和直觉（我知道它们在有效决策中很重要），而是确保我的情绪不会蒙蔽我对客观可能性的判断。我越来越相信，只要你花时间去彻底了解现状，大多数所谓的"权衡妥协"其实是不存在的------你完全可以鱼和熊掌兼得。这种方法帮我把精力最大化地用在"解决整个问题"上，而不是卷入参与者的冲突中。

如果你觉得"存在多层上下文"这个观点太显而易见、不值一提，那你可能已经很擅长考虑各方视角了。然而，如果你经常发现自己与同事或领导意见不合，不妨花点时间，用这个概念去审视一下最近发生过的冲突，看看这是否是问题的根源。对于我曾共事过的一些极具天赋的人来说，这是他们在成为卓越的高层领导者之前需要学习的最后一课。