Sind Sie ein Visionär oder ein Macher?

In den meisten Firmen, in den meisten Projektgruppen, in den meisten Genossenschafts- und Vereinsvorständen findet man zwei Fraktionen. Die eine, die ständig etwas verändern will, und die andere, die das Bestehende am Laufen halten möchte. Die eine hat den Blick auf Übermorgen gerichtet, die andere aufs Tagesgeschäft. Die eine will entwickeln, die anderen verwalten.

In der Unternehmenswelt werden diese beiden Haltungen so genannt: „Run-the-Bank“ und „Change-the-Bank“.

Die Friktion zwischen den beiden rührt daher, dass die Changer häufig Entscheide fällen, die die Runner dann ausbaden müssen. Oder dass die Changer kühne Ideen haben, aber sich nicht darum scheren, wie sie umgesetzt werden. Umgekehrt erleben die Changer die Runner oft als chronische Bremser und Nein-Sager, die sich an Säulen klammern, die bereits ins Wanken geraten sind. Changer geniessen meistens ein höheres Ansehen als Runner. Wer eine neue Art des Abwaschens vorschlägt, erhält erstmal mehr Beachtung, als derjenige, der den Abwasch täglich macht.

Es liegt auf der Hand, dass es beides braucht, jemanden, der Neues anstösst, und jemanden der es ausführt. Aber wie kann man die Spannung zwischen beiden Lagern aufheben?

Besonders in der Softwarebranche hat man darüber viel nachgedacht. Eine Lösung sind sogenannte DevOps-Teams. Der Begriff setzt sich zusammen aus Development (engl. Entwicklung) und Operations (engl. Betrieb). Wenn Entwickler und Betreiber zusammenarbeiten, so die Theorie, entsteht weniger Friktion und mehr Verständnis füreinander. Das Mantra der DevOps: «You build it, you run it», wenn du eine Idee hast, dann setze sie auch um, und halte sie am Laufen. Wer die Initiative ergreift, dem wird Kompetenz zugesprochen, aber er muss auch Verantwortung tragen. Noch genauer: Derjenige, der die Entscheidung trifft, sollte auch die Konsequenzen seiner Entscheidung erfahren.

Warum?

Beispiel: Wer beim Stadtlauf zu schnell loslegt, erfährt schnell die Konsequenz dieser Handlung. Man zahlt sofort den Preis für seinen Fehler, der Körper stellt ab. Daraus lernt man. Aber nicht nur für den nächsten Lauf. Man zieht allgemeine Schlüsse aus dieser Erfahrung, man versteht, dass das Leben ein Marathon ist und kein Sprint, dass man sich die Kräfte einteilen muss, dass Geduld wichtiger ist als Brillanz.

In grossen Unternehmen erfahren die Changer oft nicht mehr die Konsequenzen ihrer Entscheidungen, weil zwischen der Idee und der Ausführung viele Stockwerke und viele Monate liegen. Und je weiter wir uns von der Konsequenz unserer Entscheidungen entfernen, desto leichter können wir uns selbst einreden, dass wir recht haben. Auf der Mikroebene hingegen sehen und spüren wir die unmittelbaren Folgen.

Die DevOps versucht die Makro- mit der Mikrobene zusammenzudenken. Denn wenn Entwickler ihre eigenen Ideen auch ausführen müssen, entwickeln sie zwangsläufig ein besseres Verständnis für die Anforderungen und Bedürfnisse der Umsetzung. Umgekehrt erfahren die Runner, dass nicht jede Veränderung eine Bedrohung ist, dass etwas anders machen auch heissen kann, es besser zu machen.

DevOps bedeutet nicht, dass alle alles machen müssen. Es ist keine Absage an die Arbeitsaufteilung. Es heisst bloss, dass Veränderung und Ausführung zusammengehören, dass es keine Theorie ohne Praxis gibt, keinen Hersteller ohne Kunden. Das eine gibt es nicht ohne das andere.