Es ist an der Zeit, das Kind beim Namen zu nennen: Burnout unter Entwicklern ist ein Fehler der Geschäftsleitung

Entwickler haben scheinbar alles. Sie stehen an der Spitze von Transformationsbemühungen, werden geschätzt und verehrt – doch sehen sie sich gleichzeitig mit besonders schwierigen Herausforderungen konfrontiert.

Da Entwickler innerhalb der IT-Branche eine ausgesprochen anspruchsvolle Rolle erfüllen, leiden sie häufig an Burnout. Um zu den technologischen Experten zu werden, als die man sie kennt, müssen sie eine langjährige Ausbildung absolvieren und stehen immer kurz davor, überarbeitet zu sein – ganz zu schweigen von den unrealistischen Anforderungen und oft unerreichbaren Zielvorgaben, denen sie unterworfen sind. Als außergewöhnliche Spezialisten auf ihrem Gebiet können sie Aufgaben nicht ohne Weiteres delegieren und da sie leichter erreichbar und ansprechbar sind als gewisse andere Mitarbeiter (etwa für die Hardware-Entwicklung zuständige Teams) werden sie als hochverfügbare und flexible Ressource angesehen. Da ihr Zeit- und Arbeitsaufwand dementsprechend vergleichsweise häufig unterschätzt wird, werden viele Entwickler konstant überfordert.

Nicht nur als gelernter Entwickler, sondern auch in meiner Rolle als Vorgesetzter anderer Entwickler habe ich persönlich miterlebt, wie häufig es in unserer Branche zum Burnout kommt. Ich möchte in diesem Zusammenhang das Kind beim Namen nennen und betonen, dass dieser Umstand auf Führungsprobleme zurückzuführen ist.

Ohne die Unterstützung und den Schutz der Geschäftsleitung können sich solche Probleme rasch anhäufen und Entwickler dazu verdammen, an tristen, scheinbar niemals enden wollenden Projekten zu arbeiten, die sie an den Rand des Abgrunds treiben. Und wenn schwer zu findende Experten wie Entwickler die Nase voll haben und beschließen, ihrem Unternehmen (oder sogar der ganzen Branche) den Rücken zu kehren, bringt dies enorme Kosten für die Geschäftsleitung mit sich.

Manager haben die Kontrolle über jene Aspekte, die unter Entwicklern zum Burnout führen. Sie weisen ihren Mitarbeitern Aufgaben zu und legen die zugrunde liegenden Anreize für das Erledigen dieser Aufgaben fest. Anders gesagt: Manager beeinflussen und bestimmen das Arbeitsklima der Entwickler. Wenn ein Entwickler also an Burnout-Symptomen leidet, liegt das daran, dass sein Manager ihn im Stich gelassen hat. Es ist die Aufgabe der Geschäftsleitung, die Anzeichen eines Burnout frühzeitig zu erkennen und einzugreifen, um ein weiteres Fortschreiten um jeden Preis zu verhindern.

Wenn Sie zu den Führungskräften im Technologie-Bereich gehören, mag es sein, dass diese unverblümten Aussagen Sie beunruhigen oder sogar in die Defensive drängen. Doch anstatt sich auf sich selbst zu konzentrieren, sollten Sie in erster Linie an Ihr Team denken. Hier erfahren Sie, wie Sie Burnout-Symptome unter Entwicklern erkennen und verhindern, dass diese sich in Ihrem Team ausbreiten.

Wenn Sie zu den Führungskräften im Technologie-Bereich gehören, mag es sein, dass diese unverblümten Aussagen Sie beunruhigen oder sogar in die Defensive drängen. Doch anstatt sich auf sich selbst zu konzentrieren, sollten Sie in erster Linie an Ihr Team denken.

Welche Ursachen hat Burnout unter Entwicklern?

Burnout-Symptome unter Entwicklern sind nicht immer nur auf lange Arbeitszeiten zurückzuführen. Zwar trägt dies durchaus zum Entstehen dieser Symptome bei, doch es ist die langsame Anhäufung mehrerer – sowohl großer als auch kleiner – Unzufriedenheiten, die der mit dem klassischen Burnout assoziierten Verbitterung zugrunde liegen.

Diese Unzufriedenheiten sind meist das Ergebnis eines Mangels an Zuständigkeitsgefühl, Kontrolle, Mitspracherecht oder Anerkennung für die eigenen Leistungen.

Szenarien, die mit einem hohen Burnout-Risiko einhergehen, umfassen etwa arbeitsintensive Projekte, die sich über einen längeren Zeitraum erstrecken und bei denen es nur selten zu Erfolgserlebnissen wie beispielsweise dem Abschicken der kompilierten Software kommt. Die Pflege von veraltetem Code ist ein weiteres typisches Beispiel. Ein Entwickler, der mit dieser Aufgabe betraut wird, ist so gut wie nie die Person, die den Code ursprünglich geschrieben hat. Deswegen fühlt er sich nicht dafür zuständig. Er findet sich in einer Situation wieder, in der er eine schier endlose Serie von Fehlern beheben muss, wohl wissend, dass der Code kaum zu retten ist und am besten von Grund auf neu geschrieben werden müsste – eine Entscheidung, die allerdings nicht in seiner Kontrolle liegt. Und da die Arbeit überdies einen verhältnismäßig geringen Mehrwert schafft, ist Anerkennung unwahrscheinlich.

Darüber hinaus ist Burnout unter Entwicklern häufig das Ergebnis eines fehlenden Vertrauens in das Verständnis des Produktteams für Kundenanforderungen, eines Mangels an Selbstbestimmung im Hinblick auf die eigenen Arbeitszeiten oder eines Mangels an Mitspracherecht bei Entscheidungen, die Konsequenzen für den Entwickler haben. All dies sät die Samen für ein wachsendes Gefühl der Verbitterung.

Wie bereits oben angesprochen ist die Auslieferung des fertigen Programms für Entwickler ein Erfolgserlebnis. Es sollte jedoch erwähnt werden, dass es Ausnahmen gibt. Wenn Entwickler Zeit damit verschwenden, Code für eine falsche oder sinnlose, von niemandem genutzte Funktion zu schreiben und zu veröffentlichen, sind sie wahrscheinlich genauso unbefriedigt, als hätten sie erst gar keinen Code geschrieben.

Es gibt jedoch noch weitere Szenarien, die es zu verhindern gilt. Zum Beispiel ist es stressig, wenn Vertriebs-, Marketing- und Führungsabteilungen die Zeit eines Entwicklers nach Lust und Laune beanspruchen können. Ebenso können Burnout-Symptome entstehen, wenn Entwickler keine Empfehlungen in Zusammenhang mit Systemarchitektur aussprechen und sich nicht nicht an wichtigen Entscheidungen beteiligen dürfen.

Drei Arten von ausgebrannten Entwicklern – und die Persönlichkeitstypen, auf die Sie achten sollten

Es ist wichtig, zu betonen, dass Burnout-Symptome jeden treffen können. Ich habe jedoch festgestellt, dass Menschen mit Workaholic-Tendenzen und Hang zum Perfektionismus bis ins kleinste Detail anfälliger sind als andere. Menschen mit diesem Persönlichkeitstyp sind überaus ehrgeizig und versuchen stets, über das Ziel hinauszuschießen. Wenn sie wohlauf und motiviert sind, sind sie eine Bereicherung für jedes Team.

Doch dieser Ehrgeiz kann den arbeitssüchtigen Entwickler leicht von dem Ziel ablenken, auf das es momentan ankommt. Wenn das passiert, versucht der Workaholic, vier oder fünf Projekte auf einmal zu bewältigen und muss regelmäßig 60-Stunden-Wochen einlegen, nur um am Ball zu bleiben. Entwickler dieser Art brauchen kein Mikromanagement. Sie brauchen einen Manager, der die Anzeichen des sich anbahnenden Burnout erkennt und ihnen hilft, Prioritäten zu setzen und sich auf das Wesentliche zu konzentrieren.

Wenn der Burnout zuschlägt, gibt es meiner Erfahrung nach drei Arten von ausgebrannten Entwicklern: den verärgerten Entwickler, den zurückgezogenen Entwickler und den ausgeuferten Entwickler.

Der verärgerte Entwickler ist hochnäsig und verträgt keine Kritik. Er ist auf Konfrontation aus und zeigt sich wenig kooperativ. Der zurückgezogene Entwickler verpasst Meetings oder sitzt stillschweigend da, wenn er doch teilnimmt. Er ist plötzlich nur noch schwer via E-Mail oder Slack zu erreichen und seine Codebeiträge werden seltener, weniger umfangreich oder undetaillierter. Dann gibt es den ausgeuferten Entwickler: Er neigt dazu, unverhältnismäßig viel Arbeit in kleine Aufgaben zu stecken und viel länger als nötig zu brauchen. Hilfe, die man ihm anbietet, lehnt er selbst dann ab, wenn er in unfertigen Projekten erstickt.

Prävention ist besser, einfacher und billiger als Heilung

Ein Burnout kann unerwartet auftreten, doch er kommt nie einfach aus dem Nichts. In jedem Fall lässt sich im Vorfeld ein verändertes Verhalten ausmachen, das darauf hindeutet, dass die betroffene Person Gefahr läuft, verärgert zu werden, sich zurückzuziehen oder auszuufern. Die Herausforderung für die Geschäftsleitung besteht darin, sowohl die nötigen Voraussetzungen zu schaffen, um diese Anzeichen selbst zu erkennen, als auch Entwicklern die Möglichkeit zu bieten, Bedenken oder Meinungen zu äußern, bevor sie zu größeren Problemen werden.

Regelmäßige und sinnvolle Einzelgespräche leisten einen wichtigen Beitrag zur Burnout-Prävention. Diese Meetings müssen dabei über ein simples persönliches Gespräch mit dem Chef hinausgehen und die Frage zu Sprache bringen, was Entwickler von ihrer Karriere erwarten, damit Sie proaktive Maßnahmen ergreifen können, um die Wünsche Ihrer Entwickler zu verwirklichen. Für Führungskräfte gilt es, Vertrauen aufzubauen, indem sie die im Rahmen dieser Meetings thematisierten Erwartungen in die Tat umsetzen, Entwicklern die Art von Projekten bieten, die sie sich wünschen, und sie zur Teilnahme an Schulungen ermutigen, die sie interessieren.

Hinter den Kulissen ist es wichtig, dass Führungskräfte Workloads genaustens im Auge behalten und der Entwicklerabteilung Abwechslung bieten, indem sie Mitarbeiter regelmäßig neuen Teams zuweisen. Darüber hinaus obliegt ihnen die Aufgabe, persönliche und berufliche Interessen der einzelnen Mitarbeiter bestmöglich zu fördern. Zugegebenermaßen mag die Umsetzung all dieser Punkte kurzfristige Herausforderungen mit sich bringen. Doch sind diese im Vergleich zu den Auswirkungen eines ausgebrannten Teams auf die Moral und Produktivität am Arbeitsplatz zweifellos die bessere Option.

Wenn es trotz aller Bemühungen zu einem Burnout-Fall kommt und Sie sich zum Eingreifen gezwungen sehen, ist es wichtig, sich im Vorfeld mehrere konkrete Lösungsansätze zu überlegen. Wenn Sie auf eine Verhaltensänderung aufmerksam werden, ist es wahrscheinlich schon zu spät, um Ihrem Mitarbeiter zu sagen: „Ich habe das Gefühl, dass dir etwas auf dem Herzen liegt. Erzähl mir davon.“ Denken Sie stattdessen über gezielte Maßnahmen nach, die Sie ergreifen können: Können Sie den betroffenen Mitarbeiter von einem möglicherweise belastenden Projekt befreien? Können Sie sein Arbeitspensum anpassen, ihm Urlaub gewähren und seine Arbeitsstunden nach seiner Rückkehr reduzieren?

Die Verantwortung für Burnout-Fälle liegt bei der Geschäftsleitung

Die Vorteile der Förderung der Motivation Ihrer Entwickler sind derart offensichtlich, dass ich zögere, sie zu erwähnen. Wenn Sie auf ein erfahrenes Team zählen können, das Ihren Stack und Ihre Systeme in- und auswendig kennt – ein Team, das glücklich, kompetent und motiviert ist – gelingt es Ihnen mit Sicherheit, Ihren Entwicklungsyklus zu verkürzen und Ihren Erfolg zu steigern.

Umgekehrt sollten die potenziellen Folgen eines Burnout für Unternehmen und ihre Führungskräfte nicht unterschätzt werden. Angesichts der in solchen Fällen sinkenden Qualität und ausbleibenden Releases stellt sich schnell Unzufriedenheit unter Kunden und Anwendern ein. Wenn wichtige Entwicklungsressourcen Probleme nicht methodisch zu lösen vermögen, leidet nicht nur die Leistung, sondern letztlich auch die allgemeine Moral im Unternehmen. Die schlechte Stimmung einer Person kann sich schnell im ganzen Unternehmen oder Team ausbreiten, die Arbeitskultur verderben und sich negativ auf die Rekrutierung und Bindung von Mitarbeitern auswirken.

Es sollte angemerkt werden, dass manche Entwickler dazu tendieren, sich das Leben selbst kompliziert zu machen: Die Kombination eines natürlichen Drangs zur Problemlösung und der Überschätzung der eigenen Fähigkeiten führt dazu, dass diese Entwickler sich zu viel zumuten. In diesem Fall besteht die Aufgabe der Führungsebene darin, die positiven Aspekte dieser Einstellung zu fördern und die negativen auszubremsen. In diesem Zusammenhang können Maßnahmen ergriffen werden, die eine auf Vielfalt und aussagekräftigem Feedback basierende Arbeitskultur fördern und Mitarbeiter ermutigen, jeden Tag einen Beitrag zu leisten.

Ich lege sämtlichen Führungskräften ausdrücklich ans Herz, diese Maßnahmen umzusetzen – denn letzten Endes liegt die Verantwortung für Burnout-Fälle bei der Geschäftsleitung.

Join the Conversation: Find Solve on Twitter and LinkedIn, or follow along via RSS.

Stay on top of what's next in technology

Learn about tech trends, innovations and how technologists are working today.