AI-Native GTM Teams
Posts I and II walked the diagnosis and the architecture. This is the operating piece — who owns what, what changes about roles when the context layer lands, and how leaders move teams through the transition without losing the people who built the business.
This piece is in progress. The skeleton is here so the build pipeline, graph data, and wiki citations are ready. Prose goes in next.
AI adoption is a leadership problem, not a tooling problem
[Draft section — to write.]
The piece opens by extending Posts I and II: the conditions are clear (context availability + task clarity), the architecture is buildable (layered context, vault → schema → system-of-record). The remaining question is human. Who runs each layer. Who's accountable when the AI gets it wrong. Who's promoted on AI fluency. Who gets retrained, who gets reorganized.
This is where AI adoption stops being a tooling decision and starts being a leadership decision — about what the team should look like, what skills compound, and what kinds of work the org rewards.
The build/run split
[Draft section — to write.]
A handful of operators have written the operating shape down already. The pattern is consistent: a small build/run split with builders configuring the layers, MCPs, skills, and maintenance rituals, and runners consuming what gets built. The build team is small. The run team is the entire GTM org.
Reference points to draw from:
- Tom Wentworth's incident.io GTM team — five people running a full enterprise marketing stack on Claude Code + Cowork, with an explicit builder/runner split.
- Jordan Crawford's Cannonball methodology — time-boxed, embedded engagements where the build team transfers capability to the internal team before they leave.
- Kyle Norton's Owner.com — 50% human, 50% AI agent revenue teams by end of 2026, running the playbook in public.
Roles, redesigned
[Draft section — to write.]
What changes for each role:
- AE / Account Executive — the deal owner still owns the deal. What changes: pre-call prep is AI-drafted, account research is AI-pulled, follow-ups are AI-composed. The AE's job moves from production to review and judgment.
- BDR / SDR — outbound at scale, AI-personalized. The IC's job moves from researching prospects to setting target lists and reviewing/improving the AI's targeting.
- PMM — owns L2, the canonical schema. The job moves from drafting decks once to maintaining the source-of-truth from which AI generates every variant.
- Demand gen — owns the campaign substrate. AI handles the variant generation; the IC owns the strategy and the read on what's working.
- Sales engineering — the role that benefits earliest. Engineering-style task clarity already exists; AI accelerates demo prep, RFP responses, proof-of-concept scaffolding.
- RevOps — owns L3, the system of record. The role expands from "keep the CRM clean" to "keep the substrate the AI reads from clean."
The leader's job is to pick which transitions happen first, who pilots them, and what success looks like before scaling.
Moving the team through the transition
[Draft section — to write.]
The hardest part isn't designing the new roles — it's moving the team you have through the transition without losing the people who built the business. The piece closes on the leadership choices that decide whether transformation feels like an opportunity or a threat to the people inside it. Hiring, training, internal mobility, what gets celebrated, what stops being celebrated.
What comes next
[Draft section — to write.]
The reader has the diagnosis (Post I), the architecture (Post II), and the operating model (this piece). The piece closes with a clean handoff to whatever the consulting practice does — a workshop invitation, a diagnostic, or a conversation. To be written.