There were 3,000+ open "GTM engineer" roles on LinkedIn in January of this year. That's double the count from six months earlier, a 205% jump year over year. Bloomberry analyzed 1,000 of those job postings and found the median salary sits around $127,500, with SQL and Python showing up in nearly 40% of listings.
If you run RevOps at a B2B sales org, you probably already have one of these people on your team. You might call them a GTM Engineer or something similar like RevOps Engineer or Automation Engineer.
We spend most of our time talking to RevOps and sales leaders about territory planning. GTM engineers care about it too, but they show up with a different question. Not "how do we carve fair territories," but "why is territory logic the one thing in our stack I can't touch with an API?"
What a GTM engineer actually does
GTM engineering replaces manual go-to-market work with automated systems built on AI, data, and workflow tools. The distinction between GTM engineering and regular old ops is that a traditional ops hire researches an account, updates the record, drafts the follow-up. A GTM engineer builds the workflow that does that for every account, automatically, forever.
That's a person who lives in Clay, n8n, Zapier, and whatever API their CRM exposes. They're the reason a lead gets enriched and routed in seconds instead of sitting in a queue. And they're increasingly the person deciding which vendors get connected to a company's Salesforce instance and which ones don't, because they're the one who has to build and maintain the integration.
Territory planning has the same problem GTM engineers spend their days fixing
GTM engineering and dynamic books are reactions to the same failure: running go-to-market as a pile of manual tasks instead of a system.
76% of companies still use geographic territories, typically carved once a year in a spreadsheet. 83% still plan with spreadsheets, full stop. It's the same problem GTM engineers get hired to fix everywhere else in the funnel - someone doing by hand, once a year, what should run as a continuous system.
The difference is where the logic lives. A GTM engineer can point an agent at an enrichment pipeline, routing rules, or outreach sequences, because those systems expose an API. Territory and book logic usually doesn't. It lives in a spreadsheet nobody but RevOps can open, or buried three layers deep in Salesforce config. An agent can read the accounts. It can't touch how they're assigned, why a rep has the book they have, or what happens when that rep gets reassigned.
GTM engineers care about anything still running on manual process, and territories are usually the most manual process left standing. That's the gap.
What changes when territory logic is programmable
We built Carve and Bookbuilder because manual territory management doesn't scale past a certain team size, no matter how good the RevOps team running it is. We built an MCP server for the same reason GTM engineers build everything else: so an agent can act on the data, not just read it.
With MCP wired up, a GTM engineer's agent can:
- Pull rep coverage and book data without a custom Salesforce query
- Compare territory scenarios Carve generated, the same way they'd compare A/B test results
- Debug a routing assignment by asking why, instead of digging through flow logic by hand
- Trigger a redistribution when a rep leaves, instead of filing a ticket with RevOps and waiting
None of this replaces Zapier, or n8n. It gives them something to talk to. Territory and routing logic sits behind an API the same way a CRM and an enrichment provider already do, one more system in the stack an agent can act on, instead of the one system it can only read about secondhand.
The bigger point
GTM engineers didn't invent the idea that go-to-market should run as an automated system instead of a pile of manual tasks. We've been making a version of that argument about territories since before "GTM engineer" was a job title anyone had. Dynamic books replaced the annual carve with a continuous distribution-and-retrieval cycle for exactly this reason, because a system beats a spreadsheet, whether the person running it is in RevOps or writing Python.
The difference now is that the person building that system might not be in RevOps at all. They might be the GTM engineer three desks over, and the first thing they're going to ask is whether your territory data has an API.
