Das System, das nur eine Person versteht

5 Min. Lesezeit

Die Namen, die jeder kennt

Der Experte ist meist nicht das Problem

Wissen konzentriert sich, weil es schneller ist, den Experten zu fragen, als sein Urteilsvermögen weiterzugeben. Er behebt den Produktionsfehler, erklärt die Ausnahme bei der Abrechnung und rettet das Release. Die Arbeit geht weiter. Das Dashboard bleibt grün. Jede Rettung lässt die Abhängigkeit normal aussehen.

Das Risiko versteckt sich meist in langweiligen Geschäftsregeln: Finanzberechnungen, Ausnahmen beim Onboarding, alten Verarbeitungsläufen, Migrationsskripten, Integrationen oder Tabellenlogik, die still und leise zur Infrastruktur wurde. Wenn niemand die Komponentenbibliothek versteht, beschwert sich das Team und repariert sie. Wenn niemand versteht, was Kunden schulden, verhandelt das Unternehmen auf Basis von Vermutungen mit der Realität. Die Realität ist nicht für großzügige Zahlungsziele bekannt.

Machen Sie den Urlaubstest

Kann diese Person zwei Wochen Urlaub nehmen, ohne dass das Team stillschweigend seine Ambitionen senkt?

Nicht: „Kann das Unternehmen überleben?“ Überleben ist kein hoher Anspruch. Fragen Sie, ob die normale Arbeit sicher weitergehen kann:

• Kann jemand anderes das Deployment übernehmen?
• Kann jemand anderes die kritische Geschäftsregel erklären und verändern?
• Lässt sich ein Vorfall untersuchen, ohne erst die Vergangenheit in Gesprächen zu rekonstruieren?
• Kann ein neuer Entwickler in diesem Bereich ohne ständige persönliche Anleitung arbeiten?

Wenn die Antwort immer wieder Nein lautet, ist der Urlaubskalender Teil der Architektur. Mehr Menschen in dieses Labyrinth einzustellen, schafft keine Karte. Es verlängert nur die Warteschlange für Wegbeschreibungen.

Dokumentation ersetzt kein Urteilsvermögen

Sie brauchen wahrscheinlich bessere Dokumentation. Sie müssen aber auch aufhören, so zu tun, als könne sie die ganze Last tragen.

Ein Dokument kann erklären, dass eine Finanzberechnung einer bestimmten Regel folgt. Es kann nicht automatisch vermitteln, wann diese Regel bei einem migrierten Kunden falsch ist, warum die Ausnahme existiert, welcher nachgelagerte Bericht den Fehler anzeigen wird und welches Risiko das Unternehmen akzeptiert, wenn die Zahl später korrigiert wird.

Dieses Urteilsvermögen entsteht bei der Arbeit am echten System. Jemand anderes untersucht das Problem. Der Experte erklärt das Warum, nicht nur das Was. Gemeinsam ergänzen beide einen Test, eine Schutzvorkehrung oder einen klareren Entwurf. Dann nimmt die andere Person die nächste Änderung mit weniger Hilfe vor.

Urteilsvermögen durch die Arbeit weitergeben

Beginnen Sie mit einem kritischen Bereich, in dem immer wieder derselbe Name fällt. Machen Sie die nächste riskante Änderung zu gemeinsamer Arbeit. Lassen Sie jemand anderen den Code schreiben, untersuchen, deployen oder das System wiederherstellen. Machen Sie aus einer wiederkehrenden Erklärung einen ausführbaren Test. Halten Sie das Review klein genug, dass eine andere Person es wirklich versteht.

Pairing, TDD, CI/CD, Trunk-based Development und echte Code-Reviews sind hier kein Methodenschmuck. Sie sind Mechanismen für Wissenstransfer. Pragmatisch eingesetzt bringen sie Urteilsvermögen in die tägliche Arbeit und verkürzen den Weg von der Annahme zum Beleg. Zeremoniell eingesetzt sind sie nur weitere Meetings und Etiketten.

In der ersten Pairing-Session wird eine riskante Änderung zum Mittel für den Wissenstransfer. Eine Person schreibt den Code, eine andere erklärt und weitere prüfen. Der Fehler ist nützlich, weil er verborgene Annahmen ans Licht zwingt.

Wenn das Team den nötigen Freiraum nicht allein schaffen kann, stellen Sie eine erfahrene Person an die Seite des Experten und des CTO. Ihre Aufgabe besteht darin, im Code, im tatsächlichen Arbeitsfluss und im Betrieb mitzuarbeiten, bis die Abhängigkeit schrumpft – nicht darin, mit einem Dokumentationsprogramm und dem nächsten Vorgehensmodell aufzutauchen.

Das stille Veto gegen Veränderung

Wissenskonzentration gibt alten Systemen schließlich ein Veto. Es tarnt sich als Vorsicht: „Das sollten wir vor Quartalsende nicht anfassen.“ „Dieser Bereich ist riskant.“ „Wir müssen warten, bis Martin zurück ist.“

Die Roadmap beginnt, alles zu umgehen, was das Unternehmen nicht versteht.

Das sind die wirklichen Kosten. Das Unternehmen beginnt, strategische Entscheidungen innerhalb der Grenzen dessen zu treffen, woran sich einige wenige Menschen noch erinnern. Eine Vorschrift ändert sich, eine Schlüsselperson geht oder ein KI-Projekt soll einen Prozess automatisieren, den niemand erklären kann – und aus Vorsicht wird Stillstand.

Machen Sie nicht die Menschen verantwortlich, die das System am Laufen gehalten haben. Ändern Sie das System, das sie dauerhaft zu Rettern gemacht hat.