- Senior Engineers legen mehr Wert auf „effektives Handeln“ als auf „Rechthaben“ und versuchen nicht, jedes falsche Projekt zu stoppen
- „Schlechte Projekte“ umfassen technische, politische und UX-Probleme und hängen oft von subjektiver Einschätzung ab
- Einfluss sollte wie ein Bankkonto verwaltet werden; wer zu oft widerspricht, kann Vertrauen verlieren und in einen Zustand des „politischen Bankrotts“ geraten
- Ob man eingreift, wird anhand von Nähe zum Projekt, Auswirkungen auf das Team und dem Ausmaß des Schadens für das gesamte Unternehmen entschieden
- Statt jedes Problem lösen zu wollen, sollte man strategisch den Zeitpunkt für Eingriffe wählen und auf alles andere mit Beobachtung und Vorbereitung reagieren
Definition und Beispiele für schlechte Projekte
- „Schlechte Projekte“ treten in vielen Formen auf, etwa als Lösungen für unnötige Probleme, komplexe Designs oder politisch motivierte Vorhaben
- Aus UX-Sicht werden dabei Probleme gelöst, die gar nicht existieren, oder bestehende Abläufe werden zerstört
- Technisch geht es um übermäßige Komplexität, die falsche Auswahl von Bibliotheken und ineffiziente Architekturen
- Politisch sind es Projekte für Beförderungen oder das Hinterherlaufen hinter Trends
- Ob ein Projekt gut oder schlecht ist, ist eine subjektive Einschätzung, die sich oft erst mit der Zeit zeigt und anfangs nicht klar ist
- Ein Beispiel bei Google war ein Projekt, bei dem ein Plattform-Team einen zentralen User-Flow an ein anderes Team übergeben wollte, das aus politischen Gründen scheiterte
- Technisch war es hervorragend, wurde aber wegen organisatorischer Machtfragen zwischen Teams zwei Jahre später verworfen
- Die Lektion lautete: „Politik und die Genauigkeit der Problemdefinition sind genauso wichtig wie technische Exzellenz.“
Warum sich nicht jedes schlechte Projekt stoppen lässt
- Software-Unternehmen haben oft einen starken Bias in Richtung „schnelle Umsetzung“, sodass das Äußern von Bedenken als Bremsen wahrgenommen wird
- Deshalb wird Kritik wahrscheinlich ignoriert, solange das Problem nicht als groß genug gilt
- Wer wiederholt widerspricht, wird schnell als „negative Person“ abgestempelt, während verhinderte Fehlschläge kaum Anerkennung bekommen
- Widerspruch kann Beförderungen anderer oder Projekte von Führungskräften beeinflussen und birgt daher politische Risiken
- Die Aufmerksamkeit, die ein einzelner Engineer aufbringen kann, ist begrenzt; wer sich in alles einmischt, wird mit der Zeit zynisch
Einfluss wie ein „Bankkonto“ verwalten
- Einfluss ist ein Vermögenswert, der durch Ergebnisse und Zusammenarbeit aufgebaut wird und bei jedem Widerspruch abgehoben wird
- $5-Scheck: kleine Hinweise auf dem Niveau eines Code-Reviews
- $500-Scheck: Widerspruch gegen Architekturentscheidungen oder Zeitpläne
- $50.000-Scheck: der Versuch, ein Projekt auf Executive-Ebene zu stoppen
- Wer sich wiederholt in Kleinigkeiten einmischt, verliert die Fähigkeit, bei großen Themen wirksam zu handeln
- Ist der Einfluss aufgebraucht, droht „politischer Bankrott“: keine Meeting-Einladungen mehr, ignorierte Meinungen und ähnliches
Kriterien für den richtigen Zeitpunkt zum Eingreifen
- Prüfung der eigenen Expertise: Ist die eigene Einschätzung ausreichend fundiert?
- Bewusstsein für die Grenzen des eigenen Wortes: Eine Meinung zu äußern ist kein „Befehl“, sondern das Teilen einer Perspektive
- Drei Entscheidungsfaktoren
- Nähe (Proximity): Je näher es am eigenen Team ist, desto geringer sind die Kosten eines Eingriffs
- Auswirkungen auf das Team (Team Impact): Wenn ein Scheitern dem Team direkt schadet, lohnt sich ein Eingreifen eher
- Unternehmensweite Tragweite (Company Scale): Wenn das Scheitern die gesamte Organisation stark betrifft, ist Eingreifen nötig
Umgang mit schlechten Projekten
- Direktes Eingreifen: fordern, dass das Projekt gestoppt wird, oder ein Dokument mit starken Bedenken einreichen
- Dafür braucht es Überzeugung und die Bereitschaft, Risiken zu tragen
- Teilweises Eingreifen: die Designrichtung anpassen oder in eine bessere Lösung lenken
- Mit einer kooperativen Haltung kann man dabei als „hilfreiche Person“ wahrgenommen werden
- Nicht eingreifen: wenn politisches Trägheitsmoment oder begrenzter Einfluss ein Eingreifen nicht lohnenswert machen
- Ist das eigene Team betroffen, sollte man Vorsorge treffen, etwa durch geringere Abhängigkeiten oder den Aufbau von Alternativen
- Ist das Team nicht betroffen, kann man still beobachten und die eigene Meinung nur intern teilen
- Teamführung: dem Team die Realität offen mitteilen, aber unnötige politische Details weglassen
Fazit
- Zentral ist die Erkenntnis: „Rechthaben und Wirksamkeit sind nicht dasselbe.“
- In großen Unternehmen zählen Politik und Kontext oft mehr als reine Logik, und nicht jeder Fehler lässt sich korrigieren
- Man sollte Einfluss und Vertrauen strategisch einsetzen und sich auf die Momente konzentrieren, in denen echte Veränderung möglich ist
- Im Rest der Fälle gilt: mit Kolleg:innen teilen, vorsorgen und durch Beobachtung lernen
- Auch wenn sich nicht alles perfekt lösen lässt, ist dieser Ansatz nachhaltig
Noch keine Kommentare.