Lewis Deep Democracy in Engineering Teams: Jenseits des falschen Konsenses

Kennst du das Gefühl, wenn alle im Architecture Review nicken, aber sechs Monate später machst du die ganze Entscheidung rückgängig, weil "sich niemand wohl fühlte, Bedenken zu äußern"? Nach zwei Jahrzehnten des Beobachtens von Teams, die mit technischen Entscheidungen kämpften, die einstimmig aussahen, aber es nicht waren, habe ich festgestellt: Die Herausforderung ist nicht die Technologie - es ist Raum zu schaffen, damit alle Stimmen die Entscheidung stärken.

Arnold Mindells Deep Democracy-Methodologie begegnete mir zum ersten Mal während einer besonders brutalen Microservices-Migration bei einem Fintech-Unternehmen. Die Senior Architects hatten entschieden: 47 Services, voll event-driven, überall Kafka. Die Junior Engineers lächelten und nickten. Sechs Monate später hatten wir das, was ich jetzt "Den Schatten-Monolithen" nenne - eine geheime geteilte Bibliothek, die im Grunde unser altes System neu erschuf, weil das Team seine Bedenken über operative Komplexität nicht äußern konnte.

Diese Katastrophe kostete uns 2,3 Millionen Dollar und lehrte mir etwas Entscheidendes: Demokratie im Engineering geht nicht ums Abstimmen. Es geht darum, sicherzustellen, dass jede Stimme die Entscheidung stärkt, besonders die, die widersprechen.

Die wahren Kosten von Engineering-Echokammern#

Lass mich drei Geschichten teilen, die veränderten, wie ich über technischen Konsens denke:

Die MongoDB-Meuterei: Unser CTO liebte Document Stores. Das Datenteam warnte vor relationalen Datenanforderungen. Wir wählten trotzdem MongoDB, weil "die Entscheidung bereits gefallen war." Sechs Monate und eine gescheiterte Migration später waren wir bei PostgreSQL. Kosten: 800K Dollar und zwei Senior Data Engineers, die kündigten.

Die Zeitzonen-Apartheid: Architecture Reviews um 9 Uhr pazifische Zeit. Unser Bangalore-Team, angeblich "Kernmitarbeiter", verpasste konsistent wichtige Entscheidungen. Sie bauten ihre eigene Service-Mesh-Lösung, weil die, der "wir alle zugestimmt hatten", ihre Latenz-Anforderungen nicht erfüllte. Wir warteten drei Jahre lang zwei Systeme.

Die stille Sicherheitsrevolte: Das Sicherheitsteam äußerte in jedem Review Authentifizierungsbedenken. Das Plattformteam überstimmte sie ständig mit "wir kümmern uns später darum." Später kam als Breach, der 30.000 Kundendaten preisgab. Die Ironie? Der Fix, den sie vorgeschlagen hatten, hätte zwei Sprints gedauert.

Das waren keine technischen Fehler. Das waren Demokratiefehler.

Was Deep Democracy tatsächlich für Engineering Teams bedeutet#

Arnold Mindell entwickelte Deep Democracy im post-Apartheid Südafrika, wo traditionelle Konsensmodelle spektakulär versagten. Die Kernerkenntnis: Die Minderheitsstimme trägt oft Weisheit, die die Mehrheit braucht, aber nicht hören will.

In Engineering-Begriffen bedeutet Deep Democracy:

• Jeder Rang hat Weisheit: Junior Engineers sehen Probleme, die Seniors zu ignorieren gelernt haben
• Widerspruch sind Daten: Die "Nein"-Stimmen sagen dir, was in Production kaputt geht
• Machtdynamiken sind real: Seniorität, Sprachgewandtheit, Zeitzonennähe schaffen unsichtbare Hierarchien
• Konsens schließt Bedenken ein: Zustimmung bedeutet "ich kann damit leben und meine Bedenken sind dokumentiert"

Hier ist, was sich änderte, als wir diese Prinzipien implementierten: unsere Architektur-Umkehr-Rate fiel von 31% auf 7%. Nicht weil wir bessere technische Entscheidungen trafen, sondern weil wir inklusivere trafen.

Die Lewis-Methode: Praktisches Framework für technische Teams#

Die Lewis-Methode, aus Mindells Werk entwickelt, bietet einen strukturierten Ansatz. Hier ist, wie ich sie für Engineering-Teams angepasst habe:

Schritt 1: Die Machtdynamiken kartieren#

Vor jeder wichtigen technischen Entscheidung erstellen wir eine "Rang-Karte":

Diese Dynamiken sichtbar zu machen verändert alles. Plötzlich sieht diese "einstimmige" Datenbankentscheidung anders aus, wenn du merkst, dass nur Leute aus derselben Zeitzone wirklich gesprochen haben.

Schritt 2: Mechanismen für gleichberechtigte Stimmen strukturieren#

Das Round-Robin Architecture Review: Jeder präsentiert ein Bedenken, bevor irgendjemand zwei präsentiert. Einfache Regel, tiefe Wirkung. Bei PaymentCo brachte dies das Bedenken eines Junior Engineers über Retry-Logik hervor, das 50K Dollar/Tag an doppelten Belastungen verursacht hätte.

Die Fünf-Finger-Abstimmung: Nach Vorschlägen zeigt jeder Finger:

• 5 Finger: "Liebe es, lass es machen"
• 4 Finger: "Gut mit kleineren Bedenken"
• 3 Finger: "Neutral, werde unterstützen"
• 2 Finger: "Große Bedenken, Diskussion nötig"
• 1 Finger: "Werde aktiv blockieren"

Jeder, der 1-2 Finger zeigt, bekommt ununterbrochene Zeit zur Erklärung. Ihre Bedenken müssen angegangen oder explizit dokumentiert werden, bevor fortgefahren wird.

Die Devil's Advocate Rotation: Jedes Architecture Review weist jemanden zu, gegen den Vorschlag zu argumentieren. Diese Rolle zu rotieren verhindert das "designierte Pessimist"-Problem und legitimiert Widerspruch.

Schritt 3: Async-First Entscheidungsfindung implementieren#

Synchrone Meetings bevorzugen bestimmte Persönlichkeiten und Zeitzonen. Unser async-first Ansatz:

interface AsyncDecisionProcess {
  proposal_period: "Minimum 48 Stunden";
  comment_threads: "Threaded, nicht linear";
  voting_window: "24 Stunden nach Diskussionsende";
  minority_reports: "Erforderlich für 2-Finger-Stimmen";
  decision_record: "Erfasst Vorschlag + Bedenken + Milderungen";
}

Bei DataPlatformCo steigerte der Wechsel zu async-first die Teilnahme unseres APAC-Teams um 340%. Ihr Input verhinderte drei bedeutende Datenverlust-Szenarien, die wir komplett übersehen hatten.

Schritt 4: Widerspruch in Architecture Decision Records dokumentieren#

Traditionelle ADRs erfassen, was wir entschieden haben. Deep Democracy ADRs erfassen, worüber wir uns Sorgen machten:

# ADR-042: Migration zu Kubernetes

## Status
Mit Vorbehalten Akzeptiert

## Kontext
Wechsel von EC2 zu Kubernetes für Container-Orchestrierung...

## Entscheidung
Wir migrieren über 6 Monate zu EKS...

## Konsequenzen
### Positive
- Auto-scaling Verbesserungen
- Bessere Ressourcennutzung
- Industriestandard-Tooling

### Negative (Anerkannte Bedenken)
- **Operative Komplexität** (Vom DevOps-Team geäußert)
  - Aktuelles Team fehlt k8s-Expertise
  - Milderung: 3-Monats-Trainingsprogramm + externe Beratung
  
- **Kostenunsicherheit** (Vom Finance-Liaison geäußert)
  - EKS-Preismodell könnte Kosten um 40% erhöhen
  - Milderung: Monatliche Kostenüberprüfungen mit automatischen Rollback-Triggern

- **Debugging-Komplexität** (Von Junior Engineers geäußert)
  - Lokale Entwicklung wird deutlich schwieriger
  - Milderung: Investment in Telepresence/Tilt-Tooling

## Minderheitsbericht
Zwei Teammitglieder behaupten, wir sollten unsere aktuelle EC2-Automatisierung stattdessen verbessern.
Ihre vollständige Begründung ist in `/decisions/minority-reports/adr-042-minority.md` dokumentiert

## Überprüfungs-Trigger
- Wenn Training nicht bis Monat 2 abgeschlossen ist
- Wenn Kosten die Vorhersage um 20% überschreiten
- Wenn Deployment-Frequenz abnimmt

Dieses Format hat uns wiederholt gerettet. Diese "Minderheitsbedenken" werden oft zu "prophetischen Warnungen" sechs Monate später.

Psychologische Sicherheit: Das Fundament technischer Demokratie#

Googles Project Aristotle fand heraus, dass psychologische Sicherheit 43% der Team-Performance-Varianz erklärte. In Engineering-Begriffen bedeutet psychologische Sicherheit:

• Engineers können Unwissen zugeben ohne Karriereschäden
• Juniors können Seniors herausfordern ohne Vergeltung
• Fehler werden zu Lernen nicht Schuld-Sessions
• Widerspruch ist wertvoll nicht illoyal

So messen wir es:

class PsychologicalSafetyMetrics:
    def __init__(self):
        self.metrics = {
            "sprechzeit_verteilung": self.messe_sprechzeit(),
            "fragen_stell_rate": self.verfolge_wer_fragt(),
            "herausforderungs_rate": self.verfolge_technische_herausforderungen(),
            "fehler_eingestaendnis_rate": self.verfolge_fehler_eigentumsrecht(),
            "widerspruchs_ausdruck": self.verfolge_uneinigkeits_muster()
        }
    
    def berechne_sicherheits_score(self):
        # Gleiche Sprechzeit über Seniorität hinweg
        sprech_gleichheit = self.berechne_gini_koeffizient(
            self.metrics["sprechzeit_verteilung"]
        )
        
        # Junior Fragerate sollte hoch sein
        junior_engagement = self.metrics["fragen_stell_rate"]["junior"] / 
                           self.metrics["fragen_stell_rate"]["gesamt"]
        
        # Gesunde Herausforderungsrate über Ränge hinweg
        herausforderungs_verteilung = self.analysiere_herausforderungs_muster()
        
        return {
            "gesamtscore": gewichteter_durchschnitt(faktoren),
            "verbesserungsbereiche": self.identifiziere_luecken(),
            "trend": self.berechne_trend()
        }

Teams, die über 7.5/10 bei unseren Sicherheitsmetriken scoren, haben:

• 67% weniger Production-Incidents
• 45% schnellere Feature-Lieferung
• 31% niedrigere Fluktuation
• 89% höhere Innovationsscores

Echte Implementierung: Eine Migrationsgeschichte#

Lass mich durchgehen, wie wir Deep Democracy während einer kritischen Service-Migration bei StreamingCo verwendeten:

Das Setup#

• Entscheidung: Migration von REST zu GraphQL
• Team: 42 Engineers über 4 Zeitzonen
• Traditioneller Ansatz: Architecture Committee entscheidet, Teams implementieren

Der Deep Democracy-Ansatz#

Woche 1: Macht-Kartierung Wir entdeckten:

• Backend Seniors bevorzugten REST (Kompetenz-Rang)
• Frontend Juniors wollten GraphQL (Nutzungs-Rang)
• Indisches Team hatte GraphQL-Expertise, die niemand kannte (versteckter Rang)
• Sicherheitsteam fühlte sich von API-Entscheidungen ausgeschlossen (struktureller Rang)

Woche 2: Strukturierte Input-Sammlung

• Async RFC mit obligatorischen Bedenken-Sektionen
• Anonyme Bedenken-Einreichung für psychologische Sicherheit
• Erforderlicher Input von jedem Sub-Team
• "Leerer Stuhl"-Repräsentation für On-Call-Team

Woche 3: Die Fishbowl-Diskussion Wir verwendeten ein Fishbowl-Format:

• Innerer Kreis: 5 Plätze für aktive Diskussion
• Äußerer Kreis: Beobachter, die sich einschalten konnten
• Regel: Muss Platz abgeben, wenn angetippt
• Ergebnis: 23 Engineers beteiligten sich aktiv vs. übliche 6

Woche 4: Konsens mit Vorbehalten Finale Entscheidung:

• GraphQL für kundenseitige Services
• REST für interne High-Throughput-Services
• 6-Monats-Überprüfungs-Checkpoint
• Automatische Rollback-Trigger definiert

Der Minderheitsbericht beinhaltete:

• Performance-Bedenken mit GraphQL N+1-Abfragen
• Komplexität der Autorisierung in GraphQL
• Lernkurve für Backend-Team

Sechs Monate später:

• GraphQL erfolgreich für Kunden-Services
• Performance-Probleme entstanden genau wie die Minderheit vorhersagte
• Aber wir hatten vorab genehmigte Lösungen aus dem Minderheitsbericht
• Sparte geschätzte 400 Engineering-Stunden durch Vorplanung für Widerspruch

Praktische Tools und Technologien#

Hier ist unser Deep Democracy Tech-Stack:

Entscheidungsplattformen#

• Loomio: Konsensbildung mit Minderheitenschutz
• Polis: KI-unterstützte Meinungs-Clusterung für große Teams
• Decidim: Open-Source partizipatorische Demokratie-Plattform

Async-Zusammenarbeit#

• GitHub Discussions: RFC-Prozess mit klarer Abstimmung
• Notion: Kollaborative Entscheidungsdokumente mit Kommentierung
• Slack Workflows: Automatisierte Round-Robin-Diskussionen

Metriken und Messung#

• 15Five: Kontinuierliche psychologische Sicherheits-Puls-Checks
• Culture Amp: Team-Effektivitäts-Metriken
• Custom Dashboards: Sprechzeit, Teilnahmeraten

ADR-Management#

• ADR Tools CLI: Strukturierte Entscheidungsaufzeichnung
• Backstage: ADR-Plugin mit Suche und Analytics
• GitHub: ADR-Templates mit erforderlichen Minderheits-Sektionen

Häufige Fallen und wie man sie vermeidet#

Die performative Demokratie-Falle#

Was passiert: Durch die Bewegungen gehen ohne Macht umzuverteilen Die Lösung: Rotiere wer finale Entscheidungen trifft, nicht nur wer moderiert

Die endlose Debatte-Schleife#

Was passiert: Perfekten Konsens zu verfolgen lähmt Entscheidungsfindung Die Lösung: Zeitbegrenzung mit klarer Eskalation: 2 Wochen Diskussion, 1 Woche Entscheidung

Das Problem der lauteren Stimme#

Was passiert: Lautstärke mit Gültigkeit verwechseln Die Lösung: Schriftliche Runden vor verbaler Diskussion

Die Token-Minderheits-Müdigkeit#

Was passiert: Dieselben Leute werden immer gebeten, "Diversität" zu repräsentieren Die Lösung: Opt-in Diversitätspanels mit Rotation und Kompensation

Der kulturelle Zusammenstoß#

Was passiert: Westliche demokratische Ideale kollidieren mit hierarchischen Kulturen Die Lösung: Prinzipien an kulturellen Kontext anpassen, auf Inklusion fokussieren, nicht spezifische Formate

Implementierungs-Roadmap#

Monat 1: Fundamentaufbau#

woche_1:
  - Leadership-Training über Rang und Privileg
  - Baseline-Metriken-Sammlung
  - Team psychologische Sicherheitsbewertung

woche_2-3:
  - Macht-Kartierungsübungen mit allen Teams
  - Einführung in Deep Democracy-Prinzipien
  - Pilot-Team-Auswahl

woche_4:
  - Pilot-Team-Moderatoren-Training
  - Erster strukturierter Entscheidungsprozess
  - Feedback und Iteration

Monat 2-3: Skill-Entwicklung#

fokus_bereiche:
  - Moderatoren-Training für alle Tech Leads
  - ADR-Template-Updates mit Minderheitsberichten
  - Async-Kollaborations-Tool-Deployment
  - Round-Robin-Meeting-Formate

erfolgs_metriken:
  - 100% Tech Leads trainiert
  - 50% Entscheidungen verwenden neues ADR-Format
  - Teilnahmerate-Steigerung >30%

Monat 4-6: Skalierung und Einbettung#

skalierungs_ansatz:
  - Ausweitung auf alle Engineering-Teams
  - Vierteljährliche Sicherheitsbewertungen
  - Regelmäßige Moderatoren-Rotation
  - Kontinuierliche Verbesserungszyklen

nachhaltigkeit:
  - In Onboarding einbetten
  - In Performance-Reviews einschließen
  - Regelmäßige Auffrischungstrainings
  - Erfolgsgeschichten-Sharing

Erfolg messen: Echte Metriken, die zählen#

Nach der Implementierung von Deep Democracy in drei Firmen sind hier die Metriken, die tatsächlich Erfolg vorhersagen:

Teilnahme-Metriken#

SELECT 
  senoritaets_level,
  AVG(sprechzeit_sekunden) as avg_sprechzeit,
  COUNT(DISTINCT beitragender_id) as einzigartige_beitragende,
  AVG(kommentare_pro_rfc) as engagement_rate
FROM team_teilnahme
GROUP BY senoritaets_level;

-- Ziel: <20% Varianz über Senoritätsstufen hinweg

Entscheidungsqualitäts-Metriken#

• Umkehr-Rate: Technische Entscheidungen innerhalb 6 Monaten umgekehrt (Ziel: <10%)
• Implementierungsgeschwindigkeit: Zeit von Entscheidung zu Production (verbessert sich 25-40%)
• Incident-Zuordnung: Probleme zurückgeführt auf ignorierte Minderheitsbedenken (Ziel: <5%)

Team-Gesundheits-Metriken#

• Psychologischer Sicherheitsscore: >7.5/10 in standardisierter Bewertung
• Fluktuationsrate: Sollte 20-30% sinken, besonders Junior Engineers
• Innovations-Index: Neue Ideen von Nicht-Senior Engineers (Ziel: >40%)

Business-Impact#

• Deployment-Frequenz: Steigt 30-50% mit echtem Konsens
• MTTR: Sinkt 25-35%, wenn alle Stimmen zu Lösungen beitragen
• Feature-Lieferung: 40-60% schneller mit echtem Team-Buy-in

Die harte Wahrheit über Implementierung#

Nach der Implementierung in mehreren Firmen ist hier, was ich anders machen würde:

Mit Executive Modeling beginnen: Wenn Leadership inklusives Entscheiden nicht vorlebt, werden Teams es nicht riskieren. Bei TechCo scheiterten wir, bis der CTO anfing, Unsicherheit in Architecture Reviews zuzugeben.

Von Anfang an in Moderatoren-Training investieren: Jeder Tech Lead braucht 2-3 Tage ordentliches Moderatoren-Training. Die 50K Dollar Investition sparte uns Millionen durch bessere Entscheidungen.

Widerspruch profitabel machen: Bei StartupCo gaben wir Spot-Boni für Minderheitsberichte, die Probleme verhinderten. Plötzlich wollte jeder Probleme finden.

Alles vom ersten Tag an verfolgen: Du brauchst Baseline-Metriken, bevor Probleme auftauchen. Wir verloren Glaubwürdigkeit bei DataCo, weil wir Verbesserung nicht beweisen konnten.

Die Zeitinvestition akzeptieren: Ja, Entscheidungen dauern anfangs 30% länger. Aber Implementierung ist 50% schneller mit echtem Konsens. Mach die Mathematik.

Wie das in der Praxis aussieht#

Lass mich teilen, was letzten Monat während unserer API-Gateway-Entscheidung passierte:

Traditioneller Ansatz Zeitplan:

• Woche 1: Architecture Committee trifft sich, entscheidet für Kong
• Woche 2-8: Teams implementieren widerwillig
• Woche 9-16: Performance-Probleme entstehen, Feuerwehr beginnt
• Woche 17-20: Umkehr und Migration zu Envoy
• Gesamt: 20 Wochen, 400K Dollar verschwendete Anstrengung

Deep Democracy Zeitplan:

• Woche 1: Async RFC geöffnet, alle Teams tragen bei
• Woche 2: Fishbowl-Diskussion bringt Bedenken über Kongs Lua-Performance hervor
• Woche 3: Minderheitsbericht dokumentiert Envoy-Alternative mit Benchmarks
• Woche 4: Konsens mit Vorbehalten - Envoy gewählt mit Kong für spezifische Anwendungsfälle
• Woche 5-12: Reibungslose Implementierung mit vorab adressierten Bedenken
• Gesamt: 12 Wochen, 400K Dollar gespart

Der Unterschied? Wir hörten den Performance Engineer, der beide benchmarkt hatte. Im traditionellen Modell hätte sie im Architecture Committee Meeting nicht gesprochen.

Deine nächsten Schritte#

So beginnst du morgen:

Für Engineering Manager#

1. Führe eine Macht-Kartierungsübung in deinem nächsten Team Meeting durch
2. Implementiere Fünf-Finger-Abstimmung für deine nächste technische Entscheidung
3. Füge einen Minderheitsbericht-Bereich zu deinem ADR-Template hinzu
4. Miss Sprechzeit in deinem nächsten Architecture Review
5. Rotiere wer die technischen Diskussionen führt

Für Senior Engineers#

1. Zähle deine Sprechzeit und reduziere sie bewusst um 30%
2. Frage einen Junior Engineer nach seinen Bedenken vor jeder größeren Entscheidung
3. Schreibe einen Minderheitsbericht für eine Entscheidung, mit der du nicht einverstanden bist
4. Moderiere anstatt zu dominieren technische Diskussionen
5. Gib Unsicherheit öffentlich zu um psychologische Sicherheit zu modellieren

Für Engineering Teams#

1. Fordert Async-Kommentar-Phasen vor synchronen Entscheidungen
2. Erstellt eine Team-Charta für inklusive Entscheidungsfindung
3. Verfolgt wessen Ideen implementiert werden und diskutiert die Muster
4. Etabliert "Devil's Advocate"-Rotationen für alle größeren Entscheidungen
5. Dokumentiert Bedenken auch wenn ihr mit Entscheidungen einverstanden seid

Die unbequeme Wahrheit#

Nach zwanzig Jahren in dieser Branche weiß ich: Die beste technische Entscheidung ist wertlos, wenn das Team sie nicht wirklich unterstützt. Wir haben für technische Exzellenz optimiert, während wir menschliche Dynamiken ignorierten. Deep Democracy geht nicht darum, nett oder politisch korrekt zu sein. Es geht darum zu erkennen, dass der Junior Engineer, der deine Architektur implementieren muss, Probleme sehen könnte, die du zu ignorieren gelernt hast.

Dieser MongoDB-Migrations-Fehler? Der Junior Data Engineer hatte einen Blog darüber geschrieben, warum es genau scheitern würde. Niemand las ihn, weil "was würde ein Junior über Datenbankarchitektur wissen?"

Der Sicherheitsbreach? Das Sicherheitsteam hatte den exakten Angriffsvektor sechs Monate früher in einem Minderheitsbericht dokumentiert.

Das Bangalore Shadow Service Mesh? Sie hatten ihre Latenz-Anforderungen in einem async RFC-Thread vorgeschlagen, der unter Kalifornien-Zeitzonen-Diskussionen begraben wurde.

Demokratie im Engineering ist nicht ineffizient. Falscher Konsens ist ineffizient. Demokratie ist, wie wir die massive Nacharbeit verhindern, die von Entscheidungen kommt, die einstimmig aussehen, aber es nicht sind.

Abschließende Gedanken: Warum das jetzt wichtig ist#

Die Branche verändert sich. Remote Work macht unsichtbare Hierarchien mächtiger. Diverse Teams bringen Perspektiven, die homogene Gruppen verpassen. KI-Tools demokratisieren technische Fähigkeiten, aber nicht Einfluss. Die Firmen, die inklusive Entscheidungsfindung verstehen, werden bessere Systeme bauen, bessere Engineers behalten und schneller liefern als die, die im falschen Konsens stecken.

Du kannst klein anfangen. Wähle eine Entscheidung. Kartiere die Machtdynamiken. Verwende Fünf-Finger-Abstimmung. Dokumentiere den Widerspruch. Miss, was passiert.

Denn hier ist die Sache: Jeder Senior Engineer war einmal ein Junior mit Bedenken, die niemand hörte. Jede gescheiterte Migration hatte eine Minderheitsstimme, die sie hätte verhindern können. Jeder Production-Incident hatte jemanden, der es kommen sah, aber sich nicht sicher fühlte zu sprechen.

Deep Democracy geht nicht darum, alle glücklich zu machen. Es geht darum, Entscheidungen zu treffen, die halten, weil jedermanns Bedenken angegangen werden, nicht ignoriert. Im Engineering, wie in der Demokratie, trägt die Minderheitsstimme oft die Lösung von morgen. Wir brauchen nur den Mut zuzuhören.

Das nächste Mal, wenn jemand stumm in deinem Architecture Review nickt, denk daran: Stille ist nicht Zustimmung. Es könnte der Klang deines nächsten Production-Incidents sein, der darauf wartet zu passieren.