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.
