RCA

Was ist Root Cause Analysis?

RCA steht für Root Cause Analysis und ist Phase 2 der TRANSFORM-Methodik. Sie folgt unmittelbar auf Triage und beantwortet eine präzise Frage: Welche tieferen Muster, Glaubenssätze und unbewussten Entscheidungen haben den Exoskeleton Bloat überhaupt zugelassen? Ohne diese Phase werden alle folgenden Architektur-Änderungen nur Symptome behandeln — das System regeneriert denselben Zustand innerhalb weniger Monate.

RCA ist keine Psychotherapie. Sie ist Logfile-Debugging auf der Ebene unbewusster Entscheidungslogik.

Wie funktioniert das?

Die RCA läuft iterativ über die klassische Warum-Kette:

Was war der Auslöser? Welches konkrete Ereignis hat den überlasteten Zustand sichtbar gemacht?

Warum hat das System so reagiert? Welche Regel, welcher Automatismus war aktiv, als die Belastung aufgenommen wurde?

Warum gibt es diese Regel? Welcher ältere, oft unbewusste Glaubenssatz produziert diese Regel? Häufig: „Wenn ich ablehne, verliere ich Ansehen." Oder: „Wenn ich nicht sofort antworte, werde ich übergangen." Oder: „Wenn ich etwas nicht mache, macht es niemand."

Warum existiert dieser Glaubenssatz? An welchem Punkt in der Biografie wurde er installiert? Welches Umfeld, welche frühere Rolle, welche Erfahrung hat ihn fest verankert?

Ist der Glaubenssatz heute noch gültig? Dies ist die entscheidende Frage. Viele Glaubenssätze waren in früheren Lebensphasen rational — sie sind nur in der heutigen Position nicht mehr passend.

Technisches Konzept und Lebens-Architektur

Im Software-Engineering ist RCA Standard nach jedem ernsten Incident. Das Ziel ist nicht, einen Schuldigen zu finden, sondern den Mechanismus zu verstehen, der den Fehler ermöglicht hat. Die Annahme: Ein Bug, der zu einem Incident führt, ist meist nur ein Symptom eines tieferen Architektur-Problems oder einer fehlerhaften Annahme.

In der Lebens-Architektur ist der Ansatz identisch. Der Leader, der sich über einen überlasteten Kalender beschwert, hat keinen Kalender-Bug. Er hat eine Entscheidungsregel, die diesen Kalender produziert. People Pleasing ist eine solche Regel. FOMO ist eine solche Regel. Jede Regel sitzt auf einem Glaubenssatz, und jeder Glaubenssatz hat einen biografischen Ursprung.

Die RCA-Arbeit ist präzise, nicht mystisch. Sie produziert am Ende eine Liste identifizierter Glaubenssätze und die dazugehörigen Entscheidungsmuster — Material, das in der System Design-Phase in neue Regeln umgesetzt wird.

In der Praxis

Typische RCA-Ergebnisse bei Tech-Leadern:

• „Ich nehme jedes Meeting an, weil Sichtbarkeit gleich Sicherheit ist" — installiert in einer früheren Konzernrolle mit hoher politischer Dynamik.
• „Ich deligiere wichtige Aufgaben ungern, weil ich Verantwortung nicht abgeben kann" — installiert als Gründer, der alles selbst aufbauen musste.
• „Ich sage zu jeder neuen Idee ja, weil Innovation meine Marke ist" — installiert über Jahre der Selbstvermarktung als früher Adopter.

Jeder dieser Glaubenssätze war einmal rational und trug zum Erfolg bei. Heute, in anderer Rolle und Lebensphase, produziert er systemisch Bloat. Die RCA macht diesen Übergang sichtbar: Der Glaubenssatz muss nicht als „falsch" verurteilt werden, er muss als „nicht mehr passend" anerkannt und durch eine neue Regel ersetzt werden.

Häufige Fragen

Braucht man für RCA einen Coach oder Therapeuten? Nicht zwingend, aber ein Außen-Spiegel beschleunigt die Phase erheblich. Die eigenen Glaubenssätze sind per Definition transparent — man sieht sie nicht, weil man durch sie hindurchsieht. KI kann als Diagnose-Spiegel funktionieren, wenn sie präzise geprompted wird. Strukturierte Schreibverfahren helfen ebenfalls. Ein Coach mit technischem Verständnis ist der schnellste Weg.

Wie unterscheidet sich RCA von klassischer Selbstreflexion? Durch die Struktur. Klassische Reflexion ist offen und oft emotional zentriert. RCA ist zielgerichtet: Sie sucht die Regel hinter dem Bug, nicht das Gefühl hinter dem Moment. Beide haben ihren Ort, aber für Architektur-Arbeit ist RCA präziser.

Können Glaubenssätze sofort gepatcht werden? Nein, und das ist wichtig zu verstehen. Das Identifizieren eines Glaubenssatzes ist der erste Schritt; das Ersetzen durch eine neue Regel passiert erst in der Continuous Deployment-Phase. Ein identifizierter, aber nicht durch neue Struktur ersetzter Glaubenssatz aktiviert sich weiterhin — Einsicht allein patcht nichts.