最近，我与一位员工以上级别的工程师聊天，他一直在努力影响他的同行：每次他建议一种方法时，他的团队都会同意他的意见，但他在组织中的同事却不同意，并予以回击。他希望得到我的建议，为什么他的同事总是破坏他的方法？

聊天结束后，我又与他的同事们聊了聊最近的一些分歧，他们不断强调这位工程师所提的各种建议中缺少上下文背景信息。

随着我与更多同行的交谈，工程师的问题变得越来越清晰：

工程师很难从多层次的上下文中对问题进行推理。

所有有趣的问题都会跨越多个上下文层：举个具体的例子，一个我遇到过两次的问题：如果一个团队想在公司的技术栈中引入 Erlang 或 Elixir 这样的新编程语言，那么在评估该团队时需要考虑哪些上下文层？

我第一次遇到这种情况是在雅虎，当时我的团队领导引入了 Erlang，这让安全和工具团队大失所望。在我职业生涯的后期，Uber 的一个团队想用 Elixir 实现他们的服务，我也遇到过这种情况。

这里上下文的一些层次是：

项目工程团队要解决的问题涉及协调多个服务器之间的工作Erlang和 Elixir 有许多用于实现分布式系统的有用工具解决问题的团队有一位经验丰富的 Erlang 工程师，团队的其他成员对学习该语言感到非常兴奋开发人员经验和基础设施团队有固定的预算来支持整个工程组织每一种额外的编程语言都会减少对整个组织中更常用的编程语言的投资。这使得该组织在每次支持新的编程语言时都会认为基础设施组织的效率较低，因为平均而言它的效率较低。该团队告诉基础设施，他们将负责通过引入Erlang创建的所有非典型工作。然而，基础设施团队以前就听说过这个承诺，并且在这些团队重组后经常最终拥有新语言的工具。在这一点上，他们相信任何使用新编程语言的项目都会成为他们的问题，无论团队如何大力宣称它不会工程领导希望将创新预算投入到对用户重要的问题上，而不是引入通常相当于现有工具的新技术正在管理高度有限的财务预算，并试图在不影响稳定性和生产力的情况下最大限度地提高产品工程的预算支出。引入新语言与这一目标背道而驰需要标准化的招聘和培训流程，重点关注尽可能少的编程语言因团队试图引入新的编程语言而苦恼，但最终因缺乏对该语言的基础设施支持而受阻

在我的职业生涯中，两次遇到这个具体问题给了我很大的启发：

因为第一次引入一种新的编程语言似乎是个不错的主意。第二次，我的上下文堆栈已经扩大，我坚定地推翻了这个决定。

在我目前的高管职位上，引入另一种编程语言是不可能的，因为这违反了我们的工程战略：

项目团队中的中级工程师没有基础架构视角的某些部分。基础架构团队的中级工程师也会忽略产品工程视角的某些部分。

要成为一名成功的 "员工+"工程师，就必须跨越这些上下文层进行感知和推理：既要看到产品和基础架构的视角，也要了解（或知道询问）领导层的视角。

如何跨多上下文视角？在任何指定的角色中，你都会缺少关键的背景知识来扩展你对周围各层次的理解。最好的情况是，你的同事和经理会花时间解释这些层次的背景，但他们往往不会这样做。

例如，我花了很长时间才理解公司的财务计划如何与我们的规划流程相联系，部分原因是没有人向我解释过。

一般来说，人们都沉浸在自己的上下文中，以至于没有意识到这对其他人来说是多么的不直观。

如果你想增强对周围其他层面的上下文感知，以下是我发现的一些最有效的技巧，可以帮助你发展自己的上下文：

出于好奇而不是信念来运作。当别人说的东西对你来说没有意义时，几乎总是因为他们在某一层运作，而你缺少了这一层的背景。当你对别人的观点感到困惑时，与其试图说服他们他们错了，不如试着去发现那一层及其背景。这种视角越资深越有价值轮换到其他球队。如果您在平台工程部门工作，请与您的经理合作，在使用您的平台的产品工程团队中工作三个月。每隔几年这样做一次，以加深你对不同团队如何看待相同情况的理解参加销售电话并查看客户支持。跳出工程设计的视角，直接了解最终用户，是跳出上下文层的有效方法，而你的大部分时间都是在上下文层中度过的在不同类型的公司和行业工作。专注于某一特定垂直领域（如金融科技或市场）有很多好处，但在职业生涯中涉猎一些不同的行业也同样有价值。通过了解其他垂直行业，你会更好地理解自己花时间最多的行业的特别之处。同样，加入一家大公司也能更好地了解初创企业的特别之处，反之亦然。最后，建立广泛的网络。建立一个广泛的同行网络是借鉴他人来之不易的背景的最简单方法，而不会受到公司内部矛盾和政治的干扰。特别是要挖掘你对某一主题的看法可能是错误的原因，而不是寻找你可能是正确的原因

这些都需要时间，老实说，我花了整整十年的时间才掌握了感知和上下文背景层的能力。事实上，这也是阻碍我在初入职场时担任更高级职位的最大障碍。

激情可能会让人盲目与许多基本领导技能一样，跨上下文层感知是一个显而易见的想法，但很多人在实施过程中却举步维艰。缺乏好奇心是我看到的最常见的阻碍人们理解这一点的挑战，但最困难的障碍却有点不直观：太在乎。

我遇到过很多非常聪明的工程师，他们非常在意以某种方式解决特定问题，这种方式通常能完美地解决他们所处的上下文层的问题，但他们却完全无法意识到其他上下文层的存在。

例如，我曾与一位高级工程经理共事，他一直对自己没有得到晋升感到不满，同时还威胁说，如果我们不引入他们喜欢的新笔记工具，他就辞职不干。我们的知识库中已经有大量的笔记，如果再引入一个新的知识库，我们的知识就会更加支离破碎

这是我们在开发人员工作效率调查中经常出现的前三大问题。

作为一个曾经为此苦苦挣扎的人，我发现分三个阶段解决问题很有价值：

专注于了解其他各方的观点进入学术评估模式，我非常努力地从纯粹的智力基础上思考问题只有在完成这两种方法之后，我才会将自己的感受带入决策中——我实际上认为最好的方法是什么？

这种方法的要点不是拒绝我的感受和观点，因为我知道这些是做出有效决策的重要组成部分，而是确保我不会让我的感受蒙蔽了我对可能性的认识。我越来越相信，大多数隐含的权衡都是人为的——只要你花时间了解当前的情况，你真的可以鱼与熊掌兼得。这种方法帮助我最大限度地发挥精力解决整个问题，而不是卷入问题参与者之间的冲突。

明显还是不明显？如果你觉得 "有许多上下文层 "这个想法太明显，可以先不考虑这个想法，因为也许你已经很善于考虑手头的观点了。（banq注：陷入了当前上下文而不自知，身在庐山不识庐山真面目）

但是，如果你经常发现自己与同事或领导不和，那么就花点时间对照你最近的一些冲突来检验一下这个想法，看看它是否可能是冲突的根源。对于与我共事过的一些才华横溢的人来说，这是他们在茁壮成长为高级领导者之前需要学习的最后一课。