How To Build a GTM Engineering Function and Evaluate Talent for the Role

Should You Hire a GTM Engineer With a Technical Background or a Sales Background?

My position is pretty straightforward: bias heavily toward sales and business acumen.

We're betting on the frontier models and the tooling around them to keep getting better. Every month, the bar for what you can accomplish without deep technical knowledge drops lower. You don't need to write Apex or SOQL to interact with Salesforce through Claude Code. You need to know what actually needs to happen in the sales process, what data matters, what workflows create leverage.

You can literally just ask the tool if it knows how to solve your problem. Open Cursor or Claude Code and type "do you know how to bulk update Salesforce opportunity stages based on last activity date?" and it'll either do it or tell you it can't. The figuring-out portion of this work is not that hard if you understand what questions to ask. And understanding what questions to ask comes from knowing the sales domain, not from knowing how to code.

The jobs-to-be-done knowledge is what matters. And there's a trap I think a lot of people fall into.

There's a category of AI-powered work that I'd describe as dopamine-hit workflows. Building a CRUD app with a sleek frontend by prompting Cursor is genuinely cool. It feels productive. You get that rush of "look what I just made." But does it help close deals? Does it drive pipeline? Almost certainly not.

Someone with deep sales experience will naturally gravitate toward workflows that solve actual business problems because they've lived those problems. They know what the bottleneck is at each stage of the funnel. Someone who's primarily a technical builder, without that sales context, is going to be drawn toward building things that are impressive but not necessarily impactful. They'll optimize for the build, not the outcome.

That's the primary problem with technical people and technical founders: it's too easy to build complexity into things, thinking that is going to be effective.

My experience as a sales-first GTM engineer is that I've been able to take my experience using sales tools and apply a product management lens to these things. I've tested and iterated with end users to make sure that the workflows I'm building actually are doing what they're supposed to be doing and converting more business.

If you've never carried a bag, you've never sold anything, and you've never gotten a contract back, then it's really hard to know what workflows are actually going to produce those outcomes.

How Realistic Is It to Get Salespeople Using Git and Claude Code?

People ask me this and they'll be like, "Oh, salespeople aren't gonna be using Git." Yeah, I mean, probably not. I don't think you're going to get your account executives to become GTM engineers, and I think that's probably a distraction. You want somebody scoped for this particular function.

Maybe you could encourage somebody internally to go test some of this stuff out and see if they have any aptitude or appetite for it. But likely you're just going to have to find somebody to do it, or learn it yourself. Honestly, that's always what I recommend.

The talent market right now is really messed up for these kinds of roles. It's tough to find people who have the sales, business, and engineering acumen to actually build these workflows and systems.

If you're hiring for it, get them to walk you through a production workflow. Have them explain how they're hosting it and how they coded it. Do they use Cursor? Do they use Claude Code? How did those systems talk to each other? See if they understand the context layer of AI to help them build better systems. Get them to show you an app in production.

How Should You Handle Permissioning and Security When Plugging AI Into Sales Tools?

Security and access control are real questions once you start plugging AI into production systems, and I want to be honest about the limits of my knowledge here because there's a lot of hand-waving in this space. Cybersecurity basics are not some sort of magical thing that nobody can understand. There are a lot of people making a lot of money trying to convince you that your vibe-coded apps and workflows are going to sink your company. Is there some truth to this? Yes, however, the cybersecurity industry is based on fear, so I would largely ignore most of them.

Salesforce provides a decent mental model. When you use the Salesforce CLI, you only have access to the permissions that your user profile grants by default. If you're a sales rep, you see what a sales rep sees. If you're an admin, you see what an admin sees. The tool doesn't elevate your privileges just because you're accessing data programmatically.

That's roughly how I think about plugging APIs into Claude Code in an ideal state. Each user has their own API key or MCP connection. The applications reflect those same permission boundaries in their API access. Your AI assistant can only touch what you'd be able to touch yourself.

Should You Build an ETL Pipeline for Sales Data or Just Give AI Tools Direct API Access?

Hey, listen, I just give Cursor and Grok bot access to all of the tools. Could I be more token efficient here? Yes, and eventually I will need to be. Honestly, I think with the deflation and cost from Chinese and open-source models, it's easier to switch it out for GLM or Composer 2.5 or something rather than worrying about token cost optimization.

Is Anyone Actually Hiring GTM Engineers With a Clear Job Description?

The founder asked whether anyone has definitively scoped what GTM engineering is, what the responsibilities should be, how much you should pay someone. The honest answer is no. Anyone who claims otherwise is selling something or trying to prop themselves up as a thought leader.

I had a previous role. I took the job because the VP of Growth had a very defined set of expectations and pillars that he wanted me to operate in.

SDR outbound, like running campaigns with the SDRs. Every week I would hand off all the non-responsive leads from campaigns we sent out, each with their own kind of hypothesis behind them. I would give the SDRs a call script or something to give them a good reason to call.

I ran the whole cold email program at this company: webinars, truly cold email, events, things like that.

Evergreen infrastructure. You could think of that as both internal applications and automation, as well as building sophisticated lead magnets and things like that.

People ask whether GTM engineers should learn Claude Code or just stick with Clay and SmartLead. I think that question misses the point. I think of GTM Engineering as a senior IC role, analogous to a staff engineer on a software development team. These people should have wide leverage, latitude, and access across the business. This is not an entry-level position.

If all you need is someone to send a high volume of outbound emails, there are talented, cost-effective people all over the world who do that work well. There's nothing wrong with that function, and those folks add real value. But it's not economically sensible to pay someone $180k to $300k a year to do it. At that compensation level, you want someone operating at a higher altitude.

Is GTM Engineering a Role or a Set of Principles?

GTM Engineering is better understood as a set of principles than a defined role. The core principle: apply software solutions to sales problems. Not "go buy a tool." Where can we insert code, no-code workflows, AI, and automation to create real leverage in the revenue function?

What that looks like depends entirely on the stage of company you're at.

At a very early stage (under 20 people), you want a generalist. Someone who can run outbound, close deals, stand up a Salesforce instance, build automations, and has broad technical proficiency across a range of tools. Their job is to build the foundation that scales as the business grows. They need to be comfortable doing hands-on IC work while also thinking about what systems will hold up at 10x the current volume.

At a larger organization, the skill set shifts. You need someone who can leverage political capital internally to get things done. This is a gap I've noticed in a lot of GTM engineering talent: they come from agency backgrounds or junior-level positions where they could just build things independently. In a larger org, the ability to navigate stakeholders, get buy-in, and drive change management is just as important as the technical chops.

And if you hire someone for this kind of role, you need to give them the latitude to make changes. Otherwise you're going to be disappointed, because you've hired someone whose entire value proposition is transforming how things work, and then you've put them in a box.

What Does It Actually Mean to Build the "AI Brain" of a Sales Organization?

As the conversation went on, the founder's questions kept getting more abstract, and so did my thinking. We started by talking about hiring a GTM engineer, but by the end we were really talking about something bigger. It had me thinking about where my own work has been heading.

I've been spending less time on individual tools and workflows, and more time on what I'd call the AI brain of a sales organization. What does the architecture look like? What access does the brain need? What systems does it plug into? What should it be able to do autonomously, and where does it need a human to intervene?

And once it processes information and generates insights, where do those outputs go? Because an AI that can analyze your pipeline is interesting. An AI that can analyze your pipeline and then draft the follow-up emails, update the CRM records, flag the at-risk deals, and brief the AE before their next call, all without anyone logging into anything, that's a fundamentally different thing. That's what I mean by "where do the thoughts go."

Grokbot has access to all of the APIs. It's got tons of context on my data. It sends me a daily update every morning for leads that I need to follow up on, projects that I'm working on that I need to land the plane on, all that kind of stuff.

What's the right balance between read access and write access? How do you give an AI enough context to be useful without giving it enough rope to cause damage? How do you build institutional knowledge into the system so it gets smarter as the team uses it, rather than starting from scratch every session?

I don't have clean answers to most of these questions. But I think they're the right questions. The conversation about GTM engineering, what tools to use, who to hire, how to scope the role, is really a conversation about how your organization relates to AI as an operational layer. The specific tools and titles will keep shifting. The underlying design problem, how to build an intelligent system that amplifies what your sales team can do, is what's worth spending time on.

If you have questions about any of this stuff, or you're trying to hire GTM engineers, or you'd like us to build some of these systems for you, contact us with the form below.