FN 129: Der Problem-Lösungs-Glitch

Die Trennung von Problemdefinition und Problemlösung ist einer der elegantesten Glitches organisatorischer Betriebssysteme. Ein Protokoll, das auf dem Papier für Klarheit sorgt, im Maschinenraum aber vor allem die Zurechenbarkeit von Fehlschlägen regelt.

Produktmanager:innen definieren das Problem. Das Team löst es.

Hier wird ein Problem der komplexen Domäne, wo Ursache und Wirkung sich erst im Nachhinein erschließen und der Weg durch Experimente gefunden wird, fälschlicherweise wie ein Problem der komplizierten Domäne behandelt, wo eine Expertenanalyse zu einer korrekten Antwort führen kann.

Das Resultat ist ein organisationales Immunsystem gegen Veränderung. Das erklärte Ziel („Löse das Geschäftsproblem“) wird durch ein verborgenes, konkurrierendes Ziel sabotiert: „Vermeide persönliche Schuld“. Scheitert das Projekt, war entweder die Analyse unsauber (Schuld A) oder die Umsetzung mangelhaft (Schuld B). Das System ist fein raus. Seine Energie fließt in die Verteidigung der Schnittstelle, nicht in die Navigation des Terrains.

Kein Problem existiert isoliert. Jedes „Problem“ ist die Projektion einer übergeordneten Frage auf eine spezifische Ebene des Systems. Es ist der Versuch zentraler Steuerung, der Realität eine lesbare Form aufzuzwingen und das unordentliche, lokale Wissen der Front, ihre Mētis, in eine saubere Karte zu übersetzen.

Die Aussage „Unsere Enterprise-Deals dauern zu lange“ ist keine Problembeschreibung, sondern eine implizite Lösungshypothese. Sie ist der Versuch, einen einzelnen Parameter zu justieren, was zu den am wenigsten wirksamen Hebelpunkten in einem System gehört. Die Jagd nach der einen Wurzelursache ist oft eine Flucht vor der Erkenntnis, dass der wirksamste Hebel in der Veränderung der Systemregeln, der Informationsflüsse oder des übergeordneten Ziels liegt.

Das Kaliber des Problems definiert die notwendige Auflösung des Operators.

• Ein Team operiert effektiv mit der Direktive: „Verkürzt die Zeit zur Identifikation der Entscheider:innen.“ Das ist eine hohe Auflösung, ein klar definierter Auftrag im Rahmen der bestehenden Karte.
• Ein anderes Team zerlegt die ursprüngliche Hypothese: „Warum fokussieren wir auf Enterprise-Deals, wenn andere Segmente profitabler sind? Erhöht eine Beschleunigung nicht das Churn-Risiko?“ Diese Akteur:innen operieren mit einer geringeren Auflösung. Sie zoomen heraus, hinterfragen die Karte selbst und betreiben einen aktiven Prozess des Zweifelns und Verknüpfens, um die Welt erst verständlich zu machen.

Wenn ein System die zweite Art von Frage als „destruktiv“ oder „anstrengend“ labelt, ist das ein Signal. Es ist ein Symptom für geringe organisationale Ambiguitätstoleranz. Das System bestraft jene, die seine verborgenen Annahmen aufdecken, und züchtet eine Kultur der Fragilität, anstatt jene Antifragilität zu entwickeln, die durch Stress und Unsicherheit stärker wird.

Der Druck, ein Problem „sauber zu definieren“, ist eine Falle, die unsere eigene Kognition verstärkt. Unser schnelles, intuitives Denken bevorzugt kohärente Geschichten vor unsicheren Fakten. Ein „klar definiertes Problem“ ist eine solche Geschichte, in die wir uns verlieben, weil sie kognitive Leichtigkeit verspricht.

Diese Fixierung führt zur vorzeitigen Konvergenz. Wir einigen uns auf ein Problem, das definierbar erscheint, anstatt das wichtigste zu adressieren. Das System optimiert sich auf die Lösung von Problemen, die auf verfügbaren Informationen basieren und geringes persönliches Risiko bergen. Die entscheidende Operation ist die Kultivierung der Fähigkeit, unter Unsicherheit präzise zu handeln. Es gilt, eine Umgebung zu schaffen, in der Nicht-Wissen kein Bug, sondern ein Feature des Explorationsprozesses ist.

Fünf Manöver zur Rekalibrierung

Die Beobachtung des Glitches ist der erste Schritt. Die Fähigkeit, ihn zu neutralisieren, ist Agency. Hier sind fünf operative Manöver, um aus der Falle auszubrechen.

Manöver 1: Zerstöre die Dichotomie

Behandle die Trennung von Definition und Lösung als das, was sie ist: eine feindliche Doktrin. Sie zerreißt den Kreislauf aus Beobachtung, Orientierung, Entscheidung und Handlung in ineffektive Einzelteile. Eine Gruppe beobachtet und orientiert sich, übergibt dann eine starre Entscheidung an eine andere Gruppe, die nur noch handeln darf. Fusioniere die Verantwortlichkeiten, um einen schnellen, iterativen Kreislauf zu ermöglichen. Teams sind für den Fortschritt in einem bestimmten Terrain verantwortlich. Ihre Währung wird die erreichte Wirkung.

Manöver 2: Nutze die Lösung als Sonde

Höre auf, Lösungen dogmatisch zu vermeiden. Nutze schnelle, schmutzige Prototypen als Sonden, um das komplexe System zu stören und seine Reaktion zu beobachten. Ein Prototyp testet dein Verständnis des Problems. Die Reaktion des Systems auf die Sonde liefert mehr Daten als jede weitere Analyse im Vakuum. Das ist die praktische Anwendung des „Sondieren-Wahrnehmen-Reagieren“-Musters für komplexe Domänen.

Manöver 3: Kalibriere die Auflösung bewusst

Triff eine explizite Entscheidung, auf welcher Flughöhe du operierst. Zoomst du hinein, um ein Teilproblem zu exekutieren, oder zoomst du heraus, um die Karte selbst zu validieren? Beides ist legitim, aber die Verwechslung der Ebenen erzeugt Reibung. Mache die aktuelle Flughöhe zum expliziten Gegenstand des Gesprächs.

• Hohe Auflösung (Zoom-in): „Wir akzeptieren Hypothese X und optimieren jetzt Variable Y.“
• Niedrige Auflösung (Zoom-out): „Wir stellen Hypothese X infrage und suchen nach alternativen Pfaden zum übergeordneten Ziel Z.“

Manöver 4: Wechsle vom Problem- zum Möglichkeitsraum

Das Wort „Problem“ impliziert einen Mangel, der behoben werden muss. Sprich stattdessen von Möglichkeiten, die erkundet oder genutzt werden. Diese sprachliche Verschiebung verändert die psychologische Dynamik von Schuldvermeidung hin zu gemeinsamer Entdeckungsreise.

Manöver 5: Kartiere das Terrain, nicht den Plan

Nimm das Chaos an. Visualisiere das Netz der Annahmen, Hypothesen und Abhängigkeiten. Der Zweck einer solchen Karte ist es, ein gemeinsames mentales Modell zu schaffen, eine Arena für einen gehaltvollen Dialog. Sie fokussiert das Gespräch auf die Verbindungen zwischen den Elementen des Systems und macht die kollektive Mētis des Teams sichtbar und nutzbar.