🧬 Sequencing the GTM Engineer DNA
Everyone has a vibe-based take on GTM Engineering. We actually took the GTME playbook and applied data to define GTME.
A few weeks ago I set out to answer what should have been a simple question. What does a GTM Engineer actually do?
So I took the GTME mindset to actually defining GTM Engineering. I used AI and Exa.ai to find open roles and practitioner profiles, then built a database and a web app to help explore it and a Notion workflow to keep it updated daily.
I pulled 1,058 job listings (983 open), 1,167 named practitioners, and 867 hiring companies and I used Cursor to analyze each role and title, extract the skills and estimate the knowledge needed for each role.
What I found is a category that has started to eat most of GTM, and almost nobody has noticed yet how much the scope has expanded.
The job category is exploding. Clay coined the title in 2023. The Signal recently reported that 54% of the fastest-growing B2B SaaS companies now have a GTM Engineer (or someone doing the job under another title). There are hundreds of open roles. Carilu Dietrich, who advises hypergrowth companies, is calling them Marketing Engineers. a16z launched a Growth Engineer Fellowship. Toast posts “GTM Engineer, Marketing Operations AI Innovation.” Profound calls them AI Marketing Engineers. Drew Bredvick, who runs GTM Engineering at Vercel, has the catchiest description I have read: “pattern recognition turned into automation.” His first agent at Vercel took the inbound SDR team from 10 to 1, saved $2M+, and was built in a weekend.
I also found there are occasionally customer-facing roles that get misclassified into this job title, but they’re something separate. The main job? Building their own company’s pipeline, sales, and renewal engine.
Where the term came from (and how it’s evolving)
Clay came up with the category.
In their July 2025 essay they wrote the title was minted there in 2023, when around 100 GTME job listings were going live every month. As of late 2025 that had already grown past 245 a month, with the Signal projecting close to 2,700 listings for 2026. The original definition: a GTM Engineer was someone who used Clay (and its ecosystem) to build automated, signal-driven outbound. It meant finding the right account, enriching it, scoring it, and getting outreach to the right person at the right time with the right context, all automated. This was a good frame. It gave a name to work that high-leverage outbound teams were already doing. It also helped Clay create and own a category.
But ask any four people what the job actually is today and you will get six answers (I actually asked at our last GTME event and recorded the answers.)
“A GTM engineer is someone who can explain what GTM is to an AI agent, stitch together all kinds of APIs, visualize their workflows, and define that with the proper context to AI.”
“A GTM engineer is someone that knows very well how to use AI and all the tools that we have today for go-to-market, and can bring everything together to create great GTM systems that reduce a lot of the manual work.”
“My understanding of GTM engineering is starting to apply code to all forms of marketing, whether that’s community building, lead generation, it doesn’t really matter. Now code is leveraged for every function, not just for building product or infrastructure.”
The original scope (mostly focused on external data and outbound motions) was focused on people with specific revenue system skills. In the last 18 months, two things happened that shattered the scope.
The first is that AI made building accessible to people who don’t write code. A demand-gen marketer with Cursor and an MCP can ship a workflow in a weekend that used to require a quarter of engineering time. A RevOps analyst who has never opened a Python notebook can stand up an account research agent in an afternoon. A marketing leader can wire up an SEO pipeline made of nine specialized agents and a tenth orchestrator on top of her own GTM data.
The first useful version of most GTM systems can now be built by the operator closest to the pain.
Second, once GTM operators could build, the whole job started changing. Lifecycle marketing, website copy, account research, pipeline forecasting, competitive intel, renewal risk, campaign personalization, AEO and answer-engine visibility, brand presence inside LLMs. All of it started looking less like a list of tasks and more like a set of systems somebody has to design, instrument, evaluate, and ship.
The shift for GTMEs
There is a precedent for this: we already saw a similar shift in engineering. When swyx, who established the largest AI engineer community, wrote The Rise of the AI Engineer in 2023, the role looked like one thing: someone who specializes in taking generic foundation models into valuable products, doing the prompt, context, and harness engineering to build agents, and shipping more productively with AI.
Three years later, that role has constantly evolved. Some AI Engineers are product engineers with prompt skills. Others are platform engineers running model gateways, evals specialists, forward-deployed engineers embedding with customers, or research-adjacent. The original definition did not shrink. The market expanded around it, and now we call all of them “AI Engineers” and squint to figure out which kind we mean.
GTME is going to do the same thing, but faster, because the underlying skill is more transferable.
The shape of GTME today
When I analyzed the open GTME positions, the data supported the hypothesis that the market is rapidly shifting. The role is already expanding into different archetypes. I found eight that will probably shift and merge over time.
Here is the full breakdown of all 1,058 job listings (983 open):
All eight share the same underlying workspace (unified GTM data, agents and workflows on top of it, evaluation loops, and a measurement discipline that ties the system back to revenue), the outputs just take different shapes depending on which part of the funnel the role lives in and what the company is optimizing for.
The success metrics, on the other hand, are completely different by archetype. An Outbound GTME is measured on meetings booked from automated plays. An Exec / CoE lead is measured on org-wide AI adoption and pipeline efficiency. A Marketing Engineer is measured on pipeline-influenced or AEO visibility. A RevOps Evolution role is measured on routing accuracy and lead-to-opportunity conversion. A Founding GTME is measured on revenue, full stop.
If the role is evolving this fast, the ecosystem has to evolve too. Below are roles broken down by subtype, size of hiring company and location.
Biggest challenges currently facing GTM engineers
Problem 1: GTM Engineers need a unified data layer for internal GTM data.
Clay won outbound by giving GTM Engineers a clean platform for external data. Pull a list. Enrich it. Score it. Sequence it. The reason a Clay power user can ship in days is that someone else already did the awful work of unifying every enrichment provider behind one interface.
Internal data has no equivalent.
Every GTM Engineer who tries to build something that depends on what actually happened inside their own company hits the same wall. Salesforce is a swamp. HubSpot has the marketing side, half-synced. Gong has half the calls. Outreach has half the emails. Marketo has the campaigns from three CMOs ago, with naming conventions from two RevOps eras ago. The data warehouse has whatever someone’s analytics engineer copied over last quarter, and probably stopped maintaining six months later. The GTM Engineer’s first ten hours go to plumbing, not product.
Validity’s 2025 CRM data report found that 76% of organizations said less than half their CRM data was accurate and complete. AI exposes this weakness in a way that older tools never did. A model can summarize a call. An agent can draft an email. But if the underlying account hierarchy is broken, or the contact roles aren’t filled in, or the same person shows up under three email addresses, the agent is guessing.
AI is only as good as the data underneath it. GTM data is, almost universally, a disaster.
The thesis is simple. GTM Engineers need a unified data foundation they can build on without spending a quarter stitching together CRM, calendar, email, calls, and product usage. And it cannot just unify broken data. It has to use messy data as signal and rebuild a clean, enriched data lake for AI. The teams who have built this themselves are pulling ahead in real time.
This is the part we are working on at Upside, and we are seeing in real time how GTM professionals can transform into GTMEs when that data foundation is readily available to them and accessible to build with AI on top of it.
Problem 2: There is no agreed-upon success metric for the role.
When you hire a software engineer, you know what good looks like: PRs merged, incidents resolved, p95 latency, test coverage, on-call performance. Imperfect, but legible.
When you hire a GTM Engineer, every team measures them differently, and most teams haven’t written down what “good” means at all. They know it when they see it. Which is to say, they hire by vibes.
This is fine in 2026 because there are roughly four times as many open roles as qualified people. It will not be fine in 2027. The first GTME you hire on a strong gut feel is a great hire. The fifth one you hire that way is a disaster, because by then you have stacked five different definitions of the role on top of each other and nobody can tell which work is moving the business.
The category needs a measurement vocabulary. Until it has one, every GTM Engineer is going to be quietly underrated by their company until the day their system stops working and everyone realizes how much pipeline was secretly running through it.
Problem 3: There are no widely adopted agent harnesses built for GTMEs.
If you spend any time on LinkedIn (where most of GTM lives), you have seen Claude take over. My friend Alina Vandenberghe, the CEO of Chili Piper calls it “AI psychosis” because everyone is building with Claude and posting their morning briefs.
I personally use Cursor more. I love the harness, I love that it is better at solving its own problems, and I like being able to try GPT 5.5 for what I am building. But whether you use Claude or Cursor, these tools were built for developers. They were not built for the GTME architect persona: team memory, permissioned GTM data access, repeatable evals, safe handoffs into business systems.
Companies like Dust and Glean are taking on the problem at scale, while other teams are building this in house. Zapier has just launched its own product, and so has Notion (though more developer focused). And for companies like Ramp who want to build their tools internally, Claude is moving fastest in this area with a consulting-led enterprise approach and just announced a $1.5B JV. OpenAI is fast following with OpenAI Deployment Company, both aiming to help enterprises adopt AI.
Every GTM person needs to develop GTME skills (or risk becoming obsolete)
This is the uncomfortable part of the essay. The market is splitting GTM people into two groups, and the split is going to compound very quickly.
There are people who work within the system given to them: these are the slide-deck CMOs, templated-sequence SDRs, dashboard-only RevOps analysts and campaign managers who only configure tools that other people built and operators who only file tickets. Leaders who can describe a strategy but cannot prototype the machine that would execute it.
Then there are people who build the system. They may still hold the same titles: CMOs, SDRs, RevOps leaders, demand-gen marketers, PMMs, SEs, founders, growth leads. But they have added the builder muscle. They use AI to research, write, code, orchestrate, analyze, test, and deploy. They can rebuild a workflow in a weekend instead of writing a brief and waiting two quarters for the implementation.
This does not mean everyone becomes a traditional engineer. It means everyone in GTM has to understand how to design, evaluate, and adapt systems. The work itself becomes software.
A revenue team’s job used to be doing the work. Now it is designing the system that does the work.
Three months ago I was still mostly copy-pasting prompts into ChatGPT. I was not starting from zero. I co-founded Branch, scaled it to thousands of enterprise customers, and served as its CMO for years. I had spent that whole time building marketing teams, revenue systems, attribution models, and growth engines. But I had not built much software in years. I operated like a traditional GTM executive. Decide the strategy. Ask the team for the execution. Review the dashboard. Repeat.
Then we started building internal AI systems at Upside, and I stopped being a requester.
I shipped our case-study skill, an eight-phase pipeline that goes from “name the customer” to a published webpage. It generates the interview questions from past examples, researches the answers through the Upside MCP and Fireflies, finds the exact video timestamps for the strongest quotes, validates every claim against source data, drafts in Google Docs, and publishes the HTML. The numbers it pulled for our Assembled case study (30k+ hidden contacts discovered, 37k+ hidden touchpoints uncovered, 2x more accurate pipeline) it found itself. I just picked which ones to lead with. I also built a self-updating GTME database that uses tools like Exa and Notion to pull roles and practitioners together all in one place.
For the first time since I was an actual engineer (I haven’t written software since 2007), I felt like a builder again. Not a requester. Not a reviewer. Not a slide-deck CMO. The GTME database (though I admit I had initially overcomplicated its technical implementation), is just another example of what I can build using GTME skills.
Teams are hiring for a named GTME role right now because all these skills are still so fresh that it often makes sense to centralize them…but don’t kid yourself: everyone in GTM is going to have to learn some of these or not have a role in the next 12-18 months.
How to become a GTM Engineer
If you have read this far and thought “I am not technical enough for any of this,” I have to tell you, you are wrong. I was not technical enough three months ago. Here is what actually changed how I work, in the order it happened.
1. Think in systems, not in tasks. Every time you catch yourself doing a thing twice, ask if the second time should be a system, not a one-off automation. A real system, with memory, evaluation, and a feedback loop.
2. Overuse AI on the work you think you are best at. The temptation is to use AI for the work you don’t want to do, and keep doing the “real work” yourself. That is exactly the wrong instinct. Instead, use AI for the work you are most proud of. Force yourself to teach a model to do it.
3. Pick a problem that fights you. Pick something that has been annoying you for a year. The first version will be embarrassing. Ship it anyway. The second version will be three times better than what you would have produced if you had tried to architect it correctly up front. My project? Building a self-updating GTME hub.
4. Steal from the people doing it. This is the part everyone underestimates. The GTME community is small enough and people love to show how they are building and our last event below is just an example.
If you are building, hiring, becoming, or trying to figure out how to measure a GTM Engineer, join the community. It is forming in real time, and the people who join now are going to define what this role looks like for the next ten years.
Problem 1 maps almost exactly to what I keep hearing. Ask GTM teams where they're actually stuck and AI almost never comes up first. Data silos, broken CRM, no clean signal underneath. The teams getting durable traction solved the plumbing before adding anything on top.
I'd argue Problem 2 is downstream of something even bigger. Most GTM teams haven't defined success clearly even without AI. The GTME role inherits that ambiguity with a harder mandate attached.
Definitely true on "everyone needs GTME skills or face obsolescence." That said, I'd argue the operators getting the most traction have domain knowledge first, builder skills second. Without the GTM foundation underneath, the builder skills just accelerate movement toward the wrong problems.
Curious whether the data shows any patterns there — which archetypes tend to skew technical-background-first vs. domain-first?
Amazing and comprehensive! I feel like GTME just clicked for me for the first time.