Bei der Arbeit nichts tun

• Die Leistung von Software Engineers wird weniger durch mehr Zeit oder mehr Code bestimmt als durch High-Impact-Arbeit zum richtigen Zeitpunkt; im Alltag ist eine Auslastung von 80 % wirksam, bei der man etwa 20 % des Arbeitstags nicht am Computer verbringt
• In großen Engineering-Organisationen können zeitabhängige Gelegenheiten wie die Unterstützung eines großen Vertrags, die Eindämmung eines Incidents oder der Launch einer wichtigen Funktion großen Wert schaffen; wer bereits ausgelastet ist, verpasst solche Chancen leicht
• Wer ständig Tickets mit niedriger Priorität abarbeitet, bekommt die Lage anderer Teams, Team-Updates oder laufende Incidents nicht mit, und für Manager ist es dann auch schwer zu erkennen, wer freie Kapazität hat
• Zeit, in der man nichts tut, ermöglicht Erholung von Stress, Ruhe bei der Reaktion auf Störungen, neue Ideen und Konzentration auf wichtige Arbeit
• Wer im Alltag bewusst Reserven lässt und nur in Phasen mit sehr hohem Ertrag mit 100 % Intensität arbeitet, schafft bessere Bedingungen, um ein leistungsstarker Engineer zu werden

---

High-Impact-Gelegenheiten

• Viele Engineers sollten weniger arbeiten; das bedeutet nicht, weniger Code oder weniger Änderungen zu liefern, sondern im Tagesverlauf tatsächlich weniger zu arbeiten und auch während der Arbeit langsamer zu arbeiten
• Im Normalzustand sollte man eine Auslastung von 80 % anstreben und, wenn kein Hochdruckprojekt läuft, 20 % der Arbeitszeit nicht am Computer verbringen
• Die Leistung von Tech-Unternehmen wird stark durch außergewöhnliche Ereignisse bestimmt, und viele der Änderungen mit dem größten Effekt können mit erstaunlich wenig Arbeitsaufwand erreicht werden
• In der Softwareentwicklung gibt es keine Punkte für bloßen Einsatz; entscheidend ist, das richtige Problem zum richtigen Zeitpunkt zu lösen

• Drei Beispiele aus großen Organisationen

  • Wenn ein großes Enterprise-Geschäft kurz vor dem Abschluss steht, kann Unterstützung bei einer Funktion oder einem Bugfix helfen, den Vertrag abzuschließen
  • Die Funktion muss nicht einmal großartig sein; manchmal reicht es schon, die Bereitschaft und Fähigkeit zu zeigen, eine konkrete Änderung umzusetzen
  • Wer einen Incident früh verhindert oder abschwächt, kann sowohl unmittelbare Umsatzverluste während des Vorfalls als auch spätere Verluste durch Kundenabwanderung oder abgelehnte Verträge reduzieren
  • Schon allein zu wissen, welcher Feature-Flag deaktiviert werden muss, kann große Summen sparen
  • Wenn ein Unternehmen eine wichtige Funktion launchen will, kann Erfolg oder Misserfolg von kleinen, aber schwer zu findenden Änderungen abhängen
  • Beispiele sind das schnelle Hinzufügen eines neuen Felds zu den Benutzereinstellungen oder das Reparieren einer veralteten Enterprise-Datenexportfunktion, die seit Jahren nicht angerührt wurde
  • Systemkenntnis kann den Unterschied machen zwischen einer Änderung, die ein paar Stunden dauert, und einer, die eine Woche dauert

• Zeitabhängigkeit

  • All diese Gelegenheiten sind zeitabhängig; man kann sich morgens nicht einfach einloggen und nach Belieben einen großen Vertrag retten, einen Incident abmildern oder schnell eine wichtige Funktion bauen
  • Es reicht nicht, nur zur richtigen Zeit am richtigen Ort zu sein; man darf dann auch nicht schon ausgelastet sein

Locker bleiben

• Wer bei 100 % Auslastung bleibt und ständig Aufgaben mit niedriger Priorität erledigt, verpasst High-Impact-Gelegenheiten auf zwei Arten
• Erstens bemerkt man die Gelegenheit oft gar nicht, wenn man zu beschäftigt ist
  • Man hat weniger Zeit, mit Leuten zu sprechen, die an anderen Dingen arbeiten, Team-Updates zu lesen oder laufende Incidents anzusehen
  • Der beste Weg, an High-Impact-Arbeit mitzuwirken, ist, die eigene Expertise freiwillig anzubieten
• Zweitens ist es für Manager schwer, jemanden einzubinden, der immer beschäftigt wirkt
  • Der zweitbeste Weg zur Beteiligung ist, dass ein Manager oder Product Manager einen vermittelt, weil er erkennt: „Hier ist noch Kapazität vorhanden.“
  • Manager und Product Manager sitzen in Meetings, an denen Engineers nicht teilnehmen, und wissen deshalb oft besser, welche High-Impact-Arbeit gerade läuft

Nichts tun

• Wenn man Zeit für High-Impact-Arbeit freihalten muss und nicht einfach nur weiter Tickets abarbeiten sollte, dann ist es auf Minutenebene tatsächlich in Ordnung, gar nichts zu tun
• Software Engineering kann ein stressiger Beruf sein, aber meistens kein dauerhaft stressiger
  • Stress entsteht eher in gelegentlichen Incidents, dringenden Hochdruckphasen oder Situationen wie jüngsten Entlassungen
• Wenn man selbst Phasen mit relativ geringem Druck mit derselben Dringlichkeit angeht, ist man bereits erschöpft und gereizt, wenn wirklich hoher Druck entsteht
• Auch in Hochdruckphasen kann eine Haltung des Nichtstuns hilfreich sein
  • Engineers ohne viel On-Call-Erfahrung sollten nicht hetzen und lieber ein paar Mal tief durchatmen, bevor sie in einen Call gehen oder sprechen
  • Bei der Incident Response braucht man insgesamt „Denken in langsamer Bewegung“
• Die meisten Incidents lösen sich von selbst, und hastig eingespielte Änderungen, die „vielleicht helfen“, verschlechtern die Lage oft eher, als dass sie sie verbessern
• Im Allgemeinen ist man bei der Incident Response bereits besser als die meisten Engineers, wenn man nur Panik vermeidet
• Zeit, in der man nichts tut, schafft Raum dafür, dass etwas passieren kann
  • Wenn das Gehirn Gelegenheit zur Ruhe bekommt, entstehen eher neue Ideen
  • Wenn man wichtige Arbeit bekommt, kann man sich voll darauf konzentrieren, statt im Hintergrund gleichzeitig drei andere Dinge weiterzutreiben
  • Wenn man nicht beschäftigt ist, hat man einfach Zeit, Dinge anzusehen und neue Informationen aufzunehmen

Bestimmte Dinge absichtlich nicht tun

• Viele Engineers fühlen sich unwohl dabei, etwas nicht zu tun, obwohl sie sehen, dass es getan werden könnte
• Diese Neigung ist ein psychologisches Merkmal, das viele Software Engineers teilen und das sie bis zu einem gewissen Grad überhaupt erst gut für diesen Beruf geeignet macht
• Um Zeit fürs Nichtstun zu schaffen, muss man sich manchmal bewusst dazu zwingen, sich nicht einzumischen

• Glue Work vermeiden

  • Engineers sollten Glue Work im Allgemeinen vermeiden
  • Damit sind Dinge gemeint wie Leute miteinander ins Gespräch zu bringen, Dokumentation für Arbeit zu aktualisieren, die man nicht selbst leitet, oder Ressourcen für den Abbau technischer Schulden zu organisieren
  • Die meiste Glue Work spiegelt wider, dass die Organisation diese Arbeit nicht ausdrücklich priorisiert hat
  • Wenn die Organisation sie priorisieren würde, müsste sich keine einzelne Person freiwillig dafür melden
  • Wenn es in Ordnung ist, dass die Organisation sie nicht priorisiert, dann ist es Zeitverschwendung, sie zu übernehmen, und es kann den Manager verärgern
  • Selbst wenn es ein großer Fehler der Organisation ist, sie nicht zu priorisieren, sorgt die Einzelperson durch das Einspringen nur dafür, dass das Unternehmen die Folgen seines Fehlers nicht spürt, während Karriere und psychisches Wohlbefinden der Person den Preis zahlen
  • Das ist ein schlechter Tausch für die Einzelperson, ein schlechtes Beispiel für Junior-Kollegen und nach einem Burnout ein schlechtes Präzedenzbeispiel, wenn jemand anderes in dieselbe Rolle rutscht
  • Wenn die Folgen wirklich gravierend sind, sollte man sie eintreten lassen, damit die Organisation den Schmerz spürt und ihre Regeln ändert

• Zu viel Hilfsbereitschaft macht verwundbar

  • Zu stark helfen zu wollen macht einen verwundbar gegenüber Menschen, die unbezahlte Arbeit aus einem herausziehen wollen
  • In Tech-Unternehmen gibt es viele Menschen, die versuchen, Software Engineers Arbeit abzuverlangen, die nicht vergütet wird
  • Das ist etwas anderes als Arbeit, die über den normalen Weg kommt und durch Beförderung, Bonus oder reguläres Gehalt vergütet wird
  • Problematische Arbeit kommt über informelle Wege und von Leuten, die sie nicht offiziell unter dem eigenen Namen dokumentieren können oder wollen
  • Ein Beispiel ist ein Product Manager aus einer anderen Organisation, der einen bittet, bestimmte Kennzahlen abzufragen, weil man gut mit Datenabfragen ist
  • Ein anderes Beispiel ist ein Engineer aus einem anderen Team, der um Pairing bittet, in Wirklichkeit aber möchte, dass man den gesamten Code schreibt und die Änderung dann unter seinem Namen einreicht
  • Es ist in Ordnung, einen Teil solcher Arbeit zu übernehmen und Leuten zu helfen, wenn es gerade passt
  • Man sollte aber in der Lage sein, Gegendruck auszuüben, indem man ablehnt oder erst Stunden oder Tage später antwortet

• Nicht zu viel in Arbeit investieren, die wahrscheinlich verschwindet

  • Es ist besser, nicht zu viel in Arbeit zu investieren, die wahrscheinlich wieder verschwindet
  • Wenn ein Product Designer in Echtzeit herausfindet, was er eigentlich will, sollte man nicht jede Stunde die gesamte Seite komplett neu schreiben
  • Ein Beispiel ist, dass um 9 Uhr ein Seitenkopf auf eine Weise gewünscht wird, um 10 Uhr geändert wird und um 11 Uhr erneut anders aussehen soll
  • In solchen Fällen ist es besser, nichts zu tun, etwa spazieren zu gehen, und die Seite am Nachmittag einmal anhand des neuesten Designs neu zu schreiben
  • Ein weiteres häufiges Beispiel ist die große Idee eines Managers ohne ausreichenden politischen Rückhalt
  • Oft kann man einfach Zeit verstreichen lassen, bis das Projekt eingestellt wird
  • Wenn man den Grad der politischen Unterstützung für ein Projekt allerdings falsch einschätzt, kann man faul wirken und später in Zeitnot geraten

Fazit

• Ratschläge und Tools im Software Engineering sind oft darauf ausgerichtet, die technische Kapazität zu steigern, also gleichzeitig mehr zu erledigen, Projekte mit größerem Umfang zu übernehmen und mehr Code zu schreiben
• Erfolg im Software Engineering wird dadurch jedoch nicht bestimmt
• Erfolg wird durch die Fähigkeit bestimmt, das Richtige zum richtigen Zeitpunkt zu tun, und dafür muss man im Tagesgeschäft bewusst einen Teil seiner Energie zurückhalten
• Es ist möglich, schon mit 80 % Einsatz ein leistungsstarker Engineer zu sein; tatsächlich verringert das eher dumme Fehler durch Stress und macht es leichter, bei High-Impact-Arbeit mit großem Ertrag einzuspringen
• Es gibt Zeiten, in denen man mit 100 % Einsatz arbeiten muss; ein- oder zweimal oder auch dreimal im Jahr kann man über längere Zeit mit starker Konzentration und der gedanklichen Beschäftigung mit dem Problem den ganzen Tag arbeiten
• Diese Arbeitsweise sollte man für Phasen aufheben, in denen die Belohnung wirklich groß ist; in der übrigen Zeit ist es besser, vergleichsweise entspannt zu arbeiten

[GN⁺]

Hacker-News-Kommentare

• Guter Artikel, aber am Ende zeigt sich wieder, dass Anreize das Problem sind
  Es stimmt zwar, dass man viel Geld sparen kann, wenn man Probleme früh verhindert oder abmildert, aber was ich in mehreren Firmen immer wieder gesehen habe, ist, dass Prävention nicht anerkannt wird, während jemand, der erst einen riesigen Haufen Zunder auftürmt und dann den unvermeidlichen Brand löscht, dafür gleich zweimal Anerkennung bekommt. Selbst in „guten“ Organisationen war das so
  In diese spieltheoretische Politik, absichtlich schnell schlechten Code auszuliefern und dann die Lorbeeren dafür einzusammeln, konnte ich mich nie wirklich hineindenken. Ich war einfach zu stolz auf meine Arbeit
  Ich habe über fünf Jahre lang ein Framework betreut und ausgebaut, das eine ganze Klasse von Problemen beseitigte, die frühere Produktversionen geplagt hatten. Aber das Partnerteam, das schlechten Code deployte, Ausfälle verursachte und sie dann behob, wurde öffentlich gelobt, während unser Team keinerlei Anerkennung bekam, gerade weil es diese Ausfälle nicht gab. Das ist eben nicht messbare Prävention

  • Spieltheoretisch müsste ein Team, das wiederholt Probleme verursacht und dadurch Kunden verliert, entsprechend bestraft werden. Wenn das nicht passiert, kann es auch sein, dass die Probleme durch schnelles Ausliefern die Kundenbindung gar nicht so stark beeinflussen, wie man denkt
  • Einfach überall Thread.sleep(100000) einbauen und warten, bis etwas kaputtgeht. Dann ist man derjenige, der bis Freitag Mitternacht nach dem Release lang und heldenhaft Brände löscht
    Man sollte nur nicht fragen, warum das belohnt wird, und natürlich ändern Organisationen gelegentlich auch mal ihre Maßstäbe dafür, was sie belohnen
  • Zu der Aussage „Man bekommt keine Anerkennung dafür, dass es diese Ausfälle nicht gab, weil sich das nicht messen lässt“: Philosophisch gesehen denke ich, dass man auch das Gewicht des Nichts messen kann
  • Leider ist das vollkommen richtig, aber nicht der einzige Weg
    Ein ehrlicherer Ansatz ist, ein paar komplexe, aber unverzichtbare Tools zu bauen, wegen derer andere Engineers immer wieder zu mir kommen. Man wird dann sehr gut darin, Missbrauch eines bestimmten Tools zu erkennen, und wenn man Bugs in fremdem Code in Sekunden aufspürt, wirkt man viel schlauer, als man tatsächlich ist
    Idealerweise sind die Tools zuverlässig, nützlich und zugleich komplex. Wenn andere Entwickler bei der Nutzung auf Bugs stoßen, kommen sie weiter zu dir, und du kannst auf ihre Fehler hinweisen. Damit diese Strategie funktioniert, müssen die Fehler fast immer auf der anderen Seite liegen, und mein eigener Code muss robust sein
    Wenn in meinem Code ein echter Bug gefunden wird, möglichst ein kleiner Grenzfall, sollte man sehr demütig und entschuldigend reagieren und in der Teamsitzung den Entwickler loben, der diesen komplexen Bug entdeckt hat
    Das ist besser, als Anerkennung dafür zu bekommen, den eigenen fehlerhaften Code zu reparieren. Das mag bei Managern oder Juniors funktionieren, aber andere Senior Engineers werden das nicht mögen
    Komplexe, aber stabile Tools zu bauen, führt wiederholt zu Anerkennung, oft sehr viel öfter als nur zweimal, und die Anerkennung anderer Entwickler dringt am Ende auch zu den Ohren des Managements vor. Kluge Führungskräfte wissen, dass dieses Signal besser ist als eine spektakuläre Demo
    Führungskräfte, die einen bestimmten Entwickler nur dafür mit Lob überschütten, dass er schnell Prototypen baut, lernen ihren Fehler am Ende meist noch. Junge Gründer scheinen diese Phase, Oberflächliches zu loben, oft zu durchlaufen
  • Wenn man den Gegensatz so aufzieht, stimme ich zu, aber etwas mehr Nuance ist nötig
    Ein Teil davon, ein Produkt oder ein Paket von Features zu bauen, ist eher Erkundung als exzellentes Engineering. Manchmal ist es besser, zwei ausreichend gute Features zu bauen, um herauszufinden, was für Nutzer wertvoll ist, als ein einziges wirklich solides Feature
    Ich war immer eher auf der Seite von „Lass es uns einfach ausprobieren und sehen“. Allerdings bin ich auch dankbar, dass jemand mit einer anderen Haltung git gebaut hat
    Es braucht hier Balance, und es hängt davon ab, wie sehr das Problem, an dem man gerade arbeitet, ein Erkundungsproblem ist. „Solide“ bedeutet hier Dinge wie Verfügbarkeit, Wartbarkeit oder die Möglichkeit, dass sensible Fotos von Nutzern nach außen dringen – also aus einer rein technischen Perspektive

• Der Teil über „Menschen, die unbezahlte Arbeit aus einem herauspressen wollen“ ist reif zum Einrahmen
  Besonders Situationen wie wenn ein Produktmanager aus einer anderen Organisation sagt: „Du kennst dich gut mit Datenabfragen aus, könntest du mir bitte ein paar Statistiken zu X ziehen?“ oder wenn ein Engineer aus einem anderen Team um „Pairing“ bittet und am Ende ich den ganzen Code schreibe und er die Änderung still unter seinem eigenen Namen einreicht

  • Wo ich arbeite, ist Principal Engineer ein Titel, den alle wollen, der gut vergütet wird, aber nur selten erreicht wird. Alle, mit denen ich in dieser Rolle gearbeitet habe, waren äußerst fähig und auch menschlich angenehm, und einen davon habe ich einmal gefragt, wie er in seiner vorherigen Firma an diesen Titel gekommen ist
    Seine Strategie war, Menschen zu helfen und Anerkennung aktiv weiterzugeben. In 1:1s oder Meetings mit mehreren Management-Ebenen hob er immer wieder den Wert der Arbeit seiner Teammitglieder hervor, und dadurch gewann er viel Sympathie im Team
    Als dann Jahre später ein Projekt mit sehr viel Geld auf dem Spiel hinter dem Zeitplan lag und mehrere Schlüsselingenieure gekündigt hatten, machte er Überstunden und führte das Projekt zum Erfolg. In der nächsten Beurteilung bekam er den Titel und eine Gehaltserhöhung
    Dieses Projekt war zwar der letzte Schub, aber er war nicht der einzige Engineer, der Überstunden gemacht hatte. Er sah seine Beförderung als Ergebnis des Wohlwollens, das er sich aufgebaut hatte, indem er anderen Anerkennung zuschrieb
  • Ich denke, das hängt davon ab, wie stark der Vorgesetzte involviert ist. Ein Typ Mensch, mit dem ich nicht zusammenarbeiten möchte, ist jemand, der sagt: „Das ist nicht mein Job“
    Ich möchte mit Leuten arbeiten, die ein Problem sehen und eine Lösung vorschlagen, egal ob es in ihrer Stellenbeschreibung steht oder nicht
    Wenn meine Arbeit nicht anerkannt wird, dann ist das ein Führungsproblem. Arbeit einfach kategorisch abzulehnen fühlt sich für mich wie ein Weg in eine erstarrte, langsame Organisationskultur an
  • Ein Satz zum Einrahmen ist: „Bitte machen Sie dafür ein Ticket auf“
  • Das stimmt, aber ich sehe es nicht ganz so schwarz-weiß. Es gibt neben dem direkten Kümmern um die eigene Anerkennung auch Anreize, der Firma insgesamt zum Erfolg zu verhelfen, daher kann es vernünftig sein, kleine Bitten zu erfüllen, auch wenn man dafür keine Parade bekommt
    Genauso könnte ich selbst irgendwann einmal etwas von einem Kollegen brauchen, und dann wäre ich dankbar, wenn er proaktiv hilft, statt mich mit „Bitte über die offiziellen Kanäle“ abzuweisen. Die offiziellen Kanäle können viel länger dauern
  • Gute Firmen haben eine Kultur, und die Leute helfen einander
    Gespräche beim Mittagessen können zum Beispiel dabei helfen, dass Menschen etwas besser verstehen
    Jemandem allerdings mehrere Stunden Arbeit abzunehmen, kann noch einmal eine ganz andere Sache sein

• Das ist nicht spöttisch gemeint, eher eine Beobachtung, aber in ausreichend großen oder bürokratischen Organisationen ist es schwer, Anerkennung oder Sichtbarkeit dafür zu bekommen, wenn man Probleme im Voraus verhindert. Solche Leistungen fallen unter „gehört sowieso zum Job“.
  Deshalb entscheiden sich Leute, die gut in Unternehmenspolitik sind, eher dafür, Zwischenfälle geschehen zu lassen und dann bei den Folgemaßnahmen lautstark aktiv zu werden. Der Trick besteht darin, den Vorfall nicht zur Katastrophe werden zu lassen, und das ist ziemlich filigrane Arbeit.

  • Das habe ich früh in einer konservativen Organisation gelernt. Prävention ist riskant. Besser ist es, eine Lösung bereitzuhalten, falls etwas schiefläuft; erst dann lässt sie sich genehmigen.
  • Alle Beispiele für großen Einfluss wirken wie Arbeit, für die man nur schwer Anerkennung bekommt.
    Wenn man einen Verkaufsvertrag rettet, bekommt das Vertriebsteam den Applaus und auch die Provision. Ich bekomme keinen Anteil davon.
  • Katastrophen können für die Führungsebene auch ein gutes Signal sein, dass es in der Organisation Probleme gibt. Wenn man heroisch jedes Feuer löscht, merkt es der Vorgesetzte vielleicht, aber der Vorgesetzte des Vorgesetzten des Vorgesetzten sieht nur, dass die Organisation hervorragend läuft und alles auf Grün steht.
    Wenn man zulässt, dass ein paar Dinge anbrennen, sieht der Vorgesetzte des Vorgesetzten des Vorgesetzten dieses Feuer, und vielleicht wird etwas verbessert. Vielleicht ist das sogar der einfachste Weg, mit ihnen zu kommunizieren.
  • Entscheidend ist, ob die Leute es überhaupt bemerken. Ich habe gehört, dass in Kommunalverwaltungen manchmal beliebte Programme gestrichen werden, um Widerstand auszulösen, und man sich dann die Wiederherstellung als Verdienst anrechnet. In der Zwischenzeit kann man auch andere notwendige, aber unpopuläre Maßnahmen dazwischenschieben.
  • Karrieren werden oft durch Heldentum gemacht, und dafür werden Boni gezahlt.

• Ich hatte vor langer Zeit schon einmal halb einen Text in diese Richtung geschrieben und dabei eine Fantasy-RPG-Metapher benutzt. Wenn man in solchen Spielen einen Charakter spielt, der Mana verbraucht, lernt man schnell, dass man nicht in jedem kleinen Kampf sein ganzes Mana verballern und dann leer herumlaufen sollte, nur um im entscheidenden Moment nichts mehr übrig zu haben.
  Mit der mentalen Energie, die man bei der Arbeit verbraucht, ist es nicht sehr anders. Wenn man etwas im Tank lässt, kann man bei unerwarteten Ereignissen strategisch damit umgehen, ohne die eigene Gesundheit, also Burnout, zu riskieren.
  Wenn man in solchen Spielen schon einmal mit jemandem in einer Gruppe war, der sein Mana nicht managen kann, weiß man auch, dass diese Person kein besonders guter Teamkollege ist.

  • Ich habe gemerkt, dass es extrem schwer werden kann, die nächste Herausforderung zu meistern, wenn man eine Zeit lang nicht ausreichend gefordert war.
    In jedem Bereich waren meine Fähigkeiten dann am stärksten, wenn genug Arbeit vor mir lag, sodass ich sie gleichmäßig wie eine Maschine abarbeiten konnte, und ich genug Vertrauen bekam, um unbehelligt auf ein Ziel hinzuarbeiten, statt ständig zum Erklären unterbrochen zu werden. Dann wuchsen die Fähigkeiten wie ein Flächenbrand, und die Arbeit war schneller fertig als erwartet.
    Leider sind Arbeitsplätze, die eine solche Struktur nutzen, sehr selten. Es gibt zu viele Blocker und Unterbrechungen, die einen daran hindern, in echte Deep Work zu kommen.
  • Bei mir würde ein RPG damit enden, dass ich 29 Ether übrig habe, obwohl es viel weniger Grind gewesen wäre, wenn ich sie früher benutzt hätte.

• Wenn man ein System zum Zusammenbruch bringen will, lässt man den Regelbetrieb auf 100 % laufen. Dann gibt es keinen Puffer und keine Kapazität, neue Nachfrage aufzunehmen, also reicht schon eine kleine Störung, damit das System dauerhaft in den Fehlermodus kippt.

  • Effizienz ist der Feind von Resilienz.
  • Allerdings kommt der Kollaps nicht. Wenn Ingenieure ausbrennen oder altern, stellt man einfach neue Leute ein, und der Zyklus wiederholt sich.
    Das Problem bei solchen Texten oder Büchern wie Peopleware / Slack ist, dass sie keine ausreichend überzeugenden harten Kennzahlen liefern, damit die Leute im Rechnungswesen bereit wären, einen anderen Ansatz auszuprobieren.

• Die Metapher, die meine Perspektive verändert hat, kam aus „The Power of Full Engagement“. Sinngemäß hieß es: „Du verhältst dich wie ein Weltklasse-Ausdauersportler ohne Off-Season. Hör damit auf.“

• Hier steckt viel Weisheit drin. Zusätzlich dazu, etwas Kapazität für den Fall zurückzuhalten, dass wirklich wertvolle Arbeit auftaucht, glaube ich, dass man in der Softwareentwicklung nicht gut sein kann, wenn man nur ständig beschäftigt ist.
  Wenn man versucht, so schnell wie möglich Code zu schreiben, entsteht nur selten ein gutes Design. Dieser Text behandelt allerdings nicht einen weiteren wichtigen Aspekt: wie man mit 80 % Auslastung arbeitet, ohne vom Management Ärger zu bekommen.
  Dafür braucht es etwas Sorgfalt bei Kommunikation und Aufwandsschätzung. Einer der besten Ratschläge, die ich in meinem ersten echten Programmierjob von älteren, erfahrenen Entwicklern bekommen habe, ist mir bis heute geblieben: Schätze, wie lange etwas dauern wird, und verdopple es, bevor du es dem Management oder den Nutzern nennst.
  Mit mehr Erfahrung kann der Faktor vielleicht von 2 auf eher 1,5 sinken, aber das Prinzip gilt weiterhin.

  • Kent Beck sagte entweder in Good News Factory oder in einem Vortrag, dass sein Team niemals mehr als die Hälfte von dem zugesagt habe, was es selbst für machbar hielt. Das ist gut für Nachhaltigkeit.
    Optimieren und zum Vorbild nehmen sollte man die Fähigkeit, langfristig beständig mit nachhaltigem Tempo zu liefern. Es ist ein langes Spiel, und zu viel zu versprechen untergräbt nur das Vertrauen. Genau dieses Vertrauen ist aber eines der wichtigsten Mittel, mit denen Entwickler sich den nötigen Freiraum verschaffen.
    Man muss weniger versprechen, dann zuverlässig liefern, was man zugesagt hat, und sich so den Raum verschaffen, nicht auszubrennen.
    Je senioriger man wird, besonders als Lead, desto mehr wird Grenzen setzen, Aufmerksamkeit bewahren und Burnout verhindern selbst zur Arbeit. Es gibt einfach zu viele Wege, sich selbst kaputtzumachen.
  • „Verdopple deine Zeitschätzung, bevor du sie dem Management oder den Nutzern nennst“ stimmt zwar, aber ich frage mich, ob dabei Hofstadters Gesetz berücksichtigt wurde.
    Selbst wenn man Hofstadters Gesetz berücksichtigt, dauert alles immer länger als erwartet.
    https://en.wikipedia.org/wiki/Hofstadter%27s_law

• Aus der Sicht von jemandem, der viel in kundennahem Umfeld gearbeitet hat, war eine der schlimmsten Fallen, denen ich mehrfach begegnet bin, mit zahlenden Kunden freundschaftlich zu werden. Wenn man als Experte engagiert ist, um zu helfen, und der Kunde wirklich ein netter Mensch ist, wird Nein sagen absurd schwer.
  Noch schlimmer ist es, wenn diese Person nicht der Entscheidungsträger ist, sondern selbst in der Position steckt, mir etwas aufzudrängen. Als vertrauenswürdiger Experte kann ich leicht Nein sagen, wenn der Kunde selbst mit einer schlechten Idee kommt; aber wenn Anweisungen von dessen Vorgesetztem kommen, mit dem ich nie direkt zu tun habe, lande ich in der Position, entweder wie nutzloser Kostenaufwand auszusehen oder als Ja-Sager ein Monster zu hinterlassen.
  Manchmal beneide ich Leute, die hauptsächlich intern gearbeitet haben. Sie hatten zumindest die Chance, irgendwen weiter oben irgendwie zu überzeugen.

• Der Teil über Glue-Arbeit ist interessant; als ich in einem Großunternehmen gearbeitet habe, war das ein expliziter Teil der jährlichen Leistungsbeurteilung. Google nannte das „citizenship“, und ich finde, das trifft den Kern ziemlich gut. Gemeint war: „Was hast du verbessert, damit es für den Rest des Unternehmens besser funktioniert?“
  Einerseits war das etwas seltsam. Es stand nicht in meiner Stellenbeschreibung und war technisch gesehen also unbezahlte Arbeit, zugleich war es aber Teil der offiziellen Erwartungen. Andererseits war es gut, an einem Ort zu arbeiten, an dem alle ein wenig Zeit und Mühe investieren, um die Umgebung für alle zu verbessern
  Wenn man es für alle zu einer expliziten Anforderung macht, ist das auch ein Versuch, die toxische Kultur zu umgehen, in der jemand sagt: „Ich bin ein Rockstar-Ingenieur und mit wichtigen Dingen beschäftigt, also soll jemand anders die Glue-Arbeit machen.“ Außerdem war dieses „jemand anders“ meist eine Frau und wurde mit ziemlicher Sicherheit schlechter bezahlt als dieser Rockstar-Ingenieur
  Der Originalbeitrag impliziert, Unternehmen sollten gezielt Leute für Glue-Arbeit einstellen, aber in der Praxis besteht sie aus zu vielen unterschiedlichen Einzelteilen, als dass man sie einfach einer Person übertragen könnte. Was wäre zum Beispiel ein Jobtitel, der zugleich „Dokumentation schreiben, Bewerbungsgespräche für Software Engineers führen und Team-Offsites organisieren“ umfasst?
  Aber all diese Aufgaben waren nötig, und die citizenship-Anforderung half dabei, die Last fairer zu verteilen
  Die bessere Formulierung ist aus meiner Sicht nicht „Mach keine Glue-Arbeit“, sondern „Sei nicht der einzige Depp, der unbezahlte Glue-Arbeit macht.“ Das heißt: Alle sollten einen Teil davon übernehmen, und man sollte eine Kultur fördern, in der das offiziell als Arbeit anerkannt wird

• Mit 80 % Auslastung zu arbeiten ist eine gute Gewohnheit und hilft, wenn es keinen aufsichtführenden Micromanager gibt, der jeden Tag durchgehend 100 % verlangt. Solche Leute missverstehen es als faule Untätigkeit, wenn Software Engineers ruhig und entspannt dasitzen und nachdenken
  Deshalb ist Remote-Arbeit die beste Methode, um einen Teil der Auslastung als Reserve zu behalten und die psychische Gesundheit zu schützen
  Ein bisschen Glue-Arbeit kann den Arbeitsalltag für alle deutlich besser machen, und wenn sonst niemand weiß, wie man das angeht, kann es dich im Team zu einer unverzichtbaren Person oder sogar zu einem Helden machen

  • Ich finde sogar 80 % noch hoch. Und es ist von Entwickler zu Entwickler unterschiedlich
    Wenn ich bedenke, wie schwer ich mich mit Lernen, Nachdenken und dem Anfangen tue, sind meine 80 % überhaupt nicht dasselbe wie die 80 % eines technisch stärkeren Kollegen
    Schon wenn man Neurodiversität auch nur ein wenig berücksichtigt, können die 80 des einen die 120 eines anderen sein