Office-Alltag: Was Entwickler:innen wirklich brauchen

Warum das Bild vom durchgehend programmierenden Entwickler falsch ist

Die verbreitete Vorstellung lautet:
Entwickler:innen sitzen am Rechner und schreiben Code. Die Datenlage sagt etwas anderes. Laut Atlassian entfallen nur rund 16 Prozent der Arbeitszeit auf das Programmieren. Das ist aber gar nicht der Reibungspunkt, weshalb Coding-Assistenten die Erfahrung zwar angenehmer machen, aber nicht grundlegend verbessern.

Das hat eine unangenehme Konsequenz für Investitionsentscheidungen. Wer Budget in Werkzeuge steckt, die den kleinsten Teil des Arbeitstages beschleunigen, verbessert die Kennzahl, aber nicht den Alltag.

Atlassian hat 2025 rund 3.500 Entwickler:innen und Führungskräfte in sechs Ländern befragt, darunter Deutschland. Das Ergebnis: 99 Prozent sparen durch KI-Werkzeuge Zeit, 68 Prozent mehr als zehn Stunden pro Woche. Gleichzeitig verlieren 50 Prozent zehn Stunden oder mehr pro Woche an nicht-programmierende Tätigkeiten, 90 Prozent verlieren mindestens sechs Stunden. Unter dem Strich stehen viele Teams damit dort, wo sie vorher waren.

Die drei größten Zeitfresser sind laut der Untersuchung:

1. Informationen finden
2. sich in neue Technologie einarbeiten
3. zwischen Werkzeugen wechseln.

Das sind keine technischen Probleme. Das sind Organisations- und Wissensprobleme.

Was kostet ein Kontextwechsel tatsächlich?

Mehr, als in jeder Kalkulation auftaucht. Die Forschung von Gloria Mark ist für die sogenannte 23-Minuten-Regel bekannt: Nach einer Unterbrechung dauert es im Schnitt 23 Minuten und 15 Sekunden, bis jemand wirklich zur ursprünglichen Aufgabe zurückfindet.

Entscheidend ist die Häufigkeit. Microsoft hat 2025 in einer Studie mit 31.000 Wissensarbeitenden aus 31 Ländern rund 275 Signale pro Tag gemessen, also E-Mails, Chatnachrichten und Meeting-Einladungen. In der Kernarbeitszeit ergibt das im Schnitt alle zwei Minuten eine Unterbrechung.

Für Entwicklungsarbeit ist das besonders teuer. Wer ein Datenmodell im Kopf hält, drei Systemzustände gleichzeitig durchdenkt und einen Fehlerpfad verfolgt, verliert bei einer Unterbrechung nicht eine Minute. Er verliert den gesamten aufgebauten Kontext. Deshalb ist geschützte Fokuszeit kein Wohlfühlthema, sondern eine betriebswirtschaftliche Größe.

Was brauchen Entwickler:innen im Alltag konkret?

Aus der Datenlage und aus über zehn Jahren Projektarbeit lassen sich fünf Punkte ableiten, die immer wieder auftauchen.

• Zusammenhängende Fokuszeit. Nicht mehr Stunden, sondern längere Blöcke. Drei ungestörte Stunden sind produktiver als acht fragmentierte. Praktisch heißt das: Meetings bündeln statt über den Tag verteilen, und eine klare Regel, was als dringend gilt.
• Wissen, das ohne Nachfrage auffindbar ist. Der teuerste Weg zu einer Information ist die Frage an eine Kollegin, weil sie zwei Menschen aus dem Kontext reißt. Atlassian beziffert den Effekt deutlich: Wenn Entwickler:innen sich Informationen selbst beschaffen können, sind sie 4,4-mal produktiver. Dokumentation ist damit kein Nebenprodukt, sondern Infrastruktur.
• Weniger Werkzeugwechsel. Jeder Sprung zwischen Ticketsystem, Repository, Monitoring, Chat und Tabelle kostet Aufmerksamkeit. Ein zusätzliches Tool, das ein kleines Problem löst und zwei neue Kontextwechsel erzeugt, ist ein Verlustgeschäft.
• Entscheidungsspielraum in technischen Fragen. Wer die Lösung verantwortet, sollte den Weg dorthin mitbestimmen. Das ist auch ein Bindungsfaktor. Erfahrene Entwickler:innen verlassen Teams selten wegen der Aufgaben. Sie verlassen sie, weil sie die Aufgaben nicht sauber lösen dürfen.
• Systeme, die nicht bei jeder Änderung zurückschlagen. Das ist der am meisten unterschätzte Punkt und deshalb ein eigener Abschnitt.

Welche Rolle spielt die Systemlandschaft?

Eine größere, als der Begriff „Office-Alltag" vermuten lässt. Ein erheblicher Teil der täglichen Reibung entsteht nicht im Büro, sondern in der Architektur.

Typisches Muster im Mittelstand: ein gewachsenes ERP, ein Shop, ein Lagersystem, dazu Excel-Listen als inoffizielle Schnittstelle. Jede neue Anforderung berührt drei Systeme, deren Datenmodelle nicht zusammenpassen. Entwickler:innen verbringen dann Tage damit, Zustände abzugleichen, statt Funktionen zu bauen. Aus Sicht der Geschäftsführung wirkt das wie ein langsames Team. Tatsächlich ist es eine langsame Landschaft.

Genau hier setzt die von uns entwickelte Datenintegration an. Sie normalisiert Daten zentral und synchronisiert sie zwischen den angebundenen Systemen. Wichtig ist uns dabei die ehrliche Einordnung: Middleware löst Architekturprobleme, keine Organisationsprobleme. Wer Fokuszeit nicht schützt, gewinnt sie durch keine Integrationsschicht zurück.

Neue Werkzeuge reduzieren Komplexität nicht automatisch

Das gilt auch für KI in der Softwareentwicklung. Sie kann Entwickler bei vielen Aufgaben unterstützen, aber sie nimmt einem Team nicht automatisch Arbeit ab.

Im Stack Overflow Developer Survey 2025 mit mehr als 49.000 Antworten nennen 66 Prozent der Entwickler KI-Lösungen, die fast, aber nicht ganz richtig sind, als eine ihrer größten Frustrationen. 45 Prozent geben an, dass das Debuggen von KI-generiertem Code zusätzlichen Zeitaufwand verursacht. Gleichzeitig ist das Vertrauen in die Genauigkeit der Ergebnisse von 43 Prozent im Jahr 2024 auf 33 Prozent gesunken.

Die Konsequenz ist ähnlich wie bei einer komplexen Systemlandschaft: Neue Technologie hilft vor allem dann, wenn die Prozesse rundherum stimmen. Wer KI-Werkzeuge einführt und gleichzeitig Zeit für Prüfung, Reviews und saubere Integration kürzt, beseitigt Arbeit nicht. Er verschiebt sie lediglich an eine andere Stelle.