GTM engineering is new. The work behind it isn’t.

There is a new role title showing up more often: GTM engineer.

I like it, mostly because it gives a name to work many people in startups have already been doing for years. Especially in smaller companies, you rarely stay inside one neat job description. You might start by building a campaign, then realise the CRM data needed for targeting is unreliable. You fix the data, notice the lead routing is wrong, build an automation, check the attribution and eventually end up trying to understand why the whole funnel behaves differently from what everyone expected.

For a long time, this kind of work sat somewhere between growth marketing, RevOps, marketing operations and “the person who knows how the system actually works.” GTM engineering is a useful name for it, but I think the interesting part of the role is not really the engineering.

The ability to build things has become much easier. No-code tools already moved a lot of work away from developers, and AI is pushing that much further. Today, someone working in marketing or RevOps can connect APIs, manipulate data, build automations and even create small internal applications without being a traditional software engineer. I have noticed the same thing in my own work. Tasks that would previously have required development resources are increasingly things I can prototype or build myself with tools like HubSpot, n8n, Clay and AI coding tools.

That changes where the real value is.

Building the wrong thing faster is not much of an improvement

The danger is that easier building also makes it easier to automate things that should probably not exist in the first place.

CRM adoption is a good example. Imagine salespeople are not keeping their opportunities updated. It is relatively easy to build a workflow that detects missing fields, reminds the rep, escalates the issue to their manager and creates a dashboard showing who is compliant. Technically, the system works.

But it may be solving the wrong problem.

Much of the information we ask salespeople to enter manually already exists somewhere else. It is in meeting transcripts, emails, calendar events and notes. If that is the case, automating reminders is just a more sophisticated way of nagging people to duplicate information. A better solution might be to collect the context automatically and ask the salesperson to confirm or correct it.

I see versions of this problem quite often. Someone asks for a dashboard, but the real issue is that nobody agrees on what the metric means. A team wants more enrichment, but the problem is not missing data, it is unclear segmentation. Sales wants more leads, while a large part of the existing pipeline is going nowhere. Someone wants an AI agent when a deterministic automation would actually be more reliable.

This is where I think the “GTM” part of GTM engineer matters more than the “engineer” part. You need to understand enough about the customer, the sales process, the data and the commercial goal to recognise what problem you are actually solving before you start building.

The role sits between functions

Many GTM problems are difficult precisely because they do not belong cleanly to one team.

Marketing can generate the right accounts but fail to pass useful context to sales. Sales can learn something important in a customer meeting, but that information never makes it into the CRM. RevOps can build a perfectly functioning process that salespeople avoid because it creates too much admin. An AI tool can produce excellent output in isolation but fail in daily use because it does not know enough about the customer, account or deal.

These are not purely marketing, sales or technical problems. They sit between functions.

That is also why people doing this kind of work often end up with unusually broad toolkits. You need to understand the CRM well enough to change it, automation well enough to connect systems, analytics well enough to know whether something worked, and sales and marketing well enough to know why anyone should care.

I recognise quite a lot of my own career in that description. I have worked in sales, growth and marketing, but over time more and more of my work has involved CRM, automation, data and now AI. It was not really a deliberate move towards becoming more technical. It happened because solving the marketing problem often required fixing something outside marketing.

If the lead process does not work, writing another campaign does not solve it. If nobody trusts the CRM, another dashboard does not solve it. If an AI workflow has no reliable context, improving the prompt does not solve it.

Eventually you end up working on the system around the work.

AI makes this role more important, not less

This is also why I expect GTM engineering to become more common.

AI is making software creation cheaper. Small internal tools that would have been unrealistic to build a few years ago can now be put together quickly. General-purpose AI can work with CRM data, analyse conversations, research accounts and generate content. A single operator can do significantly more than before.

But easier building does not remove the need for judgment. It probably increases it.

When building something costs months and requires engineering resources, there is naturally quite a high threshold for starting. When you can prototype something in an afternoon, that threshold disappears. Companies can end up with dozens of automations, agents and internal tools, each individually reasonable but collectively making the system harder to understand.

Someone still needs to decide what should be automated, what should stay manual, where specialised software makes sense and where a small internal workflow is enough.

That is why I would not define a GTM engineer simply as a technical RevOps person or someone who knows how to use Clay and n8n. Those skills help, but tools change quickly. The more durable skill is being able to move from a commercial problem to a working system without losing sight of why you are building it.

So, is GTM engineering genuinely a new role? I am not sure.

I think many startup operators have been doing versions of it for a long time. What has changed is how much one person can now build, how interconnected the GTM stack has become, and how quickly the boundary between an idea and a working system is disappearing.

The title might be new.

The need for someone who understands how the whole thing actually works is not.