The Problem With "Just Document Your Processes"

Every company we walk into has a Confluence or Notion with hundreds of process docs. Maybe ten percent get read. Fewer get updated. The docs were not the problem the team thought they were solving. Writing them down did not make the processes better. It gave leadership something to point at when someone asked "how does this scale."

The pattern repeats. A growing company hits a coordination problem. Someone senior says "we need to document our processes." A quarter of effort goes into populating a wiki. The processes do not improve. A year later, the wiki is mostly obsolete, nobody trusts it, and the original coordination problem is still there.

This is not an argument against documentation. Documentation is useful for a narrow set of jobs. The problem is that "just document your processes" gets prescribed as a general fix for scaling, and for that job it is close to useless.

What does "just document your processes" actually mean in practice?

"Just document your processes" is the common leadership prescription for operational scaling, which translates into asking teams to write down how their work happens in a wiki like Confluence or Notion. The intent is to reduce key-person risk, speed up onboarding, and make operations legible. In practice, the exercise produces a large volume of pages that describe the work as people imagine it, not the work as it actually happens.

The idea goes back further than most people realize. Ward Cunningham built WikiWikiWeb, the first wiki, in 1995 for software teams to capture patterns and conversations. His original design assumed writers and readers were the same people, editing constantly. Modern corporate wikis inverted that assumption. A few people write, many are supposed to read, and almost nobody edits. Atlassian's State of Teams research tracks the gap: teams spend real time producing internal content that colleagues struggle to find and rarely consume.

The practical effect is a growing gap between what the docs say and what the team does. Research cited by Productiv shows that organizations typically use a small fraction of the SaaS apps they pay for. The same dynamic shows up in a different context here. Capacity gets spent on artifacts that do not match the actual flow of work.

Does process documentation actually scale operations?

Process documentation does not scale operations on its own. Documentation is a record of a process, not the process itself. Writing a page about how an onboarding workflow should run has roughly zero effect on whether the workflow actually runs that way next month, because next month's work is driven by calendars, tools, incentives, and handoffs. Not by the wiki.

Scaling an operation means producing more output per unit of input without more heroics. That usually requires removing steps, automating them, or changing how handoffs work. Writing a page about an existing process does none of that. It can make the process legible to a newcomer, which helps onboarding, but it does not make the process run better or absorb more volume.

The illusion of scalability is the expensive part. When leadership looks at a populated wiki and concludes "we have documented the process, so the process can scale," they stop funding the real work of improving it. McKinsey's research on knowledge management has found for more than a decade that documentation investments produce most of their value when paired with structural workflow change, and little value on their own. Companies that got real returns from SOP programs did so by using the documentation exercise to surface broken steps and fix them. The docs themselves were a byproduct.

What does documentation actually solve versus pretend to solve?

Documentation solves a narrow set of problems well. It pretends to solve a much wider set, and that mismatch is where the Confluence graveyard comes from.

The jobs documentation is actually good at: onboarding a new hire into a job that exists today, preserving an audit trail for compliance, and enabling a handoff when a specific person leaves or changes roles. In all three cases, the doc has a clear reader, a clear expiration date, and a specific event that triggers the read. That is why these docs tend to stay alive. Someone needs them, on a schedule, for a defined purpose.

The jobs documentation pretends to do: scalability, consistency, and knowledge retention across the whole company. These fail for the same reason. They assume the doc will be read by the right person, at the right time, without a trigger. That assumption breaks constantly. People do not consult the wiki mid-task. They ask a colleague, search Slack, or improvise. Atlassian's own research on knowledge work shows that search and colleague-ask beat wiki-consult for almost every in-the-flow question. A doc that would have prevented a mistake, if read, does not prevent the mistake because nobody read it.

Why do documented processes still fail?

Documented processes fail for three compounding reasons. Docs rot faster than anyone maintains them. Writing docs for work you do not yet understand is theater. And the act of documenting something creates a false belief that the thing is solved.

Documentation rot is the first and largest force. A process changes whenever the tool behind it changes, whenever the team changes, and whenever upstream or downstream steps change. That happens constantly in a growing company. The doc does not change on the same cadence. Harvard Business Review has reported on the cost of this drift for years under different names, from "tacit knowledge loss" to "institutional forgetting." The pattern is the same. The wiki captures a snapshot from a moment that has already passed.

The second force is premature documentation. Teams under pressure to "document our processes" end up writing pages about work that is still being figured out. Writing forces a specificity the underlying work does not yet have. The doc describes a clean version of the process that nobody actually follows, because the real process is still being invented in Slack threads and ad-hoc meetings. Gallup's State of the Workplace data consistently shows that engagement declines when people are asked to do work that feels performative. This is that work.

The third force is the false-solve. Once a page exists, leadership and the team both feel the problem is handled. New friction points get treated as a documentation gap, which sends the team back to writing more docs, which rot at the same rate. The company now has two problems instead of one.

When is docs-first the wrong answer?

Docs-first is the wrong answer any time the underlying process is changing faster than the doc can be updated, any time the process is repetitive enough to be automated, and any time the knowledge transfer is visual or conversational by nature.

The faster-than-maintainable test is simple. If a workflow changes tools, owners, or steps more than once a quarter, a written doc will be wrong by the time someone reads it. The team will either ignore the doc or burn capacity keeping it current. Either way, the doc is not doing useful work. This applies to most sales operations workflows, almost all RevOps reporting pipelines, and anything that touches a rapidly evolving SaaS tool.

The automation test is the "document only what you have already automated" heuristic. If a process runs the same way every time, it belongs inside a workflow engine, not inside a wiki. Documenting a repeatable process is strictly worse than automating it, because the automated version cannot drift. The doc for an automated process is a single page explaining what triggers it, what it produces, and who owns the script. That is useful. Writing a five-page SOP for work a script could do is busywork.

The visual-or-conversational test is where Loom and similar tools fit. Some processes are much easier to show than to describe. How to handle a specific customer escalation. How to run a particular kind of deal review. How to work around a tool's weird corner case. A three-minute recording of someone doing the thing, with narration, carries more useful signal than a thousand words of prose and takes a tenth the time to produce. It also ages more gracefully, because a viewer can tell from context clues when a Loom is out of date in a way they cannot from a text doc.

What is the difference between living docs and dead docs?

Living docs are working artifacts embedded in the flow of work, owned by a specific person, with a clear trigger for when they are read and updated. Dead docs are artifacts written once and deposited into a wiki without an owner, a trigger, or a reader. Most corporate documentation is dead on arrival.

A living doc is usually something like a runbook in the repo next to the code it describes, a prompt template a team references every week, a checklist built into the tool where the work happens, or a README someone has to read before they can run a command. These docs stay alive because using them is the same action as reading them. The cost of them being wrong is immediate and visible.

A dead doc is a Confluence page called "How We Do Onboarding" that was written two years ago by someone who has since left. Nobody has a trigger to read it. Nobody is paid to maintain it. It shows up in search results and confuses new hires. The team routes around it using Slack and tribal knowledge. The doc is a fossil. It takes up space and provides negative value, because it misleads anyone who trusts it.

The useful question for any existing doc is: who reads this, when, and what happens if they read a wrong version. If there is no clear answer, the doc is dead. Delete it or move it to an archive. Notion bloat and Confluence graveyards are the same phenomenon. Dead docs accumulating because nobody has permission to delete.

How do you triage existing process documentation?

Triage means walking the existing doc store and making an explicit keep-automate-record-or-delete decision for every significant page. The goal is to shrink the doc store to what is load-bearing and route everything else to a better home.

Expect the triage to cut the doc store by fifty percent or more. Teams we work with routinely find that fewer than one in five pages in a mature Confluence or Notion instance meets the living-doc bar. The rest are dead or describe work that should be automated or shown. A smaller, trusted doc store gets used more than the larger, untrusted one it replaced.

The pattern is the same one that applies to process improvement in general. Adding things is easy and feels productive. Removing things is harder and actually moves the needle. For the broader frame on prioritizing this kind of work, see how to prioritize process improvements with limited resources. For what continuous improvement looks like when it is working instead of burning people out, see continuous improvement without burning out your team.

When should you write, when should you automate, and when should you record?

The short answer: write only when the process is stable, the reader is clear, and the trigger for reading is defined. Automate when the process repeats. Record when the knowledge is visual or conversational.

Write when onboarding a hire into a defined job that will stay stable for at least a year, when compliance requires an audit trail with specific format requirements, or when a single expert is leaving and a specific successor needs their knowledge transferred. In all three cases, the reader and the trigger are obvious. These docs stay current because someone specific cares.

Automate when a sequence of steps runs the same way each time. Billing reconciliations, lead routing, invoice generation, data syncs, reporting pipelines. Each of these belongs in an automation layer, not a wiki. Technology companies we work with usually find that thirty to fifty percent of their documented SOPs are candidates for full automation. For related context, see lean operations for technology companies.

Record when the knowledge is about how something looks or feels. A Loom of a senior rep running a discovery call conveys more than any written call guide. A screen recording of a CS lead walking through a renewal beats a playbook doc. The recording is faster to produce and ages more gracefully, because the viewer can see from context what has changed.

Key takeaways

Documentation rots faster than anyone maintains it. The docs a company needs are a small fraction of the docs it tends to produce. "Just document your processes" fails as a scaling strategy because documentation is a record of work, not a mechanism that changes how work runs.

The jobs documentation does well are onboarding, audit trail, and handoff. The jobs it pretends to do, scalability and consistency and knowledge retention, are better served by automation, by structural redesign, or by short recordings.

The heuristic worth adopting: document only what you have already automated, record what is visual or conversational, and delete what has no reader or trigger. A smaller, living doc store is used more and trusted more than a large graveyard. The smaller store is also cheaper to maintain, which means the capacity it frees can go to work that actually improves how the operation runs.

If your Confluence or Notion has become a graveyard, the fix is not more documentation discipline. The fix is triage, followed by a serious look at which documented processes should be automated away. For the frame on why teams stop noticing this kind of buildup, see why teams stop noticing inefficiencies.