Most publishers don't have a content problem. They have a team design problem.

And the difference costs them more than they think.

I've had a version of this conversation more times than I can count.

A publisher reaches out. They're producing content (articles, listicles, evergreen pieces) but something isn't clicking. Traffic is flat. Output feels inconsistent. Writers are burning out. Editors are stuck firefighting. And the instinct is always the same:

"We need to hire more people."

So they do. And six weeks later, the problem is worse.

More writers means more coordination overhead. More overhead means the editor who was already stretched is now a full-time traffic cop. Quality dips. Deadlines slip. The operation gets bigger but slower.

This is the moment most publishers realize they don't actually have a content problem.

They have a team design problem.

The way most editorial teams get built is backwards.

It usually goes like this: someone decides they need X articles per day, backs into a headcount number, posts job listings, and calls it a team.

What they've built isn't a team. It's a roster.

A roster is a group of people doing similar tasks in parallel. A team is a system where each role reinforces the others, where a writer's output feeds directly into an editor's workflow, which feeds into a QA layer, which feeds into distribution. Where the bottleneck is visible before it becomes a crisis.

The difference isn't philosophical. It shows up in your output per seat, your revision rate, your time-to-publish, and ultimately in your ability to scale without chaos.

Hiring writers doesn't build capacity. Designing the right operating structure does.

The numbers that don't lie

Here's what I see consistently across editorial operations we've worked with:

60–70% of editorial bottlenecks sit in QA and editorial review, not in content creation.

3× is roughly how much longer publishing takes when there's no defined handoff between writing and editing.

40% of first-draft revisions are avoidable with a proper brief-to-writer workflow.

None of these are content problems. They're structural problems dressed up as content problems.

What a well-designed editorial team actually looks like

There's a common misconception that a 'senior editor' fixes everything. It doesn't. Putting one strong editor on top of a poorly designed team just creates a smarter bottleneck.

The teams that actually scale, the ones producing 50, 100, 200 pieces per month without losing consistency, share a few structural traits:

Brief ownership is non-negotiable. Every article starts with a brief that defines the angle, keyword intent, tone, length, and audience. Writers who brief themselves produce inconsistent output. Writers who receive clear briefs produce consistent output. This sounds obvious. Almost no one does it right.

QA is a role, not a step. When quality control is everyone's responsibility, it's no one's responsibility. The best operations have a defined QA layer that runs parallel to production, catching issues before they reach the editor, not after.

The editor's job is strategy, not survival. If your editor spends more than 30% of their time on line edits, your team is under-leveraged. The editorial lead should be setting direction, calibrating voice, and spotting patterns, not fixing grammar.

Volume is a lagging indicator. The teams that produce the most aren't the ones chasing output. They're the ones who've made each step of the process predictable enough that speed is a natural byproduct.

Why 'just hire more writers' keeps failing

Adding writers to a broken workflow is like adding lanes to a highway with a broken on-ramp. The congestion doesn't move, it just starts earlier.

I've seen publishers go from 2 writers to 6 and watch their per-article turnaround time increase. Not because the writers were bad. Because the system wasn't designed to absorb the volume.

The failure mode is always the same: the editor becomes the single point of failure. Every decision routes through them. Every question lands in their inbox. Every draft waits in their queue. And at some point, usually around writer #4, the whole operation grinds to a slow crawl dressed up as productivity.

The real cost isn't the salary of the extra writers. It's the compounding drag on everyone else's output.

What the fix actually looks like

It's not about hiring fewer people. It's about designing the team before you hire anyone.

The questions that should come before headcount:

What's the actual bottleneck today? Is it ideas, drafts, edits, or publishing? Most teams can't answer this precisely. That's usually the first sign of a design problem.

Where does quality actually break down? In the brief? In the draft? In the edit? The answer determines which role you need next, and it's rarely 'more writers.'

What does a predictable workflow look like end-to-end? Brief → Draft → Edit → QA → Publish → Reporting. If any step in that chain is undocumented or owner-less, you have a structural gap. Fill the gap before adding headcount.

What does 'done' mean for each role? Vague expectations create revision loops. Clear definitions of done, per role, per format, eliminate most of the back-and-forth that kills editorial velocity.

Design that first. Then hire into it.

The insight that changes everything

Publishers are obsessed with content volume because volume feels like progress. More articles. More coverage. More output. But volume without structure doesn't build a media operation, it builds a chaos machine that burns through writers and editors until someone finally hits the wall.

The publishers who've scaled consistently, the ones running 100+ articles per month with lean teams, didn't get there by hiring more. They got there by designing better.

They treated their editorial team like a system: with defined inputs, clear handoffs, measurable outputs, and roles that reinforce each other instead of competing for the same limited resource of editorial attention.

If your content operation isn't scaling the way you want, I'd bet the answer isn't in the next hire. It's in how the team is designed.

Start there.

---

Milan Lab builds and operates editorial, content, and software teams for digital publishers and media companies. See how we work.