A GTM engineer finds the bottlenecks in how a company finds, wins and keeps customers, and builds systems that remove them. That usually means enrichment and scoring, lead routing, AI research and drafting, CRM automation and reporting tied to outcomes. Clay's guide describes the rhythm: identify a revenue bottleneck, build a workflow to fix it, validate it on a small set of records, then scale it, and measure success in meetings booked and hours saved rather than tasks completed (Clay).
If you are new to the field, start with What is GTM engineering?. This article is about the actual work.
The core loop
Almost everything a GTM engineer does fits one loop. MitHub teaches it as the scientific method applied to revenue: observe → hypothesis → build → measure → learn → adjust (see Operate).
- Observe. Where are deals, leads or hours getting stuck? Look at the CRM, talk to reps, trace recent wins back to their source.
- Hypothesize. "If new inbound leads were enriched and routed in under a minute, more of them would book a meeting."
- Build. The smallest workflow that tests the idea.
- Measure. Run it on a small batch first, check the records by hand, compare against a baseline.
- Learn. Did the business number move, or only the activity?
- Adjust. Scale it, fix it or kill it.
The word that matters is small. A GTM engineer who builds a giant system before testing it on 50 records is just taking a bigger risk.
Typical projects
Inbound: speed and routing
When a lead fills out a form, a workflow enriches the company and person, scores fit, assigns the right owner, creates or updates the CRM record and alerts the rep, ideally before the lead has closed the browser tab. Clay's guide lists real-time inbound routing among the typical deliverables (Clay).
Outbound: better lists and research, not more spam
Instead of buying a list and blasting it, a GTM engineer builds a target list from signals (hiring, funding, expansion, technology changes), enriches contacts, and uses AI to write a short research brief per account. Reps get fewer, better accounts with context.
Post-call automation
Everett Berry, head of GTM engineering at Clay, described workflows that draft follow-up emails from call transcripts and generate handoff decks automatically when a deal closes (The GTME). Clay's guide also mentions enriching the CRM from call transcripts (Clay). Every field a rep doesn't type by hand is time returned to selling, and data that is more likely to be complete.
Signals and alerts
Berry's team also built Slack alerts triggered by account signals such as product usage patterns or upcoming contract milestones (The GTME). The system watches; the human acts at the right moment.
Hygiene and reporting
Deduplicating records, standardizing fields, fixing ownership, and building the report that shows which plays actually produced pipeline. Unglamorous, and often the highest-return work in the quarter.
How GTM engineers organize the work
Clay splits the role in two (The GTME):
- Forward-deployed GTM engineers work with customers on implementation and use cases.
- Internal GTM engineers build and maintain the company's own revenue infrastructure.
Berry also described the internal team working in two-week sprints and treating workflows like code, with version control and release notes. That habit is worth copying even if you work alone: batch requests, ship in cycles, and write down what changed.
Tools and skills: what job postings ask for
Bloomberry analyzed 1,000 GTM engineering job postings (Bloomberry). A few findings help you set expectations:
| What postings ask for | Finding |
|---|---|
| Top responsibilities | Build and automate GTM workflows; integrate the GTM tech stack; own or optimize the CRM |
| Most popular tools | Clay (most popular), HubSpot (52%), Outreach (49%), Salesforce (45%) |
| Coding | SQL and Python each mentioned in 38% of postings |
| Experience | 4.11 years on average |
| Most common path in (from profiles reviewed) | SDR/BDR, followed by RevOps and sales ops |
Clay's guide adds nuance on the entry point: it says coding expertise isn't required to start and that learning tools through experimentation matters most, with backgrounds ranging from product design to RevOps to sales (Clay). Clay's blog lists the qualities it looks for as technical fluency, commercial bias, curiosity and an experimental mindset (Clay blog).
In practice, the working toolkit looks like this:
- CRM: Salesforce or HubSpot, including objects, fields, stages and automation rules.
- Enrichment and data: Clay and the providers it connects to.
- Automation and orchestration: tools such as n8n to connect systems and run AI steps. See n8n for AI automation.
- Engagement: email sequencing, calling and LinkedIn tools.
- AI: models for research, classification, extraction and drafting, with clear instructions and review.
- Data: spreadsheets, SQL and a warehouse as the work matures.
What about pay?
Pay varies widely by country, company stage and seniority, so treat any number as context. Bloomberry reports a median of $127,500 per year, calculated only from postings that published a salary range, with some employers listing much higher figures (Bloomberry). Many postings don't publish a range, and remote roles hiring internationally may pay on different bands.
What separates good GTM engineers from tool operators
Knowing Clay is not the job. Clay's own guide names commercial judgment, the ability to tell whether a workflow actually helps close deals, as what separates GTM engineers from generic automation specialists (Clay).
MitHub describes the same shift with a capability ladder:
- Doer: does the research, data entry and outreach by hand.
- Director: directs AI and systems to do those tasks and judges the output.
- Designer: designs the systems and workflows.
- Owner: owns the business result.
A tool operator stays at Director. A GTM engineer works at Designer and grows toward Owner, which is exactly where revenue engineering begins: starting at the payment and tracing it backwards before deciding what to build.
A MitHub build ticket you can use
Before building anything, fill this in. If you can't, you're not ready to build. It fits on one page.
| Field | What to write |
|---|---|
| Problem | What is slow, manual or leaking? One sentence. |
| Evidence | The number that shows it (e.g., median time to first touch, % of records missing a phone). |
| Money link | How fixing it plausibly affects meetings, deals or revenue. |
| Hypothesis | "If we build X, metric Y will move from A toward B." |
| Family | Lists and enrichment / agentic AI system / automated workflow / data and reporting. |
| Smallest test | How many records, for how long, with what baseline. |
| Limits | What the system, especially any AI step, must never do. |
| Validation | Where you'll check the business result (the CRM record, not the run log). |
| Owner | Who maintains it after launch. |
| Decision date | When you'll scale, fix or kill it. |
Example (hypothetical)
- Problem: Demo requests wait hours for a rep to research them.
- Evidence: In a sample of last month's requests, most had no enrichment before the first call.
- Money link: Faster, better-prepared first calls should raise show and conversion rates.
- Hypothesis: An automatic enrichment and AI brief within a minute will raise meeting show rate.
- Family: Lists and enrichment + agentic AI system + automated workflow.
- Smallest test: 50 requests over two weeks, compared with the prior 50.
- Limits: The AI writes internal briefs only; it never emails the prospect.
- Validation: Open each CRM record; confirm brief attached and owner assigned.
- Owner: The GTM engineer, with the sales manager as reviewer.
- Decision date: End of week two.
How to start doing the work
You don't need the title to build proof. Pick a real process, even at a small business, and complete one build ticket end to end. Document the before, the system and the result.
MitHub's Faculty of Revenue Reverse Engineering walks through this in six free foundation chapters, from Follow the money to Prove value fast and your case study. For the career path itself, read How to become a GTM engineer.