Marketing Platform Engineering

The exceptional Aurooba Ahmed has written a series of articles on her Working Notes blog covering what she calls Marketing Platform Engineering:

• Marketing Platform Engineering
• What Marketing Platform Engineering Isn’t
• The Impact of Marketing Platform Engineering
• Where does Marketing Platform Engineering Belong?
• What is a Marketing Platform

In this series, she digs into the particular craft “of building the systems and workflows that enable marketing teams to work at their best.”

We worked together at WP Engine, doing exactly this sort of stuff—though without the name for it. So I’m really glad she’s worked through this and written these articles. If you are building a platform for marketing teams, but don’t think of yourself as a marketer—or if your organization includes that sort of people, read her articles now.

I’m going to dig in to a few points, mostly highlighting valuable contributions to a discussion that needs to happen. I’ll have a quibble or two, and some ideas to extend her thinking.

I’ll say up front that (1) she is on to something, (2) I’m inclined to agree with her because she truly knows her stuff, (3) I’m incredibly glad I was able to hire her into the team at WP Engine (with a major assist from Ross Wintle), and (4) identifying and giving language to a specialization is incredibly valuable on its own, and she should get credit for doing so here.

The Plight of Marketing Platform Engineers

When managing the web development team,¹ I would often joke about working with “overcaffeinated marketers”. They wanted to move fast, get results, move on to the next thing, when’s it going to be done is it done yet why isn’t it done? I very much enjoyed working with most of them!² They were not engineers, though—they were marketers. They didn’t understand engineering, didn’t understand many of the things that we did, but just wanted to be able to do their jobs.

We were engineers, not marketers. Marketing is a craft of its own (well, several distinct crafts), and I am every bit as ignorant of marketing as they were of engineering. So there’s not a value judgment. It’s simply two different worlds.

So as a team responsible for providing a platform that allowed the marketing team to market on the web, we had a conundrum. We wanted to provide a stable, maintainable, flexible platform that made it easy for marketers to do their jobs quickly. And we wanted to support the new work we were being asked to do (“can we have a carousel widget that will behave like so?”, “let’s rebuild the plans page and make it look like this!”, “what Hubspot forms are we actively using across all the sites?”, “we need better user data, and it’d be really nice to have this new analytics tool deeply integrated by 2PM on Tuesday”).

I often visualized a stream³ going around a bend. The current on the outer edge of the bend moves fast, carrying away sand, smoothing stones, and carving the channel deeper. The water on the inner edge of the bend moves very slowly, letting sand settle out, often spreading thin across the shallow part of the channel.

In effect, there are two streams of work.

There’s the fast stream at the outer edge. Campaigns, rebrands, experiments, new features to boost engagement, copy and graphics changes. It’s fast-moving, it’s exciting, it’s often time-sensitive, and it’s where the marketers love to be.

Then there’s the slow, steady stream. Solid, secure, stable infrastructure. Workflows that don’t fall apart when you look at them sideways. Thinking past the “happy path”. Knowing there will always be more ideas for things to add, and knowing if we get spread too thin or shallow, we’ll stop moving entirely, get stagnant, and become a breeding ground for mosquitoes and smelly algae. (Ahem.)

It’s difficult for both the engineers and marketers. More so than in a product engineering world, and definitely more than in a R&D world.

With that bit of background in place, let’s dive in.

Identifying and Defining the Role

Identifying Marketing Platform Engineering as a particular craft and defining it is valuable. Having language to discuss these sorts of things is useful. Not having a tidy name means it’s harder to get to the crux of what a role does:

• He fastens and unfastens metal and sometimes plastic bits in these machines with wheels that people use to get around so when they make weird noises or leak stuff, the noises and leaks go away — is a clumsy way to say “auto mechanic”.
• He’s an expert in using cleaning supplies and does a lot to make sure furniture is where it needs to be, and sometimes changes light bulbs or works with tradespeople to handle bigger jobs, and plans it all so the things he does don’t disrupt classes, and picks stuff up maybe – is a clumsy way to say “school janitor”.

And if it’s hard to get to the crux of a role, it’s hard to really discuss. So identifying Marketing Platform Engineering as a niche—and giving it a solid definition—means that discussions can happen that lead to better ways of working.

I like that the definition creates clear separation between marketing activities and what MPEs do: “…enable marketing teams to work at their best.” By creating this separation, Aurooba makes it possible to begin untangling the plight that (often unlabeled) MPEs find themselves in. Once a company (including their marketers) agree there is a group of engineers that exists to enable the marketing teams, without being marketers themselves, the situation becomes less of a competition for scarce (engineering) resources and can be treated as an organizational or workflow design problem.⁴

It’s also helpful to distinguish Marketing Platform Engineering from other adjacent or slightly overlapping roles, which Aurooba does. MPE isn’t:

• Growth Engineering / CRO – though MPE will build the foundation a CRO team will use to do their jobs better and faster.
• DevOps / Platform Engineering – though MPE uses a lot of those skills in service of marketing.
• Marketing Technology / Marketing Operations – though MPE might intersect with the third party tools MarTech people configure and use.
• Solutions Engineering – though MPE might engineer solutions, Solutions Engineering is focused on helping customers use the product, not provide internal systems.
• Product Engineering with some time carved off to help Marketing – though this is how I suspect most engineers working within marketing get started, this is organizationally unstable and eventually either collapses or leads to dedicated engineering resources for Marketing. (This one isn’t in Aurooba’s articles, but is worth calling out, similar to DevOps.)
• Simply setting up and babysitting a CMS – though the CMS is a very important component.

Distinguishing Marketing Platform Engineering from these other roles helps Marketing Platform Engineers and folks in these other roles. It prevents well-intentioned splitting of the focus of other roles (e.g., asking the Platform Engineering team to set up a CMS and wire it into analytics). It helps Marketing by making it clear that these other roles aren’t on call to support their workflows. It avoids setting up incorrect measurements for success of MPE work and for these other roles.

Clarity around what MPE is and isn’t helps everyone—Marketers, Marketing Platform Engineers, and folks in roles that might be confused for MPE.

Metrics

“What gets measured gets managed—even when it’s pointless to measure and manage it, and even if it harms the purpose of the organization to do so.”

– Simon Caulkin (summarizing V.F. Ridgeway’s argument in Dysfunctional Consequences of Performance Measurements)⁵

The plight of engineers supporting marketing is that, typically, the measurements are wrong or incomplete. The metrics are pure marketing metrics, which don’t align well with things like stability or ability to move fast in the future.

Aurooba proposes four dimensions for measuring MPE, with an acronym of ARCS:

• Agility
• Reliability
• Cost
• Speed

As dimensions to measure MPE’s success, I like this start. I have two points of confusion.

First, I think these metrics are taken from the point of view of the marketing teams MPE supports, but I’m not sure about that. Following that thread, I think it makes sense for the metrics to be largely measured from the marketing point of view, so that MPE isn’t chasing internal metrics to the detriment of the teams they serve (for example, optimizing for engineering cost in a way that makes marketing workflows brittle).

Second, I’m not entirely sure what the distinction is between Agility and Speed. Agility is the ability to pivot quickly; Speed is the ability to move quickly. In a marketing environment, both are strongly linked, because there’s almost always something new brewing in the latest campaign or experiment. I’ll come back to this in a bit.

One of the things I like about these dimensions in the inherent tension between them. Goodhart’s Law states “When a measure becomes a target, it ceases to be a good measure.” Tension between dimensions makes it harder to turn a single measure into a target.⁶ Reliability creates tension with Cost and Agility. Speed creates tension with Cost.

Proposed Detailed Metrics

The specific, detailed metrics will probably vary by organization. That makes Aurooba’s ARCS dimensions really more of a framework, much like the SPACE framework for developer productivity proposed by Forsgren, et al.⁷ In the SPACE framework, metrics are chosen that fit within the five dimensions.

In this section, I’ll propose some specific example / potential metrics that might fit under each of the ARCS dimensions. Worst case, I misunderstand the whole thing and look dumb on the Internet.⁸ Even if my understanding is a bit off, having something wrong to correct can make it easier to explore a topic.

I believe, without comprehensive evidence, that metrics gathered from within marketing will be noisy and inaccurate—just the way marketers work and the tools they use make it harder to identify task durations or even start/end times for activities.

So, with reminders of the questions above, here is a swing at potential metrics one could choose. (Definitely do not use all of these at the same time!)

Agility

From the perspective of a Marketing Platform Engineering team:

• Count of marketer requests for something the tools should let them do (e.g., change text on a page or launch an A/B test without new components)
• Time between escalations from marketing for urgent feature development
• Work in Progress count (Flow metric)
• Number of slight variations on a theme that need to be built⁹

From the perspective of the marketing team they support:

• Time to make changes to marketing (e.g., to switch to the new branding, or to swap out hero images)
• Time between needing to make requests to MPE for “basic” functionality
• Percentage of marketing activities (e.g., A/B tests, new landing pages) that can be done well¹⁰ without MPE involvement.

Reliability

From the perspective of a Marketing Platform Engineering team:

• Count of incidents
• Downtime due to incidents
• Defects (or Change Failure Rate from DORA?)
• Time to remediate defects (MTTR from DORA)
• Percentage of time spent on keeping-the-lights-on activities (KTLO) vs enhancing the platform

From the perspective of the marketing team they support:

• Downtime (can include incidents, but also includes smaller reliability failures)
• Time spent discussing defects with MPE team (actual defects, not additional features to add)
• Perceived satisfaction with reliability of platform

Cost

From the perspective of a Marketing Platform Engineering team:

• Budget for the MPE team (personnel and licenses)
• Infrastructure budget

From the perspective of the marketing team they support:

• Costs to work around MPE (e.g., contractors, agencies, SaaS tools that replace part of the platform)
• Estimated costs to eliminate MPE¹¹

Speed

From the perspective of a Marketing Platform Engineering team:

• Lead or cycle time for new feature development (Lead Time for Changes from DORA / Cycle Time flow metric)
• Deployment frequency (DORA metric!)
• Throughput (Flow metric)
• Work Aging (Flow metric)

From the perspective of the marketing team they support:

• Count of interruptions in work because of a dependency on MPE
• Time spent waiting for needed feature / capability development
• Lead or cycle time improvement after new capabilities are created by MPE
• Lead or cycle time for “standard” marketing tasks (lots of noise in this)
• Count of marketing activities (e.g., campaigns launched, copy updates, experiments)

An Organization Design Quibble

Aurooba poses an excellent question: where does Marketing Platform Engineering belong in the org chart?. She concludes it’s engineering.

I’m about to quibble with that, but before I do, I want to point out something vital from her argument that I 100% agree with. She explains that an MPE team needs four things to succeed:

• Early involvement (i.e., they need to help shape the platform capabilities and possibly the marketing roadmap, not just be ticket-takers)
• Their own roadmap (i.e., they need the autonomy to balance platform work with feature work, not always prioritizing marketing features)
• Partner-level collaboration (i.e., marketing stakeholders must partner with MPE, not treat them as magical request-handling genies)
• The ability to work in context (i.e., MPE’s systems don’t exist in isolation, and must seamlessly integrate with other company / product systems)

To understand her (strong) argument that MPE belongs within Engineering, read her post, then come back.

I don’t think her conclusion is completely wrong, but I think it’s heavily context-dependent. I’m going to step through a few considerations before making my own suggestion.

Budgets

Most of the work MPE does serves marketing. MPE’s budget should be managed by marketing. While it’s possible for MPE to report up through engineering but draw on marketing budgets, that is likely to cause some difficulty with finance and tracking costs well.

That’s to say nothing of the likely complications with purchase approvals—or arguing about where promotion/raise budgets belong—if those must percolate up through an organization other than marketing.

(To be fair, making a promotion case for an engineer within marketing has its share of complications.)

Purpose and Alignment

MPE build production systems to a high level of rigor that serve marketing. The engineering team builds production systems (or products) to a high level of rigor that serve end users.

I agree that it’s important for MPE to be close to the conversations and roadmaps that shape what engineering builds. And I believe it’s important for MPE to be just as close to the conversations and roadmaps shaping marketing plans.

Marketers, typically, don’t understand engineering rigor. That’s fine—they don’t need to, just like engineers typically don’t need to understand the nuances of constructing an affiliate marketing program. While it’s tempting to put MPE with engineering so the CTO can provide air cover for MPE when it comes to engineering rigor, it’s important that marketers understand enough to give MPE space to work.

As a hybrid function, MPE’s purpose comes from two departments, and must align with both.

Platform Companies vs SaaS vs “Regular” Companies

This section nuances the previous section a bit more.

Depending on the “kind” of engineering a company does, the need for alignment between engineering and MPE will vary.

To take one example of a platform company, Aurooba and I worked together at WP Engine, which primarily sells managed WordPress hosting. Customers pay a fee, and get a WordPress installation that “just works” with some nice features (backups, security, support, etc) added on. Engineering builds the platform, handles security, builds WordPress plugins… all of which is work that aligns closely with our former team’s work of enabling performant marketing sites and user experiences hosted on WP Engine’s platform.

SaaS companies differ slightly from platform companies. Most SaaS companies don’t integrate their marketing technology with the service they sell quite so tightly as web platform companies might. Think Zoom,¹² or Adobe, or DropBox. Slack is arguably a platform company, but most of their marketing is more SaaS flavored and less intertwined with the stuff they sell.

Besides SaaS and platform companies, there are a whole bunch of “regular” companies out there. Insurance companies. Companies that makes tools. Manufacturing companies. Accountants. Some have software engineering departments; some don’t. Even the ones that do have software engineers on staff probably don’t have platforms that would make any sense as a marketing base.

Only a small slice of companies have a synergy between their engineering teams and their marketing platform.

Conway’s Law

Conway’s Law states that “organizations which design systems…are constrained to produce designs which are copies of the communication structures of these organizations.”

A marketing platform is definitely a system, and is (hopefully) designed.¹³

A good marketing platform will facilitate work from multiple marketing teams (design, CRO, analytics, social, …). Skipping a few steps here, that means that the communication structures of the company must put the MPE team in regular, open, partner-level communication with all those marketing teams. And with any engineering teams the platform needs to support.

Exactly what this means for a given company is going to vary a lot. But MPE’s place on the org chart must be selected to create communication structures that mirror the desired shape of the marketing platform (this is known as the “inverse Conway maneuver”). At the very least, the location on the org chart should be selected to avoid putting communication barriers in place.

The Conway factor is far more impactful than most realize.

Another Home for MPE

Because of these factors, I am going to disagree with Aurooba’s suggestion that MPE generally belongs in engineering (and I acknowledge she said “there’s probably not a single ‘right’ answer”).

Instead of engineering, I’d usually put MPE inside marketing. But not reporting up through Creative, or Marketing Operations, or CRO.

I would specifically have the head of MPE reporting to the CMO or a Vice President of Marketing Technology.¹⁴ The point is that MPE needs to be connected high in the marketing organization, and prioritized as a first-class part of marketing.

I agree with all of the factors Aurooba identified for MPE success:

• Early involvement
• Their own roadmap
• Built on collaboration, not tickets
• Balancing context and ownership

…and to me, those factors generally weigh in favor of marketing.

However, context matters. In a platform company, or a smaller company, or a company with siloed communication within marketing, placing MPE within engineering may be more likely to result in success.¹⁵

No matter where MPE is placed, it needs strong lines of communication with both marketing and engineering. It needs to operate with engineering rigor. It needs enough separation from the marketing day-to-day that it can build a platform that enables marketing ARCS, but close enough to the marketing day-to-day that it’s difficult for MPE to lose connection with their “customers”.

And no matter where MPE is placed, it needs to be managed like part of an engineering organization. If engineers within MPE are evaluated solely on marketing criteria, can’t progress in their careers, or are always told to “just make it work before we launch”, MPE will fail to deliver value. It can be a resource that provides incredible leverage—or expensive dead weight. And, to be very blunt about it, the reasons MPE succeeds or fails are mostly on marketing leadership, the organization’s engineering culture, and company alignment.

Here’s why that’s really important. If I’m right that MPE usually belongs in marketing,¹⁶ and the CMO is not willing to prioritize MPE (by having it report high up, by managing it like engineering, etc.), the CMO should eliminate any pretense that MPE matters and instead outsource. Run the marketing tools on third-party platforms. Use agencies to do any set-up or modifications. But don’t pretend you’ll get leverage from a team that’s siloed off.

Wrapping Up

Charity Majors¹⁷ is quoted as saying “The more foundational your work is, the more conservative you should be. You cannot afford to be reckless if you’re handling databases or operating systems. These are the building blocks of your system, so ‘boring’ is essential in those areas.”

Marketing Platform Engineering needs to be “boring” engineering that enables marketing teams to work at their best. It’s not a “by the way” organization or a ticket-taking team.

It’s engineering. It’s marketing enablement. And it’s a fundamentally different discipline than either.

Aurooba is exactly right that Marketing Platform Engineering needs to be identified as its own unique function. Given a name, it can be explored and shaped.

A few thousand words in for me, plus a few thousand for her, and that paragraph above is the biggest point. Metrics, org chart placement, all of those details matter a lot less than that basic concept: Marketing Platform Engineering is something different.

Treating it as its own separate thing is important—not because it needs to feel special, but because in doing so, it will enable those already doing Marketing Platform Engineering to do better, and that will improve overall marketing metrics.

Thanks to Aurooba for her comments on an early draft of this post.

1. The web development team at WP Engine was responsible for building a platform for the rest of Marketing to use for putting content and experiences on the web. It’s the first time in my career my team was inside Marketing, and it was a fascinating experience. [↩]
2. And the ones I didn’t very much enjoy working with are the ones I didn’t have as much of a chance to get to work with or know. The “I like less than half of you half as well as you deserve” quote comes to mind. [↩]
3. Two particular streams, as it happens. The Cedar River, which runs through Cedar Rapids. And the Bois Brule River in northern Wisconsin, which is where I learned to canoe rapids. [↩]
4. Not that organizational design or workflow design is everyone’s jam, especially in marketing. But at least it starts to become clearer that it’s not just a problem that can be addressed by defining a place to submit tickets, or having a meeting once a month to review priorities, or yelling at each other. [↩]
5. Often shortened to “what gets measured gets managed” and misattributed to Peter Drucker. [↩]
6. Creating tension between metrics is a principle I use when defining metrics for a team. It even shows up in metrics for professional athletes. Take American football quarterbacks for example. Throwing for more yards is good, but completing passes can be more difficult. A higher completion percentage is good, but sometimes a quarterback needs to throw the ball incomplete to avoid getting sacked. Taking sacks is bad, but taking a sack can avoid an interception, which is worse. And, coming full circle, interceptions are more likely on long passes that would rack up more yards. [↩]
7. If you haven’t read the linked article, and have any interest in measuring productivity, it’s worth your time to read. Even if you’re not measuring developer productivity specifically, there is a lot of wisdom to be had (e.g., “Having too many metrics may lead to confusion and lower motivation” or “These metrics…should never be used in isolation to make decisions about individual or team productivity.” — and that’s just two random sentences I scrolled past!). [↩]
8. That, of course, will be the first time anyone has ever looked dumb on the Internet, which will make me famous! Wait. I’m being told…oh. Apparently, it will not be the first time. [↩]
9. As opposed to making the variations configurable. If you have, say, “Text Box (left justified, top justified, red background)”, “Text Box (left justified, vertically centered, green background)”, and “Text Box (right justified, top justified, green background)”, MPE has duplicate code to maintain. There’s also a lot of burden for the marketing teams. And if someone needs right/top/red, that’s a whole new component to build. (This is true technical debt, in the sense that the as-built technical environment does not match the business environment.) [↩]
10. No hacks, no fragile workarounds. [↩]
11. For all “cost” items, it’s worth comparing the MPE costs against the costs of not having MPE. If the TCO of MPE is larger than the TCO of a bit of SaaS / platform / contractor development, it’s reasonable to get rid of MPE. But make sure you’re evaluating the full cost. For example, if you get rid of MPE, will the product engineering team get interrupted occasionally (or frequently!) to review work from technical contractors hired by marketing? That’s a huge, hidden cost there. [↩]
12. I do quite enjoy the idea of Zoom insisting they “eat their own dogfood” for marketing. Instead of new landing pages, they’d have new long-running meetings telling prospective customers all about how great Zoom meetings and webinars are. It’d be truly ridiculous. [↩]
13. If a marketing platform is sprawling or un-designed—an aggregation of components and services all lumped together because they were independently picked out once upon a time and must be maintained forever—someone who is aware of Conway’s law can deduce that the marketing platform shows the communication structure of the organization. It’s sprawling, not well connected, and undisciplined enough to be focused solely on the next shiny object. I suspect this mode is far more common than the reverse, in which the marketing platform is too tightly bounded. Both modes will have serious negative effects on long-term productivity. [↩]
14. Depending on the size of the company and marketing department. Titles may vary. Void where prohibited. [↩]
15. There are times I might even advocate for temporarily moving MPE to engineering to reset expectations within marketing, so that when MPE moves back into marketing expectations and behaviors are calibrated for success. “Temporarily” is doing a lot of work here, but I’m not envisioning a short time period. Six months is about the minimum that would make it worthwhile, and a year or more is quite reasonable. The temporary move is probably best done if MPE has a significant project to focus on, so the project focus reinforces the organizational move. [↩]
16. And I realize I’m disagreeing with Aurooba, who is very smart and is very often right, about where MPE belongs. [↩]
17. Charity Majors knows a thing or two about technology, building solid systems, and keeping things running. [↩]