The Process Map on Your Wiki Is Fan Fiction

Every company has two operating systems. The first one lives in Notion, polished and quarterly-reviewed, with tidy swimlane diagrams and named owners. The second one lives in Slack DMs, a sticky note on someone's monitor, and a spreadsheet that Maria in ops keeps on her desktop because "the official one doesn't have the right columns."

Guess which one keeps the business running?

If you're a small team trying to automate your workflows, this gap isn't a quirk. It's the reason your Zapier zaps keep breaking, your handoffs keep dropping, and your shiny new tool gets abandoned by week three. You automated the fiction.

The Documentation Drift Is Nobody's Fault (and Everyone's Problem)

Here's how drift happens. Someone writes a process doc. It's accurate — for about six weeks. Then a client asks for something slightly different, so a rep starts looping in a teammate earlier. A vendor changes their portal. Someone leaves, and their "temporary" workaround becomes permanent tribal knowledge.

Nobody updates the doc because everyone's busy doing the actual work. The doc becomes aspirational — a description of how the team should operate in a world without edge cases. It's fan fiction about your own company.

The danger compounds when you layer automation on top. If you build an automated handoff based on the documented flow, but the real flow includes an undocumented review step, you've just created a bottleneck the wiki says can't exist. And unlike a human, your automation won't quietly improvise to compensate. It will just fail, silently, at 2 a.m.

Run a Shadow Audit (It Takes One Afternoon)

Before you automate anything, you need to find out what's actually happening. Call it a shadow audit. You're not looking for what the process should be — you're mapping the process as it survives in the wild.

Step 1: Pick one workflow that hurts. Invoice approvals, client onboarding, content publishing — whatever generates the most "hey, quick question" messages. Don't try to audit everything. One workflow, end to end.

Step 2: Follow a real work item, not the diagram. Take the last five instances of whatever flows through this process — five invoices, five new clients. Trace each one from start to finish. Where did it actually go? Who touched it? Ask each person one question: "What did you do next, and who did you ask about it?"

Step 3: Hunt for the three tells of shadow process.

• The side channel. Work happening in DMs, texts, or hallway conversations that never touches the system of record.
• The personal tool. Maria's spreadsheet. The private checklist. The bookmarked folder of email templates. If it lives on one person's machine, it's a single point of failure with a smile.
• The silent step. The review, the double-check, the "I always run it by Dana first" that appears in zero documentation.

Step 4: Write down the real map — including the ugly parts. Yes, it's embarrassing that your client onboarding involves a screenshot emailed to a contractor. Document it anyway. You can't fix a workflow you won't admit exists.

Rebuild the Docs Around Reality, Then Automate the Boring Parts

Once you have the real map, resist the urge to redesign everything into an idealized flow. Small teams don't have the bandwidth for process re-education campaigns. Instead, meet the workflow where it is.

First, rewrite the documentation so it matches observed behavior. If the real process has six steps and a Dana-check, the doc gets six steps and a Dana-check. This alone kills a huge amount of tribal knowledge risk — the stuff that walks out the door when someone resigns.

Second, look for the friction that the shadow process was invented to solve. Maria's spreadsheet exists because the official tool lacks a column. The DM-to-Dana exists because the approval queue has no notifications. These workarounds are free user research. Each one is a feature request or an automation candidate wearing a trench coat.

Third, automate only the steps that are identical every single time. The invoice routing? Automate it. The judgment call about whether a client is happy? Leave it human. A good rule of thumb: automate the handoffs, not the decisions.

Keep the Doc Honest With a Two-Question Habit

Documentation drift returns unless you build a small counter-force. Add two questions to your existing retros or monthly ops check-in:

1. "Did anything this month happen outside the documented process?"
2. "Did anyone build a workaround?"

That's it. Two questions, five minutes, once a month. It won't produce perfect documentation, but it will keep the gap between the wiki and reality narrow enough that your automations don't fall into it.

Your team's real process isn't the enemy of your automation stack — it's the blueprint for it. The wiki version was written by who you wanted to be. The DM-and-sticky-note version is who you actually are. Automate the second one, and the first one might finally become true.