One GTM engineer is not a capability
A builder can build anything you describe. The constraint was never the tooling. Why every AI GTM problem needs a pod: an executive sponsor, one or two subject matter experts, and a builder.
[ key takeaways ]
- A GTM engineer is a builder, and a builder is not a capability. The constraint in AI go-to-market work is decisions, not implementation.
- A pod is the smallest unit that can ship a capability: an executive sponsor who can override a no, one or two subject matter experts who specify what the system should decide, and a builder.
- The rules of engagement document is the missing input in most failed builds, because without it the builder encodes logic that contradicts what another team believes is happening.
- Nobody has one pod per problem, so no team is at maximum velocity; adding pod capacity buys the number of problems you can run at once, not labour.
Why does hiring a GTM engineer not fix your go-to-market?
Because a builder is not a capability. A GTM engineer can build almost anything you describe. The constraint was never what the tools can do, and treating it as an engineering hire is what makes the hire fail.
- definitionGTM pod
A GTM pod is the smallest group that can actually ship a go-to-market capability: an executive sponsor who can unblock resources, one or two subject matter experts who know what the system is supposed to decide, and a builder who implements it. Removing any one of the three does not slow the work down. It stops it.
[ fig. 01 · what you hired against what ships ]
The reason is that almost every hard question in this work is a decision, not an implementation. Anything is possible. The question is what you want, and that question sits at the intersection of three domains that rarely live in one person: what the technology can do, what the business is willing to commit to, and how a customer should be treated at each point in their lifecycle.
What a pod actually contains
[ fig. 02 · the pod ]
executive sponsor
Overrides a no
Without them: the work stalls at the first reasonable no and nobody can tell you why the project went quiet.
subject matter expert
Knows what it should decide
Without them: the builder guesses, consistently and wrongly, and it looks like the builder underperforming.
the builder
Implements the decisions
On their own: the only role most companies actually hire, and the one that can do least without the other two.
Often doubled: sales and marketing each need their own sponsor and their own expert, because a blocker on one side cannot be overridden by an executive on the other, and the interesting decisions live exactly where the two bodies of knowledge meet.
The executive sponsor
Not the person who signed the contract. The person who overrides "that is not a priority right now."
Every one of these projects hits a wall where someone reasonable, with their own roadmap, says no. Data access needs approval. A field needs to change on an object three teams depend on. Someone needs to stop doing the thing they have done for two years. The sponsor is the person who can say "it is a priority, do it now," and be obeyed.
This role fails in a specific and predictable way: the sponsor hires the capability and then stops attending. They believe hiring was the intervention. It was not. The intervention is being reachable the week something gets stuck, and the value of the sponsor is measured entirely in how fast a blocked thing gets unblocked.
You may need two, one on the sales side and one on the marketing side, because a blocker on one side cannot be overridden by an executive on the other.
The subject matter expert
The person who does not know how to build any of it and knows exactly what it should do.
Which fields. Which exclusions. Is the list uploaded manually or on a schedule. Weekly or monthly. Who owns the exception when the system is unsure. These are not implementation details, they are the specification, and a builder who has to guess at them will guess consistently and wrongly.
You will often need two of these as well, because sales go-to-market knowledge and marketing go-to-market knowledge are genuinely different bodies of expertise, and the interesting decisions live exactly where they meet.
The builder
The GTM engineer. The one role most companies actually hire, and the one that can do the least on its own.
The document nobody writes
Before a single workflow gets built, someone has to write the rules of engagement.
It is an internal service level agreement, and it answers questions that feel obvious until two teams answer them differently. Is marketing allowed to email someone sales is actively working? Who does what, by when? What are the exclusion rules? What happens when a record qualifies for two motions at once?
Skip this and your builder will encode logic that contradicts what the sales team believes is happening. The system will work exactly as specified and produce an argument. That is not a technical failure and no amount of engineering talent prevents it, because the missing input was a business decision nobody made.
The rules of engagement document is also the artifact that makes the work auditable later. When someone asks why a particular customer got a particular message, the answer is a written rule rather than a reconstruction.
Before any of it: what your data will actually support
There is a chain of dependencies here that gets discovered rather than planned, and it is worth walking before scoping anything.
Do you have direct access to a data warehouse? Most teams do not. So the fallback is headless access to the CRM, which raises the next question: are you on a package that permits API access at all? That is a commercial question answered by your contract, not by your engineering team.
Assume you get access. Now the question is what is actually in there. A field existing is not the same as a field being populated. A populated field is not the same as a usable one. There is a real difference between a date, a date with a reason attached, a reason chosen from a controlled list, and a reason typed as free text. And if it is free text, the only question that matters is what percentage of the time anyone bothered to fill it in.
A field with a thirty percent fill rate is not a data source. It is a sample, and any number you extrapolate from it inherits that uncertainty and should be stated with it.
Then there is the layer most teams skip: something has to check the record against reality. Call transcripts and email correspondence are where the truth about a relationship actually lives, and a modern AI-native CRM will hand you that access directly while an older one will not. That raises a governance question rather than a technical one, because inbox access is rarely scoped to the conversations you care about. Somebody has to decide what the system is allowed to read before it reads anything.
The optimism curve
Every one of these projects follows the same shape.
[ fig. 03 · the optimism curve ]
It looks straightforward and everyone is enthusiastic. The tooling genuinely can do it.
Every granular decision turns out to be a small argument between two teams. This is the schedule, not a failure.
An accurate view of what is possible, which is usually a great deal, just not the thing imagined at the start.
At the start it looks straightforward and the team is enthusiastic. In the middle it is harder than anyone expected and the enthusiasm inverts. At the end it settles into an accurate view of what is possible, which is usually a great deal, just not the thing that was imagined at the start.
The practical version: roughly eighty percent of the work lands in about a week. The remaining twenty percent takes months. That last portion is not slow because the technology is hard. It is slow because it is where all the granular decisions live, and every one of them is a small argument that has to be resolved by people rather than resolved by code.
Plan for four months and expect the middle to feel like pulling teeth. A team told this in advance treats the hard middle as the schedule. A team not told treats it as evidence that the project has failed.
The velocity claim that does not survive contact
Here is the argument this is all building toward.
"We already have a GTM engineer" is not a rebuttal. Neither is "we hired a VP of RevOps." Because you do not have one pod per problem. Nobody does. That would be impossible.
Reactivating dormant demand is one problem and needs a pod. Lead scoring is another problem and needs a pod. Existing-business motion, upsell, cross-sell, champion monitoring when your advocate changes jobs: each of these is its own problem with its own decisions, its own subject matter expert, and its own set of arguments to resolve. Any one of them, examined properly, is bigger than it looks from outside.
So by all means tell me you have a builder. Do not tell me you are at maximum velocity, because that claim requires a pod per problem and you have one team.
The capacity question
Ask a marketing leader how many people are on their marketing team and the answer is often eight or ten. Ask how many should be on the AI-native version of that team and the honest answer is closer to two, because the leverage per person is genuinely different.
That sounds like a headcount argument. It is not. It is a capacity argument, and it runs the other way than people expect: a strong individual contributor should be carrying three to five projects at once and picking up the next one the moment something wraps. There are hundreds of these projects available. There is no version of this where you run out of work.
What you are actually buying, when you add pod capacity, is not labour. It is the number of problems you can have in flight simultaneously. You are never at one hundred percent, and anyone who tells you they are has confused having a builder with having a capability.
[ key takeaways ]
- A GTM engineer is a builder, and a builder is not a capability. The constraint in AI go-to-market work is decisions, not implementation, and the decisions sit where technology, business commitment and customer lifecycle meet.
- A pod is the smallest unit that can ship: an executive sponsor who can override a no, one or two subject matter experts who specify what the system should decide, and a builder. Sales and marketing often each need their own sponsor and their own expert.
- The rules of engagement document is the missing input in most failed builds. Without a written answer to who may contact whom, when, and under what exclusions, the builder encodes logic that contradicts what another team believes is happening.
- Data readiness is a chain: warehouse access, then CRM API access as a commercial question, then whether fields are populated at all, then whether a free-text field was filled in often enough to extrapolate from.
- Roughly eighty percent of one of these builds lands in a week and the last twenty percent takes months, because the tail is where the granular decisions live.
- Nobody has one pod per problem, so no team is at maximum velocity. Adding pod capacity buys the number of problems you can run at once, not labour.