Category: Engineering

Your engineering team can build a new marketing page in a few hours.

But getting it live takes weeks.

Not because anyone is slow. Not because the work is hard. But because the system wasn’t built for this kind of change.

AI has made this tension more visible.

With the right tools, small, highly technical teams can generate pages directly in code, iterate quickly, and bypass much of the infrastructure that used to feel required. For teams where the same people design, write, build, and ship, working without a CMS can be a rational choice¹.

That approach can work well.

But it optimizes for a very specific shape of organization. And most teams don’t look like that for long.

For most teams, a marketing website isn’t just a set of pages. It’s a marketing platform. And treating it like one fundamentally changes the cost of change.

A marketing site has an audience and users, and they are not the same

This is where the complexity usually gets underestimated.

A marketing website’s audience is prospects, customers, and the public. But its users are internal: editors, marketers, designers, SEO specialists, data teams, legal, brand, leadership.

Those two groups have very different needs. And the platform has to support both at the same time.

Once you separate those layers, the work stops being about pages and starts being about leverage.

The questions shift to:

• How long does it take marketing to launch an experiment without engineering?
• How safely can teams make changes without risking brand, performance, or compliance?
• How easily can content be reused, measured, and evolved?
• How expensive is each change in engineering time, context switching, and opportunity cost?

These are not theoretical concerns. They show up as cycle time, missed experiments, delayed campaigns, and teams waiting on each other.

AI changes how we build, not what breaks at scale

AI is an accelerant.

It lowers the cost of implementation. It helps teams generate code faster. It makes iteration feel cheap. And that’s powerful.

What AI doesn’t change is organizational complexity.

It doesn’t decide who can publish what. It doesn’t design workflows. It doesn’t resolve governance, analytics consistency, accessibility requirements, or long-term maintainability.

In fact, AI often makes bad architecture ship faster.

When structure is missing, speed just moves the bottleneck elsewhere. Marketing waits on engineering. Engineering becomes the gatekeeper for small changes. Experiments that could have shipped in a day take weeks instead.

A CMS isn’t just a content store. It’s where decisions get made explicit rather than implicit. About:

• how content is modelled and reused
• how editorial workflows function
• how accessibility and localization are handled
• how performance and analytics are enforced
• how new page types and experiments are introduced

Choosing not to have that structure is still a choice. But it pushes those decisions into code, documentation, or a handful of people. That can work at small scale. It becomes fragile as velocity and headcount grow.

Hard-coding pages feels fast, until it becomes expensive

Hard-coding pages often looks like speed.

And initially, it is.

But over time, the costs are predictable. Marketing requests pile up. Engineers spend more time on one-off changes. Experiments slow down because every iteration requires a deploy. Eventually, teams start talking about a rebuild.

The real cost isn’t just time. It’s lost opportunity.

When a team could test three variations in a week but only ships one in a month, learning slows. When campaigns miss windows because changes are gated on engineering availability, revenue is left on the table.

None of this happens because teams made bad decisions. It happens because the system was optimized for immediacy rather than adaptability.

“We’re not most companies” (and when that’s true)

A common reaction here is: This doesn’t apply to us. We’re technical. We move fast.

Sometimes, that’s true.

If your marketing site is owned end-to-end by a small engineering team, if content changes are infrequent, and if marketing doesn’t need autonomy, a code-first approach can be efficient.

The question is not whether it works today. It’s how long it keeps working.

As soon as marketing needs to move independently, as soon as experiments increase, as soon as more people need to touch the system, the shape of the problem changes.

This isn’t about company size. It’s about organizational complexity.

What success actually looks like

When a marketing platform is working well, a few things change in measurable ways.

Marketing can ship experiments in days instead of weeks. Engineers spend less time on one-off changes and more time improving shared systems. Design sees consistency in production without constant oversight. The cost of change goes down.

That’s the real return on investment.

Not that you shipped one page faster, but that you can keep shipping, learning, and adapting without hitting friction every time.

Speed and structure are not opposites

The tension between speed and foundations is understandable, especially in an AI-driven world.

But structure is not the enemy of speed. It’s what makes speed sustainable.

This isn’t an argument against AI, or against code-first workflows. It’s an argument for choosing them deliberately, based on how your team actually operates and where you want to be in a year.

You can optimize for shipping quickly today.

Or you can build a system that keeps letting you ship quickly as the organization evolves.

Both are valid choices.

They just lead to very different futures.

1. aka what Cursor did. ↩︎

One of the most gratifying things about writing publicly is when someone doesn’t just agree or disagree in passing, but takes the time to really engage with your thinking. Matt did exactly that in post about Marketing Platform Engineering on his blog, and I want to start by saying thank you.

There’s something deeply nostalgic and deeply right about this kind of interaction. A blog post responding to a blog post. Thoughtful engagement that stays where the thinking originated, rather than being flattened into a tweet or a LinkedIn comment. That kind of exchange is rarer than it used to be, and I’m genuinely grateful Matt chose to engage this way.

Matt is also one of the smartest people I know. He’s spent far more time thinking about organizational design than I have, and he brings a managerial and leadership lens that I simply don’t yet have. I learned a lot from his post, even in the places where I ultimately land somewhere different.

Today, I want to focus specifically on the organization design aspect of his piece. If you haven’t read his post yet, go read that first. 🙂

MPE as a dual-alignment function

One of the core points Matt makes, and one I fully agree with, is that MPE’s purpose comes from two departments, and must align with both.

That framing resonated deeply with me because it mirrors how the work shows up day to day. Regardless of where MPE sits on the org chart, the team is constantly operating in between marketing and engineering. There is a lot of translation involved. A lot of making implicit assumptions explicit. A lot of helping each side understand not just what the other wants, but why.

This isn’t something unique to one reporting structure. It’s inherent to the role itself. Because MPE lives at that intersection, alignment with both sides isn’t optional, it’s part of the job.

Company context shapes what “right” looks like

Another part of Matt’s post that really sharpened my thinking was his distinction between platform companies, SaaS companies, and what he calls “regular” companies.

Reading that section made me realize how unspoken my own lens has been throughout this series. I’m used to working in software-first organizations, where engineering is always present, central, and structurally important. That’s a very particular slice of the world.

Matt is absolutely right that in many companies, engineering either doesn’t exist in the same way or exists in a form that has very little overlap with marketing technology. In those contexts, it would make no sense at all for an MPE team to sit within engineering. In a mechanical engineering firm, an insurance company, or a manufacturing business, MPE should very clearly live inside marketing.

That nuance matters. It doesn’t invalidate the engineering placement argument, but it does limit the contexts where it makes sense.

Budgets, accountability, and structural tradeoffs

Matt also raised something I hadn’t thought through carefully before: budgets.

In theory, “the company funds the team.” In practice, departments own budgets. Someone pays.

I agree with Matt that in most cases, it makes sense for MPE’s budget to come from marketing. Marketing is the customer. Marketing is who the platform primarily exists to serve. That alignment is clean and intuitive.

Where I start to diverge slightly is in the assumption that budget ownership must automatically determine reporting structure.

Engineering organizations already fund teams that don’t build end-user features: infrastructure teams, enablement teams, internal platforms. You could reasonably argue that a marketing platform is another internal platform, and that from an accountability and rigour perspective, it belongs within engineering, even if marketing is funding it.

That setup is undeniably messier. It introduces friction with finance, with planning, and with incentives. But it may also create clearer accountability and stronger pressure for the two organizations to learn how to work together.

I’m currently living inside that experiment. Marketing funds the work, while the team reports through engineering. So far, it’s workable. Whether it’s sustainable long-term is still an open question.

Rigour, speed, and the value of tension

In one of my posts, I implied that placing MPE within engineering allows a CTO to provide air cover around rigour and standards. Matt pushes back on that framing in a thoughtful way, and I think he’s right to.

The more I sit with this, the more I think rigour isn’t primarily enforced by org charts. It’s a function of how MPE behaves and what standards it chooses to hold itself to.

What is very real, and something Matt’s post helped me articulate more clearly, is the tension between marketing’s desire to move fast and engineering’s desire to move right. That tension isn’t a problem to solve away. It’s a productive force.

Where MPE teams lose their ability to create compounding value is when they collapse that tension, when they fully optimize for speed or fully retreat into purity. Either way, the platform stops being a platform.

In some organizational setups, including ones where budget and reporting don’t perfectly align, that tension becomes harder to ignore. Not because MPE should be responsible for fixing organizational dynamics, but because the structure itself resists oversimplification.

That balance is difficult. I’m still learning how to navigate it.

Continuing the conversation

I’m deeply grateful to Matt for engaging with my work so thoughtfully and generously, and for taking the time to write such a considered response. His post is excellent, and this piece only engages with one part of it. I’m looking forward to engaging with other aspects of his thinking in future posts. 🙂

Over the last little while, I’ve had the chance to spend a lot of time inside different CMSes. Not just skimming docs or watching demos, but actually building something small and real with them.

As part of a broader evaluation, I revisited six CMSes I already had experience with, some recently, some not so recently, and explored a handful of others more lightly. To force myself out of abstract comparison mode, I built the same small site multiple times. I prototyped the idea first, then implemented it across each system. I leaned on AI heavily to move faster, and over the course of about a week, I ended up with a set of scrappy but functional proofs of concept.

What surprised me wasn’t how different these systems were. It was how similar many of their ambitions have become.

Most of the CMSes I evaluated deeply were headless. That wasn’t accidental. Headless was a hard requirement for the context I was working in, for a variety of migration related reasons.

As I spent more time inside these tools, something kept catching my attention. Almost every headless CMS I touched was investing heavily in some form of visual editing or live preview. Some had already built it. Some were actively reworking it. Some were clearly racing toward it.

That struck me as interesting.

The original promise of headless CMSes is that content and presentation should be decoupled. Editors focus on content. Developers focus on rendering. Content becomes portable, reusable, and adaptable to many different outputs.

Conceptually, this makes a lot of sense. Especially if you imagine an organization with a truly diverse set of surfaces. A marketing website. A web app. A mobile app. A kiosk. Digital signage. Maybe even hardware.

In that world, it’s reasonable to think about content as something that exists independently of how it looks anywhere in particular.

But once you get into the day to day reality of how most organizations work¹, that model starts to feel a bit fragile.

Yes, there are some kinds of content that genuinely travel well. An announcement banner is the example I keep coming back to. A short sentence. A call to action. That kind of content can live almost anywhere with very little adaptation. Website. App. Notification. Screen on a wall. The same is often true for product data, things like names, prices, SKUs, or availability. This information is primarily data, not presentation, and different surfaces can consume it and render it in ways that make sense for their context.

But most content isn’t like that.

The way you write and structure something for a website is often different from how you’d write it for a mobile app. Which is different again from how you’d design it for a kiosk or a constrained interface. The medium often shapes the message, whether we want it to or not. Length, hierarchy, emphasis, even tone all shift based on where something is going to appear.

So while we like to talk about universal content, I’m not convinced most organizations actually have that much of it.

And for a lot of companies, they don’t even need to solve for extreme multi surface complexity. Take a typical SaaS company. They might have a marketing site, a web app, a mobile app, maybe a desktop app. All of these are still primarily web centric experiences. The mobile and desktop apps diverge the most, but even then, they’re not radically different worlds.

In that context, do you really need a fully headless CMS to manage content across those surfaces? Sometimes the answer is yes. Often, I’m less sure.

I think the headless CMS vendors are running into this tension in practice. Decoupling sounds clean and elegant. But editors don’t experience content in the abstract. They experience it as something that appears somewhere, for someone, in a particular shape.

When you remove presentation entirely, you also remove the feedback loop that helps people understand whether what they’re creating makes sense.

Which might explain why so many headless CMSes are now trying to reintroduce that loop. Live previews. Visual editors. Embedded rendering. Ways to see content in context while you’re working on it.

In other words, finding ways to bring the presentation layer back into the editing experience, without fully giving up the architectural benefits of headless.

As I was working through these systems, I kept thinking about CMSes that offer a more hybrid model. Systems that can handle both content and presentation together, but don’t force you to couple them if you don’t want to. You can go fully decoupled. You can go fully integrated. Or you can sit somewhere in between.

For many marketing teams, that flexibility feels genuinely valuable. Not because it’s theoretically pure, but because it maps more closely to how teams actually work. Designers and editors often want to think in terms of pages and layouts. Developers want structure and APIs. Both can coexist, if the system allows for it.

The usual counterargument is scale, performance, and operational complexity. Hybrid systems are often not fully managed platforms. You need to care about hosting, caching, upgrades, and infrastructure. Or you need to partner with someone who does.

Meanwhile, fully managed headless vendors handle all of that for you. They control the CMS and the platform it runs on. Their systems are tuned for their specific use cases. And that’s real value.

But that also means that some of the tradeoffs we attribute to a CMS are actually platform level decisions. Performance. Scalability. Reliability. Those are not inherent properties of content models or editors. They’re properties of how the system is deployed, operated, and maintained.

Seen through that lens, it makes sense that headless CMS vendors are evolving in the direction they are. They’re responding to what users are asking for. A way to think about content in context. A way to see what they’re making. A way to reduce the cognitive gap between editing and outcome.

None of this feels like a failure of the headless model. I actually really like the headless model (just maybe not for the reasons it’s normally marketed for). It feels more like an adjustment. A recognition that while the idea of fully decoupled content is appealing, the reality of most content work is messier, more contextual, and more human.

I don’t think there’s a single right answer here. There are absolutely cases where headless is the right choice. There are cases where it’s overkill. There are cases where a hybrid approach unlocks the best of both worlds.

What I came away with most strongly wasn’t a verdict, but a pattern. A noticeable convergence. A lot of different systems, starting from different philosophies, all inching toward the same question.

How do we give people the benefits of structured, flexible content, without taking away their ability to understand what they’re actually creating?

I don’t think we’re done answering that yet, as an industry.

1. Yes, there ARE content-as-API shops, I just haven’t found them to be as common as many claim them to be. ↩︎

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.

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 box¹, 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. ↩︎

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

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.

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.

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.