Warum Senior Engineers schlechte Projekte einfach laufen lassen

• 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

[GN⁺]

Hacker-News-Meinungen

• Das erinnert mich daran, wie ein Manager einmal sagte: „Manchmal muss man Menschen scheitern lassen.“
  Es hat zu viel Energie gekostet, bestimmte Leute ständig mitzutragen. Irgendwann hoffte ich, dass sie von selbst schwimmen lernen würden, aber manchmal war diese Mühe anderswo einfach besser investiert.
  Es gab ein Projekt, das ohne meine Beteiligung lief, aber ohne mein Wissen niemals hätte erfolgreich sein können. Das Team war so schlecht aufgestellt, dass es Fragen und eigentliche Arbeit bunt durcheinanderwarf.
  Als ich dann auch noch erfuhr, dass das Management mein Team herabsetzte und stattdessen sie lobte, fühlte ich mich wirklich gedemütigt. Ihre Umsetzung war grauenhaft.

  • Ich sage oft: „Manchmal muss man Manager scheitern lassen.“
    Manche Manager hören nicht gern, dass ihre Idee nicht funktioniert. Wenn man widerspricht, wird man schnell als Ursache des Scheiterns dargestellt.
    Deshalb lasse ich die Arbeit laufen, halte sie aber regelmäßig auf dem Laufenden. So sehen sie das absehbare Scheitern mit eigenen Augen, und ich werde vom Scheitern getrennt.
  • Wenn das Management scheitert, gibt es keine gegenseitigen Schuldzuweisungen. Stattdessen holt man Berater ins Haus und entlässt Senior Engineers.
  • Ich habe einmal gehört: „Menschen müssen ihre Daten selbst sammeln.“ Am Ende lernt man nur, wenn man selbst dagegenläuft.
  • Ich finde, das Scheitern einer Person und das Scheitern eines Projekts sind zwei verschiedene Dinge.
    Das Scheitern einer Einzelperson ist kostengünstig und lehrreich. Manchmal funktioniert ihr Ansatz sogar, und die Organisation gewinnt dadurch neue Wissenswerte.
  • Menschen selbst lernen zu lassen, ist riskant. Man muss darauf vertrauen, dass sie Selbstwahrnehmung haben und sich nicht nur auf meine Unterstützung stützen.
    Sie können scheitern, ohne etwas daraus zu lernen. Aber wenn man sein Bestes getan hat, bleibt wenigstens ein ruhiges Gewissen.

• Wie „schlecht“ ein Projekt ist, bleibt über den größten Teil seines Lebenszyklus subjektiv.
  Es gab einmal Außenstehende, die ein Projekt ablehnten und stoppen wollten. Als es am Ende doch veröffentlicht wurde und erfolgreich war, war ihre Glaubwürdigkeit dahin.
  Man sollte sorgfältig überlegen, wofür man seinen Ruf einsetzt.

  • Ich habe etwas Ähnliches erlebt. In einer Organisation, die auf Zusammenarbeit ausgelegt war, hatte ich so unverhohlenen Egoismus noch nie gesehen.
    Mir ist klar, dass die Welt nicht immer nur aus Sonnenschein und Regenbögen besteht, aber damals war ich wirklich enttäuscht.

• Wie in dem Spruch „Nicht mein Affe, nicht mein Zirkus“ mische ich mich nicht in Dinge ein, die nicht in meiner Verantwortung liegen.
  Auch als Architekt habe ich zu UI oder Business-Logik außerhalb meines Bereichs keine unnötigen Ratschläge gegeben.
  Bei Entscheidungen von übergeordneten Managern mache ich einfach mit. Auch als Berater halte ich mich an dasselbe Prinzip.
  Ich greife nur vorsichtig in meinem Fachgebiet ein. Und selbst dann nur mit Zustimmung der C-Suite.

• Für kleine und mittlere Unternehmen ist dieser Rat ziemlich passend. In Großunternehmen ist es dagegen fast bedeutungslos, sich gegen ein Projekt zu stellen.
  Wenn es erfolgreich ist, sieht man wie ein Idiot aus, und wenn es scheitert, erinnert sich niemand daran.
  Der echte ROI entsteht, wenn man nach dem Scheitern eine Lösung präsentieren kann. Menschen mögen „Problemlöser“.
  Ich hatte einmal automatisierte E2E-Tests vorgeschlagen, wurde abgelehnt, und als später Probleme auftauchten, holte ich das Framework wieder hervor und wurde wie ein Held behandelt.

  • Je weiter man im Unternehmen aufsteigt, desto eher muss man Verantwortung für Fehler anderer übernehmen, bei immer geringerer Belohnung.
    Manchmal wirkt es klüger, lieber in einer niedrigeren Position stressfrei zu leben.
  • In Startups können ein paar Engineers mit einem klaren „Das ist doch Unsinn“ noch eine Katastrophe verhindern.
    In Großkonzernen werden dagegen wegen Politik über Jahre hinweg Millionen verschwendet.

• Ich vertrete die Position: „Man sollte Probleme nicht ignorieren.“
  Wenn man in einer Position ist, zu helfen, sollte man auch leise einen anderen Ansatz vorschlagen. Emotional werden muss man dafür nicht.

  • Die Bedingung „wenn man in einer Position ist, zu helfen“ ist der entscheidende Punkt.
    In kleinen Organisationen werden gute Ideen leicht aufgegriffen, in großen Organisationen ist das politische Risiko dagegen viel höher.
    In Wirklichkeit ist die Wahrscheinlichkeit, Ansehen zu verlieren, oft größer als die, tatsächlich helfen zu können. Deshalb ist es wichtig, seine Kämpfe sorgfältig auszuwählen.
  • In kleinen Organisationen kann frühes Eingreifen sogar Pflicht sein.
    Aber in großen Organisationen ein bereits laufendes Projekt umzulenken, kostet enorm viel Zeit und Energie.
  • Die Formulierung „ein schlechtes Projekt einfach laufen lassen“ ist missverständlich.
    Tatsächlich können wir solche Projekte oft gar nicht kontrollieren. „Ich weiß nicht, warum das andere Team so vorgeht“ wäre der treffendere Titel.
  • Wenn ich ein Scheitern erwarte, halte ich meine Meinung ebenfalls schriftlich fest und belasse es dabei.
    Professionalität bedeutet, etwas zu sagen, wenn es gesagt werden muss. Aber meiner Erfahrung nach ändert sich fast nie etwas.
  • Wenn man es weiß, sollte man es sagen, danach aber nicht die emotionale Last tragen. Wenn mein Rat ignoriert wurde, ist das nicht mehr mein Problem.

• Ich beobachte genau so eine Situation gerade in der Realität.
  Der Eigentümer hat aus Kosten- und Geschwindigkeitsgründen eine Low-Code-Plattform gewählt, aber am Ende waren riesige, hackartige Anpassungen nötig.
  Mein Team deployed mit TypeScript mehrmals täglich, während jenes Team einmal im Monat deployed und mit curl seltsame Dinge anstellt.

• Dieser Rat ist in der politischen Realität von Big Tech hervorragend, wirkt am Ende aber wie eine Art Unternehmenspazifismus.
  In anderen Umfeldern kann man es sich nicht leisten, Geld und Motivation zu verbrennen.
  (Trotzdem bringt Lalit die komplexe Dynamik von Organisationen in einem kurzen Text sehr gut auf den Punkt.)

  • Ich habe zwar nie bei Big Tech gearbeitet, aber in kleinen Organisationen dasselbe Phänomen gesehen.
    Wer ständig nörgelt, wird am Ende als negative Person abgestempelt.
    Der eigentliche Rat ist also, sich Energie für den entscheidenden Moment aufzusparen. Nicht jedes Problem entscheidet über Sein oder Nichtsein des Unternehmens.
  • Pazifismus ist nicht Untätigkeit. Im Gegenteil: Er ist oft die aktivste und wirksamste politische Handlung.

• Engineers haben nicht die politische Befugnis, schlechte Projekte „scheitern zu lassen“.
  Das ist Aufgabe des Managements. Engineers müssen nur technischen Rat geben.
  Man muss diese Dynamiken aber verstehen, damit sie sich nicht auf die eigene Karriere auswirken.
  Der Revierkampf zwischen Produktteam und Plattformteam entsteht aus dem Fehlen klarer Führung.
  Wer wissen will, warum so etwas so oft passiert, findet in diesem Google-Beitrag lesenswertes Material.

• Diese Denkweise ist in großen Organisationen, besonders in Behörden, weit verbreitet.
  Die Kosten trägt eine andere Abteilung, und Macht wird daran gemessen, wie viele Leute man verwaltet.
  Um solche organisatorische Nekrose zu verhindern, müssen Führungskräfte klare Messgrößen und Präventionsmechanismen etablieren.

  • Menschen mögen instinktiv positive Menschen und mögen negative nicht.
    Politisches Kapital verschwindet nicht einfach, nur weil man es ignoriert.

• Das ist eine gute Analogie.
  Wenn man Führung und Vertrauen aufbaut, entsteht ein Raum, in dem man sagen kann: „Du liegst falsch.“
  Führungskräfte vertrauen Engineers aber nicht immer, weil Engineers manchmal falschliegen.
  Engineers sind hervorragend darin, Fehler zu finden, aber schwächer darin, den geschäftlichen Kontext zu verstehen.
  Deshalb sollte man selbst bei einer „dumm wirkenden Idee“ erst den Kontext verstehen und dann urteilen.
  Wenn man echte Kill-Ideen von bloß fehlerhaften Ideen unterscheiden kann, gewinnt man Vertrauen in der Organisation.