SKILL.md
context-not-control（情景管理而非控制管理）
R — 原文摘录 (Reading)
"不要告诉员工应该做什么，而是应该通过讨论来设置情景，达成一致，最后让他们自己去做出正确的决定。"
I — 诠释理解 (Interpretation)
情景管理用"提供决策所需的信息"替代"告诉别人该做什么"。这不是放任自流，而是通过充分的信息共享让团队自主做出正确决策。
四个前提条件：
- 高人才密度 — 你必须信任他们的判断力
- 创新导向目标 — 追求创新而非防范错误
- 松耦合组织 — 团队能够独立运作，无需层层审批
- 共同理解 — 所有人对齐同一个北极星目标
树模型（Tree Model）：
- CEO（根）→ 设定全局情景（使命、愿景、战略方向）
- 高管（干）→ 添加战略情景
- 经理（枝）→ 添加运营情景
- 知情指挥（叶）→ 做出最终决策
关键思维转变： 当员工犯错时，不要责怪他们——问自己"我在情景设置上哪里出了问题？"修复情景，而不是修复人。
A1 — 过去应用 (Past Application)
- 16 岁儿子隐喻： 控制模式 = 审批他能参加哪些派对、安装手机追踪器。情景模式 = 教育他了解危险（酒精、毒品、鲁莽驾驶），然后信任他的判断。后者才能真正培养决策能力。
- 《Mighty Little Bheem》的成功： 这是一个 4 层情景级联的典型案例。Reed Hastings 设定全球战略（"进军印度市场"），高管添加战略情景（"投资本土原创内容"），经理添加运营情景（"寻找印度动画合作伙伴"），Aram Yakubian 作为知情指挥做出最终决策——买下这部动画。结果成为 Netflix 全球排名第一的动画节目。整个过程没有层层审批，只有情景传递。
- 新加坡 5 年规划事件： 设施经理询问 Reed 关于未来 5 年的人员增长预测（用于办公空间规划）。Reed 没有责怪他提了错误的问题，而是意识到这是情景传递的缺失——Netflix 的核心理念是灵活而非可预测。Reed 将此加入季度业务回顾（QBR）议程，确保所有人理解"灵活性优先于可预测性"。
A2 — 未来触发 (Future Trigger)
以下场景触发此技能：
- 用户正在微观管理团队（审批每一个决定）
- 用户询问"如何在不失控的情况下赋能员工"
- 用户是创始人瓶颈——所有决策都需要经过自己
- 用户想从命令控制型管理转向自主团队
- 用户抱怨下属"不会独立思考"
- 用户引用 Netflix 的管理理念
- 用户在快速扩张中遇到管理带宽不足
E — 执行步骤 (Execution)
步骤 1：检查前提条件
在实施情景管理之前，逐一确认：
- 人才密度够高吗？ 如果团队中有很多平庸 performer，你需要先提升人才密度
- 目标是创新导向的吗？ 如果核心目标是防范错误（如合规、安全），控制模式可能更合适
- 组织是松耦合的吗？ 如果每个变更都需要多个团队协调，情景管理的效果会大打折扣
- 是否有共同理解？ 团队是否对齐了同一个北极星？
步骤 2：用情景替代指令
- 不要说"做这个"，而是分享：战略目标是什么、背后的假设是什么、潜在风险是什么
- 通过讨论达成一致（alignment），而非通过命令达成服从（compliance）
- 使用树模型逐层传递情景：确保每一层都添加了属于自己层面的上下文
步骤 3：用"修复情景"替代"责怪人"
- 当员工做出错误决定时，克制责怪的冲动
- 问自己："我在情景设置上哪里出了问题？我遗漏了什么关键信息？"
- 修复情景（补充信息、澄清优先级），而不是修复人（批评、惩罚）
- 将这次经验纳入未来的情景传递中
B — 边界与限制 (Boundary)
- 不适合安全关键型操作： 医院、航空、核电站等场景中，一个错误可能是致命的，控制模式不可替代
- 不适合紧耦合组织： 如果组织架构中一个团队的变更会级联影响多个团队，情景管理的独立性优势无法发挥
- 人才密度低时不可用： 如果团队还没有达到高人才密度，需要先解决人才问题（参考" keeper test"）
- 组织架构转换极难： 作者的盲点——从紧耦合转向松耦合在实践中极其困难，这个模式在组织设计之初就植入效果最好
- 不是放任自流： 情景管理不等于"不管了"，而是用信息共享替代审批控制。管理者仍需持续投入时间进行情景传递