Hiring a Great GTM Engineer Is Actually Hard
These observations are from helping clients with GTM engineer hiring, and observing the GTM engineering market at large.
This sounds easy in theory, especially as a firm that specializes in GTM engineering.
In reality, this is actually quite difficult. It sounds easy - someone who can build the systems that make outbound and revenue operations actually work. Data flows, enrichment pipelines, automation architecture, AI workflows, campaign infrastructure. But the moment you start interviewing, the gap between the job description and the talent pool becomes painfully obvious.
The four near-misses
There are four types of people who show up when you post a GTM engineer position, and each one is missing something critical.
The software engineer. Strong technically - can write code, build APIs, think in systems. But they’ve never spent a day inside a B2B sales org. They don’t understand why a 2% reply rate might actually good, or why your enrichment pipeline needs to handle the fact that 30% of your contact data will be wrong by next quarter. They build elegant solutions to the wrong problems.
The analytical ex-SDR. This person has been on the frontlines of the sales motion. They know the buyer journey because they’ve walked it hundreds of times. They’ve probably built some impressive spreadsheets to fix their own problems as an SDR, maybe even learned a bit of SQL. But they will hit a wall when you ask them to wire up an automation or Clay formula that chains three API calls together. The intuition is there, but the technical muscle isn’t. At least not yet.
The RevOps hire. Mastered the CRM. Owns the Salesforce instance. Can build reports and dashboards for nearly every use case. But they’re stuck inside the GUI. And you will need more then that. You will need things like a custom enrichment pipeline, a lead scoring model that pulls from six different data sources, or an agent workflow that triages replies. This is usually outside of their comfort zone.
The Claude Code and Clay power user. This is the newest archetype, and honestly the most exciting one. They’ve gone deep on the tool stack. They can build automations that look like magic. But there’s a stereotype here that keeps proving true: when your primary skill is a hammer, everything starts looking like a nail. They’ll automate a process that shouldn’t exist in the first place, or build a beautiful enrichment workflow for a segment that was never going to convert.
Each of these people is genuinely talented. Any of them could be the right hire for the right role. But none of them are perfect GTM engineers - not the way the role actually needs to work.
What the role actually requires
The most effective GTM engineers we’ve worked with share three overlapping capabilities.
Technical fluency. Not “can code” in the software engineering sense, though that helps. More like: comfortable working with APIs, can read documentation and figure out how to connect systems, understands data schemas well enough to design an enrichment pipeline from scratch. They think in inputs and outputs, not features and buttons.
GTM understanding. They know what a good sales org looks like. They understand outbound metrics, sales training, lead enrichment, competitor battle cards. They can look at sales performance and know whether the problem is the data quality, talk tracks, or sales enablement. This isn’t something you pick up from a blog post. It comes from doing the work inside the sales org.
AI-native thinking. This is the newest layer, and increasingly the most important one. My biggest takeaway as an early Clay power user is that the toughest skillset isn’t about mastering the tool stack or knowing how to configure workflows or integrations you can build. The most important skill is the ability to orchestrate AI to do what you want it to do - while accounting for the edge cases, the bad data, the weird inputs that break everything at 2 AM. Can they design a prompt chain that triages incoming replies and handles the ambiguous ones gracefully? Can they build an agent workflow that does research, personalization, and quality checks without constant human intervention - and that degrades predictably when something unexpected shows up? A lot of people think this is just about knowing which AI tools exist (and keeping up with this in reality is nearly impossible). In practice, it’s about understanding how to decompose a problem into steps that a model can handle reliably, and knowing where the guardrails need to go. Knowing which problems to solve, how to solve them, and how to prepare for inevitable issues while knowing how to iterate through to production.
The Venn diagram of people who are strong in all three is… small.
The chart that explains everything
Bloomberry published an analysis of 1,000 GTM engineering job postings, and the growth curve tells the whole story.
From essentially zero postings in 2020 to over 100 new openings per month by late 2025. The demand more than doubled in a single year.
This tells you about demand. The other half is the supply curve, which is growing but not at the same pace. Universities don’t teach this. This knowledge is mostly tacit. We’re teaching this to clients, and soon to prospective GTM engineers.
The people who have these skills usually built them by accident - by being the RevOps person who happened to learn Python, or the engineer who ended up on a sales team, or the SDR who got obsessed with Clay and never looked back.
What this means if you’re building a team
If you’re a founder or sales leader trying to hire for this role, a few things are worth internalizing.
Stop looking for the finished product. The person who checks all three boxes out of the gate is being courted by ten other companies right now. You’re probably not going to outbid them. Instead, find someone who’s strong in two of the three and genuinely hungry to learn the third. The ex-SDR who taught themselves Clay and is now messing around with Claude Code on weekends - that person might be your best bet.
Build the role, don’t just post it. A job posting that says “GTM Engineer” and then lists 47 tools isn’t going to attract the right people. It’s going to attract the tool-stack collector. Define the role by the problems you need solved, not the technologies you think you need. “We need someone who can take a list of 10,000 companies, figure out which 200 are actually worth talking to right now, and build the system that surfaces them automatically” - is much more likely to yield the right hire who has worked on this problem before. There is a bit of performance theatre happening at the moment when it comes to GTM tech stack (we are also guilty of this!)
Invest in the learning loop. The best GTM engineers we’ve seen are the ones who are constantly experimenting. Give them room to run tests, break things, and iterate. If you hire someone with the right instincts and then lock them into a rigid process, you’ve just bought a very expensive SDR.