Working Notes

Category: Engineering

  • Editorial experience is a core marketing platform concern

    One of the skills marketing platform engineers need to get very good at is designing editorial experiences.

    Not the pixels or the exact design visually speaking, but rather the semantic experience of interacting with the editor. There’s an art to it.

    If you work on a marketing platform long enough, you start to realize that the editor is a core part of the product for a large group of people. It’s not the whole thing, but it’s the part most people experience most often. Designers, authors, marketers, PMMs, SEO specialists, ops folks, sometimes even founders. Anyone who touches content ends up living inside the editorial experience in some way.

    And importantly, this isn’t your system. It’s the system you’re charged with designing, curating, and maintaining in service of the marketing team.

    Their day-to-day relationship with that system shapes how fast they can work, how confident they feel, and how effectively they can focus on the actual work.

    You don’t need to be a UX designer to do this well. You do need a deep understanding of how the people using the editorial experience think and operate.

    Editorial experience is not just “the UI”

    When people talk about editorial UX, it often gets framed around questions like:

    • Is it visual or form-based?
    • Is it flexible or structured?
    • Is it WYSIWYG or field-driven?

    Those questions are important but they aren’t complete.

    The core question is:

    Does the system help someone express intent clearly and predictably?

    A strong editorial experience is semantic. It helps people interacting with content answer questions like:

    • What kind of thing am I working on?
    • What matters here versus what’s optional?
    • How will this content behave elsewhere?
    • What decisions am I making right now?

    When those answers are unclear, teams rely on conventions, Slack messages, Notion docs, and shared context to compensate. When they’re clear, work moves faster with less coordination overhead.

    This matters no matter what CMS you’re using. It’s true whether you’re working in:

    • A heavily field-based CMS
    • A visual, block-based editor
    • Something hybrid in between

    The technology changes. The problem doesn’t.

    In a field-based system, poorly defined structure can lead to bloated models and inconsistent usage. In a visual-first system, unclear semantics lead to fragile layouts and unpredictable outcomes.

    In both cases, the job of the marketing platform engineer is to create guardrails that encode intent.

    That means thinking carefully about:

    • Naming: what words we use for blocks, fields, and sections. (Yes, naming is hard. Worthwhile things usually are.)
    • Structure: what’s repeatable, what’s composable, what’s fixed
    • Defaults: what happens when someone does nothing
    • Constraints: where choices are intentionally limited and why

    These are product decisions, even if they’re expressed in code.

    Marketing platform engineers aren’t product engineers, but product thinking is valuable when shaping the marketing platform editorial experience.

    The shape of a good editorial experience

    When I think about designing a strong editorial experience, a few questions always come up:

    • What does the setup state look like, and when do we need one?
    • What does the editing experience look like once someone is past that initial moment?
    • Can people jump straight into editing, using sensible defaults to communicate intent?
    • What does the preview state look like, and where does it live?

    Each of these moments sets expectations.

    A thoughtful setup state orients someone without slowing them down. Defaults communicate intent without requiring explanation. A reliable preview experience builds confidence and trust between the editor and the system.

    None of this happens accidentally. It’s the result of deliberate design decisions.

    Why this is both taxing and rewarding

    Personally, I find this part of the work the most taxing and the most rewarding.

    It lives in the space where design intent, marketing goals, technical constraints, and human behavior meet. There’s rarely a single correct answer, and feedback often comes from real usage rather than upfront validation.

    But when it starts working, the impact compounds.

    People stop asking for exceptions. Designers trust the system. Engineers spend less time handling edge cases. The platform starts to feel aligned with how the team actually works.

    That alignment is designed.

    Marketing platform engineering is partly about empathy

    Marketing platform engineering eventually becomes about understanding people.

    Understanding how different roles approach content, where uncertainty shows up, and what the system needs to make obvious.

    If you’re building platforms for marketing teams and you’re not designing the editorial experience with this level of care, you’re leaving leverage on the table.

    And if you are, you’re doing meaningful product and design work alongside engineering, whether or not your role explicitly names it that way.

  • How to judge a CMS: mandatory vs. extensible

    This post is written for the people actually inside the work: the marketing platform engineers and technical content strategists who spend real time modeling content, shipping workflows, and trying to create a CMS that doesn’t fight its own authors. What follows isn’t a high level executive checklist. It’s a practitioner’s view of the table-stakes capabilities a CMS needs if it’s going to function at the centre of an enterprise marketing platform and the extension points it absolutely has to make possible.

    If you’ve ever evaluated CMSes for marketing teams, or had to live with ones chosen for you, you start to see the same split over and over. There are the things that absolutely have to come out of the box, and then there are the things a CMS doesn’t need to ship natively, as long as it is extensible enough that you can build them without heroic effort. You can customize plenty, but you shouldn’t have to rebuild the foundation just to get work done.

    That split leads naturally to two buckets: the capabilities that must exist out of the box, and the ones the CMS doesn’t need to ship natively but absolutely needs to make possible through clean extension points. Both matter, but for different reasons: one is baseline viability, the other determines whether the CMS can grow with you instead of boxing you in.

    And sometimes having something out of the box can work against you. You get boxed into their version of a feature instead of building the one you actually need. But there are a few places where out of the box support is not just helpful, it is mandatory. Anything less and you are paying down CMS debt forever: through migrations, brittle plugins, duplicated models, or constant workaround engineering.

    The mandatory bucket

    So let me start with the first bucket, the mandatory one. These are the missing capabilities you feel instantly, the seams you end up patching with scripts, plugins, governance rules, or expensive workarounds.

    Different systems solve these in different ways, but if too many of them are missing out of the box1, you end up relying on workarounds more than you should. At some point, the CMS stops feeling like the centre of the platform and starts feeling like another constraint.

    Multiple component or field types for authoring content

    A CMS needs to support more than a single monolithic content shape. Marketing content comes in many forms, so the system has to offer a variety of fields and components so marketers can structure content properly without developer intervention.

    The ability to extend existing component and field types for authoring content

    A CMS should let you extend or customize components without forking the system or building brittle hacks, and without having to register entirely new field types just for small tweaks.

    Conditional component or field settings

    Marketers should be able to configure components based on context. If the CMS supports conditional logic, you can simplify the authoring experience and enforce guardrails without forcing everything into templates.

    Rich text editing

    There is no world where marketing can function without reliable, flexible rich text editing. The editor needs to be stable, predictable, and capable of handling formatting, embeds, and basic structure.

    A way to preview your work before publishing

    Marketers need to see their content in context, not guess how it will render. A preview workflow is essential for quality, especially when content appears in multiple layouts or templates.

    A way for other authenticated users to preview work before publishing

    Collaboration does not work if only the author can see drafts. Stakeholders need authenticated previews so they can review work without screenshots or copy-pasted text.

    Drafts that actually behave like drafts

    Drafts need to save safely, persist over time, and avoid leaking into the live site. If drafts are unreliable, marketers stop trusting the CMS and start working in Google Docs instead.

    Content scheduling

    Scheduling is basic operational hygiene. Marketing plans revolve around timing, and a CMS that cannot schedule content reliably creates unnecessary production pressure.

    Multiple taxonomies

    Content needs to be classified from multiple angles. Tags, categories, segments, journeys, and whatever else the team relies on should be possible without workarounds.

    A sane way to delete content

    Deletion should not be destructive or terrifying. Ideally there is an archive or soft-delete flow that prevents accidental loss but still gives teams control over what stays and what goes.

    Ways to separate content types cleanly

    Pages are not blog posts, and neither are announcements or landing pages. A CMS needs to logically separate content types so models stay clear and marketers are not overloaded with irrelevant fields.

    Navigation management

    Navigation is content. Teams need a straightforward way to manage menus, labels, and links without opening engineering tickets for every change.

    Some kind of asset management

    Images, videos, SVGs, PDFs, etc are all relevant when you’re creating marketing content, and a CMS that cannot handle assets in some way out of the box (without addons) creates unnecessary friction.

    Role based permissions

    Different people need different levels of access. Clear, native role-based permissions keep content governance sane and reduce accidental edits.

    A way to reuse content

    When teams build content modules, promos, or key components, they should be usable across the site without duplication. Reusability reduces drift and keeps messaging consistent.

    A way to create templates / content blueprints

    Not every page should start from scratch. Templates or blueprints give marketers the structure they need while still allowing flexibility.

    A way to version control your fields, components, and content types

    Content modeling evolves over time. Having version control keeps changes intentional and safe, and it makes collaboration between developers far easier.

    Ability to comment on content inside the CMS

    Inline comments let marketers and reviewers collaborate directly where the content lives instead of juggling external docs or Slack threads.

    A way to duplicate content

    Sometimes you do not want to start from zero. Duplication allows teams to reuse structure or layout quickly. It is astonishing how many CMSes still treat this as an extra.

    Basic content history

    Teams need visibility into who changed what and when for individual items. A basic history or audit trail builds trust, helps debugging, and supports compliance.

    An ability to integrate with external services and vendors

    Modern marketing stacks depend on many tools. And together they form a bespoke platform for the marketing team. A CMS should make it straightforward to integrate analytics, translation, experimentation, or personalization systems without breaking its core.

    Multi-tenant capable

    As marketing platforms grow, they often need multiple sites, regions, brands, or properties that share infrastructure but differ in content, configuration, or governance. A CMS should be able to support this without hacks, duplicated environments, or brittle workarounds. Multi-tenant capability keeps things scalable, maintainable, and aligned across teams while still allowing the separation you need.

    A predictable way to manage URLs and redirects

    A CMS should let teams define and adjust URLs safely without breaking the site or requiring engineering intervention. Redirects, slug changes, and URL patterns should be manageable and transparent. When URL behavior is unpredictable, everything from SEO to content migration becomes painful.

    A way to perform bulk operations safely

    A CMS should allow teams to update, archive, delete, or modify high-level attributes across multiple items without resorting to one-by-one edits or manual queries. Bulk operations matter for migrations, taxonomy changes, rebrands, housekeeping, and large-scale content updates. When the CMS cannot handle these safely and natively, the burden shifts to engineers and slows down the entire marketing workflow.

    A way to define structural relationships between content

    A CMS should support simple structural relationships so content can be organized and connected in ways that reflect how people actually navigate information. This includes the ability to create parent and child hierarchies, reference other content items directly, and maintain these connections predictably over time. Marketing content often depends on these structural links for sequencing, context, and discoverability, and without them the underlying platform becomes inconsistent and difficult to scale.

    Publishing automation hooks

    A CMS should provide reliable events or triggers for core actions such as creating, updating, publishing, unpublishing, and deleting content. These hooks are essential for keeping the rest of the marketing platform in sync, whether that means updating a search index, regenerating pages, clearing caches, triggering notifications, or syncing with external tools. Without predictable publishing events, teams end up building brittle polling systems or manual workarounds that slow down every workflow.

    The extensible bucket

    These are the things you don’t need out of the box, but you absolutely need clean extension points for. If you’ve ever had to hack a CMS to do something it never intended, you know why this category exists.

    Once the essentials are covered, the next category is the set of things that do not need to come bundled, but the CMS still needs to make straightforward to build. This is where flexibility matters. If the architecture is sound and the extension points are clear, you can shape the system to fit your team’s needs without fighting it or piling on technical debt. These are not table stakes, but they become critical as your marketing platform grows and your workflows mature.

    SSO integration

    The CMS does not need to ship SSO by default, but it should not fight it. Authentication needs to fit into the larger company ecosystem cleanly and without custom rewrites.

    A way to un-publish content on a schedule

    Unpublishing at a specific time is common in campaigns, promos, and regulatory updates. If the CMS doesn’t ship it, it should at least provide hooks to build it without contortions.

    A way to create a changeset and schedule it to go live

    Coordinated releases often involve multiple pieces of content. The CMS should make it possible to group changes and publish them together on a defined schedule.

    A way to archive content

    Archiving lets teams hide content without deleting history. Even if it is not built in, the CMS should make it easy to create this state and manage it consistently.

    A way to create approval based workflows

    Most marketing teams eventually want review steps. If the CMS doesn’t include this natively, its API and model should make it feasible to build a clean, reliable approval flow.

    A platform wide audit trail

    If the CMS’s native history is limited, it should still expose enough structure to layer on deeper, cross project auditing. This becomes especially important in regulated industries or when content spans multiple properties.

    A way to move from staging → QA → production for complicated work that involves more than just content changes

    Sometimes content updates come bundled with schema, template, or configuration changes. The CMS should support multiphase promotion paths or at least give you the tools to build them.

    A way to localize content on a granular level

    Not every CMS ships sophisticated localization. What matters is that you can build locale-specific variations, syncing logic, or translation workflows without rewriting the platform.

    A way to register custom validation rules

    As content models grow more complex, teams need the ability to define their own validation rules to protect quality and prevent broken layouts. A CMS should make it possible to enforce requirements such as mandatory fields, mutually exclusive options, allowed combinations, or component level constraints without resorting to manual checking. Even if this is not built in, the CMS should expose clear extension points so teams can add consistent, reliable validation that supports the way their authors actually work.

    A few ending thoughts

    One more point that matters but doesn’t neatly fit into either bucket:

    A CMS has to meet marketers where they are.

    Different organizations have different levels of technical comfort, content complexity, and operational maturity, and the CMS needs to match that reality instead of forcing teams into workflows they’re not ready for. A system can be powerful on paper and still be the wrong fit if the day-to-day authoring experience doesn’t feel approachable to the people actually using it.

    And it is worth stating plainly: our stakeholders are the marketing team. Their comfort, not ours, is the benchmark. A CMS that feels elegant to engineers but confusing to marketers has already missed the point. It also cannot be designed only for the most technical people on the team. A healthy authoring experience should support the full range of contributors, from power users to occasional authors. The whole purpose of the technical foundation is to make their work easier, faster, and more reliable, not to optimize for the preferences of the people building it.

    If you’re a marketing platform engineer, architect, or anyone responsible for the long-term health of a marketing CMS, these buckets are a starting point, not a standard. Use them to start conversations, challenge assumptions, and refine how you evaluate the systems you depend on. Teams evolve. Workflows mature. Your CMS has to keep up with both.

    The reason this list is long is because the pain shows up in the details. When you’re actually inside the work, building models, shipping content, integrating workflows, these are the places where CMSes either support you or work against you.

    1. This caveat is important, because I’ve yet to discover a CMS that includes everything in my mandatory list. ↩︎

  • What is a Marketing Platform?

    I’ve been chewing on a question lately that keeps showing up in my work: what actually counts as a marketing platform? Not the high-level marketecture, but the real thing you end up building toward when a company grows past “we have a website” and into “we need a system we can rely on.”

    A lot of tools call themselves a “platform.” A CMS calls itself one. Some SaaS tools take it even further and brand themselves as a DXP, a digital experience platform, promising content, personalization, testing, analytics, and half the stack in one place. That’s the pitch. But real marketing operations rarely match those diagrams.

    Marketing work is iterative, cross-functional, and dependent on timing. And the systems that support that work evolve in ways that are far more layered, operationally and technically, than any vendor roadmap suggests.

    So I’ve been trying to articulate what a marketing platform actually is in practice, especially inside companies that outgrow the idea that one tool can hold everything together.

    A CMS is not a marketing platform

    At its core, a CMS solves a specific problem: how to store, structure, and publish content. That’s essential, but it’s nowhere close to the full picture of how modern marketing operates. A CMS doesn’t tell you:

    • whether the content is performing
    • how personalized it should be
    • how it fits into the journey
    • how it interacts with experiments
    • or how teams collaborate to move updates safely

    A CMS is the home for content. It’s not the engine for growth.

    A marketing platform is the ecosystem

    The more I work in this space, the more a marketing platform looks like an interconnected system: tools, workflows, data flows, APIs, governance, design language, and delivery layers that let marketing operate with speed and clarity.

    In most companies, it doesn’t look like the polished DXPs vendors sell. It looks like a tailored, composable version built over time, informed by the business, the audience, and the people doing the work.

    Some parts of it are obvious:

    • the CMS
    • the frontend
    • the design system
    • the analytics pipeline
    • the experimentation framework
    • the asset pipeline
    • the metadata and search layer
    • the integrations and APIs that glue everything together

    But the invisible elements are just as important:

    • how content moves through review
    • how requests flow
    • how experiments roll out safely
    • how versions are governed
    • how data moves across boundaries
    • how design tokens and content schemas enforce consistency

    A marketing platform isn’t a single tool, it’s how all these components reinforce each other to make marketing predictable, fast, and safe.

    This is where marketing platform engineering actually shows up: keeping the seams intentional instead of accidental.

    Why the CMS sits at the centre

    Here’s the piece that’s hard to get away from: the CMS really does sit at the center of everything. It’s not the platform, but it shapes the entire platform’s behavior.

    • The content model becomes a data contract.
    • The APIs define frontend architecture.
    • The editorial UI shapes workflows.
    • The schema affects analytics, personalization, search, accessibility, and consistency.
    • The versioning patterns affect deployments and cross-surface stability.

    You can switch analytics providers without rewriting your world.

    You can rebuild your frontend without rethinking your operating model.

    But switching the CMS? That’s a seismic move. Necessary sometimes, but never small.

    Which is why choosing the right CMS matters. You want one that adapts as needs evolve, expands when the organization gets more ambitious, stays light when workflows demand simplicity, and avoids boxing the rest of the stack into awkward patterns.1

    The CMS isn’t the platform, but it defines the platform’s shape.

    The bespoke DXP most companies actually build

    Commercial DXPs are the “buy everything” approach. But most companies end up building their own version over time, shaped by actual business goals, internal maturity, and the realities of the team.

    At first, things feel messy or inconsistent. But as a company invests in clearer APIs, stronger content models, consistent design tokens, reliable data flows, and thoughtful governance, the system starts behaving like a platform, not a collection of tools.

    Marketing platform engineering isn’t a rebrand of frontend engineering, analytics engineering, or design systems. It’s the discipline of ensuring the entire ecosystem behaves cohesively, safely, and predictably across content, delivery, experimentation, and operations.

    No single existing discipline owns that. Someone has to.

    That’s the direction I keep coming back to: a composable, API-literate, long-term marketing platform that grows with the company instead of constraining it.

    I don’t have a perfect definition yet

    And honestly, that’s fine. I’m still exploring it. I know a CMS isn’t the whole platform. I know marketing increasingly needs its systems to behave like unified, dependable infrastructure. And I know strong engineering practices, content architecture, design systems, and workflows matter far more than the vendor logo.a

    But the shape of the definition is starting to form and feeling more right:

    A marketing platform is the system that enables marketing teams to work at their best, consistently, repeatably, and at scale.

    I’ll keep refining this as the work continues. For now, this is where the thinking lands.

    Footnotes

    1. If all I need is a basic page, I don’t want to click around and create 5 different pieces, I just want to create a page. But if I need something complex for a large campaign, then heck yeah, I want to lean into reusability. ↩︎

  • Why We Choose What We Build With

    I’ve been thinking about how teams make technology decisions. After seeing the same patterns repeat across a few different teams, it’s started to make sense to me why some ideas take root easily while others never seem to get traction.

    On the surface, it looks like a logical exercise: tradeoffs, benchmarks, cost of ownership, performance, security, velocity. We make comparison charts, run evaluations, and try to arrive at an answer that feels objective.

    But technology choices are rarely made with logic alone. They are about identity.

    Every stack carries a culture. React has its fast-moving product-builder vibe, Ruby on Rails has its elegance and craftsmanship story, WordPress has its scrappy pragmatism and deep commitment to composability. Every ecosystem has its myths, heroes, and villains, and joining one means subscribing to a particular worldview about what “good” software looks like.

    So when a team defends or rejects a technology, they’re often defending or rejecting a part of their identity1. It’s not, “we use React because it’s modern,” rather it’s “we see ourselves as builders who stay at the edge of what’s current, always experimenting, always shipping.”

    This kind of shared identity becomes more entrenched the longer a team works together and invests in a particular stack. Suggestions to change it can feel like a challenge to the group’s sense of self. This can be especially noticeable if a vilified technology resurfaces later as a viable solution. Even when the data supports the alternative, emotion quietly wins.

    This isn’t good or bad, it’s just real. It’s a reality worth naming, because once you do, you can stop asking why a team is resisting something and start understanding what identity they’re protecting and what worldview they’re defending.

    And perhaps that is the first step to making better decisions, not by removing the emotion but by understanding the culture and sense of belonging that shape them.

    Once you start seeing technology through the lens of identity and belonging, you notice it everywhere: in the tools we defend, the language we use, the stories we tell about what “good” looks like.

    In the end, choosing the “right” technology isn’t just about logic. It’s about what we feel at home building with, what aligns with our identity, and what we believe is worth our time and care. There’s no single right answer, only what’s right for your team, right now.

    Footnotes

    1. That’s why decisions like this one from Motion to move off of Typescript feel so big. ↩︎

  • Stacking PRs Without Losing Your Mind (or Your Velocity)

    Generally speaking, I’m a big fan of trunk-based development. There’s plenty online about what it is, but in short, it’s a workflow where you’re constantly merging into a trunk or main branch, and you branch off from there whenever you’re making new changes.

    There’s a lot of goodness baked into trunk-based development: it naturally encourages continuous integration, sets the stage for continuous deployment, promotes the use of feature flags, forces testing discipline, enables faster and better code reviews, and can be a solid forcing function for thinking in smaller, incremental changes.

    But what happens when you are working on a large and complicated feature, and you are waiting on code reviews for previous PRs because your next ones depend on them?

    That’s where stacking workflow comes in.

    Now, folks often do stack PRs by branching off an existing branch instead of main. The problems start when you need to stack more than two or three PRs, and upstream feedback changes need to cascade down through the rest of the stack.

    That’s where proper stacking workflow tools earn their keep. They actually work quite well with trunk-based development because you’re still merging into main, sequentially, not into a long-lived feature branch.

    That said, I’ll go to great lengths before resorting to stacking. That’s a post for another day; trunk-based development strategies for big features.

    There are a bunch of CLI tools that help you manage stacked PRs, the one that I’ve used with success is git-town (which has many other useful features as well).

    Even if you do use stacking, “tall” stacks suck. They’re an anti-pattern. Keep your stacks as small as possible. Push for reviews on your earlier PRs and merge them quickly to keep the chain tight.

    Stacking helps you increase your velocity and keep up your momentum, but the single responsibility principle still applies to every PR. The moment you break that, you’re signing yourself and your team up for a world of pain.

    Yes, there will be times you bend that rule. But think very, very hard before you do.

    There’s more I’ll say on this topic another time, but for now, I’ll leave you with this: there’s a natural intersection between trunk-based development and the stacking workflow, and it’s worth understanding both if you want to move fast without breaking things.

  • Where does Marketing Platform Engineering belong?

    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.

    This is post is a part of a series on Marketing Platform Engineering. Read the next post here on what a marketing platform is.

  • The Impact of Marketing Platform Engineering

    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.

    This is post is a part of a series on Marketing Platform Engineering. Read the next post here on where I think MPE belongs in an org.

  • What Marketing Platform Engineering isn’t

    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.

    This is the second post in a series on Marketing Platform Engineering (MPE). Read the next post here on the impact of MPE.

  • 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:

    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 vendors1, 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.

    This is the first post in a series on Marketing Platform Engineering. Read the next post here on what it isn’t.

    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. ↩︎