Production

Draft folder structure tells you who owns what

By Holt

Folder hierarchy is an ownership map

You already know your CMS tracks publish status. What you probably haven't formalized is where draft content lives before it enters the CMS—and that choice determines who feels responsible for finishing it.

If every contributor dumps Word docs into a shared "Blog Drafts" folder, you've created a tragedy of the commons. No one owns the mess. If each author gets a subfolder named after them, accountability is suddenly legible: Sarah's folder has eleven unfinished drafts, Tom's has two. The structure makes the problem visible.

This isn't about blame. It's about making work findable and ensuring handoffs don't vanish into vague Slack promises.

Name folders by role, not just by person

Person-named folders work until someone leaves or you hire a second editor. Then you're renaming folders mid-project or creating "Editor 2" folders like a database designed by someone who's never heard of normalization.

Instead, structure by stage and role:

  • 01_Pitches/
  • 02_Assigned/AuthorName/
  • 03_FirstDraft/
  • 04_InEdit/
  • 05_ReadyToProduce/
  • 06_Scheduled/

Now the folder position tells you the content's state. You can glance at 03_FirstDraft/ and see what's stuck. You can audit 05_ReadyToProduce/ every Monday and know exactly what should be uploaded to the CMS.

When someone new joins, they inherit the system without needing a manual.

Enforce file-naming that includes the owner

Folder structure gets you halfway. File names close the loop.

A file named blog-post-draft.docx is orphaned the moment it's saved. A file named 2025-01-15_holt_draft-folder-structure.docx tells you the target date, the author, and enough title context to distinguish it from every other draft in the folder.

You can sort by name and see everything Holt's responsible for. You can grep your archive and find every draft from January. You can avoid the soul-crushing experience of opening fourteen files named final_FINAL_v3.docx to find the one the client actually approved.

This is the same discipline that makes redirect rules belong in version control—if the artifact doesn't declare its context, you'll lose that context the moment you stop thinking about it.

Avoid "Archive" folders

The moment you create an Archive/ folder, it becomes a junk drawer. Everything goes in, nothing comes out, and six months later you're excavating it because someone wants to "refresh that post from last spring."

Instead, use dated folders within each stage:

  • 03_FirstDraft/2025-01/
  • 03_FirstDraft/2025-02/

Old content ages out naturally. You can delete 2025-01/ in March without worrying you're trashing something important, because anything important would have moved to 05_ReadyToProduce/ weeks ago.

This also prevents "Archive" from becoming a passive-aggressive dumping ground for content someone doesn't want to admit is dead.

Test the structure by simulating a handoff

Once you've built your folder tree, walk through a realistic scenario: Author drafts, editor revises, producer uploads to CMS, editor schedules. At each step, ask: "Where does this file go next, and will the next person know to look there?"

If the answer is "I'll Slack them the link," your structure has failed. Handoffs that require manual notification don't scale and don't survive turnover.

The folder layout should make the next step obvious. When a file lands in 04_InEdit/, the editor should check that folder as part of their daily routine—not because you trained them, but because that's where edited content lives.

This is the filesystem equivalent of setting your CMS default sort before anyone publishes: decide the logic before the chaos starts, then let the system enforce it.

Shared drives require shared conventions

None of this works if three people use Google Drive, two use Dropbox, and one insists on emailing attachments. Pick one shared location and make it non-negotiable.

Then document the folder structure in a README.txt at the root level. Not in a wiki. Not in a Notion doc. Right there, in the folder, where someone opening it for the first time will trip over it.

Include:

  • What each stage folder means
  • File-naming convention (with an example)
  • Who's responsible for moving files between stages
  • What to do with content that's killed or postponed

You're not writing a manual. You're writing the minimum viable context so the system survives your absence.

The structure is the workflow

If your draft workflow lives in someone's head, it dies when they take vacation. If it lives in folder names and file conventions, it runs without you.

This isn't about being controlling. It's about making sure good work doesn't get lost because no one remembered where Sarah saved that draft three weeks ago.

← All posts