In der heutigen digitalen Welt sind Entwicklerinnen und Entwickler das Rückgrat jedes erfolgreichen Technologieunternehmens. Sie sind es, die tagtäglich innovative Produkte entwickeln, neue Features implementieren und technische Probleme beheben – und damit maßgeblich zum Unternehmenserfolg beitragen. Trotz dieser Schlüsselrolle wird die Erfahrung, die Entwicklerinnen und Entwickler bei ihrer Arbeit machen, oft unterschätzt oder als rein technisches Detail betrachtet. Doch bei Jimdo, einem Unternehmen, das kleinen Betrieben und Solopreneuren dabei hilft, online Fuß zu fassen und zu wachsen, hat man eine andere Perspektive – Developer Experience, kurz DevEx, ist dort keine Nebensache, sondern eine zentrale geschäftliche Priorität. Die Developer Experience beschreibt, wie Entwicklerinnen und Entwickler ihre Arbeit wahrnehmen und erleben.
Es geht dabei nicht nur um einzelne technische Aspekte wie kürzere Build-Zeiten oder verbesserte Code-Review-Prozesse, sondern um ein gesamtheitliches Erlebnis, das Motivation, Effizienz und Produktqualität beeinflusst. Die Praxis zeigt: Zufriedene Entwickler sind produktiver, arbeiten schneller und lösen Probleme effektiver. Doch genau hier liegt eine Herausforderung: DevEx wird häufig zwischen eng gesteckten Business-Zielen, Produkt-Deadlines und dem Umgang mit technischem Schuldenberg vernachlässigt. Jimdo hat sich daher zum Ziel gesetzt, DevEx explizit in den Mittelpunkt der Unternehmensstrategie zu setzen – weit über die reine Engineering-Abteilung hinaus. Der Schlüssel zum Erfolg lag für Jimdo darin, zunächst ein gemeinsames Verständnis für DevEx zu schaffen. DevEx ist nicht einfach nur schnelleres Bauen von Software oder ein besseres Management von Entwicklungsprozessen. Es ist vielmehr das Erlebnis, das Entwickler während ihrer täglichen Arbeit erfahren.
Um dies wissenschaftlich fundiert anzugehen, griff Jimdo auf aktuelle Forschung zurück, insbesondere auf die Arbeit von Noda, Abi und Kollegen, die in ihrer Studie „DevEx: What Actually Drives Productivity“ drei zentrale Dimensionen der Developer Experience herausstellten: Flow, Feedback Loops und Cognitive Load. Der „Flow“-Zustand beschreibt jene Momente, in denen Entwickler völlig vertieft und ungestört an Aufgaben arbeiten können. Jegliche Unterbrechungen oder Verzögerungen kosten wertvolle Zeit und brechen diesen Zustand. Feedback Loops beziehen sich darauf, wie schnell ein Entwickler eine Rückmeldung erhält, zum Beispiel durch Code-Reviews oder Testergebnisse. Langes Warten schmälert die Geschwindigkeit und Motivation erheblich. Cognitive Load dagegen bezeichnet die geistige Belastung durch komplexe Prozesse, widersprüchliche Tools oder fehlende Dokumentationen, die das Entwickeln unnötig erschweren.
Für Jimdo bedeutete die Verankerung dieses Verständnisses, DevEx in zwei Ebenen zu betrachten: zum einen aus quantitativer Sicht, also messbaren Kennzahlen wie Build-Zeiten, Durchlaufzeiten von Pull Requests oder der Häufigkeit von Deployments, und zum anderen aus qualitativer Sicht, also der subjektiven Wahrnehmung der Entwicklerinnen und Entwickler. Nur die Kombination beider Perspektiven ermöglicht ein vollständiges Bild, um die tatsächlichen Herausforderungen zu erkennen. Ein anschauliches Beispiel aus dem Unternehmen verdeutlicht diesen Ansatz: Zwei Entwickler verbringen die gleiche Zeit damit, Pasta zu kochen, doch unterschiedliche Kochtöpfe sorgen für verschiedene Kochzeiten. Zwar stimmt das Endergebnis, doch ihre subjektive Empfindung zum Aufwand ist unterschiedlich. Dies zeigt, dass reine Zahlen ohne den Kontext der Wahrnehmung irreführend sein können. Nach der Definition und dem Aufbau eines gemeinsamen Verständnisses widmete sich Jimdo der praktischen Umsetzung.
Mit der Durchführung erster interner Umfragen erfasste man die Stimmung und das Erleben der Entwickler, kombiniert mit bestehenden Leistungskennzahlen. Die gesammelten Daten wurden zentral aufbereitet, um ein klares Monitoring von DevEx-relevanten Parametern zu ermöglichen. So konnte das Unternehmen frühzeitig Problemfelder identifizieren. Die Ergebnisse führten zu konkreten Maßnahmen, etwa der Anpassung der Richtlinien für Pull-Request-Größen, um den Review-Prozess zu beschleunigen, oder einer Überarbeitung der Meeting-Kultur, um Entwicklern mehr ungestörte Arbeitszeit zu gewähren. Auch die Übereinstimmung der Produktstrategie mit den täglichen Entwicklungsaufgaben wurde gestärkt, sodass alle Teams klar erkennen konnten, welchen Beitrag ihre Arbeit zum Erfolg leistet. Ein besonderes Augenmerk lag darauf, DevEx nicht als einmaliges Projekt, sondern als kontinuierliche Praxis zu verstehen.
Die regelmäßige Wiederholung von Umfragen ermöglicht es, Fortschritte sichtbar zu machen und neue Herausforderungen zeitnah zu adressieren. Dieses zyklische Vorgehen schafft Feedback-Schleifen, die es erlauben, agile und datengetriebene Verbesserungen einzubauen. Die Verbindung von Investitionen in technische Plattformen – beispielsweise schnellere Continuous-Integration-Systeme oder optimierte Entwickler-Tools – mit spürbaren Verbesserungen im Arbeitsalltag der Entwickler wird durch konkrete DevEx-Metriken messbar. Dies bringt auch Transparenz gegenüber dem Management und anderen Geschäftsbereichen und macht die Relevanz von Entwicklungsprozessen als unternehmerischen Erfolgsfaktor deutlich. Nach eineinhalb Jahren intensiver Arbeit auf diesem Gebiet konnte Jimdo bereits Verbesserungen in zentralen Bereichen verzeichnen. Der Flow-Zustand wird weniger durch Unterbrechungen gestört, Review-Zeiten haben sich verringert, und neue Team-Mitglieder finden leichter Zugang in ihre Aufgaben.
Doch die Verantwortlichen wissen auch, dass die Entwicklung hin zu einer optimalen Developer Experience ein fortwährender Prozess ist. Es geht nicht um das Erreichen eines idealen Endzustands, sondern um eine Haltung, die DevEx immer wieder in den Mittelpunkt stellt und weiter vorantreibt. Für Unternehmen, die DevEx als Wettbewerbsvorteil im umkämpften Markt für Entwicklerinnen und Entwickler nutzen möchten, liefert Jimdos Ansatz wertvolle Erkenntnisse. Es empfiehlt sich, nicht auf Perfektion zu warten, sondern mit einfachen, nachvollziehbaren Schritten zu starten – etwa durch interne Befragungen, die helfen, tatsächliche Schmerzpunkte zu erkennen. Die Fokussierung sollte nicht auf der Erfassung von „Produktivität“ als abstraktem Ideal liegen, sondern auf dem genauen Verständnis, welche Hindernisse Entwicklerinnen und Entwickler erleben und wie sich diese beheben lassen.
Darüber hinaus macht eine strategische Verankerung von DevEx als „Produkt“ mit eigener Verantwortung und Feedback-Möglichkeiten den Unterschied. Letztlich zeigt sich, dass Developer Experience wesentlich mehr ist als eine technische Randnotiz oder ein Modebegriff. Sie ist eine komplexe, unternehmensweite Herausforderung, deren Lösung greifbare Auswirkungen auf die Geschwindigkeit der Produktentwicklung, die Qualität der Software und die Zufriedenheit der Mitarbeiter hat. Durch das Beispiel Jimdos wird klar, dass wenn Entwicklerinnen und Entwickler bessere Voraussetzungen vorfinden, alle davon profitieren – vom Management über die Produktteams bis hin zu den Endkunden. Das Unternehmen untermauert damit eindrucksvoll: Developer Experience ist nicht nur eine Angelegenheit der Technik, sondern eine echte geschäftliche Priorität, die in keinem modernen Unternehmen fehlen darf.
