There are a few phrases that quietly undermine organisations from the inside out. They are rarely said with malice - often with confidence, but I've heard them all when it comes to a lack of documentation.
"I'll do it later."
"I know it inside out, so it's fine."
"There's no time right now."
On the surface, these sound reasonable in the short-term. Sensible, even. But taken together, they form one of the most reliable recipes for operational failure that I have seen in over three decades of working with technology, infrastructure, and security.
Documentation is never viewed as exciting work. It does not solve problems, ship features, win demos - nor does it feel urgent when systems are running and alerts are quiet. But when it is missing (along with the person who created that system and is the knowledge holder), that solid pane of glass will shatter into a million pieces.
Knowledge in One Person Is Not "Knowledge"
One of the most common justifications for a lack of documentation is familiarity.
"I built it."
"I've maintained it for years."
"I know where everything lives."
This is not documentation. This is institutional risk concentrated in a single human being just waiting to bubble to the surface.
The moment that person is unavailable, unwell, on holiday, or leaves the organisation, that knowledge becomes inaccessible. What was once a functioning system quickly turns into an opaque black box. Even simple tasks become slow, risky, and dependent on guesswork.
This is not a theoretical concern. It is how outages get prolonged, how incidents escalate, and how organisations discover too late that they do not actually understand their own environment.
"I'll Do It Later" Usually Means "Never"
Documentation debt behaves very much like technical debt, but with an even sharper edge.
When systems are first deployed, context is fresh. Design decisions are clear, trade-offs are understood, and dependencies make sense (at the time). That is the moment documentation is easiest and most accurate.
When documentation is deferred, it almost never gets done properly. Systems evolve, quick fixes accumulate, and exceptions become normal. Before long, even the original implementer no longer remembers why something was configured the way it was.
At that point, documenting the system becomes a reconstruction exercise rather than a record. And most teams, already under pressure, simply never circle back.
When Things Break, Documentation Is the Difference
Incidents have a way of exposing uncomfortable truths.
Without documentation:
-
Team members unfamiliar with the concept waste time discovering basic architecture under pressure.
-
Changes are made without understanding downstream impact.
-
Recovery relies on siloed knowledge and luck.
-
Root cause analysis becomes speculation rather than fact.
With documentation:
-
Teams can act decisively rather than cautiously.
-
New responders can contribute immediately.
-
Fixes are safer, faster, and more targeted.
-
Lessons learned actually stick.
The difference is not just operational. It is reputational. Senior management and clients do not care how complex your environment is. They care how quickly and confidently you restore service.
Undocumented Systems Do Not Scale
As organisations grow, undocumented environments become an anchor.
New hires take longer to onboard, external partners struggle to integrate, and auditors will ask questions that cannot be answered cleanly or with any semblance of confidence. Security reviews stall because no one can confidently describe data flows, trust boundaries, or system ownership.
What once felt like a time-saving shortcut becomes a barrier to growth, compliance, and resilience.
This is particularly dangerous in regulated or high-growth environments, where clarity and accountability are not optional extras, but are essential components.
Documentation Is Not Bureaucracy
There is a persistent myth that documentation is about creating work for its own sake. In reality, good documentation is practical, lightweight, and purpose driven.
It answers simple but critical questions:
-
What is this system?
-
Why does it exist?
-
How does it fit into the wider architecture?
-
Who owns it?
-
What happens when it fails?
That is not bureaucracy. That is operational hygiene.
Final Thoughts
A lack of documentation is rarely noticed when things are calm but will become painfully visible when they are not.
The organisations that struggle most during incidents, audits, or periods of rapid change are almost always the ones that assumed knowledge was enough. It never is.
At Phenomlab, this is a recurring theme in environments that are otherwise well engineered. Systems work, until they don't. And when they fail, the absence of clear documentation turns manageable problems into prolonged crises.
Phenomlab helps organisations put structure, clarity, and resilience back into their technology estates. That includes pragmatic system documentation that supports operations, security, compliance, and growth without becoming shelfware.
Because "I'll do it later" is not a strategy. And knowing something inside out only helps if you are always there - and we all know that just isn't the case.
