And why does it matter?

In current usage, it can mean one of three different things:

• AI-first salesperson. This is how go-to-market automation startup powerhouse Clay (who coined the term) use it internally: rather than hiring 'account executives', they hire smart technical reps that can automate a bunch of their work.
• AI-first marketing automation person. This is mostly how it's used outside of Clay. If you're a software product that wants to scale via outbound email, you hire a GTM engineer(ing agency) and they build AI-driven outbound campaigns for you with Clay and n8n.
• AI-first operations automation person. While the GTME term is mostly used to refer to outbound and marketing emails specifically, it also is sometimes used to AI-assisted workflow builders more broadly. This roughly maps onto what Clay call the other GTM engineering operations team.

You might object to the above by saying that that covers basically any go-to-market function. Which would be a reasonable objection. While Clay's claiming of this term was an act of branding genius, it's also quickly become close to devoid of meaning.

Now, in light of the above, it would be helpful for someone to come along and clear up this confusion by providing a single, clear, unified definition of what GTM Engineering really is, either through some sort of grand unified theory or some sort of convincing argument that only one of the above is the real definition.

Unfortunately I'm not going to do that. Instead, I intend to muddy the waters further by introducing my own definition of the term, which is different to all of the above. Wait, hear me out.

Are we all engineers now?

It's pretty popular now to reframe job titles as being 'thing engineers'. Customer support reps are now 'customer support engineers'. Web developers are 'design engineers'.

This kind of rebranding works for two reasons. Firstly it works as a prestige boost that helps recruit talented people to do unglamorous work (Mark Zuckerberg famously and pretty ingeniously rebranded the dull-sounding business analyst role as 'data science' in order to persuade people with PhDs to come and take it, and repeated this trick by rebranding marketing as 'growth').

Secondly it boosts the prestige of people actually doing those roles. No one wants to tell the girl you just met at a house party that you work as a CRM consultant (trust me, I've tried). But GTM engineer? It sounds cool. Mysterious. Ingenious. OK, yeah, not something that's exactly turning heads. But it's definitely cooler.

So viewed from that angle, you might wonder why this sort of debate matters at all. Maybe this stuff is all just a branding exercise to allow thirty-something remote workers to feel less remorseful about the fact that they spend their working hours making little rounded-square Screen Studio videos about how to more efficiently blast people with outbound email.

However, I disagree.

How I think about GTM engineering

Cutting to the chase: for me, the most interesting interpretation of the GTME role is the most literal one: applying basic software engineering principles to problems faced by go-to-market orgs. Here are some examples:

Aspect	Traditional RevOps	GTM eng
Modularity	Monolithic systems that handle everything	Ecosystem of specialized tools
QA	Reliance on manual testing	Automated data testing as standard
Observability	Minimal to no automated alerting on failures	Nothing shipped without observability
Data integration	One-off integrations (M x N)	Centralized data integration (M + N)
UX	Reactive engagement with internal users	GTM team are your customers
Technology selection	Tool emphasis - 'salesforce expert'	Tools chosen flexibly per use-case
Mindset	Implement standard framework	Approach each engagement from first principles
Risk management	Reduce risk through checklists	Reduce risk through incremental rollout

Is this a new idea?

I don't think so - the idea of taking software engineers and applying them to fix messy go-to-market processes has been tried before at significant scale. It's exactly what Palantir do.

• Technical background, commercial focus. Palantir's 'forward deployed engineer' model involves hiring talented software engineers and then shipping them off to work directly with customers on hairy business problems like 'how do we double A380 production this year for Airbus'
• Data model emphasis. Palantir talk constantly about the importance of the 'ontology' in a way that can be confusing due to the internal jargon they use for it, but this is just describing the business data model.
• Customer obsession: Palantir are the most effective founder factory on the planet because they have a culture of obsessing over customer problems and figuring out scrappy solutions to them on the fly.
• Data integration focus. Palantir have invested huge amounts of effort in developing proprietary data integration tech that allows them to ingest federated data from any source in an organization, transform it, and access it via their ontology data model.

Now obviously there's a lot that's unique about Palantir. They serve some of the largest customers in the world, often in highly regulated sectors. Not all of what they do will transfer to startups and growth stage tech companies. But it's an interesting lens to look at this through.

Does AI mostly remove jobs, or create them?

If we put my own speculation aside for the moment and return to the orthodox definition of a GTM engineer - someone who configures Clay and uses it for clients - it's interesting to observe that this role is one which defies the common wisdom about AI, which is that it's going to increase unemployment of technical people. Instead, we see that Clay's ability to build an AI-native platform has actually created massive demand for the specialized niche of people that know how to use their tool well.

Clay is a power tool. It's not simple. It feels like it was built by a product team that shipped every user request they ever received, in the best way. So observing the current form of the GTM engineer, it's one who is an expert in a particular AI-native power tool and who can use that tool to create value for companies. Again that sounds pretty Palantir-esque! The role of a Palantir FDE is to implement their power tool for companies to help them leverage AI, albeit it's a vastly different tool.

What's next

I don't think that Palantir is going to eat all of software, but I do think that the Palantir model remains underrated based on my experience going deeper on this space over the past few months. I also think that the Clay model remains under-exploited: so many SAAS tools right now are leaning into the 'autonomous software' model - decreasing human engagement - when there appears plenty of evidence that the real AI opportunity lies in creating power tools.