What a GTM engineer actually does

I am a GTM engineer. The title is recent enough that most job descriptions using it are still guessing, so it gets used for three different jobs: a sales rep with some tooling, a marketer who can write SQL, and whatever the last person in the role happened to do.

Here is the version I actually do, in the order it happens.

It starts with a definition, not a list

A company tells me who its best customer is. Usually that answer is too broad to build on. “B2B SaaS companies with 50 to 200 employees” is a filter, not a customer.

The useful version names an observable state. Not a size band but a condition you can detect from outside: they just hired their first sales hire, they run a specific competitor’s software, they have job postings for a role that implies the problem. If the definition cannot be observed in data, it cannot be built into a system, and the whole thing stays a manual list someone rebuilds every quarter.

Getting this right is most of the job. Everything downstream inherits it.

Then the data, which is where the work really is

Sourcing the list is the easy part. Making every row carry the signals the message needs is not.

That means enrichment waterfalls: provider one, and where it comes back empty, provider two, then three, each attempt gated so it only fires when the previous one failed. It means verification before anything is sent, because an unverified address is not a lead, it is a bounce with a name attached. And it means hard gates - conditions that must be satisfied before a record is allowed anywhere near a send.

Most of my time goes here. Not because it is interesting to describe, but because every failure further down turns out to have started as a data problem wearing a copy problem’s clothes.

Segmentation is a copy decision made in data

A market is not one audience, and a single sequence to all of it is the most common way outbound quietly fails. The message that works on a company already running a competitor’s product is not the message for a company that has never considered the category.

So the market gets split into segments that deserve genuinely different messages, and each segment gets wired to its own sequence. Which means the segment boundary has to be computable, and every variable a sequence references has to be populated for every record routed to it. A sequence with an empty variable does not fail loudly. It sends “Hi , I saw that “ to a real person.

The sending infrastructure

Domains, inboxes, warmup, sending schedules, deliverability monitoring. This is the part that looks like plumbing because it is.

The constraint that governs all of it: sending reputation is slow to build and fast to destroy, and the incentives inside a company always push toward more volume today. Someone has to hold the line where volume growth stops being free. That is usually me, and it is usually unpopular for about a month.

Then the automation, and only then

Manual first, automated second. I run a segment by hand until it produces replies, then automate the parts that proved themselves.

This ordering is the single most load-bearing opinion I have about the work. Most outbound that fails was automated before it worked. Automating a broken process does not reveal the break, it just reaches more people with it, faster, while the dashboard reports throughput and everyone assumes throughput is progress.

The last piece is making the system report on itself: scrapers, scheduled jobs, dashboards, alerts. Not for the reporting, but so nobody has to remember to check anything. A check that depends on a human remembering is not a check.

So what is the job

Closer to data and infrastructure engineering than to sales. The output is not a list and not a campaign. It is a system somebody keeps: it can be re-run, the reasons for its decisions are inspectable, and when it breaks it says so.

The reason the role exists at all is that these pieces used to belong to four different people who each optimised their own part. The list got bigger, the copy got cleverer, the sending got more aggressive, and nobody owned whether the thing worked end to end.

That is the job. Owning end to end.

If that sounds like what you need, get in touch.

--- title: What a GTM engineer actually does date: 2026-08-04 tags: gtm-engineering, outbound url: https://mihajlomaiga.com/blog/what-a-gtm-engineer-actually-does --- I am a GTM engineer. The title is recent enough that most job descriptions using it are still guessing, so it gets used for three different jobs: a sales rep with some tooling, a marketer who can write SQL, and whatever the last person in the role happened to do. Here is the version I actually do, in the order it happens. ## It starts with a definition, not a list A company tells me who its best customer is. Usually that answer is too broad to build on. "B2B SaaS companies with 50 to 200 employees" is a filter, not a customer. The useful version names an observable state. Not a size band but a condition you can detect from outside: they just hired their first sales hire, they run a specific competitor's software, they have job postings for a role that implies the problem. If the definition cannot be observed in data, it cannot be built into a system, and the whole thing stays a manual list someone rebuilds every quarter. Getting this right is most of the job. Everything downstream inherits it. ## Then the data, which is where the work really is Sourcing the list is the easy part. Making every row carry the signals the message needs is not. That means enrichment waterfalls: provider one, and where it comes back empty, provider two, then three, each attempt gated so it only fires when the previous one failed. It means verification before anything is sent, because an unverified address is not a lead, it is a bounce with a name attached. And it means hard gates - conditions that must be satisfied before a record is allowed anywhere near a send. Most of my time goes here. Not because it is interesting to describe, but because every failure further down turns out to have started as a data problem wearing a copy problem's clothes. ## Segmentation is a copy decision made in data A market is not one audience, and a single sequence to all of it is the most common way outbound quietly fails. The message that works on a company already running a competitor's product is not the message for a company that has never considered the category. So the market gets split into segments that deserve genuinely different messages, and each segment gets wired to its own sequence. Which means the segment boundary has to be computable, and every variable a sequence references has to be populated for every record routed to it. A sequence with an empty variable does not fail loudly. It sends "Hi , I saw that " to a real person. ## The sending infrastructure Domains, inboxes, warmup, sending schedules, deliverability monitoring. This is the part that looks like plumbing because it is. The constraint that governs all of it: sending reputation is slow to build and fast to destroy, and the incentives inside a company always push toward more volume today. Someone has to hold the line where volume growth stops being free. That is usually me, and it is usually unpopular for about a month. ## Then the automation, and only then Manual first, automated second. I run a segment by hand until it produces replies, then automate the parts that proved themselves. This ordering is the single most load-bearing opinion I have about the work. Most outbound that fails was automated before it worked. Automating a broken process does not reveal the break, it just reaches more people with it, faster, while the dashboard reports throughput and everyone assumes throughput is progress. The last piece is making the system report on itself: scrapers, scheduled jobs, dashboards, alerts. Not for the reporting, but so nobody has to remember to check anything. A check that depends on a human remembering is not a check. ## So what is the job Closer to data and infrastructure engineering than to sales. The output is not a list and not a campaign. It is a system somebody keeps: it can be re-run, the reasons for its decisions are inspectable, and when it breaks it says so. The reason the role exists at all is that these pieces used to belong to four different people who each optimised their own part. The list got bigger, the copy got cleverer, the sending got more aggressive, and nobody owned whether the thing worked end to end. That is the job. Owning end to end. If that sounds like what you need, [get in touch](mailto:mihajlo@prospeqt.co).