• LinkedIn
• Twitter
• Instagram
• YouTube
• RSS Feed

Apple •Spotify• Pocket Casts •Youtube •Overcast •RSS

What’s up everyone, today we have the pleasure of sitting down with Keith Jones, GTM Systems Lead at OpenAI.

Summary: Keith walks through the full restructuring journey of the GTM org at OpenAI and how GTM Systems ended up under finance. He shares his interview process, the two archtypes that make up his team as well as his filter for separating human candidates from AI-generated applications. If you work in and around GTM and RevOps or just want to understand what operating at 10x growth actually requires, this one is worth your time.

In this Episode…

• What Separates GTM Ops from GTM Systems
• Why OpenAI Moved Its GTM Systems Team Back Under a Single Budget Line
• Why GTM Systems Teams Gain More Budget Control Under Finance Than Under Revenue
• The 2 Profiles Every GTM Systems Team Needs in the Agentic Era
• How OpenAI Orchestrates Agentic Code Deployment with Symphony
• How to Decide When to Move Fast vs Slow on a GTM Systems Team
• How to Stand Out in Job Applications When Everyone Is Using the Same AI Tools
• What Building at OpenAI’s Velocity Teaches You About Decision-Making
• How an Endurance Athlete Mindset Applies to Cognitive Work

About Keith

Keith Jones is GTM Systems Lead at OpenAI, where he leads the team responsible for the tools, platforms, and technical infrastructure behind the company’s go-to-market motion.

He began his career across sales ops and marketing ops roles before joining Mural, where he built and led the GTM Systems function. He later served as Senior Director and Analyst at Gartner, covering revenue technology, before moving to OpenAI.

Just a quick disclaimer that Keith is joining the podcast as Keith the technologist and human, not the employee at OpenAI. The views and opinions he expresses in this episode are his own and do not represent OpenAI.

What Separates GTM Ops from GTM Systems

The naming debate in martech ops has been running so long it’s almost a genre. Marketing ops, revenue ops, GTM ops, GTM systems; the titles keep multiplying and nobody agrees on where one ends and the other begins. If you’re in this function, you’ve had the conversation. In job interviews. In org design meetings. In budget justifications. It goes nowhere, and it keeps happening.

Keith has a more useful framing. When he first came on the show, he drew a clean line. GTM ops handles process design, training, and the frontline support that keeps the humans in your GTM org running. GTM systems owns the tools, the technical infrastructure, the back-end work: Salesforce, integrations, scaling, the stack. That line still holds. But he’s added something that makes it more useful than a job description.

“go-to-market ops is really the heartbeat of the go-to-market organization, they’re the ones that provide to us really clean requirements of what we need to do”

They’re the ones in the room with every sales segment leader, every functional head, absorbing what the business actually needs and translating it into something buildable. Without that translation layer, a systems team is guessing. And guessing at OpenAI’s pace doesn’t go well.

At OpenAI, both functions have kept evolving alongside the company. Denise Dresser came in as CRO with a complete vision for reshaping the go-to-market org. B2B marketing got folded in. The company launched ads. The org changed repeatedly and fast. Through all of it, the underlying logic held: GTM ops partners with the business, GTM systems delivers what that partnership requires.

As for the labels, Keith’s position is that they’re the wrong thing to anchor on. At OpenAI, the specific titles of marketing ops or rev ops matter less than who owns the stakeholder work and who owns the technical delivery. The names on the teams are almost secondary. The friction comes from not having clarity on which team does which job and what flows between them. Most organizations that treat these two functions as interchangeable tend to find out why that’s a problem the hard way.

The clean requirements that GTM ops provides to GTM systems aren’t a process nicety. They’re what keeps a systems team from building the wrong thing at the wrong pace.

Key takeaway: Draw a line in your own org between who owns stakeholder requirements and who owns technical delivery. If one person or team is carrying both, something is consistently slipping. Establish a regular meeting rhythm where GTM ops and GTM systems leaders hash through priorities together, and treat that handoff as seriously as any technical dependency.

Back to the top ⬆️

Why OpenAI Moved Its GTM Systems Team Back Under a Single Budget Line

OpenAI’s GTM systems team didn’t move under finance because someone had a grand theory about org design. They moved because of a cost center problem. And the cost center problem showed up in the most unglamorous way possible: headcount.

The original case for moving was practical. Keith’s team needed to accelerate a set of deep financial integrations: Salesforce data flowing into ERP systems, billing pipelines, downstream finance reporting. The work required close collaboration with the finance function. The initial plan was a wholesale move. What the org settled on instead was a compromise: split the team. Some engineers stayed under go-to-market. The rest moved into what OpenAI calls Enterprise Platform Technology (EPT), the org that reports to the CFO. On paper, the logic held. In practice, the friction started almost immediately.

2 separate cost centers sharing an overlapping team create problems that don’t announce themselves upfront. They surface sideways:

• 2 separate budget owners with different priorities pulling the same engineers in different directions
• Shared consulting firms split across orgs, with different teams allocating the same people to different workstreams
• Tooling budgets that required negotiation across reporting lines rather than a single decision
• Headcount competing directly against a new CRO’s vision for building out the go-to-market org

That last one is what forced the decision. Denise Dresser joined as CRO after budgets were already set, bringing a complete vision for reshaping the go-to-market org and the headcount requirements to execute it. Keith found himself competing against her priorities for resources from the same finite pool. The arrangement happened by math, not design: 2 leaders sharing 1 budget.

“it was our CRO who didn’t offer even a shred of detraction from the proposal that we move over. It wasn’t even a conversation. She was like, ‘Yeah, go.’ Like, I know you’ll continue to support us. I know I can hold you accountable. But I can’t sit here and try to decide between revenue-generating roles and your roles.”

The conversation was brief. Dresser knew Keith’s team would keep supporting go-to-market regardless of which org they sat in. She knew she could hold him accountable. But she couldn’t justify choosing between revenue-generating hires and systems resources from the same budget line when the answer was that obvious.

The reunified structure looks different from what existed before. Keith now has a peer leading quote-to-cash and revenue-adjacent systems. Keith owns top-of-funnel data enrichment, pre- and post-sale workflow, and the support systems org. The org got flatter, the division of responsibility got cleaner, and the cost center competition disappeared.

How GTM Systems and GTM Ops Stay Aligned After the Split

GTM ops stayed under the go-to-market umbrella when GTM systems moved to EPT. The obvious question: how do they stay connected? Keith’s answer is a biweekly meeting he calls the most productive hour on his calendar. 6-7 people in the room from both sides of the new org boundary:

• Keith and his peer leading go-to-market systems
• The manager running all of Enterprise Platform Technology, including people systems, supply chain, and revenue systems
• The most senior leaders from growth, go-to-market ops, and rev ops

No prep deck. No pre-circulated agenda. Everyone spends 5 to 10 minutes writing down their top of minds: what’s keeping them up at night, what’s shifted, what needs cross-functional attention. Then the group talks through where priorities overlap, where they’re diverging, and which teams need to be working together on something they’re currently doing separately.

It’s not a status meeting. It’s a priority alignment session with people who have the authority to act on what comes out of it.

The distributed period was hard. It was also clarifying. The experience exposed exactly which parts of the operating model depended on shared reporting structure and which parts could survive without it. The biweekly session is what replaced the assumptions the old org chart used to carry. For most GTM systems teams navigating similar structural tensions, that’s the practical takeaway: cost center structure shapes decision-making speed more than almost anything else, and when two teams share a surface area but report up through different budget owners, the overhead of that arrangement compounds faster than most people expect.

Key takeaway: Audit the cost center structure between your GTM systems team and its primary budget owner. If your team is competing for resources against the very stakeholders you support, that structural friction will keep surfacing as misaligned priorities regardless of how well the individuals involved are working together. If reunification isn’t on the table, build a standing joint priority session with your most senior GTM stakeholders; run it as a decision-making forum, not a status update, with the people who actually have authority to act on what comes out of it.

Back to the top ⬆️

Why GTM Systems Teams Gain More Budget Control Under Finance Than Under Revenue

Ask most GTM systems leaders where their team belongs in the org and they’ll say: close to go-to-market. Close to the revenue motion. Close to the stakeholders who are selling and building pipeline. Keith held that view for most of his career. He called it a core mental model: be close to the money. What changed at OpenAI was how he defines “the money.”

“My baseline mental model around org structure and systems had always been be very close to the money,” he says. “What was interesting, though, is that I had always codified that in my mental model as be close to generating revenue. But where my model has now been updated is that I am being close to the dollars, to the bank account, to the people who control our budget.”

“my baseline mental model around org structure and systems had always been be very close to the money. I had always codified that as be close to generating revenue. But where my model has now been updated is that I am being close to the dollars, to the bank account, to the people who control our budget.”

The distinction matters more than it sounds. At a company like OpenAI, where budget cycles get disrupted constantly by organizational changes, new leaders, and product moves that nobody planned for, sitting close to finance gives Keith something a GTM reporting line never could: a direct channel to advocate for his team’s resource needs in real time. When unplanned expenditures show up (and they always show up), he’s not waiting for a budget justification to travel up through the GTM chain. He’s already in the room with the people making the call.

That advocacy role has become a meaningful part of the job. Keith describes himself as providing connective tissue between his internal GTM customers and the strategic finance partners embedded in the org. When Dresser joined after budgets were set and the go-to-market org needed to reimagine itself, Keith was positioned to help facilitate conversations about new expenditures that no one could have forecasted during the prior year’s planning cycle.

IT versus Enterprise Platform Technology: 2 Different Groups

1 thing that trips people up when Keith describes his org: “finance and IT” sounds like a single destination. It’s 2 distinct groups with different mandates, different leaders, and almost no overlap in what they own.

	IT	Enterprise Platform Technology
Led by	CISO	Reports to CFO
Focus	Global infrastructure	Core business applications
Owns	Networking, hardware, access management, meeting rooms	Business-specific tools, third- and first-party workflow, agentic access governance
Keith’s team	No	Yes

IT handles the infrastructure that everyone in the company relies on and mostly takes for granted: the network, the hardware, the access management layer that controls who can log in to what. Keith calls it the unsung heroic work. EPT is something different. Keith describes his group as an internal forward-deploy business systems org, focused on maturing and hardening the specific platforms that go-to-market and other internal teams use to operate.

A big part of that hardening work right now is making OpenAI’s core business applications agentic-ready. A seller should be able to go to Codex and ask it to update their Salesforce pipeline in plain language. But “agentic-ready” means the underlying permissions are correct, the right actions are published, and the agent can only do the things it’s authorized to do. Keith’s team maintains a continuously developing list of published actions and permissions through the Salesforce MCP, so that when someone uses Codex to interact with the stack, they’re operating within guardrails the systems team built and controls.

For GTM systems leaders watching the market move toward agentic go-to-market workflows, the EPT model represents a specific organizational bet: the team that governs the systems also has to govern the access layer for everything that runs against those systems. Separating infrastructure governance from application governance, which most orgs do by default, creates a gap that becomes expensive when agents start operating at scale.

Key takeaway: Reframe your own mental model of where GTM systems belongs in the org. If your primary argument for staying under the GTM umbrella is closeness to stakeholders, audit whether you’re actually close to the budget decisions that shape what you can build. Document your team’s current published actions and permissions for any AI-accessible system in your stack, Salesforce especially, before your stakeholders start using agents to interact with data your team owns.

Back to the top ⬆️

The 2 Profiles Every GTM Systems Team Needs in the Agentic Era

If you’ve looked at the job postings on Keith’s LinkedIn, one requirement stands out: developer or software engineer background required. No exceptions, no equivalent experience considered. For a GTM systems team that deals with Salesforce architecture, data enrichment, and lead-to-opportunity workflow, that requirement raises a reasonable question: what about the people who’ve spent a decade as power users, platform architects, and Salesforce admins without writing production code?

Keith’s answer: he already has those people. They’re on the team. He just doesn’t need to hire more of them right now. His org today is built around 2 distinct profiles, and he’s explicit about why both are necessary and why very few people can actually do both jobs.

	Enterprise Systems Manager (TPM)	Systems Engineer
Background	Platform architect, systems architecture experience	Developer with pre-Codex Salesforce or systems experience
Main job	Requirements gathering, milestone planning, stakeholder liaison with GTM ops	Implementation, PR review, writing agent skills
Agent interaction	Informs what agents should build	Reviews what agents actually produce
Critical quality	Translating business context into clear technical requirements	Knowing what good output looks like and what should have been done differently

In an ideal workstream, the TPM is the one in the room with go-to-market ops. They absorb stakeholder requirements, translate them into technical milestones, and hand that clarity off to the engineering side. The engineer takes those requirements and builds. The line between those 2 jobs has always been porous in practice; most GTM systems leaders have stretched across both at various points in their careers. But as agents enter the picture, the roles don’t merge. They get more distinct.

“unless you have spent time in a pre-Codex world writing software, writing code in systems like Salesforce, understand some of the implications of that, you’re not going to be effective on reviewing something that an agent has written.”

That’s what Keith’s engineers are doing. Agents are generating PRs. The TPM has written a crisp ticket. The agent has done the legwork. But someone has to review what the agent produced: catch the mistake a junior developer would make, figure out why it happened, and write a skill that prevents it from recurring. That someone needs to have spent real time in a pre-Codex environment writing production code in systems like Salesforce, understanding what correct output looks like and what the implications are when something goes wrong.

This is the part of the agentic transformation that gets undersold. The conversation tends to center on what agents can now do. The less visible question is who’s qualified to judge whether they did it right. “Unless you have spent time in a pre-Codex world writing software, writing code in systems like Salesforce, understand some of the implications of that,” Keith says, “you’re not going to be effective on reviewing something that an agent has written.” A TPM-only team can tell agents what to build. It takes an engineer to tell whether what came back is correct.

For GTM systems leaders staffing up in the current environment, the relevant planning question isn’t which of these 2 profiles to prioritize. It’s whether you have enough of both to run the model: enough TPMs to keep requirements crisp and enough engineers to keep the agents building the right things. The gap between what agents can write and what they should write is exactly the gap the engineering side has to close.

Key takeaway: Map your current GTM systems team against these 2 profiles and identify where you have gaps. If you have strong platform architects but no one with production code experience in your core systems, you can tell agents what to build but you can’t reliably review what comes back. Prioritize hiring or developing at least 1 engineer with pre-LLM Salesforce development experience before you build agentic workflows into your delivery process.

Back to the top ⬆️

How OpenAI Orchestrates Agentic Code Deployment with Symphony

For the last decade or more, the GTM systems leader’s core job was translation. A stakeholder would come in with a business requirement (change the stage automation, add a new data field, update the enrichment logic) and the systems leader would convert that into technical language: the Apex class to write, the flow to build, the exact configuration to deploy. The technical knowledge lived with the human. The agent was the human.

That translation job still exists. What’s changed is how far down the technical stack the translator needs to go.

Keith’s team has open-sourced 2 tools that sit at the center of how they operate now. The first is harness engineering. The harness is the infrastructure that a coding agent needs in order to know where to slot things in: the structure of the codebase, the standards the team has established, the context that turns a vague requirement into a buildable instruction. Without the harness, an agent writing Salesforce code is writing blind. With it, the agent knows your conventions and can follow them.

The second is Symphony, which orchestrates the whole generative code deployment process. When a ticket is crisp enough, the workflow runs like this:

1. A stakeholder or TPM creates a ticket with clear, specific requirements
2. An engineer applies a label that kicks off the Symphony process
3. Symphony uses the harness to orient the agent within the codebase and its standards
4. The agent writes code and drafts a PR
5. The engineer reviews the PR, identifies what the agent got right and what it missed
6. If the agent made a mistake, the engineer writes a new skill to prevent that mistake from recurring
7. The agent runs again and doesn’t make the same mistake, and that skill applies to every future requirement that hits the same pattern

The compounding effect is the part that’s hard to appreciate until you’ve seen it. Every skill the engineer writes makes the agent better on the next similar requirement. The harness carries institutional knowledge that would otherwise sit in a human’s head. New team members, including contractors, inherit that context from day one.

“I’ve got contractors who within less than thirty days of being with the business are shipping the same changes as someone who’s been here for two years is doing. Think about that. That is an acceleration in productivity that has not been heard of in a technical landscape before.”

That result requires prerequisites. Keith is direct about this. The harness and Symphony work because the team built the discipline that makes them possible, and that discipline has to exist before the tooling gets introduced.

The prerequisites Keith considers non-negotiable:

• A proper version control repo with disciplined DevOps practices already in place
• No building in production: “those days are over, at least they should be, and I will refuse to soften my stance on that”
• Clear standards encoded in the harness that the agent can follow
• Engineers with enough pre-Codex experience to review agentic output and recognize when something has gone wrong

If those conditions exist, the harness and Symphony let a systems team leapfrog into agentic delivery without spending years building toward it. If they don’t, introducing agentic code deployment just accelerates the accumulation of technical debt. The 30-day contractor result is real. But it’s downstream of years of building the right foundation.

For the martech and GTM systems ecosystem, what Keith’s team has open-sourced represents something worth studying beyond the tooling itself. The model they’ve built treats agents as a layer between requirements and delivery, with human engineers responsible for improving the quality of that layer over time. That framing shifts how you think about what your GTM systems team is actually building, and who on that team creates the most leverage.

Key takeaway: Before adding agentic code generation to your GTM systems workflow, run a prerequisite audit: do you have a proper version control repo, clear coding standards documented, and engineers with enough production experience to review what agents produce? If the answer to any of those is no, build the foundation first. If yes, explore OpenAI’s open-sourced Symphony repository as a reference for how to structure the orchestration layer; the harness and skills model it uses is directly applicable to Salesforce-based GTM systems teams.

Back to the top ⬆️

Your buyers are already asking ChatGPT about your brand. Do you know what it’s saying?

Every day, ChatGPT, Claude, Gemini, Perplexity decide which brands get named, which pages get cited, and which products gets recommended—often before a buyer ever lands on your site.

Scrunch makes your brand the answer. We’ll show you how AI talks about your brand today, where the citation gaps are, and the page-level fixes that put you back in the answer.

Curious what it says about your brand?

→ See how AI reads my site

How to Decide When to Move Fast vs Slow on a GTM Systems Team

Team principles are easy to write and hard to live by. Most of them sound good on a slide and disappear during a hiring crunch or a deadline. The ones Keith posts on his job listings are different because they’re operationally specific: constraints that shape actual decisions rather than aspirational values that evaporate under pressure. Two of them in particular say something concrete about how he runs the team.

Reversible Decisions Move Fast, Irreversible Ones Need Time

Keith didn’t invent this principle. He borrowed it from other leaders whose thinking he respected and made it his own. The core is simple, but the application is where most teams fall short: how much time you spend on a decision should be proportional to how hard it would be to undo.

In practice, this creates 2 completely different operating modes depending on the type of change on the table:

Decision type	Examples	Approach
Reversible	Adding a new field, tweaking an automation, minor configuration changes	Move fast, minimal deliberation: do a quick sanity check and ship
Irreversible	Rearchitecting a data schema, introducing new objects to represent new business models, major platform migrations	Take real time: map the consequences, think through what happens when things go wrong, don’t be rushed by urgency

Keith’s framing for the irreversible side: “the juice is gonna be worth the squeeze, but you also know that you’re gonna have to put some serious grip strength into that squeeze.” When the work is hard to undo and the labor required is significant even with agentic assistance, the cost of a fast wrong decision gets paid later in cleanup and rework. At OpenAI’s pace, that’s not a hypothetical cost. It’s a predictable one.

No Brilliant Jerks and No Shiny Solutions

The no-brilliant-jerks principle sounds obvious until you examine why it matters more now than it did 3 years ago. As agents take over a larger share of the actual execution work, the humans on a GTM systems team spend proportionally more time on the work that requires real collaboration: scoping requirements together, reviewing each other’s calls on agentic output, making judgment calls on what to prioritize. A brilliant jerk is a liability in that environment in a way they weren’t when everyone was heads-down on their own individual workstream.

“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 at my org.”

Working-style friction is different. Keith is clear that friction between people is normal; that’s different from what he’s actually screening against. What he’s screening against is someone whose talent comes bundled with behavior that makes it harder for the people around them to do good work. In a team where the leverage increasingly comes from how well the humans collaborate around the agents, that’s a load-bearing distinction.

The no-shiny-solutions principle is the operational complement. It sounds like common sense and gets violated constantly. Keith’s current example: a stakeholder came in with an ask that seemed straightforward. A vendor had told them it would take about 30 minutes to implement. Keith’s team is 4 weeks in and not done yet. The requirement turned out to be substantially more complex than the sales demo suggested, as requirements often do when a vendor is selling the demo version of their product.

His test for a vendor claim or a new solution: “Is it really shiny, or am I gonna rub that off and have nothing but a dull finish underneath of it?” The skepticism he’s describing is the discipline of pressure-testing the easy sell before you commit your team’s time to implementing it, not reflexive resistance to new tools. The 30-minute estimate that turns into 4 weeks is one of the most reliable patterns in GTM systems work, reliably caused by evaluating the demo rather than the underlying complexity.

Key takeaway: Build a simple decision log that categorizes every change request as reversible or irreversible before work begins. For any irreversible change, require a written consequence map: what breaks if this goes wrong, and how hard is it to fix, before approving the work. Before committing to any vendor evaluation or new tool, run a pre-mortem on the best-case timeline the vendor gave you and ask what would have to be true for that estimate to be accurate.

Back to the top ⬆️

How to Stand Out in Job Applications When Everyone Is Using the Same AI Tools

The volume problem in hiring right now is real. A role goes up for a GTM systems position at a company with recognizable brand equity, and within 24 hours there are hundreds of applications. Most of them went through the same process: take the job description, take the resume, feed both to ChatGPT, ask for a personalized cover letter. The output is polished, competent, and completely indistinguishable from 800 other applications that did exactly the same thing.

The Hot Take Filter and How Keith Runs His Screens

Keith’s solution is a prompt buried in the job posting. His most recent version asks candidates for their most pointed, controversial, forward-looking AI-native opinion on GTM tech stacks. If you don’t answer it, your application gets treated like any other generic message. If you start your DM with “hot take:” followed by an actual take, you’ve already separated yourself from the stack.

Most candidates answer it, he says. The gravitational pull of the OpenAI brand pushes people to read closely. But the filter also does something beyond sorting for attention to detail: it’s a semantic sort that shows up immediately in his inbox. A message that opens with credentials is easy to skip. A message that opens with a take is a message that makes a claim, and a claim that’s specific and forward-looking is a signal that someone has thought about the problem domain.

The hot takes that earned candidates interview time weren’t necessarily the most provocative ones. They were the ones that anticipated where things were heading. A few people called out something Keith’s team was already working toward: in a world where agents interact with your systems conversationally, the UI layer matters less than the data layer and the hardening layer. “UX doesn’t matter. Data matters. Hardening matters.” That kind of take (specific, unfashionable in some quarters, directionally correct) is what gets a response.

Once someone is in a screen, Keith runs his opening the same way every time. He gives the candidate 10 to 15 minutes of context (the role, why it exists now, what the team looks like) and then says: ask me questions based on what I just told you. The questions they ask steer the rest of the conversation. He has a set of screening criteria he’s working through, but he adapts how he gets there based on what the candidate’s curiosity shows about them. A candidate who asks about the agent skills model he mentioned in passing is a different conversation than a candidate who asks about compensation.

Represent Yourself, Not Your AI

The deeper problem in AI-era job applications is that candidates are letting the AI represent them instead of using it as a tool and then representing themselves.

“we have to remind ourselves that we’re representing ourselves and not the agentic version of ourselves”

Keith’s model for what good looks like draws from a pre-LLM example. At a previous company, the inbound automation he built would send a near-real-time email to new free trial signups, even on nights and weekends. The email came from a person’s name. But it included a line that said: “I didn’t write this email. This is fully automated, sent on my behalf because you signed up when I’m not typically online.” That explicit transparency (here’s what the human did, here’s what the system did) is what he thinks candidates should apply to their own applications.

The differentiation he’s describing is about showing your work. Specifically:

• State what you did versus what the model did; don’t blur the line
• Call it out explicitly: “ChatGPT did not write this. Claude did not write this. I wrote this.”
• If the model helped with formatting, phrasing, or structuring your resume, say so, and make your own thinking the visible layer
• Treat the application itself as a demonstration of how you use AI as a tool rather than a replacement for your own judgment

That last one is what Keith is actually testing for. He’s looking for people who can show the seam: who understand the difference between their reasoning and the model’s output well enough to make it explicit. In a role where your job is to govern how agents operate inside business systems, that distinction is the job.

The candidates who stand out in the AI era are the ones who can show you where the human ends and the tool begins, and make that visible without being prompted to.

Key takeaway: If you’re applying to GTM systems roles right now, write a cover letter or outreach DM where you explicitly state what you wrote and what the model helped with. Then add a specific, forward-looking take on something in the GTM tech stack that you think is genuinely undervalued or misread. Make it specific and contestable. If you’re hiring, add a specific prompt to your job posting that requires a directional opinion, and run your hiring screens by leading with context and then asking candidates to ask you questions.

Back to the top ⬆️

What Building at OpenAI’s Velocity Teaches You About Decision-Making

When Keith joined OpenAI, there were fewer than 100 people in the go-to-market org. Today there are close to 1,000. That growth happened in roughly 2 years. Most companies don’t reach that headcount in a decade. The systems implications of that trajectory are almost impossible to explain to someone who hasn’t been inside it.

When new colleagues joined in late 2023 and early 2024, Keith told them the same thing: the most important skill you need to develop, as fast as possible, is the ability to distinguish between the decision you can make right now and the decision that needs more time. At a company growing that quickly, the volume of inbound decisions is constant and the stakes vary enormously. Getting those 2 categories mixed up is where the expensive mistakes live.

Keith makes that point as someone who’s made those mistakes. He’s speaking from direct experience. “There are decisions I made so quickly that were not the right ones,” he says. “Turns out I should have slowed down and thought about that a little bit more before just heeding that Slack message or making that decision.”

“There are decisions I made so quickly that were not the right ones. Turns out I should have slowed down and thought about that a little bit more before just heeding that Slack message or making that decision.”

The operating model he’s describing (index quickly on what to act on immediately versus what to slow down for) is the same principle as the reversible/irreversible framework he applies to his team. But at OpenAI’s pace, the skill of calibrating that in real time is less of a framework and more of a reflex that has to get built through experience. You can read about it. You can even practice it. But the actual muscle develops under conditions where the volume and velocity are high enough that the wrong calls happen fast enough to be corrective.

That’s what he says OpenAI provides that nowhere else does right now: the operating environment itself, not the technology, the brand, or the product. The sheer rate of organizational change, product evolution, and stakeholder pressure creates a training condition for decision-making judgment that most GTM systems careers never encounter. Most companies move slowly enough that you can compensate for a poor decision framework by just being careful. At OpenAI, careful isn’t a substitute for calibration.

Key takeaway: Start a personal decision log and categorize each significant call you make as either a fast-and-right, fast-and-wrong, or slow-and-deliberate decision. Review it monthly. The goal isn’t to move slower overall; it’s to build the pattern recognition for which decisions deserve more time before you make them. The calibration only develops if you track your errors with enough specificity to learn from them.

Back to the top ⬆️

How an Endurance Athlete Mindset Applies to Cognitive Work

A year ago, Keith’s answer to the happiness question was that fulfillment requires 2 things: problems that challenge your brain and time that protects your energy. Both of those are still true. What’s changed is how much more deliberate he’s had to be about the second one.

When you’re managing GTM systems at a company that went from fewer than 100 people in go-to-market to close to 1,000, the cognitive load doesn’t distribute evenly across the day. It arrives in waves and doesn’t always let up. Keith is an endurance athlete, a cyclist and runner, and he applies the same physiology-based logic to his mind that he applies to training.

On the bike, zone 5 and zone 6 output (maximum power, maximum effort) can only be sustained for a short period before the body physically shuts it down. The mind works differently, but the body is still part of the equation. “I get tired, I get hungry, I get sleepy,” he says. The cognitive load of his role at OpenAI can’t be sustained indefinitely, and trying to sustain it indefinitely doesn’t produce better work; it produces worse decisions made by someone who needed to recover hours ago.

“when I decide I’m done working, the monitor is turned off, the keyboard is unplugged, the keyboard is put away, the laptop is disconnected from the monitor. I have to create some friction there.”

The friction is deliberate. Keith has noticed that without physical barriers between himself and work, the boundary doesn’t hold. So he creates it mechanically. When he’s done:

1. Turn off the monitor
2. Unplug the keyboard
3. Put the keyboard away
4. Disconnect the laptop from the monitor

Each step adds friction to the act of going back. The monitor being off is easy to reverse. The keyboard being unplugged and put away is harder. The laptop disconnected from the monitor is harder still. By the time he’s completed all 4, the activation energy required to return to work is high enough that he actually doesn’t. That’s the design.

He’s not prescribing this for anyone else. The logistics of recovery look different for every person. What he’s describing is the principle underneath the specifics: without a deliberate mechanism for stopping, the cognitive load of a high-velocity role fills every available hour by default. The mechanism has to create friction on purpose, because the work won’t do it for you.

Outside of work, he’s trying to vibe code a fitness app, still experimenting, going in several directions, not yet sure what he’s building. The point isn’t the output. His brain still wants good problems. It just needs them to be different problems, with stakes low enough that a wrong call on a Tuesday evening doesn’t cost anyone anything.

Key takeaway: Design a physical shutdown sequence for your workday that creates real friction between you and going back to work. The specific steps matter less than the fact that they’re sequential, physical, and slightly annoying to reverse; that’s the mechanism. If you’re in a high-cognitive-load role, treat recovery the way an endurance athlete does, as a prerequisite for sustainable output rather than a luxury. Recovery is what determines the quality of your decision-making tomorrow, not how many hours you work today.

Back to the top ⬆️

Episode Recap

Keith Jones makes one central argument across this episode: the decisions that shape a GTM systems team’s effectiveness are almost always structural rather than technical. Where the team sits in the org determines what budget conversations they can have and who they’re competing against. Whether a decision is reversible determines how fast it should move. Whether a hire is a brilliant jerk determines whether the human collaboration that holds the agentic layer together actually functions. The technology changes. The organizational math stays roughly constant.

The restructuring story is the spine of the episode and more instructive than it first appears. The GTM systems team didn’t move under finance because of a grand theory about optimal reporting lines. They moved because 2 teams competing for the same budget and headcount is an arrangement that creates friction in every direction, and eventually a CRO who was being asked to choose between revenue-generating hires and systems resources said the obvious thing: just go.

The Symphony and harness engineering section represents something worth taking seriously beyond the tooling specifics. The model Keith’s team has built treats agents as a delivery layer between requirements and output, with engineers responsible for improving the quality of that layer over time. The result (contractors shipping equivalent changes in under 30 days) is real, but it’s downstream of years of building DevOps discipline, proper version control, and engineers who understand the systems they’re asking agents to write code for. The open-source tooling is accessible. The prerequisites are the work.

The hiring section is where the episode gets uncomfortable in a useful way. Keith describes the AI-era job application problem as a representation problem: candidates who let AI represent them, rather than using AI as a tool and representing themselves, produce applications that are indistinguishable from each other regardless of how strong the underlying candidate might be. His solution is low-tech and immediately usable: ask for a real take, run the screen by leading with context and asking candidates to drive, and be explicit about what you wrote versus what the model helped with.

Even someone who has built a principled decision-making framework makes wrong calls. Keith says directly that there were decisions he made too quickly at OpenAI that he’d take back. The operating environment there (a company that went from fewer than 100 to close to 1,000 people in go-to-market in roughly 2 years) doesn’t give you a soft landing for calibration errors. That’s also what makes it the kind of environment that builds the reflex faster than anywhere else could. The sheer velocity is the teacher.

You can follow Keith on LinkedIn where he shares open roles, team principles, and his own takes on where GTM tech stacks are heading.

Full episode ⬇️ or Back to the top ⬆️

✌️

—
Intro music by Wowa via Unminus
Cover art created with Midjourney (check out how)

Apple •Spotify• Pocket Casts •Youtube •Overcast •RSS

Related tags

See all episodes

Future-proofing the humans behind the tech

Apple •Pocket Casts•Google •Overcast •Spotify •Breaker •Castro •RSS

• LinkedIn
• Twitter
• Instagram
• YouTube
• RSS Feed