The most profound technologies are those that disappear, weaving themselves into the fabric of everyday life until they are indistinguishable from it. When technology is implemented correctly, you do not notice it; it simply works.
So why are we still fighting the tools?
Every modern company relies on its website to communicate with customers. Every day, people sit down at their desks with a clear goal: publish an article, launch a campaign, or share a story with their audience. They are there to communicate.
Yet the moment they open their tools, the communication stops and the wrestling begins.
Instead of an invisible tool that gets out of the way, they encounter friction at every turn. They are forced to stop thinking about what they want to communicate and start thinking about how the system wants them to work.
They have to adapt how they express an idea to match how a platform was engineered.
In my daily work, I see a constant tug-of-war between code architecture and actual users. And this is where the fundamental problem lies.
We call these platforms “Content Management Systems”—or CMSs. But look at what that name actually tells you. They were created to manage content. They were engineered to store data, handle structures, and serve database rows. It has little to do with whether it is easy or difficult for a human being to express an idea.
Whether an editor has a good experience is completely separate from the underlying system—it has fulfilled its architectural purpose the moment the database record was saved.
Governance, workflows, and structured content matter to a business. But when a platform manages all of that while making daily publishing a nightmare, who is the tool really built for?
If the person creating the content cannot create and adapt what is needed, the system has failed at its job.
The system becomes so rigid that actual progress grinds to a halt.
Developers aren’t the problem here. They work within the system they were given, and developers respect limits. But when a platform’s architecture makes flexibility “impossible,” they can’t magically invent capabilities that were never part of its design.
So how does the industry handle this friction? By locking the system down.
Instead of respecting communication as something people across an organization need to do, employees are thrown into editor roles without any background in design, web, or communication. To compensate for this mismatch, system creators add rigid guardrails to the interface and call it “governance.”
Locking down doesn’t fix a broken workflow—it just traps the editor in a box built by people who have never had to publish anything under pressure in their lives.
But when you actually sit in the editor’s chair and try to communicate, the truth is plain to see:
The emperor is completely naked.