创新团队两种失败模式

GitHub Next 是一个应用科学家/研究科学家组成的团队，专注 3-5 年时间尺度的问题（"不是想现在，而是想软件开发的未来会是什么样"），写论文、跑实验、做 POC。Copilot 就出自这个团队。

她总结了此类团队最常见的两种失败模式，以及 GitHub 的应对：

1. 变成"大学"：团队只顾写论文、发表研究，但成果从不真正走向生产环境——如果从第零天就没有想清楚"这个想法怎么落地到产品里"，它很难跨过从研究到量产的门槛。
2. 被过度工具化/短期化：公司把这类团队当成"六个月内必须交付一个东西"的加急工程队，本质上变成了另一个执行 Horizon 1 任务的产品/工程团队，丧失了探索远期问题的初衷。

GitHub Next 的应对方式是在两个极端之间找平衡：一方面给团队真正的自由和带宽去探索、允许大部分实验失败（"fail forward"）；另一方面刻意制造与产品、工程团队的强连接和高频讨论，确保创意有路径流向真实产品，而不是被束之高阁。她强调创新本身不应该被过度结构化（"如果每天给你 15 分钟去有创意，这不现实"），比起流程设计，更重要的是团队的人和心态（right people, right mindset）以及是否真的鼓励这种思考方式。

配套机制：（1）持续大量与客户、开源社区交流，很多创新想法直接来自客户的抱怨和诉求；（2）内部允许任何团队"提案"（pitch idea + 一份研究性文档），再决定资助方式（专项预算、POC、临时 V-team 等），保持灵活而非固定流程。