Die zwei Wahrheiten

Technische Projekte scheitern an falschen Wahrheiten

Es fühlt sich an, als würden zwei Spezies miteinander reden. Und genau das passiert auch. Es ist kein technisches Problem, es ist ein linguistisches und philosophisches Problem. Wir nutzen dieselben Wörter („Wahrheit“, „Ziel“, „Problem“), operieren aber auf völlig inkompatiblen Betriebssystemen.

Um diesen Deadlock zu verstehen – und vielleicht zu lösen – müssen wir nach Osten schauen. Russland und Japan haben Konzepte entwickelt, die präziser beschreiben, was in unseren Sitzungszimmern schiefläuft, als jedes agile Manifest.

Die zwei Wahrheiten

Wir blicken hier nicht auf die aktuelle Geopolitik, sondern auf das intellektuelle Narbengewebe einer Kultur. Von Dostojewski bis Kasparov zeichnet die großen Denker des Ostens eine mentale Härte aus, die wir im Westen oft verloren haben.

Diese Härte ist kein Zufall, sondern ein Überlebensmechanismus. Ob unter den Zaren, im Stalinismus oder in Putins lupenreiner Kleptokratie: Das System war stets darauf ausgelegt, den Einzelnen zu brechen oder zu korrumpieren. Der sibirische Winter ist einfach nur kalt – das ist Physik, damit kann man umgehen. Aber ein totalitäres Regime versucht aktiv, dich zu vernichten.

Unter diesem enormen Druck entstand eine notwendige sprachliche Präzision: Die strikte Trennung zwischen der staatlich verordneten Lüge und der faktischen Realität. Ein Werkzeugsatz, der unser modernes Management-Dilemma besser beschreibt als jedes westliche Lehrbuch:

• Istina (Истина): Die objektive, faktische Wahrheit. Sie ist universell. $1 + 1 = 0$, zumindest im $\mathbb{F}_2$. Die Gesetze der Thermodynamik machend das Wetter. Istina kümmert sich nicht um deine Gefühle, deinen Bonus oder deine Quartalsziele. Sie ist.
• Pravda (Правда): Die soziale oder moralische Wahrheit. Die „Gerechtigkeit“ im Sinne einer Gruppe oder Ideologie. „Unsere Strategie ist alternativlos.“ „Wir sind Marktführer.“ Pravda ist ein Narrativ, das eine Gruppe zusammenhält.

Der Konflikt im Meeting: Die Engineers sind Botschafter der Istina. Wenn sie sagen „Das System stürzt ab“, ist das ein Faktum. Das Management operiert im Modus der Pravda. Für sie ist die „Wahrheit“, dass das Projekt erfolgreich sein muss, weil es strategisch wichtig ist. Wenn ein Engineer nun Istina („Geht nicht“) in den Raum wirft, greift er die Pravda („Wir sind ein erfolgreiches Team“) an. Er wird nicht als Warner gesehen, sondern als Verräter an der gemeinsamen Sache.

Das japanische Modul: Interface vs. Backend

Während die Russen die Art der Daten unterscheiden, unterscheiden die Japaner die Art der Übertragung. In der westlichen Firmenkultur gilt “Heuchelei” als schlecht, aber wir haben kein Wort für “notwendige Fassade”. Die Japaner schon.

• Honne (本音): Der wahre Klang. Das, was man wirklich denkt, fühlt und weiß. Das Backend, der ungeschminkte Code, die „Dirty Hacks“, die echten Risiken.
• Tatemae (建前): Die Fassade. Das, was man öffentlich zeigt. Das öffentliche API-Interface. Es dient dazu, soziale Reibung zu vermeiden und Harmonie zu wahren.

Der Absturz: Für einen Manager ist Tatemae überlebenswichtig. Er kann vor dem Vorstand nicht sagen: „Ich habe keine Ahnung, ob das klappt“, er muss sagen: „Wir sind zuversichtlich.“ Das Problem entsteht, wenn wir Engineers – oft radikal ehrlich oder autistisch veranlagt – unser Honne ungefiltert gegen das Tatemae des Managements feuern. Wir durchbrechen die Kapselung. Wir verursachen eine „Uncaught Exception“ im sozialen Protokoll des Meetings.

Debugging: Wie wir das Projekt retten

Hier stehen wir nun. Eine Handvoll Engineers, die Istina und Honne sprechen, gegen eine Übermacht an Managern, die Pravda und Tatemae sprechen. Eine demokratische Abstimmung über physikalische Fakten („Wer ist dafür, dass die Datenbank schneller ist?“) ist sinnlos, aber genau das passiert implizit.

Wie kriegen wir das Projekt wieder rund, ohne gefeuert zu werden?

A. Die „Pravda“-Injektion (Translation Layer) Wir müssen lernen, unsere Istina in ihre Pravda zu übersetzen. Statt: „Diese Architektur ist technisch Müll.“ (Angriff auf das Ego/Tatemae). Sagen wir: „Um das strategische Ziel der Kosteneffizienz (Pravda) zu erreichen, müssen wir die technische Schuldenlast senken, die uns sonst in Q3 das Budget zerschießt (Istina).“ Wir nutzen ihre Ziele, um unsere Fakten zu transportieren.

B. Nemawashi (根回し) – Das System patchen, bevor es bootet In Japan werden kritische Entscheidungen nie im Meeting getroffen. Man geht vorher zu jedem Stakeholder einzeln (Nemawashi = die Wurzeln vorbereiten). Für uns Introvertierte ist das anstrengend, aber effizient. Wenn du deine Bedenken im großen Meeting äußerst, zwingst du den Manager zum Gesichtsverlust. Wenn du es vorher unter vier Augen tust, kann er im Meeting die Lösung als seine Idee präsentieren. Das Ergebnis zählt: Das Projekt läuft.

C. Die Dokumentation als Schutzschild Manchmal ist die Übermacht der Pravda zu groß. Dann hilft nur die schriftliche Rückkehr zur Istina. Ein sauberes Ticket, eine E-Mail, ein Eintrag im Risk-Register. Nicht zynisch, sondern sachlich. „Risiko: Latenzprobleme bei >1000 Usern. Empfohlene Maßnahme: Architektur-Refactoring. Status: Abgelehnt durch Management am [Datum].“ Das ist git commit. Es sichert den Zustand der Wahrheit. Wenn das Projekt gegen die Wand fährt (und das wird es), hast du die Logs.

Fazit

Wir werden die 80% Manager nicht zu Hackern umerziehen. Sie brauchen ihr Tatemae, um in ihrer Welt zu überleben. Aber wir dürfen nicht aufhören, die Istina zu verteidigen. Denn am Ende des Tages, wenn das Marketing-Geschwurbel verhallt ist und die PowerPoints geschlossen sind, gilt nur noch eine Wahrheit: Kompiliert es, oder kompiliert es nicht?

Quellen und Links

• “On Bullshit” von Harry G. Frankfurt