2 Punkte von GN⁺ 2024-04-12 | 1 Kommentare | Auf WhatsApp teilen
  • Die Rolle von Startup-Führungskräften hat weniger mit Code zu tun als mit unsicheren Verantwortlichkeiten; Panikattacken, Angstzustände und Burnout können Arbeitsleistung und das gesamte Leben erschüttern
  • Je höher die Position, desto mehr nimmt der Druck mit offenen Enden zu: statt klarer Tickets wechselnde Anforderungen, überlappende Deadlines und 24/7-Incident-Response
  • Eine „make it happen“-Kultur verstärkt Burnout durch das Akzeptieren unrealistischer Deadlines, Micromanagement, das nächtliche Umschreiben von PRs, ausgelassene Mahlzeiten und immer mehr Meetings
  • Nicht jede Deadline birgt dasselbe Risiko; unterscheidet man regulatorische, vertragliche und selbst auferlegte Deadlines, lassen sich verhandelbarer Druck und echte Risiken besser trennen
  • Erholung beginnt weniger mit großen Vorsätzen als mit kleinen, wiederholbaren Handlungen: frühe Warnsignale erkennen, Wochenenden schützen, delegieren, Benachrichtigungen ausschalten, Beratung in Anspruch nehmen

Angst und Burnout, ausgelöst durch eine Führungsrolle im Startup

  • 2017 übernahm er die Rolle des Head of IT und damit ein fünfköpfiges Entwicklungsteam, viele Zusagen gegenüber Partnern und den Druck, „alles zu liefern, nichts kaputtzumachen und niemanden zu verbrennen“
  • Damals hatte er nicht das Gefühl, wegen psychischer Gesundheit krankgeschrieben werden zu können; selbst wenn im Firmenhandbuch ein mental health day steht, zögern Engineers häufig weiterhin
  • Wenn die Angst hochkam, suchte er auf Reddit in r/Anxiety nach ähnlichen Symptomen; das war keine langfristige Lösung, half aber, nicht aus dem Büro zu rennen
  • Am Ende ging er zum Arzt, erhielt eine offizielle Diagnose und fand langsam zu seinem Normalzustand zurück; bis heute hält er eine Notfall-Checkliste griffbereit

Von kontrollierbarer Entwicklungsarbeit zu unsicherer Führungsarbeit

  • Frühe Entwicklungsaufgaben hatten oft relativ kontrollierbare Abläufe: klare Tickets, Akzeptanzkriterien, Tests und Merges
  • Mit wachsender Position wird die Arbeitsdefinition unschärfer, Deadlines überschneiden sich, Stakeholder ändern mitten im Sprint ihre Meinung, und probabilistische Entscheidungen werden Alltag
  • Infrastruktur- und SRE-Arbeit bringt durch einen 24/7-Pager eine noch stärkere dauerhafte Anspannung mit sich als Produktdeadlines
  • Es gab eine Situation, in der der CEO verlangte, ein dem größten Kunden versprochenes Feature zur obersten Priorität zu machen, und einen Tag später ein dazu widersprüchliches anderes Feature ebenfalls zur obersten Priorität erklärte
    • Auch nachdem gesagt wurde, dass nicht beide Features gleichzeitig oberste Priorität sein können, lautete die Antwort: „make it happen“

Der kumulative Schaden von „make it happen“

  • Burnout war weniger das Ergebnis eines einzelnen großen Unfalls als vielmehr die Summe tausender kleiner Selbstverletzungen
  • Handlungen, die die mentale Belastung erhöhten, wiederholten sich immer wieder
    • Um das Gesicht des Sales-Teams zu wahren, wurden alle unrealistischen Deadlines akzeptiert
    • Unter dem Vorwand, das Team zu schützen, sprang er selbst in den Code und betrieb Micromanagement
    • Um 2 Uhr morgens aktualisierte er das Bankkonto, um zu prüfen, ob die Gehälter ausgezahlt werden konnten
    • Während er akute Incidents löschte, versuchte er gleichzeitig, die künftige Architektur zu planen
    • Tagsüber coachte er Junior Engineers und schrieb nachts heimlich PRs um
    • Eine Kette aus Meetings, kaltem Kaffee und ausgelassenem Mittagessen setzte sich fort
  • Am Wochenende waren die ersten 10 Sekunden am Morgen in Ordnung, dann fiel die Angst sofort wieder über ihn her

Nicht jede Deadline ist dasselbe Risiko

  • Früher behandelte er jedes Release wie die Landung des Mars Rover, doch rückblickend entschieden nur wenige Deadlines wirklich über das Überleben des Unternehmens; der Rest hatte eher mit Stolz und misslungener Erwartungssteuerung zu tun
  • Als der Cashflow des Unternehmens besser wurde und Kunden stabiler waren, begann Work-Life-Balance weniger unrealistisch zu wirken
  • Einmal scheiterte ein Deployment am Freitagabend, und sechs Stunden gingen für die Behebung drauf; er dachte, der Kunde werde den Vertrag kündigen, doch am Montag stellte sich heraus, dass der Kunde auf einem Segeltörn war und nicht einmal den Staging-Link geöffnet hatte
  • Deadlines lassen sich in drei Kategorien einteilen
    • Regulatorische Deadlines: nicht verhandelbar
    • Vertragliche Deadlines: meist verhandelbar, wenn man früh genug spricht
    • Selbst auferlegte Deadlines: meist aus Stolz entstanden
  • Manche Unternehmen werben mit einer 4-Tage-Woche und Slack-Verbot nach Feierabend; man muss nicht bei Firmen bleiben, die Burnout wie eine Ehrenmedaille behandeln

Persönliche Gegenmaßnahmen, die funktioniert haben

  • Das ist kein medizinischer Rat, aber es gab Verhaltensweisen, die halfen, funktionsfähig zu bleiben
  • Frühe Warnsignale finden
    • Bei ihm waren doom-scroll-bedingte Schlaflosigkeit und eine plötzliche Abneigung gegen Code Reviews, die er sonst mochte, Warnsignale
    • Wenn solche Signale auftauchen, drosselt er das Tempo
  • Klar „Nein“ sagen
    • Wochenenden müssen geschützt werden; wenn es kein Pager-Alarm ist, soll es bis Montag warten
  • Richtig delegieren
    • Jeder PR, den man festhält, ist eine verlorene Gelegenheit für Mentoring und ein Aufbau von Angst
  • Koffein reduzieren
    • Er wechselte über half-caf zu decaf, und sein Herz wurde ruhiger
  • Täglich 12.000 Schritte gehen
    • Ohne besondere Ausrüstung reichen Schuhe und eine Route
  • Benachrichtigungen auf dem Handy ausschalten
    • Wenn die Produktion wirklich brennt, wird schon jemand anrufen

Führung, die zuerst den Menschen sieht

  • Als er anfing, über emotionale Intelligenz zu lesen, sah er Menschen nicht mehr wie merge-conflict-Maschinen
  • Erst zuzuhören und später zu reparieren kann manchmal hilfreicher sein als eine weitere Sprint-Retrospektive
  • Es passt nicht zusammen, zahnärztliche Behandlung ohne Scham in Anspruch zu nehmen, aber zu erwarten, die eigene psychische Gesundheit allein refactoren zu müssen
  • Die Zeit mit einem Experten gehörte zu den Stunden mit dem höchsten ROI
  • Erholung ist ein wiederkehrender Prozess; es kommt immer noch vor, dass er bis spät arbeitet oder das Mittagessen vergisst, aber jetzt bemerkt er es, korrigiert es und macht weiter

Ein wichtigeres Asset als Code

  • Code kann neu geschrieben werden, Menschen kann man nicht so behandeln
  • Depression interessiert sich nicht für Kubernetes-Uptime, und wenn Führung Menschen verheizt, läuft der Cluster vielleicht weiter, aber die Menschen, die ihn betreiben, halten nicht durch
  • Auch wenn der Impuls da ist, alle Kundentickets selbst zu fixen, fragt er heute zuerst: „Liegt das in meinem Kontrollbereich?“ Wenn nicht, gibt er es ab
  • Dadurch wurde er ein etwas ruhigerer Engineer und schläft laut Apple Watch nachts 45 Minuten länger
  • Wer eine schwere Zeit durchmacht, ist nicht kaputt und nicht allein; es ist besser, um Hilfe zu bitten, kleine Experimente auszuprobieren und psychische Gesundheitstage zu nehmen
  • Ein Unternehmen, das Wert in Burnout-Stunden misst, ist diese Stunden nicht wert; das größte Asset ist nicht der geschriebene Code, sondern die Menschen, die diesen Code schreiben

1 Kommentare

 
GN⁺ 2024-04-12
Meinungen auf Hacker News
  • Nach fast 30 Jahren in der Softwareentwicklung bin ich zu dem Schluss gekommen, dass die meisten Deadlines völlig willkürlich sind
    Ob man eine Woche oder sogar sechs Monate zu spät ist, wird das Unternehmen nicht ruinieren; und wenn es das wirklich tut, ist es auch nicht die Schuld des Engineerings – es sei denn, die Engineering-Organisation ist so kaputt, dass sie ihre eigenen Lieferprognosen wiederholt reißt
    Es gibt echte Deadlines, etwa durch Regulierung, Proofs of Concept bei Kunden oder Auslieferungen, aber eine normale Engineering-/Business-Organisation kennt solche Termine lange im Voraus; entscheidend ist, ob die Umsetzung innerhalb eines Zeitplans mit ausreichend Puffer machbar ist
    Ich habe kaum erlebt, dass Kunden abspringen, weil ein Produkt nicht in einem bestimmten Rhythmus veröffentlicht wird; viele Kunden freuen sich im Gegenteil nicht einmal über Upgrades, wenn damit nicht ein von ihnen gemeldetes Problem behoben wird
    Endlose 80-Stunden-Wochen bewirken meist das Gegenteil und führen zu minderwertigen Produkten, die ständig kaputtgehen und die man am liebsten wegwerfen würde

    • Meiner Erfahrung nach ist auch die meiste Arbeit selbst willkürlich
      Wenn ich auf die letzten 30 Jahre zurückblicke: Wie viel Prozent der Arbeit hätte man komplett weglassen können, ohne dass es langfristig irgendeinen Unterschied gemacht hätte? Bei mir sind es locker mehr als 50 %, und an einem schlechten Tag würde ich sagen: fast 90 %
    • Das hängt von der Branche ab
      Videospiele werden immer noch auch in Einzelhandelsgeschäften wie Target oder Best Buy verkauft, und die Läden müssen ihre Regalflächen Monate im Voraus planen. Wenn du versprichst, bis zum 15. November ein verpacktes Spiel an die Logistikrampe zu liefern, und den Termin verfehlst, bleibt das Regal, das für dich freigehalten wurde, einfach leer
      Bei Unterhaltungselektronik ist es ähnlich, und Werbung, insbesondere TV-Werbung, musste früher ebenfalls viel früher gebucht werden. Wenn man den Werbeplatz nicht sechs Monate vorher kauft, ist er ausverkauft; und wenn das Produkt nicht kaufbar ist, wenn die Werbung läuft, verbrennt man eine Menge Geld
      Deadlines in gewöhnlichen IT-Projekten können ziemlich unsinnig sein, aber bei Einzelhandelsprodukten versteht man, warum es Deadlines gibt
      Die Lösung wäre, erst dann mit Verhandlungen über Regalflächen zu beginnen, wenn das Produkt zu 100 % fertig ist, aber Unternehmen schaffen das normalerweise nicht. Sie müssen mit den Bestellgeldern Gehälter zahlen; wenn sie nach Fertigstellung des Produkts Werbung und Regalflächen buchen und dann sechs Monate warten, ist unklar, was die Mitarbeiter in der Zwischenzeit tun sollen, und auch die Kosten sind hoch, erst zum nächsten Produkt überzugehen und später wieder zum Support des vorherigen Produkts zurückzukehren
    • Als jemand, der verschiedene Software wie VirtualBox und Docker nutzt, hasse ich Updates und sogenannte Upgrades wirklich
      Ich bevorzuge deutlich stabilere Versionen, die viel seltener aktualisiert werden
    • Unternehmen leiden weniger unter der Deadline selbst als darunter, wenn es keine ausreichende Vorwarnung gibt, dass die Deadline nicht gehalten wird
      Frustrierender ist, wenn es keinerlei Warnung gibt und das Engineering plötzlich verkündet, dass eine unmittelbar bevorstehende Deadline nicht geschafft wird, oder wenn sich „fast fertig, nur noch ein Sprint“ immer wieder wiederholt
      Deshalb helfen spontane Reaktionen wie „Wir schätzen ab jetzt nicht mehr“ oder „Fertig ist es, wenn es fertig ist“ überhaupt nicht
    • Viele Manager und Führungskräfte gehen davon aus, dass jede Aufgabe eine Deadline braucht
      Sie organisieren auch ihren eigenen Kalender mit Timeboxing und willkürlichen Fristen, empfinden sich dabei als produktiv und übertragen diese Einsicht auf das gesamte Unternehmen. Dahinter steht die Annahme, dass Arbeit ohne eine zeitlich begrenzte Drohung nicht rechtzeitig erledigt wird
      Das Gefühl, dass etwas an einem festgelegten Datum fertig wird, ist menschlich reizvoll, und es vermittelt auch dieses warme Gefühl, als laufe eine gut geölte Maschine nach einem vorhersehbaren Zeitplan
      Aber vielen Menschen Zwangspläne aufzuerlegen, um die Angst und den Terminzwang einer einzelnen Person zu managen, ist grausam. Die Realität ist komplex, und der Wunsch, sie in saubere Kästchen zu packen, ist wahnhaft und unproduktiv
  • Ich bin nicht wirklich überzeugt, dass Software Engineering schlechter für die psychische Gesundheit ist als andere White-Collar-Berufe wie Arzt, Anwalt, Vertrieb, Ingenieur, Profisportler oder Lehrer.
    All diese Berufe haben ihre eigenen Stressfaktoren, und es gibt jede Menge Texte von Menschen, die gehen, weil es zu belastend ist. Wenn man keine Grenzen setzt, frisst es die Freizeit auf, und Stress durch Deadlines ist ebenfalls allen gemeinsam.
    Der Teil, dass man dem Team nicht sagen könne: „Ich nehme mir einen Tag frei, weil es mir psychisch schlecht geht“, und dafür krankgeschrieben sein könne, war schwer zu lesen.
    In 20 Jahren Berufserfahrung habe ich eine solche Haltung nie erlebt, und Menschen nehmen häufig krankheitsbedingt frei wegen psychischer Gesundheit. Es tut mir leid, dass sich jemand so gefühlt hat, als könne er das nicht sagen, aber das ist viel eher die Ausnahme als die Regel.
    Gab es in den vergangenen 20 Jahren irgendein Unternehmen, das sich offen gegen psychische Gesundheit gestellt hat?

    • In einem militärischen Umfeld versucht man solche Situationen eher aktiv zu verhindern.
      Es gibt viele 18- bis 20-Jährige mit psychischen Problemen, und es hilft oft nicht, ihnen zu leicht frei zu geben. Fachleute versuchen, sie weiterarbeiten zu lassen, statt sie zu Hause trinken und nur Games spielen zu lassen.
      Manche junge Leute haben sogar besser reagiert, wenn der Arbeitsstress zunahm. Wie in der Grundausbildung: Sie arbeiten hart, gehen erschöpft nach Hause und schlafen. Schickt man sie dagegen nach Hause, ohne dass sie müde sind, führt das zu Alkohol und Gaming bis spät in die Nacht, und am nächsten Tag erscheinen sie wie Zombies zur Arbeit.
      Das funktioniert nicht für alle, aber wir müssen akzeptieren, dass wir nicht unbedingt die besten Therapeuten für uns selbst sind. Bei vielen Menschen verstärkt mehr freie Zeit negatives Verhalten.
      Die bessere Antwort ist nicht „Ich muss mir morgen frei nehmen“, sondern eher „Ich habe morgen um 08:00 einen Beratungstermin“.
    • Aus der Perspektive von jemandem, der aus der Medizin kommt, haben Software Engineers es wirklich gut. Man sollte zu schätzen wissen, was man hat.
      Persönliche Erfahrungen mit schlechtem Management, unrealistischen Zeitplänen und uninteressanten Projekten erkenne ich an, aber so etwas gibt es überall.
      Wenn man dazu nimmt, dass man jeden Tag dort sein muss, wo Patienten und Familien den schlimmsten Tag ihres Lebens erleben, Entscheidungen unter hohem Druck treffen muss und während der Schicht kaum Gelegenheit hat, sich hinzusetzen oder auch nur auf die Toilette zu gehen, sieht die Sache anders aus.
      Außerdem kann ein schlechter Tag, an dem man nicht in Form ist, in einer langen Untersuchung oder einem Gerichtsverfahren enden.
      Es mag gefühllos klingen, aber Software Engineering ist nicht so komplex oder stressig wie viele medizinische Berufe. Es ist psychisch wie körperlich weniger auszehrend.
    • Ich glaube nicht, dass Software Engineering weniger schädlich für die psychische Gesundheit ist als der Anwaltsberuf.
      Ich habe fast zehn Jahre lang mit Anwälten zusammengearbeitet und nicht-technische Professional Services erbracht, und ich habe auch jahrzehntelange Erfahrung in Software Engineering und Startups.
      Der Druck im Software Engineering war völlig anders als in juristischen Umgebungen und deutlich schlimmer.
      Im Allgemeinen sind Anwälte eher Anwälte als Manager. Es gibt eine Hierarchie vom Junior Associate bis zum Top-Partner, aber oben wie unten sind es Anwälte. Das ist etwas anderes als eine Struktur, in der Anwälte unter Managern arbeiten.
      Auch im juristischen Umfeld gibt es Druck und lange Arbeitszeiten, und Ehepartner beschweren sich, dass Anwälte ständig in der Kanzlei sind oder zu Hause geistig abwesend. Aber dort hatte ich keine Angstattacken oder psychischen Probleme; in Software- und Startup-Umgebungen schon.
      In der juristischen Welt kennen alle den Prozess und führen diesen Prozess aus, und auch der Vorgesetzte ist jemand, der diesen Prozess selbst durchlaufen hat.
      In der Software ist dieser Prozess oft unbekannt, und man wird leicht immer weiter zerrieben, um jemanden zufriedenzustellen, der nie selbst durch die Mühle gegangen ist. Ein erfolgreiches börsennotiertes Unternehmen, bei dem ich früher gearbeitet habe, hatte genau aus diesem Grund ständig Stellenanzeigen für Senior Software Engineers offen.
    • Viele Menschen wissen nicht, dass sie ihrem Manager nur sagen müssen, dass sie aus gesundheitlichen/medizinischen Gründen frei nehmen, und keine weiteren Informationen liefern müssen, ob es Grippe, ein Rückenproblem oder die psychische Gesundheit ist.
      Es würde vielen helfen, wenn in der Schule grundlegendes Arbeitsrecht vermittelt würde.
    • Warum ist es wichtig, wer gesagt hat, Software Engineering sei härter?
      Ob man in Scheiße getreten ist oder bis zu den Knien darin steckt: Am Ende ist man in der Scheiße. Wäre es nicht besser, einander sauberzumachen, statt darum zu wetteifern, wer mehr abbekommen hat?
      Wir sollten aufhören zu vergleichen. Das ist gerade keine Situation, in der Triage nötig wäre, und man kann auch mit Menschen Mitgefühl oder Empathie haben, die im Durchschnitt besser dastehen. Wir sind alle Menschen und profitieren davon, zusammenzuhalten.
  • Früher hatte ich eine gewisse Ehrfurcht vor jungen CEOs, die das College abgebrochen hatten, aber nachdem ich unter einigen von ihnen gearbeitet habe, habe ich beschlossen, nicht mehr bei Startups zu arbeiten, an deren Spitze Leute in ihren Zwanzigern stehen.
    Sie verstehen wirklich nichts von Management oder Leadership. Sie sind von Angst vor dem Scheitern getrieben, haben noch nichts erreicht und behandeln andere deshalb wie Dreck. Man sollte sie meiden.

    • Das Phänomen, in Stanford aufzutauchen, einem 21-Jährigen zu sagen, er sei Jesus Christus, und ihm Millionen von Dollar geben zu wollen, ist ebenso ein Geschwür der amerikanischen Geschäftskultur wie Corporate Raiders.
      Es ist die Freak-Version des Recruitings im College Football/Basketball.
    • Ich sehe keinen Grund, warum ein 25-Jähriger kein großartiger Startup-CEO sein könnte.
      Der schwierige Kern ist, dass es für einen 25-Jährigen, selbst wenn er insgesamt klug ist, ungewöhnlich viel Selbstreflexion und Demut besitzt und ein großes Problem angeht, schwer ist zu wissen, wann er auf sein Team oder seine Berater hören sollte, auf wen er hören sollte und wann er gegen den Rat anderer seinem eigenen Urteil folgen sollte.
      Wenn alle guten Eigenschaften vorhanden sind und er Zugang zu einem guten Team und guten Beratern hat, könnte es bis zu einem gewissen Grad funktionieren.
      Es hilft allerdings nicht, dass viele Bereiche voller schlechter Praktiken und Ratschläge, offener Täuschung und Manipulation sind. Als ich früher PGs Texte las, konnte man noch erwarten, dass ein anderer Techniker und Unternehmer einem klugen und wohlmeinenden Rat gibt und den eigenen Erfolg will; heute ist das ganz und gar nicht mehr Standard.
      Heute ist die Wahrscheinlichkeit, schlechte Ratschläge zu bekommen, fast überall viel höher, und es gibt auch mehr Einzelpersonen und Institutionen, die einen manipulieren wollen. Selbst wenn man selbst filtert, kommen diese Einflüsse sekundär über kluge, anständige Menschen herein, die man Einfluss nehmen lässt.
    • Man muss keine Ehrfurcht vor Menschen haben, die andere wie Dreck behandeln, egal ob sie 20 oder 60 sind.
      Ich komme gerade aus einer Erfahrung mit einem 49-jährigen Gründer/CEO heraus und werde künftig wohl nach allen entsprechenden Warnsignalen Ausschau halten.
    • Auch unter jungen Middle Managern gab es wirklich nervige Fälle. Unsichere Workaholics Ende 20 bis Anfang 30, also nicht einmal ganz jung, machen allen das Leben zur Hölle.
      Sie haben wie verrückt gearbeitet, um befördert zu werden, und glauben nun, sie könnten ihr Team mit Menschen wie sich selbst füllen.
      Aber so ist es nicht. Diese „Menschen wie sie“ waren entweder klug genug, ihre Gesundheit nicht zu ruinieren, oder wollten das nicht tun und wurden deshalb nicht befördert.
      Glückwunsch, dass sie es besser gemacht und mehr Geld und Macht bekommen haben, aber jetzt müssen alle in dem Bett liegen, aus dem sie die Laken gezogen und in das sie die Krümel gestreut haben.
    • In der Theorie stimmt das, aber ist es in der Praxis auch so? Sind Amazon und Oracle bessere Arbeitsplätze als Facebook und Stripe?
  • Ab einem gewissen Punkt muss man einfach eine Warteschlange anlegen und mit der nächstwichtigen Aufgabe beginnen.
    Wenn zu viele Dinge gleichzeitig in Arbeit sind, geht es schief.

    • Deshalb ist Kanban eine meiner liebsten Projektmanagement-Methoden.
      „Das ist also die neue Top-Priorität. Nach einer kurzen Sondierung dürfte diese Arbeit etwa 20 Sticky Notes entsprechen. Unsere bisherige Durchsatzrate im Team liegt bei 10 Sticky Notes in zwei Wochen. Wenn wir also alles, was gerade in Arbeit ist, stoppen, sind wir vermutlich in vier Wochen fertig. Bitte gehen Sie jede der bestehenden Sticky Notes durch und prüfen Sie, ob wir sie wirklich anhalten können.“
      Stakeholder können weiterhin Entscheidungen treffen, aber es sorgt dafür, dass sie realistisch verstehen, was sie vom Team verlangen.
    • Vor ein paar Jahren arbeitete ich bei einem Unternehmen als Engineering Director und bereitete eine große neue Version des Produkts vor.
      Ein paar Wochen später sagte ich dem CEO, dass ich glaube, Umfang und Schwierigkeit des neuen Releases inzwischen ziemlich gut zu verstehen; der CEO sagte: „Nein, tun Sie nicht.“
      Als ich nach dem Grund fragte, sagte er, es gebe ein am Wochenende neu ausgedachtes „unverzichtbares“ Feature, und das war offensichtlich technisch sehr schwierig. Dann erklärte er kategorisch, man könne alles innerhalb von 48 Stunden bauen.
      Es ist erstaunlich, dass ich es in dieser Stelle so lange ausgehalten habe.
    • Als Manager schließe ich eine Sache einfach ab, wenn von oben die Prioritäten geändert werden, die aktuelle Arbeit aber fast fertig ist.
      Wenn wir später zur ursprünglichen Aufgabe zurückkehren, sind alle immer überrascht, dass sie schon erledigt ist.
    • Mein früherer Arbeitsplatz war genau so, und wer länger in so einer Position bleibt, als nötig ist, sollte sich eine andere Rolle suchen.
      Am Ende führt das zu Burnout oder Gleichgültigkeit.
      Damals schaute ich viel X-Files und nannte es „Monster der Woche“; die Formulierung gefällt mir bis heute.
    • Eine der stärksten Fähigkeiten für Entwickler, die mit dem Business zu tun haben, ist die Fähigkeit, Nein sagen zu können.
  • Die Fähigkeit, sich von der Arbeit zu lösen, selbst nur für sehr kurze Zeit, ist wirklich wichtig.
    Man kann spazieren gehen, Kaffee machen oder einfach die Augen schließen und atmen.
    Stress wird oft künstlich erzeugt, schadet der Leistung und verschlechtert auch die Denkfähigkeit.
    Ich habe es mehrfach erlebt, dass Arbeit „dringend“ wurde, weil das Unternehmen angeblich einen Vertrag oder Umsatz gewinnen konnte, und dass alle zu Superstars würden, wenn wir diesen „Crunch“ schaffen.
    Wenn man zwei Monate lang Nachtschichten und drei bis vier Stunden Schlaf durchzieht, um ein Projekt früher auszuliefern, beginnen Management und Entscheider abzustumpfen und einem immer wieder solche „Geschenke“ in Form von Crunch zu machen.
    Dem Unternehmen zu helfen und die Extrameile zu gehen, haben die meisten von uns schon getan und werden es auch wieder tun können. Aber wenn alles dringend ist und jede Aufgabe sofort erledigt werden muss, gibt es ein größeres Problem.
    Geld, Zeit und Aufwand haben normalerweise Grenzen und Budgets. Wenn man diese Grenzen und Spielräume missbraucht, respektieren die Leute irgendwann denjenigen nicht mehr, der ständig „Wolf!“ ruft, und investieren auch weniger Energie in die Arbeit.

    • In meiner Laufbahn hat sich so etwas nie ausgezahlt.
      Jedes Mal, wenn wir wegen einer dramatisch dringenden Aufgabe nach dem Motto „Wenn wir das liefern, ist ein riesiger Großauftrag sicher“ gecruncht haben, endete es schließlich mit einem gescheiterten Vertragsabschluss.
      Vertriebsleute scheinen nicht gefeuert zu werden, selbst wenn sie die gesamte F&E-Organisation monatelang für eine langfristige Wette einspannen und die Leute verheizen.
      Natürlich macht dieser Vertriebsmitarbeiter in dieser ganzen Zeit auch nicht wochenlang Überstunden.
      Inzwischen verweigere ich Überstunden fast immer, außer wenn ich damit meinen eigenen Fehler ausbügle. Ich werde nie wieder länger arbeiten, um die unrealistische Deadline irgendeines Idioten einzuhalten.
    • Das ist die am schwersten zu lernende Lektion.
      Manchmal bekommt man nicht die Gelegenheit, es für das Unternehmen, das Produkt oder den Kunden „richtig“ zu machen. Am Ende fragt man, was heute am wichtigsten ist, erledigt das und macht nach Feierabend wirklich Schluss.
      Sinn und persönliche Zufriedenheit muss man im Privatleben finden. Man kann Sport machen, sich ehrenamtlich engagieren, ein Hobby haben oder sich auf die Familie konzentrieren.
      Der beste Weg zu Work-Life-Balance ist, beides zu trennen. Das ist auch einer der Gründe, warum ich Homeoffice nicht mag. Der Arbeitsweg mit dem Auto ist für mich ein hervorragender Trenn- und Dekompressionsmechanismus.
  • Die Aussage, man könne sich nicht krankmelden mit „Mir geht es psychisch schlecht, ich nehme mir einen Tag frei“, stimmt nicht.
    Man kann sagen, dass man einen Mental-Health-Tag braucht, und Erwachsene verstehen das.

    • In den meisten Unternehmen, in denen ich gearbeitet habe, reichte „Ich fühle mich heute nicht gut und nehme mir einen Tag frei“.
      Niemand fragte nach Details.
    • „Erwachsene verstehen das“ ist eine ziemlich blasenhafte Erfahrung.
      In den meisten Berufen ist das nicht so.
    • Vielleicht ist das dort so, wo du arbeitest, aber ich sage einfach, dass ich nicht zur Arbeit komme.
      Wenn ich das meinem Lead oder Vorgesetzten so sagen würde, würden sie nachhaken, warum ich nicht komme.
    • Aus demselben Grund kann man auch einen Wellness Day nehmen.
  • Ich bin zu der Überzeugung gelangt, dass in der Praxis der Softwareentwicklung selbst etwas steckt, das psychische Erkrankungen auslöst oder auslösen kann.
    Über Jahrzehnte habe ich gesehen, wie einige Kollegen sehr schwere Probleme hatten, und ich glaube, dass das in unserer Branche wirklich ein ziemlich ernstes Problem ist.

    • Software Engineering scheint Menschen mit Neurodiversität anzuziehen.
      Ich bin Software Engineer mit ADHS und kenne ungewöhnlich viele ADHS-Software-Engineers.
      Dieses Ausmaß an Störungen der exekutiven Funktionen und ständigem „Aufholen“ wird zum Problem.
    • Damit man sich besser fühlt, braucht man Erfolgserlebnisse oder Projekte mit einem Ende.
      Viele Projekte laufen jedoch Jahr für Jahr endlos weiter, bis dem Unternehmen oder einem selbst die Energie ausgeht oder man zu einer anderen Firma wechselt und dasselbe wiederholt.
      In der Webentwicklung ist der Launch-Termin die nächstgelegene Ziellinie, aber keine echte Ziellinie. Das Erreichen zentraler Kennzahlenziele zählt gewissermaßen auch dazu, ist psychologisch aber nicht so befriedigend wie einen Tisch oder Keramik fertigzustellen oder eine Ernte einzubringen und zu verkaufen oder zum Abendessen zu servieren.
    • Diese Branche besteht im Kern darin, bewusstes Denken in Kapital umzuwandeln, und zwar so effizient wie möglich.
      Daher ergibt es Sinn, dass sie schlecht für den Geist ist.
    • Ein großer Teil des Stresses entsteht aus der Verantwortung, „etwas“ zum Laufen zu bringen, obwohl sich die Definition dieses „Etwas“ wegen der Launen von Kollegen, mangelnder Weitsicht oder schlechter Planung drastisch ändern kann.
    • Letztlich ist das, was wir tun, größtenteils Schreiben.
      Man muss nur schauen, wie gut andere Autoren damit zurechtkommen und leben. Besonders diejenigen, die wegen der Miete viele Stunden lang Texte schreiben müssen, von denen sie wissen, dass sie wertlos sind.
  • Die Beschreibung aus dem Jahr 2017, dass er versucht habe, alle Unsicherheit um sich herum zu kontrollieren, klingt so, als würde jemand sich selbst die Schuld dafür geben, in einem albtraumhaften Arbeitsplatz in einer miserablen Firma durchgehalten zu haben.

  • So jemand hätte niemals in eine Führungsposition kommen dürfen.
    Ich habe unter so einem Typ gearbeitet: Er war selbst ein hervorragender Engineer, aber als Lead miserabel.
    Kein Vertrauen ins Team, macht immer alles selbst, keine Diskussionen, Gespräche durch die Hintertür, und gegenüber den Wünschen des Managements knickt er immer ein. Alles ist „wichtig“ oder „kritisch“, und es ist Mikromanagement in schlimmster Form.
    Gleichzeitig hätte ich, wenn ich in dieser Position gelandet wäre, vermutlich ähnlich versagt, wenn auch weniger stark. Das Management bringt uns oft ohne wirklich guten Grund in unmögliche Situationen, außer um „bei X gut dazustehen“.
    Noch schlimmer ist es, wenn das passiert, um bei irgendeinem namenlosen mittleren Manager Punkte zu sammeln.
    Deshalb fände ich Gewerkschaften in der Tech-Branche sinnvoll. Sie könnten realistische Erwartungen setzen und dem Management mit einer kollektiven Perspektive begegnen.
    Leider zielen Unternehmen heutzutage nur darauf ab, Venture-Kapital über schnelle Exits und IPOs zurückzuholen. Die allgemeine Stimmung unter den Geiern scheint zu sein, dass Gewerkschaften die Chance auf einen schnellen Exit verringern.

    • Das ist ein Organisationsversagen.
      Die Organisation hat jemanden befördert, ohne ihn zur Führungskraft auszubilden.
      Von Managern ohne technischen Hintergrund erwartet man ja auch nicht, dass sie einfach anfangen zu coden – warum erwartet man dann von Codern, dass sie einfach anfangen zu managen?
    • „Dem Team nicht vertrauen und immer alles selbst machen“ war eine der Lektionen, die für mich am schwersten zu lernen waren.
      Auch beim Coaching angehender Führungskräfte ist das häufig ein Hindernis.
      Wenn man in eine Führungsrolle wechselt, muss man lernen zu akzeptieren, dass Menschen Dinge auf eine andere Weise erledigen, als man selbst es tun würde.
      Wenn das Ergebnis eines Mitarbeiters fast gut genug oder gut genug ist, muss man es akzeptieren. Und der Spielraum dafür, was „gut genug“ ist, ist wahrscheinlich viel größer, als man vor dem Lernen glaubt.
    • Ich hatte auch einmal so einen Chef.
      Vielleicht war das Unternehmen besonders dysfunktional, aber ich hatte nicht viel Erfahrung mit den mir zugewiesenen Projekten und Aufgaben und habe das auch nicht versteckt.
      Wenn ich mir dann Zeit nahm, um es selbst herauszufinden, machte mein Chef es einfach selbst und gab kein Feedback.
    • Zu sagen, jemand hätte „niemals Führungskraft werden dürfen“, ist eine zu starke Vereinfachung.
      In Wirklichkeit hätte es konkrete Schulungen zu Priorisierung, Delegation und emotionaler Intelligenz gebraucht.
      Solche Schulungen werden selten angeboten. Stattdessen wirft man leistungsstarke Leute ins kalte Wasser und schaut, ob sie sich über Wasser halten können.
    • „Immer alles selbst machen“ ist einer der kontraintuitivsten Aspekte einer Führungsrolle.
      Man wird meist befördert, weil man als Individual Contributor viele Dinge selbst erledigt hat. Nach dem Wechsel in eine Führungsrolle ist es aber für einen selbst, das Unternehmen und die Teammitglieder umso besser, je weniger man selbst macht.
      Deshalb muss man lernen, dass es kein Zeichen dafür ist, schlecht zu arbeiten, wenn es sich weniger ausgelastet anfühlt als früher.
  • Es kann durchaus sein, dass man dem Team nicht sagen kann: „Ich nehme einen Krankheitstag, weil es mir psychisch schlecht geht.“
    Ich habe vor ein paar Jahren angefangen, genau das zu tun, und insgesamt war es eine positive Erfahrung. Weil ich zuerst offen mit meinen eigenen Schwierigkeiten umgegangen bin, haben auch andere im Team über ihre Schwierigkeiten gesprochen.