When “basic changes” become bottlenecks, it’s the system not the people that needs attention.

There’s a familiar tension in many organisations. Marketing teams, driven by market opportunities and agility, need to make frequent content updates to their digital platforms. They see these as "basic changes" a quick swap of a hero image, an update to a CTA, or a new landing page for a campaign. Yet, often, these seemingly small requests get caught in a web of tickets, backlogs, and approvals, leaving Marketing feeling blocked by Engineering.

It’s easy to frame this as Marketing versus Dev, a conflict of priorities or understanding. But that’s a unproductive framing, and an inaccurate diagnosis. The truth is far more nuanced. This isn’t a battle of wills; it's a workflow problem, a consequence of systems that haven't evolved to meet modern digital demands. Both Marketing and Engineering share a common goal: to deliver impactful customer experiences at speed, knowing our digital platforms remain robust, performant, and perfectly aligned with our brand and technical standards. The blockage isn't people; it's the system.

Why "Basic Changes" Aren't Always Basic

To Engineering, a "basic change" often carries hidden risks that Marketing isn't always privy to. When content is not properly modelled, permissions are blunt, and guardrails are absent, every seemingly innocuous tweak becomes a potential minefield.

Consider the perceived simplicity of updating a hero image or changing a navigation label

• Layout Fragility: A headline that’s five characters too long might break a responsive grid on mobile, requiring careful CSS adjustments.
• Performance Roulette: An unoptimised large image from a marketing team could drastically slow page load times, impact user experience and Core Web Vitals, and cost money.
• Silent SEO Regression: A simple URL slug alteration without a corresponding 301 redirect could erase months of accumulated search authority.
• Responsive Unpredictability: Content might look perfect on a large desktop monitor, but collapse into an unreadable mess on smaller screens without intrinsic sizing guardrails in components.
• Accessibility Drift: Missing alt-text for new images or low-contrast text choices can expose the brand to compliance risks.

This common, reactive workflow, prevalent in many organisations, often forces Engineering to serve as the gatekeeper, not out of malice but out of necessity to protect the brand and technical integrity.

Reimagining the Workflow: From Bottleneck to Flow

The reactive workflow often looks like this:

1. Ticket Creation (The Guess): Marketing creates a ticket for a content change, often with static mockups.
2. The Backlog Wait: The ticket waits in a backlog, competing with feature work for developer time (3-10 days).
3. Context Switching: A developer picks it up, spins up their environment, and hardcodes the change.
4. Staging Push: The change is pushed to UAT/Staging for Marketing review.
5. The "Visual Disconnect" Loop: Marketing spots issues (e.g., poor mobile wrapping) and bounces the ticket back to Dev.
6. The QA Tax: Automated tests run, even for text changes, because code was touched.
7. Release Train: The change waits for a scheduled deployment window.
8. Live: The update goes live, potentially weeks after the market opportunity.

This is not sustainable. The solution lies in building a system where "basic changes" truly are basic for Marketing, without introducing undue risk for Engineering. This starts with content modelling.

Content Modelling: The Foundation of Flexible Content

Content modelling enables teams to create a flexible content foundation, helping them achieve more ambitious goals at scale. It's about breaking content down into reusable, structured components rather than treating it as one monolithic blob. For instance, instead of a "homepage" page type with a giant rich text editor, you define specific content types like:

• Hero: (Title, Subtitle, CTA Text, CTA URL, Image/Video Asset, Alt Text, Background Colour/Gradient)
• Product Feature Block: (Image, Headline, Description, Link)
• Promotion Banner: (Headline, Body Text, CTA, Start Date, End Date)
• CTA Module: (Button Text, Target URL, Style Variant)

When content is modelled this way, the CMS becomes a structured environment where Marketing can assemble, edit, and publish content components with confidence, knowing the underlying structure is sound.

Guardrails: Enabling Safe Self-Serve

Content modelling sets the stage, but guardrails are what truly empower safe self-serve editing without breaking layouts or compromising brand and performance. These are not restrictions; they are the engineering elegance that enables creative freedom within defined boundaries.

• Component Library + Design Tokens: Ensures every editable element adheres to brand guidelines. Marketing chooses from approved button styles (e.g., Primary, Secondary, Ghost) rather than defining colours in a WYSIWYG, preventing one-off CSS and maintaining consistency.
• Constrained Layouts: Instead of free-form drag-and-drop that can break responsive designs, Marketing arranges pre-defined modules within a grid system or "slots." They can swap "Social Proof" above "Features" on a product page, but the overall page structure remains intact.
• Structured Fields: For critical elements, Marketing interacts with dedicated fields. For a "Hero" component, they enter text into "Headline" and "Subtitle" fields, upload an asset to "Image/Video Asset," and define a link in "CTA URL," ensuring data integrity and correct rendering.
• Validation Rules: The CMS enforces field-level rules. A "Headline" field might have a character limit to prevent layout breaks; an "Image" field might require alt-text to be entered before publishing to catch accessibility issues early.
• Previews (Staging + Device Breakpoints): A true preview environment that accurately reflects how content will appear on various devices (desktop, tablet, mobile) and channels before publishing. Marketing can see how that new hero image will wrap on a small screen, reducing visual disconnects and rework.
• Versioning + Rollback: The ability to instantly revert to a previous version of content. If a change has unintended consequences (e.g., a critical tracking pixel stops firing), Marketing can quickly roll back without Engineering intervention, making self-serve truly safe.
• Performance Budgets: Automated checks ensure content additions don't degrade site performance. If an image is uploaded that exceeds a defined file size budget, the system alerts the user or automatically optimises it. This prevents a single large asset from tanking Core Web Vitals.

These guardrails shift the responsibility from Engineering constantly fixing issues to Engineering enabling Marketing to make changes safely. They transform "Marketing is blocked by dev" into "Marketing is empowered by dev."

A Proposed Operating Model: Shared Ownership, Clear Boundaries

The ideal operating model isn't "Marketing owns content" or "Dev owns code"; it's a collaborative ecosystem:

• Engineering owns the components: They build the robust, performant, accessible, and responsive building blocks and define the guardrails.
• Marketing owns the content within those components: They assemble, edit, and publish using the defined content types and structured fields, confident they won't break the underlying structure.
• Product Owners/Website Managers own the workflow and governance, ensuring the content model evolves, and processes are clear.

This doesn't mean Engineering never touches content; it means their involvement shifts to building more sophisticated components, optimising performance, and evolving the platform, rather than being a ticket machine for repetitive content tweaks.

What to do this week:

• Map a "Crisis" Workflow: Pick one "basic change" that frequently gets stuck (e.g., updating a sitewide alert banner) and map its ideal, guardrail-enabled workflow.
• Audit a Single Content Type: Choose one common content type (e.g., a "Hero" component or a "Promotion Banner") and identify all its fields, required validations, and how it maps to your design system.
• Review Preview Capabilities: Assess your current CMS preview. Does it accurately reflect live content on all devices? If not, identify the gaps.
• Initiate a "Shared Goals" Workshop: Bring Marketing, Engineering, and Product together to align on the shared win statement and identify the top 3 pain points for both sides regarding content updates.