Authors Always Win Architecture Debates

by Karol Mejia

I've been in maybe a hundred architecture-debate meetings over the years. They all look the same. Engineers argue for the technically elegant option, product argues for the cheapest one, and marketing wants whatever ships in time for Q4. Then somebody at the table says "but the authors are used to the current way." That argument rarely wins the vote, and it usually decides the outcome anyway, once the platform is live.

Why the author argument keeps coming back

The author objection sounds, in the meeting, like a soft concern. "Change management." "Training cost." "Let's just communicate the new workflow well." The team votes for the technically better option and moves on.

Then the platform launches. The authors don't migrate. They keep filing tickets against the old system. The new system's content count flatlines. The CMO asks why traffic to the new site is half what was projected. The technical-elegance victory becomes a six-month rollback project.

This happens because the author is the only person in the system who creates the content. Engineering can build the most elegant headless CMS in the world. If the marketing team can't publish into it, the platform delivers zero value. The author's leverage is total. They're a single point of failure for the entire content pipeline, and the org chart doesn't reflect that.

What "author-oriented" actually means

A fancy WYSIWYG doesn't cover it. Author-oriented means three concrete things:

• The author's mental model matches the platform's structure. When the author thinks "I'm editing the hero block," the platform also calls it the hero block, in the same place, with the same affordances. Mismatch here is invisible to engineers and corrosive for authors.
• The author can finish a piece of work without engineering help. If publishing a page requires a developer to deploy a new component, the authors will route around the CMS via PDFs and one-offs. Always.
• The platform fails gracefully when the author makes a mistake. Extra row in a block? Render the first row, ignore the rest. Wrong image format? Convert it or skip it. The platform protects the author from their own typos.

What this means for the next debate

If you're in an architecture meeting and the author concern surfaces, take it seriously. In production, a platform the authors won't use delivers no business value, regardless of how elegant the technical choice was.

You can have the most defensible technical architecture in the company. If the marketing team is filing tickets against your platform two months in, you're going to lose anyway. Build for the author first. The choice is whether they win during the design phase or after the rollback.