the word GTM engineering has exploded, and rightfully so. But what are all these GTM engineers actually building?
my answer is that anyone who is any good at this job is building a GTM engine. Not an agent, not a workflow, not a tidier CRM. An engine.
the trouble is that there are a lot of ways to define that, a lot of neighbouring buzzwords, and the terms get used interchangeably until they stop meaning anything. So here is what I want to cover:
what it isn't, because that is where most of the confusion actually lives
the three components I think every real engine has
what the market is asking for right now, which is not the same as what people claim
when not to build one, because there are real cases where you shouldn't
For anyone new here, I am trying to automate as much of GTM end to end as I can, and publish the research and the findings as I go, feel free to check the video version of this also
1. what it isn't
the fastest way to define this is to rule things out, because a GTM engine is not an agent, it is not a CRM, and it is not a GTM engineer.
A CRM is the record. It stores what already happened and answers questions when you ask them, and it decides nothing on its own.
An agent does one job. It researches an account, drafts an email, pulls the objections out of a call. It is genuinely good at the task and completely blind to which task should be running.
A GTM engineer is a person. They are the one wiring the signals, the systems and the agents together, and they are the role everyone is suddenly posting for.
A GTM engine is the thing that person should be building, and the agents, the CRM and the engineer are all components of it rather than substitutes for it.
now, I want to be fair about the edge case here, because in theory a GTM engine could be a single agent, and in theory it could be a set of CRM automations. But when someone describes their engine as one agent, or they have built one workflow and put a name on it, most of the time they are not describing an engine at all. They are describing a component and hoping the rest is implied.
that distinction matters because you can hire a GTM engineer and still not end up with a GTM engine.
2. the components of one
I have seen a lot of people define this and I have watched a lot of other videos and read a lot of other blogs, and everyone carves it up slightly differently. For me the core loop is three parts.
Observe. Any good GTM engine starts from an honest data foundation. That means your CRM, your market signals, your past campaigns, who your personas actually are, what your brand is, what a high-intent lead has really looked like historically. It is sensing everything it can and building a model of your world out of it.
Plan. Given all of that, given that you are this brand, in this market, targeting this ICP, with these things that worked before under these conditions, what should you do next to take more share? Which account, which action, which channel, and who or what should carry it out.
worth being honest about where planning sits today: in most of the engines I see, humans still do a lot of the planning. That is not a failure state, it is just where the maturity is.
Act. Then it executes. Do we route this to an agent, do we hand it to a sales rep, do we book it, do we log it. It carries the plan out.
and then the part that makes it an engine rather than a workflow: once it acts, the world is in a different state. The account has been contacted, the deal moved, the signal is spent. So the model has to be updated, and it observes again.
a really good analogy I like for this is a chess machine.
a chess engine observes the board, plans the next few steps, asks whether this move is good or that move is better, plays one, and then re-evaluates the board and does the whole thing again. It never plays its entire game up front. It plays one move and then looks at the board again, because the board has changed and the old plan is now describing a position that no longer exists.
that is the difference between an engine and a workflow, and it is the entire reason the loop closes. A workflow finishes and reports success. An engine goes round again.
3. what people are actually using them for
in one of my last pieces I put out a six-step ladder for working out how AI-native your GTM team really is. I am not going to re-explain it here, so go and read that one for the framework. Most teams with something they call a GTM engine sit around level two and upward.
the more interesting thing to look at is what companies write down when they hire, because that tells you where the market actually is rather than what it claims.
across 1,000 GTM engineering job postings, the top asks are building and automating GTM workflows at 90%, integrating the tech stack at 86%, and owning the CRM at 78%. AI and LLM-powered automation only comes fourth, at 73%.
read that as a picture of the landscape. Three of the top four asks are plumbing. Companies are hiring people to connect things together, which tells you most of them are at the stage of building their first real workflows, with a defined task and something to carry it out. That is the lower half of the ladder, and there is nothing wrong with being there as long as you know you are there.
the line I would actually watch is data quality and hygiene, sitting ninth at 58%. My read is that the teams putting that near the top of their job spec are either further along than the rest or they are simply starting in the right order, and either way I would bet on them over the team that leads with AI automation.
4. when not to build one
there are very real cases where you should not build one, and I would rather say so than pretend this is for everybody.
if you do not have product-market fit, and if you do not have good marketers or good salespeople on your team, then not yet. At the end of the day you cannot automate something that is not working.
if you hand a sales and marketing problem to Claude and ask it to build automations for something that was not working for you before Claude, it is not going to work very well afterwards either. Automation is a multiplier, and multiplying a motion that does not work just gets you the same problem at higher speed and higher cost.
so find the things that work manually first, then automate those. Any time I approach an automation problem myself, I do it by hand first. It is slower for about a week and it saves you from automating your own bad assumptions.
conclusion
everyone right now is hiring for GTM engineers. You might be one yourself. The thing that matters is knowing what is actually possible and what you should be building towards, because if you are the GTM engineer, or you are hiring one, and neither of you understands these concepts, then nobody in the room knows what the target is.
So, the four things I would take away:
An engine is not an agent, a CRM or a person. Those are the components. The engine is the loop that runs across them.
The loop is observe, plan, act, and then observe again. If it does not come back around, it is a workflow with better branding.
The market is mostly buying plumbing. Three of the top four asks in a thousand job posts are integration and CRM work, so be honest about which rung you are on.
Automation multiplies whatever you point it at. Find the motion that works by hand, then automate that one.
If you’ve got this far you should DEFINITELY subscribe to my newsletter here.
thank you.
roman
If you are new here, my mission with the newsletter is to take GTM engineering as far as it can possibly go, and publish my findings/methods on GTM engineering in public on top of my platform Scale Intelligence
(which provides buyer, signal & market data for my agents in real-time so I can things like ai lead generation, CRM automation, signal-based outbound etc.)