In case you missed it, here's what I shared yesterday: My Case for Owning Your GTM.
Demand for GTM engineering work is rising from a small base. Combined postings for GTM engineer and revenue operations roles rose 205 percent from January through September 2024 against the same period in 2025, across 1,000 analysed roles. The role writes code and it is paid like it.
The title is 100 percent my view. Marketing departments are becoming engineering departments.
Median pay among postings that disclosed a range was 127,500 dollars. Vercel listed about 252,000 dollars for the role. OpenAI listed about 250,000 dollars.
The market has already priced this as a serious engineering job.
What a GTM engineer actually does
The GTM engineer of today writes production code, names the system, versions it and owns how it runs.
They build a scoring engine, research chain, routing rule, page system, reporting layer or approval gate. They connect the data, write the logic, set the tests, watch the failures and improve the result.
Playing with Zapier taught many marketers how workflows fit together. The current role goes much deeper. It can open a terminal, inspect a repository, understand an API, review generated code and explain the architecture to security.
The person still needs marketing judgment. Code with weak customer knowledge simply produces weak work faster. The useful combination is commercial taste with the ability to turn an idea into a running system.
They also name what they build. A useful system has an owner, a purpose, clear inputs and a result the business understands. Naming forces the team to agree on the job before the code starts moving data.
That combination removes the long handoff chain.
A marketer used to write a brief. Ops translated it. Product found a place in the queue. Engineering interpreted it again. Weeks passed before anyone saw the first result.
Now a small team can move from a conversation to a prototype in the same week. Working software makes the rule, the exception and the outcome visible. The team can argue with evidence on the screen.
Uber already runs a version of this.
Uber paired about 30 AI proficient engineers with domain experts. It formed 16 agentic pods across 16 functions in two months.
Uber's own August 2026 report goes further. Agents were credited with more than 70 percent of pull requests inside one dedicated platform team. Cost per session fell 52 percent from a June peak. The figure measures production capacity only. The pod structure keeps that capacity close to judgment, which is the harder part to build.
The pods worked in short cycles around a business problem. Marketing quality assurance fell from two weeks to under an hour. Capital allocation dropped from 15 hours to 30 minutes. Pacing reports moved from two days to 10 minutes.
An engineer sat beside the person who knew the function. Building capacity stayed close to judgment.
That is the same shape I keep seeing in GTM.
I have watched this shape emerge for 23 years building GTM engines, the last two to three years specifically inside GTM x AI engines. My studio has built 27 of them with the embedded developers we place directly inside client teams, spanning more than 100 projects from seed stage startups to enterprise accounts. The pattern repeats every time. An engineer who understands the domain and sits beside the person who owns the outcome moves faster than any handoff chain no matter how well documented that chain is.
The three seat unit
The smallest useful unit has three seats.
The operator owns the outcome. This person knows the customer, campaign, pipeline or market.
The ops lead owns systems and definitions. This person knows where the data lives, what each field means and which process breaks when a rule changes.
The GTM engineer builds. This person connects the tools, writes the workflow, sets the tests and keeps it running.
The posting data says what that third seat needs. Across the 1,000 roles Bloomberry analysed, the average requested experience was 4.11 years. SQL appeared in 38 percent of postings and Python in 38 percent as well.
That describes a mid level engineer with commercial judgment, hired at engineering rates. Most marketing organisations do not have one yet. No repository owner, no review practice, no on call rota, no deprecation policy. A company without a named operator for the owned layer sits below the capability threshold whatever the software can do.
The seats matter because the work splits three ways and one person rarely holds all of it. The operator carries the outcome. The ops lead carries the meaning of every field. The engineer carries the code and the failures. Put all three on one person and the company ends up with a system only that person can run.
A thin shared hub supports those units with version control, security, review standards and reusable components. It stays thin because context belongs near the work.
Ramp reports 300 to 400 salespeople building internal tools with 79 tools available through its internal protocol. Local work gets promoted into a governed common set.
One central builder quickly becomes a queue. A large centre of excellence quickly becomes a meeting. Small embedded units keep the company language beside the code.
This is what winning GTM teams look like right now. No vendor lock-in. LLM-agnostic by design, never married to one model provider. The flexibility to build as they go, adding a tool or an agent the week they need it instead of waiting on a roadmap. Lean and highly efficient. Sitting on the newest capability the moment it ships, genuinely on the cutting edge.
What changes for the individual
I think the GTM expert of the future can move from an idea to a running system without a long handoff.
For a growth marketer this means learning how data moves, how rules are written and how to test an agent. For an ops person it means moving closer to the outcome. For an engineer it means learning the business language behind every field and approval.
The best place to start is one motion with one real owner. Give the unit access to the data. Write down the definitions before the agent acts. Set gates for consequential actions. Review the result every week.
You can learn the shape before changing the org chart.
GTM OS is designed for this three seat unit. It gives the operator, ops lead and engineer reusable GTM motions they can adapt to one company. We are in closed alpha. Read more at https://www.heyarnoux.com/gtmos/ Request a demo or join the founding group at https://docs.heyarnoux.com/gtm-os-founding/
Tomorrow I will explain why I think a GTM leader should own the code, infrastructure and data behind the revenue motion.
David
Tomorrow: You Should Own Your GTM Infrastructure. The Code. All of It.
By the way, if you need help building your GTM engine, reach out on the collab page. If you are ready to start building, I have GTM engineers ready to embed in your team.
