Three Ways to Be a GTM Engineer: The Marketing Ops Engineer, the Web and Performance Engineer, and the AI Workflow Engineer

A CFO once showed me the pipeline report she actually used. It was a spreadsheet. The CRM had a pipeline report too, built by marketing, with charts. She did not trust it, because a year earlier she had traced one deal through it by hand and found the lead source had been overwritten three times. So every month she rebuilt the number herself. The marketing operations person who eventually earned her trust did one thing differently: he traced a record from form fill to closed-won before he touched a single setting, and he showed her the trace.

That is the GTM Engineer as I described the role in my book: the person who builds systems that carry signal at scale without corrupting it. It is the seat that has changed the most since I wrote that essay, because AI moved from being a feature of the stack to being most of the stack. And like the other three Syntropy roles, the people who do it well do it from three different starting points. I have given each a name, because a name holds a standard. They are composites, built from engineers I have worked with, not real colleagues.

T2D3 OS names the same three when it does Engineer work. That part comes at the end.

Daniel Osei, the Marketing Operations Engineer

Daniel opens the CRM before he opens a conversation. Which objects exist. Which fields are populated. Which lifecycle stages actually fire. Where the same concept lives under three names. He does not trust a funnel report until he has traced one record from form fill to closed-won by hand.

He explains decisions in terms of what the data will and will not be able to prove afterward. He never calls a setup best practice. He says what question it answers and what question it makes unanswerable forever.

His craft is designing for the report the CFO will ask for in a year. Lifecycle stages with entry and exit criteria a machine can evaluate. Lead source captured once at first touch and never overwritten. An attribution model chosen for what the company can act on, not for what looks sophisticated. Deduplication before enrichment. Workflows with a kill switch and a log. Naming conventions a new hire can decode without a wiki. And a rule that a field nobody fills in gets deleted, because an empty field is a lie the report tells with a straight face.

What he hands over: a documented data model, a working set of reports, and a monthly hygiene scorecard naming the three things that degraded. His rarest skill is sitting between a sales leader who wants every lead and a marketing leader who wants only qualified ones, and getting both to sign the same definition.

The evidence he cares about: a pipeline report that finance stopped rebuilding in their own spreadsheet.

Lucía Fernández, the Web and Performance Engineer

Lucía starts with a Lighthouse run and a DNS lookup. Before she reads the design she wants to know how the site is hosted, what sits in front of it, how many third-party scripts load before the first byte of content, and who holds the login for the domain registrar. To her a beautiful site on a broken foundation is a liability with a launch date.

She explains decisions in milliseconds, error rates, and what happens when a vendor goes down. She never calls a stack modern. She describes its failure modes and how long recovery takes.

Her craft is building so the site can be changed without her. Every environment reproducible from a repository. Deploys that roll back in one command. The runbook written before launch, not after the first outage. Cache headers per asset type. Images in the right format for the viewport that asked for them. Fonts subset and preloaded. Consent wired so tracking fires only after permission. Redirect maps maintained through every migration so ten years of inbound links keep working.

What she hands over: a launch checklist that has actually been executed, monitoring with alerts routed to a human, and a performance budget the Sculptors agreed to before they started designing. She can tell a designer that the hero video costs 400 milliseconds and a marketer that the chat widget costs 800, and hold the line on both.

The evidence she cares about: a site with no unplanned outage in a year that still scores green after a dozen content releases she had nothing to do with.

Arjun Mehta, the AI Workflow Engineer

Arjun's first move is finding where the signal lives and how it gets to the model. His view is that the prompt is the least important part of a workflow. What feeds it and what checks the output matter more. So he traces a piece of content from the customer call that inspired it, through the transcript, the tagged verbatims, the voice guide, the generation step, the human review, and the published page, looking for the point where quality leaks out.

He explains decisions in cost per accepted output, review time saved, and how often a human overrode the machine. He never calls a workflow intelligent. He describes what it gets right unaided and what still needs a person.

His craft is treating cost and quality as one decision. Premium models where the output is customer-facing. Cheaper models where volume matters and a human reviews anyway. Local inference for batch work with no deadline. Grounding steps that force the model to cite its source. Baseline checks that make generic filler visible by comparing the output against what the model would have said with no context at all. Injection monitoring on anything that ingests external text. Fallbacks that fail to a cheaper model rather than to nothing. And he treats human feedback as training data: every vote, edit, and accept-versus-adjust decision feeds back into how the next task gets routed.

What he hands over: a documented pipeline, a cost and quality dashboard per client, and a short list of the prompts with the highest override rate and what he plans to change about them. He can explain to a CMO why a task is cheaper on an open-weight model and to a developer why the connector should own all the writes.

The evidence he cares about: a CMO who has stopped re-explaining context to a chatbot, and a monthly AI bill that went down while output went up.

Same seat, three foundations

Daniel builds the foundation the reports stand on. Lucía builds the foundation the site stands on. Arjun builds the foundation the AI stands on. None of the three is visible when it works, which is the curse of the role and the reason it is undervalued right up until the report is wrong, the site is down, or the AI is confidently making things up.

Sequence matters here more than in the other roles. Arjun's pipelines are only as good as the data Daniel structured and the site Lucía keeps up. A company that hires the AI engineer first, because AI is the exciting part, gets beautiful workflows fed by a CRM where lead source has been overwritten three times.

What T2D3 OS does with this

T2D3 OS is, in large part, an Engineer. It extracts signal from every upload, enriches contacts and accounts, keeps the platform's own workflows healthy, and routes every generation to the model that fits the task. From this release it names which Engineer did what. Audience enrichment and the CRM-facing data work are Daniel's. Platform upkeep, the site's deploy and performance layer, and the stewards that keep them green are Lucía's. Signal extraction, grounding, prompt review, and model routing are Arjun's.

As with every role, the archetype is chosen by the kind of artifact, never by the model picking a persona at run time. Signal extraction is always Arjun's; the routing is a table with a test on it. And the name carries the bar. If the app says Daniel enriched the records, the lead source had better still be the original. If it says Arjun grounded the draft, the sources had better be cited. If it says Lucía kept the platform up, there had better be a log.

The people named here are composites, not staff or candidates. If one of them is you, the GTM Engineer careers page shows all three next to the growth ladder for the role, and the open roles are there when you are ready. The other seats have their own three: the Navigator, the Scribe, and the Sculptor.