Three buckets, one honest conversation first
GTM engineering job postings are everywhere right now.
I talk to other GTM engineers regularly, and this year I noticed something. Almost none of us are doing the same job.
One of them is provisioning mailboxes and fixing SPF records. Another is stitching Clay into Salesforce into Slack with an AI agent making decisions in the middle. A third spent his whole quarter replacing three SDRs worth of manual busywork with a single automation.
Same title on LinkedIn. Three completely different jobs.
Here's the part nobody talks about: most of that mismatch isn't the engineer's fault. It's that the company never actually defined the problem before it went hiring.
Estimated reading time: 2 min 50 sec
Background
Hey, I'm Miguel!
I run The SaaS Consultants, a remote full-service sales and marketing agency that helps SaaS companies launch their first sales-led motion, spanning cold outbound, paid ads, and sales hiring. Running it remotely means I get to live as a digital nomad. I'm currently in South America, working toward C1 fluency in Spanish.
My favorite part of running the agency is the GTM engineering side: building the automation and systems behind growth (Clay, Make, n8n, cold email and calling stacks, paid media funnel buildouts, CRMs) instead of just running campaigns by hand. It lets me use my engineering background instead of leaving it behind.
Before the agency, I was a software engineer, including a stint at a big tech company, a B2C AI startup I exited just three months after launch, and a B2B SaaS product I built to recurring revenue. I split my time between the agency, travel, and learning new languages.
Want to know exactly which GTM system to fix first?
Take the 60-second GTM Readiness Assessment
I'll tell you your biggest constraint and the exact next step to fix it.
1. The title is doing three jobs' worth of work
GTM engineering isn't one discipline, it's three, and most job descriptions blur them into one.
Every GTM engineering project I've seen, mine included, falls into one of these buckets:
Infrastructure buildout. Mailboxes, domains, deliverability, sending capacity, data enrichment pipes. This is the plumbing underneath a go-to-market stack. Nobody notices it's there until it's broken.
Full-stack wiring plus AI. Connecting the entire GTM stack together, CRM, enrichment, dialers, LinkedIn, ads, and layering AI agents on top to make decisions across all of it instead of a human toggling between six tabs.
Automating people's time. Taking manual, repetitive work off SDRs and AEs so more of their day goes toward actual selling instead of data entry and prep.
These are not three flavors of the same job. They require different skills, different tools, and a different definition of what "done" looks like.
2. Why the mismatch happens
Companies write the job posting before they know which of the three problems they actually have.
A founder or a VP of sales hears "GTM engineer" at a conference or on a podcast, decides they need one, and posts a role that's a grab bag of all three buckets stitched into one job description. They hire whoever interviews best, not whoever fits the actual problem.
Six months later, there's frustration on both sides. The company wanted their bounce rate fixed and their domains cleaned up. The person they hired is genuinely great at wiring together agentic workflows and has never touched an SPF record in their life. Nobody's wrong here. Nobody ever named the problem.
3. The diagnostic I run before touching anything
Before I build a single workflow, I make the company pick a bucket.
A few questions I ask early, and what the answers usually point to:
Are your emails not landing, or landing in spam? That's infrastructure. Fix the plumbing before anything else, because nothing built on top of broken deliverability matters.
Are your tools not talking to each other, forcing your team to copy-paste between systems all day? That's full-stack wiring. The stack exists, it just doesn't function as one system yet.
Is your team spending hours on tasks that don't require a human judgment call? That's automation. The workflow already exists in someone's head, it just needs to move out of their hands.
Most companies can answer this in under five minutes once someone actually asks. The problem is almost nobody asks before the job gets posted or the contract gets signed.
4. It's rarely just one, but it's never all three at once
Most companies eventually need all three buckets, just never at the same time.
Infrastructure work tends to come first because it's the fastest, most visible win, and it buys the trust needed to tackle the harder, revenue-facing projects later. I've written before about sequencing a GTM engineering roadmap around this exact logic, and the order matters as much as the work itself.
Trying to sell a company on full-stack AI wiring before their basic sending infrastructure is stable is how GTM engineering projects fail. Not because the vision is wrong, but because nobody agreed on which problem came first.
Conclusion
If you're hiring a GTM engineer, or you are one, name the problem before you name the tool.
The title "GTM engineer" is going to keep expanding to cover more ground as the role matures. That's fine. But the companies and engineers who get the most out of it will be the ones who stop and ask which of the three jobs actually needs doing this quarter, instead of assuming the title alone answers that question.
Want to know exactly which GTM system to fix first?
Take the 60-second GTM Readiness Assessment
I'll tell you your biggest constraint and the exact next step to fix it.
Already know you want to work together? Skip the assessment and grab 30 minutes with me directly.
