Cora Byrne · Founder, The Ór Standard · April 2026
The documentation debt no one is counting
Technical teams track code debt. They do not track documentation debt. They should.
Code debt is the cost of shortcuts taken now that increase the cost of change later. Documentation debt works the same way — but it accumulates invisibly, in support tickets answered manually instead of by documentation, in onboarding sessions repeated because the getting-started guide does not exist, in integration failures caused by API reference documentation that describes the endpoint as it was designed rather than as it currently behaves.
The reason documentation debt stays invisible is that it is paid in other people's time. The engineer answers the Slack message. The customer success manager walks the new client through the setup. The developer advocate runs the webinar that explains what the documentation should have covered. None of these costs appear on the documentation line of the budget. They appear on the engineering line, the success line, the marketing line — distributed and therefore uncounted.
Documentation debt has three components:
1. Completeness debt: the documentation that should exist but does not. This is the most visible component because the gaps are at least identifiable, even if they are not filled.
2. Accuracy debt: the documentation that exists but describes a product that no longer exists. This is more dangerous than absence, because it creates active misinformation — a developer following outdated documentation fails in a way that looks like their failure, not the documentation's.
3. Structural debt: the documentation that is complete and accurate but organised in a way that prevents users from finding it. This is the most expensive component and the least discussed, because it requires architectural thinking rather than writing effort to resolve.
Organisations typically attack completeness debt while ignoring accuracy debt and structural debt. The application of this ends up with writing more docs without updating existing docs and rebuilding the architecture. This is why documentation investment frequently fails to produce the expected reduction in support load or improvement in developer experience — it addresses the visible symptom rather than the structural cause.
The Ór Standard's six-dimension audit framework was built to make all three components visible simultaneously, so that remediation effort goes to the failure with the highest organisational cost, not the failure that is easiest to write about.
If your team is answering questions that should be answered by documentation, the documentation debt is already compounding. The question is not whether to pay it — you are already paying it. The question is whether to pay it in engineer time, or in a structured remediation that eliminates the debt rather than services it indefinitely.
Cora Byrne is the founder of The Ór Standard, a specialist documentation systems consultancy based in the United Kingdom.
Cora Byrne · Founder, The Ór Standard · April 2026
Your documentation excludes people. I am one of them.
I have dyslexia. I have dyscalculia. I have dyspraxia. I am also a Senior Technical Author who has spent years building documentation systems for some of the most technically demanding products in the industry. These two facts live together in me every day, and the tension between them is what drives everything I do.
I am not writing this for the disability awareness moment. I am writing it because documentation — technical documentation, specifically — is one of the most inaccessible forms of writing that exists, and almost nobody in the industry treats that as the systems failure it is.
Let me tell you what it is like to be a documentation specialist who struggles with the documentation that most of our industry produces.
A wall of unbroken text is not neutral. It is a barrier. When text has no visual hierarchy — no headers that tell me where I am, no short paragraphs that give me a place to pause, no clear signposting between concept and instruction — I lose my place. I re-read the same line. I lose my place again. I close the page. For someone without dyslexia, this might register as mildly annoying. For me, and for the estimated one in ten people who share this, it is the difference between being able to use a product and not being able to use it at all.
Passive voice is not just stylistically weak. It is cognitively expensive. "The configuration file should be modified" costs more processing than "Modify the configuration file." That additional processing matters when your brain is already working harder to decode the letters on the page. I know this not because I read a study, but because I feel it every time I encounter documentation written in passive voice. My brain stumbles. I re-read. I lose my place. The instruction fails to land.
Inconsistent terminology is not a minor style issue. It is a cognitive load problem. When a product calls the same thing a "workspace" in one section and a "project" in another, my brain has to hold both labels, decide whether they mean the same thing, and continue reading while carrying that uncertainty. For someone with a working memory difference — which dyscalculia and dyspraxia both affect, in different ways — that is a significant additional burden. It is one of the reasons I care so intensely about terminology governance. It is not an abstract documentation principle. It is the difference between a user who can follow a process and one who cannot.
Numbered sequences presented without structure are something I find genuinely difficult to hold. A ten-step process written as a numbered list is not automatically clear. The steps need to be short. Each one needs to be a single action. The numbering needs to be unambiguous. When documentation contains steps that bundle multiple actions ("Configure the environment and ensure the permissions are set correctly before proceeding"), I lose count, lose sequence, lose my place in the process. My dyspraxia affects sequencing. It affects planning. Documentation that does not respect sequence — that buries the order of operations inside prose paragraphs — is documentation I cannot follow reliably, regardless of how technically accurate it is.
I am telling you this not to describe a personal inconvenience but to describe a structural failure. These are not edge cases. The estimates vary by study, but something in the range of fifteen to twenty percent of the population is neurodivergent in some form. Dyslexia alone affects around ten percent. That is not a small segment of users. It is a large portion of the developers, operators, and customers attempting to use your product right now, failing, and either escalating to support or giving up entirely.
Here is what I know from building documentation systems for technical products: the patterns that exclude neurodivergent users are the same patterns that make documentation harder for everyone. Short sentences are clearer than long ones for every reader. Active voice is faster to process for every reader. Consistent terminology reduces cognitive load for every reader. Clear hierarchy — headers that actually tell you what the section contains, not clever ones that make you read to find out — helps every reader navigate more efficiently. Accessible documentation is better documentation. Not adapted documentation. Not documentation with an accessibility appendix. Better documentation, for everyone who uses it.
The documentation industry has a habit of treating accessibility as a checkbox. Alt text on images. Sufficient colour contrast. A skip navigation link. These are important. They are also the absolute minimum. Cognitive accessibility — the kind that affects whether someone with dyslexia or ADHD or dyscalculia can actually use the documentation to accomplish a task — rarely appears in documentation audits, style guides, or governance frameworks.
It appears in The Ór Standard's.
When I audit documentation, I look at whether the information architecture maps to how users actually think, not how the internal team has organised the product. I look at whether terminology is consistent enough to be held in working memory. I look at whether procedural documentation is broken into genuinely discrete steps. I look at whether headers communicate content rather than tease it. I look at whether the reading level is calibrated to the actual audience rather than the assumed audience. None of these are specialist accessibility considerations. They are the baseline of documentation that works.
I built The Ór Standard to raise that baseline. I did it partly because I have spent my career in a field that produces a product I often cannot use myself, and I find that professionally unacceptable. I did it partly because every organisation I have worked with has the same fundamental problem: they have documentation that was never designed to be used, only to exist.
Accessible documentation is not a feature you add at the end. It is a structural property of documentation that was designed correctly from the beginning. And it begins with the architecture — which is where The Ór Standard always begins.
Cora Byrne is the founder of The Ór Standard. She is dyslexic, dyscalculic, and dyspraxic — and has built a career in documentation precisely because of what those experiences have taught her about what good documentation actually requires.
