Erst mal einen Bereich umstellen?

„Wäre es nicht klüger, erst einen Bereich umzustellen statt das ganze Haus auf einmal?“ Diese Frage höre ich oft — und sie ist eine gute Frage. Sie klingt nach Umsicht, nach Risikogefühl, nach jemandem, der nichts überstürzt. In vielen Häusern heißt dieser Schritt schlicht: erst mal einen Piloten fahren, ein Pilotprojekt aufsetzen. Erst im Kleinen lernen, dann im Großen ausrollen: So geht man vernünftig mit Unsicherheit um. Bei einer neuen Maschine, einem neuen Markt, einer neuen Software ist der Pilot goldrichtig. Bei der Frage, wie Ihr Unternehmen geführt wird, trägt er nicht — und es lohnt, einen Moment zu sehen, warum.

Meist geht es um Bereiche, die nicht eigenständig sind: Produktion, Entwicklung, Vertrieb, Administration. Sie leben von der engen Verzahnung mit dem Rest des Hauses. Stellen Sie einen solchen abhängigen Bereich um, erzeugen Sie an seinen Rändern Inkonsistenzen. Drinnen gelten plötzlich neue Spielregeln — Teamverantwortung, dezentrale Entscheidung dort, wo sie ansteht, Steuerung über den Markt. Draußen, im unveränderten Unternehmen, gelten die alten. An dieser Grenze reibt sich beides, fortlaufend, und will fortlaufend ausgeglichen werden.

Was Sie am Ende bekommen, ist „agile“ Entwicklung oder „agiler“ Vertrieb: ein Bereich, der anders arbeitet, aber nicht anders eingebettet ist. Ein Eiland mit neuen Regeln im alten Meer. Die eigentliche Integration — der Punkt, auf den es ankäme — findet nicht statt.

Echte Selbstorganisation entsteht so nicht. Sie bleibt notwendig begrenzt und muss sich der zentralen Steuerung unterordnen — und damit bleibt auch gebunden, was an Potenzial frei würde: das meiste davon.

In der agilen Softwareentwicklung lässt sich der Vorgang im Zeitraffer beobachten. Scrum, Kanban und Co. bringen die Zugeständnisse ans Management gleich eingebaut mit. Der Product Owner etwa ist eine zentrale Verantwortung — genau dort, wo dezentrale, gemeinsame Teamverantwortung stehen müsste. Und es braucht Rollen, die das nötige Biegen und Dehnen besorgen, ohne dass etwas bricht: Scrum Master, agile Coaches. Gebogen wird dabei an zwei Fronten zugleich — an den zentralen Strukturen, die nicht nachgeben dürfen, und an den Menschen, die man per Coaching, Kulturarbeit und Mindset-Schulung passend ausrichten will.

Das ist keine Überwindung des alten Managements. Es ist seine Optimierung — aufwendig, teuer, und mit viel Mühe damit beschäftigt, Inkonsistenzen auszugleichen, die sie selbst erst erzeugt. Warum „agile Transformation“ für diesen Vorgang ein zu großes Wort ist, habe ich an anderer Stelle ausgeführt.

Hier kommt der Teil, der den Piloten von der klugen Vorsichtsmaßnahme zur Falle macht. Der Pilot sollte das Risiko senken. Aber er ist von Bauart gehemmt: Die Inkonsistenz an seinen Rändern drückt sein Ergebnis. Er kann gar nicht zeigen, was dezentrale Führung leistet — weil er sie nie ganz zulässt.

Und so liefert er am Ende einen Messwert, der trügt. Die Zahl, die Sie ablesen, heißt nicht „so viel bringt Selbstorganisation“. Sie heißt „so viel bringt eine halbe Sache unter fortbestehender Zentralsteuerung“ — also wenig. Dieser falsche Befund ist das Teuerste am ganzen Versuch, denn er bleibt nicht im Bereich. Er wandert. „Wir haben Agil probiert, viel kam nicht dabei heraus“ wird zur Erzählung im Haus. Und wenn Jahre später die echte, ganze Veränderung zur Debatte steht, argumentieren Sie gegen Ihren eigenen Piloten.

So besehen senkt der Pilot kein Risiko. Er fabriziert genau das, das er vermeiden sollte — nur später, und schwerer rückgängig zu machen.

Eine Ausnahme gibt es, und sie ist wichtig. Halten Sie das Mandat nicht — leiten Sie ein Team, eine Abteilung, einen Bereich, ohne die Autorisierung, das ganze Haus zu verändern —, dann kann genau dieser Weg richtig sein. Dann gilt: biegen, nicht brechen. Gehen Sie überlegt und fachlich sauber vor, seien Sie sich der Inkonsistenzen bewusst und gleichen Sie sie aus. Und seien Sie sich bewusst, dass „agile Transformation“ hier den Namen im Grunde nicht verdient, sondern das Optimieren von bekanntem Management ist. Das ist legitime Arbeit — und manchmal die einzige, die Ihnen offensteht.

Aus dem Sessel der Geschäftsführung rechnet sich dieselbe Rechnung anders. Sie halten die eine Autorisierung, die die Spielregeln tatsächlich ändern kann. Diese auf einen anstrengenden, aufwändigen, teuren Umweg zu verwenden, der bisheriges Management am Ende nur festigt, statt es zu überwinden — das ist die eine Option, die nicht zu Ihrem Platz passt.

Was bleibt, ist vielleicht das ungute Gefühl, ohne Probelauf springen zu müssen. Ins Ungewisse. Alles auf eine Karte. So ein wenig wie Indiana Jones vor dem Abgrund: den Schritt voller Vertrauen tun und hoffen, dass da eine Brücke ist, wo Sie noch keine sehen.

An der Stelle sind wir uns einig: Als Glaubenssprung wäre das fahrlässig. Im Indiana-Jones-Epos großes Kino, im Unternehmen schlicht unverantwortlich. Nur war die Alternative zum Piloten nie der blinde Sprung. Sie ist das Verständnis.

Sie brauchen keinen Probelauf für die Sicherheit. Sie brauchen ein Begreifen dezentraler Führung — so, wie Sie einst zentrales Management erlernt haben. Nicht auf Meinung und Bauchgefühl gestützt, sondern auf Logik, Evidenz, System- und Verhaltenswissen. Die Brücke ist dann nichts, von dem Sie hoffen, dass es sie gibt. Sie bauen sie — indem Sie verstehen, bevor Sie treten.

„Einfach mal machen“ ist keine Option. Das trügerische Sicherheitsversprechen des Piloten genauso wenig. Was beides ersetzt, ist durch nichts zu ersetzen: dass Sie es wirklich, wirklich verstehen wollen — und dann gehen.

Wie ein so geführtes Unternehmen von innen arbeitet — dezentral, marktnah, in sich stimmig —, zeigt die Serie zum BetaCodex Schritt für Schritt.