What is a GTM Engineer, anyway?
GTM engineers combine people, process, tools, and data to produce more consistent outcomes and value for the organization. Read: "Everything Starts Out Looking Like a Toy" #238
Hi, I’m Greg 👋! I write weekly product essays, including system “handshakes”, the expectations for workflow, and the jobs to be done for data. What is Data Operations? was the first post in the series.
This week’s toy: an autonomous robot may be taking inventory at your local grocery store. While the initial goal might be to reduce labor by automatically checking shelves, it might have the side benefit of being able to answer: “where can I find [that thing] in this store"? Beware of hallucinating AI robots who can’t find pie filling and make up their own flavors. Edition 238 of this newsletter is here - it’s Feb 17, 2025.
Thanks for reading! Let me know if there’s a topic you’d like me to cover.
The Big Idea
A short long-form essay about data things
⚙️ What is a GTM Engineer, anyway?
In any company today there are many intersections between systems. The analog version looked a lot like this control board where similarly colored cables indicate similar kinds of data that need to flow from one place to another. At this level, it’s pretty hard to understand, so most people zoom out to concepts like “does the phone call go through” or “does a message sent here end up where it’s supposed to get to.”
The digital version of system intersections looks like a microservices handshake where one system asks another to do some work, providing context for current state, start, and end of a step. Both the calling step and the receiving step are responsible for following a known format. When errors happen, this breaking point needs to be resolved by a person (possibly, the GTM Engineer).
In a world of slow-moving tech companies, the person who solved this problem when things don’t work worked in Information Technology. They owned the systems, the support, and (sort of) the results. With the advent of Software as a Service tools, that effort got democratized, which is to say … no one owns it any more.
The people who understand how this mess of cables, dials, and switches go together don’t typically have a single title, and don’t always exist in every department. But they do share these characteristics:
Curiosity → they wonder: how does this work, and why is it behaving this way?
Tenacity → they don’t shy from hard problems
Operational Skill → they understand process and how to apply it to different systems even when it hasn’t been done before
Emotional intelligence → they reframe concepts for different learning styles and organizational levels
We’re talking about the GTM Engineer, which Brendan Short and Jason Salzman call “someone who can not only interpret data but also translate those insights into actionable strategies that enhance sales outcomes (aka revenue).”
Smoothly running systems ensure consistent data and system workflow across the organization. That means that a “company” (or other object) accessed from a sales system can be linked with a “company” in another system. (Yes, this seems obvious, and is also key to the diagram above.)
There’s an elephant 🐘 in the room. Most of the time, there are systems in place when you arrive. They work (sort of), and need to be understood, improved, and patched together to address any perceived problems.
We approach the idea of a GTM Engineer and think of an ideal: a solid base workflow system reinforced by system design.
Too often, you inherit the opposite: system design that designs the workflow. The GTM engineer is a necessary piece for modern GTM motions precisely because many items are combined in a bespoke way.
They literally need to translate what’s happening simultaneously between people and systems.
System Basics
The classic triad of “people, process, and technology” as an blueprint for building high performance teams stems from the 1965 paper “Applied Organizational Change in Industry” by Harold Levitt. In it, Levitt argues that a combination of people skills, effective process, and purpose-made tools is essential for success.
Levitt didn’t consider the impact of data, which Sean Gold, Rob Harper, and Jonathan Katz address in “People. Process. Technology. And Data. A Heretic’s View” (2003). Data intersects with the three pillars and creates new problems (and opportunities) for the GTM engineer.
This suggests that “GTM Engineer” is a subset of organizational skills that have impact beyond the GTM area of the business, and are currently focused on the go-to-market process.
The role of GTM Engineer implies the ability to learn, understand, and improve a process, along with the ability to put these solutions together and execute them. This is a crucial role for the organization because it plays a part in automating repetitive tasks and reducing cognitive load for team members.
What’s missing today about the discussion of GTM engineers? The best way to organize, document, and complete the work so that it doesn’t end up locked in a single system.
We’d like this work to be:
well-scoped
with a limited number of simultaneous works in progress
highly effective and levered
and focused on continuous delivery and value
One philosophy that I find compelling is the Team Topologies playbook, which defines a few concepts that overlap with the work GTM engineers do already:
Cross-functional collaboration → teams are aligned to deliver a product or service to various teams
Defined interaction modes → you’re either collaborating, facilitating, or providing a product as a service
Focus on reducing cognitive load → as a north star, make things easier for your teammates and your organization
Combine these ideas with the work already being done by GTM Engineers and you have a recipe for combining the ability to bring ops, data, and sales together with broader organizational impact.
What’s the takeaway? “GTM Engineer” is the latest description for team members that cross boundaries, deliver results, and improve team outcomes through improved system design, integration, and automation with GTM tools. These skills aren’t just for GTM - they can improve ops across the company.
Links for Reading and Sharing
These are links that caught my 👀
1/ Just add … intent - Kristen Berman shares the story of Betty Crocker cake mixes (yes, that Betty Crocker) to point out that when people do self-directed study or building, they like the results better. This is pretty important for AI features, because it suggests that “magically fix it with ✨” might be the wrong product focus. “Give me AI suggestions ✨ to do it myself” is more on the right track.
2/ Turn that dial - Casper Kessels writes a fantastic essay on in-car design and the use of haptic feedback to improve the familiar radio or climate control dial in your car. It’s the combination of analog and digital that sticks with me here when you think about the considerations you need to make for a control, especially when you’re likely to have partial attention and you’re not looking at the dial itself.
3/ Find your own voice - A reminder that your opinion and way of doing things matters, even if it’s not the norm. This might also mean that the norm you’re looking at is an equilibrium and not necessarily the best solution. This is super important when considering outcomes delivered by an AI stack. The next token might be the most likely one, and also wrong. (Context matters)
What to do next
Hit reply if you’ve got links to share, data stories, or want to say hello.
The next big thing always starts out being dismissed as a “toy.” - Chris Dixon