Hauptgedanke

Beim Lesen der Dokumentation eines anderen Teams — eines Ablaufs zum Abschluss eines Einsatzes, einer Backup-Richtlinie — entdeckt man einen Fehler. Man weiß, was zu korrigieren wäre; es würde dreißig Sekunden dauern. Besser, man schlägt die Korrektur vor, als sie selbst vorzunehmen.

Wer den Fehler entdeckt, entscheidet nicht darüber, wo das Wissen endgültig seinen Platz hat. Das verantwortliche Team beurteilt, ob die Korrektur wirklich seinen Bereich beschreibt oder nur den Sonderfall dessen, der sie vorschlägt. Was der Leser für einen Fehler hält, kann eine Regel sein, die außerhalb seines eigenen Falls stimmt.

Warum das wichtig ist

Das verhindert, dass ein lokales Ergebnis stillschweigend zu einer allgemeinen Wahrheit wird. Eine direkte Korrektur sieht ganz nach einem Gefallen aus; sie kann aber eine Regel aus einem einzigen Blickwinkel umschreiben, ohne dass der Eigentümer davon weiß.

Es hält das Eigentümer-Team außerdem darüber auf dem Laufenden, was andere in seiner Dokumentation sehen — ein Signal, das eine stillschweigende Korrektur unterdrückt.

Nuancen und Grenzen

Die Regel setzt voraus, dass ein Vorschlag wenig kostet und bearbeitet wird. Bleibt er unbeantwortet, kehrt die Versuchung zurück, selbst zu korrigieren oder eine korrigierte Version zu sich zu kopieren — und die Regel bewirkt genau das, was sie vermeiden wollte.

Bei einem Tippfehler ohne inhaltliche Tragweite übersteigen die Kosten des Vorschlags das Risiko.

Offene Fragen

• Welche Bearbeitungsfrist muss ein Eigentümer-Team einhalten, damit der Vorschlag der direkten Korrektur vorgezogen wird?