011:校准(Calibrations)过程中的情境崩塌问题
011: Calibrations Have a Context Collapse Problem
Old School Burke
2025年4月24日 — 阅读时长9分钟
注意: 本文所表达的观点和意见仅代表作者个人,并不一定反映作者雇主的官方政策或立场。
什么是情境崩塌(Context Collapse)?
情境崩塌发生在当为特定受众设计的内容被多个受众同时消费时,每个受众都带着自己的参照框架和期望。最初用于描述社交媒体动态,指的是消息在不同社交圈传播时失去其预期情境。(这也是Twitter成为地狱的原因)。
这种现象不仅困扰着我们的社交媒体帖子,也破坏了我们组织中最关键的流程之一:绩效评估。在社交媒体中,代价可能只是误解或尴尬的对话,但在校准(calibration)会议中,赌注是职业生涯、薪酬和团队士气。
我们又来到了那个房间:五张长桌排列成一个正方形,二十五位经理弯腰盯着笔记本电脑,头顶上的灯光闪烁不停……好吧,我只是在编故事——我们大多数人都是在Zoom上参加的。但你明白我的意思吗?今天是校准日。 计划是客观和公平。但多年工程领导经验告诉我,当我们都坐下来时,情境就会开始崩塌。
善意的虚构
理论上,校准应该是一种理智的检查,防止我们进行曲线评分,但通常它只是绩效评估的表演。经理们聚集在一起交叉验证彼此的评估,确保A团队工程师的“超出预期”与B团队工程师的“超出预期”相匹配。
现实呢?它可能变成一个充满竞争的故事时间。
我曾亲眼目睹一位经理就一位工程师在缓存层上的“突破性”工作发表了长达三分钟的热情洋溢的演讲。两分钟后,我意识到我根本不知道这是否真的令人印象深刻,或者只是这位经理恰好是技术推销界的Don Draper。
情境崩塌的实际案例:就像你的社交媒体帖子可能被不同的受众误解一样,当一位工程师的成就被呈现给来自不同领域的经理时,也可能被误解。
情境失真的几个维度
1. 领域特定的盲点
每位经理都专精于某个领域:前端、后端、数据工程、SRE。但在校准期间,专业知识的广度并不会神奇地扩展。而是被稀释。
让我通过一个真实的例子来说明:
反馈陈述: “他们为我们的移动应用构建了一个离线优先功能。”
_真正_发生了什么:
- 实现了具有同步冲突解决的本地缓存
- 设计了一种对不稳定网络具有弹性的重试机制
- 平衡了电池使用与后台同步策略
- 必须处理Android和iOS上的操作系统级别限制
- 与后端协调以公开同步安全的API
但在校准中……
后端经理: “听起来像是API的客户端包装器。不太复杂。” (情境:他们习惯于以数据管道、分布式系统来思考。)
前端负责人: “我们使用 service worker 做过类似离线的事情;真的有那么不同吗?” (情境:Service worker确实有帮助,但它们并不能反映原生移动的复杂性。)
数据工程总监: “这项工作对业务的影响甚至可以衡量吗?看起来像是一个边缘案例。” (情境:他们的世界运行在仪表板和批量作业上,而不是最终用户延迟或离线 UX。)
SRE经理: “这是否触及任何基础设施的可扩展性或可靠性?否则看起来很窄。” (情境:他们关注负载、系统健康状况和事件风险。)
结果: 实际的技术提升被扁平化,可能被低估,或者没有得到支持,仅仅是因为:
- 没有为跨学科受众使用正确的词汇
- 价值没有被翻译成普遍易懂的术语
- 听众的心理模型与工程师的领域不匹配
2. 技术特定的偏见
即使在同一领域内,技术和环境也千差万别。如果你从未构建过流式传输管道,你可能会认为添加实时聚合器是一项微不足道的“几行代码”的工作,而忽略了扩展、成本优化和许多其他因素的细微之处。
我曾经听到一位高级领导将几周的迁移工作轻描淡写为“只是移动一些 yaml 文件”。房间里顿时安静下来。没有人立即纠正他。那种沉默?那是你的工程文化正在慢慢消亡。
这里有另一个例子来说明这一点:
“简单”的数据库迁移
一位后端工程师花费了三个月的时间,小心地将一个关键系统从MongoDb迁移到PostgreSQL。他们的工作包括:
- 创建复杂的数据转换管道
- 确保使用双写系统的零停机迁移
- 构建全面的验证工具
- 通过查询优化解决性能回归
- 实施新的监控系统
在校准期间,一位专注于前端的工程总监将其总结为:“他们将数据从一个数据库移动到另一个数据库。这些天这不大多是自动化的吗?”
这种说法揭示了他们对数据库的心理模型,将其视为可互换的存储容器,而不是具有不同行为、约束和故障模式的复杂生态系统。迁移的复杂性——它避免了潜在的业务中断灾难——完全在翻译中丢失了。
3. 可见性偏见
一个全新的 UI 重新设计会得到截图、演示和高管的关注。一个幕后的可靠性改进只能得到一个简单的要点:“事件减少了 40%。”
消除持续在线问题的工程师可能会为公司节省数百万美元的停机成本,但他们的经理只有 30 秒的时间来解释为什么这很重要。与此同时,构建了一个高管每天都能看到的炫目仪表板的人会得到几分钟的讨论和普遍赞扬。
4. 倡导彩票
老实说,你的评分部分取决于你的经理玩游戏的能力。一位擅长讲故事的经理可以将“修复了一些错误”转化为“通过深入的技术分析和创新解决方案,系统地消除了关键的客户体验问题。”
两位表现相同的工程师,但拥有不同的经理,可能会得到完全不同的评分。就像两位技术水平相当的工程师走进校准会议:一位得到了 TED 演讲的介绍,另一位则只能在饮水机旁小声讲述自己的故事。
5. 锚定效应和沉默的顺从
房间里的第一个强烈的观点会成为引力,其他一切都围绕它旋转。如果一位高级主管说:“我不确定这是否符合‘超出预期’的标准,”你会看到房间里一半的人突然发现地毯上有令人着迷的图案。
我曾见过经理们带着一种评分走进房间,然后随着共识的风吹过房间,逐渐改变立场。我们有一种从众心理,挑战人群中正在形成的共识会让人感到危险,即使我们知道真相。
6. “符合预期”的五十道阴影
每位经理对评分类别的解释都不同。一位经理的“超出预期”是另一位的“星期二”。有些经理设定的标准如此之高,以至于爱因斯坦也只能勉强获得“符合”,而另一些经理则像发会议赠品一样发放“超出”。
在校准中,这些理念会实时碰撞。不同团队的工程师实际上遵循着不同的规则,但却在一个没有人完全同意的单一标准上被评判。
7. 时间挤压
由于经理众多,需要讨论的工程师也很多,而且会议时间有限,因此每个人只有几分钟的时间。一年的复杂基础设施工作变成了:“他们提高了延迟。”没有时间解释如何提高,为什么这很困难,或者它如何启用了三个新的产品功能。
在我的脑海中,这相当于只阅读章节标题来阅读和理解一本小说。我们将复杂的人类所做的复杂工作简化为要点和声音片段。
8. 对增长与影响的不一致
一些经理非常看重工程师的增长轨迹——他们改进或学习了多少——而另一些经理则主要关注对关键业务指标的直接影响。在校准中,这些理念会发生冲突。
工程师X年中加入,迅速上手,并交付了一个成功的试点项目。工程师Y已经工作多年,维护着维持收入流动的关键功能。哪个更有价值?校准可能会演变成关于什么最重要(原始影响还是上升轨迹)的哲学辩论——导致混乱和不均衡的结果。
9. 经理行为的博弈论
也许最阴险的是,校准如何在经理之间产生系统性的行为模式,从而进一步扭曲流程。通过系统思维的视角,我们可以看到系统的结构如何激励特定的行为:
评分膨胀:一些经理系统地将他们的工程师的评分评定为比他们真正认为应该得到的水平高一个级别。他们知道他们的评分可能会在校准中被向下协商,因此他们从一开始就设定较高水平作为缓冲。例如,当他们私下认为工程师完全“符合预期”时,将其评为“超出预期”。这造成了一场通货膨胀的军备竞赛,使得诚实的评估几乎不可能。
战略时机:精明的经理学会了玩转晋升周期本身。他们会比应有的时间提前一个周期(例如,年中而不是年末)让某人晋升,他们知道即使该工程师现在没有获得晋升,他们也会在下一个周期中排在首位——那时他们实际上已经准备好了。这会将校准系统变成一个战略游戏,而不是一个诚实的评估过程。
囤积“证据”:一些经理全年都在隐瞒建设性的反馈意见,而是将其收集起来作为校准的弹药。他们将本应是发展机会的东西武器化,将其变成追溯性的评分理由。这阻止了工程师在问题发生时解决问题,并在评估期间造成有害的意外。
这些行为并非源于“坏经理”,而是自然而然地从系统的结构和激励机制中产生的。当经理根据他们的团队在校准中的表现来评估时,我们不应该感到惊讶,因为他们优化的是游戏,而不是预期的目的。
实际成本
成本不仅仅是压力大的会议或受伤的感情。
- 人才幻灭: 感到被误判的工程师会对系统失去信任。随着时间的推移,这些高价值贡献者会悄悄地更新他们的LinkedIn个人资料。
- 有偏差的职业轨迹: 讨人喜欢和演讲技巧成为职业发展的催化剂。与此同时,有条不紊的、幕后的贡献者会想知道他们为什么要这么做。
- 经理信誉受损: 当你的工程师意识到你更专注于制作叙事,而不是提供准确的反馈时,你就失去了一些宝贵的东西。
- 组织盲点: 校准可以发现系统性问题——资源缺口、技能分配、新兴的团队瓶颈。但很少是关注的焦点。
关键洞察: 情境崩塌不仅会损害个人职业生涯,还会奖励错误的行为,并错过组织学习的机会,从而损害整个工程文化。
打破循环
那么,我们如何解决这个问题呢?真正的问题可能是:我们需要修复校准,还是需要完全重新思考它?
以下是一些可以考虑的方法,按它们解决的问题进行组织:
解决领域和技术偏见
- 创建特定领域的校准: 不要举行一次大规模的会议,而是举行更小型的、以领域为中心的讨论,让合适的专家可以评估合适的工作。
- 实施跨职能的预审: 在正式校准之前,让工程师的工作接受来自不同领域的同行的审查,他们可以将成就转化为自己的情境。
改善情境保存
- 工程师声音和共同创作: 让工程师共同撰写他们的绩效叙述,澄清技术成就和领域挑战。
- 标准化成就格式: 创建模板,确保跨团队对成就的一致表示,减少演示技巧的影响。
识别无形贡献
- 专用认可轨道: 为可靠性、指导、文档和其他难以量化的贡献创建特定的认可类别。
- 影响故事工作坊: 培训经理如何有效地沟通无形工作的影响。
使校准更具连续性
- 实施持续校准: 用季度性审查代替年末的表演,以防止近因偏差,并允许更准确的实时见解。
- 将反馈与评估分离: 创建一种系统,让经理提供频繁的、发展性的反馈,这些反馈与绩效评估没有直接关系,从而减少了“保存”反馈以进行校准的动机。
解决系统性游戏行为
- 审核通货膨胀模式: 如果你是一位高级领导,请审查跨团队的评分通货膨胀模式,并解决系统性问题,而不是只关注个别案例。
- 为晋升创建安全失败路径: 设计晋升流程,使“尚未”结果不会惩罚工程师或经理,从而减少了战略时机游戏的动机。
- 关注价值观而不是结果: 评估经理不仅要看团队的绩效,还要看他们如何体现你希望看到的反馈和发展价值观(而不是他们如何玩校准游戏)。
系统思维的视角: 正如 Donella Meadows 所说,“不要责怪球员,改变游戏规则。”与其试图阻止经理玩游戏,不如重新设计系统,使游戏行为无法获得回报。
试试这个: 在你的下一次校准会议上,要求经理用完全不属于他们领域的人能够理解的术语来解释他们每位报告的成就。这个简单的练习可以突出显示通常会损失多少情境。
适应细微差别
校准应该是我们防止主观性的保障,一种公平的制度机制。但以其目前的形式,它往往适得其反,将复杂的工作过度简化为整洁的、堆栈式排列的叙述。
好消息是?我们有能力停止将我们的工程师扁平化为要点。
第一步是承认工程工作的内在复杂性,并且这种复杂性无法压缩到半小时的讨论中。我们需要欢迎细微差别、鼓励更深入的对话,并奖励可能被忽视的真正重要工作的流程。
正如我们越来越意识到情境崩塌如何影响我们的社交媒体存在一样,我们需要认识到它如何破坏我们的组织流程。
两者之间的相似之处非常惊人:
社交媒体情境崩塌 | 校准情境崩塌 ---|--- 不同的受众以不同的方式解读相同的帖子 | 不同的经理以不同的方式解读相同的工作 个人帖子被专业联系人看到 | 技术工作受到非技术标准的评判 消息在跨越情境时失去细微差别 | 工作在被总结时失去复杂性 最响亮、最具争议的内容会受到关注 | 最炫目、最容易展示的工作会受到认可 用户学会玩转算法以获得可见性 | 经理学会玩转校准以获得更好的结果
因为如果组织只庆祝那些炫目的、容易谈论的或可以在 60 秒内推销的东西,我们最终会得到一个由伟大的推销员组成的团队,以及可能平庸的建设者。
让我们把目标定得更高。让我们建立一种看到完整情境的文化,而不仅仅是标题。
最后的思考: 如果你下个季度参加校准会议,请问自己两个问题:“我是在捕捉这位工程师工作的真实故事,还是仅仅是符合模板的故事?”以及“我是在玩游戏,还是真的在为我的团队的成长服务?”我们提出的问题越多,我们就越接近真正理解我们组织中的人,而不是将他们的故事崩溃成堆栈式排列的列表的校准流程。
- Share on Twitter
- Share on Facebook
- Share on LinkedIn
- Share on Pinterest
- Share via Email
- Copy link
Old School Burke
Old School Burke Newsletter
Join the newsletter to receive the latest updates in your inbox. Your email address Subscribe Please check your inbox and click the link to confirm your subscription. Please enter a valid email address! An error occurred, please try again later.
Related Posts
31 Mar 2025
010: Don’t Panic: Unblock yourself first
Unblocking yourself is part of the learning journey. When you get stuck, resist the temptation to type “Help!” immediately and run. Try these steps first: * Give your brain a chance to self-solve * Dive into existing docs or knowledge bases * Tinker, test, and experiment * Reach out methodically, with strong context, only
© 2025 Old School Burke