Wie funktionieren OKRs in Crossfunktionalen Teams?

Bei nahezu jeder OKR Einführung kommt irgendwann einmal die Frage auf: „Funktionieren OKRs eigentlich mit crossfunktionalen Teams?“. Die Antwort ist recht einfach: “Ja!”. Das OKR Modell lässt sich nirgendwo einfacher anwenden, als in einer Organisation mit echt crossfunktionalen Teams (XTs). 

„OKRs lieben crossfunktionale Teams! Und in der Regel auch umgekehrt."

Das Problem an der Sache ist meist nur, dass sich die Unternehmen in vielen Fällen irgendwo auf dem Pfad der Digitalen Transformation befinden und die Aufbauorganisation „an-agilisiert“ ist, d.h. man traut dem Grundkonzept noch nicht so ganz und steckt Mitarbeiter zusammen in Teams mit verschiedenen Fähigkeiten, belässt sie aber mit einem - oft unbestimmten - Teil ihrer Ressourcen in der funktionalen Linienorganisation. Um das Chaos perfekt zu machen kommen einige Organisation noch auf die Idee zusätzlich Projekt-Teams aufzusetzen.

Damit OKRs in der crossfunktionalen Organisation alle Vorteile voll entfalten können sind einige wichtige Rahmenbedingungen zu beachten:

Was ist ein crossfunktionales Team?

Der Grundsatz ist leicht zu beschreiben. Eine überschaubar große Gruppe an Menschen mit unterschiedlichen Fähigkeiten findet sich zu einem Team zusammen und verschreibt sich einer gemeinsamen Mission. Da sich die Teammitglieder kennen und schätzen, sind sie in der Lage, schnell und flexibel auf neue Herausforderungen zu reagieren und diese abschliessend zu lösen. Dabei haben sie alle Fähigkeiten und Ressourcen, die sie dafür benötigen und sind in der Entscheidungsfindung über den Lösungsweg autark. Die grundsätzliche Mission und die Ziele sind so definiert und abgegrenzt, dass eine sogenannte „End-to-End Verantwortung“ möglich ist. Das Team übernimmt also die Verantwortung, die Herausforderung eigenständig zu lösen - und nicht nur an einer möglichen Lösung zu arbeiten. 

Analogien für dieses Konzept finden sich in den “Squads” der Spezialeinheiten von Militär oder Polizei. Kleine, schlagkräftige Einheiten sind autark in der Lage, ein sich stellendes Problem, innerhalb ihres grundsätzlichen Handlungsfeldes, schnell zu lösen. Durch gemeinsame Trainings und operative Erfahrungen lernt das Team sich gegenseitig schätzen und entwickelt Vertrauen in die Fähigkeiten der einzelnen Teammitglieder. Der Übernahme der Verantwortung durch das Team steht eine Stabilität und autarke Entscheidungsfindung gegenüber. Schliesslich würde niemand auf die Idee kommen einer Spezialeinheit mitten in einer Geiselnahme den Scharfschützen vom Dach zu entziehen. In der Unternehmensrealität kommt dies allerdings ständig vor.

Das Produkt muss eine „End-to-End Verantwortung“ überhaupt ermöglichen

Um am Ende auch wirklich die Verantwortung „bis zum Ende“ übernehmen zu können, muss dies auch durch die Realität im Produkt oder entsprechenden Servicebereich entsprechend abzubilden sein. Gerade klassische Softwareprojekte mit einer zentralen Architektur ermöglichen es den crossfunktionalen Teams (XTs) oft nicht, ihre Lösungen auch in die Realität zu überführen. Es kann also einige Zeit dauern, bis zum Beispiel ein Wechsel zu einer Mikroservice-Architektur stattgefunden hat. Wichtig ist nur, dass ein entsprechendes Zielbild klar vorhanden ist und alle Beteiligten das gleiche Verständnis von der Umsetzbarkeit einer End-to-End-Verantwortung haben - und dies auch wollen. In vielen Fällen geht damit nämlich ein Kontroll- oder Machtverlust bei den bisher zentralisierten Kontroll-Organen einher. Der teilweise berechtigten Angst vor unerkannten Fehlern oder Qualitätseinbussen muss im Vorfeld mit sauberen Prozess- und Schnittstellendefinition begegnet werden.

"Support Teams“ tragen nicht ohne Grund den Begriff „Support“ im Namen

In einer crossfunktional aufgebauten Organisation richten sich alle Teams nach einem Produkt oder einem Teilbereich eines Produktes aus. Dabei sollte man nicht den Fehler machen, die Teams nach Prozessen oder ähnlichen Konstrukten zu schneiden und die Rolle des „Product Owners“ dann entsprechend umzuinterpretieren. Klar könnte man den PO intern auch “Process Owner” nennen, das ist aber nicht die Grundidee des Konzeptes. Ein Produkt ist eben etwas anderes als ein Prozess. 

Wenn sich alle Teams im Unternehmen nach den Produkten ausrichten, dann kommt es trotzdem vor, dass einige Rollen und Funktionen nicht zwingend explizit in den Teams gebraucht werden, diese aber für den Gesamterfolg notwendig sind. Buchhaltung ist ein klassisches Beispiel: Natürlich braucht nicht jedes XT seine eigene Position für die Buchhaltung.
Diese Rollen werden zentral zu den sogenannten “Support Teams” zusammengefasst, die den XTs entsprechende Unterstützung zukommen lassen, um bestmöglich ihren Job zu erledigen. Wie immer im Leben ist es auch hier ein Geben und Nehmen und man begegnet sich respektvoll und auf Augenhöhe. Wenn es allerdings anfängt, dass die Support Teams die XTs steuern, da beispielsweise das Controlling-Team aus dem Finance-Bereich (oder Circle) die operativen KPIs „durchsteuert“ wird es kritisch. Ähnlich fraglich ist ein Aufbau eines Support-Teams „Marketing“. Hier lohnt es sich einmal das Selbstverständnis und die Rollendefinition des Marketing-Teams zu hinterfragen, da sich ein echter Marketing-Profi in einer „Supportfunktion“ recht unwohl fühlen dürfte, wenn doch die Definition von Marketing die "Steuerung des Unternehmens nach den Bedürfnissen des Marktes“ ist - und somit einen wesentlichen Bestandteil im XT einnehmen sollte.

Braucht man eine Matrix oder reicht eine Gilde?

Moderne Organisationsformen wie beispielsweise das Spotify Modell schaffen es, die klassische Matrix-Struktur aufzulösen, indem klar definiert wird, nach welchen Größen innerhalb des Unternehmens optimiert wird. Dadurch hört man endlich auf, der Illusion einer Optimierung nach mehreren Faktoren gleichzeitig hinterher zu laufen. In der Optimierung nach einem Maximum ergibt sich immer ein Spannungsfeld mit einer anderen Größe. Versucht man beides, landet man in einer unlösbaren Gleichung, optimiert sich zu Tode oder, noch schlimmer, verbrennt die Mitarbeiter.

„Die Matrix ist ein systemtisch definierter Interessenskonflikt“

Grundsätzlich stellt sich ja die Frage, ob man alle Spezialisten wie zum Beispiel “Maurer” in eine Organisationsstruktur packt oder ob es sinnvoller ist, all diejenigen zusammen zu organisieren, die gemeinsam ein Haus bauen. Der crossfunktionale Ansatz folgt der Idee, dass es hilfreicher ist, alle zu vereinen, die sich dem gleichen Ziel verschrieben haben, anstatt den Kreis um all jene zu ziehen, die ähnliche Fähigkeiten haben.

Die Möglichkeit autarke Entscheidung zu treffen, ein bestimmtes Material zu nutzen oder eine Technik anzuwenden führt zu besseren Ergebnissen in dem jeweiligen Produkt, auch wenn dies in Teilen der herrschenden Meinung der Mehrzahl der Fachleute widersprechen mag. Versuchen sowohl der erfahrenste Experte, als auch der Architekt ihren Einfluss auf denjenigen zu nehmen, der sich um die Umsetzung kümmert, kommt es unweigerlich zu einem Interessenkonflikt. Daher lösen moderne Konzepte dies mit einer Gilde statt einer Matrix. Die Gilde stellt den Erfahrungsaustausch unter Experten sicher und sorgt dafür, dass jeder Experte die neusten Erkenntnisse und Fähigkeiten hat. Die Entscheidungen über die konkreten Umsetzungen werden allerdings autark innerhalb eines Produktes getroffen. Die Gilde ist somit nicht mehr als eine „Interessengemeinschaft“.

Wer bekommt ein OKR Set in einer crossfunktionalen Organisation?

Bei der Einführung von OKRs stellt sich nun die Frage, welches Team ein OKR Set bekommt und welche OKR Sets sich aus welchen ableiten lassen bzw., besser gesagt, auf welche sie einzahlen.

Jedes Produkt- und jedes Support-Team bekommt ein eigenes OKR Set. Innerhalb der Produkt-Teams können diese beispielsweise auf einzelne Squads herunter gebrochen werden. Die klassischen funktionalen Linienorganisationen werden nicht mehr verfolgt.

Die bisherigen Führungskräfte der Funktionen sind nach der Transformation der Organisation die Zentralorgane der Gilden. Sie sorgen für die Interessenvertretung der Gemeinschaft und den internen Informations- und Erfahrungsaustausch, haben jedoch keine Steuerungsfunktion und keine disziplinarische Durchgriffsmöglichkeit, da sie selbst nicht über Mitarbeiter verfügen. Die „Interessenvertreter“ können als Stabsstellen aber weiterhin ein OKR Set definieren, welches sie mit Unterstützung der einzelnen Product Owner und der dort vertreten Mitarbeiter umsetzen können. Die Themen müssen dann während der OKR Planung in den OKR Sets der POs entsprechend berücksichtigt werden.

Wie stellt man crossfunktionales Alignment her?

Das schöne an XTs ist, dass es per Definition deutlich weniger Abstimmung und Alignment braucht. Die Grundidee ist ja gerade, dass ein Teams nichts von einem anderen Team benötigt, um seine Ziele zu erreichen. Die Abstimmung im Kontext der OKR Workshops bezieht sich dann nur noch auf die gemeinsamen Effekte für den Kunden, die sich durch Umsetzung der Ziele erreichen lassen. Die Abstimmung fokussiert sich also deutlich mehr auf den Teil der Synergieeffekte, die erzielt werden können, wenn Team A und B an Themen arbeiten, die gegenseitig aufeinander einzahlen. 

Innerhalb des OKR Workshops werden die Inhalte der crossfunktionalen Teams aufeinander abgestimmt, so dass entschieden wird, worauf der Fokus innerhalb des Produkt-Teams für das kommende Quartal liegt. Innerhalb des Produkt Teams stimmen sich die Sub-Teams oder Squads darüber ab, wie die Ziele für das Quartal am sinnvollsten intern verteilt werden. Der Scope auf Ebene des Produktes ist definiert. Sub-Teams oder Squads können innerhalb des Scopes mit der Unterstützung durch andere Teams rechnen. Darüber hinaus benötigen sie keine Unterstützung und können maximal Themen bearbeiten, die sie aus sich selbst heraus zusätzlich zum OKR Sets des Produktes lösen können. Eine crossfunktionale Abstimmung zwischen Sub-Teams oder Squads ist nicht erforderlich. Natürlich kann auf der Umsetzungsebene die Expertise und Meinung etc. anderer Teams eingeholt werden; allerdings versucht man nicht deren Arbeit durch die eigenen Ziele zu beeinflussen.

Wie funktionieren OKRs in der Übergangsphase zu crossfunktionalen Teams?

Befindet sich das Unternehmen mitten in der Digitalen Transformation und ist die Organisation noch nicht vollständig nach XTs aufgebaut, bietet es sich an die Themen sauber über die klassisch funktionale Aufbauorganisation zu steuern, so dass beispielsweise Entwicklung und Marketing die jeweiligen Themen definieren, die sie beitragen können, um ein gewisses Ziel auf dem Company Set zu realisieren. Die einzelnen XTs leiten ihre Ziele dann sinnvollerweise aus den übergeordneten Teams ab, deren Funktionen in dem XT vertreten sind.

Die Gesamtverantwortung inkl. der Machbarkeits- und Ressourcenplanung obliegt dann noch den jeweiligen funktionalen Führungsrollen. Werden Ressourcenplanung und Zieldefinition nicht an einer zentralen Stelle zusammengeführt, ergibt sich ein massives Risiko der Überforderung der Organisation durch unrealistische Ziele. Die jeweiligen Product Owner stimmen mit den Funktionen mit Hilfe ihrer OKR Sets ab, welche Unterstützung zu dem Set der Funktion wie zum Beispiel Entwicklung aus dem XT zu erwarten ist. Somit ist sichergestellt, dass alle Anforderungen zentral überblickt werden können.

Sind die Team-Mitglieder der XTs nicht dediziert zu 100% den XTs zugeordnet, bietet es sich an, für die XTs keine eigenen OKR Sets zu definieren, sondern dies über die Funktionen zu steuern, bis die erforderlichen Rahmenbedingungen hergestellt worden sind und die Teams autark arbeiten können. In diesem Ausnahmefall können sich die XTs auf der Arbeitsebene treffen, sie arbeiten aber nicht an einem einheitlichen und gemeinsamen OKR Set.

Die Definition zusätzlicher Projekte sollte ebenfalls vermieden werden, da sich die Grundidee der Projektorganisation mit der der Produktorganisation in die Quere kommt. Versucht man über die oben beschriebene Ebenen noch einen Projekt-Layer zu legen ergibt sich daraus eine neue Ziel-Ebene für eine weitere virtuelle Gruppe an Menschen (die Mitglieder eines Projektes). Allerdings werden es dadurch nicht mehr Menschen, die das Ziel auch erfüllen können - es wird lediglich komplexer abzubilden und nachzuvollziehen. Die ursprünglichen Projekte sollten stattdessen den Missionen der einzelnen Teams zugeordnet und in Ziele für die Teams zerlegt werden.

Welche Erfahrungen habt Ihr in Bezug auf OKRs in Verbindung mit crossfunktionalen Teams gemacht, gerade wenn es um die Einführungsphase geht?