Delegation und Eigenverantwortung in der Praxis

Agilität setzt auf Selbstorganisation, Eigenverantwortung und Delegation von Entscheidungen an die Stelle, wo das beste fachliche Wissen vorhanden ist. Das klingt erstrebenswert und einfach. Wenn man Teams die Entscheidungsbefugnis und Verantwortung selbst überlässt, sollten diese sie doch mit Freude und großem Nutzen für die Unternehmung annehmen. Eigentlich. Die praktische Umsetzung weist aber doch einige Tücken auf. Eigenverantwortung bedeutet nämlich nicht nur selbst entscheiden zu können, sondern auch, tatsächlich die Verantwortung für die Umsetzung einer Entscheidung zu übernehmen oder die Entscheidung mit anderen gemeinsam erarbeiten zu müssen.

Von der eigenverantwortlichen Blockade und Resignation

Typischerweise treffen Teams ihre Entscheidungen nicht im luftleeren Raum. Meistens gibt es Auswirkungen auf andere Bereiche oder Teams. Das folgende, problematische Muster ist mir dabei häufiger begegnet:

Team A möchte für eine spezielle Aufgabe, dass Team B etwas Bestimmtes tut. Also spricht Team A mit Team B um dies anzufragen. Team B möchte aber – aus unterschiedlichsten Gründen – das Angefragte nicht tun und antwortet entsprechend an Team A. Eventuell hakt Team A noch nach, aber wenn Team B stur bleibt, führt das aus der Eigenverantwortung. Team A wendet sich an eine Eskalationsinstanz E: typischerweise die erste übergeordnete Stufe in der Hierarchie, die sowohl Team A, als auch Team B (ggf. indirekt) führt. Es kann also auch mehrere Hierarchiestufen hinauf gehen und entsprechend Zeit kosten. Ist die Eskalation dorthin passiert, entscheidet typischerweise die Instanz E (sie fühlt sich ja dadurch wichtig und in ihrem Dasein bestärkt) und das war es dann mit der Eigenverantwortung. Das ist die Anfängervariante.

Fortgeschrittene Blockadeabteilungen haben sich so organisiert, dass sie noch ein Team C dazwischen schieben. Angenommen Team A  braucht wieder etwas von Team B. Wenn jetzt offiziell festgelegt ist, dass Team A dafür mit Team C sprechen muss (welches Team B vorgelagert ist – nennen wir es Single Point of Contact), hängt alles am Wohlwollen von Team B und Team C. Wenn nur eines von beiden nicht mag, wird es wieder schwierig für Team A. Insbesondere gibt es dann kaum noch eine Chance gemeinsam eine Lösung zu erarbeiten, da A mit C diskutieren muss, aber C gar nicht die Problemlösungskompetenz hat. Diese liegt bei B. Hier ist das Risiko noch höher, dass die Verantwortung an eine Eskalationsinstanz E abgegeben wird.

Erschwerend kommt hinzu: Je öfter Team A erlebt, wie die eigenen Wünsche und Anforderungen von anderen Abteilungen weggewischt werden, umso schneller wird es zukünftig aufgeben und resignieren.

Die nicht-nachhaltige Delegation

Wie schon angedeutet, nehmen die übergeordneten Führungskräfte eine solche Eskalation oft an – obwohl sie die Entscheidungsbefugnisse eigentlich in die Teams delegiert hatten. Sie wollen das Problem schnell lösen und fühlen sich eventuell bestätigt in ihrer Wichtigkeit für die Unternehmung. Nur bringt das der Unternehmung bei ihrer Entwicklung zu mehr eigenverantwortlichem Handeln leider nichts. Die Teams gewöhnen sich statt dessen daran in schwierigen Situationen die Verantwortung bequem wieder abgeben zu können. Die Führungsaufgabe in einem agilen Unternehmen ist es hier deshalb das Annehmen der Verantwortung zu unterstützen.

Agile Führung

Wie kann die Führungskraft die Teams dazu bringen ihre Verantwortung wahr zu nehmen? Sie sollte ernsthaft prüfen, ob sie die Eskalation zurückgeben kann. Indem sie klar macht, dass sie eine selbständige Einigung von Team A und B erwartet, kann sie ein allzu leichtfertiges Eskalationsverhalten aufbrechen. Um dem Nachdruck zu verleihen würde ich als Führungskraft ankündigen, dass ich die Entscheidung verbindlich und final treffen würde, sollten die Teams keine gemeinsam getragene Lösung finden und tatsächlich wieder eskalieren. Das bringt für beide Teams das unter Umständen hohe Risiko, dass ich völlig zu deren Ungunsten entscheide, wenn ich es für die sachlich richtige Entscheidung halte. Unter diesem Druck wird den Teams hoffentlich bewusst, dass sie eine Lösung finden sollten, die beide mittragen können. Der Zwang ist größer, ein gutes Ergebnis im größeren Kontext zu erreichen. Wenn ich das ein paar Male gemacht habe, gewöhnen sich die Teams hoffentlich daran, ihre Konflikte selbst zu lösen und zwar als von allen gemeinsam getragene Lösung. Das schärft auch deutlich das Denken zum Wohle der Unternehmung und nicht nur zum Wohle des eigenen Bereichs.

Konterkarierend wirken hier eventuell Zielvereinbarungen, die stark auf das Voranbringen des eigenen Teams gemünzt sind und damit im Widerspruch stehen zum Erfolg des Rests der Unternehmung. Diese sind auf jeden Fall hinderlich und werden eventuell Inhalt eines späteren Blogbeitrags werden.

 

 

Wenn du einen Rechtschreibfehler findest, benachrichtige mich bitte, indem du den Text auswählst und dann Strg + Eingabetaste drückst.

Diesen Beitrag teilen:

2 Gedanken zu „Delegation und Eigenverantwortung in der Praxis

  1. Wenn der Arbeitsorganisation auf dynamischen Teams setzt, werden solche Konflikte „automatisch“ und selbstorganisiert gelöst. Durch dynamischen Teams befindet sich die Wissensverteilung in einem relativen Balance, was dazu führt, dass Team A einfach die notwendige Feature(s) implementiert und als Merge/Pull-Request an Team B sendet. Team B freut sich, dass a) die Aufgabe ohne eigenen Aufwand erledigt ist und b) deren „Code-Ownership“-Gefühl (der bei hoch-motivierten und engagierten Mitarbeiter immer wieder entsteht) nicht verletzt ist, da sie weiter der letzte Entscheider sind. Dafür sind m.E. feste Regeln, wie unternehmensweiten Code Style Guide, Inspections, Tools etc. notwendig, damit sich jeder in jeglichem Kode ohne grossen Aufwand wiederfindet.

    1. Vielen Dank für diesen Kommentar!
      Das Gesagte kann ich so nur bestätigen und die im Artikel geschilderten Probleme sind in der Tat in einer Struktur mit festen Komponententeams aufgetreten. Dynamische Teams funktionieren in der beschriebenen Weise viel besser. Grenzen gibt es dann dort, wo Team A die Änderungen nicht mehr selbst vornehmen kann, weil von Team B beispielsweise eine Technologie verwendet wurde, zu der die Kompetenz in Team A fehlt. Dies führt dann wieder zurück auf die ebenfalls angesprochene Standardisierung.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert