Autonomie vs. Fremdbestimmung

Praktisch jedes große Technologieunternehmen ist mittlerweile auf den Zug eigenverantwortlicher, engagierter/beständiger, funktionsübergreifender und gut zusammenarbeitender Produkt-Teams aufgesprungen und ich glaube, dass das auch gut so ist. Man sieht kaum noch ein Unternehmen, das noch die alten Modelle nutzt (hauptsächlich das Pool-Modell). Allerdings ist es dennoch manchmal nicht leicht, die richtige Mischung aus Autonomie und Fremdbestimmung zu finden.

Die Ergebnisse sprechen zwar für sich, jedoch schreibe ich die meisten Vorteile der gesteigerten Motivation und dem wahren Verständnis für Ownership zu, welches entsteht, wenn Teams das Gefühl haben, selbst über ihre Arbeit bestimmen zu können.

Aber auch wenn mir die Teamleiter meistens erzählen, dass ihre Teams eigenverantwortlich und selbstständig sind, hört man von vielen Teammitgliedern, dass sie das oft anders sehen. Wenn das der Fall ist, versuche ich herauszufinden, was genau das Team nicht alleine entscheiden kann oder wobei es sich eingeschränkt fühlt.

Wo verläuft die Grenze zwischen Autonomie und Fremdbestimmung?

Meistens läuft das auf eine der folgenden beiden Antworten hinaus:

Entweder genießt das Team noch nicht voll und ganz das Vertrauen des Managements und daher will das Management den Teammitgliedern nicht wirklich freie Hand lassen.

Oder das Team möchte etwas ändern, was das Management als einen Teil der Grundlagen ansieht.

Grundsätzlich würden wohl alle Teams zustimmen, dass es sowohl einige Dinge gibt, die sie ganz frei selbst entscheiden können, als auch andere Bereiche, die ein Teil der gemeinsamen Grundvoraussetzungen für alle Teams sind.

Ein Beispiel

In diesem letzten Fall wäre es z. B. sehr ungewöhnlich, wenn jedes Team ein eigenes Versionierungstool aussuchen würde. Wenn das Entwicklungsteam beispielsweise GitHub als Standart festgesetzt hat, wird das normalerweise als Teil der grundlegenden Voraussetzungen angesehen. Selbst wenn ein Team eine starke Präferenz für ein anderes Tool hätte, würden die Kosten die Vorteile für das Unternehmen bei weitem übersteigen.

Dieses Beispiel ist zwar ziemlich eindeutig, allerdings gibt es auch viele andere, bei denen das nicht so klar ist.

Sollte jedes Team z. B. die Testautomatisierung auf eigene Art und Weise angehen können? Sollten die Teams individuell die Programmiersprache wählen können? Was ist mit dem Framework für die Benutzeroberflächen? Was ist mit Browserkompatibilität? Was ist mit teuren Features wie „Offline-Support”? Sollten sie selbst entscheiden können, wie „agil” sie arbeiten? Und muss jedes Team wirklich in mehreren Produktinitiativen im Unternehmen involviert sein?

Wie es bei Produkten oft der Fall ist, läuft es im Endeffekt auf einen Kompromiss hinaus – in diesem Fall ist es ein Kompromiss zwischen Eigenverantwortlichkeit und Einhaltung der vorgegebenen Grundlagen.

Auch wenn ich grundsätzlich das Prinzip autonomer und unabhängiger Teams sehr befürworte, bin ich zugegebenermaßen auch ein großer Fan davon, in eine gute Grundlage zu investieren. Mit einer soliden gemeinsamen Grundlage können die Teams nämlich viel schneller großartige Produkte und Erfahrungen schaffen.

Ich möchte diesen Kompromiss einmal etwas näher erläutern. Ich möchte aber auch betonen, dass ich nicht behaupte, dass es nur eine Antwort auf diese Frage gibt, sondern dass es bei jeder Firma und jedem Team anders sein kann. Alles hängt von verschiedenen Faktoren ab, die ich hier erläutern werde:

Punkte, die berücksichtigt werden sollten:

– Die Kompetenz des Teams:

Dabei gibt es im Großen und Ganzen drei unterschiedliche Situationen:

A-Team – ein erfahrenes Team mit klugen und kreativen Köpfen, bei denen man voll und ganz darauf vertrauen kann, dass sie gute Entscheidungen treffen.

B-Team – diese Personen haben die richtigen Absichten aber in vielen Fällen noch nicht die nötige Erfahrung, um gute Entscheidungen treffen zu können, weshalb sie noch etwas Unterstützung benötigen.

C-Team – ein Juniorteam, dass vielleicht sogar noch nicht einmal weiß, was es nicht weiß. Ohne intensive Betreuung können diese Teams unabsichtlich für große Schwierigkeiten sorgen.

– Schnelligkeit:

Eines der Hauptargumente für feste Vorgaben ist die Geschwindigkeit. Die Logik dahinter ist, dass Teams in der Lage sein sollten, auf die Arbeit ihrer Kollegen aufbauen zu können, damit sie keine Zeit damit verschwenden, das Rad neu zu erfinden. Jedoch ist es in einigen Fällen allgemein akzeptiert und üblich, den Teams zu erlauben, auch schon mal etwas langsamer zu arbeiten und eventuell etwas doppelt zu machen, wenn damit die Eigenständigkeit gefördert werden kann. Manchmal ist es aber auch essentiell wichtig für das Geschäft, dass sich an die Vorgaben gehalten wird.

– Bedeutung von Integration:

In einigen Unternehmen besteht das Portfolio aus verwandten aber größtenteils voneinander unabhängigen Produkten, bei denen Integration und Vorgaben nicht sonderlich wichtig sind. In anderen Firmen geht es im Portfolio um stark integrierte Produkte, bei denen gewisse allgemeine Vorgaben unverzichtbar sind. Im Endeffekt kommt es also darauf an, ob ein Team sich auf eine ganz bestimmte einzelne Lösung konzentrieren soll oder ob es eine optimale Lösung im Hinblick auf das gesamte Unternehmen finden soll.

– Quelle für Innovation:

Wenn die Hauptquellen für künftige Innovationen schon bei den Grundlagen zu finden sind, sollten die Teams mehr Freiheiten haben, diese grundlegenden Elemente überdenken zu können. Wenn die Ursprünge für Innovationen jedoch auf der Lösungsebene zu finden sind, sollte das Team sich weniger auf die Grundlagen und stattdessen mehr auf kreative Innovationen auf Anwendungsebene konzentrieren.

– Firmengröße und Standorte:

Autonomie wird oft schwierig, wenn Probleme bei der Skalierung auftreten. Wenn Unternehmen wachsen und ihre Teams auf verschiedene Orte verteilt sind, wird es schwieriger aber auch wichtiger, gewisse grundlegende Vorgaben zu machen. Einige Firmen versuchen dieses Problem dann mit dem Konzept eines „Center of Excellence” (Kompetenzzentrums) zu lösen, bei dem man ein Team, das gemeinsam an einer Aufgabe arbeitet, an einem bestimmten Standort zusammenbringt. Andere versuchen es mit ganzheitlicheren Rollen. Und wieder andere fügen Prozesse hinzu.

– Unternehmenskultur:

Auch bei der Teamkultur spielt das Verhältnis von Autonomie zu Fremdbestimmung eine wichtige Rolle. Je mehr Vorgaben ein Unternehmen macht, desto mehr haben die Teams das Gefühl, in ihrer Eigenständigkeit eingeschränkt zu sein. Für B-Teams und C-Teams mag das noch akzeptabel sein, für A-Teams ist das allerdings schon etwas problematischer.

– Reifegrad der Technologie:

Zu früh eine einheitliche Grundlage für alle festlegen zu wollen, ist ein häufig auftretendes Problem. Wenn die Grundlage nämlich noch nicht ausgereift ist, kann sie nicht die Unterstützung bieten, für die sie eigentlich gedacht war. Zu sehr auf die Umsetzung von Vorgaben zu drängen, bevor die Grundlagen wirklich fertig sind, kann den Teams, die sich ja auf die Grundlagen verlassen müssen, wirklich schaden. Das ist das Gleiche, als würde man etwas auf einem wackeligen Kartenhaus aufbauen wollen.

– Geschäftliche Bedeutung:

Wenn wir davon ausgehen, dass die Grundlage solide ist, bestehen mehr Risiken bei einem Team, das diese Grundlagen nicht nutzt. In einigen Fällen mag das nicht weiter schlimm sein. Wenn es aber um Produkte oder Initiativen geht, die entscheidend für das Geschäft sind, muss man sich gut überlegen, worauf man sich konzentrieren sollte.

– Grad an Verantwortung:

Ein weiterer Faktor ist der Grad an Verantwortung, der mit Selbstbestimmung und Unabhängigkeit einhergeht. Wenn die Teams keine Eigenverantwortung haben – und besonders wenn es keine starken A-Teams gibt – haben die Teams auch keinen wirklichen Grund, diesem Kompromiss besondere Beachtung zu schenken. Man möchte aber, dass die Teams sich Gedanken um diesen Kompromiss machen. Wenn ich weiß, dass das Team stark ist und voll und ganz über die Risiken und Konsequenzen Bescheid weiß und dennoch einen wesentlichen Bestandteil der Grundlagen ignoriert oder austauschen möchte, dann unterstütze ich die Teammitglieder bei dieser Entscheidung.

Zusammenfassung

Wie Sie sehen, gibt es viele Punkte, die beachtet werden müssen. Meiner Meinung nach sind die meisten Teams allerdings sehr vernünftig, wenn man diese Themen offen anspricht. Manchmal helfen dem Team schon ein paar grundlegende Fragen bezüglich der Auswirkungen, um bessere Entscheidungen im Hinblick auf diesen Kompromiss treffen zu können.

Wenn Teams jedoch permanent schlechte Entscheidungen diesbezüglich treffen, sollten Sie noch einmal über den Grad an Erfahrung im Team nachdenken und vielleicht mehr Zeit investieren, um sicherzustellen, dass die Teammitglieder auch wirklich alle geschäftlichen Zusammenhänge verstehen.

Dieser Text stammt aus dem Blog von Marty Cagan und wurde von uns ins Deutsche übersetzt.