processes · operations
Why documented processes get skipped (and it isn't laziness)
Teams write the process down and still miss the step. The reasons are structural: distance, timing, stale documents and invisible adherence. What each one looks like on a real ticket, and what fixes it.
Every operations leader has had the conversation. A customer was told the wrong thing, an escalation bounced back from engineering, a release went out without the sign-off. Someone pulls up the Confluence page and says: but it's right here.
It is right there. And it still got skipped. After a few hundred of these conversations, the pattern is clear enough to name. People don't skip documented steps because they're careless. They skip them for four structural reasons, and each one has a different fix.
1. The document is far from the work
The runbook lives in Confluence. The ticket lives in Freshdesk. The engineering issue lives in Jira. The decision that changes everything was made in a Slack thread on Tuesday. The person working the ticket would need five tabs and ten minutes to assemble what the process says for this item.
Nobody has ten minutes per ticket. So they do what people do: they act on what's in front of them, which is the ticket, and they rely on memory for the rest. Memory is fine for the common path and terrible for the exception, and the exception is exactly where the document earns its keep.
What fixes it: bring the process to the work. Not a link — the step. "Next: tell the customer this is expected behaviour, and run Recalculate." The document is still the source of truth; it's just read on the person's behalf, for this ticket, with the context joined up.
2. The step depends on a fact nobody checked
Most processes branch. "If the LP is compliance-critical, raise P2." "If the customer is on 4.12 or later, the fix is already live." "If it's one user, it's data; if it's many, it's configuration." The branch condition is a fact about the item, and the fact is often not in the ticket.
Here is the quiet failure: the person doesn't know the fact, doesn't know the process depends on it, and takes the default branch. The document was followed. The wrong branch was taken. Nobody notices until the customer does.
What fixes it: asking. The question the document needs answered, asked at the moment it matters, with the document's own options: one user or many? Which environment was it tested on? A process that asks before it assumes is followed far more often than one that assumes.
3. The document was right last quarter
Processes drift. Engineering changes the escalation path, a new squad takes over an area, a tool is replaced. The document is updated six weeks later, if someone remembers. In those six weeks the experienced people follow the real process (they were in the meeting) and the new people follow the written one. Both think they're right.
The expensive version of this is training: a cohort trained in March on a document that changed in April, confidently doing it the old way in May.
What fixes it: make corrections flow back. When someone says "that's wrong, we escalate to the Learn squad now", that correction should (a) apply immediately to similar items and (b) become a proposed edit to the document, with the owner deciding. And when the document changes, the people trained on the old version should be told what changed — in one paragraph, not a diff.
4. Nobody can see adherence until it's a post-mortem
Ask a team lead what percentage of tickets followed the triage process last month. Nobody knows. Adherence is invisible until something breaks badly enough to warrant a review, and by then the question is "who", not "where".
Without visibility there's no feedback: a step that gets skipped 40% of the time looks exactly like one that's never skipped. The document can't improve because nobody knows where it's failing.
What fixes it: signals. Every correction, every question the document couldn't answer, every training scenario people get wrong, grouped by stage. A stage that many people miss is a document problem, not a people problem — and now you can see it.
The common thread
None of these are solved by writing a better document, running a training session, or sending a reminder. They're solved by closing the distance between the document and the moment of action, and by letting the moment of action correct the document. That loop — follow, correct, retrain — is what we built Ovenbird around. But even without a tool, the four questions are worth asking about any process your team keeps missing: how far is the document from the work? Which fact does the step depend on? When was it last true? How would we know it was skipped?