DE 
EN 
Komplexe Embedded-Systeme entstehen nicht zwischen zwei Meetings. Sie entstehen dort, wo Entwickler Zeit haben, gedankliche Zusammenhänge aufzubauen. Warum Unternehmen Fokus als strategische Ressource verstehen sollten.
Ein Embedded-Entwickler sitzt vor einem schwer reproduzierbaren Bug. Seit über einer Stunde analysiert er einen Fehler, der nur unter ganz bestimmten Bedingungen auftritt. Langsam beginnt sich das mentale Modell des Systems vor seinem geistigen Auge zusammenzusetzen. In diesem Moment erscheint eine Teams-Nachricht am Bildschirmrand: „Hast du kurz zwei Minuten?“
Innerhalb der nächsten halben Stunde kommt dazu ein neuer Kommentar über Jira rein, der seine Aufmerksamkeit beansprucht, gefolgt von einer Einladung zu einem spontanen Meeting. Es folgen zwei neue E-Mails und schließlich eine Rückfrage eines Kollegen, der plötzlich neben ihm steht.
Keine dieser Unterbrechungen dauert länger als ein paar Minuten. Als er seine Konzentration wieder dem Bug zuwendet, sieht der Editor noch genauso aus wie zuvor. Der Debugger läuft. Die Breakpoints sind gesetzt. Und trotzdem ist etwas Entscheidendes verschwunden. Er weiß plötzlich nicht mehr, warum er genau an dieser Stelle gesucht hat. Die Gedankenkette ist gerissen. Er beginnt, das mentale Modell des Systems Stück für Stück neu aufzubauen.
Diese Szene spielt sich täglich in Embedded-Projekten ab, und sie zeigt beispielhaft, wie sehr die Taktung eines Projekts von Entscheidungen abhängt, die Projektleiter treffen: wie Meetings gelegt, wie Anfragen priorisiert und wie Kommunikationswege organisiert werden.
Das Zeitalter der Unterbrechungen ist angebrochen
Bereits 2012 kam das McKinsey Global Institute zu einer bemerkenswerten Beobachtung: Wissensarbeiter verbringen rund 60 Prozent ihrer Arbeitszeit mit elektronischer Kommunikation und der Suche nach Informationen im Internet. Fast ein Drittel der Arbeitswoche entfällt allein auf das Lesen und Beantworten von E-Mails. Die Informatikerin Gloria Mark von der University of California in Irvine fand etwa zur gleichen Zeit heraus, dass bereits kurze Unterbrechungen ausreichen, um die Bearbeitung komplexer Aufgaben deutlich zu verzögern.
Mehr als zehn Jahre später hat sich die Situation kaum verbessert. Im Gegenteil: Nach aktuellen Untersuchungen von Microsoft werden Wissensarbeiter heute im Durchschnitt alle zwei Minuten durch Nachrichten, Meetings oder andere “dringende Anfragen” unterbrochen. Mit den Kollaborationsplattformen wie Microsoft Teams oder Slack sind mittlerweile weitere Kommunikationskanäle hinzugekommen. Und damit auch neue Unterbrechungen.
Für viele Wissensarbeiter ist das vor allem ein Produktivitätsproblem. Doch in der Embedded-Entwicklung können häufige Kontextwechsel weitreichendere Folgen haben. Wer versucht, ein komplexes Laufzeitverhalten, einen schwer reproduzierbaren Fehler oder das Zusammenspiel mehrerer Software- und Hardwarekomponenten zu verstehen, arbeitet mit einem komplexen mentalen Modell des Systems. Durch jede Unterbrechung verliert er nicht nur Zeit, sondern etwas, das sich nicht innerhalb weniger Sekunden wiederherstellen lässt. Und genau das kann Auswirkungen auf Softwarequalität, Fehlerraten, Termine und letztlich den Projekterfolg haben.
Multitasking ist ein Mythos
Viele Menschen sind überzeugt, mehrere Aufgaben gleichzeitig bearbeiten zu können. Tatsächlich arbeitet unser Gehirn jedoch nicht parallel, sondern seriell. Es kann keine zwei komplexen Denkaufgaben gleichzeitig bearbeiten, sondern schaltet ständig zwischen ihnen hin und her. Jeder dieser Aufgabenwechsel kostet Zeit und mentale Energie.
Die Organisationspsychologin Sophie Leroy bezeichnet dieses Phänomen als “Aufmerksamkeitsrückstand” (Attention Residue). Beim Wechsel von einer anspruchsvollen Aufgabe zur nächsten folgt unsere Aufmerksamkeit nicht vollständig dem neuen Problem. Ein Teil bleibt unbewusst bei der vorherigen Aufgabe. In ihren Experimenten zeigte Leroy, dass sich dieser Aufmerksamkeitsrückstand direkt auf die Leistung bei der nächsten Aufgabe auswirkt. Insbesondere dann, wenn die erste Aufgabe unterbrochen oder nicht abgeschlossen wurde. Je häufiger wir wechseln, desto stärker leidet die Konzentration.
Warum Kontextwechsel Fehler begünstigen
Beim Debugging beispielsweise arbeiten sich Entwickler über Beobachtungen, Vermutungen und Ausschlussverfahren an die Ursache eines Fehlers heran. Denn viele Fehler treten nur sporadisch auf oder hängen von einer bestimmten Hardwarekonfiguration ab. Jeder Kontextwechsel unterbricht diese gedankliche Spur.
Gerade in sicherheitskritischen Anwendungen, wie etwa in der Automobiltechnik, der Medizintechnik oder der Industrieautomation, kann fehlender Fokus deshalb weit mehr kosten als ein paar Minuten Arbeitszeit. Er erhöht das Risiko, Zusammenhänge zu übersehen, Annahmen falsch zu bewerten oder Fehler erst sehr spät im Projekt zu entdecken.
Die versteckten Kosten von Kontextwechseln
Schon wenn jeder relevante Kontextwechsel im Durchschnitt nur wenige Minuten zusätzliche Wiederanlaufzeit verursacht, kommen in einem zehnköpfigen Entwicklungsteam schnell mehrere Arbeitsstunden pro Tag zusammen. Der eigentliche Zeitverlust entsteht dabei nicht durch die Unterbrechung selbst, sondern durch den erneuten Aufbau des gedanklichen Kontexts. Diese versteckten Kosten erscheinen in keinem Projektplan. Sie fallen jedoch Tag für Tag an.
Was also tun? In vielen Unternehmen gilt konzentriertes Arbeiten noch immer als persönliche Fähigkeit. Wer sich häufig ablenken lässt, muss sich eben besser organisieren, so die verbreitete Annahme. Die Forschung zeichnet jedoch ein anderes Bild. Nicht mangelnde Disziplin, sondern häufige Kontextwechsel sind oft der eigentliche Produktivitätskiller.
Fokus braucht die richtigen Rahmenbedingungen
Wie Unternehmen konzentrierte Entwicklungsarbeit schützen können, hat der Informatiker und Y-Combinator-Mitgründer Paul Graham bereits 2009 in seinem vielzitierten Essay “Maker’s Schedule, Manager’s Schedule” beschrieben. Seine zentrale Beobachtung: Manager organisieren ihren Tag in einstündigen Terminslots. Für Entwickler, Ingenieure oder Autoren funktioniert dieses Modell jedoch nur bedingt. Wer komplexe Probleme löst, benötigt zusammenhängende Zeitblöcke von mehreren Stunden. Ein einziges Meeting am Vormittag oder Nachmittag kann ausreichen, um einen gesamten Fokusblock zu zerstören.
Für Embedded-Teams bedeutet das nicht, Meetings grundsätzlich abzuschaffen. Entscheidend ist vielmehr, dass Projektleiter Kommunikations- und Abstimmungsphasen bewusst bündeln (etwa durch feste Statusrunden statt Ad-hoc-Nachfragen) und ihren Entwicklern ausreichend große, geschützte Fokusfenster einräumen. Hochwertige Software entsteht selten zwischen zwei Meetings, sondern in den ungestörten Stunden dazwischen.
Fazit
Projektleiter, die Entwicklungszeit bewusst vor unnötigen Unterbrechungen schützen, schaffen die Voraussetzung für bessere Softwarequalität, effizienteres Debugging und verlässlichere Projektlaufzeiten. Sie verstehen Aufmerksamkeit nicht als persönliche Eigenschaft ihrer Entwickler, sondern als Ressource, die sich aktiv gestalten und schützen lässt: etwa durch störungsfreie Fokuszeiten, klar strukturierte Kommunikationswege oder Meeting-freie Zeitfenster. Wer den gedanklichen Kontext seines Teams auf diese Weise schützt, investiert nicht nur in konzentrierteres Arbeiten, sondern in bessere Software, weniger Fehler und erfolgreichere Projekte.
Über den Autor
Bernhard Lermann arbeitet seit über 25 Jahren als Journalist und Kommunikationsberater. Er entwickelt Content-Strategien und Fachbeiträge für Technologieunternehmen, darunter MicroConsult. Sein besonderes Interesse gilt der Frage, wie Aufmerksamkeit, Kommunikation und Arbeitsorganisation die Qualität von Denken, Zusammenarbeit und Wissensarbeit beeinflussen. Auf dieser Grundlage konzipiert er Workshops für Unternehmen, die eine Arbeits- und Fokuskultur fördern, in der hochwertige Wissensarbeit wieder den nötigen Raum erhält.
Weiterführende Informationen
MicroConsult Training & Coaching zum Thema Projektmanagement
MicroConsult Fachwissen zum Thema Projektmanagement
