Tool-Ermüdung ist real: Was Engineering Manager tun können
Engineering Manager jonglieren mit zu vielen Tools. So funktioniert Tool-Ermüdung, was sie kostet und welche systemebenen Fixes wirklich helfen.
By Ellis Keane · 2026-03-31
Es ist 9:47 Uhr an einem Dienstagmorgen, und die Engineering Managerin hat weder eine Zeile Code geschrieben noch einen einzigen Pull Request geprüft noch ein Gespräch mit jemandem im Team über echte Engineering-Arbeit geführt. Sie hat ein Notion-Dokument mit Statusupdates aus Linear aktualisiert, einen Slack-Thread gegengeprüft, um herauszufinden, ob eine Entscheidung getroffen oder nur diskutiert wurde, und versucht sich zu erinnern, ob der Figma-Kommentar, den sie gestern gesehen hatte, beim v2- oder v3-Mockup war – weil die Benachrichtigung nicht genug Kontext enthielt.
Wenn du Engineering Manager bist, erkennst du diesen Morgen wahrscheinlich, auch wenn du ihn noch nie Tool-Ermüdung genannt hast.
Die Form des Problems
Tool-Ermüdung für Engineering Manager dreht sich nicht wirklich darum, zu viele Tools zu haben (obwohl es meist so formuliert wird). Es geht um den kognitiven Aufwand, ein mentales Modell davon aufrechtzuerhalten, wo Informationen liegen, wer sie dort abgelegt hat und ob sie noch aktuell sind. Jedes Tool im Stack ist eine eigene Quelle der Wahrheit, und die Aufgabe des Engineering Managers ist es stillschweigend geworden, diese Quellen zu einem kohärenten Gesamtbild zusammenzufügen, das als Entscheidungsgrundlage dienen kann.
So sieht das in der Praxis aus. Angenommen, du leitest ein Team von sechs Engineers, und dein Unternehmen nutzt Linear für das Projektmanagement, GitHub für Code, Slack für Kommunikation, Figma für Design und Notion für Dokumentation. Das sind fünf Tools – ehrlich gesagt eher wenig für die meisten Startups, mit denen wir sprechen.
title: "Der Dienstagmorgen einer Engineering Managerin" 8:30 AM|ok|Öffnet Linear, scannt den aktiven Sprint. Drei Issues als „in Bearbeitung" markiert, ohne aktuelle Updates. 8:42 AM|amber|Wechselt zu GitHub, um zu prüfen, ob Pull Requests für diese Issues existieren. Zwei gibt es. Einer fehlt. 8:51 AM|ok|Prüft Slack für Kontext zum fehlenden PR. Findet einen Thread vom Freitag, in dem der Engineer einen Blocker erwähnte. 9:03 AM|amber|Der Blocker verweist auf einen Figma-Kommentar. Öffnet Figma. Scrollt durch Kommentar-Threads in der Design-Datei. 9:14 AM|missed|Findet den Kommentar, aber er wurde als erledigt markiert, ohne dass das Linear-Issue aktualisiert wurde. Der Engineer weiß möglicherweise nicht, dass der Blocker beseitigt wurde. 9:22 AM|amber|Schreibt dem Engineer auf Slack eine Direktnachricht. Wartet auf Antwort. 9:31 AM|ok|Aktualisiert das Notion-Statusdokument mit dem bisher Gelernten. Drei Absätze, hauptsächlich darüber, was sie noch nicht weiß. 9:47 AM|missed|Stellt fest, dass sie keine eigentliche Management-Arbeit erledigt hat. Nur Informations-Archäologie.
Irgendwo dazwischen ist die Berufsbezeichnung „Engineering Manager" zu einem höflichen Synonym für „Human API Router" geworden – jemand, dessen Hauptaufgabe darin besteht, Kontext zwischen Systemen zu shutteln, die sich weigern, miteinander zu sprechen.
Das ist kein Ausnahme-Morgen. Das ist der Standard. Tool-Ermüdung für Engineering Manager bedeutet, dass die Aufgabe, zu verstehen, was im Team passiert, stillschweigend zu einer Vollzeit-Datenintegrationsübung geworden ist – und das hat niemand so geplant.
stat: "77 Minuten" headline: "Durchschnittliche tägliche Zeit für Kontextwechsel-Zusammensetzung" source: "Basierend auf dem internen Zeittracking unseres Teams über 4 Wochen"
Warum es schlimmer wird, nicht besser
Tool-Ermüdung potenziert sich – ich sage das als jemand, der es im eigenen Team beobachtet hat. Jedes neue Tool, das du hinzufügst, addiert nicht nur seinen eigenen Overhead: Es multipliziert die Verbindungen, die du zwischen bestehenden Tools aufrechterhalten musst.
Bei 5 Tools gibt es 10 mögliche paarweise Verbindungen. Bei 8 Tools sind es 28. Bei 12 sind es 66. Der Engineering Manager muss nicht alle Verbindungen aktiv nutzen, aber er muss wissen, welche existieren und welche unterbrochen sind – denn eine unterbrochene Verbindung ist genau dort, wo Informationen verloren gehen.
Und Informationsverlust im Engineering Management ist nicht abstrakt. Es ist ein Designer, der nicht wusste, dass sein Blocker behoben wurde, und deshalb zwei Tage wartete, bevor er die nächste Iteration begann. Es ist ein Sprint-Commitment, das davon ausging, dass eine Abhängigkeit abgeschlossen war, weil der Linear-Status „complete" anzeigte – aber der eigentliche PR befand sich noch im Review. Es ist das wöchentliche Sync-Meeting, bei dem die ersten fünfzehn Minuten damit verbracht werden, zu klären, was jeder individuell bereits wusste, aber nicht geteilt hatte, weil die Tools diese Signale nicht verbunden haben.
Tool-Ermüdung dreht sich nicht um die Anzahl der Tools. Es geht um die Anzahl der Lücken zwischen ihnen – und darum, dass das Schließen dieser Lücken zum inoffiziellen Zweitjob des Engineering Managers geworden ist.
Was nicht funktioniert
Drei häufige Reaktionen auf Tool-Ermüdung, die nicht wirklich helfen:
Konsolidierung um ihrer selbst willen. Der Instinkt ist verständlich: Wenn das Problem zu viele Tools sind, benutze weniger Tools. Aber Engineering-Teams haben gute Gründe für starke Meinungen zu ihren Tools. Versuche, Linear durch „das Projektmanagement-Modul in [All-in-one-Plattform X]" zu ersetzen, und schau dir die Revolte an. Die Tools sind nicht das Problem – die Lücken zwischen ihnen sind es. Einen Satz von Tools durch einen anderen zu ersetzen verschiebt die Lücken nur.
Dashboards. Ich weiß, ich weiß. Der Reiz von „einem Dashboard, sie alle zu regieren" ist fast unwiderstehlich, und jedes Enterprise-SaaS-Unternehmen hat eine Präsentation darüber. Aber die meisten Dashboards, die wir getestet haben, sind schreibgeschützte Momentaufnahmen des Zustands – sie zeigen dir, wo die Dinge stehen, aber nicht was sich seit gestern verändert hat, warum es sich verändert hat oder was du dagegen tun solltest. Ein Engineering Manager, der ein Dashboard betrachtet, muss trotzdem zu jedem Tool wechseln, um den eigentlichen Kontext hinter den Zahlen zu erhalten.
Mehr Meetings. Das ist das Schmerzhafteste, weil es so verbreitet ist. Wenn Tools nicht miteinander kommunizieren, kompensieren Teams mit synchroner Kommunikation (tägliche Standups, wöchentliche Syncs, Ad-hoc-Check-ins). Das Meeting löst das Problem nicht – es übertüncht einen defekten Informationsfluss mit menschlicher Bandbreite. Und menschliche Bandbreite ist die teuerste Ressource im Team.
Was man versucht
- Tool-Konsolidierung – 5 Tools durch 1 ersetzen. Engineers rebellieren, das All-in-one erledigt 5 Dinge mittelmäßig.
- Dashboards – schreibgeschützte Momentaufnahmen, die ohnehin Kontext aus den Original-Tools erfordern.
- Mehr Meetings – synchroner Informationstransfer, um defekten asynchronen Workflow zu kompensieren.
Was wirklich hilft
- Verbindung, nicht Konsolidierung – die Tools behalten, die Lücken zwischen ihnen schließen.
- Signal-Routing – sichtbar machen, was sich geändert hat und was Aufmerksamkeit braucht – nicht alles.
- Asynchrone Kontextlieferung – Informationen kommen dort und wann an, wo du sie brauchst, ohne Nachfragen.
Was wirklich hilft
Die Fixes, die den Kontakt mit einem echten Engineering-Team überstehen, teilen meist eine gemeinsame Eigenschaft: Sie verlangen nicht von Menschen, die Integrationsarbeit zu erledigen. Sie bauen die Verbindungen auf Systemebene auf und lassen den Engineering Manager seine Zeit für Urteilsentscheidungen aufwenden, statt für Informationsbeschaffung.
Gezieltes Benachrichtigungs-Routing. Der größte Teil von Tool-Ermüdung entsteht dadurch, dass die falsche Information am falschen Ort ankommt. Slack-Channels, die Statusupdates mit Design-Feedback vermischen. GitHub-Benachrichtigungen für Repos, in denen du nicht aktiv arbeitest. Der Fix ist nicht weniger Benachrichtigungen, sondern besser geleitete. Richte Channel-Konventionen ein (wir nutzen #proj-[name]-eng für Engineering-Signale, #proj-[name]-design für Design) und beschneide aggressiv. Eine konkrete Automation, die sich sofort auszahlt: Richte einen GitHub-Webhook ein, der PR-Statusänderungen mit der Linear-Issue-ID im Nachrichtentext in den Projekt-Slack-Channel postet. Das allein eliminiert die „Gibt es einen PR für dieses Issue?"-Prüfung aus dem morgendlichen Ritual. Keine glamouröse Arbeit, aber sie reduziert das Rauschen spürbar.
Ein wöchentliches Budget für „Informations-Archäologie". Akzeptiere, dass etwas Cross-Tool-Zusammenfügen im Moment unvermeidlich ist, und zeitboxe es. Wir reservieren montags früh dreißig Minuten speziell für den „Was ist seit Freitag in den Tools passiert?"-Scan. Geplant bedeutet, dass er nicht in jede andere Stunde der Woche einblutet, und mit Zeitbox hört man auf, wenn die Zeit abgelaufen ist, statt ins Kaninchenloch zu fallen.
Cross-Tool-Signal-Routing. Das ist die Richtung, in die sich die Kategorie entwickelt – und ja, das ist es, was wir bei Sugarbug bauen. Anstatt dass der Engineering Manager manuell Linear, dann GitHub, dann Slack, dann Figma prüft, um den Zustand der Welt zu rekonstruieren: eine Schicht, die sich über APIs mit all diesen Tools verbindet und die relevanten Änderungen, Entscheidungen und Blocker direkt zu dir leitet. Kein Dashboard – das ist passiv –, sondern etwas, das dir aktiv mitteilt, was deine Aufmerksamkeit braucht und warum. Das ähnelt eher der Art, wie ein erfahrener Team Lead dich briefen würde, wenn dieser Team Lead jeden Slack-Thread und jeden PR-Kommentar seit gestern gelesen hätte.
Die ehrliche Version unseres aktuellen Stands: Die ersten beiden Fixes funktionieren heute, und der dritte ist das, worauf Sugarbug hinarbeitet. Wir sind noch nicht fertig – wir haben noch nicht entschieden, wie aggressiv die Signal-Filterung sein soll, und das Ranking-Modell zeigt immer noch etwas Rauschen, das wir lieber unterdrücken würden. Aber die Kernarchitektur funktioniert: API-Konnektoren für jedes Tool, LLM-basierte Signalklassifizierung und ein Wissensgraph, der Personen, Aufgaben und Diskussionen über Quellen hinweg verknüpft. Er bewältigt den „Was ist seit Freitag passiert?"-Scan in Sekunden statt in siebenundsiebzig Minuten – das ist der Teil, der uns antreibt.
Die Aufgabe eines Engineering Managers sollte nicht darin bestehen, fünf Tools zu einem kohärenten Gesamtbild zusammenzufügen. Das ist die Aufgabe einer Maschine. Die Aufgabe des Menschen ist es, zu entscheiden, was mit dem Bild zu tun ist. attribution: Ellis Keane
Häufig gestellte Fragen
Lass dir Signalintelligenz direkt in dein Postfach liefern.
Q: Was ist Tool-Ermüdung für Engineering Manager? A: Tool-Ermüdung ist der kognitive und operative Aufwand, der entsteht, wenn man Arbeit über zu viele voneinander getrennte SaaS-Tools verwaltet. Für Engineering Manager bedeutet das, mehr Zeit damit zu verbringen, Informationen zwischen Linear, Slack, GitHub, Figma und Notion zu verschieben, als tatsächlich Entscheidungen damit zu treffen.
Q: Hilft Sugarbug bei Tool-Ermüdung? A: Ja – Sugarbug verbindet sich über native API-Integrationen mit deinen bestehenden Tools, klassifiziert Signale aus jedem von ihnen und zeigt dir, was wichtig ist – an einem Ort. Anstatt fünf Dashboards vor deinem ersten Kaffee zu prüfen, erhältst du den benötigten Kontext direkt geliefert. Wir iterieren noch daran, wie die Signal-Filterung genau funktioniert (ehrlich gesagt eines der schwierigeren Design-Probleme, die wir angegangen sind), aber die Kern-Pipeline ist live.
Q: Wie viele Tools nutzt ein typisches Engineering-Team? A: Die meisten Teams, mit denen wir sprechen, verwenden je nach Teamgröße und Funktion zwischen 8 und 14 SaaS-Tools. Das Problem ist nicht die Anzahl selbst, sondern der Kontext, der in den Lücken zwischen ihnen verloren geht. Wir haben Dreier-Teams mit acht Tools gesehen und Fünfzig-Personen-Teams mit neun. Die Zahl ist weniger wichtig als die Frage, ob die Tools tatsächlich Informationen teilen.
Q: Sollten Engineering Manager ihren Tool-Stack konsolidieren? A: Manchmal, aber meistens ist das der falsche Ansatz. Fünf zweckgebundene Tools durch ein All-in-one zu ersetzen, das fünf Dinge mittelmäßig erledigt, löst das eigentliche Problem nicht. Der eigentliche Fix besteht darin, die vorhandenen Tools zu verbinden, damit Informationen ohne manuelles Kopieren und Einfügen von Kontext zwischen ihnen fließen. Wenn du echte Redundanz reduzieren kannst – zwei Projekt-Tracker zum Beispiel –, tu es. Aber konsolidiere nicht um einer kleineren Zahl willen.