If someone can't follow it without you, it's a memory, not documentation.
I heard that on a Monday, in a session about writing standard operating procedures. I wrote it down thinking it was about documentation.
By Friday it had described two different failures of mine, and the second one had nothing to do with writing anything down.
The obvious version
Last week I mapped my default work habit as a flowchart and the left branch looped back on itself. I take the work because I already know how to do it, nobody else learns it, and next week I am still the only one who knows.
That line is the same loop in one sentence.
Everything I take on because I already know how to do it lives in my head. It feels like productivity while I am doing it. What it produces is a memory, and a memory leaves the building when I do. The loop was never that I work too hard. The loop is that I keep generating knowledge that has exactly one copy.
The session's worked example was deliberately stupid: how to log into your laptop, written out to the level of which button is the power button and where it sits on the keyboard.
My first reaction was that this is over-explained. That reaction is the problem. "Everybody knows that" holds up right until the person who knows it is out sick.
The same idea pointed at a team
The other framework this week was Role, Signal, Handoff.
- Role. What you are specifically responsible for.
- Signal. How anyone else knows it is done.
- Handoff. How the next person receives it and confirms they got it.
Weak version: "I handle research." "I finished my part."
Strong version: find three credible sources, put the key points on slide 2 by 1 PM, upload it and tag the person who needs it next.
The difference is not effort. It is whether the work is visible from outside your own head.
We have our roles set and our signals defined. Handoff is the part we are still building, which is predictable, because handoff is the only one of the three that requires somebody else to confirm they got it. The first two you can do alone.
The same failure at company size
Friday was the i.c.stars iOpener Innovation Conference. The theme was "KC's AI Boom: Billions Invested, What Comes Next?" Banks, engineering firms, law firms, a school district.
I went in expecting infrastructure and models. Most of what I heard was about documentation.
Traci Wills, who runs enterprise portfolio management and strategy execution at NAIC, put it plainly: the barrier is not access to AI. The access is there. The barrier is organizational readiness. Companies pilot fine and then cannot scale, because there is no clear problem statement, no trusted data, and governance that exists on paper without changing what anyone actually does on a Tuesday.
Then Craig Moore II of Endeavor Heartland said the thing that made me put my pen down:
If you can't do it manually, you're not going to be able to automate it. If you don't have SOPs, if multiple people in your organization cannot speak to the same process the same way, AI is going to be hard for you.
That is Monday's session with a budget attached. A company where one person can describe a process is a company running on memory instead of documentation. Same failure as mine. More zeroes.
Dianna Keen, Managing Director of Technology at VML Enterprise Solutions, gave the version that stuck:
Whatever is true about that system at the time is what you're scaling. If it's bad, you're scaling bad.
Scale is not a fix. Scale is a multiplier on whatever shape is already there.
One shape, three sizes
By Friday afternoon I had seen the same diagram three times in five days.
One person. I already know how to do it, so it never gets written down, so next week I am still the only one who knows.
A team. Roles that sound like "I handle research," so nobody says what done looks like, so the work stalls between people.
An organization. A process only one person can describe, so the pilot works and production never ships.
Something valuable exists, it has exactly one copy, and the fastest path today guarantees you make the same decision again next week.
At every one of those scales, the problem is rarely that the knowledge does not exist. It exists and cannot be reached. Somebody absorbs that friction either way. The only question is whether it lands on the one person who knows or the however-many people who have to go ask them.
The fix is the same at every size and it is boring. Write it down so it survives without you.
The fourth size
Here is the one I did not see coming, and it is smaller than all three.
On Thursday we had a roundtable Q&A with our client. Every team got to ask. I asked one.
Not a throwaway. I am the solutions analyst on my team and I could not tell where this project was supposed to end. The only people who could answer that were sitting right there, so I asked them.
That is the exact thing I told you all I would start doing. I did it inside of a week.
It was also the easiest possible version of it. Clear role, specific gap, question written down in advance. If speaking up were always that structured I would not have a problem.
Friday was not structured.
The table exercise: your table gets a symbolic one billion dollars. Allocate all of it to one of six AI priority areas. Then imagine it is 2031 and it worked. Write the headline.
I contributed. I also choked.
Both are true and the difference between them is the useful part. I said things at my table. They were not the things I was actually thinking. The gap between what I had in my head and what came out of my mouth was wider than it has been in any session so far, and the only variable that changed was who was sitting there.
Then I walked away from the table and networked for the rest of the event with none of that friction. Real conversations. People I want to talk to again.
So I am not quiet. One on one I am fine. What shuts me down is a group of people I have not earned anything with yet, talking about something I have an opinion on.
Which brings it back around to Monday.
An opinion I do not say out loud is knowledge with exactly one copy. It exists. It is in one head. Nobody else can act on it, build on it, or tell me I am wrong about it. Next week I am in another room with the same thought, having the same internal argument, and nothing about the situation has changed.
That is not a personality trait. That is the same loop I drew last week, running at the smallest scale there is.
A memory, not documentation.
Looking ahead to week four
Finish the handoff half of Role, Signal, Handoff, which means actually confirming receipt instead of assuming the work landed.
And find the smaller version of Friday. Not a keynote. A room of eight or ten people where I have an opinion and no assigned role that requires me to speak. That is the rep I am missing, and asking a prepared question at a structured Q&A does not count as having done it.
What is the thing you know how to do that nobody else on your team could run without you?
That is not a skill. That is a single point of failure with your name on it.
Week four goes up Friday.
Top comments (3)
Interesting thought. Makes me think though, that's exactly the pattern we tend to do when programming with LLMs. we have the idea in our heads, then we instruct the LLM, then correct the LLM if it's wrong? In the end, if we drift, the scope drifts. As opposed to discuss the process with the LLM first, commit the scope to file. Then have another LLM monitor progress and prompt the second either we, or the LLM coding drifts? Distributed redundancy for scope drift.
Yeah, I've lived this. Constant prompting and the thing slowly becomes something I didn't ask for.
What I do now is keep a backlog and a manual for each build. Scope goes in the file, not the chat. When a session starts wandering, I have something to check it against instead of trying to remember what I decided three days ago.
So I've got the first half of what you're describing. The part I haven't tried is the second LLM watching for drift. Does that hold up in practice, or does the monitor drift too?
It actually did pretty decently in Qoder, I had a polling task set to monitor for drift and send corrections to the llm, that way it progressively keeps it on track