Kein Tool ist in Stein gemeißelt

Die meisten Teams wissen, dass ihre Tools nicht funktionieren. Sie bleiben trotzdem.

Nicht weil das Tool gut ist. Sondern weil ein Wechsel teuer erscheint. Weil niemand weiß, was die Alternative wäre. Weil das letzte Mal, als jemand eine Änderung vorschlug, daraus ein sechsmonatiges Projekt wurde. Weil alles um das aktuelle Setup herum gebaut wurde und das Entwirren unmöglich erscheint. Also passt sich das Team an, arbeitet um die Limitierungen herum, fügt Workarounds auf Workarounds hinzu, und die Reibung wird unsichtbar, weil sie schon immer da war.

Das passiert, wenn Change Management kein Unternehmensprinzip ist. Wenn die Standardannahme ist, dass Tools, Prozesse und Strukturen permanent sind, es sei denn, es gibt eine Krise. Die Kosten dieser Annahme summieren sich still über die Zeit, und die meisten Teams berechnen sie nie.

Die Alternative ist kein Chaos. Es geht darum, ein Unternehmen von Tag eins an so aufzubauen, dass Veränderung erwartet, eingeplant und günstig ist.

Change Management als Designprinzip

Wenn man ein Team mit der Annahme aufbaut, dass nichts permanent ist, baut man anders. Man schafft keine tiefen Abhängigkeiten von spezifischen Tools. Man lässt Dokumentation nicht nur an einem Ort leben. Man verdrahtet den gesamten Workflow nicht mit einer einzelnen Plattform auf eine Weise, die Migration wie eine Operation erscheinen lässt. Man hält Teams klein und autonom genug, dass eine Tooling-Entscheidung in einem Team keinen unternehmensweiten Rollout erfordert, um sie zu ändern.

Das Prinzip lautet nicht "häufig wechseln". Es lautet: "Niemals die Kosten des Wechsels zu einem Grund werden lassen, irgendwo zu bleiben, das nicht mehr passt." Das ist ein subtiler, aber wichtiger Unterschied. Häufiges Wechseln um seiner selbst willen untergräbt das Vertrauen und schafft Instabilität. Aber die Angst vor dem Wechsel, die Art, die Teams in Tools festhält, die sie längst entwachsen sind, ist genauso schädlich und weitaus häufiger.

In der Praxis bedeutet das, von Tag eins an zu kommunizieren, dass kein Tool in Stein gemeißelt ist. Nicht als Warnung, sondern als Designprinzip, das prägt, wie Menschen bauen und woran sie festhalten.

Wie eine echte Migration aussieht

Wir sind von Jira zu GitHub Issues gewechselt und dann zu dem, was Motion geworden wäre. Jeder Wechsel hatte einen Grund. Jira hatte alles, was wir brauchten, fühlte sich aber schwerfällig an, zu viel Overhead für das Tempo, in dem wir uns bewegten. GitHub Issues ergab auf dem Papier Sinn: schon vorhanden, ein Tool weniger, passt zum Prinzip, weniger zu tun. In der Praxis war es auf eine Weise verwirrend und ungewohnt, die das Team verlangsamte. Wir wussten es innerhalb von Tagen. Wir blieben trotzdem ein paar Wochen, weil ein sofortiger Wechsel chaotisch gewirkt hätte, und es gibt einen Unterschied zwischen der Bereitschaft zur Veränderung und Impulsivität.

Die Entscheidung zum Wechsel war meine. Ich gab dem Team ein bis zwei Wochen Zeit, sich eine Meinung zu bilden, sammelte diesen Input und entschied dann. Kein Ausschuss, keine Abstimmung, kein monatelanger Evaluierungsprozess. Ein klarer Verantwortlicher, ein angemessenes Zeitfenster, eine Entscheidung.

Was die ganze Sache günstig machte, waren zwei Dinge. Erstens die Infrastruktur, die wir bereits aufgebaut hatten. AI und MCP erledigten den Großteil der Migration. Der eigentliche Wechsel dauerte Sekunden bis Minuten. Alle mit dem neuen Tool vertraut zu machen, dauerte ein paar Tage, aber nur wenn der Verantwortliche die Änderung klar und früh kommunizierte. Zweitens migrierten wir nicht alles. Wir ließen den Ballast zurück. Nur was aktiv benötigt wurde, kam mit. Alles, was wochenlang nicht angefasst worden war, wurde fallen gelassen. Der Toolwechsel wurde zu einem natürlichen Filter. Was überlebte, war das, was tatsächlich zählte.

Und es gibt einen Bonus, den die meisten übersehen: Jeder Wechsel ist auch eine Gelegenheit, die Automatisierung zu verbessern. Man wechselt nicht nur zu einem neuen Tool, man baut die Integrationsschicht neu auf, und das ist eine Chance, es besser zu machen als zuvor. Teams, die Migrationen als Optimierungszyklen behandeln, kommen schneller auf der anderen Seite heraus, nicht nur anders.

Warum Horten den Wechsel teuer macht

Je weniger man ansammelt, desto günstiger wird jeder Wechsel. Eine Migration ist nur schmerzhaft, wenn man Dinge angehäuft hat, die man nicht loslassen wollte. Tausende von Tickets, die niemand anschaut. Dokumentation, die seit einem Jahr nicht geöffnet wurde. Automatisierungen, die um die Eigenheiten eines spezifischen Tools herum gebaut wurden, statt um ein Prinzip, das reisen könnte.

Im Zeitalter der KI ergibt das Horten operativer Inhalte noch weniger Sinn als früher. KI generiert Meeting-Zusammenfassungen, Ticket-Entwürfe, Statusupdates und routinemäßige Dokumentation. Das muss man nicht bewahren. Es kann regeneriert werden. Was man bewahren muss, sind die Dinge, die über die Zeit wahr bleiben: Konzepte, Prinzipien, Validierungen, Architektur-Reasoning, die Entscheidungen, die das Produkt Monate später noch leiten. Das sind die Inputs, aus denen KI und Teammitglieder ihre aktuelle Arbeit ableiten. Alles andere ist vorübergehend.

Wenn man mit dieser Unterscheidung im Hinterkopf baut, hört der Wechsel von Tools auf, ein Dokumentationsproblem zu sein. Der zeitlose Inhalt reist mit. Die operative Schicht regeneriert sich. Die Migrationskosten sinken auf fast nichts.

Wie viel von dem, was gerade in Ihrem Backlog liegt, würden Sie tatsächlich vermissen, wenn es morgen verschwände?

Ein Tool für das gesamte Unternehmen ist keine Tugend mehr

Früher gab es ein starkes Argument für die Standardisierung auf ein einziges Toolset im gesamten Unternehmen. Weniger Schulung, weniger Integrationskomplexität, einfacheres IT-Management. Dieses Argument ist jetzt schwächer als je zuvor.

MCP und KI sind universelle Informationsschnittstellen. Es ist ihnen egal, welches Projektmanagement-Tool ein Team verwendet. Sie können aus Jira oder GitHub Issues oder Motion oder allem anderen lesen. Sie können in Confluence oder Notion oder eine Markdown-Datei schreiben. Die Integrationsschicht, die früher erforderte, dass alle dasselbe Tool verwenden, sitzt jetzt auf den Tools, die für die tatsächliche Arbeit jedes Teams sinnvoll sind.

Das bedeutet, dass ein Produktteam, das Linear verwendet, ein Engineering-Team, das GitHub Issues verwendet, und ein Operations-Team, das Motion verwendet, alle Kontext über dieselbe KI-Schicht teilen können, ohne dass einer von ihnen beim Tool Kompromisse eingehen muss, das am besten zu seinem Workflow passt. Die Kosten dieser Heterogenität sind dramatisch gesunken. Der Nutzen, jedem Team das richtige Tool für seinen Kontext zu geben, hat sich überhaupt nicht geändert.

Der tiefere Punkt

Jedes Tool, das Sie verwenden, kodiert Annahmen darüber, wie Arbeit fließen sollte. Diese Annahmen ergaben Sinn, als Sie das Tool gewählt haben. Sie ergeben möglicherweise keinen Sinn mehr. Die Disziplin des Change Managements als Standardwert ist die Disziplin, dabei ehrlich zu bleiben, konsequent, bevor die Reibung unsichtbar wird.

Bauen Sie kleine, autonome Teams. Halten Sie Dokumentation toolagnostisch. Bewahren Sie, was zeitlos ist, lassen Sie KI handhaben, was vorübergehend ist. Machen Sie das Prinzip von Tag eins an explizit. Und wenn ein Tool der Arbeit nicht mehr dient, behandeln Sie den Wechsel als Optimierungsgelegenheit, nicht als Krise.

Die KI- und Automatisierungsschicht, die all dies ermöglicht, entwickelt sich selbst schneller als jedes der Tools, die darauf sitzen. Wie diese Schicht aussieht und wie man darauf aufbaut, ohne sich einzuschließen, ist das Thema des nächsten Beitrags.