Widerstand gegen Transformation überwinden: Was Führung wirklich braucht

„Once your mindset has shifted you can implement really tricky things. Before that you cannot implement almost anything.”

Diesen Satz sagt Krisztina Kalo nicht als Motivationsphrase — sondern als operative Diagnose. Als Head of Engineering bei Frais, einem SaaS-Unternehmen, hat sie mehrere Transformationen von Waterfall zu Agile und Lean durchgeführt, darunter Operations-Teams mit über 4.500 Mitarbeitern. Ihre Erkenntnis: Der limitierende Faktor ist nie das Framework. Er ist der Mensch.

Wer Transformationen scheitern sieht — und das ist keine Ausnahme, sondern Normalzustand in Engineering- und IT-Organisationen — findet die Ursache selten im Prozess. Scrum war falsch eingeführt? Kanban-Board zu komplex? Meistens liegt es woanders: Führungskräfte schieben zu hart, zu früh, ohne die emotionale Dynamik zu verstehen. Das Ergebnis: erhöhter Widerstand, Abgänge, Stagnation.

Krisztina Kalo hat einen anderen Weg beschritten. In diesem Gespräch teilt sie sechs konkrete Frameworks, eine kritische Führungsstatistik und den kontraintuitiven Schlüsselgedanken, der alles verändert: Um schnell zu transformieren, musst du langsamer werden.

Die wichtigsten Erkenntnisse

• Druck erzeugt Gegendruck: Wer Transformation forciert, verstärkt Widerstand. Die Verlangsamung — bewusst weniger pushen — ist der Moment, in dem Widerständler von sich aus das Gespräch suchen.
• Nur 10 % der Führungskräfte befinden sich in der „Catalyst”-Phase, die echte Transformation ermöglicht. 90 % operieren in Expert- oder Achiever-Logik — und können Transformationen strukturell nicht führen.
• Informelle Kommunikation schlägt Change-Management-Meetings: Lunch, Kaffeepause und authentische 1:1-Gespräche bauen mehr Vertrauen auf als jedes formale Update-Meeting.
• Kanban vor Scrum für Ops- und Engineering-Teams: keine festen Rollen, flexible Cadence, besser geeignet für Ad-hoc-Aufgaben und Incidents.
• 3-Wochen-Experimente statt Rollouts: Teams sagen leichter „ja” zu einem begrenzten Test als zu einer permanenten Umstellung — und das Commitment danach ist deutlich höher.
• Retrospektiven brauchen Spielregeln: Teams, die nur klagen, öffnen sich nicht für echte Problemlösung. Spielerische Formate senken die Einstiegshürde und surfacen tatsächliche Hindernisse.
• Größte Gegner werden stärkste Unterstützer — aber nur mit der richtigen Herangehensweise. Wer ihnen Gehör schenkt und Freiheit zurückgibt, gewinnt die machtvollsten Change-Champions.

Im Detail: Widerstand gegen Transformation überwinden — was Führungskräfte wirklich tun müssen

Transformationen scheitern nicht wegen Widerstand gegen Veränderung, sondern wegen schlechter Führung derselben. In technischen Organisationen entsteht der größte Reibungsverlust, wenn Führungskräfte neue Frameworks top-down einführen, ohne ihre Teams in die Gestaltung einzubeziehen. Was wirklich funktioniert: Partizipation statt Anordnung.

Das Kernproblem: Warum Transformationen in technischen Organisationen scheitern

Engineering-Teams und Ops-Teams sind nicht gegen Veränderung. Sie sind gegen schlecht geführte Veränderung. Dieser Unterschied ist entscheidend für jede Führungskraft, die eine Agile Transformation, eine DevOps-Transformation oder einen Lean-Management-Umbau verantwortet.

Das Muster ist immer ähnlich: Ein neues Framework wird eingeführt, ein externer Berater oder interner Change-Leader gibt die Richtung vor, und die Mehrheit der Mitarbeitenden folgt — widerwillig oder formal. Aber eine Minderheit mit hoher informeller Macht blockiert. Sie stellen Fragen, die keine echten Fragen sind. Sie finden Gründe, warum es nicht funktionieren kann. Und solange diese Personen nicht überzeugt sind, bleibt die Transformation auf dem Papier.

„The moment you take the speed back and keep it a little bit more silent — this is when these opposers come to you.” — Krisztina Kalo

Das ist der kontraintuitive Kern: Weniger Druck führt zu mehr Bewegung. Wer als Transformationsverantwortlicher begreift, dass erhöhte Geschwindigkeit erhöhten Widerstand erzeugt, hat den ersten strategischen Hebel identifiziert.

Warum nur 10 % der Führungskräfte Transformationen wirklich führen können

Dies ist die unbequemste Zahl aus dem Gespräch — und die wichtigste für jede Organisation, die plant, sich grundlegend zu verändern.

Studien zeigen, dass nur 10 % der Führungskräfte sich in der sogenannten „Catalyst”-Phase befinden. Diese Phase ist geprägt von Empathie, Systemdenken und der Fähigkeit, das große Bild zu sehen — also genau die Kompetenzen, die Transformation braucht. Die restlichen 90 % befinden sich in der Expert- oder Achiever-Phase: stark in Fachkompetenz und Ergebnislieferung, aber nicht darauf ausgerichtet, Menschen durch fundamentalen Wandel zu führen.

„Studies have shown that only 10% of leaders are in that catalyst state. Which means that if you really want to transform from waterfall to lean or lean ops or dev ops or agile or whatnot — then you need to have one of those one out of 10 leaders.” — Krisztina Kalo

Praktische Konsequenz für PMO-Verantwortliche und IT-Führungskräfte: Bevor eine Transformation startet, muss die Frage beantwortet werden, wer sie führt — nicht wer formal zuständig ist, sondern wer in der Lage ist, Empathie, Geduld und systemisches Denken unter Druck aufrechtzuerhalten. Das ist kein Softskill-Problem. Es ist eine strategische Besetzungsfrage.

Informelle Kommunikation als Transformations-Hebel: Was formale Change-Meetings nicht leisten

Change-Management-Literatur fokussiert auf Kommunikationspläne, Stakeholder-Maps und formale Update-Meetings. Krisztina Kalos Erfahrung zeigt: Diese Instrumente sind notwendig, aber nicht hinreichend. Der eigentliche Wandel passiert in der Kaffeepause.

Das Backpack-Framework illustriert das eindrücklich. Ein besonders kritischer Mitarbeiter — mit hohem Widerstand gegen neue Priorisierungsmethoden — wurde nicht durch ein Meeting überzeugt. Der Durchbruch kam über eine Analogie: Statt abstrakte Kanban-Logik zu diskutieren, wurde das Bild eines Rucksacks verwendet, aus dem der Mitarbeiter selbst entscheidet, welche Aufgabe er als nächstes herausnimmt. Die emotionale Botschaft war Kontrolle und Freiheit statt Prozesszwang.

„Analogy is a really nice tool. When I managed to get the interest of this person […] it’s his view to his tasks and he can open the backpack the way he wants and when the freedom were also seen that the new way of working maybe gives more freedom of choosing which one I take from the backpack first — then the shift started to happen slowly.” — Krisztina Kalo

Parallel dazu: mehrere gemeinsame Mittagessen, ohne Status-Agenda. Authentisches Teilen eigener Transformationserfahrungen. Das Signal: „Ich bin nicht dein Feind.”

Das Informelle-Kommunikation-Framework in fünf Schritten:

1. Größten Widerständler als Schlüsselperson identifizieren
2. Gemeinsame Interessen oder geteilte Geschichte recherchieren
3. Lunch oder Kaffeepause initiieren — kein Formal-Meeting
4. Authentisch eigene Perspektive teilen: „Ich kenne diesen Weg, ich habe ähnliches erlebt”
5. Regelmäßig wiederholen, bis Vertrauen entstanden ist — erst dann sind Argumente hörbar

Kanban für Operations-Teams: Warum Scrum strukturell nicht funktioniert

Einer der häufigsten Fehler bei der Einführung agiler Methoden in Ops- und Engineering-Teams: Scrum 1:1 zu übernehmen, weil es in Development-Teams funktioniert.

Ops-Teams leben in einer anderen Realität. Sie haben keine fixen 2-Wochen-Sprints. Sie haben Incidents, Ad-hoc-Anfragen, Zertifikatsprobleme, Windows-Neuinstallationen — also eine fundamentale Unvorhersehbarkeit, die Sprints strukturell unterminiert.

„An operations team cannot keep the same cadence. They have also ad hoc to-dos. We have to now reinstall windows. We have to now look at the certificates […] And I haven’t talked about incidents and problems yet.” — Krisztina Kalo

Kanban ist der bessere Einstiegspunkt — nicht weil es einfacher ist, sondern weil es realistischer ist. Keine Rollenzwänge (kein Scrum Master zwingend erforderlich), keine feste Cadence, bessere Integration von Ad-hoc-Aufgaben.

Stufenweise Kanban-Einführung (Start Where You Are):

1. Backlog aufbauen: Was ist zu tun?
2. Board visualisieren — physisch oder digital, je nach Team-Präferenz
3. WIP-Limit einführen: maximal 3 gleichzeitige Tasks pro Person
4. Flow wöchentlich messen und reflektieren — nicht bi-weekly
5. Technical Product Manager oder Product Owner zur wöchentlichen Priorisierung hinzuziehen

Die wöchentliche Priorisierungssession — 30 Minuten, Montag oder Dienstag, Team plus Product Owner plus Engineering Manager — ersetzt tägliche Standup-Overheads ohne Informationsverlust. Das Team kennt seine Aufgaben für die Woche, Ad-hoc-Aufgaben bleiben flexibel integrierbar.

Wie 3-Wochen-Experimente Adoptionsbarrieren dramatisch senken

Permanente Veränderung erzeugt Angst. Zeitlich begrenzte Experimente nicht.

Krisztinas Methode: keine Rollouts, sondern 3-Wochen-Piloten mit klar definierten Erfolgskriterien und anschließender Retrospektive. Teams, die „nein” zu „ab sofort agile” sagen würden, sagen deutlich häufiger „ja” zu „Wir testen das drei Wochen lang, dann schauen wir gemeinsam, was funktioniert hat.”

Das psychologische Prinzip dahinter: Die Angst vor dem Unumkehrbaren verschwindet. Das Experiment ist limitiert, kontrollierbar, und das Team hat Mitsprache bei der Auswertung.

„It’s hard to get the people to really say yeah okay let’s try it out for three weeks and then regularly go into it and really look what works what doesn’t work.” — Krisztina Kalo

3-Wochen-Experiment-Framework:

1. Mit dem Team vereinbaren: „Wir testen das drei Wochen lang”
2. Klare Erfolgskriterien definieren (z. B. „Wir sehen Postits, die in der Woche fertig werden”)
3. Retrospektive nach drei Wochen: Was funktioniert, was nicht?
4. Abstimmung: Weitermachen, pausieren oder anpassen?
5. Bei positivem Signal: nächste drei Wochen — jetzt formalisiert

Retrospektiven als Change-Engine: Warum klagen kein Feedback ist

Das häufigste Retroformat in Transformationsprojekten: Alle sitzen zusammen und beschweren sich. Das fühlt sich nach Partizipation an, ist es aber nicht.

„At the beginning they only just complaining, complain. Everybody just complains […] it’s very important to use different tools in my opinion so that the team loosens up at least for the retrospective.” — Krisztina Kalo

Spielerische Einstiege — Emoticons, Team-Radar, 3-2-1-Retro-Formate — senken die Hemmung und erzeugen eine andere Gesprächsqualität. Widerständler, die in formalen Settings schweigen oder opponieren, öffnen sich in niedrigschwelligen Formaten eher.

Der entscheidende Schritt danach: Retro-Outputs in das Kanban-Board integrieren, sodass Verbesserungen sichtbar werden. Teams, die sehen, dass ihre Rückmeldungen tatsächlich zu Änderungen führen, bauen Vertrauen in den Prozess auf — und das ist die Grundlage für nachhaltige Verhaltensänderung.

Was Erfolg aussieht: Sechs Monate, null Abgänge

Krisztina Kalo nennt zwei Metriken, die den Erfolg ihrer Herangehensweise quantifizieren: