From Unwritten Rules to SOP Without Slowing Teams Down

Every content team has rules they don’t write down.

They exist in comments, in Slack messages, in the heads of a few senior people who know how things “usually” work. New hires learn them by getting things wrong. Contractors guess. Editors correct quietly. Over time, a shared understanding forms, even if no one can quite articulate it.

This system can function surprisingly well. Until it doesn’t.

When teams grow, change, or simply get tired, unwritten rules stop being efficient and start becoming a liability.

The problem with institutional memory

Unwritten rules rely on continuity. The same people. The same tools. The same volume of work.

Most teams don’t have that luxury.

Someone leaves. Someone new joins. Output increases. Deadlines tighten. Suddenly, the person who “just knows” how to handle edge cases isn’t in the room anymore. The rules haven’t changed, but access to them has.

I’ve worked with teams where the quality gap between senior and junior contributors wasn’t skill. It was context. Senior writers knew which claims would trigger review. Junior writers didn’t. Senior editors knew which templates were fragile. Junior editors learned after something broke.

The work still got done, but it took longer, required more correction, and created quiet frustration on all sides.

That’s the moment when teams start talking about SOPs.

Why SOPs get a bad reputation

Standard operating procedures are often introduced after something goes wrong. A compliance issue. A missed deadline. A public correction. In that context, SOPs feel like punishment.

They also tend to arrive fully formed and overly ambitious. Long documents. Rigid steps. Language borrowed from process frameworks instead of real workflows.

People read them once, bookmark them, and then go back to doing what they were doing before. The rules remain unwritten, just with more paperwork attached.

That’s not a failure of discipline. It’s a failure of design.

What effective SOPs actually do

The best SOPs I’ve seen don’t try to capture everything. They focus on the decisions that create the most friction or risk when they’re made inconsistently.

They answer questions like:

When does a claim need support, and what counts as support?
When does something require review, and by whom?
What does “done” actually mean for this type of content?

They don’t explain how to write. They explain how to avoid predictable mistakes.

When SOPs work, they don’t feel like rules. They feel like shortcuts.

Translating unwritten rules into usable guidance

The mistake teams make is trying to formalize behavior before they understand it.

A better approach is observational.

Start by paying attention to where edits cluster. What changes keep coming up in review? What comments get repeated? Where do projects slow down unexpectedly?

Those moments are where unwritten rules live.

I’ve helped teams turn that friction into guidance by doing very simple things. Capturing examples of approved language. Writing short notes about why certain claims were changed. Creating checklists that mirror how editors already think, rather than how process documents usually read.

None of this requires a massive rollout. It requires noticing patterns and naming them.

Why SOPs don’t have to slow teams down

Speed suffers when people have to guess.

Every time a writer hesitates because they’re unsure whether something is allowed, momentum drops. Every time an editor has to explain the same correction again, time gets wasted. Every time a piece goes back and forth because expectations weren’t clear, trust erodes.

SOPs reduce that guesswork. They move decisions earlier. They let people self-correct before review.

I’ve seen teams increase output after introducing SOPs, not because they worked harder, but because they spent less time undoing work.

Keeping SOPs lightweight and alive

The biggest risk with SOPs isn’t rigidity. It’s stagnation.

Processes that don’t evolve quietly become irrelevant. Teams work around them. New exceptions pile up. Eventually, the SOP becomes a historical document rather than a practical one.

The teams that avoid this treat SOPs as living notes, not rulebooks. They update them when patterns change. They remove steps that no longer add value. They keep them close to the work, not buried in a folder no one opens.

Most importantly, they don’t confuse documentation with enforcement. The goal is clarity, not control.

Where SOPs matter most

Not every part of content work needs formalization.

The places where SOPs earn their keep are usually predictable: regulated claims, disclosures, accessibility checks, publishing workflows, and maintenance routines. These are areas where inconsistency carries real cost.

When those rules are clear, teams have more freedom everywhere else.

The quiet shift that happens

When unwritten rules become shared language, something changes.

Writers ask better questions before drafting. Editors spend more time on substance and less on correction. Reviews feel collaborative instead of corrective. New contributors ramp faster. Senior contributors get time back.

The work doesn’t feel slower. It feels steadier.

And steadiness is often what teams are actually missing.

Previous
Previous

What a “Single Source of Truth” Really Requires Beyond a Wiki

Next
Next

The Trust Score: Auditing Your Marketing Copy for EEAT and Verifiable Claims