Selbstorganisierte Teams, Verantwortung und Konsequenzen

Jun

Neulich hatten wir in der Firma eine interessante Diskussion über das Thema selbstorganisierter Teams und Verantwortung. Die Frage war, ob Verantwortung übernehmen für selbstorganisierte Teams heißt, dass sie für ihr Handeln automatisch auch die Konsequenzen tragen müssen. Im Zuge der Diskussion stellten wir fest, dass es im englischsprachigen Raum zwei sich überlappende Begriffe für das Wort „Verantwortung“ gibt: Resonsibility und Accountability. Einen interessanten Blogpost dazu gibt es hier:  http://matthiland.wordpress.com/2013/06/15/the-most-important-aspect-of-management/

Ich habe mal für mich versucht, responsibility und accountability zu übersetzen, um zu verstehen, was genau der Unterschied ist:

  • Responsibility: Verantwortung übernehmen
  • Accountability: Für etwas zur Verantwortung gezogen werden

Wenn das so ist, dann kommt die Responsibility freiwillig aus dem Team, während das Andere von außen auf das Team wirkt, z.B. wenn man einen Schuldigen sucht. Accountability wirkt wie eine konstante Drohung, bloss keinen Fehler zu machen, da man sonst mit Konsequenzen zu rechnen hat. So kann aber keine Kreativität und schon gar keine Eigenverantwortung erwachsen. Im Gegenteil: Accountability verhindert genau das. Wenn ich für einen Fehler direkt zur Verantwortung gezogen werden kann, lasse ich das lieber jemand anderes machen. Am liebsten einen Manager.

Wie in unserer Diskussion ganz richtig bemerkt wurde, gibt es in Teams verschiedene Rollen. Sei es Entwickler, oder Product Owner etc. Jeder übernimmt in diesen Rollen Verantwortung für das, was er tut, und auch für die anderen Teammitglieder. Was ich nicht glaube ist, dass eine Rolle von einer anderen accountable gemacht werden kann, denn das bedeutet automatisch, dass eine Rolle über einer anderen Rolle steht, und das ist das alte, hierarchische Management-Bild. Rollen beschreiben jedoch eigentlich nur Tätigkeiten, und die sollten gleichberechtigt sein. Das Entwickler-Team arbeitet nicht für den PO, sondern der PO übernimmt in dem Team eine andere Tätigkeit, als die Entwickler. Nur durch dieses Nebeneinander (statt Übereinander) kann ein wirkliches Miteinander und somit auch Selbstverantwortung und Selbstorganisation entstehen. Daher ist es wohl so, dass accountable eher schlecht ist, denn es verhindert am Ende das Übernehmen von Verantwortung. Und nein, ich glaube nicht, dass man automatisch auch accountable ist, wenn man Verantwortung übernimmt.

Eine Gruppe, ein Team, ein Unternehmen muss vielmehr einen geschützten Raum bieten, in dem das Übernehmen von Verantwortung gefördert wird, weil Fehler gemacht werden dürfen. Ich glaube, in der Wissensarbeit müssen Fehler gemacht werden, weil das Lernen sonst nahezu unmöglich ist. Wir machen oft Dinge, die noch nie (von uns) gemacht wurden. In diesem Umfeld sind Fehler normal und wichtig. Durch die Übernahme von Verantwortung durch das Team, werden aber die Konsequenzen, die diese Fehler haben können, reduziert. Ein verantwortlich denkend und handelndes Team wird keine Entscheidungen treffen, die dem Unternehmen schaden können. Sie müssen jedoch wissen, was der Schaden sein kann, wann der Schaden eintreten kann, wie groß der Schaden sein könnte etc. Daher ist es aus meiner Sicht elementar wichtig, dem Team alle relevanten Informationen zu geben und maximale Transparenz zu schaffen. Stünde hier wieder jemand „über“ dem Team der entscheidet, welche Informationen wichtig sind und welche nicht, käme sicherlich nicht alles beim Team an. Daher auch hier wieder: Hierarchien und das klassische Management-Verständnis behindern das Übernehmen von Verantwortung.

Natürlich aber hat das Handeln jedes Einzelnen auch Konsequenzen, und zwar für ihn selbst und seine „Karriere“. Wenn jemand konstant Fehler macht, nicht lernt, keine Verantwortung übernimmt oder sogar schädlich für ein Team, einen Kunden oder das Unternehmen ist, hat das natürlich Konsequenzen. Weil jeder Mensch für sich und sein Handeln verantwortlich ist UND zur Verantwortung gezogen werden kann.

Beispiele:

Ein Entwickler, der sich über Jahre nicht weiterentwickelt, wird vielleicht irgendwann den Anschluss verlieren und mit dem Rest des Teams nicht mehr mithalten können. Ein selbstorganisiertes Team wird versuchen, ihn zu unterstützen, in dem sie ihn weiterbilden oder vielleicht eine andere Tätigkeit für ihn suchen (weil sie das selbständig entscheiden können!). Durch Pairing wird versucht, ihn gleichzeitig zu schulen und seine Fehler zu minimieren. Das Team wird Dinge ausprobieren. Möglicherweise ist er kein guter Entwickler mehr, kann aber gut mit Kunden umgehen oder als agiler Coach arbeiten. Dann kann das Team darüber nachdenken, ob es sinnvolle Tätigkeiten für ihn gibt. Sollte sich keine Lösung finden und keine Verbesserung eintreten, wird er jedoch vielleicht irgendwann seinen Job verlieren.

Ein PO, der immer wieder Probleme mit Kunden hat, wird diese Tätigkeit vielleicht irgendwann nicht mehr ausüben und sich – mit dem Rest des Teams – für eine andere Tätigkeit entscheiden. So wird er vielleicht wieder Entwickler, weil er das vorher schon war. Oder er übernimmt organisatorische Aufgaben ohne direkten Kundenkontakt. Oder aber es stellt sich heraus, dass es keine passende Tätigkeit für ihn in diesem Team gibt. Mit den entsprechenden Konsequenzen.

In selbstorganisierten Teams funktioniert das.

Da kommt dann gleich der nächste Punkt ins Spiel: Wer entscheidet denn, was gut ist und was nicht? Wer bewertet die Arbeit des Teams und der einzelnen Teammitglieder? Da kommt man dann wohl automatisch zu 360° Reviews oder Peer Reviews, da es ja eigentlich keinen klassischen „Vorgesetzten“ mehr gibt. Aber das will ich hier gar nicht weiter ausführen, obwohl das auch ein wichtiges Thema ist (Karrierepfade in hierarchielosen, agilen Unternehmen, Gehaltsstrukturen, Feedbacksysteme etc.)

Spannend wäre jetzt noch zu klären, inwiefern das Team insgesamt accountable ist. Wahrscheinlich ist es das als (Business-)Einheit schon irgendwie. Das würde also bedeuten, dass man als Team für negative Auswirkungen zur Verantwortung gezogen werden kann. Aber müsste das nicht auch heißen, für positive Erfolge ebenso die Verantwortung zu haben? Und sind solche selbstorganisierten Teams dann am Ende nicht Unternehmen im Unternehmen? Und was ist das Mantelunternehmen drumherum dann überhaupt noch?

Wenn das Unternehmen mehr sein will, als nur ein hohler, juristischer Container für selbstorganisierte Teams, muss es wahrscheinlich vor allem die Konsequenzen des Handelns der Teams übernehmen, im positiven (Umsatz +) wie im negativen (Umsatz -). Ich habe dazu bisher aber noch keine finale Meinung.

Wie bekommt man die Teams nun dazu, diese Verantwortung zu übernehmen? Ich denke, durch Motivation, und zwar intrinsische (also innere) Motivation. Nur wenn die Teams motiviert sind, werden sie so handeln, wie ich es hier beschrieben habe. Für manche ist schon die Möglichkeit, diese Verantwortung zu übernehmen eine Motivation. Für andere sind es andere Faktoren, die für Motivation sorgen. Die Tätigkeit, die Technologien, die Zusammenarbeit mit den Kollegen, was auch immer. An dieser Stelle immer wieder die Aufforderung, Daniel Pinks Buch „Drive“ zu lesen…

In unserer Diskussion ging es dann noch um den Begriff der Antiautorität. In unserem Fall und den selbstorganisierten Teams, die Verantwortung übernehmen sollen, handelt es sch wohl tatsächlich um Antiautorität, da niemand von innen oder außen Autorität gegenüber dem Team ausübt und ihm Befehle erteilt, wie es in klassischen, autoritären Top-Down-Managementsystemen der Fall ist. Stattdessen gibt es Ziele, ein- oder beschränkende Rahmenbedingungen (das kann mal eine Technologievorgabe sein, ein festes Budget, was auch immer) und ein Team, das aus einem gemeinsamen Verständnis von Eigenverantwortung danach handelt. Wie bei einem Kind, dem man erklären muss, warum man nicht über eine rote Ampel laufen darf, ist eine ganz wichtige Aufgabe vor allem das Coaching. Dem Kind wird die Wichtigkeit der roten Ampel durch Erklären und Zeigen viel klarer als durch die autoritäre Ansage „Das darf man nicht“. Coaching ist also bei Kindern wie bei Teams extrem wichtig, und das ist auch genau die Aufgabe von modernem Management.

Die Diskussion ist noch nicht beendet, ich bin sehr gespannt, wie sie sich weiterentwickelt…

Diskutieren

Kommentare sind geschlossen.