The quick-version: This post introduces the mental model that anchors The Doc Landscape platform: documentation as part of a living knowledge system inside software companies. Instead of treating documentation as isolated writing tasks, it maps how product knowledge is created, shaped, versioned, and often lost — from early decisions and ephemeral conversations to formal reference content. The model provides the conceptual foundation for the platform, explaining why documentation must be understood as an interconnected system that supports development, onboarding, support, decision-making, and increasingly, automation.
The Doc Landscape started with a premise that felt true but wasn’t fully worked out: documentation is part of a living knowledge system.
It’s a useful framing. It reorients how you think about what documentation is for, and it pushes back against the idea that writing is something you do at the end of development and then move on from. But as a premise, it has a gap. If documentation is part of a knowledge system, that implies there’s a larger system it’s part of. And I hadn’t really drawn that system out.
So I did.
The diagram I’ve been building toward (the foundation of a new series launching on The Doc Landscape called The Living Knowledge System) maps the system that product knowledge actually moves through in a software company. Not all knowledge in a company. Not HR onboarding or sales enablement or anything else. Specifically the knowledge that’s born when a product is conceived and that evolves, or degrades, as the product does.
It has five lifecycle stages, three knowledge tiers, two flow directions, five audience types, and six structural gaps that show up in most companies whether they’ve thought about them or not.
I’m not going to reproduce all of it here. The diagram and the series landing page do that more clearly than prose would. But there are a few things that came into focus while building it that are worth naming.
Release-specific & Public-facing Documentation gets all the investment
Most organizations concentrate their tooling and process work in what I’ve been calling the “versioned knowledge tier”. These are the docs tied to specific releases, the API reference, the changelogs, the user guides. This is where the documentation development life cycle (DDLC) pipelines live, where CMS decisions get made, where review workflows exist. It’s the most visible tier because it’s directly tied to shipping.
The tiers on either side of it are largely ungoverned. Ephemeral knowledge, such as Slack threads, meeting decisions, and design rationale shared in a PR comment, disappears before anyone decides it was worth keeping. Not because it wasn’t valuable, but because there’s no pipeline to promote it into something durable.
And evergreen content, such as the architecture overviews, the foundational concept docs, and the onboarding guides, gets created carefully and then left to drift. Nobody retires it. Nobody audits it. It sits alongside current content with no signal that it may no longer be accurate.
Both of these are knowledge lifecycle problems, not writing problems. The content might be excellent. The system around it is missing.
Upstream knowledge is the most lost
Documentation teams typically enter the product lifecycle at Build: after discovery, after design, after the decisions that explain why something works the way it does have already been made in meetings that weren’t recorded, in Slack threads that have scrolled past, in Figma comments that nobody thought to preserve.
What’s left is the artifact. The spec, if there is one. The feature as built. The technical writer reconstructs context through SME interviews, compresses what took months to decide into a paragraph of background, and moves on.
This isn’t a failure of individual writers. It’s a structural problem. The knowledge that would make documentation genuinely explanatory — not just accurate, but useful in a way that helps someone understand rather than just execute — enters the system too late, if it enters at all.
The Pipeline is infrastructure, not the system
This one took me a while to articulate clearly. Docs-as-code practices (the enhanced view, anyway) and the documentation operations infrastructure are real advances in how documentation is produced and maintained. But they operate on one tier of a much larger knowledge system. They’re the CI/CD of documentation: a production and distribution infrastructure for a specific class of content.
Just as CI/CD doesn’t define a company’s engineering culture or its product strategy, the operations infrastructure doesn’t define its knowledge culture. A company can have a sophisticated documentation pipeline and still have a broken knowledge system, because the upstream capture is missing, because the downstream feedback loops don’t exist, because evergreen content is drifting without anyone responsible for it.
Documentation engineering, as a discipline, is concerned with the full system. DDLC is one layer within that. The distinction matters for how the field understands its own scope.
The series landing page has the full mental model, diagram and all.
Leave a Reply