daniel rusu
DOC
writing/stop-telling-me-you-need-a-marketo-admin
VER
1.0
STATUS
MAINTAINED
LAST REVIEWED
2026-08

Stop Telling Me You Need a Marketo Admin

Somewhere right now, a company is writing a job post for a "Marketo Admin." Meanwhile, inside that same company: marketing and sales report different lead counts and have simply agreed to stop discussing it, the attribution model is a spreadsheet named attribution_v7_USE_THIS_ONE, and nobody can say with confidence what happens to a lead after the webinar. The job post mentions none of this. It mentions smart campaigns, email builds, and "3+ years of Marketo experience."

They will get exactly what they asked for. That's the tragedy. The req will be filled by someone who knows where all the buttons are, the buttons will be pressed competently, and eighteen months later the lead counts still won't match — because none of those problems were ever in Marketo. They were in the seams between systems, in definitions nobody wrote down, in an architecture nobody was hired to own.

After a decade of doing this job under a dozen different titles, I've come to believe the tool-first framing is the single most expensive habit in how companies buy marketing operations — hiring and consulting alike. So let me make the argument properly, under my own name.

Tools are the smallest part of the job

Here's a partial list of platforms I've run, migrated to, migrated from, or been formally certified in: Marketo, Pardot — sorry, Marketing Cloud Account Engagement, a name change that cost someone millions and me nothing — HubSpot, customer.io, Salesforce Marketing Cloud, Segment. I have the certifications. They're lovely. I keep them the way you keep a driver's license: proof I can operate the vehicle, silent on whether I know where we should be going.

Because across every one of those platforms, the actual work was identical. Where are records born, and who owns them? What does "lead" mean, in writing, in both systems? How does consent flow, and would it survive an auditor? Why do the numbers disagree, and which one is lying? These questions don't care which logo is on the login page. I've answered them in six different tools, and the tool has never once changed the answer — only the menus I clicked while finding it.

That's the seniority axis in this field, and it's perpendicular to the tool axis. A junior person knows the platform. A senior person knows which problems live above the platform — and that's precisely the layer no tool-named job post ever asks about.

How the framing fails, mechanically

Hire by tool and you select for the wrong layer. The interview asks how to build an engagement program; it doesn't ask what to do when two systems disagree about reality, because the tool name framed the conversation at button altitude. You end up with a competent operator sitting on top of an undiagnosed architecture problem — pressing the buttons correctly, shipping the campaigns on time, while the actual damage compounds one silent sync error at a time. Then the operator gets blamed for outcomes that were never within their layer, leaves, and becomes — as I've written elsewhere — a ghost in someone's instance.

Buying consulting by tool fails the same way but faster. "We need a Pardot consultant" produces a Pardot-shaped engagement: the instance gets tidied, the naming conventions get fixed (I do love a fixed naming convention), and the CRM sync that's been quietly leaking records since 2023 stays out of scope — because the scope was a product name, and the problem lives between products.

I'm sympathetic to why this happens. Tool names are legible. Recruiters can screen for them, procurement can budget for them, and "Marketo Admin" fits in a job title field, whereas "person who makes our systems stop lying to each other" does not, although I'd apply. Legibility is a real constraint. It's just currently optimizing for the easiest thing to filter instead of the actual thing that's broken.

What the functions are actually called

Strip the logos off and the job decomposes into functions that have been stable my entire career while the tools underneath churned:

Data plumbing — how records are created, synced, deduplicated, enriched, and retired across the CRM, the marketing automation platform, and the data layer. Lifecycle architecture — what the stages mean, where the definitions live, and what enforces them. Governance — naming, consent, permissions, documentation; everything that keeps the machine legible to its next operator. Measurement — whether the numbers describing all of the above can be trusted. And campaign machinery — the layer everyone can see, which is why it gets 90% of the attention while the other four determine whether it works.

Every marketing ops problem I have ever been handed sorts into those functions. CRM, MAP, CDP — categories, not products — because the category names survive the migrations. Companies that think in functions can diagnose before they buy. Companies that think in tools buy first and let the diagnosis emerge, usually via incident.

What to ask for instead

If you're hiring or engaging help, the fix costs one sentence: lead with the problem, not the platform. "Our CRM and MAP disagree by 15% and nobody trusts the funnel report" — now the conversation starts at the right altitude, and you can hear immediately who lives there. The tool-first candidates will answer with features. The right ones will answer with questions: which fifteen percent, since when, and what happened around then?

And if you're the one being hired: the platform expertise that got you in the door is real, but it depreciates — I've watched three of "my" tools fall out of fashion in a decade, and my Pardot certification now certifies me in a product name that no longer exists. The questions are what appreciate. Learn the questions.

The tools will keep changing. I'll keep getting certified in whatever they're called next, and I'll keep being fondly unsentimental about every one of them. The job was never the tool. The job is making the systems tell the truth — and that one, no vendor can rename.

I'm Daniel — ten years across CRM, marketing automation, and customer data platforms, currently thinking in functions and clicking in whatever menus are required. I take a small number of advisory conversations; if your problem doesn't fit in a job title field, say hello.