The GTM Loop: build the workflow, not the org chart

Fix a stretched GTM team by running one loop on your worst workflow, not by hiring the org chart.

Who it is for: An operator or GTM leader whose team is stretched and whose first instinct is to add a role.

The problem: When GTM is stretched, the reflex is to hire. Right now that hire is the GTM Engineer. A title does not fix a system that was never designed. You add a person to the org chart while the problem stays in the work. A bad handoff does not get cheaper with headcount. It gets more expensive, because now a salaried person is doing it by hand.

The move: Build the workflow, not the org chart. A modern GTM team is not a hire. It is a workflow you build, stack, and split, so your people do the part only people can. One loop, three moves, run on the workflow that costs you the most.

The stack: The skills in the GTM Loop plugin (Solve the Problem, Stack the Tech, and the two halves of Split, Cut the Drag and Keep the Judgment), the plumbing your workflow already uses (CRM, dialer, email), and one AI runner to carry the drag.

The loop

1. Solve the problem (skill: solve-the-problem)

Pick the workflow that costs you the most and write the problem as a workflow, not a role. Follow the spreadsheets and the "whoever has five minutes" work to find the leaks. Rank by cost. If your problem sentence names a person, rewrite it until it names the work.

2. Stack the tech (skill: stack-the-tech)

Break the workflow into steps and tag each buy, build, or have. Buy the plumbing you would be crazy to rebuild. Build only the thin edge that is yours. Decide per workflow, not per vendor pitch.

3. Split the work (skills: cut-the-drag + keep-the-judgment)

Split the work between the machine and the people. Cut the drag to the machine: list the repeatable execution between the steps, and for each ask if it needs judgment, context, or a relationship. Put AI on the safe, repeatable drag, and watch that a sloppy cut does not create cleanup that eats the savings. Keep the judgment with the people: name the human calls and give them four threads, context, tooling, ownership, and rhythm, so the workflow does not tear again. Then repeat the loop on the next most expensive workflow.

Why it scales

You never run this on the org. You run it on a workflow. A big transformation is the same loop repeated on the seams that cost the most. That is why it works on a single rep brief and on a whole GTM engine.

Two receipts, two altitudes

Small. My reps burned hours pulling context from six tools before every call. Solve: the problem was the pre-call brief, not another SDR. Stack: I kept only the tools with context that mattered. Split: AI builds the brief now (the drag), and my reps walk in briefed and keep the conversation. Receipt: about six hours a week per rep, back.
Big. Ghazi Masood, CRO at Replit, ran the same loop: about $2M to $150M in a year, GTM 40 to 230. Bought Salesforce, built apps on top, cut the drag across the motion, kept people on judgment. Same three moves.

Failure points

Naming a role instead of a problem. A job req is not a fix.
Rebuilding infrastructure you should have bought.
Automating a task that carried context, or shipping a sloppy cut.
Cutting the drag and walking away. No owner means it tears again.

The receipt

[the one workflow you ran the loop on, and the time or pipeline it gave back]

Steal this

Pick the workflow that costs the most. Solve, Stack, Split. Then the next one. The GTM Engineer everyone wants to hire is one possible owner of one workflow, which is exactly why hiring one does not fix the team.

Built GTM. Battle-tested, scar-approved. Receipts only.