One GTM engineer is not a capability

Why does hiring a GTM engineer not fix your go-to-market?

Because a builder is not a capability. The constraint on this work is how many problems a team can run at once, and each problem needs its decisions made and its blockers cleared before there is anything to implement. A GTM engineer hired alone is at most one problem's worth of implementation with none of the decisions attached, and treating the hire as an engineering hire is why it spends the quarter waiting.

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. Remove any one of the three and the work stops rather than slows.

Almost every hard question in this work is a decision, not an implementation. The question is what you want, and it 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

The executive sponsor

The person who overrides "that is not a priority right now", which is often not the person who signed the contract.

The common failure is that the sponsor treats the hire as the intervention and stops attending. The intervention is being reachable the week something gets stuck, and the sponsor's value is measured in how fast a blocked thing gets unblocked.

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, manual upload or on a schedule, who owns the exception when the system is unsure: these are not implementation details, they are the specification.

The builder

The rules of engagement document

Before a single workflow gets built, someone has to write the rules of engagement: an internal service level agreement that answers questions which 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 it and the builder encodes logic that contradicts what the sales team believes is happening. The system works exactly as specified and produces an argument.

Before any of it: what your data will actually support

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. A field existing is not the same as a field being populated, and 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 question is what percentage of the time it was filled in.

A field with a thirty percent fill rate is a sample, not a data source, and any number extrapolated from it inherits that uncertainty and should be stated with it.

Then there is the layer most teams skip: checking the record against reality. Call transcripts and email are where the truth about a relationship lives, and a modern AI-native CRM will hand you that access directly while an older one will not. Inbox access is rarely scoped to the conversations you care about, so somebody has to decide what the system is allowed to read before it reads anything.

The optimism curve

Roughly eighty percent of the work lands in about a week. The remaining twenty percent takes months, so plan for four months. The working explanation is that the tail is where the granular decisions live, and each one is a small argument that people rather than code have to resolve. That is a reading from inside the projects, not a controlled comparison: it does not separate decision latency from ordinary integration work, and the test would be a build where the rules of engagement were written before week one.

How many problems can one team run at once?

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.

So "we already have a GTM engineer" answers a different question. It says the team has a builder. Velocity on a list like the one above is set by how many pods the team can staff at once, and a builder without a sponsor and an expert attached is at most one problem's worth of implementation, with the decisions for that problem still unmade.

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 is a capacity argument, not a headcount 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, and the list of these projects is long.

Adding pod capacity buys the number of problems you can have in flight at once, not labour. That is the distance between having a builder and having a capability.