Why Does Your Content Team Keep Asking a Developer for Small Changes?

The request arrives as a ticket: change three words in a headline. It waits six days behind a payment bug. Someone picks it up, works out which component renders that page, ships it on a Thursday, and by then the campaign the headline was written for has finished. Nobody did anything wrong. The system turned a two-minute job into a two-week one, and it will do it again next month.

When a content team keeps filing tickets like this, the instinct is to blame the CMS and start shopping. Sometimes that is correct. More often the platform is fine and the real constraint is one of four things underneath it, only one of which a migration would touch. CMS editor autonomy is not a feature you buy. It is a property of four separate decisions, each of which was made for a reasonable-sounding reason at the time.

The four are: copy that lives in code rather than in content, fields that were never modelled so a change has nowhere to go, an approval habit built out of fear rather than risk, and a preview nobody believes. Every one of them produces the same ticket. Every one of them needs a different fix, and applying the wrong fix is how teams end up migrating twice in three years.

So work out which one you have before you do anything else. The diagnosis takes an afternoon, and it decides whether you are buying software, writing a content model, deleting an approval step, or repairing an environment.

Start with one diagnostic question

Take the last ten content requests your team filed. For each one, ask a single question: what physically stopped the editor from doing it themselves?

Not why they asked. What stopped them. The answers cluster quickly. There was no field for it. There was a field, but the result could not be checked before it went live. They could have done it and were not allowed to. Or the words were never in the CMS at all, because they sit in a template. Ten tickets is usually enough to see which answer dominates, and the dominant one is the only one worth fixing first.

This matters because the four causes get blamed on each other constantly. Editors say the CMS is limited when what they mean is that they are not trusted. Developers say editors keep breaking pages when what they mean is that the preview is unreliable. The ticket queue is where those two misunderstandings meet, and neither side can see the whole shape of it from where they sit. It is also why what a content workspace should do the day after launch is a more useful question at procurement time than any feature comparison.

The four causes of poor CMS editor autonomy

They look identical from the outside and they cost very different amounts to remove. Two are engineering work. One is a content-modelling exercise. One is a conversation that costs nothing and gets put off for years.

Cause one: the words are in the code

This is the literal version of the problem. A heading, a button label, a legal footnote or a whole section is written into a template or component, so changing it means changing code, running a build and deploying. There is no field to edit because there is no content record. The page renders text that only exists in the repository.

How it happens, quite reasonably

Nobody sets out to hard-code a headline. It happens because launch was in nine days and modelling a field for the homepage hero felt like ceremony when the copy was already signed off. It happens because a section was added after the content model was agreed and there was no time to reopen it. It happens most of all on the pages that were considered final: the homepage, the pricing page, the footer. Those are, of course, the pages that change most.

The fix

Audit by page type rather than by page, and start with the type that generated the most tickets. For each one, list every string a reasonable person might want to change in the next year, then decide deliberately which ones stay in code. Some should: an error message, a form validation string, an accessibility label. Move the rest into content, as typed fields rather than one large HTML blob, for the reasons set out in why you should stop storing content as a wall of HTML.

Where those fields physically live is a separate decision, and a real one: files in the repository or records behind an API, which we have compared in git-backed or api-backed. Either can give editors autonomy provided something sits between them and the raw storage. A workspace like Acrosite takes the repository route: editors work in structured forms, the workspace generates the required files, commits them to GitHub and triggers the configured deployment. The editor never sees a branch. The audit trail exists anyway.

Cause two: the field does not exist

Here the CMS is working exactly as designed. The editor can change the title and the body, and that is all the model ever described. So when the request is “add a short summary above the fold” or “put a second call to action at the end”, there is genuinely nowhere to put it, and the only route is a developer adding a field, a migration and a template change.

Under-modelling is more common than over-modelling and much harder to spot, because a missing field never appears in an interface to be noticed. The symptom shows up sideways: editors pasting styled markup into a rich-text box to fake a layout the model does not support, which then breaks the first time the design changes.

A page type that looks simple usually needs more than two fields once you watch it for a quarter. The list below is not a template. It is the set of things that keep turning up in tickets.

• A short summary that is not the meta description. One is for the page, one is for search results, and conflating them means changing both when you meant to change one.
• An optional secondary action, with its own label and destination. Two buttons is a layout the design already supports. The content model rarely does.
• Alternative text the editor writes. Alt text describes an image in context, so it belongs to whoever chose the image, not to whoever built the component.
• A visibility switch per section. Editors need to hide a block for a fortnight without deleting the content and rebuilding it from memory afterwards.
• A published date and a last-reviewed date, kept apart. They answer different questions, and merging them destroys the only signal you have about which pages have gone stale.

Modelling well also pays off at the least convenient moment. Content stored as typed fields can be re-rendered into a new design; content stored as pasted markup has to be rebuilt by hand, page by page, which is one of the quieter reasons organic traffic falls after a redesign: pages get quietly simplified during the rebuild because nobody has time to reconstruct them faithfully.

Cause three: approval built out of fear

This one is not a software problem, and no migration has ever fixed it. The editor can make the change. The editor is not allowed to make the change, or believes they are not, which produces identical behaviour and is considerably harder to disprove.

It forms the same way every time. Something went out wrong two years ago. A rule was made that everything goes through one person. That person left, the rule stayed, and now a blog typo waits behind a legal review queue that was designed for contract wording. Nobody defends the rule when asked directly. Nobody removes it either, because removing a control feels like accepting a risk, while keeping it feels like nothing at all.

The fix is to sort changes by what an error would actually cost. Pricing, legal wording, claims about what a product does, anything regulated, and anything that changes a URL: those get review, and the reviewer gets named. A typo in a two-year-old article does not. Our parent company has written about how to structure that step in the reviewer’s pass, and the principle worth stealing is that a review with no stated question is a delay wearing a badge.

Blanket approval carries a second-order cost people miss, too. When every change is slow, editors batch them, and a batch of eleven mixed edits is genuinely harder to review than eleven single ones. The control designed to increase care ends up reducing it.

Cause four: a preview nobody trusts

The quietest of the four, and the one most often mistaken for timidity. An editor who cannot see what a change will look like will not publish it. They will ask someone to check, and asking someone to check is a developer ticket wearing different clothes.

The tells are consistent. Staging holds content from eighteen months ago, so nothing resembles the real page. Preview renders through a different path than production, so the spacing is wrong and everyone learns to discount what they see. Draft links point at URLs that do not resolve. Images fail to load because the media library is not mirrored. Each of these is individually minor, and together they teach an editor that the only reliable way to see a page is to publish it, which is exactly the habit you were trying to prevent.

A preview worth having renders through the same code path as production, with realistic content, at a URL the editor can open on a phone and send to a colleague. Per-branch or per-draft deployments make that ordinary rather than special, and keeping them working is part of website maintenance rather than a one-off setup task. Where drafts live, and what stops them moving, is the same question asked from the other end: our parent company has covered it in where drafts live and what stops them.

The order to fix them in

Cheapest first, and front-load whatever the editors will feel. Momentum matters here, because this kind of programme dies of tedium rather than disagreement.

1. Run the ten-ticket audit. Half a day, one spreadsheet, one column: what physically stopped this. Do not skip it because you believe you already know the answer.
2. Delete the approval steps that protect nothing. This costs no engineering time at all and changes daily life immediately. Name the reviewer for the changes that genuinely need one, and remove the rest in writing so nobody has to guess.
3. Repair the preview. Realistic content, the production rendering path, a shareable URL. An editor who can see the result will attempt far more without asking first.
4. Model the missing fields on the two page types that change most. Not all of them. The two that generated the tickets. Add the constraints as you go rather than promising to add them later.
5. Move hard-coded copy into content, page type by page type. Start with whatever changes most often, which is almost never the page anyone nominates first.

Only if you finish that list and the tickets keep arriving is the platform genuinely the constraint. At that point the evaluation is a real one, and the twelve questions that separate a CMS shortlist will be far more useful than they would have been at the start, because you now know precisely which constraint you are buying your way out of.

When the developer should stay in the loop

Here is the concession, and it is not a small one. Zero developer involvement is the wrong target, and teams that chase it build content models so permissive that editors can break the site in ways nobody thought to prevent.

Some changes should always route through engineering: anything that changes a URL, anything that touches redirects, structured data tied to page templates, pricing rendered from billing logic, and any field consumed by something other than the website. Those are not bureaucracy. They carry consequences an editor cannot see from the editing screen, which is the actual test worth applying.

The dividing line we use is short enough to say in a meeting: editors own the words and the arrangement of approved blocks, engineering owns structure, routing and anything with a downstream consumer. Draw that line once, write it down, and the argument stops being about individual tickets. It becomes a question of which side of the line a change falls on, which is a much shorter conversation and one that content and organic growth work depends on more than most teams expect.

Autonomy is not the absence of review. It is knowing, before you start typing, whether this particular change needs one.

If you want a test for whether the line sits in the right place, watch what happens the next time something urgent needs saying on the homepage. If the answer involves a deployment, the line is wrong, and the remedy is a build decision rather than a training problem. If you would like a second opinion on which of the four causes you are actually living with, send us your last ten tickets and what each one was waiting on.