Pinning the Blame: 

Platform vs Process

‍When a CMS feels hard to use, the instinct is to blame the platform. The interface is clunky. The fields don't make sense. Publishing takes too many steps. These frustrations are real, but they are almost never purely caused by the software. They are the result of the decisions made before and after implementation: how content was modeled, how roles were assigned, how governance was (or wasn't) established, and how the organization expected a system to adapt to work patterns it was never configured to support.

Signals of Friction

CMS friction is diagnostic. It points to structural problems that existed before implementation and survived it.

The most common culprits are familiar to anyone who has audited a mature digital environment. Content types that were built to mirror internal departments rather than serve actual publishing workflows. Metadata fields that no one agreed on, so no one fills in consistently. Editorial roles that were assigned at launch and never revisited, even as teams reorganized. Approval chains inherited from print processes that don't translate to digital cadence.

None of these are technology failures. They are governance failures. And when they go unaddressed, they compound. Fields get abandoned. Workarounds get institutionalized. The CMS becomes a system that people work around rather than within, and the workarounds get mistaken for the process.

The Content Model Problem

Most organizations underestimate how much the content model shapes the day-to-day experience of working in a CMS. A well-designed content model reduces editorial decisions at the point of publishing. A poorly designed one multiplies them.

When content types are defined too broadly, editors face ambiguity on every entry: which type does this piece belong to? When types are defined too narrowly, the model can't accommodate new content needs without developer intervention. When fields are added reactively, over months and years, without a governing framework, the entry form becomes a sprawl that no one fully understands.

The consequence is friction that feels like a usability problem but is actually a modeling problem. The CMS is doing exactly what it was configured to do. The configuration just wasn't designed with the editorial team's actual workflow in mind.

Role Clarity

Equally disruptive is the absence of clear content ownership. Who can publish? Who must review? Who is accountable when something goes wrong? In many organizations, these questions have informal answers that shift depending on the situation. The CMS, however, requires explicit answers. Permissions must be assigned. Workflows must be configured. When the informal understanding doesn't match the system configuration, friction is the result.

This is compounded in organizations where content responsibility is distributed across multiple departments, each with different risk tolerances, review cadences, and definitions of "ready to publish." The CMS cannot resolve those organizational disagreements. It can only surface them, repeatedly, at the worst possible moment.

The Adoption Gap

Even well-configured systems fail when the organization wasn't prepared to use them. Training that covered features but not workflows. Launch timelines that didn't allow for iterative adjustment. Change management that was treated as a checkbox rather than a sustained process.

The result is a system that works correctly but isn't used correctly. Editors develop compensating behaviors. Content operations fragment. The CMS accumulates debt not in its codebase but in its institutional usage patterns.

This is the adoption gap, and it is one of the most underestimated sources of CMS friction. The platform is functional. The organization just never fully learned how to operate it.

What Resolution Requires

Addressing CMS friction requires diagnosing it accurately. A content audit that examines what exists and who owns it. A workflow audit that maps actual publishing behavior against what the system expects. A governance review that identifies where ownership is ambiguous and where accountability gaps exist.

From there, resolution is sequential. Structural problems (content modeling, taxonomy, permissions architecture) must be addressed before workflow problems. Workflow problems must be addressed before training. Training must be reinforced before adoption can be measured.

This is not a simple platform migration question, but rather it is an operating model question. The right CMS cannot compensate for an undefined content strategy. The wrong CMS configuration will create friction regardless of the platform's underlying capability.

The experience of working in a CMS is a reflection of how well an organization has defined its content operations. When that experience is hard, the most important question to ask isn't which platform to switch to.  The friction is actually telling you about the system beneath it.

‍