Der Vorfall, bei dem ich den CTO angelogen habe, um eine Krise abzuwenden

Die Geschichte, wie ein Entwickler den CTO anlog

• Das ist eine Geschichte aus meiner Zeit vor einigen Jahren, als ich bei einem Fortune-500-Unternehmen gearbeitet habe
• Damals akquirierte der CTO für einen wichtigen Kunden aus seinem persönlichen Netzwerk ein großes Projekt und entschied, den Kernteil an einen großen technischen Dienstleister auszulagern
• Das „Produkt“ des Anbieters erforderte in Wirklichkeit jedoch massive Anpassungen, um zu den Anforderungen zu passen, und das war die denkbar schlechteste Wahl
• In den Status-Meetings mit dem CTO hielt niemand diese Idee für gut, aber alle sagten nur: „Gute Idee, Boss“
• Als der Anbieter das „Produkt“ schließlich lieferte, war bereits September, und der Death March für den Oktober-Launch begann
• Beim Testen wurden schwerwiegende Bugs entdeckt, darunter Performance-Probleme und das Erreichen des MongoDB-Dokumentlimits von 16 MB
• Dem Kunden wurde mitgeteilt, dass der Launch sich um einen Monat verzögere, und gleichzeitig wurde beschlossen, heimlich ein Projekt zu starten, das die Integration des Anbieters ersetzen sollte
• Ich war ein junger, leidenschaftlicher Entwickler und bekam drei Teammitglieder zugeteilt, mit denen ich die Entwicklung des Ersatzsystems begann
• Mitte Dezember hatten wir die Ersatzsoftware im vergangenen Monat fast fertiggestellt, aber alle waren ausgebrannt
• In diesem Moment kam der CTO vorbei und sagte, dass der Urlaub gestrichen werde, und ich antwortete: „Verstanden“
• Dann erinnerte ich mich an den Rat meines Vaters, sagte den Teammitgliedern, sie sollten in den Urlaub fahren, und nahm allein am Death-March-Status-Meeting mit dem CTO teil und log
  • „Das Team arbeitet hart. Heute haben wir den 73. Milestone-Integrationspunkt erreicht“
  • „Das Team hat gestern gute Fortschritte gemacht. Wir haben noch einen weiteren Web Service fertiggestellt“
• Eine Woche später kamen die ausgeruhten Teammitglieder zurück, und im Januar konnten wir pünktlich und erfolgreich launchen

Meinung von GN⁺

• Dies ist ein Fall, in dem die Leadership hervorsticht, mit der das Projekt trotz schlechter Bedingungen und überzogener Anforderungen erfolgreich zum Abschluss gebracht wurde. Besonders eindrucksvoll ist die Aufmerksamkeit für den Zustand des Teams
• Dennoch ist es nicht wünschenswert, den CTO anzulügen. Langfristig kann das zu Vertrauensverlust innerhalb der Organisation führen und größere Probleme verursachen
• Dass die Auswahl des Anbieters und das Management des Outsourcings scheiterten, liegt in hohem Maß in der Verantwortung des CTO. Im Prozess der Korrektur wäre jedoch eine transparentere und aktivere Kommunikation nötig gewesen
• Um Burnout bei Entwicklern zu verhindern, hätte von Anfang an ein realistischeres Zeitmodell aufgestellt und ausreichend Personal eingesetzt werden müssen. Crunch Mode ist eine Praxis, die vermieden werden sollte
• Als Alternative, die in ähnlichen Problemsituationen als Orientierung dienen kann, bietet sich die agile Methodik an. Durch die Wiederholung kurzer Entwicklungszyklen mit anschließendem Feedback lassen sich Risiken minimieren und die Arbeitsbelastung im Team steuern

[GN⁺]

Hacker-News-Kommentare

• Überarbeitung und abgesagte Urlaube:
  • Sich zu überarbeiten und Urlaub zu streichen, um unrealistische Fristen einzuhalten, ist nicht klug und wird später bereut
  • Unternehmen, die sich darauf verlassen, dass Mitarbeitende ihren Urlaub opfern, um ein Produkt auszuliefern, fördern eine problematische Arbeitsplatzkultur
• Gesundes vs. ungesundes Unternehmen:
  • In einem gesunden Unternehmen hätten erfahrene Leute die Probleme des Outsourcing-Ansatzes vorhergesehen und früh Bedenken geäußert
  • Offene Kommunikation, gemeinsames Arbeiten an Lösungen und Manager, die sich für das Wohl des Teams einsetzen, sind Anzeichen eines gesunden Umfelds
  • Die Geschichte beschreibt eine ungesunde Situation, in der ein Manager wiederholt Vorgesetzte anlügt
• Absurde Vendor-Praktiken:
  • Der Ansatz des Vendors, alle Transaktionen in einem riesigen JSON-Dokument zu speichern und bei jedem Update alles komplett lesen zu müssen, ist absurd
  • Ein weiteres Beispiel ist ein Startup, das Ticketdaten von Nutzern als zusätzliche Spalten in der Benutzertabelle speichert, sodass Hunderte Spalten entstehen
• Dysfunktionale Lage und Führung:
  • Der Ansatz des Teamleiters, wegen des Urlaubs zu lügen, ist nicht akzeptabel und ein Verstoß, der zur Kündigung führen könnte
  • Ein besserer Ansatz wäre, sich gegen unangemessene Überstundenforderungen zu stellen und auf einen vernünftigen Projektumfang sowie die Verantwortung des Vendors zu pochen
  • Ein Teamleiter hat die Verantwortung, sein Team vor verrückten Anforderungen zu schützen, selbst wenn er damit seinen eigenen Job riskiert
• Niemand profitiert davon:
  • Der Vendor lieferte geringe Qualität, der CTO war ahnungslos, die Entwickler waren überarbeitet, und die Hauptfigur war auf Lügen angewiesen
  • Das ist eine verrückte Situation, die niemand akzeptieren sollte. Es ist ratsam, zu einem besseren Arbeitsplatz zu wechseln
• Ehrlichkeit und Transparenz:
  • Es hat bei einigen gut funktioniert, gegenüber dem Management ehrlich über technische Probleme, Performance-Probleme und Änderungen im Umfang zu sprechen
  • Zu lügen, um willkürliche Fristen einzuhalten, die von einer realitätsfernen Führung gesetzt wurden, ist kein guter Ansatz
• Vertrauenslücke zwischen Entwicklern und Management:
  • Zwischen Entwicklern und nichttechnischem Management gibt es oft ein Informationsungleichgewicht und mangelndes Vertrauen
  • Manager können den Fortschritt nicht leicht bewerten und fühlen sich unsicher, was den Projekterfolg angeht
  • Da das Risiko auf der Business-Seite liegt, müssen Entwickler Druck machen und liefern, um diese Vertrauenslücke zu überbrücken
• Weniger versprechen und mehr liefern:
  • Dass die Hauptfigur log, bereits erledigte Arbeit als abgeschlossen zu melden, kann teilweise als „weniger versprechen und mehr liefern“ gesehen werden
  • Über nicht abgeschlossene Arbeit zu lügen, ist riskanter und kann die Moral des Teams beeinträchtigen, wenn die Leute zurückkommen
• Hilflose Organisationen und Low-Code-Tools:
  • Die schlechten Praktiken des Vendors und der bescheidene Projektumfang zeigen, wie hilflos sich manche Großunternehmen bei Softwareprojekten fühlen
  • Das könnte die Beliebtheit von Low-Code-Tools wie Retool zumindest für die technische Führung erklären, wenn schon nicht für Ingenieure
• Integrität und Nein-Sagen:
  • Ein echter „Rockstar“ hat Integrität und den Mut, Dummheit und unvernünftige Anforderungen zurückzuweisen
  • Es ist nicht die Verantwortung des Einzelnen, außergewöhnliche Inkompetenz auszugleichen oder die Last für das ganze Team zu tragen