Mitarbeiterentwicklung: fachliches Hierarchiedenken oder Eigenverantwortung mit individueller Anerkennung?

Die sukzessive Umsetzung agiler Managementprinzipien in Softwareentwicklungsunternehmen fordert nicht nur dem Management massive Veränderungen ab. Auch seitens des Mitarbeiters ist ein Umdenken erforderlich. Dies betrifft in besonderer Weise – wenn auch nicht ausschließlich – den Blick auf den persönlichen Karrierepfad und die Art und Weise, wie dieser beschritten wird.

Junior – Experte – Senior – Architekt?

In klassischen Organisationen wird der Weiterentwicklung von Entwicklern in der Regel mit dem Ansatz begegnet, dass der Arbeitgeber vergleichbar einer hierarchischen Struktur fachliche Rangstufen definiert. Diese sind häufig mit der Gehaltsentwicklung verknüpft, ohne jedoch eine konkrete Veränderung der Rolle mit sich zu bringen. Klassifiziert und honoriert wird eine Persönlichkeitsentwicklung – wobei die Kriterien, wie die jeweils nächste Stufe erreicht wird, zumeist unklar sind.

Ist das Alter ein Kriterium? Oder die Anzahl der Projekte? Die Dauer der Unternehmenszugehörigkeit? Die Begleitung bestimmter Fortbildungen? Die Einschätzung der fachlichen Kompetenz durch den disziplinarischen Vorgesetzten? Bei der individuellen Entscheidung für einen Mitarbeiter, ob die nächste Stufe erreicht wurde, wirken vielfach mehrere dieser Aspekte mit - gewürzt von einer ordentlichen Portion Willkür.

Architekt. Und was nun?

Mit zunehmendem Alter, Erfahrung und langjähriger Betriebszugehörigkeit erreichen Softwareentwickler nahezu automatisch den obersten Rang: ob der nun „Senior Architect“, „Chief developer“ oder gar „Heavy chief“ heißt. Was passiert dann? Ist die Persönlichkeitsentwicklung mit 38 Jahren abgeschlossen? Oder ist die Voraussetzung für eine weitere Entwicklung des Mitarbeiters eine fachlich bzw. organisatorische Veränderung – was letztlich heißen kann, dass er nicht mehr das tun kann, was ihm am meisten liegt.

Es ist offensichtlich: selbst in klassischen Organisationen ist dieses Entwicklungsmodell wenig überzeugend. Umso erstaunlicher ist seine große Verbreitung. In agilen Organisationen entsteht der Bruch bereits in der Konzeption: wieso sollte ich eine differenzierte, fachliche Hierarchie aufbauen, wenn ich mich auf der anderen Seite bemühe, organisatorische Hierarchiestrukturen zu nivellieren?

Mitarbeiter und Management sind ratlos

Mit der zunehmenden Etablierung agiler Managementansätze in der Organisation tritt das Problem offen zutage. Der Mitarbeiter wünscht sich einen Entwicklungspfad und ist typischerweise in der Denkweise verhaftet, die er von früher – oder aus anderen Unternehmen – kennt. Schulterklappe und Visitenkarte haben noch ihren Wert.

Der agile Manager steht dem hilflos gegenüber: er kann die fachlichen Fähigkeiten des Mitarbeiters nur bedingt bewerten, da er auch keine fachliche Führung übernimmt (die erfolgt im Team). Die Einführung von Hierarchiestufen innerhalb von agilen Entwicklungsteams wird als kontraproduktiv wahrgenommen. Darüber hinaus ist das Bild dessen, was einen guten Softwareentwickler ausmacht, in einer agilen Entwicklungsorganisation deutlich vielschichtiger als es sich gewohnterweise darstellt. In einem gut positionierten Team ist der immer fröhliche, stets motivierende, aber fachlich nur mittelmäßige Entwickler ein genauso wertvolles Mitglied wie der introvertierte Spezialist, der die schwierigsten Probleme wegräumt. Auf welcher Basis verteilt man da Ränge?

Weniger Kontrolle, mehr Verantwortung

Die Herausforderung besteht darin, einen Weg zu finden, der die Entwicklung heterogener Persönlichkeiten in einem prinzipiell rangfreien Umfeld unterstützt.

Wie bei vielen Teilaspekten agiler Transformation steht und fällt der Erfolg damit, im Management Kontrolle abzugeben und dem Mitarbeiter Verantwortung zu überlassen – der diese auch annehmen muss. Hierin verbirgt sich insbesondere auf Mitarbeiterseite die maßgebliche Leistung des Umdenkens: es liegt an ihm eigene Ziele zu entwickeln, sowohl mittelfristig als auch langfristig. Unterstützt wird der Mitarbeiter hierbei durch sein Team, welches - bei genügender Reife - in der Lage sein sollte, ihm in den regelmäßigen Retrospektiven ein Bild zu vermitteln, wie seine jeweiligen Kompetenzen ausgeprägt sind.

Die Rolle des Managements besteht darin, den Mitarbeiter in diesem Prozess zu begleiten. Es reflektiert seine Ideen, hilft ihm sein Selbstbild mit den äußeren Wahrnehmungen in Einklang zu bringen und unterstützt ihn bei der Ableitung der nächsten Schritte. Angereichert wird dies durch richtungsweisende Impulse fundierend auf der technischen und strategischen Ausrichtung des Unternehmens und daraus abgeleiteten, unmittelbaren Entwicklungsangeboten.

Individuelle Weiterbildung einfordern

Die zentralen Angebote sind ein Mittel des Managements, die Mitarbeiter zu aktivieren. Dadurch werden sie aber nicht der Verantwortung enthoben, selber initiativ zu werden: es gilt grundsätzlich aus Sicht des Mitarbeiters das Pull-Prinzip. Vorgekaute Fortbildungsprogramme, definierte, fachliche Karrierepfade mit Entwicklungsstufen, die nach Abschluss bestimmter Zertifizierungen zu neuen Rangstufen führen, sind explizit nicht Bestandteil des Vorgehens. Wichtig ist allein, dass der Mitarbeiter für sich erkennt, wo seine individuellen Stärken und Schwächen liegen. Er muss den Eigenwillen mitbringen, seine Stärken zu entwickeln und Strategien zu erarbeiten, einen geeigneten Umgang mit seinen Schwächen zu finden oder diese mittel- bis langfristig zu relativieren.

Vielfalt ermöglichen

Die entstehenden Weiterentwicklungsmöglichkeiten sind vielfältig. Sie basieren auf einer Gesamtreflektion des Könnens und Vermögens des Mitarbeiters und beschränken sich nicht allein auf seinen fachlichen Fokus. So kann das Ziel von individuellen Weiterentwicklungsangeboten auch darin bestehen, die Präsentationsfähigkeit zu stärken, die Fähigkeit zu entwickeln, qualifiziertes Feedback zu geben oder Wissen zu vermitteln.

Es obliegt dem Management, hier die richtige Gratwanderung zwischen den Anliegen des Mitarbeiters zu finden, die eher seiner privaten Persönlichkeitsbildung dienen und denjenigen, die letztlich die Arbeit des Teams unterstützen und damit dem Unternehmen dienen. Der mögliche Raum ist jedoch weit gesteckt.

Was macht den Erfolg aus?

Für alle Seiten – Management, Team und Mitarbeiter – bleibt der Wunsch, die Summe der Bemühungen langfristig im Blick zu behalten. Dies kann in einfacher Weise durch die Dokumentation konkreter Fortbildungs- und Coachingaktivitäten erfolgen. Die Auseinandersetzung zwischen Mitarbeiter und Manager im Hinblick auf getroffene Maßnahmen und erzielten Wirkungen ist dann steter Bestandteil der weiteren Personalentwicklung.

Häufig stellt dies aber gerade die Mitarbeiter nicht abschließend zufrieden. Es besteht das verständliche Bedürfnis, nicht nur eine Maßnahmendokumentation in Händen zu halten, sondern auch eine Dokumentation der persönlichen Erfolge.

An diesem Punkt könnten Führungskräfte wieder auf die eindimensionale Betrachtungsweise „Junior – Senior – Architekt“ zurückfallen, in dem sie den Versuch unternehmen, die unterschiedlichsten Aktivitäten in Themenblöcke zu fassen und die Titelvergabe nach „Zielerreichungsgraden“ in den jeweiligen Kontexten zu richten. Damit würden sie das Vorgehen jedoch ad absurdum führen: Die mühsam geschaffenen Voraussetzungen zur Abbildung von Individualität und Vielfalt gehen neuerlich verloren und wir stoßen wieder auf die Endlichkeit des Konzepts im Hinblick auf die Dokumentation der persönlichen Weiterentwicklung.

Viel besser ist es hier, die tatsächlichen Erfolge, die durch die Weiterentwicklung erzielt werden, als solche zu feiern. Ein Mitarbeiter, der zuvor Schwierigkeiten hatte, vor unbekannten Menschen die Stimme zu erheben und nun seinen ersten Vortrag auf einer Konferenz hält, hat einen nennenswerten Erfolg erzielt. Dieser sollte erwähnt und zumindest symbolisch individuell belohnt werden. Stellt der Mitarbeiter fest, dass ihm die Vortragstätigkeit sogar richtig Spaß macht und wiederholt sein Engagement auf unterschiedlichen Konferenzformaten, so ist auch das ein guter Grund für eine besondere Auszeichnung.

Bei der Bewertung des Erfolgs spielt natürlich – davon kann sich niemand lösen – die persönliche Berufserfahrung eine Rolle. Diese Dimension bleibt, sofern sie nicht an Jahren der Berufserfahrung oder Ähnlichem festgemacht wird, zwangsläufig subjektiv.

Von Spielen lernen: Neue Entwicklungen im Badge-System

Die individuelle Würdigung gelingt durch die Einführung eines differenzierten Systems von kontextabhängigen „Abzeichen“ (oder auch als Anglizismus „Badges“), die Mitarbeiter unter bestimmten Rahmenbedingungen gewinnen können, die unternehmensöffentlich sind und auch Niederschlag in den Personalinformationen bis hin zum Arbeitszeugnis finden können.

So gelingt äußerst leicht die Abbildung von hochdifferenzierten Weiterentwicklungsmöglichkeiten weniger mit Blick auf die zugrundeliegenden Maßnahmen, sondern vielmehr mit dem Fokus auf den individuellen Erfolg, der aus den Maßnahmen resultiert. Dem Umfang des Badge-Systems sind faktisch keine Grenzen gesetzt, womit das Problem der „Endlichkeit“ des Weiterentwicklungskonzepts entfällt.

Bei einem durchdachten Design des Badge-Systems wird noch ein maßgeblicher, positiver Zusatzeffekt erzielt: es können dieselben Anreizmechanismen greifen, die auch Grundlage von herkömmlichen Spielkonzepten sind. So wirkt dann für den Mitarbeiter nicht mehr allein der abstrakte Gedanke an Weiterentwicklung motivierend, sondern darüber hinaus der Ehrgeiz, das nächste „Badge“ für sich zu gewinnen.

Sorgsam sollten Führungskräfte hier allerdings darauf achten, dass die persönliche Motivation des Mitarbeiters und das Badge-System nicht so interagieren, dass im Ergebnis der Mitarbeiter den Fokus auf seine Kerntätigkeit verliert. Hier ist wieder die Wechselwirkung mit Team und Management als regulierende Faktoren entscheidend.

Alle gewinnen

Gelingt es, den Mitarbeitern diesen Weg nahezubringen und gleichzeitig das Management zu befähigen, eine zielgerichtete Begleitung zu ermöglichen, gewinnen alle. Der Mitarbeiter lernt, selbst seine Ziele zu stecken und entwickelt sich ihnen entsprechend weiter. Er sieht dies dokumentiert und als Bestandteil seines Lebenslaufs. Über das Badge-System erfolgt eine Strukturierung des Erreichten mit dem Fokus auf den Erfolgen und weniger auf dem Abarbeiten von Lerninhalten.

Das Management verschiebt seinen Fokus von einer Führung der Mitarbeiterentwicklung auf ein Coaching des Mitarbeiters zu einem selbstgestaltenden, mündigen und vermehrt eigenmotivierten Kollegen. Damit stärkt der Mitarbeiter das Team und kann seinen Beitrag zum gemeinsamen Erfolg des Unternehmens erhöhen.

Und schließlich: fachliche Ränge gehören der Vergangenheit an.

Der Mechanismus des Scheiterns

Im Zuge der „Digitalisierung“ suchen viele Unternehmen aktuell Mittel und Wege, wie sie ihre eigene Version einer „Digitalisierungsstrategie“ ausbilden können. Sobald sich ausprägt, was dies inhaltlich bedeuten könnte, stellt sich die Frage - gerade bei historisch wenig IT-affinen Unternehmen - wie die entwickelten Ansätze praktisch umgesetzt werden können. Auf oberster Abstraktionsebene läuft dies auf eine klassische Make-or-Buy-Entscheidung hinaus … allerdings mit einer besonderen Herausforderung: das was hier geschaffen werden soll hat den Anspruch, in Zukunft nicht nur maßgeblich zur Wertschöpfung beizutragen, sondern muss zu jedem Zeitpunkt der Entwicklung hochgradig wandelbar sein, um der Marktentwicklung folgen zu können. Darüber hinaus besteht häufig der Anspruch, etwas "Neues" zu erschaffen, dessen strategische Bedeutung für das Unternehmen so groß ist, dass es vernünftig erscheint, dass das entstehende Asset vollumfänglich in Eigenregie und -produktion entsteht. Um diesen Aspekten gerecht zu werden,  fällt die Entscheidung ungewöhnlich häufig auf "Make".

Diesen Weg der Entscheidungsfindung und mögliche Alternativen möchte ich an dieser Stelle gar nicht weiter diskutieren - auch wenn es für sich genommen ein hochinteressantes Thema ist. Was nun vielmehr im Fokus stehen soll ist die Frage: Was passiert, wenn eine vollumfängliche "Make"-Entscheidung gefällt worden ist?

Unternehmen ohne Erfahrung in der Erstellung von Softwareprodukten sind gezwungen eine neue Organisation aufzubauen. Eine Weiterentwicklung bestehender IT-Strukturen schließt sich in der Regel aus: Das tatsächliche methodische und technische Know-How der IT-nahen Organisationsteile, deren bisheriger Fokus allein die Aufrechterhaltung und Weiterentwicklung des Legacy-IT-Betriebs war, ist hierfür nach Befinden aller - häufig auch der betroffenen Organisationsteile selbst - nicht hinreichend.

Die neue Struktur soll dann auch nach den augenblicklich modernsten Kriterien handlungsfähig sein. Ein reichhaltiges, externes Beratungsangebot hilft den Unternehmen hierbei, ihr Zielbild zu entwickeln. Das Ergebnis ist in der Regel die Empfehlung zum Aufbau einer von der Hauptorganisation entkoppelten IT-Zweigs mit einer lupenrein agilen Ausrichtung. Erstere Entscheidung folgt der Überlegung, dass eine solche organisatorische Abbildung der strategischen Bedeutung des Vorhabens am Besten gerecht wird und die Loslösung von womöglich einengenden Konzernrestriktionen darüber hinaus aus vielerlei Gründen vernünftig sein mag.

Aber wie kommt es zu der Überzeugung, dass die Organisation agil sein soll? Die bis zu diesem Zeitpunkt handelnden Entscheider haben - mit Verlaub - in der Regel nicht die leiseste Ahnung, was das für sie und die neue Organisation bedeutet. Die Entscheidung fällt dennoch in diese Richtung,

• weil das Beratungsumfeld dies forciert,
• weil die großen, international erfolgreichen Softwarekonzerne agil arbeiten (und diese das Vorbild für die zukünftige Geschäftsentwicklung sind),
• weil man sich in der Frühphase des Aufbauprozesses der neuen Organisation bereits  erfahrene IT-Manager als zukünftige Führungsriege an Bord geholt hat, die entweder aus eigener Erfahrung den agilen Ansatz favorisieren oder weil es gerade en vogue ist,
• weil die oberflächliche Selbstbeschäftigung des Managements mit dem Thema im Ergebnis häufig nur ein sehr reduziertes Bild erzeugt: Agilität erhöht Time-to-Market und ermöglicht Flexibilität - im schlimmsten Fall glaubt man auch noch, nachweislich günstiger Software erstellen zu können. Mögliche Nebeneffekte dieser methodischen Assets bleiben im Hintergrund.

So startet die neue Innovationstochter losgelöst vom Konzern in agilem Gewand. Je nach Führungsmannschaft der ersten Stunde besteht tatsächlich die Chance, dass die Unternehmenskultur vorbildlich im Sinne agilen Managements ist. Mitbestimmung, Verantwortungsteilung, Fehlertoleranz und flache Hierarchien bestimmen das Miteinander. Der Ergebnisdruck ist von Anfang an erheblich, dem wird mit hoher Motivation und ohne politische Schönfärberei begegnet. Das wird konzernseitig anfangs als exotisch charmant aber mit der Zeit als zunehmend unprofessionell wahrgenommen.
Der Druck wächst und äußert sich zunächst in einem beschleunigten Organisationsaufbau. Das steht einem agilen Managementansatz auch nicht entgegen, dient aber nicht der Sache. In der Softwareentwicklung gilt selten das Motto "viel hilft viel" und eine stark skalierende Scrum-Organisation erzeugt in sich neue Herausforderungen, die nicht unmittelbar auf den extern wahrgenommenen Geschäftswert des Softwareproduktes einzahlen.

So lässt der Konzern seine neue Tochter agieren, bis ein Punkt erreicht wird, an dem die Zusammenarbeit an den Schnittstellen beginnt zu brechen. Hierfür gibt es ein Spektrum an möglichen Gründen, die im Kern immer auf dasselbe Problem hinauslaufen: die bestehenden, konzernseitigen Erwartungshaltungen werden im Hinblick auf die Umsatzentwicklung, die Entwicklung neuer Features oder der Kundenzahlen enttäuscht. Hierbei muss man sich vor Augen führen, dass in der Regel die Verantwortlichen der agilen Tochtergesellschaft entweder in die Zielfindung gar nicht eingebunden oder nach dem Duktus eines klassischen Management-Commitments verpflichtet wurden.

Ist dieser Punkt erreicht, so gerät die agile Organisation in existenzielle Gefahr. Der Konzern verliert das Vertrauen und beginnt methodisch fremde Projektcontrollingmechanismen einzufordern oder bereits durch äußeren Zwang in der Organisation umzusetzen. Es werden langfristige fachliche Commitments eingefordert, Releasepläne eingeführt und deren Einhaltung peinlichst überwacht. Dies geschieht maßgeblich aus dem in der klassischen Geschäftswelt tief verankerten Wunsches eines langfristigen Plans, der dem Manager bei einer aktuell nicht befriedigenden Geschäftsentwicklung ein Gefühl der Sicherheit suggeriert, dass am Ende alles zum Erfolg kommt.

Diese "Planwirtschaft" ist tatsächlich aber der Sargnagel für den Erfolg. Agile Methoden dienen dazu, Kreativität in Kombination mit Flexibilität in der Produktentwicklung zu vereinen, um in einem sich schnell entwickelndem Markt- und Technologieumfeld ein Produkt herstellen zu können, was zur richtigen Zeit in der richtigen Weise den Kunden adressiert. Der Weg dahin ist nicht linear, sondern gespickt von Fehlentscheidungen. Die den agilen Methoden inhärente Flexibilität erlaubt die Kostenkontrolle darüber, indem sie die Möglichkeiten bieten, einmal identifizierte Fehlentwicklungen auch unmittelbar zu beenden und - mit viel Kreativität und hoher Geschwindigkeit - eine Neuausrichtung vorzunehmen.

Wird jedoch das Produkt in seiner aktuellen Ausprägung festgeschrieben und nur noch die Abarbeitung eines Umsetzungsplans erwartet, kann nur noch sehr viel Glück dazu führen, dass nicht das gesamte Vorhaben scheitert und die Investition verloren geht.

Dies weiß das agile Management der neuen IT-Organisation natürlich sehr genau und man sollte erwarten, dass es sich gegen den methodischen Strategiewandel massiv wehrt. Der Versuch wird auch fraglos unternommen, der Kampf geht meistens verloren. Woran liegt das?

Agile Organisationen verfügen in der Auseinandersetzung mit klassischen Konzernstrukturen über keine Abwehrmechanismen. Tritt der agile Manager in den Konflikt mit seinen Ansprechpartnern auf der Konzernseite - als Vertreter einer untergeordneten Tochtergesellschaft - so steht ihm nicht die Wahl der Waffen zu. Die Waffen sind diejenigen, die die Kultur des Konzerns vorschreibt.

Dies hat zur Folge, dass der agile Manager bei Anwendung der in seiner Organisation üblichen Konfliktlösungsansätzen grandios scheitert. Die Fehler, die er in der Eskalationssituation begeht, sind vielfältig:

• Zunächst nimmt er an, dass er und seine Gegenspieler dasselbe Ziel verfolgen. Dies ist aber mitnichten so: die monetären Steuerungsmechanismen und intern wettbewerbsorientierten Aufstiegspfade im Konzernumfeld prägen auf den mittleren und höheren Managementebenen häufig Charaktere aus, deren persönliche Weiterentwicklung in ihrem Konzernhabitat wichtiger ist als das Unternehmenswohl selbst. Dies heisst nicht, dass ein bewusster Wille bestände, Schaden zu erzeugen. Aber sollte der Erfolg der agilen Organisation die Position oder den persönlichen Karrierepfad des Konzernmanagers gefährden, so wird er sich - auch wieder besserer Argumente - gegen die agile Organisation aufstellen.
• Der agile Manager wird mit der Erwartung in die Deeskalation treten, dass alle in dem Kontext relevanten Themenfelder gemeinsam diskutiert werden. Dies ist dem Konzernmanager zuwider: er ist gewohnt seine Pfründe gegen Einflussnahme zu schützen und empfindet es als Schwäche, wenn man aus für ihn nicht nachvollziehbaren Gründen dies nicht tut. Eröffnet der agile Manager auch nur die kleinste Option zur äußeren Beeinflussung seiner eigenen Themen, so wird der Konzernmanager versuchen diese neue Wirkungssphäre dauerhaft zu für sich zu sichern und den agilen Manager mittel- bis langfristig zu verdrängen.
• Bei der Bewältigung der Eskalation wird der agile Manager mit Transparenz, offener Selbstreflektion und Fehlertoleranz auftreten. Dies ist ein gefundenes Fressen für den Konzernvertreter: Fehler seinerseits wird er niemals einräumen, sondern sie kaschieren und die Schuld anderen in die Schuhe schieben. Räumt der agile Manager einen Fehler seiner Organisation ein, so wird der Konzernmanager dies weidlich kommunikativ ausnutzen, um den agilen Kollegen zu schwächen und seine eigene Einflusssphäre zu erweitern.
• Anders als der agile Manager dies erwartet, besteht kein Teamzusammenhalt zwischen ihm und dem Konzernkollegen. Selbst wenn es gelingt, einvernehmliche Entscheidungen zu treffen, muss der agile Manager davon ausgehen, dass im Falle, dass sich diese als falsch erweisen, der Konzernkollege geübte Cover-your-ass-Strategien in der Hinterhand hat, um bei der Klärung der Schuldfrage seinen agilen Kollegen deutlich in ein schlechtes Licht zu rücken.

Auch wenn hier eine andere Anmutung aufkommen mag: ich halte den Konzernkollegen nicht für einen Bösewicht. Er bewegt sich schlicht nach den Spielregeln seines Kulturkreises, in dem er sozialisiert wurde. Und diese Spielregeln weichen fundamental von denen einer agilen Organisation ab.

Die Abweichungen sind leider dergestalt, dass in der direkten Auseinandersetzung der agil denkende Mensch das Nachsehen hat. Die Waffenungleichheit wird dadurch fundamental, dass der Konzernkollege mit seinem Handeln den Erwartungen der finalen Entscheidungsträger im Konzern entspricht, wohingegen die Herangehensweise des agilen Managers bestenfalls als zu methodenorientiert und schlimmstenfalls als esoterisch wahrgenommen wird.

Die Lösung für den agilen Manager besteht erfahrungsgemäß nicht in dem Versuch, einen Kulturkampf zu führen und den Konzern zu „agilisieren". Berater der agilen Szene betonen gerne, häufig und richtigerweise, dass das Management eines Unternehmens Agilität in allen Konsequenzen verstanden haben muss und idealerweise auch leben sollte, damit diese sich in den kreativen Teilorganisationen wirklich entfalten kann. Wie bereits beschrieben, sind diese Voraussetzungen jedoch in der Regel schlichtweg nicht gegeben. Wenn der agile Manager versucht, die aus Konzernsicht klare Sachdiskussion darum, warum Ziele hinsichtlich Zeit, Budget und Fachlichkeit nicht eingehalten werden auf einer kulturell-methodische Ebene zu führen, so erarbeitet er sich nur den Ruf eines wenig zielorientierten, esoterischen Spinners. Seine Demontage wird beschleunigt und der agilen Organisation in der Notlage nicht geholfen.

Wie gelingt es also der agilen Organisation, sich selbst zu schützen? Paradoxerweise nur dadurch, dass das agile Management die Bereitschaft mit sich bringt, an den Schnittstellen zum Konzern ihre eigenen Ideale zu verraten. Darüber hinaus ist hinreichende Erfahrung vonnöten, um sich in der Auseinandersetzung mit dem Konzernmanagement kulturell an die Gegenspieler anzupassen und wenn nötig ihre Mittel zu adaptieren und gegen sie zu richten. Erforderlich ist eine moralische Kaltblütigkeit, wie sie auch immer wieder in politischen Kontexten gefragt ist: inwieweit folge ich meinen eigenen Grundsätzen wenn ich gefordert bin das System, an das ich glaube, zu verteidigen?

Dieser Anforderung an das agile Management zu genügen ist wahnsinnig schwer. Menschen, die Agilität mit der Muttermilch aufgesogen haben, sind tendenziell ungeeignet. Ihnen fällt nicht nur die moralische schizophrene Positionierung schwer - ihnen fehlt auch in der Regel die nötige Erfahrung im Umgang mit ihren kulturell fremden Gegenspielern. Besser geeignet erscheinen Menschen, die aus einem klassischen Konzernumfeld kommen und die Klaviatur der konzernpolitischen Auseinandersetzung beherrschen. Gleichzeitig müssen sie aber erfahren in agilen Managementmethoden sein, die sie in ihrer eigenen Organisation aus wahrer Überzeugung leben können.

Mit der Etablierung von solchen, wehrhaften Charakteren an den Schnittstellen zu nicht-agilen Organisationsbestandteilen gelingt es dann auch womöglich, dem Scheitern agiler Substrukturen in Konzernorganisationen etwas von seinem deterministischen Charakter zu nehmen.

Der Mechanismus des Scheiterns folgt seinen eigenen Regeln. Mit diesen muss man umzugehen wissen.