Warum dich Drama Entwicklungszeit kostet, die in keinem Ticket steht

Wer Software baut, betreibt oder ein IT-Team führt, kennt Wochen, in denen viel geredet und wenig gebaut wird. Um diese Wochen geht es hier: um Konflikte im IT-Team und die Frage, warum sie Entwicklungszeit kosten, die in keiner Statistik auftaucht. Die Beispiele stammen aus dem Alltag von Entwicklungsteams, mit Pull Requests, Team-Chat und Product Owner. Der Artikel erzählt, wie die Stressforschung seit den 1930er Jahren verstanden hat, was eine spitze Bemerkung im Kopf anrichtet, und was neuere Studien über Unterbrechungen und über unglückliche Entwicklerinnen und Entwickler herausgefunden haben. Wer den Mechanismus kennt, sieht schneller, wo die Woche eigentlich hingeht.

Ein Bug ist eine ehrliche Sache. Er hat eine Ursache, die man finden kann, einen Stacktrace, wenn man Glück hat, und ein Ticket, in dem jemand die Zeit bucht. Wenn er behoben ist, ist er behoben. Am Ende des Sprints steht er in der Statistik, und jeder kann sehen, was er gekostet hat.

Drama hat nichts davon. Es hat kein Ticket, keinen Stacktrace und taucht in keiner Velocity auf. Trotzdem weiß jeder, der in einem IT-Team arbeitet, wie sich ein Tag anfühlt, an dem man acht Stunden im Büro war und am Abend nicht sagen kann, was man eigentlich gebaut hat.

Wo die Zeit bei Konflikten im IT-Team hingeht

Eine Liste macht das am besten greifbar. In vielen IT-Teams sieht eine normale Woche so aus:

• Das Pull-Request-Review, das zu einer Grundsatzdiskussion über Code-Stil wird, weil zwei Kolleginnen seit Monaten aneinandergeraten.
• Die Nachricht im Team-Chat, die du dreimal umformulierst, damit sie niemand falsch versteht.
• Die halbe Stunde nach dem Termin mit dem Product Owner, in der ihr euch gegenseitig erzählt, wie unmöglich das alles war.
• Der Kollege, der eine Entscheidung so lange infrage stellt, bis niemand mehr Lust hat, sie umzusetzen.
• Die Architekturentscheidung, die nicht fällt, weil niemand den Konflikt mit dem anderen Team eröffnen will.
• Das Gespräch in der Kaffeeküche über den Teamlead, der „mal wieder“ etwas versprochen hat.
• Der Abend, an dem du im Kopf noch das Meeting durchgehst und dir überlegst, was du hättest sagen sollen.
• Die Kündigung eines guten Entwicklers, der in der Übergabe sagt, es sei „wegen der Stimmung“.

Kein einziger dieser Punkte hat etwas mit Technik zu tun. Und jeder einzelne kostet Zeit, die eigentlich für saubere technische Lösungen gedacht war.

Warum Konflikte im IT-Team so teuer sind

Ein Bug kostet einmal Zeit. Drama kostet doppelt, weil es das Werkzeug beschädigt, mit dem du arbeitest: dein Denken.

Die Stressforschung hat dafür eine gute Erklärung. Richard Lazarus (1922–2002), ein US-amerikanischer Psychologe, der in Berkeley forschte, hat mit dem transaktionalen Stressmodell beschrieben, wie Stress im Kopf beginnt. Sein Kern: Stress entsteht, wenn wir eine Situation als bedrohlich einschätzen und gleichzeitig zweifeln, ob unsere Mittel reichen, damit fertigzuwerden. Als Bedrohung genügt dabei vieles, das den Körper gar nicht berührt: eine spitze Bemerkung im Review, eine Eskalationsmail an den Chef, ein Kollege, der vor allen widerspricht.

Sobald diese Einschätzung fällt, reagiert der Körper wie vor Zehntausenden Jahren: mehr Adrenalin, schnellerer Puls, ein Gehirn, das auf Überleben umschaltet. Das ist in echter Gefahr hilfreich. Beim Debuggen ist es katastrophal. Unter Stress denken wir vereinfacht, schwarz-weiß, kurzfristig. Genau die Art zu denken, die gute Software braucht, nämlich differenziert, geduldig, mit mehreren Möglichkeiten im Kopf, ist dann kaum noch verfügbar.

Der Teil, den keiner bucht

Damit erklärt sich auch, warum Drama in keiner Statistik auftaucht. Es frisst die Zeit in drei Formen:

1. Die sichtbare Zeit: Diskussionen, Eskalationen, Abstimmungsschleifen.
2. Die unsichtbare Zeit: die Minuten danach, in denen du wieder in den Code zurückfinden musst.
3. Die schlechtere Zeit: die Stunden, in denen du zwar arbeitest, aber mit einem Kopf, der noch im Konflikt hängt.

Die dritte Form ist die teuerste, und niemand misst sie. Sie zeigt sich später, als Bug, der beim nächsten Release auftaucht.

Der Nachmittag nach so einem Termin sieht oft gleich aus. Du kommst aus dem Meeting, setzt dich an den Rechner und starrst auf denselben Funktionsaufruf, den du vor einer Stunde noch verstanden hast. Oder du schreibst schnell einen Workaround, weil du heute keine Geduld mehr für die saubere Lösung hast. Oder du merkst erst am nächsten Morgen, dass dein Commit von gestern Abend Unsinn war.

Grundlagen: Stress am Arbeitsplatz und was er im Kopf von Entwicklern anrichtet

Dass eine spitze Bemerkung den Rest des Tages verderben kann, weiß jeder aus eigener Erfahrung. Warum das so ist, hat die Forschung in drei Schritten herausgefunden. Zuerst wurde Stress als Reaktion des Körpers beschrieben. Dann entdeckte man, dass die Bewertung einer Situation darüber entscheidet, ob diese Reaktion überhaupt anspringt. Und erst in den letzten zwanzig Jahren hat man genauer gemessen, was danach mit Aufmerksamkeit, Arbeitstempo und Codequalität geschieht. Die Geschichte führt von einem Labor in Montreal über Berkeley und Michigan bis zu einer Befragung von gut dreihundert Entwicklerinnen und Entwicklern.

Hans Selye: Stress als Antwort des Körpers

Am Anfang steht ein junger Mediziner, der eigentlich ein neues Hormon finden wollte. Hans Selye (1907–1982), in Wien geborener ungarisch-kanadischer Mediziner und Biochemiker, forschte in den 1930er Jahren in Montreal. Er spritzte Ratten verschiedene Gewebeextrakte und beobachtete, dass die Tiere immer dieselben Veränderungen zeigten, gleich, was er ihnen verabreichte. Dieselben Veränderungen fand er, als er die Tiere Kälte, Verletzungen oder Giften aussetzte. 1936 beschrieb er in einem kurzen Brief an die Zeitschrift Nature ein Syndrom, das durch die unterschiedlichsten schädlichen Einflüsse ausgelöst wird.

Daraus entwickelte Selye das Allgemeine Anpassungssyndrom mit drei Phasen:

1. Alarm: Der Körper mobilisiert seine Kräfte gegen die Belastung.
2. Widerstand: Er hält die erhöhte Leistungsbereitschaft aufrecht, solange die Belastung andauert.
3. Erschöpfung: Hält die Belastung zu lange an, brechen die Reserven ein.

Selye machte das Wort Stress in der Medizin heimisch und unterschied später den anregenden Eustress vom belastenden Distress. Sein Modell erklärt gut, warum eine Woche voller Konflikte müde macht, auch wenn in dieser Woche keine einzige zusätzliche Zeile Code entstanden ist. Und die dritte Phase, die Erschöpfung, beschreibt ziemlich genau den Entwickler aus der Liste oben, der nach Monaten voller Reibereien geht und in der Übergabe nur noch von der Stimmung spricht. Es erklärt aber eine Beobachtung nicht, die jeder aus seinem Team kennt: Derselbe Review-Kommentar lässt die eine Kollegin völlig kalt und verdirbt dem anderen den ganzen Tag. Für Selye kam der Stress aus der Belastung. Wo er im Kopf beginnt, blieb offen.

Richard Lazarus: Die Bewertung entscheidet

Diese Lücke schloss Richard Lazarus. Er wurde 1922 in New York geboren, wuchs in der Zeit der Weltwirtschaftskrise auf, studierte Psychologie, lehrte zunächst an der Johns Hopkins University und an der Clark University und forschte von 1957 bis zu seiner Emeritierung 1991 an der University of California in Berkeley.

Berühmt wurden seine frühen Filmversuche. Lazarus und seine Mitarbeiter zeigten Versuchspersonen einen verstörenden Film über ein schmerzhaftes Initiationsritual und maßen dabei die Leitfähigkeit ihrer Haut, ein Zeichen körperlicher Erregung. Lief derselbe Film mit einem ruhigen, sachlich-wissenschaftlichen Kommentar, sank die Erregung deutlich. Die Bilder waren dieselben. Verändert hatte sich nur, wie die Zuschauer sie einordneten. 1966 fasste Lazarus diese Arbeiten in „Psychological Stress and the Coping Process“ zusammen.

1984 folgte mit Susan Folkman, geboren 1938, US-amerikanische Psychologin und später Professorin an der University of California in San Francisco, das Buch, das bis heute die Grundlage der Stressforschung bildet: „Stress, Appraisal, and Coping“. Das Modell darin heißt transaktionales Stressmodell. Sein Kern ist eine Abfolge von Bewertungen, die meist in Sekundenbruchteilen und ohne unser Zutun abläuft.

1. Die primäre Bewertung: Ist das, was gerade passiert, für mich irrelevant, positiv oder gefährlich? Gefährlich kann dabei dreierlei heißen: eine Herausforderung, die ich meistern will, eine Bedrohung, vor der ich mich schützen muss, oder ein Verlust, der schon eingetreten ist.
2. Die sekundäre Bewertung: Reichen meine Mittel, damit umzugehen? Zu diesen Mitteln gehören Wissen, Zeit, Erfahrung, Unterstützung durch andere und die eigene Verfassung an diesem Tag.
3. Stress entsteht, wenn die erste Bewertung „gefährlich“ lautet und die zweite „Meine Mittel reichen nicht sicher aus“.
4. Die Bewältigung setzt dann ein, entweder am Problem selbst oder an den eigenen Gefühlen dazu. Lazarus und Folkman nannten das problemorientiertes und emotionsorientiertes Coping.
5. Die Neubewertung schließt den Kreis: Hat es funktioniert? Daraus lernt das Gehirn für das nächste Mal.

Die halbe Stunde nach dem Termin mit dem Product Owner, in der ihr euch erzählt, wie unmöglich das alles war, ist in dieser Sprache emotionsorientiertes Coping. Sie tut gut, weil sie den Ärger abbaut und das Gefühl gibt, mit dem eigenen Eindruck nicht allein zu sein. Am Problem selbst ändert sie nichts: Die Anforderung ist am nächsten Morgen dieselbe, und das Gespräch, das die Sache klären würde, hat niemand geführt. Lazarus und Folkman hielten beide Formen der Bewältigung für sinnvoll, je nachdem, ob sich an der Lage etwas ändern lässt. In vielen Teams überwiegt bei Konflikten die zweite Form, und deshalb kehren dieselben Konflikte wieder.

Ein Review-Kommentar wie „Das ist so nicht wartbar“ ist für eine erfahrene Entwicklerin vielleicht eine Herausforderung. Für einen Kollegen, der gerade unter Termindruck steht und sich ohnehin unsicher fühlt, ist derselbe Satz eine Bedrohung. Der Satz ist derselbe, die Bewertung entscheidet. Ob ein Satz einen Konflikt im IT-Team auslöst, hängt deshalb an der Lage dessen, der ihn liest.

Lazarus nannte sein Modell transaktional, weil Mensch und Situation einander ständig beeinflussen. Wer gestresst ist, neigt dazu, auch die nächste Situation bedrohlich zu finden. Wer eine Woche voller kleiner Konflikte hinter sich hat, startet mit weniger Mitteln in den Montag. So erklärt sich, warum Teams mit viel Drama immer dünnhäutiger werden und warum die Kosten von Konflikten mit der Zeit steigen.

Robert Zajonc: Das Gefühl ist schon da

Lazarus' Modell hatte einen prominenten Gegenspieler. Robert Zajonc (1923–2008), polnisch-amerikanischer Sozialpsychologe, hatte als Jugendlicher den Krieg in Polen überlebt: Bei einem Luftangriff auf Warschau 1939 verlor er beide Eltern, später floh er aus einem deutschen Arbeitslager, schloss sich der französischen Résistance an und kam nach dem Krieg in die USA. Fast vier Jahrzehnte lehrte er an der University of Michigan. Bekannt wurde er mit dem Mere-Exposure-Effekt, der Beobachtung, dass Menschen Dinge mögen, nur weil sie ihnen vertraut sind.

1980 veröffentlichte Zajonc einen Aufsatz mit dem Titel „Feeling and Thinking: Preferences Need No Inferences“. Seine These: Gefühle entstehen oft unmittelbar und unabhängig vom Denken, ohne vorherige gedankliche Bewertung, und das Denken liefert die Begründung hinterher. Lazarus widersprach 1982, und 1984 standen beide Positionen nebeneinander in derselben Ausgabe des American Psychologist, unter den Titeln „On the Primacy of Affect“ und „On the Primacy of Cognition“.

Für die Nachricht im Team-Chat, die du dreimal umformulierst, ist dieser Streit sehr praktisch. Du formulierst um, weil du ahnst, dass dein Gegenüber beim Lesen ein Gefühl haben wird, bevor es überhaupt über den Inhalt nachdenkt. Zajonc hätte gesagt: Diese Ahnung ist berechtigt.

Aufmerksamkeitsrückstand: Was nach dem Konflikt im Kopf bleibt

Was mit der Aufmerksamkeit geschieht, wenn man von einer Aufgabe zur nächsten wechselt, hat eine Organisationsforscherin untersucht, die heute an der University of Washington in Bothell lehrt. 2009 veröffentlichte sie zwei Experimente mit Studierenden. Sie bekamen zuerst eine Wortaufgabe, die sich in der verfügbaren Zeit entweder lösen ließ oder nicht, und danach eine zweite Aufgabe, bei der sie Lebensläufe beurteilen sollten.

Sie fand, dass ein Teil der Aufmerksamkeit bei der ersten Aufgabe hängen blieb, wenn diese unerledigt war. Sie nannte das attention residue, Aufmerksamkeitsrückstand. Wer die erste Aufgabe nicht abschließen konnte, schnitt bei der zweiten schlechter ab. Am wenigsten Rückstand zeigten diejenigen, die die erste Aufgabe unter Zeitdruck abgeschlossen hatten, und sie waren sich auch am sichersten, wirklich fertig zu sein.

Ihre Versuchspersonen lösten Wortaufgaben; Konflikte kamen in ihren Versuchen gar nicht vor. Die Übertragung auf den Arbeitsalltag liegt trotzdem nahe. Ein Meeting, in dem ein Konflikt aufbricht und ungelöst endet, ist eine unerledigte Aufgabe in Reinform. Der Funktionsaufruf, den du am Nachmittag nicht mehr verstehst, ist der Ort, an dem dieser Rückstand sichtbar wird. Genau das ist die unsichtbare Zeit aus der Liste oben. Und der Abend, an dem du im Kopf noch einmal das Meeting durchgehst und dir überlegst, was du hättest sagen sollen, ist derselbe Rückstand nach Feierabend. Der Befund erklärt auch, warum ein vertagter Konflikt so lange nachwirkt: Er bleibt eine offene Aufgabe, an der ein Teil der Aufmerksamkeit hängt, bis jemand sie abschließt.

Unterbrochen arbeiten: eine Studie aus Irvine

Einen überraschenden Befund steuerte eine US-amerikanische Psychologin bei, die an der University of California in Irvine Informatik lehrt und seit vielen Jahren erforscht, wie Menschen mit Unterbrechungen und digitaler Ablenkung arbeiten. Für eine Studie, die sie 2008 mit zwei Psychologen der Humboldt-Universität zu Berlin veröffentlichte, ließ sie 48 Versuchspersonen in einem nachgestellten Büro E-Mails beantworten. In einigen Durchgängen wurden sie etwa alle zwei Minuten von einem vermeintlichen Vorgesetzten unterbrochen.

Die Ergebnisse widersprachen der Erwartung:

• Tempo: Die Unterbrochenen erledigten ihre Aufgaben schneller.
• Qualität: Fehler und Höflichkeit der Antworten unterschieden sich nicht. Die Mails wurden kürzer.
• Belastung: Stress, Frustration, Zeitdruck und Anstrengung stiegen deutlich.

Sie und ihre Kollegen schlossen daraus, dass Menschen Unterbrechungen ausgleichen, indem sie schneller arbeiten, und dass sie diesen Ausgleich mit Stress bezahlen. Der Preis zeigt sich also zunächst im Menschen. In der Arbeit selbst taucht er erst später auf. Für Entwicklungsteams, in denen Chat-Nachrichten, Review-Anfragen und Rückfragen aus dem Betrieb den Tag zerteilen, ist das eine wichtige Einsicht: Ein Team kann wochenlang pünktlich liefern und dabei Stress ansammeln, den keine Kennzahl zeigt.

Was unglückliche Entwickler produzieren

Wo der Preis schließlich landet, hat ein Team um einen Softwareforscher der Universität Stuttgart erfragt. Er hatte sich darauf spezialisiert, die Gefühle von Entwicklerinnen und Entwicklern mit den Methoden der Psychologie zu untersuchen. Für einen Aufsatz, der 2018 im Journal of Systems and Software erschien, werteten er und drei Kollegen die schriftlichen Antworten von 317 Entwicklerinnen und Entwicklern aus. Sie fragten, was passiert, wenn man bei der Arbeit unglücklich ist, und fanden 42 verschiedene Folgen.

Die Folgen lassen sich in drei Bereiche ordnen:

• Im Menschen: geringere Konzentration und geistige Erschöpfung, Unruhe, Stress und Selbstzweifel, weniger Motivation, weniger Kreativität und Rückzug von der Arbeit, der bis zur Kündigung reicht.
• Im Prozess: geringere Produktivität, die am häufigsten genannt wurde, Verzögerungen, ein unterbrochener Arbeitsfluss und Abkürzungen, schnelle, unsaubere Lösungen an Stellen, an denen man es eigentlich besser weiß.
• Im Code: schlampigerer Code und manchmal gelöschter Code, weil jemand im Ärger wegwirft, was er gerade geschrieben hat.

Liest man diese Liste neben der Woche vom Anfang, findet man fast jeden Punkt wieder: den Workaround am Nachmittag, den Commit, der am nächsten Morgen Unsinn ist, und den Entwickler, der „wegen der Stimmung“ geht. Die Befragten haben die dritte Form der verlorenen Zeit, die schlechtere Zeit, in ihren eigenen Worten beschrieben.

Wo sich die Modelle widersprechen

Die Forschung ist sich einig, dass Stress etwas kostet. Woher er kommt und wie er wirkt, darüber gehen die Meinungen an vier Stellen auseinander.

1. Reiz oder Bewertung? Für Selye bestimmte die Belastung die Reaktion. Lazarus verlegte den Anfang in die Bewertung des Menschen. Für ein IT-Team ist der Unterschied entscheidend: Nach Selye müsste man die Belastung senken, nach Lazarus kann dieselbe Belastung je nach Lage sehr verschieden ankommen.
2. Denken oder Fühlen zuerst? Lazarus hielt an der Bewertung als erstem Schritt fest, Zajonc sah das Gefühl vorn. Heute nimmt man an, dass beides vorkommt und dass sich schnelle Gefühlsreaktionen und Bewertungen eng durchdringen. Für den Alltag heißt das: Die Lesart einer Nachricht entsteht oft, bevor jemand sie bewusst gelesen hat.
3. Kostet Stress sofort Leistung? Die Studie aus Irvine fand schnelleres Arbeiten bei gleicher Qualität und höherem Stress. Die Forschung zum Aufmerksamkeitsrückstand fand einen Rückstand, der die nächste Aufgabe verschlechtert. Die Stuttgarter Befragten berichten von schlechterem Code. Zusammen gelesen ergeben die Befunde einen zeitlichen Ablauf: Kurzfristig gleichen Menschen aus, die Rechnung kommt mit der nächsten Aufgabe und über Wochen.
4. Wie viel davon ist Drama? In den Stuttgarter Daten stehen technische Ursachen weit vorn: festgefahrene Probleme, Zeitdruck, schlechter Code. Nicht jeder unglückliche Tag ist ein Drama-Tag. Lazarus' Modell erklärt allerdings, wie beides zusammenhängt. Wer schon mit einem hartnäckigen Fehler kämpft, hat weniger Mittel übrig, und der nächste spitze Kommentar trifft auf einen Menschen, dessen sekundäre Bewertung bereits „reicht nicht“ lautet.

Für die Frage dieses Artikels ist das Ergebnis eindeutig genug. Ein Konflikt im IT-Team kostet die Minuten, in denen über ihn gesprochen wird. Er kostet die Aufmerksamkeit, die danach an ihm hängen bleibt. Und er kostet die Qualität der Arbeit, die mit einem gestressten Kopf entsteht.

Was das für dein Team heißt

Das Gute an dieser Erkenntnis: Drama folgt einem Ablauf, den man kennen und unterbrechen kann. Es beginnt mit einem Auslöser, geht über eine Stressreaktion in eine Haltung, die nur noch auf Probleme schaut, und landet in den Rollen, die Menschen unter Druck spielen.

Derselbe Review-Kommentar kann auch einen anderen Verlauf nehmen, wenn der Ablauf früh abbricht. „Das ist so nicht wartbar“, steht unter dem Pull Request. Der Kollege, der ihn liest, spürt, wie ihm warm wird, und bemerkt im selben Moment, dass er schon an einer scharfen Antwort formuliert. Er lässt den Thread ruhen und ruft die Kollegin an. Nach zwölf Minuten wissen beide, welche Stelle gemeint war und warum, und sie haben sich auf einen Umbau geeinigt, der in einen eigenen Pull Request wandert. Der Nachmittag gehört wieder dem Code. Abends geht er nach Hause, ohne das Gespräch im Kopf noch einmal zu führen.

Wie man diesen Ablauf in sich selbst bemerkt und an welcher Stelle der Ausstieg am wenigsten kostet, ist der Stoff des Selbstlernkurses Dramafreiheit, gedacht für genau solche Wochen mit Review, Eskalationsmail und einem Daily, das wieder zu lang wird. Wer sich den Kurs ansehen möchte, findet ihn auf dramafreiheit.de.

Ein Bug kostet dich einmal Zeit. Drama kostet dich die Zeit und den Kopf, den du für die nächste Stunde gebraucht hättest.

---

Quellen

1. Graziotin, Daniel; Fagerholm, Fabian; Wang, Xiaofeng; Abrahamsson, Pekka: What Happens When Software Developers Are (Un)happy. Journal of Systems and Software 140, 2018, S. 32–47.
2. Heinze, Holger: Dramafreie Arbeitswelt. Haufe, 2024.
3. Lazarus, Richard S.: On the Primacy of Cognition. American Psychologist 39 (2), 1984, S. 124–129.
4. Lazarus, Richard S.: Psychological Stress and the Coping Process. McGraw-Hill, New York 1966.
5. Lazarus, Richard S.: Thoughts on the Relations between Emotion and Cognition. American Psychologist 37 (9), 1982, S. 1019–1024.
6. Lazarus, Richard S.; Folkman, Susan: Stress, Appraisal, and Coping. Springer, New York 1984.
7. Leroy, Sophie: Why Is It So Hard to Do My Work? The Challenge of Attention Residue When Switching between Work Tasks. Organizational Behavior and Human Decision Processes 109 (2), 2009, S. 168–181.
8. Mark, Gloria; Gudith, Daniela; Klocke, Ulrich: The Cost of Interrupted Work. More Speed and Stress. Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (CHI 2008). ACM, New York 2008, S. 107–110.
9. Selye, Hans: A Syndrome Produced by Diverse Nocuous Agents. Nature 138, 1936, S. 32.
10. Zajonc, Robert B.: Feeling and Thinking. Preferences Need No Inferences. American Psychologist 35 (2), 1980, S. 151–175.
11. Zajonc, Robert B.: On the Primacy of Affect. American Psychologist 39 (2), 1984, S. 117–123.