Nothing is wrong yet. Two articles went out with the wrong image. Somebody rewrote a piece that was already approved. A post has been “nearly ready” for three weeks and nobody can say who is holding it.
That is what a missing process looks like on a small team: not chaos, just a slow accumulation of things that had to be redone.
The instinct is to add a process, and the instinct is usually wrong about how much. A team of three does not need what a team of thirty needs, and a process copied from a larger organisation will be abandoned within a month, which leaves you worse off than having none.
This page is about the smallest thing that helps.
Why handoffs are the unit of cost
The arithmetic that matters, and you can do it on your own numbers in a minute.
Every stage in a process is a handoff, and every handoff is a moment where work stops and waits for a person. A process with three review stages, on ten posts a week, is thirty moments where something waits for somebody. Not thirty tasks. Thirty pauses, each of which can last as long as that person’s inbox is full.
Two consequences follow.
Adding a stage does not add its own duration; it multiplies by your volume. A review that takes ten minutes costs ten minutes and one queue, and the queue is the expensive part.
A stage nobody performs is worse than no stage. It creates an expectation that something was checked, and the person downstream relies on a check that did not happen.
So the design rule for a small team is: as few stages as will actually catch what you are getting wrong, and each stage owned by exactly one person.
The smallest workflow that works
Four states. Not four documents, four states an article can be in, and everyone knows which state everything is in.
1. Agreed. Somebody decided this article should exist, and what it is. The decision includes what it is about, who it is for, and what it needs to contain. Skipping this is why writers produce the wrong article, and it is the cheapest stage to get right.
2. Drafted. It exists. Written by one named person.
3. Approved. One named person has said it can go. One. Not a committee, not a round of comments, one decision by one person. This is the single change that unblocks most stuck workflows, and it deserves its own treatment.
4. Scheduled or published. It has a date, and someone knows what that date is.
That is it. If your team is two to five people, this covers you, and the failure modes below are what you add stages for, one at a time, when a specific failure keeps happening.
Who does what
Roles rather than job titles, and one person can hold several.
Someone decides what gets written. If nobody owns this, you write whatever occurs to you.
Someone writes it.
Someone approves it. One person, and the same person each time for a given kind of content.
Someone publishes it, meaning someone owns the calendar and knows what is going out when.
On a team of three, one person might hold three of those. That is fine, and it must be explicit anyway, because the failure is not that one person does two jobs, it is that nobody knows who does the second one.
What to write down
Almost nothing, and this is where most small-team processes go wrong. A forty-page style guide is a document nobody has opened.
Three things, each of which fits on one screen:
A brief format. What a writer needs before starting. If the wrong article keeps getting produced, this is the fix, and it is a workflow artefact rather than an editorial one.
A publish checklist. The things that are always checked before something goes live, derived from what you have actually got wrong. Not a generic list. Yours.
A named owner per stage. Four lines.
Everything else can live in habit until a specific failure proves it needs writing down. Write the rule after the second time it breaks, not in anticipation.
The visible state, and why it beats any tool
The one thing that has to be true regardless of what you use: anyone on the team can see, in under a minute, what every in-progress article’s state is and who is holding it.
That is the whole requirement. Whether it is satisfied by your CMS’s own statuses, a shared board, a spreadsheet or a channel is a smaller question than the category’s tooling market suggests, and this article names no tool for that reason.
The test is simple: ask someone on the team what is happening with a specific article. If they have to ask somebody else, your state is not visible, and every stall you have had traces back to that.
What breaks first on a small team
Four failures, in the order they usually appear.
Nobody knows whose turn it is. The commonest by a wide margin. Fixed by the four states and named owners, not by a tool.
The wrong article gets written. Fixed at the brief, not at review. Catching it at review means the work is already done.
Two people edit at once. Fixed by the states: only one state has an owner at a time.
Approval never happens. Either because approval is diffuse, or because the approver is a bottleneck. The first is a structural problem with one fix, and it is the most consequential change in this whole article.
Where the platform actually matters
The process is not the platform, and most of what is wrong with a small team’s publishing is not a platform problem. But two platform properties genuinely constrain what process is possible.
Can the least technical person publish unaided? If not, every publish is a handoff to a technical person, permanently, and no process design routes around that. It is worth establishing before it becomes the shape of your workflow: can a non-developer actually publish on this? is an hour and it answers it.
Does anything need a developer to change? If adding a content type or a field waits on someone else’s queue, your content model is effectively fixed, and a fixed model constrains what you can publish. Do you need a developer to keep this running? works through which tasks fall on which side of that line.
Those two constraints are worth knowing when you choose a platform, which is the argument this site’s platform pillar makes: how to choose a CMS without reading 165 vendor pages starts from who publishes and how often, precisely because the workflow outlives the platform choice.
What not to add
- A second approver. Two approvers is not more careful, it is slower and less accountable.
- A stage for something that has gone wrong once. Once is an incident, twice is a pattern.
- A tool before a process. A tool encodes a process, and encoding a process you have not agreed on produces a tool nobody uses.
- A style guide longer than a page, until you have a specific recurring problem it would solve.
- A meeting. Almost every editorial meeting on a small team is a substitute for visible state.
Reviewing it
Once a quarter, ask two questions: what went wrong, and which stage should have caught it?
Add a stage only when the answer is “none of them”, and remove a stage when the honest answer is that nobody has performed it in months. A process that grows without ever shrinking becomes the process nobody follows, and then you have no process and a document that says you do.
This is a living document on this site for the same reason: the useful version is the one that reflects what a team actually does.
The short version
- Handoffs are the cost. Stages multiply against your volume, and a stage nobody performs is worse than none.
- Four states: agreed, drafted, approved, scheduled. That covers a team of two to five.
- One named owner per stage, and one approver. Not a committee.
- Write down three things only: a brief format, a publish checklist, and who owns each stage.
- The real requirement is visible state. Anyone should see who is holding what, in a minute.
- Two platform properties constrain the process: whether a non-developer can publish, and whether changes need a developer.
- Add a stage after the second failure, never the first. Remove any stage nobody performs.
