Every organization has them: Standard Operating Procedures. They are the documented backbone of how work gets done. They represent institutional knowledge, hard-won process clarity, and the organizational promise that people won’t have to figure things out alone.
Until, one day, they do.
At one of Amazon’s Alexa Shopping teams, we operated against a clear accuracy standard. On established projects, our SOPs were built from months of real-world application. They were thorough because the work had taught us what a thorough SOP needed to look like. We knew the data, we knew the edge cases, and the SOP reflected that accumulated knowledge.
Then a new project would arrive.
And the SOP would go quiet exactly where we needed it to speak.
This isn’t a criticism of Amazon specifically. It’s a fundamental truth about documentation: SOPs are written for the work you already understand. They cannot, by definition, fully account for the work you haven’t done yet. New projects expose gaps not because someone was negligent, but because the unknown is undocumented by nature.
The question isn’t whether gaps will exist. They will. The question is what happens to people when they do.
Experience became the unofficial SOP.
On our team, those of us with years on the job could draw on deep pattern recognition when the documentation went silent. We knew how the data was typically processed, how similar situations had been handled on previous projects, and what the underlying logic of the work usually demanded. We could float on expertise even when the SOP offered no instructions.
Newer team members didn’t have that same life jacket.
This is the change management problem that rarely gets named: when an SOP is incomplete, the gap doesn’t disappear. It gets filled as we go, by experience, by judgment, by informal consultation, or by guesswork. The quality of what fills that gap depends entirely on who is doing the filling and what they have to draw from. An SOP that assumes experienced practitioners will compensate for its own gaps is not a safety net. It’s a system that rewards tenure and penalizes newness in ways that are invisible until something goes wrong.
The team built what the system didn’t provide.
What emerged organically on our team was something I now recognize as real-time knowledge management. In a group chat, we’d calibrate with each other constantly on new projects. We didn’t gossip or vent; we used structured peer reasoning. “I’ve been seeing data like this. I’ve been handling it X way because of Y. How are you approaching it?”
We were building collective intelligence informally because the formal system couldn’t keep up with the pace of new work.
Some of that intelligence made it back into the SOP. We’d keep our own documentation as we went, capturing our reasoning and our decisions, and bring it to the project lead for clarification. At Amazon, logical reasoning was your defense. If you could articulate why you made a call, you were generally protected. So we documented our logic, pushed for SOP updates, and watched the next iteration of the project benefit from what we’d figured out the hard way.
But some of that knowledge stayed in the group chat. In people’s heads. And when people left, it left with them.
This is the part organizations consistently underestimate.
The informal knowledge layer that experienced teams build around incomplete documentation is extraordinarily valuable. It represents real-time gap analysis, peer calibration, and applied judgment under uncertainty. It is, functionally, the organization learning in real time.
But if that learning never makes it back into the formal system — if it lives in chat histories and institutional memory rather than updated SOPs and documented rationale — then the organization isn’t actually learning. It’s just cycling through the same undocumented gaps with each new project, each new team member, each new iteration.
A document is not a change. It’s a record of intent. The change happens when people understand not just what the SOP says, but why it says it. Real comprehension means having enough context to exercise judgment in the spaces the SOP doesn’t cover, and the organization having a mechanism to capture what people learn when they do.
So here’s the question I’d ask of your organization: when your team fills the gaps your SOPs don’t cover, where does that knowledge go? And who bears the cost when it stays informal?