224: Keith Jones How OpenAI’s GTM leader structures teams and spots standout candidates

• OpenAI 把 GTM Systems 重新集中到 CFO 体系下的 Enterprise Platform Technology（EPT），不是因为某个抽象的组织设计理论，而是因为分拆后出现了两个成本中心。 Salesforce 下游财务数据、ERP、计费等工作需要 Systems 靠近 Finance；但一半团队留在 GTM、一半迁入 EPT 后，咨询资源、工具预算和 headcount 都要跨成本中心反复协调。新任 CRO Denise Dresser 需要在 account director 等直接收入岗位与 Systems 编制间做选择，最终支持 Systems 整体迁出 GTM，使预算责任和系统责任重新一致。
• 迁入 Finance 不等于远离业务；OpenAI 用“组织集中、业务协同”的双层结构解决张力。 GTM Ops 继续留在 GTM，负责吸收 stakeholder 需求并形成清晰要求；GTM Systems 集中负责 Salesforce、集成、数据、权限与技术交付。双方通过一个约 6–7 人的双周会议对齐优先级，先用 5–10 分钟写下各自“最睡不着的问题”，再寻找重叠和分歧。Keith 因此更新了“离钱近”的定义：不仅靠近产生收入的人，也要靠近预算控制者和全公司支出视角。
• Agent 没有消灭专业分工，而是重构了分工：TPM 提供清晰业务上下文，资深工程师负责审查，agent 承担可规模化的 junior developer 劳动。 Keith 的团队保留 Enterprise Systems Manager 与 Software/System Engineer 两类画像。前者定义需求、里程碑和 ticket；后者判断代码质量、系统完整性与错误影响。没有 pre-Codex 开发经验的人可以告诉 agent “做什么”，但很难判断它在 Salesforce 等生产系统里“做得对不对”。
• Harness Engineering 与 Symphony 的价值不是一次性自动写代码，而是把错误转化为可复用的组织知识。 清晰 ticket 触发 Symphony，agent 读取 harness 中的代码库结构和规范，写代码并提交 PR；工程师发现错误后，不只是手工修复，而是写成新 skill，让下次同类需求不再犯错。Keith 称已有 contractor 入职不足 30 天就能交付与在公司两年员工相同类型的变更，但前提是版本控制、DevOps、repo、权限和非生产环境开发早已到位。
• AI 越能放大产出，人的判断与协作越成为瓶颈。 团队用“安全处快、关键处慢”区分可逆和不可逆决策；拒绝为了技术才华招聘 brilliant jerks；在招聘中用候选人的问题、真实观点以及“人做了什么、模型做了什么”的透明度来识别差异。OpenAI 的 GTM 在约两年内从不足 100 人扩到接近 1000 人，使 Keith 不得不快速训练决策节奏，也迫使他承认：有些决定因响应过快而做错，高认知负荷必须用恢复和物理断连来管理。

贯穿全场的核心线索是：AI 提升的是组织杠杆，不会替组织补齐基础。 当 agent 能大量生成代码与内容之后，真正稀缺的不是“多做一点”，而是让预算归属、角色边界、工程规范、权限控制、审查能力和人的协作共同形成一个不会失控的系统。

核心要点：OpenAI 没有把 Marketing Ops、RevOps、GTM Ops 的名称争论当成组织设计起点，而是用责任链来划分工作。GTM Ops 是业务需求的第一接触面，GTM Systems 是系统完整性和技术交付的最终责任人。

• GTM Ops 直接服务不同销售 segment、增长和 GTM 领导者。它们持续吸收一线需求，把业务语言整理成 Systems 可以执行的“干净要求（clean requirements）”。Keith 把这个角色称为 GTM 组织的“心跳（heartbeat）”：如果缺少这层翻译，Systems 只能猜业务真正需要什么。
• GTM Systems 负责 Salesforce、集成、扩展性、后端技术工作与相关基础设施。它并不替业务定义目标，而是把已经澄清的业务要求变成稳定、可扩展、能被治理的系统能力。
• 两者边界会因 Codex 等工具变得更模糊。GTM Ops 可以更直接地处理数据、生成初步方案，甚至参与部分技术工作；但“谁保证系统不会被破坏、权限不会越界、生产质量可以接受”的责任仍留在 Systems。
• Keith 不否认组织中仍存在 Marketing Ops、RevOps 等群体，但认为标签本身的重要性低于结果。对管理者而言，真正的问题不是团队叫什么，而是 stakeholder work、requirements、technical delivery 和 accountability 是否有明确所有者。
• 这种分工也解释了为什么 GTM Ops 留在 GTM、GTM Systems 可以迁到 EPT：前者需要保持一线业务接触，后者需要对跨部门平台和技术治理负责。两者组织归属不同，并不等于价值链断裂。

“Go-to-market ops is really the heartbeat of the go-to-market organization.” —— Keith Jones

核心要点：OpenAI 最初拆分 GTM Systems，是为了同时满足财务集成和业务贴近性；最终重新合并，是因为共享一个交付面却分属两个成本中心，导致预算、供应商和编制持续错位。

故事起点是 Salesforce 的下游财务数据。OpenAI 需要加速 ERP、billing 和其他财务系统集成，最直接的组织方案是把 GTM Systems 整体迁入更靠近 Finance 的组织。但团队担心：一旦与 GTM 形成组织距离，是否还能及时响应快速变化的商业需求？因此采取折中方案——把更靠近 Finance 议题的人迁入 EPT，另一部分继续留在 GTM。

技术上，这个安排完成了若干重要集成；管理上，它逐渐暴露出一个非常朴素的问题：同一组工作由两个成本中心供给。

• 同一家咨询公司的资源需要被拆到两边；工具预算要判断由 GTM 还是 EPT 支付；共享能力却要分开解释投入。
• headcount 摩擦最明显。Denise Dresser 加入 OpenAI 担任 CRO 后，需要重塑 GTM 组织，也需要新增 account director 和其他更直接产生收入的角色。Systems 的岗位虽然影响收入，却难以在同一预算讨论里与前线收入岗位竞争。
• Dresser 对 Systems 整体迁出没有表现出明显阻力。她的判断是：Systems 即使不在 GTM，也必须继续支持 GTM，并且仍然可以被业务问责；但她不必再在“多招收入岗位”与“多招系统岗位”之间进行不必要的内部竞争。
• Keith 因此强调，重新集中并不是证明所有 distributed model 都错误。在结构更稳定、节奏更慢的公司，分布式 Systems 可能有效；但 OpenAI 的产品、组织和商业模式持续变化，两个优先级体系和两种工作方式会把协调成本放大。

重新合并也不是简单恢复旧组织。团队没有回到“Keith 一个人管理所有方向”的窄金字塔，而是设置了更扁平的双负责人结构：一位同级负责人聚焦 quote-to-cash 和直接收入链路；Keith 聚焦 top-of-funnel 数据丰富、售前/售后工作流与 support systems。组织吸收了分拆期的学习，而不是否认那段经历。

分拆阶段还提供了一项反事实验证：如果 Systems 在两个组织中仍能共享同一套工作面，理论上可以同时获得两边视角；但实际运行中，视角收益没有覆盖协调代价。团队面对的不只是“多开几场会”，而是每个资源决定都要回答归谁出钱、由谁排优先级、失败由谁承担。OpenAI 的变化速度使这些问题无法靠年度规划一次性解决，几乎每次新增需求都会重新触发。因此，Keith 的结论不是“集中制天然优越”，而是当任务高度耦合、底层平台共享、预算频繁变化时，组织边界必须与责任边界尽量一致。

“It was just so wildly practical.” —— Keith Jones 对重组原因的概括

核心要点：GTM Systems 进入 CFO 体系的价值，不只是获得预算，而是让系统负责人能在资源决策发生处代表内部客户；Systems 仍服务 GTM，但不再只能从 GTM 单一视角解释投入。

• Keith 过去长期相信系统团队应该“be very close to the money”，并把 money 理解为 revenue generation：靠近销售、营销和业务 stakeholder，便于快速捕捉需求。
• OpenAI 的实践让他更新了模型。离钱近也意味着靠近实际预算、银行账户和控制支出的人；这些人能看到整个公司资源流向，而不是只看到某一条收入链路。
• 这一点对高变化环境尤其重要。公司仍然有年度预算和支出预测，但新产品、新组织负责人和新业务会带来预算周期内无法预见的投入。访谈当时，Denise Dresser 在预算设定后才加入，意味着“新 CRO、新愿景、新能力需求”都需要在既有预算外重新讨论。
• GTM Systems 的资源最终仍服务 GTM，部分支出也仍来自 GTM 预算；区别在于 Keith 能靠近战略财务伙伴，作为内部客户的连接组织（connective tissue），直接解释为什么出现新的、此前无法规划的支出。
• 这套判断不意味着所有 GTM Systems 都应该向 CFO 汇报。Keith 的结论有明确适用条件：团队负责跨部门核心应用、财务数据链路和 agent 访问治理；公司又处于高速度、预算经常变化的阶段。若 Systems 仍主要承担局部销售工具配置，迁入 Finance 可能只会增加距离。

维持业务贴近性的机制是一场双周优先级会议。参会者约 6–7 人，包括 Keith、另一位 GTM Systems 负责人、负责 EPT 的管理者，以及 Growth、GTM Ops、RevOps 等 stakeholder 的资深领导。会议不是先看一张固定 roadmap，而是让每个人用 5–10 分钟写下当前最关心的问题，再讨论重叠、分歧和跨团队资源。这使 Systems 在组织上集中，却不失去 GTM 的实时信号。

“My baseline mental model … had always been: be very close to the money.” —— Keith Jones

核心要点：OpenAI 把 IT 与 Enterprise Platform Technology 分开。IT 负责全公司基础设施与访问底座，EPT 负责具体业务应用和工作流；Agent 时代要求后者同时治理应用、动作和权限。

• IT 位于 CISO 相关体系，负责全球基础设施，包括 access management、网络、硬件、会议室等常被组织忽略但不可中断的能力。各业务团队可以管理部分具体授权，但全局底座由 IT 维护。
• EPT 更像内部的 forward-deployed business systems 组织。它负责人员系统、供应链、收入系统等特定核心应用及第一方工作流，目标是让业务能快速使用，而不必自己承担系统完整性风险。
• Keith 所描述的成熟化不是把所有动作重新塞回 Salesforce UI，而是把底层系统“硬化（hardening）”：数据结构稳定、权限正确、可调用动作清楚、接口适合 agent 使用。
• 例如，销售人员未来可以直接在 Codex 里要求更新 Salesforce pipeline，或创建管理 pipeline 的 dashboard；即便不打开 Salesforce UI，其身份权限、可写字段和允许执行的 action 仍必须与系统规则一致。
• 团队因此持续维护 Salesforce MCP 等接口中的 published actions 与 permissions。Agent 只是新的交互入口，不是绕过既有治理的捷径。

这也是“headless CRM”讨论的组织含义：当交互层逐渐从传统 UI 转向自然语言，价值重心会从页面布局转向数据质量、权限、API 和系统稳定性。候选人若只会描述一个更漂亮的界面，可能仍停留在旧问题；能提前看到“UX 变轻、data 和 hardening 变重”的人，更接近未来的 Systems 角色。

“We are heavily focused on ensuring that even if they’re not using the UI of Salesforce … their permissions are in line.” —— Keith Jones

核心要点：Agent 能缩短从要求到代码的距离，却不能取消业务定义和专业审查。Keith 的团队保留两类人类角色，并把 agent 放在两者之间承担高杠杆执行。

• Enterprise Systems Manager 类似 technical product manager。理想画像是在系统架构、平台或某个业务域中积累多年，能与 GTM Ops 共同理解需求、拆里程碑、定义清晰验收条件，也能交付一部分系统工作。
• Software/System Engineer 负责更深的代码、集成和平台工程，也负责审查 agent 或 TPM 产生的 PR，确保代码质量、数据完整性和系统后果可控。
• Keith 认为少数人能在两类能力上都有足够深度，但不能以此作为普遍组织假设。若强行把所有要求都压到“既懂业务、又能写生产代码、还能治理 agent”的单一岗位上，团队会因稀缺人才而无法扩展。
• 他把 agent 类比为 intern 或 junior developer。Junior developer 的价值不在于永远只能做简单任务，而在于有 senior developer 给予上下文、审查结果并修正错误模式。
• 没有 pre-Codex 开发经验的人仍能指示 agent 产出内容，但难以识别 agent 生成代码中的典型 junior 错误，也难以判断这些错误在 Salesforce 权限、自动化或数据模型中会造成什么后果。

这套三层结构改变了“技术产品经理与工程师是否会融合”的答案：两者的执行边界确实变模糊，TPM 可以借助 agent 产出更多技术成果；但审查责任没有消失，反而因产出速度提升而更重要。AI 让更多人能写代码，不等于更多人能判断代码。

对岗位设计而言，这意味着不能把“会用 Codex”简单写成新能力要求后，就缩减资深工程师。Agent 把实现速度向上推，PR 数量和变化频率也随之上升，审查吞吐与风险判断会成为新的约束点。TPM 的价值也不是被压缩成写 prompt，而是把模糊业务诉求变成可验证、可交给 agent 的任务：边界、依赖、验收标准和失败条件必须比过去更清楚。两类角色都在升级，而不是一类吞并另一类。

“That entity … is an intern and junior developer. What’s the best way to make a junior developer successful? Give them a senior developer to teach them.” —— Keith Jones

核心要点：Symphony 的核心不是自动起草一个 PR，而是形成“要求—生成—审查—写 skill—再生成”的复利回路；harness 则提供 agent 必须继承的组织上下文。

Keith 用一条具体工作流解释团队如何做 generative code orchestration：

1. Stakeholder 或 TPM 把需求写成足够清晰的 ticket，包括具体目标、动作位置和验收要求。

2. 工程师加上标签，触发 Symphony 流程。

3. Coding agent 读取 harness：代码库结构、团队标准、既有组件、哪些内容应放在哪个位置。

4. Agent 完成主要编码工作并起草 PR。

5. 工程师审查 PR，判断结果是否正确、哪里像 junior developer 的常见错误。

6. 若出现可复现的错误，工程师不只修这一处，而是新增 skill：以后遇到同类条件，不要采用错误做法，应采用指定做法。

7. 回滚并重新执行。Agent 不再犯同类错误，skill 也会服务后续所有相似需求。

过去，Systems 负责人需要把业务要求一直翻译到技术实现细节：写哪个 Apex class、搭哪个 flow、如何配置对象。现在，人仍需把业务语言翻译为足够清晰的技术上下文，但不必每次重新描述全部实现路径，因为 harness 已经保存团队标准和当前系统状态。

Keith 给出的结果很有冲击力：一些 contractor 入职不足 30 天，就能交付与在公司两年员工相同类型的变更。这不是 contractor 瞬间拥有两年业务经验，而是组织把大量隐性知识放进 harness 和 skill，使新成员与 agent 从第一天就继承既有约束。

但他对前提非常强硬：

• 必须有规范的版本控制 repo 和 DevOps 流程；
• 必须把标准写入 harness，而不是依赖口头传承；
• 必须有人具备足够工程经验，能审查 agent 输出；
• 不能直接在生产环境里“边试边改”。

因此，Symphony 不是用来绕过工程纪律的自动化工具，而是把既有纪律规模化。如果基础混乱，agent 只会更快地复制混乱。

“You don’t get away with this building in production. Those days are over … I refuse to soften my stance on that.” —— Keith Jones

核心要点：决策速度应由可逆性和失败后的清理成本决定。Agent 能降低部分执行成本，却不会自动降低错误数据模型、权限设计或跨系统依赖的返工成本。

• 新增一个字段通常可快速执行，但仍需检查是否与现有字段重叠、是否必须持久化、能否从其他来源虚拟读取。完成最低限度判断后，如果可轻易回滚，就没有必要投入过量脑力。
• 引入新的数据 schema、为新业务建立整片对象和关系则不同。它会影响集成、权限、历史数据和后续流程，即使有 agent 辅助，迁移与清理成本也很高，因此应在决定前放慢。
• Keith 的判断公式很直接：如果做错，修复要多久？需要多少人？会不会影响不可逆数据？答案决定决策所需时间，而不是外部对“速度”的抽象期待。
• 他用“挤果汁”的比喻说明：如果一个决定后续需要投入很大的 grip strength，先确认 juice worth the squeeze；否则只是用快速决策制造一个高成本清理项目。

团队对“闪亮方案”的健康怀疑也是同一原则。一位 stakeholder 带来第三方供应商方案，供应商声称只需约 30 分钟即可完成；实际进入系统后，团队做了 4 周仍未结束，因为隐藏的依赖和细节远超演示。问题不在 stakeholder 的需求不合理，而在于组织把演示中的简单性误认为生产系统中的简单性。

“Fast where it’s safe. Slower where it counts.” —— Keith Jones 的团队原则

核心要点：AI 提升同规模团队的产出后，人类成员更集中在定义问题、协同决策和审查结果上；这使合作质量成为生产系统，而不是文化装饰。

• Keith 明确表示，团队不为才华或复杂能力牺牲 chemistry 和 harmony，也就是“不招 brilliant jerks”。一个人即使技术很强，如果会持续破坏合作，就没有组织位置。
• 这不等于要求团队完全没有摩擦。不同工作风格、意见冲突和适应成本属于正常的人类协作；管理者需要区分“可通过沟通和 coaching 调整的摩擦”与“以能力为理由反复伤害他人的行为”。
• Agent 能让同一批人完成过去更多的工作，因此人类成员之间需要更高质量的协同：TPM、工程师和 stakeholder 必须共同解释需求、判断风险、审查结果，并持续把学习写回系统。
• 如果一个 brilliant jerk 成为审查或协同链路的核心节点，他造成的沟通损耗会被更高的机器产出量同步放大。AI 不会抵消负面协作，反而可能放大其影响范围。

这条原则也与“不追逐 shiny solution”相连：团队需要能相互挑战、对供应商叙事保持健康怀疑、在不确定时公开说“还没弄清楚”。如果组织只奖励最快给答案的人，agent 与 vendor 都会让“看起来完成”更容易，真正的系统风险却被推迟暴露。

“If you’re brilliant at what you do, but you’re going to be a jerk to everybody you work with, then I don’t have a place for you in my org.” —— Keith Jones

核心要点：当数百名候选人都用同类模型改写履历，格式和措辞迅速同质化。Keith 用招聘 prompt、候选人的问题和贡献透明度，筛出仍能代表自己的人。

Keith 在招聘帖中加入一项具体任务：给出一个关于 AI-native GTM tech stack 的、尖锐、有争议、面向未来的 hot take。这项设计同时检验三件事：候选人是否读完岗位说明、是否能形成独立判断、是否能把判断表达清楚。

• 只发“我对岗位感兴趣，我做过 X/Y/Z”的信息，Keith 会认可其诚意，但在大量申请中难以形成区分。
• 如果信息以“hot take -”开头，他会优先阅读，因为候选人直接回应了岗位要求，也把思考放在履历之前。
• 一些候选人提出“UX 不重要，data 和 hardening 更重要”等判断。措辞可以争议，但方向预判了后来 headless CRM、自然语言交互与 API-ready 系统的趋势，因此获得进入面试流程的机会。

进入 hiring manager screen 后，Keith 也不先按固定问题逐项询问。他通常先花 10–15 分钟说明角色、为什么现在招聘、团队情况，然后要求候选人根据这些信息主动提问。候选人的问题决定后续访谈路线：有人追问 agent skill 模型，有人先问薪酬，两者透露出的关注点和好奇心不同。Keith仍有标准筛选项，但会根据问题自然调整问法，避免一小时面试的前 40 分钟只交换模板化信息。

面对 AI 生成申请，他的原则不是“禁止 AI”，而是“不要让 agent 代表你”。他回忆 pre-LLM 时代的一封自动化邮件：用户在晚上或周末注册后，系统会以销售人员名字发信，但邮件明确写着——这不是本人刚刚写的，而是因为你在我通常不在线时注册，由系统代我自动发送。透明度没有削弱自动化，反而建立信任。

Keith 建议候选人采用同样方式：明确写出哪些内容由自己完成，模型负责了哪些格式、措辞或结构工作，自己又如何基于模型输出做判断。如果 cover letter 中最重要的观点确实由本人写，就直接说明“ChatGPT did not write this”。真正的差异化不是假装没有使用 AI，而是让 hiring manager 看见人的推理、经验和选择。

这套做法也改变了“注意细节测试”的性质。过去，招聘帖中藏一个问题，主要检验候选人是否完整阅读；现在，同一问题还要检验候选人能否越过模型最容易生成的平均答案。Keith 并不因为候选人使用 AI 就直接否定申请，他要找的是模型无法替代的证据：一个来自真实经历的判断、一项愿意承担争议的立场、对系统未来状态的预判，以及能继续追问的好奇心。候选人提出的问题因此比标准化自我介绍更有区分力，因为问题暴露了他如何选择信息、如何构建因果关系、下一步想验证什么。

“We have to remind ourselves that we’re representing ourselves and not the agentic version of ourselves.” —— Keith Jones

核心要点：Keith 在 OpenAI 学到的关键能力不是某项工具，而是快速区分“现在就能决定”与“必须放慢”的事项；这种判断来自高频真实反馈，也包括承认自己曾经做错。

• Keith 加入 OpenAI 时，GTM 组织不足 100 人；访谈时已接近 1000 人，扩张大约发生在两年内。产品、组织和 stakeholder 需求同时变化，使 Systems 面对的决策数量与速度远高于普通成熟公司。
• 2023 年末至 2024 年初，新同事加入时，他反复提醒：要尽快形成判断——哪些事情可以马上答应，哪些事情必须“踩刹车”，进行更审慎的分析。
• 这种能力不能只靠阅读 reversible/irreversible 框架获得。高速度环境不断给出真实后果，使管理者更快建立模式识别。
• Keith 没有把高速决策浪漫化。他明确承认自己做过错误决定：有些事情响应 Slack 太快，后来发现应该先停下来思考。错误不是速度文化的例外，而是校准判断所支付的成本。
• 因此，OpenAI 对他的最大训练价值不是品牌或技术光环，而是组织环境本身：大量决策、不断变化的条件、快速暴露的结果，迫使人建立更准确的速度感。

这也回到组织归属问题。若一个高速度团队还需要跨两个成本中心、两套优先级和两种工作方式才能做决定，协调成本会直接侵蚀判断时间。重新集中 GTM Systems，本质上是把有限的管理注意力从内部谈判转回业务与系统风险。

“There are decisions I made so quickly that were not the right ones.” —— Keith Jones

核心要点：Keith 把耐力运动的强度管理迁移到知识工作：高功率区间只能短时维持，恢复决定下一轮判断质量；靠延长工作时长维持输出，会增加错误而非价值。

• Keith 是耐力运动者。他用骑行 zone 5/zone 6 类比高强度认知工作：身体只能短时间维持高功率，之后必须恢复；思维虽然不同于肌肉，但仍受疲劳、饥饿和睡眠影响。
• OpenAI 的工作需要持续处理高复杂度和高变化问题，Keith认为自己不能靠每天 12 小时以上的 endless hustle 长期维持决策质量。他需要在合理时间主动离开工作。
• “离开”不只是一项意愿，而是一套物理动作：关闭显示器、拔下并收起键盘、断开笔记本与显示器。每一步都增加重新开始工作的摩擦，使边界不依赖当下意志力。
• 工作之外仍可做有认知挑战的事情，例如尝试 vibe-code 健身应用、研究 Garmin 与 Apple Watch 数据；关键是切换问题类型，而不是让工作系统无限延伸到所有时间。
• 休息后重新回来，运动、家庭和其他活动可能为工作提供新视角。恢复并不与高绩效冲突，而是避免疲劳状态下把“应当放慢”的决定误判为“马上处理”。

这一段不是访谈的附加生活方式话题，而是前述决策框架的闭环：组织可以设计再好的预算归属、harness 和权限，如果负责人长期处于认知透支状态，最终仍会在错误的事情上过快行动。

“When I decide I’m done working, the monitor is turned off, the keyboard is unplugged, the keyboard is put away.” —— Keith Jones