Tag: mpe-intro

As I’ve been sketching out this idea of Marketing Platform Engineering (MPE), a natural question comes up: where does a team like this sit in the org chart? With marketing? With engineering? Somewhere in between?

There’s probably not a single “right” answer, but here’s where my thinking has landed so far: MPE should live inside engineering. I’ve experienced first hand what happens when MPE teams live inside marketing, and I’m not convinced that’s to the benefit of either the marketing team or the MPE team.

Why Engineering?

Marketing Platform Engineering is first and foremost engineering work in service of marketing outcomes. That distinction matters, because where a team sits determines how its work is valued and how sustainable it becomes.

Shared Standards, Shared Strength

MPE builds production systems: CMS architectures, experimentation frameworks, analytics pipelines. To be effective, those systems need to be designed, reviewed, and maintained with the same rigour as any other engineering work. Living inside engineering ensures security, performance, and scalability aren’t afterthoughts.

Collaboration, Not Siloes

Marketing is the primary stakeholder, but marketing doesn’t exist in isolation. Campaigns connect to product surfaces, sign-up flows, and onboarding experiences. Sitting within engineering keeps MPE close to the conversations and roadmaps that shape those touch points, so integrations are intentional and efficient rather than fragile bolt-ons.

Credibility and Leverage

Placement inside engineering signals this is a first-class platform function, with the mandate to advocate for long-term investments. The kinds of investments that extend beyond near-term campaign goals, ensuring marketing’s impact compounds over time. That identity matters. It unlocks trust, budget, and partnership.

Modern marketing is already deeply technical. SEO, CRO, and ops teams run complex systems every day. MPE builds on that sophistication by aligning production systems with engineering standards. That way, MPE can maintain its own roadmap and standards, while staying close enough to marketing to understand its rhythms and respond effectively.

At its best, MPE is the partner function — close enough to marketing to anticipate its needs, and close enough to engineering to build sustainable, scalable systems that serve both.

What Would It Take for MPE to Work?

Org placement is one piece, but the environment matters just as much. I believe an MPE team need a few things to really succeed:

Early Involvement

They need to be brought into conversations early, not handed tickets after decisions have been made. Late involvement usually means patchwork additions: “just get it working in time for launch.” That might work once, but it builds fragility. With early context, MPE can design systems that serve both the immediate campaign and the long-term roadmap, so marketing moves quickly now and in the future, without sacrificing stability.

Their Own Roadmap

If MPE is only a request queue, it will never get ahead. To deliver compounding value, MPE needs to own a roadmap, one shaped together with marketing, balancing urgent requests with platform investments.

For example: fixing a one-off workflow bug might take a day, but investing that same time in a reusable workflow engine could save weeks across multiple campaigns. These kinds of wins are less likely to happen without a roadmap co-prioritized with marketing. Ownership ensures the space to pursue platform-level bets while still meeting campaign needs that marketing helps define.

This is why placement matters. When MPE sits inside engineering, it gains the credibility and leverage to protect that roadmap. Marketing remains the primary stakeholder, but MPE has the authority to invest in the long-term systems that ultimately accelerate marketing’s work.

Built on Collaboration, Not Tickets

Designers, SEO specialists, CROs, and growth marketers need to collaborate with MPE as partners. Otherwise, the team gets boxed into doing surface-level implementation instead of building the platforms that really accelerate marketing. It’s a subtle irony: when MPE is framed only as a request channel, its ability to deliver real leverage is limited. Collaboration as partners unlocks the speed stakeholders actually want. Tickets keep everyone stuck in the weeds.

Balancing Context and Ownership

Even though MPE focuses on marketing’s needs, the systems they build don’t exist in isolation. A CMS for editorial publishing connects to product pages. A workflow for campaign tracking connects to onboarding flows. An analytics pipeline connects to customer portals. To avoid fragmentation, MPE has to mesh tightly with the rest of engineering and stay close to marketing, so the seams don’t show and customer experiences feel whole.

---

That’s where my thinking is at the moment: MPE as a partner to marketing, but a home inside engineering.

I’ll admit, this is all theorization based on my experiences and the patterns I’ve seen around me. I’m working it out in public, and so far, this is my working model, which I’m sure will evolve with more practice and feedback. But exploring these questions feels worthwhile, because naming and shaping this kind of work is an important step in making it something real and impactful.

We’ve covered what Marketing Platform Engineering isn’t. Now let’s shift focus to what it actually delivers; the impact of this work when it’s done well.

This is a work in progress (I am inventing this all based on the patterns I have been seeing in my own work and around me, after all), but the impact of MPE can be understood across four dimensions: agility, reliability, cost, and speed. My working acronym is the ARCS of Marketing Platform Engineering.

Agility

If I’ve learned anything, working with marketing teams, it’s that modern marketing moves fast. Priorities can shift suddenly, and campaigns appear out of nowhere, and pivots can happen overnight. But agility isn’t possible when every experiment or landing page requires custom engineering or hacks to get out the door.

MPE makes agility real: feature flag frameworks, composable content systems, and integrations designed to flex and bend with the changing needs of the marketing team. Done well, it empowers marketing teams to adapt quickly without waiting on the ticket queue.

Reliability

Nothing undermines trust faster than broken tools or bad data. A CMS failing mid-launch creates chaos. An experiment with missing, or worse, false data leads teams astray.

Reliability is at the heart of MPE. Durable systems with automation, scalability, performance, and observability built in give marketing teams the confidence to launch and know the platform will hold steady, even through the most complex campaigns.

Cost

Budgets matter, especially right now. Without a dedicated marketing platform engineering team, waste and hidden costs are everywhere. Engineering hours are drained on repetitive tasks, there are redundant SaaS purchases, and constant duplication of effort across teams.

There is an upfront cost to dedicated marketing platform engineering, but it pays off. You get less tool sprawl, fewer fire drills, and the marketing team is freed to imagine campaigns of any scale without ballooning expenses.

Speed

Brittle workflows slow everything down. Editorial teams can‘t publish quickly.Campaigns are delayed by trivial missing features. And engineers spend more time working on adhoc requests and urgent needs than on meaningful improvements.

With clear goals and real buy-in, MPE unlocks serious velocity. With thoughtful CMS architectures, reusable workflows, and solid integrations, marketing can ship in days instead of weeks. And that speed compounds over time: faster launches, faster feedback, better data, and faster results.

The Metrics of Impact

Marketing platform engineering is the craft of building the systems and workflows that enable marketing teams to work at their best.

While traditional engineering metrics still apply, the true measure of an MPE team is how effectively they empower the marketing team to do its work.

And, at least so far, I believe those metrics to be ARCS: agility, reliability, cost, and speed. A true marketing platform engineering team can reshape the arc of a marketing team’s performance, positively and sustainably.

When you evaluate MPE through Agility, Reliability, Cost, and Speed, the value becomes clear: it’s not just support work, it’s strategic infrastructure. It’s the difference between marketing teams that are constantly scrambling and ones that can move with confidence and focus.

In the next post, I’ll talk about where this work should live inside an organization, because even the best engineers can’t deliver ARCS if the environment around them isn’t set up for it.

I touched on this briefly in the last post: the other roles that Marketing Platform Engineering (MPE) overlaps with but isn’t. Before diving into what the role is and what it entails though, it’s worth pausing to draw the lines around what it’s not. MPE intersects with several familiar disciplines, which makes it easy to mistake it for something else entirely. Drawing these boundaries matters, because without them, it’s all too easy to dismiss this work as just a repackaged version of roles that already exist.

It’s not Growth Engineering or CRO

Growth engineering focuses on driving long-term growth metrics like acquisition, activation, retention, and revenue. They build new features, experiment setups, and product optimizations that shape user behaviour across the entire funnel, often well beyond marketing-owned surfaces. Their work is deeply metrics-driven, experimental, and product-oriented.

CRO (Conversion Rate Optimization) teams, on the other hand, run rapid, targeted tests on specific marketing surfaces, like landing pages, lead forms, or campaign microsites, to improve immediate conversion outcomes. Their work is quick, tactical, and often one-off.

MPE is neither of these. It doesn’t run growth experiments or tweak campaigns to boost short-term conversion rates. Instead, it builds the platforms and workflows that enable both growth and CRO teams to move faster and more effectively: robust CMS architectures, experimentation frameworks, analytics pipelines, and reusable systems. MPE is about building the foundation that these teams operate on, not the experiments themselves.

It’s not DevOps or Platform Engineering

DevOps and platform teams are focused on infrastructure reliability, deployment pipelines, CI/CD, and security across an organization. Their work is measured in uptime, latency, and operational consistency, not marketing agility.

MPE overlaps in its concern for developer experience and maintainability, but its purpose is different: to serve marketing and editorial velocity specifically. Where platform engineering prioritizes scale and standardization across everything, MPE tailors its solutions to the distinct needs of marketing teams.

It’s not Solutions Engineering or Developer Advocacy

Solutions engineers and developer advocates are external-facing roles. They help customers adopt products, or market to developers, translating between technical and business audiences out in the world.

MPE is internal-facing. It builds the underlying framework within a company, the systems, workflows, and integrations that marketing teams operate on every day.

It’s not just a Marketing Technologist

Marketing technologists typically focus on configuring SaaS tools, CRMs, email platforms, analytics dashboards, and live close to or within marketing operations. They rarely design custom architecture or maintain production codebases.

MPE does though. It’s engineering work, not tool configuration. It involves writing and maintaining code, designing system architectures, and building long-lived internal platforms that marketing functions depend on.

---

Marketing Platform Engineering sits close to these roles, which is why it’s easy to misread, but also why it’s powerful. It intersects with growth, platform, and solutions work, but it isn’t a mash-up of them. It’s its own practice with its own mandate: to build the foundational systems that make modern marketing possible.

Getting clear about what MPE isn’t is the first step. It creates space for what it is and why it matters. In the next post, we’ll dig into the impact of marketing platform engineering.

I’ve been thinking about the direction of my career a lot recently, and reflecting on the twisting turns and bends it has taken so far. I do this often, and for the last 3 years or so, I’ve felt like I’ve been in a phase of experimentation and going where the wind blows.

And I came to the realization that maybe I’ve been growing into a marketing platform engineer all this time.

There’s surprisingly little information out there about the kind of engineer I feel I am. I really only found two articles that seem to vibe with what I was thinking:

• This piece from Pantheon
• This blog post from someone in Europe

The problem is that both use the term marketing engineer, which means something altogether different than what I mean.

So I’m calling it marketing platform engineering.

What is marketing platform engineering?

Marketing platform engineering is the craft of building the systems and workflows that enable marketing teams to work at their best.

In practice, this might mean designing a CMS tailored to editorial needs, integrating data collection into an existing website or app, or orchestrating smart workflows and service integrations to power complex campaigns.

It’s not the work of marketing itself, it’s the platform that marketing operates on. The infrastructure that lets campaigns launch faster, content scale cleanly, and insights flow back into strategy.

Doing this well requires fluency in both marketing and engineering. You have to understand the value of strong design, clear brand expression, and persuasive copy, while also mastering the engineering side: performance, tech stacks, coding best practices, accessibility, security, and scalability.

A successful marketing platform engineer sits at the intersection of these skills, able to fluently speak to both marketers and engineers in their language.

Why does this matter?

Marketing is becoming increasingly platform-driven and multidisciplinary. Modern marketing teams don’t just write copy and launch campaigns, they orchestrate content across dozens of surfaces, analyze user behaviour in real time, run rapid experiments, and demand seamless collaboration between design, editorial, data, and engineering.

But most engineering orgs still treat marketing as an aside: something you build a quick CMS for, bolt on a form or analytics tag, and call it done. Others dedicate engineering teams to marketing but fail to take their work seriously. The result? Marketing teams are often stuck using fragile, siloed, or overly generic systems that slow them down, while engineering teams are frustrated by unclear requirements and one-off requests that prevent them from growing as a mature function.

Sometimes this work gets outsourced to agencies or vendors¹, but usually only in fragments, a CMS build here, an analytics setup there, an integration for a single campaign. Because they’re brought in for isolated deliverables, they often lack the full context of the marketing strategy, tech stack, and long-term goals.

Without that continuity, the solutions are more likely to be shallow or brittle: they solve the immediate problem but don’t scale, adapt, or integrate well over time. These vendors can be helpful specialists, but they rarely act as true partners embedded in the ongoing system the way a marketing platform engineering team does.

Marketing platform engineering bridges that gap. It creates durable, scalable systems that marketing teams can trust and build upon, while enabling engineers to work with clear standards and maintainable codebases.

Right now, this role often exists kind of invisibly, held by a handful of people who quietly straddle two worlds without a proper name for what they do. Naming it matters. Recognizing the skill set and the strategic value they provide matters. It gives the work legitimacy, creates a shared identity, and encourages others to intentionally build expertise in it.

How It Differs From Adjacent Roles

There are roles that overlap with pieces of this work, but none capture the whole picture:

• Full-stack engineers build products for end users, not the internal platforms marketing teams rely on. They focus on features and functionality, not editorial workflows, content modelling, or brand governance.
• Growth engineers experiment on user acquisition and conversion funnels. They operate inside the marketing function, not alongside it, and their work is highly metrics-driven and short-cycle, not platform-oriented.
• Marketing technologists choose and configure SaaS tools (CRMs, email platforms, analytics dashboards), but rarely build custom systems or own the underlying codebases the way engineers do.
• Developer advocates or solutions engineers connect marketing and tech from an external-facing angle, but they don’t build internal platforms or integrate marketing workflows deeply into core infrastructure.

A marketing platform engineer is different. She sits between product engineering and marketing, translating needs in both directions and building the connections that lets marketing scale, robust CMS architectures, design systems, analytics pipelines, experimentation frameworks, and cross-service integrations.

—

In future posts, I’ll dive deeper into the skill set this role demands and what it takes to build an environment where marketing platform engineers can thrive.

---

Footnotes

1. To be clear, I think agencies are great — I’ve worked at a few and ran my own for a time too, and they can massively accelerate the velocity of an internal marketing platform team, give them a strong jumpstart, or be fantastic long-term partners when they have the right amount of context and are treated like true partners. ↩︎