Marketing operations is not growth engineering
Marketing operations runs the system. Growth engineering designs the one that should exist.
A few years ago, a service-based business with a substantial monthly ad budget approached us with a specific ask. They wanted someone to manage their Google Ads account. Ads were their primary lead source, the budget was meaningful, and they wanted operational rigor brought to a function that had been running on intuition.
The brief was straightforward. The reality, once we started looking, wasn’t.
The ad account itself was fine. Campaigns were running. The reporting inside the account was clean enough. What was broken was everything around it. The website was years old, still standing on hand-coded HTML and out of step with what the company had become. Social media accounts existed in a kind of half-life, posted to occasionally and then forgotten. The YouTube channel had been seeded and abandoned. Email marketing was minimal. Tracking of where leads were actually coming from was inconsistent, and the question of which channels were working had no clean answer because nothing had been built to produce one.
There was no measurement architecture. There was no channel mix. There was no strategy connecting any of it together. There was just an ad account, performing on its own, with no system around it.
We didn’t accept the engagement as briefed. We came back with a proposal that reframed the work as a twelve-month rebuild of marketing, operations, and measurement, with the ad account as one component instead of the whole game. They hired us for that broader scope. A year in, they hit a growth milestone they hadn’t planned to reach for two. They’re still crushing their growth goals now.
The point isn’t the outcome. The point is the gap between what the brief said and what the problem was.
The brief said marketing operations. The problem was growth engineering.
This is the most common diagnostic error in conversations I have with prospective clients. Not because anyone is wrong about what they need, but because the vocabulary of marketing has compressed two genuinely different disciplines into one phrase. (For the broader framing, see What is growth engineering?.)
Why this confusion is so common
Marketing operations and growth engineering share the same toolset. CRMs. Marketing automation. Attribution. RevOps tooling. Analytics. From a stack diagram, the two practices look identical.
What they don’t share is the work.
Marketing operations is the discipline of running the system that exists. Keeping the CRM clean. Routing leads correctly. Maintaining campaign cadences. Making sure the integrations don’t break. Reporting on what happened. It’s an operational role, and a critical one. A marketing org without good marketing operations is a marketing org leaking value daily.
Growth engineering is the discipline of designing what the system should be. Deciding which integrations matter. Architecting how data moves between platforms and people. Choosing what to measure, and why. Building the connective tissue between marketing intent and operational reality.
The construction comparison is imperfect but useful. Marketing operations is the building’s maintenance crew. Growth engineering is the architect. Both are necessary. Neither does the other’s job.
Why “we have great ops” doesn’t always mean what people think
A national nonprofit we worked with had become genuinely good at producing content. They had an internal content engine running at high cadence. Videos, articles, social posts, email sequences. The output was impressive by any measure.
Despite that, growth was stuck. Engagement was low. Channels weren’t compounding. The volume of work being produced wasn’t translating into the trajectory the organization needed.
This is what content-first looks like when the underlying system isn’t designed for it. They had marketing operations: a content calendar, a publishing workflow, the right tools in the right roles. What they didn’t have was anyone asking the systems-level questions. What user journey does this content serve? How does this connect to the next step in the funnel? What signal does each piece of content produce, and where does that signal go?
The ops layer was healthy. The architecture above it didn’t exist.
Great content without a system doesn’t get you very far.
The work wasn’t to produce more content. The work was upstream of content, in the design of how content connects to the outcomes the organization actually wanted.
The opposite failure mode
The flip side is just as common.
We worked with the leader of a mission-driven organization who believed deeply in process documentation. We were brought in to help establish standard operating procedures across operations, revenue operations, and marketing. We did. Dozens of them. Carefully written, properly scoped, organized in a shared folder.
There was no measurement of adoption. No leadership reinforcement. No visibility into whether the SOPs were being used at all. The team didn’t see them in their daily flow, didn’t hear them referenced in meetings, didn’t have any consequence for ignoring them.
The documents existed. Nothing changed.
This is growth engineering’s failure mode when it gets confused for documentation. Designing the system isn’t enough. Designing the system and the structure that makes the system actually run is the work. Otherwise you’re producing artifacts of design (process maps, architecture decks, beautiful Notion pages) without producing operational reality.
The first nonprofit had ops without architecture. The mission-driven org had architecture without ops.
Both stuck. Both for different reasons. Neither could fix themselves by adding more of what they already had.
How to tell which one you have
I almost always lead a discovery conversation with questions about operations, not about marketing.
How do you currently know what’s working? Who runs your CRM, and how often is it touched? What happens when a lead comes in, from any channel, in the next five minutes? Which dashboards does leadership actually look at, and how often do you all agree on the numbers they show?
The answers reveal where the gaps are.
A team that gives clean ops answers but vague strategy answers is sitting on a growth engineering problem. A team that gives crisp strategy answers but messy operational reality is sitting on a marketing operations problem. A team that struggles with both is at the beginning of the journey, regardless of how mature their stack looks on paper.
Most of the time, what people come to us asking for is in the second or third bucket. They describe it as the first because that’s the vocabulary the industry has handed them.
What this means for hiring
The natural follow-up question: can a senior marketing operations person do growth engineering?
Sometimes. Not usually. And the reason isn’t capability, it’s charter.
A senior marketing ops person is hired, trained, evaluated, and promoted around keeping the system running. Their job description optimizes for reliability, accuracy, and throughput. They get good at the operational layer because that’s what the role rewards.
Growth engineering rewards a different set of muscles. Deciding what the system should be. Knowing what to refuse. Having opinions about architecture. Being able to translate strategy into infrastructure decisions and infrastructure decisions back into business outcomes. The skills overlap with marketing ops in some places. The temperament rarely does. The willingness to redesign the running system, rather than just optimize it, is a different kind of confidence.
The crossovers exist. I’ve worked with marketing ops leaders who genuinely think like architects, ask system-level questions before tactical ones, and have opinions about what shouldn’t exist in the stack as well as what should. They’re rare. When you find one, hold on to them.
But you can’t reliably hire for this by writing a “Senior MarOps” job posting. You’ll get people who excel at the role as defined. You won’t get architects.
A short diagnostic
If you read this and are still uncertain which discipline your team is short on, here’s a four-question test you can run inside your head before the next leadership meeting.
- Can leadership name three outcomes (not metrics) the marketing system is supposed to produce, and would three different leaders agree on that list?
- Can someone on your team draw the system that connects “marketing activity” to “revenue outcome” on a whiteboard, accurately, in under ten minutes?
- Do you know where the system is leaking signal, meaning places where data exists but doesn’t reach the people who need it?
- Has anyone designed the system you’re running, or did it accumulate by addition over time?
If you said no to two or more, you’re not stuck on marketing operations. You’re stuck on growth engineering. Hiring more ops people, or buying more tools, or running more campaigns won’t move the trajectory. The work is upstream of all of that.
Why the term exists
The first time I used the phrase “growth engineering” out loud was in a meeting with a corporate leadership team. I was making the case that marketing’s impact depends on its alignment with operations, that the wall between the two is the thing holding most teams back. And in the middle of explaining it, I said “growth is engineered.”
The phrase landed because the existing vocabulary didn’t fit the work. Marketing automation didn’t capture it. RevOps was close but incomplete. MarTech was a category of tools, not a discipline. What I was describing, the design of connected systems that turn strategy into compounding outcomes, needed its own name.
I’ve been using it ever since. So has every client conversation worth having since then.
Marketing as a function isn’t going away. The production-heavy version of it might be, but marketing as a discipline is still the discipline of earning attention and converting it.
What’s becoming clear is that the most leverage in a marketing organization isn’t in the marketing itself. It’s in the engineering of what the marketing connects to.
That’s the discipline. That’s where the work is.
If you’re looking at your stack and quietly wondering whether you have ops without architecture, or architecture without ops, that conversation is one we have often. Start one with us.