Führung ist Systemdesign
Sobald Dokumentation über mehrere Teams verteilt ist, entsteht der Wunsch nach zentraler Kontrolle. Wenn jede Änderung durch einen Senior Editor muss, entsteht eine Warteschlange, Product Ownership wird unsichtbar und der Lead wird zum menschlichen Merge Conflict.
Die sinnvollere Aufgabe ist, Regeln zu entwerfen, durch die Routineänderungen ohne zentrale Intervention fließen und riskante Änderungen sofort erkennbar sind.
Mache Ownership sichtbar
Jeder Bereich braucht einen technischen Owner und einen klaren redaktionellen Weg. Das kann über Repository-Regeln, Metadaten oder Teamvereinbarungen erfolgen. Writers müssen wissen, wer Verhalten bestätigt; Engineers müssen wissen, wer die Erklärung pflegt.
Zentrale Pflichtreviews sind für bereichsübergreifende Auswirkungen, rechtliche oder sicherheitsrelevante Aussagen, gemeinsame Terminologie und große IA-Änderungen sinnvoll.
Standardisiere Schnittstellen, nicht jeden Satz
Definiere Content Types, Metadaten, Terminologie, Quality Gates und wiederverwendbare Components. Sie schaffen Konsistenz, ohne jede Seite gleich klingen zu lassen.
Wenn eine Regel wichtig ist, erkläre welches Problem sie verhindert und kodiere sie möglichst in Schema, Template oder Linter.
Baue Eskalationswege
Viele Konflikte sind keine Grammatikfragen, sondern ungeklärte Produktfragen: Was ist unterstützt? Wem gehört ein Endpoint? Was ist deprecated? Welche Zusage darf gemacht werden? Definiere, wo solche Fragen entschieden und dokumentiert werden.
Miss Flow und Risiko
Beobachte Review-Zeit, veraltete Inhalte, fehlerhafte Examples, kaputte Links, Suchprobleme und Release-Abweichungen. Seitenzahl ist kein Qualitätsmaß.
Gute Führung macht die Organisation weniger abhängig vom Lead. Das System muss auch funktionieren, wenn diese Person nicht da ist.
Praxisbeispiel
Nutze „Dokumentation führen, ohne Bürokratie aufzubauen“ als Teamübung statt als Liste von Rollen. Rekonstruiere bei einer aktuellen Dokumentationsaufgabe, wer den Nutzerbedarf erkannt, technische Fakten beschafft, die Struktur entworfen, geprüft und die nächste Revision übernommen hat.
Beschreibe beobachtbare Fähigkeiten:
- welches Problem jemand ohne Schritt-für-Schritt-Aufsicht übernehmen kann;
- mit welchen Fachleuten konstruktiv gearbeitet und widersprochen werden kann;
- welche Qualitätsrisiken vor der Veröffentlichung erkannt werden;
- welcher Dokumentationsprozess verbessert und nicht nur benutzt werden kann.
Ein gutes Berufsmodell zeigt, welches schwierigere Problem als Nächstes geübt werden sollte. Reine Labels wie „Junior“, „Senior“ oder „kommunikativ“ reichen dafür nicht.
Kurzer Redaktionscheck
- Führung ist Systemdesign. Sobald Dokumentation über mehrere Teams verteilt ist, entsteht der Wunsch nach zentraler Kontrolle.
- Mache Ownership sichtbar. Jeder Bereich braucht einen technischen Owner und einen klaren redaktionellen Weg.
- Standardisiere Schnittstellen, nicht jeden Satz. Definiere Content Types, Metadaten, Terminologie, Quality Gates und wiederverwendbare Components.
- Baue Eskalationswege. Viele Konflikte sind keine Grammatikfragen, sondern ungeklärte Produktfragen: Was ist unterstützt?
