
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…

Docs-as-code has two versions in circulation and they rarely get distinguished. The narrow one says: write in plain text, use Git, work like an engineer. The broader one says: bring structure, rigor, and shared ownership to documentation work, using whatever tools best serve that goal.

Technical writers depend on cross-functional communication more than almost any other role in software. In distributed teams, that communication breaks down in different ways.

If documentation is now part of a living knowledge system, then the role responsible for it has to evolve as well. The shift happening in documentation work isn’t just about new tools or faster workflows. It reflects a deeper change in how documentation is understood.

Documentation today is no longer created, published, and consumed in isolation. It’s more like tossing a message in a bottle into the ocean, except the ocean is your organization, the bottle might get opened by an AI, and someone three departments over is using your carefully worded explanation to answer a question you never imagined.

For a long time, documentation followed software. Products were designed, built, and shipped. Then documentation came afterward. Today, software is designed and built while documentation is created in parallel, and both ship together. Documentation is no longer cleanup work. It’s part of delivery.