concepts

Mental Models

Mentale Modelle sind tief verankerte Annahmen im Kopf, die bestimmen, welche Systemsignale wir überhaupt wahrnehmen und wie wir Entscheidungen treffen.

teamsorganization·3 min Lesezeit

Was ist das?

Mentale Modelle sind tief verankerte Annahmen im Kopf, die bestimmen, welche Systemsignale wir überhaupt wahrnehmen und wie wir Entscheidungen treffen.

Warum relevant?

Nutze dieses Konzept, um beobachtbares Verhalten nicht nur zu benennen, sondern strukturell zu erklären.

Nächster Schritt

Prüfe danach, welcher Archetyp oder welche Diagnose das Muster im konkreten System sichtbar macht.

~4 Min. Lesezeit

Definition

Mentale Modelle sind die tief in uns verwurzelten Bilder, Annahmen und Verallgemeinerungen darüber, wie die Welt (oder ein Softwaresystem) funktioniert. Sie wirken wie ein unsichtbarer Filter: Alles, was wir sehen, hören oder messen, wird durch unser mentales Modell interpretiert. Im Systemdenken sind mentale Modelle von zentraler Bedeutung, weil Entscheidungen nie auf Basis der "echten" Realität getroffen werden, sondern immer auf Basis des mentalen Modells, das ein Entscheider (oder Architektur-Team) von der Realität im Kopf hat.

Systemmechanismus

Mentale Modelle steuern unser Handeln. Unser Handeln erzeugt Ergebnisse im System. Wenn das System jedoch komplex ist, passen die tatsächlichen Ergebnisse oft nicht zu unserem vereinfachten mentalen Modell. Anstatt nun das Modell anzupassen, reagieren viele Organisationen mit "Defensivroutinen" (Abwehrmechanismen) und versuchen, das System gewaltsam an ihr Modell anzupassen. Dies erzeugt extrem hohe Reibungsverluste und verhindert jede echte Adaptation.

Architekturbeispiel

Ein Architekt hat das mentale Modell: "Microservices sind immer die beste Lösung für Skalierung." Ein Team baut daraufhin eine einfache interne CRUD-App mit 12 Microservices. Die App ist ständig instabil, die Deployments dauern Stunden. Das Feedback des Systems lautet: "Das war die falsche Architektur für dieses Problem." Da das mentale Modell des Architekten dies aber nicht zulässt, interpretiert er das Feedback stattdessen als: "Die Entwickler sind nicht diszipliniert genug mit ihren Kubernetes-Manifesten." Das fehlerhafte mentale Modell blockiert das System-Lernen.

Organisationsbeispiel

Das Management-Team vertritt das mentale Modell: "Mitarbeiter arbeiten nur dann hart, wenn man sie streng mit individuellen Zielen (MBOs) kontrolliert." Wenn die Software-Qualität nun sinkt, ist die logische Reaktion (aus Sicht ihres Modells), die individuellen KPIs und Strafen zu verschärfen. In der Realität leidet die Qualität aber unter fehlender Team-Zusammenarbeit (die durch individuelle KPIs systematisch zerstört wird). Das mentale Modell des Managements verschlimmert den Systemzustand aktiv.

Diagnosefragen

1.Welche unbewiesenen Grundannahmen ("Das ist hier einfach so", "Tech-Stack X ist immer besser") steuern aktuell unsere teuersten Entscheidungen?

2.Wo werden Messdaten oder Feedback von Nutzern regelmäßig ignoriert oder uminterpretiert, weil sie nicht in "unseren Plan" passen?

3.Gibt es im Team Rituale, um die Köpfe zusammenzustecken und zu prüfen, ob alle das gleiche mentale Bild vom Systemverhalten haben?

Diagramm

Warum dieses Konzept in Architektur hilft

Einer der stärksten Hebelpunkte (Leverage) in Organisationen ist das Offenlegen und Anpassen mentaler Modelle. Solange ein Team glaubt, dass Geschwindigkeit und Qualität ein "Entweder-Oder" sind (fehlerhaftes Modell), wird es niemals in Test-Automatisierung investieren. Erst wenn das Modell zu "Qualität treibt nachhaltige Geschwindigkeit" wechselt, ändern sich die Entscheidungen radikal. Diesen Wechsel erzwingt man am besten durch das gemeinsame Zeichnen von Causal Loop Diagrams.

Woran du das Konzept von ähnlichen Themen unterscheidest

Im Gegensatz zu *Feedback Loops* oder *Delays*, die mechanische Eigenschaften eines Systems beschreiben, sind Mentale Modelle Eigenschaften der *Akteure* innerhalb des Systems. Sie sind das Bindeglied zwischen objektiver Realität und subjektiven Architekturentscheidungen.

Wie du das Konzept praktisch nutzt

Mach das Unsichtbare sichtbar. Wenn zwei Senior Engineers erbittert über eine Datenbank-Technologie streiten, streiten sie selten um Fakten, sondern um konkurrierende mentale Modelle (z.B. "Datenkonsistenz ist das Wichtigste" vs. "Time-to-Market ist das Wichtigste"). Hol die Diskussion auf diese Meta-Ebene. Zwingt euch, eure zugrunde liegenden Annahmen explizit (z.B. in ADRs) aufzuschreiben.

Erste Umsetzungsschritte

Verwende Formate wie den "Ladder of Inference" (Schlussfolgerungsleiter), um in Meetings nachzuvollziehen, wie jemand von reinen Daten zu extrem starken Überzeugungen und Annahmen gekommen ist, bevor diese zur Basis von Systementscheidungen werden.

Woran du Wirkung erkennst

Wurde bei der letzten Architektur-Debatte geklärt, welche Annahmen als unumstößliche Fakten behandelt werden, obwohl sie eigentlich testbare Hypothesen sind?