LinkedIn newsletter
Cut Complexity — Create Clarity
Technical Writing is Complexity made clear
My newsletter on LinkedIn about how technical writers structure complexity: thinking models, information design, machinery documentation, safety communication and structured content.
The issues are written in English. New issues appear on Saturdays at 9 p.m. Central European Time.
Archive
All issues
Each card shows the original title, a short summary written for this page and the focus areas the issue relates to. The links lead to the issues on LinkedIn.
Filter by focus area
No issues match this focus area.
-
Before you draw: how to choose the right model for technical information
Before an infographic is drawn, the relationships it shows have to be understood. A fictional sensor example shows how arrows can turn two independent conditions into a false causal chain, and how technical writers identify elements, conditions and relationships first.
-
Rated for what? Understanding machine limits in Technical Documentation
A machine specification describes a capability under defined conditions. Using a fictional CNC machining example and Tom Johnson’s knowledge triangle, the issue shows how published limits such as axis travel become instructions that support the decision in front of the reader.
-
Why Technical Writers need to understand IT, OT, and IoT
IT, OT and IoT answer different questions and overlap in practice. The issue gives technical writers a working model of the three terms, based on NIST definitions, and shows how it helps to make system boundaries, user actions and their consequences clear.
-
The AI has feelings — please submit a ticket
A satirical meeting in which four separate questions about AI consciousness end up as a single policy statement. Notion AI wrote the scene based on the AI TechDoc Knowledge context card “Claims about AI consciousness: four questions that get merged”; the satire targets administrative certainty, not the research.
-
How documentation takes shape in the writer's head and works in the reader's mind
A correct procedure can still fail at the moment of use. The issue links two AI TechDoc Knowledge blueprints, “Thinking models for technical writers” and “Cognitive psychology for technical communication,” and looks at the writer’s stack, which structures the documentation problem, and the reader’s stack, the cognitive work of the person using the document.
-
Every page is page one for online machine documentation
An online operating manual does not have to be read from the first page. Based on Mark Baker’s concept Every Page is Page One, the issue describes one complete information space with several valid routes through it, for example via a QR code on the machine, a fault code or a specific subsystem.
-
Prioritizing user needs makes user manuals better
User manuals become clearer when they follow what users do rather than how the product is built. The issue sets out task orientation as a core principle and shows how product logic creates complexity and separates risks from the steps where they matter.
-
Beyond DITA: How AI is redrawing the structured content market
The debate about DITA often sounds like a yes-or-no decision. The issue separates three approaches to structured content — the XML/CCMS world, semantic content engineering and docs-as-code — and shows which differences between them AI makes visible.
-
Research skills for Technical Writers
In R&D-driven organizations, the problem is rarely a lack of information but a lack of structured, traceable information. The issue describes research skills for working with internal R&D sources and supplier documentation, including AI tools, organizational systematics and research logs.
-
Where documentation responsibility ends
In integrated machinery systems, writing the manual is a boundary task. The issue shows where OEM documentation remains authoritative, what the manufacturer of the integrated system adds, which obligations lie with the operator, and that a CE mark for the whole system does not remove the documentation boundaries of the individual machines.
-
Operating modes in machinery user manuals
Safety information in machinery user manuals has to follow the real operating context. The issue connects the operating concept for each lifecycle phase with the safety concept for each operating mode: user profile, workstation, effective safeguards, responsibility boundary and remaining risk.
-
The Technology Lens Model
The Technology Lens model distinguishes deterministic technology, decision-driven control logic and the operating mode in which both are active. The issue shows how this distinction helps technical writers decide what to explain, what to warn against and where safety-relevant information belongs in the manual.
-
Hazard thinking in Operating Instructions
A warning is the visible result of a deeper analysis. The issue presents a structured approach to hazards in operating instructions: intended use, residual risks, reasonably foreseeable misuse, prohibited actions and hazards arising from the machine’s environment.
-
Mental models for better context
Technical writing begins with understanding, not with text. The issue describes how mental models help technical writers structure scattered input from engineering, risk assessments, standards and legacy documentation before they write.
-
Thinking Models for Technical Writers
Many documentation problems come from unclear thinking rather than from tools. The first issue introduces five thinking models, among them component, variant and metadata thinking, that work in any tool landscape, from a CCMS to a network folder.
LinkedIn shows its own recommendations on article pages, including articles by other authors. They are not part of this newsletter.
My other newsletter on LinkedIn: Write it Safe. Prove it Safe.