Introduction to GTM Engineering

When I started Zevenue in 2021, the work we did didn’t have a name.

We built lists no database sold, the enrichment behind them, the sending infrastructure, and the logic that decided who got an email and what it said. We called it outbound, because that was the closest word anyone had.

It has a name now. Searches for “GTM engineer” barely registered until the end of 2024, and today OpenAI and Anthropic are both hiring GTM engineering teams.

Most of this post is about what to learn if you want to become one. First, what the job actually is.

What is GTM engineering?

GTM is short for go-to-market: everything a company does to find customers, win them and keep them. GTM engineering is building the systems that do that work, and a GTM engineer is the person who builds them.

For fifteen years, pipeline scaled with headcount. Predictable Revenue popularized the SDR team in 2011: if you needed more meetings, you hired more reps. GTM engineering scales with systems instead. You build the systems that do the repetitive work, from research and routing to follow-ups and renewals, and your people spend their time where judgment matters.

The clearest example I know is Vercel. Before writing any code, Drew Bredvick, who leads GTM engineering there, spent a week watching their top performer and how she thought about leads. Then he built an agent that researches and qualifies every inbound lead the way she did, and hands the rep a draft. He built it in a weekend. Vercel went from 10 inbound SDRs to 1.

That’s the job. Learn what your best person does by instinct, then turn it into a system the whole team can run.

Where the name came from

The earliest use we could find is a Scale AI job post from 2021, for a client-facing engineer closer to what we’d now call a solutions engineer.

The meaning most people use today came from Clay. Yash Tekriwal was in ops there, taking 30-35 calls a week while building the scoring and systems behind them in Clay. Co-founder Varun Anand decided it wasn’t a sales job or an ops job, and gave it a new name: “I think we’re going to call it GTM engineer.”

The title still covers different jobs: internal builders, customer-facing engineers, and RevOps roles with a new name. If you’re job hunting, read the description, not the title.

What GTM engineers build

Outbound is where a lot of GTM engineers started, us included. It’s one part of the job.

The best map of the whole thing I’ve seen is how OpenAI describes its GTM Growth Engineering team: products tied to “pipeline quality, customer engagement, seller and marketer productivity,” covering “customer context, prioritization, routing, campaign execution, review surfaces, feedback loops, and measurement.” A second team there, GTM Innovation, is trying to automate “100% of digital knowledge work” in OpenAI’s go-to-market so sellers spend more time with customers. The word outbound doesn’t appear in any of those job posts.

Put together, GTM engineers build across the whole revenue cycle:

1. Finding the market. Lists nobody sells, signals that say who’s likely to buy right now, and the enrichment behind both. If your buyer is a laundromat owner or an HVAC operator, they aren’t in Apollo. (A lot of our work is this.)
2. Inbound. Research, score and route every lead the moment it arrives. The Vercel agent is this.
3. Marketing. Segments, campaign execution, and personalized content at a volume no team could write by hand.
4. Sales. Account research, call prep, follow-up drafts and CRM updates. Anthropic’s Sales plugin does this for its reps, and roughly 80% of their sales org was using it within months.
5. After the sale. Handoffs, renewal and expansion signals, account reviews. At Clay, the handoff deck builds itself when a deal closes, and the QBR deck builds itself from usage data and conversation history.
6. The foundation and the scoreboard. The data everything above runs on, and the experiments and evals that tell you which of it works.

Isn’t this just RevOps?

The overlap is real, and plenty of GTM engineers report into RevOps. But RevOps runs the systems of record: the CRM, reporting, forecasting, territories, comp. It keeps the machine accurate. GTM engineers build new machines on top: the systems that find customers, win them and keep them.

It isn’t an SDR job either. SDRs do the outreach. GTM engineers build what decides who gets reached, when and with what. And despite the word, it isn’t sales engineering, which is demos and technical questions inside live deals.

What coding agents changed

Building got cheap. What used to be a scoped project is now a couple of days’ work for one person with Claude Code. The vendors noticed. This year HubSpot, Salesforce, Apollo and Clay all shipped ways for coding agents to work with them directly, which is the idea behind Headless GTM.

What didn’t get cheap is knowing whether it works. Karpathy’s line is that models can automate what you can verify. Code has tests. Sales grades you once a quarter, and a test on a couple of hundred emails usually can’t tell you which version won.

That changes what you need to learn. The technical half got easier. The judgment half didn’t.

What to learn

If I were starting today, this is the order I’d learn it in. The first two are the ones people skip, and they’re what make the rest work. Hiring managers know it. Alexander DeMoulin, director of RevOps at Intercom: “I want someone who has sat in the sales seat before.”

1. How sales actually works. Every system you build encodes a sales decision: who’s worth contacting, what to say, when to follow up. Learn who buys and who signs, why buyers switch, and what reps actually do all day. The fastest way is to sit with them. Watch a good rep for a week and write down every decision they make. That list becomes the spec for most of what you’ll build. (It’s also why I think the best GTM engineers work like forward deployed engineers, embedded with their own sales team.)

2. What a good message looks like. Write 20 emails by hand before you automate one. Learn the difference between a signal (“they just hired three SDRs”) and metadata (“VP of Sales at Acme”), and how to connect a signal to a real problem (signal, bridge, voice). You can’t check an AI’s work if you don’t know what good looks like.

3. Data. Most GTM systems fail on the data, not the model. Learn what contact databases cover and who they miss, how to scrape lists nobody sells, how enrichment waterfalls work, and how to verify an email before it’s sent.

4. Systems and plumbing. How a CRM is modelled, how tools sync through APIs and webhooks, why CRM data goes stale, and, if you touch email, how it actually gets delivered: secondary domains, SPF, DKIM and DMARC, warmup (start here). It’s the unglamorous part, and when it breaks, everything on top of it breaks too.

5. Building, Clay first and then code. Clay is the best way to learn how data moves through a GTM system, because you can watch it happen. Then learn APIs and JSON, the terminal, git and Claude Code. You need less code than people think, but more than zero: enough SQL and Python to read what an agent writes and notice when it’s wrong. Jared Sires was an AE who had never written a line of code before joining Anthropic in 2024. His Claude Code builds became that Sales plugin. (Our onboarding guide is a good first step.)

6. Judgment about AI. Which steps need a model and which need an if statement. What context the model needs and where it lives. Where a human stays in the loop, and what the whole thing costs to run. Clay and Claude Code are tools. Plenty of people are great at both and still build the wrong thing.

7. Measurement. Experiments that change one thing at a time, with enough volume to trust. Evals that define what good looks like and check every change against it. And monitoring, because systems drift. Our own agent chain once routed around a broken data contract for weeks while every run finished green.

How to prove it

There are almost no junior GTM engineer roles, so a certificate won’t get you far. A working system will.

Build one thing end to end and measure it. It could be a list a database can’t give you plus the message that goes with it, an inbound router that scores and assigns leads, or an alert that flags accounts likely to churn. Then write up what you’d change. For a head start on the list version, our open-source Headless GTM skills run that whole chain in Claude Code, and reading every file they touch is a decent education on its own.

If you’re hiring, ask candidates for exactly this.

Most of what we built by hand in 2021 would take an afternoon now. Knowing what to build still takes years.