Someone on your team asks you a question. You answer it. Three weeks later, someone else asks you the same question, and you answer it again, slightly differently, because you’ve forgotten exactly how you put it the first time.
That’s not a communication problem. Everyone understood you perfectly, both times. It’s a problem with where the answer went afterwards, which is nowhere.
Most founders respond to this by trying to communicate better. More context in meetings, clearer explanations, more patience. It rarely helps, because the thing that failed wasn’t the explaining.
Conversation transmits, it doesn’t store
A conversation is very good at getting an idea from one head into another. It is terrible at keeping it there in a form anyone else can reach.
When you decide something in a conversation, four things happen. The person you told knows it. Nobody else does. Neither of you records why. And in six weeks, the two of you remember it slightly differently, with no way to tell whose version is right.
That’s survivable at three people, because everyone is in most conversations. It stops being survivable somewhere around eight to twelve, when the number of conversations exceeds what any one person can be present for. The failure doesn’t announce itself. It shows up as the same questions recurring, as two people confidently doing contradictory things, and as a founder who feels increasingly like a lookup service for their own company.
The founder who hit the ceiling and built past it
Judith Naegely ran into this early, and her response is instructive because she treated it as an operations problem rather than a people problem.
In 2007 she co-founded CertaMed Medical Staffing, a home health therapy staffing company, which she grew from a one-person operation to more than 45 therapists. By her own account, only a few months in it became clear that spreadsheets weren’t going to hold it — the business needed real-time visibility into patients, notes and communications, and a spreadsheet updated by whoever remembered to update it couldn’t provide that.
So they built the thing they needed. That internal tool became Pariox, software for physical, occupational and speech therapists working in home health. Other therapy groups saw it and asked to use it, and the internal fix became a company in its own right, which she co-founded and led as CEO. She sold CertaMed in 2020 and has since changed field entirely — she’s now a CERTIFIED FINANCIAL PLANNER professional and a fiduciary advisor at Marathon Wealth & Protection Strategies.
Two things in that are worth separating out.
The first is the timing. She hit the spreadsheet ceiling within months, not years, and treated it as a real constraint rather than something to push through with effort. Most owners feel the same ceiling and respond by trying harder — more reminders, more check-ins, more of themselves in the gaps.
The second is what the fix was aimed at. Not better communication. Shared visibility, so the current state of things could be looked up rather than asked about. The question stopped needing to reach a person.
You almost certainly don’t need to build software. But the distinction holds at any size: some problems get better when you explain more clearly, and some only get better when the answer stops living in someone’s head.
What actually needs writing down
Not everything, and this is where most attempts at documentation go wrong. A founder decides to write things down, starts a wiki, produces forty pages nobody reads, and concludes documentation doesn’t work here.
Three categories are worth the effort. Almost nothing else is.
- Decisions and the reasoning behind them. Not just what was decided — why, and what was considered and rejected. Without the reasoning, people can’t tell whether a new situation is covered by the old decision.
- Who decides what, and up to what limit. The single most common cause of unnecessary escalation is that nobody knows the boundary of their own authority, so everything gets checked.
- Anything you’ve now explained twice. The second time you say something is the signal. There will be a third.
Everything else — process detail, step-by-step instructions, how the software works — matters less than people think, changes constantly, and is usually better learned by doing.
Where it goes matters more than how good it is
A well-written document in a place nobody looks is the same as no document.
The practical test is whether someone with a question finds the answer before they think to ask you. That means it lives where the work happens, not in a separate knowledge system somebody has to remember exists. One findable page beats a well-organised library that requires a habit nobody has.
It also has to be the kind of thing you’ll actually maintain. A paragraph you update is worth more than a template you fill in once and abandon, because the failure mode of documentation isn’t being incomplete — it’s being wrong. People stop trusting a record that has misled them once, and then they come back to asking you, which is where you started.
It’s also worth noticing what the interruptions cost you. Every question that reaches you is time taken from the work only you can do, which is the argument for protecting thinking time in the first place.
The test worth running
For two weeks, note every question you answer that you’ve answered before. Don’t change anything, just keep the list.
What you’ll have at the end is a precise, ranked account of what your business has failed to write down, ordered by how much it’s costing you. Start at the top.
Most founders are surprised by the list, and specifically by how few distinct items are on it. The same handful of questions usually accounts for most of the interruptions — which means the fix is smaller than it feels from inside the experience of being asked constantly.
