Last week at the Pavilion CRO Summit it became pretty clear that CROs (especially B2B SaaS CROs) are anxious. They’re anxious about AI, about buyer behavior, and about new GTM motions.
The perpetually unprecedented-ness of it all can get a little exhausting and the solutions seem all too abstract. Become AI native or die! Ok, great. But, like, what should I actually do?
Today I want to talk about one practical thing you might want to do: get a GTM Engineer. More on that in a second.
One theme ran through nearly every CRO Summit talk—the sales team of the future is going to be a tightly-knit combination of technology and people operating as a system. That was the crux of of my 10x Sales Rep presentation and it featured prominently in Jacco van der Kooij’s talk as well.
Here’s how Jacco framed it:
This is a pretty succinct visualization of “the old playbook is dead”. Anything that uses people as the only input scales pretty much linearly—one more person, one more unit of work. For its entire history, sales (even the technology-enabled “predictable revenue” era) has scaled simply by adding more people. And it did so linearly.
On the other hand, systems that combine people with technology can scale exponentially. Let me illustrate that point with something closely associated with B2B SaaS sales and AI: corn yields since 1866.
Guess what happened around 1940? We deployed way more technology—tractors, fertilizers, pesticides, etc. Farming became a tech-enabled system.
I wonder if farmers went around saying “the old playbook is dead” back then? Maybe not but I’m sure many old school farmers who were used to the process that created ~25 bushels per acre didn’t adapt well to the new ways that now produce 180 bushels per acre.
I imagine this new era included a lot of experimentation and the introduction of more technical and scientific people to farms that knew how to wield these new technologies effectively. The farmers who learned the tech and welcomed the newcomers scaled—the farmers that didn’t went out of business.
We’re undergoing a similar change in SaaS sales today. AI is the fertilizer1 and we’re on the cusp of a major productivity increase. And there’s an emerging role that doesn’t quite look like what we’re used to out on the sales farm: the GTM Engineer.
Over the past few weeks I’ve talked to three different GTM Engineering experts about this new role:
Brendan Short, Founder of The Signal newsletter
Joe Petruzzi, Founder and CEO of Organic Outreach
Andreas Wernicke, GTM Consultant at Snowball Consult
Today I’m focusing on the interview with Brendan. He’s written some fantastic articles over on The Signal about GTM Engineering—including my favorite, The Rise of the GTM Engineer. Prior to The Signal, he was an SDR before the role existed, founded a couple of GTM tech companies and led Global SDR operations at Zoom during the pandemic. With that kind of resume, I knew he’d be the perfect person to help contextualize this role for CROs.
You can watch the full interview right here on Substack at the top of this post or check it out on YouTube. If you prefer text, read on for some of the high points of the conversation.
Programming note: I’ll cover the other interviews in a later post. If you can’t wait (and why should you?) I’ve published the interviews over on our YouTube channel. There’s great stuff about using AI to do precision account targeting with Andreas and overcoming low conversion rates with Joe.
On the role itself
“It is for leverage. It is for creating efficiencies in your go-to-market org... things that literally weren’t possible 18 months ago before we had AI.”
I love Brendan’s focus on leverage here. The entire purpose of this role is to find GTM leverage through technology—a way to make a unit of human input have a much larger GTM output. Just like our corn yields up above. (Though he didn’t put it that way. Oddly enough corn never came up in our conversation.)
To do this requires a particular set of skills which comprise the GTM Engineer role. While we discussed this, it’s probably easiest to reuse Brendan’s venn diagram from The Rise of the GTM Engineer:
Ultimately this role needs to bring together all the ultra-modern tools available today and deploy them in the service of more efficient GTM plays. That means proficiency in data, AI in all its myriad forms and a strong understanding of sales.
Brendan gives a simple, but powerful, example of this kind of leverage. Using AI to scrape information and learn more about accounts at scale can have a huge impact. If you can automate research on 40k accounts such that reps don’t have to do it, that creates phenomenal leverage.
That leverage takes the form of a) better books which reduces opportunity costs from chasing the wrong accounts and b) more selling time for reps. And it compounds—more selling time on better accounts yields more pipeline than either of those things on their own.
I’ve been barking up this tree for a while, with both the 3+1 ICP and the math behind why more prospects doesn’t actually yield more pipeline so it was good to hear it from someone else.
On where it fits in today’s GTM org
“It's a good sign something is new and messy when people don't have a good answer [for reporting structures]. I think this is a good example of that… I haven't really heard a compelling answer to that question where everybody aligns.”
Brendan ultimately leans towards defaulting the GTM Engineer role to RevOps. That, of course, begs the question of why this isn’t just an additional RevOps task as opposed to an entirely new role.
Brendan’s thesis is that current RevOps teams are spread too thin with their existing responsibilities and that this field is moving so fast that someone really needs to specialize in it.
Beyond that, RevOps is intended to be the team responsible for orchestrating the entire customer journey from prospect to expansion. Common GTM Engineering tasks like building a GTM data foundation2 and process automation fit well here.
One thing Brendan notes, in particular, is that traditional RevOps comp structures may not be the right fit for this role. He believes that GTM Engineers should have a significant portion of their comp come from pipeline or new business—more like a rep.
The other possible location for the GTM Engineer role is in demand gen under marketing. This is especially true in orgs where SDRs sit under marketing and the GTM Engineer role is more focused on top-of-funnel activities. This makes them somewhat like a growth marketer in a PLG company.
Speaking of the similarity to growth teams, there are some high profile companies (like Ramp) where growth teams report to a co-founder with the “moral authority” to cut across silos. It may not work for everyone but if there’s the right kind of founder that knows GTM, it could work to put a GTM Engineer under them.
On hiring
“A GTM engineer won’t help you find product-market fit. But once you find leverage, it’s obvious you need someone full-time.”
Brendan and I had a good debate about when to hire for the role. Much of that came down to the balance of learning what works vs scaling what already works. Brendan’s perspective is that a GTM Engineer is unlikely to have much of an impact if you’re still searching for product-market fit (PMF). Not only are there no known-good processes to scale, any experiments they run won’t be terribly effective either.
Brendan, naturally, has an article that goes into more detail on when you should hire. Check that out if you want more than you get in the conversation.
Another big area we discussed was whether to hire a consultant, hire an FTE from outside the company or promote from within. Ultimately GTM Engineering will likely need to be a core competency—you can experiment with some consulting initially but you’ll want an FTE eventually.
So where can you find these FTEs for a role that’s existed maybe ~18 months? There just aren’t that many folks who have real experience in a GTM Engineer role so you may do just as well by plucking someone from your existing team with potential.
On balance, Brendan suggests that a seller with technical proficiency might be better suited to the role than a more technical person with some sales proficiency. That would probably lead you to the classic path of finding an SDR that likes tools more than sales and trying to upskill them.
It is, of course, hard to upskill people if you don’t have anyone available who already knows the role so a good place to start is Brendan’s article How to Become a GTM Engineer.
Whether you hire internally or externally, you’ll probably want to put together a job description. To help with that, here are a few job postings for inspiration: Document Crunch3, Teleport and Tractian.
Next steps for CROs
Brendan shares three things you should go do right now if you’re considering adding a GTM Engineer role:
Write down what you believe are your main GTM bottlenecks.
Go discuss it with AI—share your GTM motion and bottlenecks with ChatGPT and then ask for places where AI and automation could help.
Actually test something yourself. Don’t just decide to designate a person to go spend a few hours playing around with it. These tools are all low code and you’ll likely learn something. If the CEO of Google can carve out some time to vibe code, so can you.
Once you’ve done those things, you’ll start to see what’s possible and what kind of leverage you could get from a GTM Engineer.
No issue next week! I’ll be enjoying some time off with the family on the lovely beaches of North Carolina. See you on the 26th.
Possibly in more ways than one. There’s a very good bullshit analogy in here somewhere that I’ll just relegate to this footnote.
See Andreas Wernicke’s interview for some great insights here.
I can personally vouch for the folks at Document Crunch. They’re great people.
Share this post