On Lean and Agility

Vor einiger Zeit reifte in einer Behörde, deren IT-Projekte ich begleiten durfte, die Einsicht, dass die eigenen Prozesse zu starr und zu langwierig waren. Um dem zu begegnen wurde ein neues "Referat für den Abbau von Bürokratie" geschaffen, das dem entgegenwirken sollte. Seine erste Amtshandlung bestand darin, alle anderen Referate anzuweisen, alle ihre Arbeitsabläufe detailliert zu dokumentieren. Auf Basis dieser Dokumente sollte dann entschieden werden, wo Bürokratie abgebaut werden könnte.

Dieses widersinnige Vorhaben (das nicht zu weniger sondern zu mehr Verwaltungsaufwand führte) gehört zu einem Trend, den der Soziologie-Professor Stefan Kühl treffend als "Bürokratisierung der Entbürokratisierung" beschrieben hat. Hinter ihm verbergen sich die zunehmend verbreiteten Massnahmen, Bürokratieabbau, Digitalisierung, Effizienzzsteigerung und ähnliche Dinge dezidierten Organisationseinheiten zuzuordnen - und damit versehentlich alles nur noch schlimmer zu machen.

Diese Verschlimmerung ergibt sich aus verschiedenen, mit grosser Wahrscheinlichkeit eintretenden Dynamiken. Zunächst gibt es für die neue Zentraleinheit starke Anreize, Informierungs-, Beteiligungs- und sonstige Pflichten anzuordnen, wodurch es wie im Fall des oben genannten Bürokratieabbau-Referats dazu kommen kann, dass alleine der dadurch notwendige Kommunikationsaufwand zu der perversen Konsequenz führt, dass alles ineffizienter wird statt effizienter.

Wenn es darüber hinaus dazu kommt, dass nicht nur über die eigenen Prozesse berichtet werden muss, sondern Änderungen an ihnen zentral begutachtet und ggf sogar genehmigt werden müssen, wird die dafür zuständige Einheit zu einem verlangsamenden Flaschenhals für alle anderen. Schlimmstenfalls kann es dazu kommen, dass selbst dringende und von allen gewollte Änderungen lange verzögert werden, weil die für die Freigabe zuständigen Personen überlastet sind.

Als Folge dessen kann es sogar zu nochmals weiteren Verschlechterungen kommen: um eine eigene Überlastung zu verhindern oder abzubauen neigen viele Zentraleinheiten dazu, der restlichen Organisation einheitliche Vorgehensmodelle oder Berichtsformate vorgeben zu wollen, um deren Lage einfacher verstehen und vergleichen zu können. Diese Vereinheitlichung kann oft nur auf Kosten der optimalen Bedienung der lokalen Bedürfnisse erreicht werden.

Gleichzeitig entstehen demotivierende Auswirkungen für die dezentralen Einheiten. Wenn plötzlich alle eigenen Verbesserungsbemühungen zu Dokumentations- und Kommunikationsmehraufwand führen und darüber hinaus befürchtet werden muss, dass von aussen gut gemeinte Verschmlimmbesserungen stattfinden, dann ist das ein Anreiz, solche Bemühungen gar nicht mehr (oder nur lokal, unangekündigt, unabgestimmt und intransparent) durchzuführen.

Zuletzt stehen Bürokratieabbau-Einheiten aufgrund der mit ihnen verbundenen Erwartungen und Aufwände unter hohem Erfolgsdruck, der (vor allem dann wenn die Erfolge Voraussetzung für Gehalts-, Karriere- und Statusverbesserungen sind) dazu führen kann, dass Fortschritte aufgebauscht und voreilig oder wahrheitswidrig verkündet werden, mit der Folge, dass vordergründig Verbesserungen stattzufinden scheinen, während in Wahrheit Verspätung, Stillstand und Verschlechterungen vorherrschen.

Die Zuordnung von Bürokratieabbau, Digitalisierung, Effizienzzsteigerung, etc. zu dezidierten Organisationseinheiten ist aus all diesen Gründen mit dem hohen Risiko verbunden, das Gegenteil des Angestrebten zu erreichen. Ein wesentlich besserer Weg kann es sein, dezentrale Freiräume für Verbesserungsbemühungen (incl. Zeit und Budget) zu schaffen, alleine verbunden mit der Bedingung einer transparenten Durchführung, um auf versehentliche Fehlentwicklungen hinweisen zu können.

Und um Missverständnissen vorzubeugen - Referate die den Abbau von Bürokratie bürokratisieren gibt es nicht nur in der staatlichen Verwaltung, sondern auch in der freien Wirtschaft. Sie tragen dort nur andere Namen, z.B. Prozessmanagement, Inhouse Consulting, Betriebsorganisation oder Agiles Transitionsteam.

Nachtrag 24.04.2025:

Stefan Kühl hat seine Gedanken zur Bürokratisierung der Entbürokratisierung im Sozialtheoristen-Blog präzisiert.

Bild: Pexels / Yan Krukau - Lizenz

Das Silicon Valley - Speerspitze des Fortschritts, Verkörperung technischer Disruptionen, Geburtsstätte bahnbrechender Innovationen und immerwährender Kreativität. Sich durch die Übernahme eines dort angesiedelten Startups in diese Wunderwelt einzukaufen erscheint den Managern vieler deutscher Konzerne und Mittelständler eine gute Idee zu sein, in der Realität enden diese Zukäufe allerdings meistens in Enttäuschungen. Und dass es immer wieder so kommt ist kein Zufall.

Um es vorwegzunehmen: was jetzt folgt ist anekdotische Evidenz. Ich habe einige dieser gescheiterten Silicon Valley-Expansionen selbst miterlebt, bei einigen weiteren kenne ich Menschen die dabei waren. In Summe lediglich eine niedrige zweistellige Zahl von Fällen, also Nichts was wissenschaftliche oder statistische Validität hätte. Da aber bestimmte Probleme immer wieder aufgetreten sind, glaube ich, dass es hier erkennbare (und prognostizierbare) Muster gibt.

Um mit dem Folgenschwersten (und auf den ersten Blick unglaublichsten) zu beginnen - die meisten deutschen Unternehmen sind sehr schlecht im Gestalten und Befolgen von Prozessen. Das kann bedeuten, dass es selbst für zentrale Geschäftsvorgänge keine klare Definition gibt (v.a. im Mittelstand anzutreffen), oder dass in Konzernen alles so überreguliert ist, dass die Mitarbeiter gezwungen sind, sich auf informelle Prozesse zurückzuziehen, um überhaupt arbeitsfähig zu sein (→ brauchbare Illegalität).¹

In beiden Fällen ist das Ergebnis, dass neue Mitarbeiter die inoffiziellen, aber für das Funktionieren der Firma elementaren Prozesse erst nach und nach herausfinden müssen, da diese lediglich im kollektiven Gedächtnis festgehalten sind. In Folge dessen dauert es entsprechend lange bis sie wirklich arbeitsfähig sind - sechs bis zwölf Monate sind in grossen Unternehmen nicht ungewöhnlich. Da in Deutschland viele Angestellte jahrzehntelang in ihrer Firma bleiben, ist das aber ein eher geringes Problem.

Im Silicon Valley findet man gleichzeitig ein Muster, das mit dem zuvor genannten komplett inkompatibel ist - die meisten Angestellten bleiben weniger als zwei Jahre bei einem Arbeitgeber, viele wechseln sogar mehrmals im Jahr. Das langsame Aufbauen von Wissen über die inoffiziellen Prozesse ist daher nicht möglich, weshalb die offiziellen möglichst minimalistisch gehalten, dafür aber strikt durchgesetzt und neuen Mitarbeitern durch starke und umsetzungsnah agierende Manager vermittelt werden.

Übernimmt jetzt ein deutsches Unternehmen ein Silicon Valley-Startup, kommt es mit hoher Wahrscheinlichkeit zu einem Culture Clash: in der (unbewussten) Erwartung, dass sich die Mitarbeiter die (inoffiziellen) Prozesse mit der Zeit selbst aneignen werden, wird von den deutschen Managern ein weniger strikter Führungsstil eingeführt. Der ständig wechselnden Belegschaft fehlen damit sowohl die schnelle Einweisung in die offiziellen, als auch das langsame Erlernen der inoffiziellen Prozesse.

Die unvermeidbare Folge eines derartigen Zusammenpralls so unterschiedlicher und inkompatibler Unternehmenskulturen ist ein erstaunlich schnelles Zusammenbrechen von Abläufen und Strukturen. Innerhalb von ein bis zwei Jahren sind kaum noch Kollegen da, die Erfahrung damit haben, die Prozesse am Laufen zu halten, stattdessen sind die meisten erst seit einigen Monaten an Bord, wurden nie richtig eingearbeitet und sind dadurch nur eingeschränkt zu effektivem Arbeiten in der Lage.

Diesem rapiden Verfall des intellektuellen Kapitals folgt meistens ein genauso schneller Einbruch der Produktqualität. Marktforschung, Product Discovery, technische Exzellenz und Qualitätssicherungs-Routinen sind mit den sich auflösenden Strukturen und Prozessen nur noch eingeschränkt durchführbar, Bugs und technische Schulden häufen sich an, die Umsetzungsgeschwindigkeit sinkt und mit ihr die Wettbewerbsfähigkeit und die Marktanteile. Irgendwann kann man alles nur noch abwickeln.

Selbst wenn diese Abläufe immer wieder zu beobachten sind, sind sie natürlich kein Naturgesetz. Sind die zugrundeliegenden Muster einmal erkannt, kann man gegensteuern und eine Silicon Valley-Tochtergesellschaft auch von Deutschland aus gut führen. Voraussetzung dafür ist allerdings, sich die Unzulänglichkeit oder Lückenhaftigkeit der meisten offiziellen Prozesse einzugestehen und ihre Unbrauchbarkeit in einer Umgebung mit hoher Personalfluktuation zu erkennen. Eine hohe Hürde.

Bild: Unsplash / Annie Spratt - Lizenz

Zu den Grundüberzeugungen aller agilen Frameworks gehört, dass Entwicklungsteams nach Möglichkeit Crossfunktional sein sollten, also in der Lage, alle im Rahmen der Produktentwicklung nötigen Tätigkeiten selbst durchzuführen, ohne dabei von anderen Abhängig zu sein. In traditionell arbeitenden Unternehmen dominieren dagegen die Spezialistenteams, die nur eine bestimmte Spezialtätigkeit beherrschen, die aber besonders effizient.

Am Anfang von agilen Transitionen stehen daher häufig Reorganisationen, in denen die Spezialistenteams aufgelöst und ihre Mitglieder auf die neuen, crossfunktionalen Teams verteilt werden. Wenn es in solchen Situationen aber mehr dieser neuen Teams gibt als bisher Spezialisten, treten Probleme auf. In den einen Teams feht das Spezialistenwissen, sie sind also doch wieder von anderen abhängig. Die anderen Teams müssen wiederum die erste Gruppe unterstützen, was zu Defocussierung und Prioritätskonflikten führt.

Um das zu vermeiden ist es sinnvoll, die Auflösung der Spezialistenteams nicht von jetzt auf gleich durchzuführen, sondern im Rahmen eines langsamen Prozesses, während dem immer mehr Wissen und Zuständigkeiten in die Breite verlagert werden. Wie das im Einzelnen geschehen kann wird natürlich von Fall zu Fall unterschiedlich sein, es gibt allerdings einen Denkansatz, mit dessen Hilfe sich der Übergang strukturiert durchführen lässt: Team Topologies.

Team Topologies geht von vier grundlegenden Team-Typen aus: Stream-aligned Teams (crossfunktional, können alles selbst), Enabling Teams (befähigen andere Teams), Complicated Subsystem Teams (besondere Spezialistenteams, deren Tätigkeit sich nicht so einfach aufteilen lässt) und Platform Teams (stellen anderen Teams Produkte oder Dienstleistungen zur Verfügung, die diese ohne externe Unterstützung sich selbst beschaffen und benutzen können). Mehr dazu hier.

Da spezialisierte Teams in Team Topologies den Complicated Subsystem Teams entsprechen sind diese der Ausgangspunkt, von dem aus zwei Weiterentwicklungen möglich sind: entweder sie können ihr Spezialgebiet zu einer Plattformdienstleistung umwandeln, die von den anderen Teams in einem Selbstbedienungs-Modus genutzt werden kann, oder sie wandeln sich zu enabling Teams indem sie das, was sie bisher selbst gemacht haben, anderen beibringen.

Häufige Anwendungsfälle für die Weiterentwicklung in Richtung Platform Team sind Spezialisten-Einheiten, von denen bisher Werkzeuge, Daten oder Infrastruktur verantwortet wurden. Die können in Selbstbedienungs-Portale überführt werden, in denen man sich Entwicklungsumgebungen, Testdaten, Anleitungen, Nutzungs-Simulationen o.ä. konfigurieren kann, die dann automatisiert erstellt und zur Verfügung gestellt werden.

Alternativ kann das bisherige Spezialisten-Team seine bisher verantworteten Themen direkt an die neuen, crossfunktionalen Teams weitergeben, allerdings mit einer wichtigen Ergänzung - statt diese mit ihrer neuen Aufgabe alleinzulassen, stehen die bisherigen Spezialisten als Trainer, Ratgeber, Erklärer und Notfallhelfer zur Verfügung, und das so lange bis sichergesetellt ist, dass ihre Unterstützung nicht mehr benötigt wird und sie sich neue Aufgaben suchen können.

In beiden Fällen (Umwandlung in ein Platform Team und Umwandlung in ein Enabling Team) kann es schliesslich zu einer finalen Entwicklungsstufe kommen, in der sich die ursprüngliche Spezialisteneinheit zwar auflöst, als "virtuelles Team" aber erhalten bleibt. Das kann z.B. in Form einer Community of Practice stattfinden, in der (ggf wechselnde) Vertreter aller crossfunktionalen Teams gemeinsam eine Platform-Dienstleistung oder einen Wissenstransfer am Leben halten.

Bild: Flickr / Queensland State Archives - Public Domain

Die Klagen über zu viel Bürokratie kennt man aus nahezu jeder grösseren Organisation, egal ob in der freien Wirtschaft, in der staatlichen Verwaltung oder bei Nichtregierungsorganisationen. Erstaunlich ist dabei aber in fast allen Fällen, dass es sich um eher unspezifische Beschwerden handelt - meistens werden nur zu viele Prozesse und Vorschriften genannt, ohne die genauer zu beschreiben. Dabei ist es durchaus möglich, diese aufzuschlüsseln, um sie deutlich klarer erkennen und ggf. beseitigen zu können.

Wichtig ist dabei, dass die offiziellen Kategorien nur eingeschränkt hilfreich sind, da es sich bei ihnen oft um Sammelbegriffe für verschiedene vorgeschriebene Tätigkeiten handelt. So kann sich z.B. hinter einer Sorgfaltspflicht oder einer Nachweispflicht alles Mögliche verbergen, mit je nach Einzelfall deutlich unterschiedlichen Auswirkungen. Eine differenzierte Betrachtung macht daher Sinn, und mit ihr kommt man zu dieser (sicherlich unvollständigen) Liste bürokratiefördernder Vorgaben:

Durchführungspflichten

Hier geht es darum, wer was zu tun hat und in welcher Reihenfolge der Arbeitsschritte. Das kann abstrakt sein, wie bei der Vorgabe eines Vier-Augen-Prinzips, aber auch komplizierte vorgegebene Abläufe umfassen, z.B. bei der Wartung einer Maschine.

Informierungspflichten

Aufbauend auf den Durchführungspflichten geht es als nächstes darum, andere über das was man selbst getan hat (oder vorhat) in Kenntnis zu setzen. Detailgrad und Empfänger können dabei je nach Fall unterschiedlich sein, wichtig ist, dass irgendjemand informiert worden ist.

Begründungspflichten

Bereits etwas einengender. Es reicht nicht mehr, zu berichten, was man getan hat oder vorhat, es muss auch klar werden, aus welcher Motivation heraus das geschieht, mit welchem Ziel oder auf wessen Anweisung. Eine häufige Erweiterung ist die Begründung für den Durchführungszeitpunkt.

Dokumentationspflichten

Die Formalisierung der Informierungspflichten. Der Kommunikationskanal zur Übermittlung der Informationen ist nicht mehr frei wählbar sondern vorgegeben, am häufigsten ist dabei die Vorgabe der Schriftform (ggf. verstärkt durch die Pflicht zur persönlichen Identifikation durch Unterschreiben).

Formatierungspflichten

In gewisser Weise die Formalisierung der Formalisierung. Es reicht nicht mehr, in irgendeiner Form die Informationen über die eigenen Handlungen zu übermitteln, auch die Struktur dieser Information wird jetzt vorgegeben, z.B. in Form einer Tabelle oder eines Formulars.

Nutzungspflichten

Die Vorgabe von Arbeitswerkzeugen. Das können physische Werkzeuge sein, digitale Werkzeuge aber auch bestimmte Räumlichkeiten, in denen Arbeit verrichtet werden muss. Eine noch immer erstaunlich häufige Extremform ist die an den hierarchischen Rang gekoppelte Vorgabe der Tintenfarbe.

Unterlassungspflichten

Das Spiegelbild der Nutzungspflichten. In einer restriktiven Variante ist alles zu unterlassen, was nicht explizit zur Nutzung vorgegeben ist, in einer offeneren Variante sind nur solche Handlungen zu unterlassen, die explizit verboten werden. Beides kann aber ggf. zu Handlungsunfähigkeit führen.

Anhörungspflichten

Beteiligungspflichten

Mit dieser Stufe ist das Mitwirken Anderer nicht mehr optional und auf die Meinungs- oder Bewertungsabgabe beschränkt, sondern verpflichtend und in die Arbeitsabläufe fest eingebunden, z.B. in Form einer Zulieferung oder Qualitätssicherung.

Kenntnisnahmepflichten

Das Gegenstück zu den Informierungspflichten. Wer auch immer Informiert wird darf das nicht einfach ignorieren, sondern ist verpflichtet, es selbstverantwortlich zur Kenntnis zu nehmen und von sich aus zu reagieren, wenn er angehört oder beteiligt werden will.

Überprüfungspflichten

Die Steigerung der Kenntnisnahmepflichten. Übermittelte Informationen müssen nicht nur zur Kenntnis genommen, sondern auf ihre Richtigkeit und ggf. Angemessenheit überprüft werden, einschliesslich einer Rückmeldung, wenn eines davon nicht gegeben sein sollte.

Genehmigungspflichten

Die Formalisierung und Generalisierung der Überprüfungspflichten. Übermittelte Informationen müssen nicht mehr nur zur Kenntnis genommen und ggf. überprüft werden, ohne eine auf dieser Überprüfung beruhende Freigabe darf der jeweilige Arbeitsvorgang nicht fortgesetzt werden.

Rechtfertigungspflichten

Spätestens an dieser Stelle wird es unangenehm. Wenn ein Überprüfungs- oder Genehmigungsprozess zu einem negativen Ergebnis führt, ist zu erklären, durch welche Fehler oder Nachlässigkeiten es überhaupt dazu kommen konnte.

Qualifizierungspflichten

Sowohl als Folge von Überprüfungs- oder Genehmigungsprozessen oder vorbeugend kann es sein, dass bestimmte Ausbildungen oder Schulungen verpflichtend vorgegeben werden, in der Regel vermunden mit der Pflicht zum Nachweis der Teilnahme oder des Bestehens einer Prüfung.

Weiterbildungspflichten

Die Verstetigung der Qualifizierungspflichten. Es reicht nicht mehr aus, Ausbildungen oder Schulungen einmal zu durchlaufen, es muss darüber hinaus in regelmässigen Abständen zu Wiederholungen, Auffrischungen, Erweiterungen oder Resensibilisierungen komen.

Stellenbesetzungspflichten

Eine Konsequenz aus den zuvor genannten Pflichten. Um ihre Erfüllung mit der nötigen Kapazität, Qualifikation und Aufgabenteilung durchführen zu können, sind Planstellen notwendig. Eigentlich nur ein Symptom der Bürokratisierung, selbst wenn es oft selbst für Bürokratie gehalten wird.

Wie oben gesagt, diese Auflistung ist sicher noch unvollständig, dass die Befolgung aller dieser Pflichten in erheblichem Ausmass zu Bürokratie im Sinn von formalisierter, nicht Mehrwert schöpfender Verwaltungsarbeit führen kann (und meistens auch führen muss), dürfte aber offensichtlich sein. Und trotzdem ist es so, dass sie alle in jeder grösseren Organisation anzutreffen sind (wenn auch in unterschiedlicher Ausprägung).

Dass das so ist, liegt daran, dass keine dieser Vorgaben komplett unsinnig ist, in jeder von ihnen wird man einen Kern von Sinnhaftgkeit finden können, schliesslich erfüllt Bürokratie durchaus einen Zweck. Es kann also kein Ziel sein, sie (oder die ihr zu Grunde liegenden Pflichten) komplett abzuschaffen. Stattdessen muss es darum gehen, die Bürokratie auf das sinnvolle Mindestmass zu beschränken - im Zweifel durch regelmässige Evaluierung und Justierung.

Und jetzt kommt es: um Evaluierung und Justierung durchführen zu können, sind wieder einige der oben genannten Pflichten notwendig, selbst wenn auch diese zwangsläufig bis zu einem gewissen Grad bürokratisch sein müssen Die finale Pointe lautet also - um Bürokratie zu bekämpfen, braucht man noch mehr Bürokratie.

Dieses Video von der Large Scale Scrum (LeSS)-Conference Madrid 2024 ist gleich auf mehreren Ebenen sehenswert. Zum einen weil der LeSS-Erfinder Craig Larman hier etwas sehr Sinnvolles tut: am Beispiel von Conway's Law zeigt er auf, wie sehr manche bahnbrechende wissenschaftliche Papers mit der Zeit aus ihrem Kontext gerissen und mit zusätzlicher Bedeutung aufgeladen werden, bis zu dem Punkt, an dem vieles, was sie in der Aussenwahrnehmung ausmacht, gar nicht mehr aus dem Original ableitbar ist.

Auf einer weiteres Enene kann man aus diesem Video aber auch erkennen, warum LeSS, das ja egentlich ein sehr schlankes und agiles Framework ist, mitunter in der agilen Community skeptisch gesehen wird. Sein Schöpfer ist offensichtlich sehr davon überzeugt, Recht zu haben und sehr schnell bereit, anderen vorzuwerfen, ahnungslos oder im Unrecht zu sein (in diesem Fall geht das u.a. gegen die Verfasser der Bücher Team Topologies und Dynamic Reteaming). Wird der eigene Standpunkt auf diese Art vermittelt, ist klar, warum das nicht überall auf Begeisterung stösst.

Es ist heute der Standard in jeder grösseren Organisation: alle geben sich (explizit oder implizit) Leitwerte wie Respekt, Augenhöhe, Fairness und Ähnliches. Das ist auch erstmal gut so, die Frage, die sich viele Betrachter dabei stellen, ist aber, ob das wirklich ernst gemeint ist oder nur der Aussendarstellung dient. Glücklicherweise gibt es eine einfache Möglichkeit, das herauszufinden - man muss sich nur anschauem, wie dort externe Mitarbeiter behandelt werden.

Zum gemeinsamen Verständnis: unter externen Mitarbeitern versteht man Menschen, die nicht in der Organisation für die sie arbeiten direkt angestellt sind. Stattdessen handelt es sich um Mitarbeiter externer Personaldienstleister und Zeitarbeits-Firmen, kooperierender Zulieferer oder eingebetteter Fremdfirmen für Kantine, Hausmeisterdienste, etc. In einigen Berufen, wie z.B. Pflegedienstleistungen oder Softwareentwicklung, kommen dazu noch zahlreiche solo-selbstständige Freelancer.

Dass diese externen Kollegen nicht komplett gleich behandelt werden können wie die internen ist auch klar, bei Leistungen wie z.B. einem Zuschuss zu einer Betriebsrente wäre das alleine aus juristischen Gründen nicht möglich. Und seit einigen Jahren muss eine erkennbar andere Behandlung erkennbar sein, wenn man verhindern will, dass externe Freelancer plötzlich als nur scheinselbstständig gelten. Was in vielen Firmen passiert ist mit diesen Gründen aber nicht zu rechtfertigen.

Um nur einige Beispiele zu nennen, die sich jetzt im Augenblick in Deutschland zutragen: eine Behörde verlangt von Bewerbern um externe Positionen die schriftliche Versicherung, sich nirgendwo sonst zu bewerben, schaut sich selbst aber in aller Ruhe verschiedene Kandidaten an. Ein Dax-Konzern verlangt von potentiellen externen Mitarbeitern, auf eigene Kosten quer durch Deutschland zu Vorstellungs-Interviews zu reisen, ein anderer teilt danach Absagen nur auf Nachfrage mit.

Ein IT-Systemhaus einer Behörde verlangt zwei Wochen unbezahlte Einarbeitung, da die Externen in dieser Zeit ja "noch keinen Mehrwert liefern", eine Bankengruppe verlangt das Gleiche, bevor ein auslaufender Vertrag verlängert wird. Bei einem Automobil-Hersteller werden die Büros, in denen die Externen sitzen, deutlich seltener renoviert und repariert als die der Internen, und fast überall sind die Kantinenpreise für externe Kollegen deutlich erhöht, zum Teil um das Doppelte.

Und das ist nur das was offiziell verlangt und kommuniziert wird, inoffiziell kommt noch mehr dazu. Es ist eine weitverbreitete Praxis, von externen Kollegen unbezahlte Überstunden zu verlangen, gerade in schlecht bezahlten Berufen, und wenn man weiss, dass diejenigen auf das Einkommen angewiesen sind. In Medien-Redaktionen wird von den so genannten "Festen Freien" oft verlangt, dass sie durchgehend in Warteräumen verfügbar sein müssen, wenn sie die Chance haben wollen, beauftragt zu werden.

Anstrengende, monotone oder Stress erzeugende Arbeiten werden in vielen Agenturen bevorzugt an externe Kollegen weitergereicht, bei Ergebnis-Präsentationen dürfen sie oft nicht mit auf die Bühne, sie werden bevorzugt in die Teams cholerischer und inkompetenter Vorgesetzter geschickt, und wenn die Budgets für ihre Einsätze gekürzt werden, erfahren sie es als letzte, damit sie durch die Hoffnung auf Verlängerung bis zum Schluss überdurchschnittlichen Einsatz zeigen.

Um auch das zu sagen: in vielen Firmen finden derartige Missstände nicht statt, und es gibt sogar einige, die die externen Mitarbeiter besser behandeln als die internen. Trotzdem sind die gerade genannten Phänomene weitverbreitet, wie zuvor gesagt handelt es sich bei jedem der genannten Beispiele für die schlechte Behandlung von Externen um solche, die gerade jetzt in verschiedenen Unternehmen und Behörden in Deutschland stattfinden und weiter stattfinden werden.

Dass all das mit Respekt, Augenhöhe und Fairness nichts zu tun hat, ist offensichtlich, stattdessen werden externe Kollegen in solchen Firmen als Menschen zweiter Klasse behandelt, und das in den meisten Fällen mit einer erstaunlichen Offenheit und mit einem bemerkenswert geringen Schuld- oder Unrechtsbewusstsein. "Das sind ja nur die Externen", heisst es häufig, "die sind ja eh bald wieder weg", oder der Klassiker: "Wenn es denen nicht gefällt, können sie ja gehen."

Was dabei oft nicht erkannt wird ist, dass diese Verhaltensweisen aber auch in der eigenen Belegschaft spürbare Folgen haben. Dass ein derartiger Umgang mit anderen Menschen toleriert oder sogar normalisiert wird trägt früher oder später zu einer toxischen Arbeitskultur bei, die dazu führt, dass die eigenen (fest angestellten) Mitarbeiter entweder verrohen und abstumpfen oder angewidert in die innere oder äussere Kündigung gehen.

Und dass die schönen an der Wand hängenden und in Management-Reden zitierten Leitwerte ernst gemeint sein könnten glaubt in solchen Firmen niemand, womit die Unternehmenskultur nochmals beschädigt wird. Die Betonung dieser Werte wird dort als paradoxe Kommunikation wahrgenommen und führt nicht nur dazu, dass ihnen nicht geglaubt wird, sondern auch dazu, dass jedem der sie einfordert Unaufrichtigkeit und Doppel-Standards unterstellt werden.

Wer hier schon länger mitliest weiss es - ich habe am Anfang meiner Karriere in einer Behörde gearbeitet, in der ich nicht nur viele der bekannten und beklagten Dysfunktionen erleben musste, sondern in der auch vieles einfacher, flexibler und effizienter organisiert war als in vielen Unternehmen, in denen ich später gearbeitet habe. Ein Werkzeug das ich dort kennengelernt habe benutze ich sogar bis heute (wenn auch meistens unter anderem Namen): den dreiteilen Vermerk.

Zum Hintergrund: mein Referat hatte relativ wenige gleichbleibende Regeltätigkeiten und war stattdessen an vielen Projekten, Arbeitsgruppen, Veranstaltungen und weiteren sehr unterschiedlichen Aufgaben beteiligt. Sowohl in der internen Kommunikation als auch in der Zusammenarbeit mit anderen Behörden, externen Partnern und höheren Hierarchieebenen war es daher immer wieder nötig, neue Themen und komplexe Zusammenhänge schriftlich zu kommunizieren.

Die Dokumente mit denen in der öffentlichen Verwaltung normalerweise Kommunikationen stattfanden, hiessen im Behördendeutsch "Vermerk", aber trotz ihrer zentralen Bedeutung für die Informationsverteilung gab es für sie kein standardisiertes Format. Je nachdem von welcher Person oder in welcher Organisationseinheit sie verfasst waren konnten sie lang sein oder kurz, strukturiert oder unübersichtlich, prägnant oder ausschweifend.

Das in meinem Umfeld meistens genutzte Format war das bereits Erwähnte. Der Vermerk bestand dabei in der Regel aus drei Teilen, die immer in der gleichen Reihenfolge angeordnet waren und die inhaltlich aufeinander aufbauten:

1. Worum geht es?
2. Was ist bisher passiert?
3. Was ist als nächstes zu tun?

Gegebenenfalls folgten danach noch weiterführende Informationen, ein freizugebendes Dokument, ein Entwurf eines Rede-Manuskripts oder irgendeine andere Mehrwert stiftende Anlage.

Um auf die drei Hauptbestandteile einzugehen: alleine der erste Teil war bereits wichtiger als man denken könnte. Angesichts vieler verschiedener Themen und ständiger Kontextwechsel konnte nicht davon ausgegangen werden, dass jeder, der in einen Termin eingeladen oder um eine Entscheidung gebeten wurde, sofort alle Ziele, Handlungsbedarfe und Hintergründe parat hatte. In Worum geht es? wurden diese daher möglichst komprimiert auf maximal einer Seite zusammengefasst.¹

Der zweite Teil, Was ist bisher passiert?, sollte verhindern, dass Diskussionen immer wieder von vorne begannen, oder dass Sachstände oder bereits abgeschlossene Aktivitäten redundant oder aufwändig zusammengetragen werden mussten. Im Idealfall enthielt er alle bereits beschlossenen Schritte oder Massnahmen, eine Übersicht darüber, welche bereits angegangen worden waren und ggf. welche davon bereits mit welchem Ergebnis beendet worden waren. Auch das idealerweise auf maximal einer Seite.

Der dritten Teil, Was ist als nächstes zu tun?, diente schliesslich dem Zweck, die anstehende Diskussion oder Entscheidung möglichst effizient zu gestalten. Im einfachsten Fall enthielt er mehrere Entscheidungs-Optionen, von denen nur noch eine gewählt werden musste, es konnten aber auch zu priorisierende Themen sein, Budget-Freigaben oder einfach die Agenda für das kommende Meeting, so dass jeder sich auf die Themen vorbereiten konnte.

Ähnlich wie z.B. die "Press Releases" von Amazon, die ich viel später kennengelernt habe, sind die dreiteiligen Vermerke eine einfache, komprimierte und klar strukturierte Art um komplizierte oder komplexe Themen verständlich aufzubereiten und effiziente Diskussions- und Entscheidungsprozesse zu befördern. Sie auf insgesamt nur ein bis zwei Seiten zu beschränken ist nicht immer einfach, kann aber dabei helfen, sich viele Ineffizienzen und redundante Diskussionen zu ersparen.

Ich habe bereits in verschiedenen Unternehmen mit diesem Format gearbeitet und es auch anderen empfohlen, wenn auch immer mit einer Einschränkung - es sollte nicht kategorisch vorgeschrieben werden, sondern nur da benutzt werden wo es Sinn macht. Auch in der Behörde in der ich es kennen gelernt habe, haben wir bei Bedarf andere Formate genutzt, wenn diese besser gepasst haben. Uns war bewusst, dass alles andere nur zu Bürokratie geführt hätte.

Bild: Pexels / Yan Krukau - Lizenz

Ein Hoch auf die Wissenschaft! Diesesmal sind es Arbeits- und Organisationspsychologen der Universität Halle, die eine verbreitete Annahme überprüft haben, so dass man diese jetzt auf der Basis valider Empirie vertreten kann. Die Rede ist von End-to-End-Verantwortung, oder "Vollständiger Tätigkeit", wie sie hier genannt wird, und von den Auswirkungen, die diese Art von ganzheitlicher Beschäftigung mit einem Thema auf Menschen haben kann.

Das Konstrukt der „vollständigen Tätigkeit“ als Ziel guter Arbeitsgestaltung heisst der Forschungsbericht, der auf Basis von 800 Betrachtungen und Interviews entstanden ist, durchgeführt mit Menschen unterschiedlichster Berufsgruppen. In dieser Forschung wurde überprüft, welche so genannten Beanspruchungsfolgen (vereinfacht gesagt Auswirkungen auf die Psyche) unterschiedliche Ausmasse der Verantwortung über die eigene Tätigkeit haben (siehe auch hier).

Ein erstes Ergebnis ist, dass "unvollständige Tätigkeiten", die jeweils nur einen Teil einer Wertschöpfung umfassen, eher zu negativen als zu positiven Beanspruchungsfolgen führen. Da in diesem Vorgehen zahlreiche Abhängigkeiten zu anderen Gruppen bestehen, empfand die Mehrheit der untersuchten Personen ständigen Zeitdruck, der Versuch allen Abhängigkeiten gerecht zu werden führte ausserdem zu ständigen Kontextwechseln und Unterbrechungen. Insgesamt entstanden Ineffektivität und Ineffizienz.

Umgekehrt führten "vollständige Tätigkeiten", die grosse Teil der Wertschöpfung umfassen, eher zu positiven als zu negativen Beanspruchungsfolgen. Das in diesem Vorgehen mögliche eigenständige Zielsetzen, Planen und Kontrollieren führte bei der Mehrheit der untersuchten Personen zu mehr Engagement, Zufriedenheit und Commitment, was sich in Form von gesteigerter Kreativität und Effizienz auch auf die Arbeitsleistung auswirkte.

Eine wichtige Differenzierung ergab sich dabei durch das Ausmass der kognitiven Beanspruchung, die durch die jeweiligen Anforderungen des End-to-End-verantwortlichen Arbeitens entstand. Wurde dieses als zu hoch empfunden, konnte es auch bei "vollständigen Tätigkeiten" zu eher negativen als positiven Beanspruchungsfolgen kommen, da dann erneut negative Treiber wie Zeitdruck und Stress auftreten können (zwar aus anderen Gründen, aber mit den selben Folgen).

Übertragen auf die Gestaltung beruflicher Stellen bedeutet dass, dass sich diese idealerweise in der Mitte eines Spannungsfeldes zwischen möglichst umfassender Verantwortung und noch bewältigbarer kognitiver Belastung befinden sollten (wobei diese "Mitte" in den meisten Fällen eher ein beweglicher als ein fixer Punkt sein dürfte). "Agile Praktiken" wie das Pull-Prinzip, Inspect & Adapt und das Automatisieren repetitiver Tätigkeiten könnten bei dieser Gestaltung wesentliche Erfolgsfaktoren sein.

Bild: Freerangestock / Rawpixel - License

Wenn sich Unternehmen einmal darauf eingelassen haben, ihren Mitarbeitern Coaches zur Seite zu stellen, kommt es immer wieder in der Folgezeit zu Ausdifferenzierungen dieser Rolle. In der Regel durch ein Präfix gekennzeichnet, entwickeln sich "Spezialisten-Coaches" für bestimmte Themengebiete, vom Quality Coach über den DevOps Coach bis zum Leadership Coach kann alles Mögliche dabei sein. Das ist auch erstmal ok, wie so oft kann man bei näherer Betrachtung aber Erstaunliches erkennen.

Viele der verschiedenen ausdifferenzierten Coach-Rollen werden weniger aufgrund von Nachfrage, Unternehmensstrategie oder sonstigen übergreifenden Notwendigkeiten und Zielen definiert, sondern aufgrund eines ganz anderen Kriteriums: der Organisationsstruktur. Sie werden innerhalb der vorhandenen Bereiche oder Abteilungen aufgebaut, deren Themengebiet dadurch auch zu ihrem Coaching-Gebiet wird. Zum Beispiel ist der Quality Coach in der Regel Teil einer Quality Assurance-Einheit.

Das ist zunächst einmal weder gut noch schlecht, und auch nicht ungewöhnlich. Die Tendenz, dass Organisationen ihre Organisationsstruktur auf alles mögliche übertragen ist so verbreitet, dass dieses Phänomen sogar als "Gesetzmässigkeit" formuliert wurde, Conways Law. Ihm zufolge ist diese Übertragung sogar zwangläufig und findet praktisch jedes mal statt, wenn neue Systeme (vor allem technischer, aber auch sozialer Art) erschaffen werden.

Was diese "Gesetzmässigkeit" problematisch macht, ist, dass eine anhand der Organisationsstruktur vorgemommene Aufteilung nicht immer den gegebenen Notwendigkeiten entspricht, und ihnen mitunter sogar zuwiederläuft. Statt zusammengehörende Aspekte gemeinsam zu betrachten und basierend darauf zu entscheiden, welcher von ihnen den grössten Handlungsbedarf (bzw. in diesem Fall Coaching-Bedarf) hat, verengt sich der (Coaching-)Fokus unverhältnismässig stark auf einen Teilbereich.

Wer solche Konstellationen erlebt hat, wird es vermutlich kennen: der Product Coach hilft den Product Ownern bei Roadmaps und Kunden-Interaktionen, lenkt die Aufmerksamkeit seiner Coachees aber selten auf technische Probleme. Der Agile Coach dringt auf regelmässige Auslieferung, selbst wenn der Release-Zyklus durch eine jährliche Leitmesse vorgegeben ist, der QA Coach fördert durch seine ausschliessliche Arbeit mit den Testern unbewusst deren Separierung von den Entwicklern, etc. etc.

Wird diese Entwicklung erkannt, ist es ein häufiger Reflex, alle Coaches in zentralen Einheiten, oft "Coach Pool" genannt, zusammenzuziehen, die z.B. in HR oder Change Management verortet sind. Das scheint zunächst sinnvoll, da Gesamtsicht und Gesamtzuständigkeit entstehen, kann aber auch wieder in Conway's Law enden, da die jetzt übergeordnete zentrale Einheit ebenfalls Partikularinteressen hat, die den übergreifenden Unternehmenszielen ggf. nicht entsprechen.¹

Ebenfalls zu beachten ist, dass es auch sinnvolle Erwägungen gibt, die dazu führen, dass Conway's Law auch bei der Definition spezialisierter Coaching-Rollen stattfindet. In Fach- oder Spezialisten-Abteilungen verortete Coaches können bei ihrer Ausbildung und Weiterentwicklung von der hier vorhandenen Expertise profitieren, die in einer zentralen, organisationsübergreifenden Einheit naturgemäss nur schwach ausgeprägt sein kann.

Aus meiner Erfahrung ist ein anderer Weg besser: die "Spezialisten-Coaches" verbleiben zwar zum Zweck des Expertise-Aufbaus in ihren ursprünglichen Einheiten, sie bilden aber organisationsübergreifend eine Querschnittsorganisation, in der Einsatzplanung, Austausch, Abstimmung und das Setzen von gemeinsamen Standards stattfinden können, mit dem Ziel, dass trotz Spezialisierung eine Einheits-übergreifende Sicht auf die Gesamtorganisation und ihre Bedürfnisse und Notwendigkeiten möglich ist.

Wichtig dabei: wir sprechen immer noch von ausdifferenzierten Rollen, wie Quality Coach, DevOps Coach, etc. Bei Team Coaches mit fester Teambindung kann eine stärkere lokale Verankerung Sinn machen, das wäre aber nochmal ein eigenes Thema.

Wir alle kennen den für agile Teams anzustrebenden Idealzustand: crossfunktional, d.h. in der Lage, alle notwendigen Tätigkeiten selbst auszuüben, und selbstorganisiert, d.h. in der Lage, selbst darüber entscheiden zu können, welche dieser Tätigkeiten wann durchgeführt wird. In der Realität gibt es aber immer wieder Sachzwänge wirtschaftlicher oder regulatorischer Art, die diesen Idealzustand einschränken. Das macht Kommunikation und Koordination mit anderen Teams nötig.

Je nachdem wie (un)hierarchisch eine Organisation aufgestellt ist, kann die Gestaltung dieser Kommunikationsströme unterschiedliche Formen annehmen. Der klassische Weg ist dabei der durch das Management. Ein Team-, Abteilungs- oder Projektleiter sammelt die zu besprechenden Themen in seiner Einheit ein, trifft sich mit seinem Gegenpart aus der anderen Einheit, der dort vorher das Gleiche gemacht hat, bespricht alles mit ihm und bringt die Ergebnisse zurück zu seinen Leuten.

Eine solche Lösung ist zwar naheliegend, allerdings aus verschiedenen Gründen problematisch. Entscheidungskompetenz und Umsetzungsexpertise werden entkoppelt, diese Art der Informationsübermittlung dauert relativ lange, durch die verschiedenen Kommunikations-Stationen entsteht das Risiko von Stille Post-Effekten und es kann sich (ggf. unbeabsichtigt) beim Management Herrschaftswissen herausbilden.

Der häufig propagierte "agile Gegenentwurf" ist die Netzwerk-Organisation. Hierarchien kann es zwar auch hier noch geben, die Kommunikationsströme richten sich aber nicht mehr an ihnen aus. Stattdessen kann jeder Einzelne mit jedem Anderen (sowohl Personen als auch Gruppen) Kontakt aufnehmen und anstehende Themen besprechen und Klären. Gegebenenfalls können dabei auch direkte Kommunikationen zwischen unterschiedlichen Hierarchie-Ebenen zustande kommen.

Auch diese Lösung ist aber nicht unproblematisch. Es besteht das Risiko, dass die Kommunikation zerfasert und unübersichtlich wird, mit der Folge, dass entweder Redundanzen entstehen (die im schlimmsten Fall zu verschiedenen, ggf. inkompatiblen Lösungen für das selbe Problem führen), oder dass ein unverhältnismässig hoher Aufwand investiert werden muss, um für jeden nachvollziebar zu machen, wer gerade mit wem über welches Thema spricht.

Ein Versuch, einen Mittelweg zwischen diesen beiden Extremen zu finden, kommt von James Coplien, einem der unbekannteren Pioniere der agilen Software-Entwicklung (unter anderem hat er das Daily Scrum/Daily Standup erfunden). In seinem Ansatz der Scale Free Organisation ergänzt er die Netzwerk-Organisation um Personen, die Informationsknotenpunkte, die so genannten Hubs, bilden, welche die zu kommunizierenden Informationen konsolidieren, bzw. verteilen.

Der Unterschied zu dem Management-zentrierten Ansatz ist, dass es sich bei diesen die Informationen konsolidierenden, bzw. verteilenden Personen nicht um Manager oder sonstige Funktionsträger handelt, sondern lediglich um Menschen, die aufgrund ihrer Kommunikativität, ihrer Versetzungshistorie, ihrer Bereitschaft Wissen zu teilen oder sonstiger Faktoren (z.B. der Mitgliedschaft im Betriebssportverein) überdurchschnittlich viele andere Menschen kennen und bei Bedarf Kontakt zu ihnen herstellen können.

Ebenfalls im Unterschied zum Management-zentrierten Ansatz erfolgt die Herausbildung von Hubs selbstorganisiert, emergent und ggf. temporär. Mit anderen Worten: da kommunikative und/oder gut vernetzte Personen mit höherer Wahrscheinlichkeit angesprochen werden oder an Abstimmungs-Meetings (z.B. einem Scrum of Scrums) teilnehmen werden als andere, verstärkt sich ihr Hub-Status selbst. Fallen Hubs aus (z.B. durch Versetzung) entsteht durch die gleichen Mechanismen ein Ersatz.

Bedingt durch diese Selbstorganisations- und Kompensationsmechanismen (die Coplien in 200 von ihm untersuchten Unternehmen identifizieren konnte) sind Organisationen, deren Kommunikation über derartige Hubs läuft, mit einer hohen Effektivität, Flexibilität und Resilienz ausgestattet, da in ihnen direkte Verbindungen immer da entstehen wo sie gerade gebraucht werden, ohne dass sie sich durch Regulierung oder Normierung verfestigen.

Bild: Gottscho-Schleisner / Library of Congress - Public Domain

Eine der Nachrichten, die in letzter Zeit für Aufmerksamkeit gesorgt haben, ist der bevorstehende Stellenabbau bei Bayer. Nicht nur wegen der verlorenen Arbeitsplätze, sondern auch wegen einer in diesem Zusammenhang veröffentlichten Zahl: 17.000 von 100.000 Mitarbeitern arbeiten dort im Management, also fast jeder fünfte. Mehrfach habe ich die Frage gehört, wie das denn sein kann, die Zahl wirkt auf den ersten Eindruck unglaublich hoch. Versuchen wir es mit einer Erklärung.

Da ich die internen Strukturen bei Bayer nicht kenne, starten wir mit Vergleichswerten, die ich in verschiedenen anderen Firmen erlebt habe. Auf der untersten Ebene gehen wir dabei von Teams, Gruppen oder Referaten von ca. 10 Mitarbeitern aus, einer häufig anzutreffende Grösse. Unterstellen wir, dass jede dieser Einheiten einen eigenen Team-, Gruppen oder Referatsleiter hat, kommen wir damit auf ein Manager/Mitarbeiter-Verhältnis von 1 zu 10.

Auf der nächsthöheren Ebene gehen wir davon aus, dass jeweils fünf der untersten Einheiten eine Abteilung bilden, jeweils fünf Abteilungen einen Bereich, und so weiter, bis hinauf zu den Ressorts und Landesgesellschaften. Jede dieser Einheiten hat einen Leiter, und nicht nur das, ab einer bestimmten Grösse kommen Stellvertreter und Stabsstellen dazu. Alle diese Positionen zählen wir auch zum Management, und gehen dadurch grob von einem Manager/Mitarbeiter-Verhältnis von 1 zu 9 aus.

Dieses Verhältnis dürfte vor allem dort anzutreffen sein, wo es um gleichbleibende Regeltätigkeiten geht, z.B. in der Fertigung oder einem Callcenter. In der Wissens- oder Innovationsarbeit ist es aber meistens komplizierter, dort wird normalerweise in Projekten gearbeitet. Diese Projekte bilden dabei eine eigene, zu den Teams, Abteilungen, etc. parallele Organisation, die sich die Mitarbeiter von den gerade genannten Einheiten leiht, zu deren Koordination aber eigene Manager hat.

Gehen wir auch hier zuerst von der Grösse von 10 Mitarbeitern aus, die zu einem gemeinsamen Teilprojekt gehören.¹ Und nehmen wir an, dass fünf Teilprojekte ein Projekt bilden und fünf Projekte ein Programm. Wenn wir jetzt noch davon ausgehen, dass wiederum jede dieser Einheiten einen Teilprojekt-, Projekt- oder Programmleiter hat (und die Linienmanager einbeziehen), kommen wir in den projektartig arbeitenden Teilen der Organisation auf ein Manager/Mitarbeiter-Verhältnis von 1 zu 5 oder 1 zu 4.

Auch hier kommen aber nochmal zusätzliche Management-Positionen dazu, zum einen erneut die Stellvertreter und Stabsstellen, ausserdem aber noch die Project Management Offices (PMO), in denen sich bemerkenswerte Mengen von Menschen mit Planungen, Schätzungen, Anträgen, Genehmigungen oder Kommunikation beschäftigen können. Dazu kommen funktionale Stellen wie z.B. Qualitäts-Manager, Rollout-Manager, Compliance-Manager, etc.

Am Ende kann durch diese doppelte Management-Hierarchie in Linien- und Projektorganisation in den projektartig arbeitenden Teilen der Firma sogar ein Manager/Mitarbeiter-Verhältnis von 1 zu 3 möglich sein (!). Verrechnen wir das mit den weniger Management-lastigen Regeltätigkeits-Einheiten, ist im Gesamtdurchschnitt ein Verhältnis möglich, dass etwa dem entspricht, von dem bei Bayer berichtet wurde, etwa 1 zu 5. Diese Zahl kann also stimmen.²

Spätestens jetzt stellt sich die Frage, was all diese Manager eigentlich machen. Wenn wir die zahlenmässig kleine Gruppe der strategisch lenkenden Topmanager ausklammern, lautet die Antwort, dass sie vor allem kommunizieren und koordinieren. Kommuniziert werden Ziele (incl. deren Herunterbrechung) und Ergebnisse (incl. deren Zusammenfassung), koordiniert werden Abhängigkeiten, v.a. fachlicher und technischer Natur, aber auch die zu anderen planenden, freigebenden oder budgetierenden Einheiten.

Wichtig für das Verständnis ist dabei, dass es in der Regel ein Systemdesign gibt, dass diese Tätigkeiten tatsächlich zu Vollzeitjobs macht. Häufige Faktoren sind z.B. hohe Spezialisierungen und knappe Budgets, wodurch Mitarbeiter nur in Teilzeit in die Projekte entsandt werden können, was zu permanenten Ziel-, Termin- und Loyalitätskonflikten führt, deren Auflösung und deren zu kommunizierende Konsequenzen bei Linien- und Projektmanagern erhebliche Daueraufwände verursachen.

Daraus ergibt sich auch, was zu tun ist, wenn man das Verhältnis von Managern zu Mitarbeitern verringern will. Zum einen müssen die unteren Einheiten crossfunktionaler und durch breitere Skillprofile in Vollzeit besetzbar werden, so dass die Zahl der zu koordinierenden Abhängigkeiten abnimmt,³ zum anderen müssen diese Einheiten mehr Entscheidungskompetenzen bekommen, wodurch es nicht mehr nötig ist, ihnen ihre Aufgaben aus übergreifenden Zielen abzuleiten (das können sie dann selbst).

In einem solchen Setting kommt eine Organisation auch mit deutlich weniger Managern aus, wobei allerdings zu beachten ist, dass eine Delegation von Verantwortung nach unten ohne Begleitung und Befähigung schnell in Überforderung enden kann (die so genannte Autonomiefalle). Um diese zu vermeiden müssen die verbleibenden Manager verstärkt die Rolle von Beratern und Coaches annehmen, um so die neuen, crossfunktional-autonomen Teams in Richtung Selbstmanagement zu entwickeln.

Genau das ist laut dem oben verlinkten Artikel auch das Zielbild der organisatorischen Veränderungen bei Bayer. Wir können gespannt sein ob das erfolgreich sein wird oder nicht, vielleicht wird es ja in einigen Monaten oder Jahren neue Berichte in den Medien geben, aus denen sich das Ausmass der Erfolge ablesen lassen wird.

Zu den Konzepten auf denen ich mittlerweile schon einige Zeit herumdenke, gehört Explore, Expand, Extract vom Extreme Programming-Erfinder Kent Beck (siehe hier und hier). Ähnlich wie bei der Idee des Methodenwechsels im Projektlebenszyklus geht er davon aus, dass unterschiedlichen Rahmenbedingungen nicht mit einem immer gleichen methodischen Ansatz begegnet werden sollte, sondern dass auch das Vorgehen an die jeweiligen Bedürfnisse angepasst werden sollte.

Was mich an dieser Idee beschäftigt hat ist, dass die Situation vieler Produkte (bzw. Produkt-Teams) bei unseren Kunden in keine der drei Kategorien so richtig hineingepasst hat, vermutlich weil deutsche Konzerne sich nun mal deutlich vom Silicon Valley unterscheiden (Beck entwickelte sein Konzept während seiner Zeit bei Facebook). Um es auch hier anwenden zu können habe ich es daher erweitert, so dass es jetzt vier statt Kategorien hat: Explore, Expand, Extract und Exploit.

Explore

Exploration ist etwas, was in deutschen Konzernen selten stattfindet, in Startups aber ständig. Wieder und wieder werden neue Features entworfen, als MVP mit möglichst geringem Aufwand umgesetzt und an die Kunden/Benutzer ausgeliefert. Werden die Neuerungen von denen ignoriert oder abgelehnt werden sie schnell entsorgt, werden sie gut angenommen bleiben sie im Produkt und durchlaufen dann idealerweise ein Refactoring, um besser betreibbar und erweiterbar zu werden.

Expand

Während die meisten der so implementierten Features ein solides aber beherrschbares Wachstum hinlegen, gibt es einige, deren Nutzung für eine kurze Zeit explosionsartig zunimmt. In dieser so genannten Expansion-Phase müssen unter Hochdruck Infrastruktur und Verarbeitungskapazität erweitert werden, um zu verhindern, dass Performance-Probleme und Ausfälle die gerade herbeiströmenden Kunden/Benutzer wieder vertreiben. Für Beck die einzige Phase in der Überstunden Sinn machen.

Extract

Sobald dieses explosionsartige Wachstum vorbei ist, folgt die Extraction-Phase. Nachdem in Expansion-Phasen zur schnellen Erweiterung von Infrastruktur und Verarbeitungskapazität ggf. auch redundante oder überdimensionierte Lösungen bewusst in Kauf genommen werden können, können diese während der Extraction durch Vereinheitlichung oder Ressourcen-Optimierung zurückgebaut oder billiger gemacht werden (ich kenne dafür aus meinen Kunden-Einsätzen auch den Begriff "Cost Down").

Exploit

Apropos Kunden-Einsätze: in ihnen habe ich die erwähnte vierte Dimension erlebt, die ich in Fortführung der mit "Ex-" beginnenden Namen die Exploitation-Phase nenne. In ihr sind Explore, Expand und Extract bereits abgeschlossen (z.T. bereits seit langem) und die Features befinden sich im Cash Cow-Modus. Das heisst, dass sie bereits etabliert und kostenoptimiert sind und jetzt mit möglichst geringen Investitionen erhalten und betrieben werden, um möglichst lange profitabel sein zu können.

Selbst wenn man sich im Organisations- und Prozessdesign grundsätzlich vor Patentrezepten hüten sollte, kann man diese vier Kategorien jetzt nutzen, um ihnen naheliegende Methodiken und Erfolgskriterien zuzuordnen. In Expand könnte das Lean Startup mit der Metrik MVPs pro Monat sein, In Expand ein Task Force-Modus mit dem Ziel möglichst geringer Down-Times oder kurzer Mean Time to Recovery, in Extract kann in Iterationen gearbeitet werden, die Einspareffekte zum Ziel haben, und in Exploit können Kanban-Systeme Sinn machen, die auf die Optimierung von Ressourcen-Effizienz ausgelegt sind.

Unabhängig davon, ob am Ende diese oder andere Ausgestaltungen entstehen, der zentrale Punkt im Explore, Expand, Extract, Exploit-Modell ist der, dass in jeder der vier Kategorien andere Ansätze Sinn machen und daher nicht versucht werden sollte, in allen mit dem immer gleichen Vorgehen zu arbeiten. Und wenn dann auch noch erkannt wird, dass viele Vorhaben sich zwischen den Kategorien hin- und herbewegen, ist die Chance gross, für fast jede Herausforderung das passende Organisationsmodell finden zu können.

Bild: Wikimedia Commons / Alien Property Custodian - Public Domain

Ein Begriff an dem man immer wieder vorbeikommt, wenn es darum geht, ein (negatives) Gegenstück zur agilen Produktentwicklung zu finden, ist die so genannte Feature Factory. Genauer erklärt wird er allerdings nur selten, und wenn, dann meistens nur mit Assoziationen zu Akkordarbeit und starren Kontrollstrukturen. Dabei steckt durchaus mehr dahinter, wenn man es sich näher anschaut. Starten wir damit in einer weit zurückliegenden Vergangenheit.

Im frühen 20. Jahrhundert sind die meisten industriellen Betriebe noch wie Manufakturen organisiert. Es gibt zwar bereits erste berufliche Spezialisierungen und Befehlsketten, die eigentliche Arbeit wird aber noch von Hand durchgeführt, in der Regel von mittelgrossen, crossfunktionalen Teams, die ihre Produkte (Kameras, Autos, Plattenspieler, etc.) Stück für Stück vollständig erstellen, was oft eher den Charakter von Einzelanfertigungen als von Serienfertigung hat.

Diese Serienfertigung kommt erst zu dieser Zeit auf, ihre Erfindung wird vor allem mit den Industriellen Frederick Winslow Taylor und Henry Ford verbunden. Sie sorgen dafür, dass die Arbeit auf hoch-spezialisierte Teams übergeht, die jeweils nur noch wenige, immer gleiche Handgriffe an nur einer Station einer motorisierten Fertigungskette (dem Fliessband) vornehmen. Dass daraus am Ende ein Produkt entsteht, wird durch das Management sichergestellt, das die Fertigungskette entwirft und überwacht.

Erst durch diese hochspezialisierte und teilautomatisierte Serien-, bzw. Fliessband-Fertigung werden Produkte so billig, dass sie mit Erfolg auf dem Massenmarkt verkauft werden können, was dazu führt, dass diese Methoden nach und nach von allen Firmen übernommen werden (bzw. dass die, die sich nicht darauf umstellen, vom Markt verdrängt werden). Zuerst geschieht das in den Fabriken, später aber auch in anderen Bereichen, z.B. in Grossküchen, grossen Büros oder in Call Centern.

Besonders die letzte Entwicklung ist dabei von Bedeutung: nach und nach werden im zwanzigsten Jahrhundert fast alle Wirtschaftszweige nach den Ideen von Winslow und Ford umgeformt, bis irgendwann der Eindruck entsteht, dass sie überall anwendbar und zielführend sind. Dass das dann irgendwann auf Fälle treffen muss, in denen das eben nicht der Fall ist, ist naheliegend. Und damit kommen wir zu einer dieser Ausnahmen, der Softwareentwicklung.

Auf den ersten Blick kann man auch in der Softwareentwicklung eine Art Fertigungskette für neue Funktionen (eben die Feature Factory) aufbauen. Am Anfang steht das Anforderungsmanagement, dann das Anwendungsdesign, dann das Schreiben des Code, die Integration der einzelnen Komponenten, die Qualitätssicherung und schliesslich die Auslieferung. Es scheint nahezuliegen, dafür sequenziell angeordnete Spezialistenteams aufzubauen. Das Problem bei diesem Vorgehen: man bekommt am Ende zwar Ergebnisse, aber leider nicht die, die man gebraucht hätte.

Bedingt dadurch, dass man Software per Copy & Paste vervielfältigen kann, kommt es bei ihrer Erstellung nie zu einer wirklichen Serienfertigung, stattdessen wird lediglich ein Einzelstück nach dem anderen erstellt und das dann gleichzeitig an alle Nutzer ausgeliefert. Da diese Einzelstücke aber jeweils individuell anders sind, müsste die "Software-Fertigungsstrasse" eigentlich jedes mal neu konzipiert werden, da sonst die spezialisierten Einzeltätigkeiten nicht sauber ineinandergreifen.

Das allerdings ist kaum realisierbar, alleine wegen des damit verbundenen Umgewöhnungs-Aufwands der jeweiligen Spezialisten. Die sinnvolle Lösung wäre daher eine Rückkehr zum Manufaktur-Prinzip. Crossfunktionale Teams mit relativ geringer Spezialisierung erstellen ein Software-Produkt nach dem anderen und passen ihre Abläufe dabei jedes einzelne mal so an, dass sie für die in diesem Fall vorhabdenen Erfordernisse passend sind. So weit, so (scheinbar) einfach.

In der Realität wird die eigentlich gut nachvollziehbare Tatsache, dass Softwareentwicklung sich nicht wie eine Fabrik organisieren lässt, von vielen Managern und Unternehmensberatern bis heute bestritten. Sei es wegen fehlendem IT-Bezug, aus Methodismus (das klappt doch überall, also auch hier) oder aus welchem Grund auch immer - wieder und wieder trifft man vor allem in grösseren Firmen auf Fälle, in denen Entwicklungsabteilungen oder -ressorts als Feature Factories organisiert sind.

Praktisch immer führt das zu einer von zwei Dysfunktionen: entweder ist die "Fertigungsstrasse" nicht so optimiert, wie es im jeweiligen Einzelfall nötig wäre, was zu Ineffizienz und Fehleranfälligkeit des Prozesses führt, oder das Design der neu zu bauenden Funktionen wird an den vorhandenen Erstellungsprozess angepasst - im Zweifel auf Kosten der Marktbedürfnisse, was geringere Akzeptanz beim Kunden und geringeren wirtschaftlichen Erfolg zur Folge hat.

Diese Entwicklungen sind der tatsächliche Grund dafür, dass in der Softwareentwicklung Feature Factories hoch problematisch und anti-agil (im Sinne von einschränkend für Geschwindigkeit und Flexibilität) sind. Und selbst wenn man es nie schaffen wird, jeden zu überzeugen - ein besseres Argument als die Ablehnung von gefühlter Akkordarbeit und starren Kontrollstrukturen sind sie auch.

Manchmal hilft es, Dinge mit einem gewissen Abstand zu betrachten. In diesem Sinn wirft die britische Zeitung The Guardian gerade einen Blick zurück auf die Regierungszeit der ehemaligen Premierministerin Liz Truss, die nur 49 Tage dauerte. Eine der interessanteren Diagnosen aus diesem Text ist, dass Truss unter anderem deshalb scheiterte, weil sie durch zu viele Stellen-Neubesetzungen das institutionelle Gedächtnis der eigenen Verwaltung zerstörte. Was hat es damit auf sich?

Das institutionelle Gedächtnis ist eine Unter- und Sonderform des kollektiven Gedächtnisses und bezeichnet das gesammelte Wissen und die Summe der Erfahrungen einer organisierten Gruppe von Menschen, insbesondere in einer formalisierten Institution wie z. B. einer Behörde oder Firma. Es ist vor allem im Zusammenhang mit informellen Strukturen und Prozessen wichtig, also solchen, die nicht offiziell festgelegt und schriftlich festgehalten wurden.

Zu den typischen Informationen aus dem institutionellen Gedächtnis gehört, welche Inhalte wo abgelegt sind, welche Vorhaben in der Vergangenheit unternommen wurden (und wie), welche Mitarbeiter mit welchen anderen bekannt und vernetzt sind, wer bereits mit welchem Themengebiet zu tun hatte und wer besser oder schlechter mit bestimmten Rahmenbedingungen klarkommt (z.B. mit Stress, nicht-muttersprachlicher Kommunikation oder besonders hoher, bzw. niedriger Formalisierung).

Dieses Wissen kann für das Funktionieren einer Organisation entscheidend sein, da seine Träger in der Lage sind zu erkennen, an welcher Stelle welche Vorhaben mit geringen Reibungsverlusten umgesetzt werden können und an welchen Stellen mit Missverständnissen, Zusatzaufwänden, Ineffektivität oder Widerständen zu rechnen wäre. Wichtig dabei ist, dass bei einer rein formalen Betrachtung diese Unterschiede nicht wahrnehmbar wären, da sie sich nur aus der "Organisationsgeschichte" ergeben.

Vor allem nach Management- oder Regierungswechseln kann ein fehlendes institutionelles Gedächtnis von neuen Mitarbeitern dazu führen, dass die Ideen der neuen Führungsebene nur unter grossen Schwierigkeiten umgesetzt werden können, weshalb fast immer versucht wird, einen Teil der bisherigen Mitarbeiter zu übernehmen und einzubinden, selbst dann wenn man sich deren Loyalität nicht vollkommen sicher sein kann (ein bekanntes und besonders kontoverses Beispiel wäre dieses hier).

Für das, was passieren kann, wenn man nach einem Management-Wechsel versucht weitgehend ohne die bisherigen Mitarbeiter (und damit auch ohne deren nicht-verschriftlichtes Wissen) zu arbeiten, kann die zu Beginn erwähnte kurze Regierungszeit von Liz Truss als (abschreckendes) Beispiel gelten: dem von ihr mitgebrachten neue Regierungsteam fehlte das institutionelles Gedächtnis in einem derartigen Ausmass, dass es in vielen Bereichen handlungsunfähig war.

An overwhelming number of the senior figures brought into the administration had limited experience running a Whitehall department, let alone the country. The entire legislative affairs team – in charge of drafting and timetabling bills – was replaced too. “It was like she’d stripped off all the wallpaper, then the paint and floorboards too. There was basically zero institutional memory left,” one Truss-era cabinet minister said.

The Guardian, The inside story of the unravelling of Liz Truss’s premiership

Wie immer gilt natürlich auch hier, dass es nicht nur einen Weg gibt, mit derartigen Situationen umzugehen. Statt Teile des bisherigen Teams zu übernehmen kann man z.B. auch Mitarbeiter-Interviews, Unterlagen-Recherche und andere Arten der "Geschichtsforschung" durchführen um ein neues institutionelles Gedächtnis aufzubauen. Wenn das geplant ist sollte man allerdings ausreichend Zeit einplanen und nicht erwarten sofort uneingeschränkt handlungsfähig zu sein.

Bild: Flickr / Oregon State University - CC BY-SA 2.0

Unter den gedanklichen Konstrukten, die ich aus der Politikwissenschaft in meinen Beruf übernommen habe, ist die Verflechtungsfalle einer meiner Favoriten. Sie beschreibt die Situation in der sich überschneidende Verantwortlichkeiten zu einer Koordinations-, Kooperations- und Kontrollbürokratie führen, die alles lähmt, die aber auch einen derartigen Komplexitätsgrad hat, dass sie nur mit erheblichen Aufwänden wieder auflösbar ist. Fast alle grossen Organisationen sitzen in dieser Falle.

In welcher Form sie auftritt kann von Fall zu Fall unterschiedlich sein, es gibt aber einen grossen, immer wieder anzutreffenden Klassiker: eine Matrix-Organisation, die einer auf dem Anforderungsmanagement basierenden Budgetplanung unterliegt. Eine derartige Struktur ist ein fast sicherer Garantiefaktor für das Zuschnappen der Verflechtungsfalle - und bemerkenswerterweise ist sie trotzdem die Grundlage für das Organisationsdesign vieler Grossunternehmen.

Wie sieht das in der Realität aus? Zunächst so, dass die Verantwortung für einzelnen Programme, Projekt- oder Produktteams aufgeteilt wird. Häufig ist eine Trennung in Personal- und Produktverantwortung, auch die lassen sich aber nochmal unterteilen. Die Produktverantwortung lässt sich z.B. trennen in Entwicklung und Betrieb, der Personalverantwortung in Disziplinarisch und Fachlich. Es wirken also zwei, drei, vier (oder noch mehr) Manager gleichzeitig auf die Menschen der Umsetzungs-Ebene ein.

Das verkompliziert sich nochmal dadurch, dass die Gruppen, auf die die jeweiligen Manager einwirken, sich nur zum Teil überschneiden. So sind z.B. die Projektleiter für ihre jeweiligen Projekte zuständig, die Abteilungsleiter für jeweils eine über alle Projekte verteilte Gruppe von Spezialisten (etwa die Frontend-Entwickler) und die Architekten dafür, dass diese Menschen sich in bestimmten Themenfeldern (etwa bei der Weiterentwicklung des Intranets) an bestimmte system- und projektübergreifende Standards halten.

Alleine das wäre schon ausreichend, um für regelmässige Abstimmungsprobleme zu sorgen, aber jetzt kommt die Budgetierung dazu. In solchen Konstellationen verfügen in der Regel die Programm- oder Projektleiter über die Budgets. Diese nutzen sie um auf einem unternehmens-internen Markt von den Abteilungen jeweils die Spezialisten einzukaufen, mit denen die gerade anliegenden Anforderungen umgesetzt werden können. Und nur damit werden diese dann beauftragt.

Die anderen Manager bringt das in ein Problem. Die Ziele der Personalentwicklung (z.B. alle lernen regelmässig neue Programmiersprachen) oder der Architektur (z.B. alle Anwendungen bestehen aus Self Contained Systems) können den Zielen der Produktentwicklung widersprechen, da sie die Umsetzung von Anforderungen temporär oder dauerhaft verlangsamen würden. Da aber an der Produktentwicklung das Budget hängt, droht allen anderen Zielen permanent das Schicksal "wegpriorisiert" zu werden.

Um diesem Schicksal zu entgehen, wird oft versucht, auf einem anderem Weg als über das Budget Einfluss auf die Produktentwicklung zu nehmen. Es gibt beispielsweise Organisationen, in denen Architekten unternehmensweit geltende Entwicklungsvorschriften machen können, deren Einhaltung in einer Qualitätssicherungsphase überprüft wird. Und die Abteilungsleiter können ihre Ziele in die Jahresziele ihrer Untergebenen schreiben, wodurch die versuchen werden, sie irgendwie unterzubringen.

Die häufige Folge eines solchen Organisationsdesigns ist eine auf allen Ebenen ausgetragener ständiger Zielkonflikt, bestehend aus Verhandlungen, Eskalationen, verweigerten Freigaben, zurückgehaltenen Informationen, Kompromissen und Versuchen vollendete Tatsachen zu schaffen, wodurch sich alle Beteiligten gegenseitig behindern. Und wenn dann auch noch jeder Manager Teile seines Gehalts mit der Erreichung seiner Ziele verknüpft hat, wird er für ein solches Verhalten sogar noch belohnt.

Wenn es das Ziel einer Organisation ist, agile Produltentwicklung zu betreiben, ist das alles natürlich nicht zielführend. Wie man davon wegkommt hängt sehr von der Ausgangssituation ab, gute Ideen sind aber, Produkt- und Personalverantwortung zusammenzulegen, die Verfolgung gegenläufiger Ziele nicht zu belohnen (alleine das wäre ein Thema für sich) und die Budgetierung nicht mehr auf Anforderungen beruhen zu lassen sondern auf stabilen, produktorientierten Teams.

In fast allen Fällen sind das tiefgreifende Eingriffe in die bisherigen Strukturen und Abläufe, wodurch das unschöne Kriterium erfüllt wird, das aus einer Verflechtung die Verflechtungsfalle macht - man kommt nur schwer wieder heraus. Aber man kommt heraus, wenn man es darauf anlegt. Ganz nebenbei ist das auch ein guter Test um herauszufinden, wie ernst es mit der Agilität gemeint ist. Dort, wo es keine derartigen Anpassungen gibt, im Zweifel nicht so sehr.

Bild: Unsplash / Jud Mackrill - Lizenz

Dass es in einer Software entwickelnden Organisation schwierig ist, wenn nur eine Minderheit der Angestellten selbst in der Lage ist zur Software-Entwicklung beizutragen, dürfte nachvollziebar sein. Das Risiko ist in solchen Fällen gross, dass es zu Silo-Bildung, Prozess-Overhead und Arbeits-Rückstaus kommt. In grossen Organisationen ist diese Problemlage aber oft nicht ohne weiteres ersichtlich, so dass ihre Entdeckung oft überraschend wirkt.

Der Grund dafür ist die fehlende Einsicht der meisten Beteiligten in die tatsächlichen Mengenverteilungen. Damit ist weniger gemeint, dass keinem bewusst ist, wie wiele Entwickler im Unternehmen sind und wie gross ihr Anteil an der Gesamtbelegschaft ist, vielmehr geht es darum, dass nur den wenigsten Mitarbeitern ausserhalb der IT klar ist, wer (ausserhalb der eigenen Abteilung) sie regelmässig beauftragt, mit was und in welchem Umfang.

Irgendwo gibt es zwar eine Portfolio- und Aufwandsplanung, aus der man herleiten könnte, für wen alles intern Software entwickelt wird, meistens ist die aber nicht so einfach zugänglich, man sieht nur das was einen selbst betrifft. Und so lange Organisation so aufgebaut sind, dass IT und Fachabteilungen eigene organisatorische Einheiten sind (in der Regel nochmals mit einer auf Funktionen basierenden Aufteilungen in Untergruppen), wäre das Gewinnen eines Gesamtbildes auch relativ aufwändig.

Im Rahmen agiler Transformationen gibt es aber einen Punkt, an dem die Mengenverteilungen schlagartig offensichtlich werden, nämlich dann, wenn versucht wird, die Organisation auf Value Stream- oder Produktorientierung umzustellen. Im Rahmen einer solchen Umstellung werden in der Regel alle Fachspezialisten, Produkt- und Projektmanager, Kundenbetreuer, Marketing- und Vertriebsmitarbeiter und eben Softwareentwickler in einer Einheit oder einer Querschnittsorganisation zusammengefasst.

Dort wo ich derartige Umstellungen in Grossorganisationen erlebt habe, waren am Ende (je nach Produktschnitt) zwischen 10 und 30 Menschen in einer solchen Produkt- oder Value Stream-orientierten Einheit zusammengefasst. wovon (und jetzt kommt es) in fast allen Fällen weniger als 10 Prozent Software entwickeln konnten. Ich kann mich sogar an Fälle in verschiedenen Firmen erinnern, in denen es mehr Value Streams als Entwickler gegeben hat.

Je nach Einzelfall kann man zwar immer argumentieren, dass es immer auch eine Reihe von Nicht-Entwicklungstätigkeiten für das jeweilige Produkt braucht, Fälle wie die gerade genannten (von denen es in grossen Organisationen erstaunlich viele gibt) sind aber offensichtlich dysfunktional und erinnern völlig zu Recht an das Single worker digging hole-Meme. Und dass eine solche Situation nur in einem Nerven- und zeitfressenden Kampf um die knappen Kapazitäten enden kann, dürfte auch klar sein.

Anders als in vielen anderen Fällen ist in einer solchen Situation die Lösung auch realativ klar: man kann entweder die Umsetzungskapazität in der Software-Entwicklung ausbauen (Leute einstellen) oder den umgebenden Overhead abbauen (Leute entlassen oder versetzen). Und wenn man sich dazu nicht durchringen kann sollte man zumindest eines Allen klarmachen - wenn man irgendein Ergebnis nicht so schnell bekommt wie man es gerne hätte liegt das nicht daran, dass die IT so langsam ist, sondern dass die Dev/Non-Dev Ratio völlig unausgewogen ist.