Search a job board for "GTM engineer" and you are likely to find three different jobs under the same title. One is an outbound specialist who can wire together enrichment tools and send sequences at volume. One is a CRM administrator with a new name. One is a builder who designs and maintains the data, rules and automation that the whole commercial team runs on. The three pay differently, need different skills and succeed or fail by different measures.
In CloudNala's reading, the first version is the one advertised most often, and it is the least useful for a company like the one in this series. CloudNala's view is that a GTM engineer is the person who builds and maintains the go-to-market system described in Part 1: its data model, its signals and scores, its plays and its instrumentation. The role is defined by the work products it leaves behind, not by how many emails it causes to be sent. If the job is measured on meetings booked, it is an SDR job, however technical.
That distinction matters most for small teams. A company with ten people in sales and marketing cannot afford a specialist whose output disappears into a sequencing tool. It needs someone whose work makes everyone else's decisions better.
Lowveld Ledger is fictional, and its systems and figures are illustrative. As in Part 1, Lowveld Ledger is a Mbombela accounting and payroll software company with about 2,300 paying SMME customers, a sales and marketing team of nine, and five broken feedback loops on its system map. It is about to hire its first GTM engineer.
Why the title is confusing
Job titles in technology move faster than job content. "GTM engineer" has spread through software-company job ads and LinkedIn profiles, and the title itself tells you little about what the person will be asked to do. The CloudNala series AI Roles Decoded argues that you should read the verbs in a role, not the title, and the same applies here.
At Lowveld Ledger, the first draft of the job ad was written by copying three ads from other companies. It asked for "experience generating pipeline through automated outbound", "proficiency in enrichment and sequencing tools" and "a hunter mentality". It was an SDR ad with a tool list. The head of sales noticed that nothing in it would fix the five broken loops on the system map.
Define the role by verbs and work products
The leadership team rewrote the role from the system map outwards. For each broken loop and each missing definition, they asked what someone would have to do to fix it and what would exist afterwards that did not exist before.
Five verbs came out of that exercise.
Model the data. Decide what an account, a contact and an opportunity are, which system owns each field, and how duplicates are found and merged. The work product is a written data model and de-duplication rules, not a cleaner CRM for one week.
Instrument. Make the journey from first visit to paying customer visible in one place, including the product events that sales could not previously see. The work product is event tracking and funnel views that anyone in the team can read.
Build plays. Turn a commercial idea ("contact trial users who have just run their first test payroll") into a specified, routed, automated workflow with an owner and a success measure. The work product is a play specification plus the automation behind it. Part 6 covers this.
Test. Treat every new signal, rule or play as a hypothesis with a stated test and a decision date. The work product is an experiment log. Parts 4 and 9 cover this.
Maintain. Keep integrations, syncs and rules working, and know when they break. The work product is a tool inventory, runbooks and alerts.
None of these verbs is "send" or "book". The SDRs and account executives still do the selling. The GTM engineer makes sure they are selling to the right people, at the right moment, with the right context, and that the company learns from every outcome.
This mirrors what CloudNala has argued about measuring capability more generally: measure people through the work products they leave, not through activity counts.
Owns, shares and must not own
A role defined only by what it does will expand until it collides with everyone else. Lowveld Ledger also wrote down the boundaries.
Owns. The CRM data model, routing and automation rules, the signal catalogue and lead score, and the integrations between the CRM, the product database, the billing system and the webinar platform.
Shares. The target customer profile is shared with the head of sales, because it is a commercial judgement informed by data. Play design is shared with the marketing lead. Funnel reporting is shared with finance, because finance owns the revenue number. Data quality fixes are shared with everyone who types into the CRM.
Must not own. Quota and pipeline targets, the approval of outbound messages, customer relationships and consent decisions.
The last column deserves a sentence each. If the GTM engineer sets the pipeline target and also builds the score that defines what counts as pipeline, they mark their own homework. If they approve the messages their own automations send, there is no second pair of eyes on what the company says in its name. If they own customer relationships, the role turns back into selling. And consent decisions, whether a person may be contacted at all, belong with the information officer and the marketing lead under the company's privacy controls, which Part 10 covers.
Where the role should report
Reporting lines shape behaviour more than job descriptions do. Lowveld Ledger considered three options.
Under the head of sales. This is common, and it risks the role drifting towards whatever the sales team needs this week, which is usually more leads.
Under the marketing lead. This risks the opposite: a role that optimises the top of the funnel and never sees what happens after the handover.
Under the founder-CEO, with a dotted line to both. This is unusual for a company of Lowveld Ledger's size, and it was the option chosen. The reasoning was that the GTM engineer's job is to fix the loops between teams, and that work needs to sit above the teams it connects. In a larger company, the equivalent would be a revenue operations function reporting to the executive who owns the whole revenue number.
There is no universally right answer. The test is simple: can the person in this role tell the head of sales that a lead source is not working, and tell marketing that a campaign's leads never convert, without being overruled by the person the role reports to? If not, the reporting line is wrong.
How to measure the first ninety days
A GTM engineer measured on meetings booked will optimise for meetings booked. Lowveld Ledger measured its first hire on work products and on the health of the system.
For the first ninety days, the success measures were:
- Stage definitions written, agreed and visible in the CRM for every lifecycle stage, with marketing and sales reporting from the same definitions.
- Duplicate rate measured and falling, with de-duplication rules running automatically, not as a one-off clean-up.
- Payroll activation visible to sales on every trial account in the CRM, synced from the product database.
- Rejection reasons captured as a short coded list, not free text, with a monthly summary going back to marketing.
- A tool inventory listing every system, who owns it, what it costs and what it connects to.
None of those is a revenue number. Revenue is the outcome the whole system produces, and attributing it to one new hire in ninety days would be dishonest. What can be measured is whether the system now has the parts it was missing.
Skills that matter more than tool names
The rewritten job ad listed skills in this order: the ability to model data and write clear definitions; comfort with APIs, webhooks and at least one scripting language; experimental discipline (stating a hypothesis before acting); the ability to explain a rule to a sceptical salesperson; and experience with a CRM and a marketing automation platform. Specific tool names came last, with a note that the company would train on whatever it used.
Interviewing for those skills is covered in more depth in Hire on evidence, part of the AI Roles Decoded series. For a GTM engineer, the most useful single exercise is to hand the candidate an anonymised export with obvious duplicates and inconsistent stage names, and ask them to propose definitions and a de-duplication rule. The answer shows how they think about data, not how fast they can configure a tool.
Start this week
- Rewrite your GTM engineer job description as verbs and work products. If nothing in it would fix a broken loop on your system map, rewrite it again.
- Draw the owns, shares and must-not-own columns with the head of sales and the marketing lead, and agree them before you advertise.
- Write the ninety-day measures as work products, not as pipeline or meetings booked.
Next: Part 3, Start with revenue data you can trust. All parts are on the series page.
How CloudNala can help
CloudNala helps growing companies define go-to-market roles before they hire for them. We work from your system map to write the verbs, work products, boundaries and first-ninety-day measures for a GTM engineer or revenue operations role, and we review reporting lines so the role can fix the loops between teams rather than serve one of them.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book a Go-to-Market Systems Review or write to us at consult@cloudnala.co.za