AMA12: Ask me anything about OKRs - Die OKR Q&A Session

In der Episode 12 der AMA-Reihe geht es um die Frage, wie viele Ziele eigentlich Sinn machen und wie viele Ressourcen man benötigt, um diese Ziele auch zu erreichen. Zusätzlich setzen wir uns mit dem Thema Cross Functional Alignment auseinander und durchleuchten, wer eigentlich an einer Retrospektive teilnimmt und wie man das Know How im OKR Rollout Prozess gut durch alle Ebenen bringen kann.

Die Episode gibt es wie immer bei Spotify, Apple Podcast, Soundcloud, Youtube und überall wo es Podcasts gibt.

Wenn Du gerne bei einer der kommenden AMA Folgen mitdiskutieren möchtest, dann melde Dich gleich zu unserer Mailingliste an.

Die häufigsten FAQs zum Thema OKRs hier auch in der AMA Session zum nachlesen

Freut mich, dass ihr die Zeit gefunden habt, um dem Thema OKRs eure Zeit und eure Gedanken zu widmen. Ich freue mich auf ganz viele spannende Fragen. Ich würde sagen, wir fangen direkt mit der ersten Frage an.

XY, ich habe gesehen, du bist der Erste.

0:00:20 Teilnehmer-Frage: Ich hätte gerne Erfahrungswerte, wie damit umzugehen ist, wenn immer wieder unumgängliche Projekte hereinkommen, die nicht ins OKR Framework hineinpassen.

Ja, hallo. Ich habe eine Frage nach Erfahrungswerten. Wir sind jetzt schon eineinhalb Jahre dabei, mit OKRs zu arbeiten und es gibt ein Problem, das immer wieder auftaucht. Und zwar kommen „Projekte“, um die wir nicht herumkommen, die per se aber gar nicht so ins OKR Framework hineinpassen. Wir haben dann oft eine Diskussion im Sinne von „das müssen wir halt machen, das muss man mitnehmen“. Wir haben jetzt noch kein Workaround oder keine Abhilfe gefunden, wie wir das mit unseren OKRs verbinden können.

Konkretes Beispiel: Ich bin aus Österreich, wir haben in Deutschland ein Team mit vier Leuten. Wir mussten umziehen und sind mitten im Umzug. Da gibt es jetzt keinen „Head of Umzug“ und das frisst dann teilweise doch viele Ressourcen, was wir vorher vielleicht gar nicht einschätzen konnten. Das eckt dann immer wieder mit den OKRs an, die wir uns vorgenommen haben.

Und wenn es jetzt nicht der Umzug ist, dann kommt irgendetwas anderes. Ich rede nicht von Sachen, die man lassen kann, da sind wir schon recht gut. Wir können wirklich sagen, jeder von uns fokussiert  drei bis fünf Dinge und so weiter. Das funktioniert eigentlich recht gut. Aber es kommen dann doch  immer wieder so Sachen rein, um die wir nicht umhin kommen, und die dann irgendwie im Clinch mit den eigentlichen OKRs stehen.

Ich brauche da irgendwie Erfahrungswerte. Wir haben noch keine Lösung gefunden, wie wir das gemeinsam auf die Bühne bringen.

Leider passiert dann, dass das Team teilweise eher wieder Richtung „ach so, jetzt machen wir wieder Projekte, dann kann ich wieder ein Projekt machen im Sinne von „Umzug ist ein Projekt“, dann mache ich das, weil das viel einfacher ist, als mich da hinzusetzen und OKRs zu formulieren.“ Da habe ich dann so ein bisschen ein Problem mit der Laune und…

0:02:25 Marco

Dieses Umzugsprojekt kommt ja ähnlich unvorhersehbar wie Weihnachten und Ostern und solche Geschichten, oder? Also, das sind Sachen, die hätte man sehen können. Dass ein Umzug nicht ohne viel Aufwand über die Bühne geht, ist auch eher wahrscheinlich als unwahrscheinlich, oder?

0:02:42 Teilnehmer

Ja, das stimmt. Es war zwar recht kurzfristig, aber man hat das sicher schon ein paar Monate im Voraus wissen können. Die Frage ist, streiche ich dann von ein oder zwei Teammitgliedern quasi die OKRs komplett und sage: Ihr macht jetzt den Umzug. Weil da ist ja sowieso alles klar. Ihr müsst das nach dort bringen, ihr müsst das dort aufhübschen…

0:03:08 Marco

Wie du inhaltlich damit umgehst, wer jetzt die Sachen von A nach B bringt, das ist nochmals eine andere Frage.

Aber es geht ja darum zu sagen, wie viel Kapazitäten haben wir denn. Wenn du weißt, dass eine bestimmte Anzahl der Kapazitäten mit so was wie mit einem Umzug oder einem Website-Relaunch oder was auch immer gebunden sein wird, dann musst du das halt auch entsprechend berücksichtigen und sagen: Wo nehme ich denn die Ressourcen her? Welches Team kümmert sich denn da jetzt um das „Projekt“? Das gilt es natürlich im Vorhinein herauszufinden. Also, so gut man eben kann. Aber du redest jetzt eher von Sachen, die man wahrscheinlich irgendwie einschätzen könnte. Also die sind ja jetzt nicht wirklich vom Himmel gefallen, die waren nicht unvorhersehbar, dass man umzieht, das könnte man antizipieren.

0:04:00 Teilnehmer

Ja, auf alle Fälle. Aber würde das im Umkehrschluss bedeuten, dass dieses Team, das ich für den Umzug bereitstelle, dann evtl. für diesen OKR-Zyklus keine OKRs hätte und dann wieder einsteigt? Wäre das ein…

0:04:04 Marco

Nein. Das würde ich nicht so sehen. Ein Teil des OKR-Sets kann ja sein, dass man sich in dem neuen Büro wohl fühlt und dass alles funktioniert und dass es besser und schöner ist als vorher. Warum kannst du das nicht als Ziel formulieren? Das ist ja relativ klar umrissen.

Dann kannst du sagen: Dafür brauche ich zwei Drittel der Ressourcen von dem Team und der Rest kann noch was anderes machen. Ein Projekt ist ja per se beschrieben als etwas, was einem Ziel dient, also kann man das auf jedem Fall in OKRs setzen, sonst wäre es per Definition auch kein Projekt. Dann hätte es auch kein Ziel.

Du musst einfach nur sagen: Das muss da rein. Dann muss man sagen, das soll in drei Monaten sein. In den drei Monaten müssen dann alle umgezogen sein, jeder sitzt an einem Platz, jeder hat irgendwie alles, was er zum Arbeiten braucht, es ist irgendwie nett, es regnet nirgendwo rein, du hast Strom und Internet. Das musst du irgendwie formalisieren, also als Ziel formulieren und dann kannst du sagen: Dafür brauche ich zwei Drittel der Ressourcen. Jetzt hast du noch ein Drittel der Ressourcen, um etwas anderes zu machen.

Wenn du aber sagst: Ich brauche drei Drittel der Ressourcen für die anderen Sachen, dann bietet es sich halt an, ein Umzugsunternehmen zu beauftragen.

0:05:39 Teilnehmer

Okay. Und das könnte man jetzt pauschal – weil du jetzt vorhin gesagt hast „Webseiten-Relaunch“ – das würde da wahrscheinlich auch funktionieren.

0:05:49 Marco

Es muss, das ist überall das gleiche! Du musst sagen, was rauskommen soll und dann weißt du, wie viel Ressourcen da ungefähr dafür zu verplanen sind. Wenn du das weißt, weißt du, was noch übrig ist, und so kannst du dann ein in sich schlüssiges OKR-Set bauen. Es geht ja darum, sich vorher zu entscheiden: Was will ich, was wo rauskommt und wo nehme ich die Ressourcen her? Denn nur dann kannst du die Entscheidung treffen, ob dir das eine wichtiger oder ob dir das andere wichtiger ist.

0:06:20 Teilnehmer

Gut. Dann ist die Lösung ja eigentlich recht leicht. Dann müssen wir einfach nur sagen, das müssen wir mit reinnehmen.  Alles klar.

Ich werde das auf jeden Fall berücksichtigen. Okay, gut. Das war’s schon.

0:06:36 Marco

Sehr gut.

0:06:38 Teilnehmer

Danke.

0:06:40 Marco

Gerne.

Dann XY.

0:06:44 Teilnehmer-Frage: Wie lässt sich das Tagesgeschäft eines typischen Agenturgeschäfts mit OKRs verbinden?

Hi zusammen.  Ich bin Geschäftsführer von einer Digitalagentur, d.h. wir machen Marketingsachen, Website-Entwicklung und solche Dinge. Wir sind 15 Leute, zwei Geschäftsführer. Seit „Dank Corona“ oder „mit Corona“, wie auch immer, hat sich das Ganze so entwickelt, dass wir jetzt deutlich mehr mit virtuellen Teams arbeiten und das ein bisschen mehr ausgliedern und andere Leute mit dazu holen, was sich aufgrund der Projektanfragen so heraus selektiert hat.

Es ist halt so, dass das typische Agenturgeschäft in den meisten Fällen sehr kundengesteuert ist. Man hat zwar eigene Themen, aber es kommt von dem, was ich tue, sehr viel Input von außen, da wir kein eigenes Produkt entwickeln.

Jetzt habe ich eine Änderung - ich verfolge das ja schon eine Weile hier über euch – und denke, dass das Tagesgeschäft im besten Fall mit in die OKRs aufgenommen werden soll. Wir nutzen sie noch nicht, würden aber gerne in diese Richtung gehen. Da hadert es ein bisschen bei mir, wie ich das unter einen Hut kriege.

Natürlich haben wir interne Entwicklungsgeschichten wie „Wohin?“ und solche Dinge, aber überwiegend ist es natürlich erstmal das Agenturgeschäft, woran gearbeitet wird.

0:08:38 Marco

Das ist sozusagen eine klassische „Projektorganisationsfrage“. Dir geht es ja darum, wie kriegst du das eher projektorientierte in die OKRs – also nicht wie wir gerade hatten, als Projektbegriff den Umzug – sondern eher euer Kundengeschäft, oder? Das ist ja die Frage. Also das, was am Kunden stattfindet.

0:08:54 Teilnehmer

Genau. Das, was am Kunden stattfindet. Dadurch, dass wir jetzt auch nicht mehr alle zusammen sitzen. Vorher war der Haufen im Büro, da ist das relativ gut hinzubekommen. Aber wir würden gerne alles ergebnisorientierter gestalten und nicht: Ich habe jetzt achteinhalb Stunden Anwesenheit hinter mir, tschüs, das war’s. Alleine dadurch, dass im Homeoffice unterschiedliche Nationalitäten und Zeitzonen zusammen kommen, ist das natürlich vom Management her anders. Trotzdem haben wir Ziele zu erreichen. Das kann man zum einen mit KPIs machen, was aber nicht überall zielführend ist, was wahrscheinlich den Entwicklern auch an der einen oder anderen Stelle komplett egal ist.

0:09:45 Marco

Eher mehr egal als weniger.

Wir müssen ein Stück zurück zoomen. Ob das nun virtuell ist oder nicht, ist total egal. Ob das Team vor Ort sitzt oder nicht, ist für die Fragestellung unerheblich. Wenn es vor Ort mit mehr Chaossteuerung besser funktioniert, dann war es vor Ort aber auch schon nicht gut, folglich ist das unerheblich.

Ein bisschen rausgezoomt muss man sagen: Was will OKRs eigentlich oder woher kommt das? Das ist ja ein Thema, was einem gegebenen Team die Möglichkeit gibt, die Ressourcen bestmöglich zu allokieren. Das ist das Gegenteil von einer projektgetriebenen Organisation. Da ist nämlich das Ziel fix, das was der Kunde will oder das, was das Projekt sagt – wo immer das auch herkommt, ob das ein Kundenprojekt ist oder was anderes. D.h., das Ziel ist fix und du musst die Ressourcen organisieren und die musst du mit dem gegebenen Ziel im gegebenen Zeitrahmen organisieren.

Das ist bei OKRs von der Denkweise her anders. Wir kommen von dem festen Team und das feste Team – die festen Ressourcen – sagen dir den variablen Scope. Da muss man erstmal umdrehen und sagen: Team ist fix. Dann kann ich nicht, wenn das Team fix ist, bzw. die Ressourcen fix sind. Wenn ich auf die Ressourcen mit festen Zielen reagiere, also mit einem festen Scope habe ich ja etwas, was nicht mehr aufgeht. Demzufolge muss ich das ja so übersetzen, dass ich sage: Wenn die Ressourcen gegebenen sind, dann können wir jetzt überlegen, was in drei Monaten machbar ist und wo die Ressourcen am besten investiert sind, also wo kommen wir am besten voran.

Das KPI-Thema, das du angesprochen hast, ist im projektbasierten Geschäft natürlich relativ dröge, weil es sich auf Auflastungsquoten und so bezieht. Dass das die Entwickler und den Rest langweilt, ist ja auch klar, weil die Aussage ist: Solange die Leute irgendwas machen, was sie können, was jemand brauchen kann, der Geld dafür zahlt, ist alles in Ordnung.

Das ist aber relativ austauschbar und damit hast du natürlich weder ein Profil, noch gewinnst du irgendwie was, was jemanden in deinem Laden oder auf der Kundenseite interessiert. D.h., das reine KPI-basierte Steuern von einem Agenturmodell ist für OKRs per se total uninteressant. Also da gewinnst du nichts, wenn du das da reinpackst, denn solange das Denken das gleiche bleibt, schreibst du halt die KPIs in die OKRs und dann hast du nichts gewonnen.

Demzufolge musst du das ganze Denkmodell umdrehen und sagen: So, wenn wir jetzt eine Truppe von zehn, fünfzehn, zwanzig, dreißig Leuten sind, müssen wir uns überlegen, was wir mit den Fähigkeiten am besten machen. Wo setzen wir die am gewinnbringendsten ein? Und gewinnbringend bezieht sich hier eher auf Nutzen als auf Cash. Demzufolge musst du überlegen: Was können wir gut, wo können wir den größten Unterschied machen, wo wirkt das am besten? Und dann musst du dir „Herausforderungen“ suchen, wo das am besten wirkt. Sprich, du brauchst Kunden, die das haben wollen, was du verkaufen willst. Und zwar so und in dem Zeitrahmen, wie du es verkaufen willst.

0:13:08 Teilnehmer

Jetzt wird’s eher ein Vertriebsthema?

0:13:10 Marco

Nein, es ist eher ein Produktthema. Also OKRs ist ja eher zur Steuerung eines Produktes statt dem, was irgendein Dritter von mir haben will. Denn das impliziert, dass du gar nicht selber entscheiden kannst, was du willst, sondern du bist quasi opportunitätsgetrieben von dem, was ein Kunde von dir „verlangt“ oder möchte oder sich vorstellt. Ich sage nicht, dass das eine besser ist als das andere, man kann Agenturen so steuern, das habe ich selber jahrelang gemacht. Ich persönlich fand es irgendwie uninteressant und es hat auch nicht zu Erfolg geführt.

Wenn man das Ganze produktisiert und fragt: Was wollen wir denn überhaupt lösen? Für welches Problem glauben wir, eine gute Lösung gefunden zu haben? Dann kann man daraus Produkte bauen, was für Dienstleistungen durchaus auch virtuell funktioniert, und kann an die dann sozusagen mit den passenden Kunden matchen. Plötzlich hast du ein Produktgeschäft, wo du deine eigenen Produkte – sei es technische Implementierung, Workshops, Ausbildungen, was auch immer da dann rauskommt - versuchst zu optimieren und mit Auslastung, sprich mit Kunden zu versehen. Aber so, wie du es dir auf deiner Seite vorstellst und nicht, was sich grade verkaufen lässt. Denn irgendjemand sagt immer: Hey, ich brauche jemanden, der was mit Computern kann, wie sieht es bei euch aus?

Ich pointiere es bewusst, aber wahrscheinlich ist es in Teilen in der Realität nicht viel anders. Ich komme ja selber aus der Ecke, demzufolge kann ich die Realität gut nachvollziehen. So findest du natürlich auch kein Standing. Dann sagt irgendein Kunde oder ein Einkäufer: Ja gut, Sie machen das, der andere macht’s billiger… Da kommst du ja nicht raus. Hingegen, wenn du sagst: Wir glauben, dass wir für das und das Problem passende Lösungen, sprich Produkte, gefunden haben. Dann musst du jetzt danach Kunden finden, die zu den Lösungen passen. Also, du brauchst Kunden, die das Problem haben, das du lösen willst. Dann kommt ein ganz anderes Business daraus. Demzufolge kannst du das dann anfangen, produktorientiert quartalsweise mit OKRs zu steuern, weil du dann sagen kannst: Jetzt kann ich das Feature verändern, jetzt kann ich dafür sorgen, dass wir dieses Produkt 17 Mal bei unterschiedlichen Kunden anwenden. Dadurch wird es auch ein bisschen steuerbar und planbar und es macht noch mehr Spaß. Und es differenziert auch noch mehr.

Also ich habe da in Agenturen schon ganz tolle Sachen machen sehen. Aber wenn man auf dem Billebillauer-Konzept bleibt und sagt: Egal, wo die Nachfrage herkommt, dann ist OKRs total unspannend.

0:15:52 Teilnehmer

Den Schritt haben wir zum Glück auch hinter uns. Das geht schon alles in die Richtung. Ja, ok. Ich weiß immer noch nicht ganz genau…

0:16:06 Marco

Du musst dir dann überlegen… D.h., hinten raus fallen ganz viele Projekte runter, die du vorher gemacht hast, weil sie nicht mehr zu deinen Produkten passen. Du hättest mich vor zehn Jahren fragen können: Kannst du unser Marketing optimieren?  Ja, kann ich. Mach ich es? Nein. Manchmal wäre es sogar spannend, das zu machen, aber es ist nicht zwingend das, was zu unserer Strategie passt, und nicht zu den Problemen, die wir lösen wollen. Also: Nein, machen wir nicht. Aber das ist halt eine klare Positionierung, wohingegen du erst mal lernen musst: Cool, das ist nicht das, was wir anbieten wollen, deswegen passt es nicht zu unserem Produktkatalog. Nein, machen wir nicht.

Da fängt es an, anders zu denken. Durch das andere Denken kommst du in diese Produktisierung und dann kannst du anfangen, das Ganze Quartal für Quartal abzubilden und kannst sagen, wie viel Mal können wir denn das Produkt – keine Ahnung – „kleiner Webshop für den Blumenladen um die Ecke“ verkaufen oder was auch immer da herauskommen mag.

0:17:20 Teilnehmer

Okay. Ab dann würde es Sinn machen, mit OKRs zu arbeiten; vorher eigentlich nicht wirklich.

0:17:25 Marco

Vorher hast du halt ein KPI-basiertes Steuerungssystem, wo es quasi immer nur darum geht, wo kriege ich die Auslastung her. Das ist halt nicht spannend. Also nicht für OKRs, sondern wahrscheinlich auch für die Leute, die da arbeiten. Das kann jeder für sich selbst entscheiden.

0:17:43 Teilnehmer

Ja, okay. Super, danke dir.

0:17:45 Marco

Gerne.

Dann XY, glaube ich.

0:17:51 Teilnehmer-Frage: Sollte das Tagesgeschäft in den OKRs abgebildet werden oder nicht?

Ja, genau. Hallo.

Eigentlich hatte ich so ziemlich dieselbe Frage wie die Person vorher, aber ich wollte jetzt nochmals in eine andere Richtung gehen.

Also, ich bin von einem kleinen Start-Up. Wir haben uns vor einem Quartal gegründet und machen auch Dienstleistungen. Wir beraten Hersteller, wie sie ihre Kunststoffprodukte auf rezikliertes Material umstellen können. Wir haben auch schon zwei Quartale OKRs verwendet und wir hatten diese Videos angeguckt. Da wurde gesagt, das ganze Tagesgeschäft soll in einem Set abgebildet sein, deshalb haben wir das im ersten Quartal auch probiert. Wir haben aber grad auch ziemlich viel andere Sachen, die wir aufbauen müssen, d.h., bei uns ist es immer sehr knapp mit den Objectives, die wir uns setzen können.

0:18:55 Marco

Das wird nie weggehen.

0:18:57 Teilnehmer

Ja, wahrscheinlich.

Im Nachhinein habe ich mal gelesen, dass du meintest, dass man sich die OKRs auch eher setzen soll, wenn man eher einen Prozess oder ein Produkt optimieren will und dass man gar nicht so versucht, dieses gesamte Tagesgeschäft abzubilden.

0:19:20 Marco

Doch, schon. Man versucht, das Tagesgeschäft abzubilden, weil – genau wie du sagst – zu wenig Ressourcen für zu viele Ziele übrig. Wenn ich jetzt einen unspezifizierten Block übrig lasse und den irgendwie Tagesgeschäft nenne, dann habe ich eine Menge Ressourcen auf irgendetwas gewettet, wo ich nicht weiß, was dabei herauskommt. Das ist ein sehr schlechtes Investment.

Also, du musst spezifizieren: Was will ich denn bei diesem Zeug, das Tagesgeschäft heißt, raushaben? Dann kannst du daneben schreiben, wie viel glaubst du, musst du reinstecken. Sprich: Wie viel Personentage, wie viel Cash, wie viel was auch immer. Wie viel Aufwand und Energie musst du da reinstecken. Dann kannst du die Entscheidung treffen, ob’s okay ist oder ob es eine gute Idee ist, das zu verfolgen oder ob du lieber was anderes machst. Solange du nicht sagst, was rauskommt und du dir keine Gedanken darüber machst, wie viel Aufwand es ist, wird es deine Zeit fressen. Aber du weißt im Nachhinein, ob es eine coole Idee war, aber du hast vorher ja nicht aktiv entschieden.

Demzufolge würden wir schon sagen: Du musst versuchen, alles als Ziel zu formulieren, dann die Entscheidung treffen, ob es wert ist zu verfolgen. Der Trick bei dem „Hey, so viele Objectives sind nicht mehr verfügbar“ ist ja, dass du nicht sagst: Ah, dann packe ich noch ein paar Os dazu, oder: Hey, die anderen Firmen haben mehr Os als ich. Sondern es geht darum, dass es eine künstliche Verknappung ist. D.h., es limitiert sich und folglich musst du dich im Vorfeld entscheiden, was wichtiger ist: Will ich A machen oder will ich B machen. Oder will ich, dass lieber A rauskommt, oder dass lieber B rauskommt. Das ist ja sozusagen der „heilsame Trick“, dass du gezwungen wirst, dich zu entscheiden, was dir wichtiger ist.

Und selbst von den fünf Dingern und den zwanzig Key-Results kommt ja die Hälfte nicht da an, wo du willst, dass sie ankommen. Wenn du jetzt noch welche dazu packst, kommt mehr als die Hälfte nicht da an, wo du willst, dass sie rauskommen. D.h. schlussendlich, je mehr Sachen du versuchst da reinzupacken, desto grösser ist die Wahrscheinlichkeit, dass du die Entscheidung dem Zufall überlässt. Und das ist das Gegenteil von dem, was wir wollen, nämlich aktiv Investment-Entscheidungen zu treffen und die Ressourcen auf die richtigen Pferde zu setzen.

0:21:43 Teilnehmer

Und das ist dann aber kein so ein „Evergreen“, wie wenn man sagt: Okay, wir wollen halt Aufträge machen, also müssen wir halt einfach, das zu machen ist ja unser Business. Aber man muss das dann immer irgendwie so umformulieren, dass man etwas Bestimmtes damit erreichen will.

0:21:58 Marco

Naja, „Aufträge machen“ bedeutet ja „Geld verdienen“. Jetzt kannst du ganz schön Geld verdienen oder du willst reich werden. Das wird ja nicht sonderlich spannend. Vielleicht für den, der am Ende jede Menge Geld verdient hat, aber für den Rest nicht. Und vor allen Dingen weder für den Kunden, noch für den, der es machen muss, also den Mitarbeiter.

Also muss ich es ja auf eine inhaltliche Ebene überführen und sagen: Was ist denn hier der Auftrag? Wann ist denn der Auftrag erfolgreich? Sind wir und die anderen dann zufrieden? Wenn ich das inhaltlich habe, kommt hinten raus zufällig auch Geld. Wenn ich das nicht verstanden habe, dann kommt da auch kein Geld raus und schon gar kein Gewinn.

Folglich ist es total heilsam herauszufinden, was eigentlich das Ziel ist und was ist inhaltlicher Erfolg. Wenn ich das verstanden habe, dann kann ich damit wahrscheinlich auch erfolgreich Aufträge abwickeln. Aber ich muss es halt inhaltlich verbal erstmal ausdrücken, worum es eigentlich geht. Außer, wir können am Ende jemandem eine Rechnung schreiben, die kannst du erst schreiben, wenn du etwas anderes erfolgreich gemacht hast.

0:23:10 Teilnehmer

Ja. Dann würde man quasi im Idealfall schreibt niemand Stunden auf, die nichts mit OKRs zu tun haben, oder? Es müsste eigentlich…

0:23:18 Marco

Das wäre die Reihenform, dass niemand was anderes macht, außer den Sachen, die dem OKR-Set zuträglich sind. Natürlich wirst du sowas wie „Reiskostenabrechnung“ oder solche Sachen haben. Die Teilnahme am öffentlichen und privaten Leben erfordert auch schon einen gewissen Zeitanteil. Aber darüber hinaus sollte alles, was du an ernstzunehmenden Anstrengungen unternimmst, in die Richtung gehen.

0:23:50 Teilnehmer

Okay. Gut. Alles klar, danke.

0:23:53 Marco

Gerne.

Dann XY.

0:23:59 Teilnehmer- Frage: Wie bringe ich Budget-orientierte Manager dazu anzufangen „Top-Down“ zu denken und OKRs zu definieren?

Ja, hallo. Ich bedanke mich zuerst für deine Zeit.

0:24:03 Marco

Sehr gerne.

0:24:05 Teilnehmer

Ich habe ganz viele Fragen – ich kürze es jetzt mal auf eine komplizierte herunter, damit die anderen auch noch dran kommen.

Ich habe grad das große Vergnügen, in einer großen Organisation, in einem großen Unternehmen bewege ich mich grad in der IT und räume grad so ein bisschen in den Projektprozessen auf. Und parallel kommen die jetzt herein und sagen: Wir wollen OKR einführen, was ich für eine total super Idee halte. Ich merke grad, wie schwer die sich tun, weil es eine rein Budget-getriebene Organisation ist. D.h., bisher haben die eine Jahresplanung gemacht und alle Manager – das sind 15 an der Zahl – haben sich dann für diese Budgettöpfe, die irgendwie strategisch ausgerichtet sind, beworben.

Die größere Herausforderung, wie ich das sehe und das finde ich jetzt total spannend, ist: Wie bekomme ich die jetzt dahin, dass die aufhören, für sich selber zu denken und nur Budgets mit irgendwelchen Überschriften abzugreifen, sondern wie bekomme ich die eigentlich dahin oder sie sich selber dahin, dass sie erstmal anfangen „Top-Down“ zu denken und die OKRs zu definieren. Das ist ein riesiger Change im Kopf, den die vor sich haben, und die sind natürlich in so einer großen Organisation, da gibt es unfassbar viele politische Spielchen und Quertreiber, die natürlich die Menschen in diese Verhaltensmuster hineintreiben.

0:25:27 Marco

Das ist so. Das ist eine gute Frage, aber keine leichte Antwort.

Naja, das ist wie wenn du einen Psychologen fragst, ob er mal kurz erklären kann, wie man bei der Psychotherapie zum Ergebnis kommt. Das ist etwas komplexer.

Wie du gesagt hast, ist das ein massiver Change-Prozess und der läuft auf drei Ebenen.

Die erste Ebene ist: Du musst das Framework verstehen. Also: Was sind die Regeln. Was sind die OKR-Regeln, die für uns gelten. Nicht, dass jeder irgendwas im Internet googeln kann, sondern es gibt EINE Regel, die für das ganze Unternehmen gilt.

Die zweite Ebene ist: der Content-Layer. Aus den verfügbaren Zielen die sinnvollsten nächsten Ziele heraus zu diffundieren. Das geht mit Logik. Basierend auf Strategien ergibt sich die Logik, wo ich am wenigsten Aufwand habe und den höchsten Ertrag. Vermutlich. Das ist noch der logische Layer, den kann man noch mit schlauem Nachdenken kriegen.

Die dritte Ebene ist: er emotionale Layer. Das ist diese ganze „Mindset-Geschichte“. Da wirst du feststellen, wie du soeben gesagt hast, dass Politics (?) und diese ganzen Sachen in solchen Prozessen in Teilen einen viel größeren Impact spielen als der logische Layer.

Unsere Erfahrung ist, du musst erstmal drei Dinge herstellen: Du musst eine Unzufriedenheit mit der Ist-Situation haben. Also irgendjemand müsste auf die Idee kommen: Komisch, so, wie es gerade läuft, läuft es wahrscheinlich nicht optimal.

Das zweite, was du brauchst, ist ein Bild der Zukunft, wo jemand sagt: Wenn es so wäre, wäre es total cool. Ich muss ein gemeinsames Bild von „Wohin verändern wir uns eigentlich?“ haben und „Wollen wir das überhaupt?“. Dafür brauchst du den Buy-In vom Management-Kreis, die sagen: Ja, Veränderung ist anstrengend, aber wenn wir das hier erreichen würden, dann wäre es ja total cool.

Das dritte, was du brauchst, ist ein glaubwürdiger Weg von A nach B. Also, es muss jemand glauben: Ah, super, wenn ich mich auf die Reise mache, komme ich auch hinten an. Könnte anstrengend werden, aber es lohnt sich zumindest. OKRs kann der Weg von A nach B sein, weil es ein super Katalysator ist, dir immer wieder vor die Füße zu spielen.

Wenn du dich an das erste Layer – nämlich das Framework – hältst, macht der zweite Layer relativ transparent, was du alles machen könntest und was du davon alles machen solltest. Wenn du feststellst, dass von den Sachen, die offensichtlich als nächstes gemacht werden sollten, nicht zwingend viele gemacht werden, wird auch relativ schnell deutlich, dass das Problem nicht im zweiten, sondern im dritten Layer – also in dem Mindset, Politics, was auch immer – ist. Und durch höhere Iterationen, also durch das immer wieder Durchlaufen dieser Sachen, kannst du dann ein Stück weit in den Dialog eintreten: Lass doch mal gemeinsam herausfinden, wenn uns das Framework jetzt gezeigt hat, dass nach A und B logischerweise C käme, wir aber D, E oder F machen. Können wir doch mal rausfinden, woran das liegt. Welche Strömungen treiben uns denn dahin?

Damit kriegst du über den Zeitverlauf eigentlich eine ziemlich gute Awareness, aus welcher Ecke und was so die Themen sind, die uns dazu treiben, andere Dinge zu machen, als wir eigentlich gerade machen sollten. Oder wo man als Gruppe darauf guckt und sagt: Es macht doch total Sinn, dass wir jetzt C als nächstes gemeinsam machen, aber in dem Budget-Topf, was auch immer, hat jemand eine Idee für F entwickelt und die zieht er einfach durch.

Dadurch, dass das alles transparent ist und im iterativen Diskurs findet der Austausch dann langsam statt und der Reflexionsprozess löst es langsam auf, sodass du in die Veränderung kommst. Aber das ist auf jeden Fall eine Reise und dafür brauchst du auf jeden Fall die Tickets von allen Mitreisenden, also, die müssen Lust haben, sich auf diese Reise zu begeben und sich darauf einzulassen.

Rein technisch gesehen hast du zwei Fronten. Das Eine ist: „Rolling Forecast“ passt besser zu einem iterativen System wie OKRs. Also, um nicht zu sagen: Ich plane jetzt mal, was du nächsten Oktober ausgeben wirst und was du damit machen wirst. Sondern: Ich plane immer auf einem Horizont von 12 bis 18 Monaten, aber immer von dem Hier und Jetzt. Also bin ich immer mit einem Zeitabstand von drei Monate an der aktuellen Planung dran, habe aber 12 bis 18 Monate Sicht nach vorne, sehe die Auswirkung und kann das adaptieren. Gleichzeitig kann ich die Sachen dann auch inhaltlich auf dem OKR-Framework umschichten und kann sagen: Wir entwickeln uns eher in die Richtung, weil wir festgestellt haben: Hey, das performt viel besser. Dann sollte man auch das Budget in die andere Richtung nachziehen, denn ich habe ja was gelernt. Das ist wohl der eine Teil, der dazu passt.

Wenn du noch nicht da bist, kannst du natürlich sagen: Jetzt haben wir ein Budget, ein festes Team, feste Rahmenbedingungen. Und dann wieder der Ansatz: Jetzt haben wir 10 Leute und 100‘000 € - was können wir in einem Quartal damit anstellen? Dann das sozusagen in OKRs zu übersetzen, ist ja Teil der Reise, bevor du in der vollen agilen Welt bist, wo sich auch der Finanzprozess angleicht.

0:31:20 Teilnehmer

Vielen Dank erstmal. Ich brauche trotzdem das ganze Management-Team, das sich auf die Ziele einigt, sonst wird es nicht funktionieren.

0:31:31 Marco

Das ist das, wie es am schnellsten funktioniert und wie es mit am wenigsten Reibung funktioniert. In der Praxis sehen wir ganz oft, dass jemand sagt: Wir müssen zuerst einen Leuchtturm haben.

0:31:43 Teilnehmer

Grad heute gehört.

0:31:45 Marco

Ja, meistens ist der Leuchtturm leider nicht allein auf einer Klippe und kann machen, was er will, sondern alle zerren dann irgendwie doch an den Ressourcen des Leuchtturms rum. Damit ist er nicht von den anderen „entkoppelt“. Wenn es ein wirklich „autarker“ Bereich wäre, dann könnte man damit schon etwas simulieren. Aber gerade wenn es funktionsübergreifende Abhängigkeiten gibt, dann ist es natürlich total heilsam, wenn die OKRs dir diesen Priorisierungsprozess und sozusagen mit Alignement über die verschiedenen Abteilungen, und damit auch die Engpässe an den Schnittstellen abnehmen. Da ist das sinnvollste, dass man die gesamte Breite dazu nimmt, damit das ja seine volle Kraft entfalten kann.

0:32:33 Teilnehmer

Okay. Super, vielen Dank erstmal.

0:32:36 Marco

Gerne.

0:32:43 Teilnehmer-Frage: Wie funktioniert das genau mit der Verankerung im Falle von crossfunktional Alignement?

Hello. Ich hätte zwei Fragen und kann gerne zugunsten der anderen auf eine verzichten. Ich mache schon mal Triage.

Also, ich habe mir erst deine Videos ausgiebig angesehen im Nachgang zu unserem Workshop im Dezember. An einer Stelle habe ich da nicht begriffen, wie es geht. Und zwar, wenn es drum geht, die Kosten des crossfunktional Alignement, also z.B., wenn ich in einem Departement die Ressourcen von einem anderen brauche. Wenn es so Richtung 60 Tage geht, dann sollte ich sie im anderen verankern, wenn es nur Meetings sind, muss es nicht zwingend verankert sein. Ich muss gestehen, ich habe es noch nicht ganz kapiert, was „verankern“ bedeutet. Wie sieht es dann in den Key-Results aus.

0:33:32 Marco

Wir haben so eine Excel- oder Google Sheets-Vorlage, da gibt es zwei Spalten. Die eine ist eben: Die andere Abteilung hat auch ein Ziel dazu, also, die haben auch ein Key-Result und sagen, ich will das auch. D.h., du kannst von der anderen Abteilung erwarten, dass die sich selbstständig in diese Richtung bewegen, weil sie ein eigenes Interesse bekundet haben, hier etwas zu erreichen.

Wenn du jetzt zu mir kommst und sagst: Hallo, da musst du mal deinen Input liefern oder da musst du mal irgendwie drauf schauen. Das sind so ein paar Meetings. Aber so wirklich treiben musst du es nicht. Dann ist es eher diese Supportfunktion. Dann habe ich mit meinem Team kein eigenes Key-Result dafür, aber wenn du kommst und sich das in einem gewissen Rahmen hält, werde ich dir zur Verfügung stehen und dir dabei helfen, das zu erreichen. Das ist erstmal die grobe Unterscheidung.

Wir haben so eine Faustformel, die besagt: Wenn es 1/20 deiner Ressourcen, die du in diesem OKR-Set vertrittst, übersteigt, dann solltest du zwingend ein Key-Result haben, weil es sonst ein massiver Impact ist, den du irgendwo leisten müsstest, aber nirgends dokumentiert hast. Wenn du 1/20 deiner Ressourcen auf ein Thema setzt, solltest du auch so intrinsisch sagen: Hey, ich will hier selber was erreichen.

Das ist so eine Faustformel, um zu dokumentieren, dass du ab einer gewissen Größe ein Eigeninteresse hast. Das kannst du dann natürlich in dein eigenes OKR-Set aufnehmen und verankern und damit treibst du es auch selber. Damit ist es auch ressourcenmäßig sichtbar. Du guckst da durch und sagst: Ja, stimmt, das andere Thema kam jetzt von der Abteilung von XY, aber na gut, ich glaube, es macht total Sinn und wir machen das und deshalb haben wir ein eigenes Key-Result. Dafür muss ich dann etwas anderes hinten runterfallen lassen, weil es sonst zu viel wird.

Deswegen kommt das in dem Workshop in den Diskurs. Jemand hat eine Anforderung an dich, ihr habt vorher so ungefähr grob festgestellt, wie groß das Thema für dich eigentlich ist. Oder du kennst die Anforderungen und kannst für dich selber einschätzen, wie groß das Thema in etwa ist. Dann kannst du sagen: Super, wir machen das, ich nehme es als Key-Result auf oder es sind ein paar Meetings, ich bin dann dabei, aber erwarte nicht von mir, dass ich dich frage, wann das Meeting ist, weil ich daran kein Eigeninteresse habe.

Das ist sozusagen mal der grobe Rahmen, wie sich dieses crossfunktionale Alignement eigentlich ganz gut einrüttelt, damit du schnell in den Diskurs kommst.

0:36:23 Teilnehmer

Vielen Dank, es wird jetzt klarer. Vielleicht kann ich an einer Stelle noch ein bisschen konkreter werden, um die Problemsituation noch etwas zu beschreiben. Wenn wir jetzt zwei Teams, zwei Departements haben, das eine ist das Projektmanagement-Team, das ist das Team, das bei Kunden ist, das andere ist das Produktentwicklungs-Team, also die Software-Entwickler.  Also kann der hier ja sein Projekt nur umsetzen, wenn hier ein Produkt entstanden ist oder wenn hier an einem Produkt entsprechend gearbeitet wird. Damit ist es per se natürlich so, dass dieses Produkt gemacht werden muss und als ein entsprechendes Key-Result in der Produktentwicklung auftauchen müsste?

0:37:06 Marco

Theoretisch, ja. Wenn es so ist, wie du sagst, dann sollte es ein Key-Result haben, damit es „sichtbar“ ist. Ob das Produkt-Team das machen muss, hängt davon ab, was die sonst noch so haben.

0:37:24 Teilnehmer

Okay, ja, das ist natürlich ein…

0:37:27 Marco

Also, wenn ich zehn bessere Produkte habe, dann musst du in deinem Projekt-Team halt leider deinen Kunden sagen, dass sie sich noch drei Monate gedulden müssen oder vielleicht auch nie drankommen, weil wir Produkte haben, die irgendwo anders stärker nachgefragt, besser bezahlt, besser Probleme lösen, etc. Aber das ist ja genau das Thema: Das interne Produkt-Team lässt sich ja nicht von einem Projekt-Team steuern, sondern es braucht ein Produkt. Wenn du ein „Feature-Request“ hast, dann baue ich den als Product-Owner ein, wenn er Sinn macht, und nicht wenn du ihn mir sagst.

Wenn ich mit dem „Feature-Request“ noch drei andere Kunden glücklich machen kann, mache ich das vielleicht. Nur weil du sagst, du brauchst das ganz dringend, dann bist du in der Prioritätenliste noch nicht sonderlich weit oben, wenn man’s produktmäßig betrachtet. Das macht ja total Sinn, ich baue ja ein Produkt und eben kein Projektgeschäft. Wenn ich ein Produkt baue, versuche ich mit meinen Ressourcen Sachen zu bauen, die möglichst viel Nutzen stiften, an möglichst vielen standardisierten Stellen und nicht die Einzelinteressen eines partikularen, singulären Kunden zu befriedigen. Denn dann brauche ich kein Produkt, sondern dann mache ich Projektgeschäft. Das ist etwas ganz anderes.

0:38:44 Teilnehmer

Das stimmt. Das muss man sich schon vergegenwärtigen. Ergibt Sinn.

0:38:52 Marco

Cool. Frage damit beantwortet?

0:38:56 Teilnehmer

Ich werde jetzt damit in die Welt rausgaloppieren und in zwei, drei Monaten werde ich hier wahrscheinlich wieder auftauchen. Vielen Dank.

0:39.03 Marco

Sehr gut. Ich bin gespannt.

Der nächste…

0:39:12 Teilnehmer-Frage: Sollte bei der Einführung von OKRs zuerst jeder Mitarbeiter das Thema OKR verstehen oder wie gehe ich dabei am besten vor?

Ja, danke für die Gelegenheit. Ich habe folgende Frage, bzw. erstmal mein Hintergrund. Ich habe ein IT-Unternehmen. Wir sind IT-Dienstleister mit 46 Mitarbeitern und schon ein paar Jahre am Markt. Wir suchen seit Jahren immer wieder nach der richtigen Methode, um den vielfältigen Aufgaben und Zielen gerecht zu werden. Jetzt bin ich vor ein paar Wochen über OKR gestolpert und habe mich damit schon intensiver beschäftigt und wie du mitbekommen hast, deinen Podcast schon gehört. Ich finde es eine geniale Methode, die sehr, sehr passend für unsere Herausforderungen sein könnte.

Meine Frage fängt also ganz vorne an: Was ist so der richtige Weg, um OKR in einem Unternehmen einzuführen? Ich habe gesagt, 46 Leute, wir haben eine mittlere Führungsebene mit 12 Teamleitern, denen ich das persönlich noch gut vermitteln kann, denke ich. Und dann geht es einen Schritt weiter. In meiner Vorstellung müsste ja jeder im Unternehmen erstmal verstehen: Was ist OKR? Wie funktioniert das? Was haben die sich da wieder ausgedacht? Man muss auch sagen, das wäre nicht die erste Methode, die da irgendwie kommen würde, wir probieren immer viele Dinge aus.

Wie schaffe ich es, dass möglichst alle relativ schnell verstehen, was OKR ist, wie es funktionieren soll, was wir uns dabei gedacht haben, um das dann auch richtig leben zu können, um dann natürlich auch über die Objectives mitzudiskutieren und mitzuüberlegen, was die richtigen Key-Results ist und dann natürlich zum Handeln zu kommen und daraufhin zu arbeiten.

Und flankierend dazu die Frage: Ist das vielleicht abhängig von den richtigen Persönlichkeiten im Führungsteam, also muss ich mir die richtigen Leute aussuchen, die das ins Unternehmen reintragen, weil es ein Persönlichkeitsthema ist. Also mehr die initiativen Menschen oder gibt’s einen schlauen Weg, das unabhängig von der Persönlichkeit ins Unternehmen reinzutragen?

0:41:20 Marco

Ich versuche mal kurz zu sortieren.

Wir standen ja auch vor der Herausforderung, wie kriege ich es hunderten oder tausenden von Leuten vermittelt, was das eigentlich von mir will? Ohne dass jeder auf die Idee kommt: Ich google mal zusammen oder lese dieses Buch oder in dem Buch habe ich das gefunden, das gefällt mir besser und in dem fand ich das besser und hier habe ich noch einen Blogeintrag, der sagt mir so.

Deswegen glauben wir, es macht total Sinn, dass es in einem Unternehmen EINE Interpretation gibt und die wird durchgezogen. Anders kommst du nirgends an. Unser Weg ist das mit diesem Online-Kurs zu machen. Denn wie wir festgestellt haben, macht es total Sinn, es nicht nur einer Ebene zu erzählen und die erzählen es weiter, sondern es allen Ebenen gleich zu erzählen. Deswegen haben wir diesen Kurs entwickelt, damit man halt hingehen und sagen kann: Schau, wir sind jetzt rund 50 Leute, es funktioniert mit 500 aber genauso. Und auf der letzten Ebene hört ihr immer die gleiche Geschichte, wie auf der ersten Ebene. D.h., die Person auf der „untersten“ Ebene oder auf der Arbeitsebene hat die gleichen Regeln gehört und das wurde nicht so „Stille-Post-mäßig“ bis dahin übertragen und jeder hat es so ein bisschen angepasst wie er a) glaubt, es verstanden zu haben und b) glaubt, wie es vielleicht besser geht oder ihm besser passt. Sondern es ist halt EIN Regelwerk.

Damit stellen wir sicher, dass alle Personen in dem Unternehmen erstmal die gleichen Grundvoraussetzungen haben und auf die gleiche Sache blicken.

Nun zu deiner zweiten Frage. Wir nehmen die ersten beiden Führungsebenen und sperren die zwei Tage in einen Raum und sagen: Wir kommen hier erst wieder alle raus, wenn wir Ziele für die Company und für die einzelnen Departements, Abteilungen, Teams, wie du die auch immer nennen magst, haben. So, dass die Transparenz in der ganzen Gruppe auch auf allen Teams ist. Jeder weiß, was das andere Team macht und was nicht. Dann geht man hin und bricht es sozusagen inhaltlich runter, d.h. jede Führungsperson bricht dann die Inhalte auf sein eigenes Team oder auf ihr eigenes Team runter. Aber da sind ja sozusagen die Regeln und das Framework schon klar erklärt.

Damit nehmen wir so ein bisschen diesen Personality-Charakter heraus, weil dieser Framework-Layer ja schon erklärt ist. Und jetzt kommt mein Direct Report und wir definieren, wie wir die Ziele, die wir fürs Company-Set und für die Abteilung definiert haben, z.B. auf mein Team runterbrechen. Das müssen alle Führungskräfte ja gleichermaßen tun, weil es sonst unten nicht ankommt.

Zusätzlich haben wir die Erfahrung gemacht, dass es total heilsam ist, einen internen OKR-Champion zu haben, den du dann ausbildest, der so ein bisschen mehr weiß, als der Online-Kurs, weil der dient ja dem „Anwenderlevel“, dann gibt es natürlich noch so ein paar organisatorische Besonderheiten, Fallstricke, Mindset-Themen. Also hast du jemandem im Unternehmen, der OKR-Champion ist und der steht nicht innerhalb dieser beiden ersten Führungsebenen, sondern idealerweise daneben. Das ist dann so ein bisschen wie ein Berater. Ich kann zu dir kommen und sagen: Was ist denn mit deinem Ziel? Das hast du wohl nicht richtig verfolgt? Dann kannst du mir nicht sagen: Aber du deins auch nicht. Denn ich hab gar keins.

0:44:49 Teilnehmer

Und wie so oft im Leben sollte das nicht ich sein.

0:44:52 Marco

Idealerweise auf gar keinen Fall der Geschäftsführer oder die Geschäftsführerin, weil das dann zeitaufwändig ist und Zeit ist das letzte, was man da oben dafür aufwenden sollte. Sondern besser eine Stabstelle, irgendwie jemand, der einfach an der Seitenlinie steht und sagt: Hey, ich helfe euch so ein bisschen aus einer Coaching-Perspektive, eure Ziele besser zu formulieren oder besser klar zu machen.

Damit hast du eigentlich alles, was du brauchst. Also das Knowhow ist komplett einheitlich ausgerollt, die ersten beiden Führungsebenen haben sich ausreichend an den Inhalten gerieben und jemand von der Seitenlinie, der sagt: Hey, ich kann euch mal helfen, das hier besser zu formulieren, den Rahmen zu halten, dafür zu sorgen, dass die Termine da sind, dass es eine Location gibt, dass jeder weiß, bis wann er sich vorbereitet haben muss... Halt alles, was so ein Prozess eben erfordert. Und der dann auch an den Inhalten mitarbeitet und sagt: Klär mal, verstehe ich gar nicht so gut. Was habt ihr denn damit gemeint, das ist doch kein Ziel, das ist doch eher Input? Also, der sich an die Seitenlinie stellt und sagt: Ich gucke euch ein bisschen zu, ich stelle euch blöde Fragen und das führt dazu, dass die Qualität overall besser wird.

0:46:12 Teilnehmer

Okay. Und dann würde man wahrscheinlich in bestimmten Abständen mal wieder auf die Meta-Ebene gehen und gucken, wie wir die Methode eigentlich leben, wie funktioniert das eigentlich in den einzelnen Teams, um da auch ständig eine Anpassung und Verbesserung reinzubekommen, oder?

0:46:28 Marco

Genau. Das heißt, auf dieser Dreimonats-Ebene machst du Retros und Reviews. Also, auf der einen Seite siehst du dir an, was dazu geführt hat, dass wir die Ergebnisse erreicht haben oder nicht. Und auf der anderen Seite schaust du dir an, wie wir besser zusammen arbeiten müssen, wo der Prozess noch nicht so ist, wo wir uns nicht so an die Meetings halten, wo die Qualität nicht stimmt, und so weiter.

Dadurch, dass du das beides quartalsweise machst und immer iterierst, kriegst du langsam die Qualität nach oben.

0:46:59 Teilnehmer

Okay. Danke.

0:47:02 Marco

Hilft das?

0:47:04 Teilnehmer

Ja, danke.

0:47:05 Marco

Super. Danke.

Dann die nächste…

0:47:10 Teilnehmer-Frage: Wie sind eure Erfahrungen mit Entwickler-Teams, die mit anderen Systemen arbeiten?

Ja, hallo. Ich werde mal meinen Video auslassen und den Ton gleich wieder ausmachen, weil ich noch so einen kleinen Mitbewohner habe.

Ich bin bei uns quasi der OKR-Champion, bin aber erst im Mai wieder dazu gekommen und da hatten wir schon das getan, was du eben gesagt hast, was wir nicht tun sollen: Jede Abteilung ist so in ihre Richtung gelaufen und hat das so ein bisschen selber gemacht, wie er die OKRs versteht. In der Tat haben die Leute nochmal Sachen gegoogelt und ein Buch gelesen und haben jetzt ihre eigene Idee dazu.

Das wollen wir nächstes Jahr besser machen. Es hat schon ganz gut geklappt, doch jetzt wieder dahin zu coachen, dass sie alle ein bisschen eine ähnliche Qualität bekommen, vor allem was die Key-Results angeht. Aber ich habe so ein bisschen in unterschiedlichen Teams Schwierigkeiten, besonders – und das wäre meine Frage – was doppelte Zielsysteme angeht. Konkret ist das das Entwickler-Team, die mit Nasfam arbeiten, und sagen: Ein Dreimonats-Zyklus ist uns schon zu lang, wir arbeiten im Sprint. Das habe ich alles da drin, was soll ich denn da noch reinschreiben, das ist doch doppelte Arbeit. Ich habe mit meinen Basis-Scrum-Kenntnissen gedacht, vielleicht Epics oder irgendwas, wo wir uns verständigen können. Was gibt’s denn da speziell für Erfahrungen für wirklich sehr stark selbstgesteuerte, aber dadurch auch so ein bisschen losgelöst von dem sehr auf Produkte fokussierte Entwickler-Teams?

0:48:56 Marco

Das Problem ist glücklicherweise schon gelöst. Die Teams sind ja nicht selbstgesteuert und machen, was sie wollen, sondern sie folgen ja einer Strategie und einer größeren Vision oder Produkt-Vision. Demzufolge gibt es ja ein abgestimmtes Bild darüber, was ich idealerweise erreichen will und in welche Richtung das gehen soll. Und dann kann ich auf dieser Grundlage in einem Dreimonatszyklus fürs ganze Team sagen, was dabei herauskommen soll. Also das sind dann, wie du gesagt hast, wahrscheinlich auf der epischen Ebene, die Sachen, die das Team erreicht haben will und vor Kunden sozusagen die Nutzendimension, die dabei herauskommen sollen.

Dann macht es wenig Sinn, von dort aus auf die persönliche Ebene in OKRs zu gehen, denn das ist ja total richtig. Du hast ja zwei Systeme, die ähnliche Sachen versuchen zu tun, nur auf einem anderen Zeitrahmen. Deswegen, da, wo ein Scram-Team nach Scram arbeitet, definierst du für drei Monate OKRs, die definieren, was bei dem Produkt herauskommt. Dann darunter arbeiten die in Sprints von einer oder zwei Wochen, wo sie dann diese Sachen sozusagen mit Scram in die Tat umsetzen.  Und so könntest du’s auch andersherum bezeichnen, dass OKRs so etwas wie Scram auf Scram ist, sozusagen die Oberebene; andere Systeme nennen das dann Portfolioebene. Also, dass die Sachen nach den nächsten großen Bausteinen sortiert werden,  die drankommen und das definiert ja das OKR-Set. Und das versuchst du fokussiert in den drei Monaten mit den Scram-Iterationen dann in Storys zu übersetzten und abzuarbeiten.

0:50:47 Teilnehmer

Okay. D.h. ich müsste mich dann ja wahrscheinlich nochmal stärker mit dem Product Owner abstimmen. Das lag wahrscheinlich auch ein bisschen in der Thematik, er war von Anfang an kein Fan und sagte, warum machen wir das überhaupt und jetzt hat er sich lange überlegt, dass er das mehr mitträgt und so, wie du das jetzt erklärt hast, glaube ich, können wir uns jetzt darauf verständigen.

0:51:10 Marco

Weil auch der Rest der Organisation natürlich a) eine Transparenz braucht, was in den drei Monaten passiert und b) je nachdem, wie wirklich autark so ein Team ist und wie crossfunktional es aufgestellt ist oder ob es dann doch Abhängigkeiten zu anderen Teams oder von anderen Teams zu dem Produkt-Team gibt, muss man ja schon die Prioritäten aufeinander abstimmen. Man kann einfach in so einem komplexen System wie einem Unternehmen nicht machen, was man will. Sondern man muss sehen, was am meisten Sinn macht. Und das macht man mit OKRs, damit der Rest der Welt auch glaubt, dass das das sinnvollste ist, bzw. dass man alle Dimensionen in die Entscheidungsfindung einbezogen hat und am Ende das, was für das Gesamt-Unternehmen am sinnvollsten ist, rauskommt.

0:52:00 Teilnehmer

Okay. Genau diese Abhängigkeiten existieren und die da rauszustellen und mit Transparenz zu schaffen, ist auf jeden Fall das Ziel und was noch ein bisschen stärker wird schaffen müssen.

Vielen Dank, das hat mir sehr geholfen.

0:52:14 Marco

Gut. Danke.

Der nächste…

0:52:19 Teilnehmer-Frage: Woran richte ich die Strategie aus, wenn ich ja keine Jahresziele, sondern nur eine Vision habe?

Hi Marco. Ich habe für dich auch was Spannendes mitgebracht.

Wir beschäftigen uns grad wieder viel mit Strategie. Für mich steht noch die Herausforderung, wenn wir keine Jahresziele setzen oder außer der Vision keinen Zielpunkt haben - klar, eine Vision hat man, in die Richtung läuft man - woran richte ich die Strategie aus?

Wenn ich eine Strategie als „von A nach B kommen“ definierte und ich B nicht genau habe… die Strategie ist ja immer das „Wie“ zwischendrin. Wenn ich Jahresstrategie mache und wenn ich B jetzt in Form eines Jahresziels noch nicht konkret habe, wenn ich dem OKR-Framework nach euch folge, mache ich ja kein Jahresziel, von daher habe ich den Endpunkt nicht. Deshalb ist es für mich ein bisschen eine Herausforderung, das „Wie“ zwischendrin zu definieren, ohne den Endpunkt zu haben. Ist die Frage verständlich? Ich habe sie etwas kompliziert gestellt.

0:53:18 Marco

Ja, ich glaube, ich hab’s – falls nicht, können wir nochmal nachkorrigieren.

In unserer Welt gibt es ja kein Jahresziel, wie du sagst, sondern die Strategie beschreibt einen Vektor, der sagt, in welche verschiedenen Richtungen will ich denn meine Energie grundsätzlich investieren. Die sind alle zuträglich, die Mission zu erfüllen, um irgendwann die Vision Wirklichkeit werden zu lassen. Das ist ja eine zentrale Geschichte. Eigentlich haben wir ja die wesentlichen Erfolgshebel definiert und sagen: Diese drei, vier, sieben, acht, neun verschiedenen Strategien sind mit hoher Wahrscheinlichkeit die Sachen, die, wenn wir hier die Energie investieren, uns dazu bringen, unsere Mission zu erfüllen.

Demzufolge brauchst du keinen Endpunkt, weil dich alle der Sache näher bringen. Du bist jedoch durch deine Ressourcen limitiert. Wenn du auf allen Strategien bestmöglich delivered hättest, wärst du noch schneller Richtung Vision, aber so viele Ressourcen hast du halt nicht. Deswegen musst du anfangen, die Ressourcen variabel zwischen den einzelnen Strategien zu verteilen. Dann kommst du halt immer soweit du kommen KANNST. Je nachdem, wie du halt innerhalb des Quartals deine Ressourcen aufteilst. Nur, weil du sagst: Ich würde gerne in dem Jahr auf der und der Strategie-Ebene da, da und da sein, würdest du ja der Gleichung bestimmte Fixpunkte zuordnen und dann müsstest du mit den Ressourcen flexibel sein, damit es aufgehen kann. Das ist ein rein mathematisches Phänomen. Du kannst nicht beide Sachen fix lassen. Also kannst du nicht sagen: Ich lasse die Ressourcen fix und ich will fixe Ziele haben. Das kann ja nicht aufgehen. Denn mit hoher Wahrscheinlichkeit irrst du dich, wie viel Ressourcen du brauchen wirst, um einen bestimmten Punkt zu erreichen, entweder zu wenig oder zu viel. Aber stimmen tut es eigentlich selten. Folglich muss man variabel investieren und sagen: Worauf investiere ich denn dieses Quartal am meisten und dann komme ich halt auf diesem Vektor das größt mögliche Stück voran. Wo du am Ende des Jahres bist – mehr ging nicht. Oder das hat sich dann über das Jahr herauskristallisiert.

Wichtig ist aber, diese Verhältnismäßigkeiten voneinander zu haben und zu sagen: Wenn ich diese fünf, sechs, sieben, acht verschiedenen Vektoren definiert habe, dann kann ich ja immer in dem OKR-Quartal hingehen und entscheiden, auf welchen dieser Vektoren will ich denn jetzt alles setzen, am meisten setzen, viel setzen, gar nichts setzen, um dann meine Ressourcen zu verteilen.

War auch eine komplizierte Antwort, aber…

0:56:13 Teilnehmer

War für mich sehr verständlich. Das Einzige, wo ich noch kurz nachhaken möchte, ist: Legst du Strategien auf gewisse Zeiträume an?

0:56:22 Marco

12 bis 24 Monate. Und danach ziehst du sie halt immer nach, wenn du halt wieder etwas gelernt hast und dann feststellst, die App löst überhaupt nicht unser Problem. Dann ist möglicherweise die Strategie, eine App herauszubringen für bestimmte Sachen einfach nicht zielführend und dann meldet man sie auch wieder ab und sagt: Gut, war eine nette Idee, aber kriegen wir nicht hin.

0:56:51 Teilnehmer

Danke, hat mir auf jeden Fall weitergeholfen. Gerade das mit den Vektoren.

0:56:55 Marco

Cool, danke.

Dann XY.

0:57:00 Teilnehmer-Frage: Wie durchlässig oder nicht durchlässig sollten die Teams, im Vergleich zur Aufbaustruktur sein, die an den OKR-Sets arbeiten?

Ja, Hi erstmal. Vielen Dank jetzt schon für die super hilfreichen Tipps und Infos.

Ich habe nochmal eine Frage. Ich arbeite in einer Digital Innovation Unit im Public Sektor, wir sind so ungefähr 50 Mitarbeiter, in fünf Teams aufgeteilt und haben vor ein paar Monaten auch mit OKR begonnen. Nach dem Motto „Wir machen es jetzt mal einfach“. Und da haben wir entsprechend vieles ausprobiert, jetzt auch schon vieles gelernt.

Meine Frage ist insbesondere zu den Teams, die praktisch an einem OKR-Set letztendlich mitarbeiten. Wir haben es in einem ersten Schritt einfach so gemacht, dass wir die OKRs im Grunde genommen teamweise definiert haben und dann aber die OKR-Sets nicht in den jetzt schon, was die Aufbauorganisation hergibt, in den Teams bearbeitet, sondern letztlich auch so ein bisschen, um ganz bewusst nicht so diese Silos gleich entstehen zu lassen, auch über die Teams hinweg daran gearbeitet. Was – glaube ich – erstmal viel Hindernisse mit sich gebracht hat und eben auch keine klare Struktur. Dementsprechend wäre meine Frage: Wie durchlässig oder nicht durchlässig sollten denn die Teams sein, die an den OKR-Sets arbeiten im Vergleich jetzt zu der Aufbaustruktur, die in der Organisation sowieso schon da ist.

0:58:26 Marco

Ich versuche nochmal mit anderen Worten zu sagen, was die Frage war, was ihr versucht habt. Ihr habt einfach OKRs in den Raum gestellt und gesagt, da können jetzt mehrere Leute dran mitwirken und woher die kommen, ist erstmal unerheblich. Trifft das den Punkt?

0:58:40 Teilnehmer

Ja, genau so.

0:58:43 Marco

Okay. Die Grundidee von diesem ganzen Squat, Agil, was auch immer, ist ja eine möglichst kleine Truppe, die sich kennt und schätzt, verfolgt eine Mission und wird dabei nicht gestört.

Das ist die Geschichte, die es zu erzählen gilt. Das ist sozusagen das Guiding Principle, was du versuchst zu erreichen. Wenn du jetzt sagst: Ich stelle dir mal ein Ziel hin und ihr bedient euch, feel free – jeder kann da mitmachen, dann hast du ja das genaue Gegenteil erreicht. Also, es ist beliebig groß, ich kenne die anderen nicht, ich vertraue den anderen möglicherweise auch nicht, ich weiß auch nicht genau, welcher was macht, aber wir machen alle irgendwas. Aber ich werde dauernd gestört. Also das ist prinzipiell vom gedanklichen Aufbau das Gegenereignis zu dem, was wir versuchen zu erreichen.

Um deine Frage konkret zu beantworten: gar nicht durchlässig!

Wenn du den Squat-Begriff mal anschaust, heißt es ja: Das ist eine spezialisierte Einheit. Manchmal ist es eine Spezialeinheit. Die können bestimmte Sachen und die können sie ziemlich gut. Dann lässt man sie alleine und dann lösen sie das Problem auf unterschiedliche Arten und Weisen. Der Teil ist agil. Wenn die linke Tür nicht geht, seil ich mich vom Dach ab. Das ist agil. Nicht: Mal gucken, wer morgen sonst irgendwie neben mir im Bus steht und mit wem ich zum Einsatz fahre. Das ist nicht die Idee. Sondern das Team ist norming and storming, die kennen und vertrauen sich, die können sich gegenseitig einschätzen, die wissen genau, wer welche Fähigkeiten hat, wer welche Stärken hat, wer welche Schwächen hat, wie man miteinander kommunizieren muss, dass du schlecht drauf bist, wenn du keinen Kaffee hattest… all so Sachen. Dann können wir losfahren und ein bestimmtes, ernst zu nehmendes Problem ziemlich gut lösen, wenn uns keiner reinquatscht.

Das ist so das Grundprinzip. Dem würdest du ja – in diesem Bild bleibend – nicht widersprechen und du würdest auch nicht den Scharfschützen vom Dach abziehen und du würdest auch nicht sagen: Fahrt schon mal los, ich guck hier nochmal, wer hier irgendwie Lust hat, sich bei euch aufs Dach zu legen, vielleicht finde ich einen. Wird schon klappen.

Das macht ja keiner. Aber das ist das, was sozusagen in der modernen Interpretation von agilen Unternehmen irgendwie passiert. Man versucht, echte, ernst zu nehmende Probleme auf die Art und Weise zu lösen und wundert sich dann, dass a) keiner auf dem Dach liegt und b) unten entweder einer erschossen wird oder keiner mehr die Tür eintritt, weil der denkt, bin ich bescheuert? Was, wenn du draufguckst, ja eigentlich nachvollziehbar ist.

Also, ich würde sagen, das Team ist nicht durchlässig, sondern: Das Team ist das Team. Dann sagt das Team, welchen Scope es erreichen kann und dann lässt man das idealerweise auch in Ruhe. Das wäre die Grundidee von dem ganzen Aufbau.

1:01:48 Teilnehmer

Okay, das habe ich verstanden. Ich glaube, das hilft im Verständnis auf jeden Fall deutlich.

Vielleicht noch darauf aufbauend zu den Teams, du hast soeben auch dieses Squats als Sinnbild eben genannt. Ich habe in einem früheren Podcast von dir auch gehört, dass die OKRs Aufbaustruktur brauchen, an der sie sich orientieren. Ist es dann die Maxime, dieses Team muss tatsächlich alleine loslaufen können und muss es machen und weniger die Maxime, das an einem OKR-Set arbeitet, muss auch tatsächlich das Team sein, was in der Ablaufstruktur als Team geformt ist?

1:02:35 Marco

Da muss man jetzt aufpassen. Die Teams bilden sich nicht, um OKRs zu erreichen, sondern bestehende Teams definieren OKRs, die sie erreichen können. So rum funktioniert es - andersherum funktioniert es nicht. Ob das jetzt sozusagen im Organisationschart schon hinterlegt ist oder nicht, das ist unerheblich. Wichtig ist, dass die Struktur auch so bleibt. Wir sagen, um diese Personen machen wir jetzt einen Kreis und nennen sie Team. Dann passieren die Sachen, dass sie sich kennenlernen und wissen, was sie voneinander zu erwarten haben, dass sie sich auf der Werteebene irgendwie grün sind. Dann definieren sie, was dabei herauskommt. Wo du das im Organsiations-Chart aufhängst, ist per se erst mal egal und es ist auch egal, ob es crossfunktional oder funktional ist.

Die Grundidee ist natürlich crossfunktional. Du schickst nicht nur Scharfschützen zur Geiselnahme, die wird auf jeden Fall blutig enden, denn die können nichts anderes. Sondern, du schickst jemanden mit, der verhandeln kann – das ist die Idee von einem crossfunktionalen Team.

Solange wir alle Scharfschützen in einem Team haben, haben wir dieses – was wir vorhin gehört haben – crossfunktionale Alignement relativ hoch. Denn da muss ich mich mit den anderen Fähigkeiten „abstimmen“ und muss das immer versuchen, iterativ irgendwie hinzukriegen. Deswegen geht der Trend dahin oder, wie wir gesagt haben, das Idealbild sieht so aus: Eine kleine, schlagkräftige Truppe, die unterschiedliche Fähigkeiten vereint, kennt und vertraut sich und wird in Ruhe gelassen. Idealerweise sind die schon so gemixt, dass sie die Probleme lösen können. Wenn das noch nicht so ist, also noch funktional organisiert ist, dann ist das auch machbar, nur hast du dann halt diesen crossfunktionalen Alignement-Teil, dann müssen sich die unterschiedlichen Disziplinen stärker aufeinander einlassen und austauschen.

Was nicht funktioniert, ist, dass man sagt: Ich stelle mal ein Ziel in den Raum und dann baue ich ein Ziel drum herum und das auch noch jedes Quartal aufs Neue. Und dann sage ich: Aber das Ziel ist nicht so ein ganzes Quartal groß, sondern nur ein Drittel Quartal groß, also darf sich jeder zu drei Zielen in Teams zuordnen. Das ist keine agile Organisation – das ist Chaos. Es folgt zumindest nicht der Grundidee dessen, was man versucht hat, anzudrehen, als man dieses Guiding Principle definiert hat.

1:05:10 Teilnehmer

Ja. Vielen herzlichen Dank. Hilft auf jeden Fall, jetzt auch nochmal die Scharfschützen und die Verhandler zu sortieren.

1:05:18 Marco

Nicht, dass ich irgendwie als Militant irgendwie einsortiert werde – ich habe damit nichts zu tun, aber das ist ein schönes Bild und es macht gut klar, dass keiner die Türe eintritt, wenn keiner auf dem Dach liegt, um den Rücken frei zu halten.

Freut mich, danke.

XY

1:05:36 Teilnehmer-Frage: Wie kann ich OKRs für so etwas Abstraktes wie die Tätigkeit einer Redaktion einführen?

Ja, hallo. Vielen Dank schon mal für die bisherigen Einblicke. Ich kann direkt an den Kollegen anschließen und zwar dahingehend, an das, was du gerade gesagt hast.

Ich arbeite in einem Verlag, wo wir noch funktional organisiert sind und ich stehe so ein bisschen vor der Herausforderung, da ein bisschen ein Zielsystem aufzusetzen und bin da eben auf OKR gestoßen. Wir sind noch nicht mal am Anfang, sondern weit davor. Es ist ein recht spezifisches Problem, ich hoffe trotzdem, dass ich damit ein paar anderen noch helfe.

Bei uns ist es derzeit so, wir haben Abteilungen, da ist es relativ einfach, anhand von Kennzahlen beispielsweise OKRs zu definieren. Wir haben einen Vertrieb, wir haben eine Marketingabteilung, eine IT-Abteilung, wo sich Fortschritt relativ gut messen lässt. In Verlagen ist es aber natürlich so, wir haben eine Redaktion, die einfach als Aufgabe hat, im Grunde ein periodisch erscheinendes Objekt mit Inhalten zu füllen und wenn ich da jetzt fragen würde: Was sind denn eure Ziele, was ist euer Zielsystem, bekomme ich aktuell sehr abstrakte Antworten, wie „Wir wollen das bestmögliche Heft gestalten“. An Absatzzahlen kann man es natürlich auch relativ schwer festmachen, gerade im Printmarkt, der ja sehr rückläufig ist. Da stehe ich jetzt gerade ein bisschen vor der Herausforderung oder Frage: Wie schaffe ich es denn da, Ziele zu definieren, die sich in ein OKR-Set gießen lassen und ist OKR für so einen Fall überhaupt das richtige Mittel?

1:07:15 Marco

OKR ist auf jeden Fall das richtige Mittel. Dafür – aber nicht für alles. Dafür auf jeden Fall schon.

Die Sachen, die du gerade so ein bisschen als „einfach“ beschrieben hast, die würde ich mit einem Fragezeichen, bzw. Ausrufezeichen versehen. Denn ich glaube, das ist eine Stolperfalle, weil hier KPIs zu Grunde gelegt werden. KPIs sind keine Key-Results. Das KPI von 1 auf 1,2 zu tragen, ist auch kein OKR. Sondern sich zu überlegen, was ist denn mein inhaltliches Ziel, dass sich das KPI von 1 auf 1,2 verändert. Das ist die OKR-Diskussion. Demzufolge bist du natürlich total richtig in dem Feld, eine inhaltliche Diskussion zu führen und zu sagen: Wir wollen das bestmögliche Heft füllen. Dann ist erstmal die Frage: Wie könnte man „bestmöglich“ definieren.

Also „bestmöglich“ heißt nicht, ich habe den größten Absatz und ich habe auch nicht den größten Werbeetat damit in Summe eingefahren, weil das den Leser nur begrenzt interessiert. Also muss ich herausfinden, was denn die inhaltlichen Sachen sind, die dazu führen, dass jemand im Nachhinein sagt: Cool, das hat a) total Spaß gemacht und b) würde ich wieder lesen oder kaufen. Da habe ich wahrscheinlich meine KPIs und dann muss ich mir von Quartal zu Quartal die Frage stellen: Was sind denn jetzt die größten Wetten, die ich eingehen kann, damit ich diese Inhalte zusammen kriege? Oder was brauche ich denn so für Kategorien, wo muss ich denn spannende Geschichten herkriegen? Das gilt es dann, wirklich in OKRs zu übersetzen. Also, erstmal rauszufinden, was denn die Erfolgstreiber sind, was bewertet der Leser als lesenswert und Entertainment-haltig? Und wie glaube ich, dass ich das im nächsten Quartal anders umsetzen kann, als ich das zuvor gemacht habe. Denn wenn ich die gleiche Geschichte nochmal erzähle, wird er wahrscheinlich sagen: Na ja, es war beim letzten Heft spannend, aber kannte ich schon, ich bräuchte was Neues.

Das ist ja eine stark inhaltliche Diskussion, dafür eignet sich OKR ja hervorragend, um zu sagen: Hey, worauf wetten wir denn jetzt? Was wollen wir denn jetzt in diesem Heft produzieren?

1:09:35 Teilnehmer

Und wenn dann die Inhalte, also zum einen natürlich die Themen, die man setzen kann, das ist sicherlich etwas, das man mit OKRs ausstatten kann.

1:09:44 Marco

Gar nicht Themen. Also mir geht es nicht darum, ich brauche jetzt eine Story über die Modeschau in XY oder so… Darum geht es mir nicht, sondern was sind die Ziele, die ein Leser damit verfolgt? Oder was ist ein Ziel, das die Redaktion damit verfolgt? Ich muss eine Übersicht geben über die heißesten Reisetipps, wenn man wieder reisen darf oder so. Damit sich der Leser dann gut orientiert fühlt und sagt: Sobald ich wieder los darf oder kann oder will, habe ich jetzt hier schon eine Liste mit genau dem und dem, das muss ich anschauen. Eher aus der Richtung.

1:10:20 Teilnehmer

Ja. Und wenn ich dann viele solche, sagen wir mal tagesaktuelle Berichterstattung hätte, dann würde das im Umkehrschluss bedeuten, ich muss schauen, wie meine tagesaktuelle Berichterstattung gestaltet sein muss, damit der Leser sie spannend und interessant findet. Daraus dann wieder Ziele ableiten.

1:10:37 Marco

Genau. Was ist, sagen wir mal, der Unterschied zu News Commodity. Also News gibt es ja schon – wie unterscheide ich mich von der Commodity in News und was macht uns unique und wann bewertet das jemand als positiv und was sind die Sachen, auf die ich hier im nächsten Quartal setze.

Hilft das?

1:11:00 Teilnehmer

Hilft auf jeden Fall. Vielen Dank.

1:11:03 Marco

Super.

Gut, weiter mit XY.

1:11:11 Teilnehmer-Frage: Wie schütze ich mein Team davor, dass immer mehr Aufgaben aus der Linie hereinprasseln?

Genau. Hier ist XY. Erstmal vielen Dank für die ganzen Beiträge. Ich bin hier schon kräftig am Mitschreiben, denn da können wir einiges schon davon lernen.

Ich komme aus einem großen Konzernumfeld, habe aber auch gleichzeitig das Glück, in einem sehr gut funktionierenden, agilen Team der Product Owner zu sein. Ich habe auch viel damit zu tun, das Team gegen die Linie zu beschützen, das gelingt grad sehr gut. In unserem Bereich sind 60 Personen, fünf disziplinarische Teams und ungefähr vier agile Teams, es wird jetzt auch OKR eingeführt. Einige Fragen wurden schon beantwortet.

Die Frage, die so ein bisschen bleibt, ist, in dem Review, das so alle drei Monate stattfindet oder wie das heißt, Retrospektive… Wer sollte da idealerweise daran teilnehmen? Wir haben den großen Vorteil, dass wir, glaube ich, sehr gut die OKRs anwenden konnten, weil wir unsere Epics als Basis genommen haben. Deswegen konnten wir die in Null-Komma-Nichts runterschreiben. Alle waren erstaunt, wir haben gesagt: Naja, das funktioniert sowieso, wir machen das Refinement eh regelmäßig, kein Problem. Und jetzt merke ich schon, dass ich unser Team immer mehr gegen die Ziele aus der Linie verteidigen muss, wo auch immer mehr versucht wird, uns über so Cross-Alignements Aufgaben reinzudrücken. Ich glaube, du hast eine Ahnung davon, was ich grad meine.

Weiterhin war das Konstrukt bei uns wirklich so aufgesetzt, dass das Ziel-Alignement dann nur über die Linie erfolgt, wo ich mich grad vehement gewehrt habe und gesagt habe: Wir müssen als agile Teams halt da mit rein, zumindest in der Vertretung mit dem Product Owner. Damit wir eben gemeinsam mit allen, die diese OKRs definieren in die Abstimmung kommen.

Habt ihr Erfahrung, wenn man Abteilungen mit Linien, mit Projektteams, mit agilen Teams, die gemeinsam OKRs gestalten? Was ist da der beste Weg?

1:13:20 Marco

Ja. Also, ich hoffe nicht, dass ihr agile und Projektteams noch dazu habt. Je nachdem, wie man das definiert, könnte das eine Menge Chaos geben. Und hybride Organisationen, glaube ich, gibt es auch nicht. Also, gibt es schon, aber sie funktionieren nur begrenzt.

Man muss dem Grundprinzip wieder Rechnung tragen. Also: Eine wirklich kleine Einheit verfolgt ein Ziel und wird dabei in Ruhe gelassen und kann, was es braucht, um das Ziel zu verfolgen.

Das runtergebrochen auf das, was du gerade sagst, ist die Frage: Welchem Team gehören denn die Leute an? D.h., wer sagt denn eigentlich, was wir machen, also auch, was ich mache? Mit wem stimme ich das denn ab? Und ich hätte gern einen Ansprechpartner. Wo der ist, ist mir eigentlich egal, aber gib mir einen Ansprechpartner oder eine Ansprechpartnerin.

Was ja passiert, ist, dass dieses „Linie“ und „agile Team“ dann plötzlich eine virtuelle Matrix wird. Manche sehen das, manche nicht, aber unter dem Strich ist das eine Matrix. D.h., mehrere Leute ziehen an den gleichen Ressourcen und die werden nicht mehr, nur weil man stärker aus unterschiedlichen Richtungen daran zieht. Das KANN nicht funktionieren. Die Matrix war schon immer Quatsch und sie wird auch Quatsch bleiben. Ich habe das noch nie funktionieren sehen.

Jetzt kannst du gucken, wie löst das ein Spotify-Modell, wie löst es ein... Es sind alles die gleichen Grundideen: Es gibt ein Team, dem man angehört und da wird entschieden, was können wir tun und was können wir nicht tun. Welche Mission nehmen wir uns und welche nicht. Was tun wir dafür, um diese Mission zu erreichen. Das muss ich natürlich mit den Teilnehmern dieses Teams abstimmen, weil die müssen sagen: Ja, klar, kann ich und will ich. Und ich glaube auch, das klappt.

Dann gibt es noch eine lose Interessensgemeinschaft. Die sagt: Hey, wir können bestimmte Sachen ziemlich gut und ich kann dir sagen, wie man das und das Problem besser löst. Ja, cool, danke. Aber sag mir nicht, was ich zu tun habe, sondern erkläre mir grundsätzlich, wie man so ein Problem besser löst und ich kläre hier in meinem Team, was wir daraus machen.

 D.h. die einen definieren den Scope, also entscheiden über ihre Ziele und dann gibt es genau eine Verantwortungslinie. Die anderen sind eine lose Interessensgemeinschaft: Hey, wir treffen uns, von mir aus auch regelmäßig, wir stellen sicher, dass der Informationsaustausch da ist, wir stellen sicher, dass jeder weiß, was best Practice ist, das kannst du Gilde nennen, das kannst du Community of Practice nennen, das kannst du nennen, wie du willst. Aber die sind eine lockere Interessensgemeinschaft. Das ist wie eine Gewerkschaft, aber am Ende ist der Architekt dafür verantwortlich, dass der Maurer eine Mauer gebaut hat. Woher weiß der, wie man mauert? Na ja, der hat sich mit anderen ausgetauscht. Aber die Verantwortung, ob die Mauer jetzt grade wird oder rund oder was auch immer, trägt halt das Team und der Architekt als Product Owner. So würde ich da mal draufgucken.

Wenn jetzt der Gilden-Anführer ein berechtigtes Interesse hat, inhaltliche Ziele zu positionieren, weil es darum geht, wir müssen irgendwelche Qualitäten nach oben bringen oder was auch immer, dann ist das natürlich der sinnvollste Weg, dass der sich mit denjenigen Product Ownern abstimmt und sagt: Hey, bevor ihr fünf Features entwickelt, entwickelt mal nur vier und mit der Ressource, die dann übrig bleibt, machen wir Learning, Training, what ever, räumen unseren Zauber auf. You name it! Aber das ist dann zwischen den beiden Ebenen abgestimmt und auf das Team kommt eine abgestimmte Priorisierung, weil das die Leute entschieden haben, die das entschieden haben müssen und nicht „unlösbare Anforderungen“ auf ein Teammitglied oder einzelne Teammitglieder hinein prasseln. Das gibt nur Stress und Überforderung und blöderweise sind wir so konditioniert, dass wir versuchen, das auch noch zu erfüllen. Damit kannst du dich nur unglücklich machen. Oder krank, langfristig. Das würde ich gerne vermeiden.

1:17:53 Teilnehmer

Ja, vielen Dank.

1:17:56 Marco

Beantwortet es denn deine Frage?

1:18:00 Teilnehmer

Ja, doch. Ich kann das auf jeden Fall mitnehmen und ich sehe auch ganz positiv in die Zukunft, weil wir jetzt auch eine Person bei euch ausbilden lassen.

1:18:10 Marco

Dann sehe ich auch positiv in die Zukunft.

1:18:13 Teilnehmer

Danke.

1:18:14 Marco

Danke dir.

So, ich glaube, XY ist schon raus. Dann XY.

1:18:21 Teilnehmer-Frage: Wie schaffen wir es, die OKR-Zielsetzung Top-down und Bottom-up in einer begrenzten Zeit zu erarbeiten?

Hallo.

Die meisten Männerfragen wurden tatsächlich schon beantwortet, finde ich super.

Wir stehen jetzt grad vor der Situation: Wir sind ein relativ junges Unternehmen und wir sind in letzter Zeit schnell gewachsen. D.h., wir hatten vorher das Alignement zwischen der Geschäftsführung und den einzelnen Abteilungen. Die Abteilungen bestanden aber aus einer Person. Das war relativ straight forward.

Jetzt haben wir aber pro Abteilung mehrere Mitarbeiter und fragen uns, wie schaffen wir es denn jetzt, in den zwei Wochen, die wir für die OKR-Zielsetzung eingeplant haben, das tatsächlich einmal Top-down und dann wieder Bottom-up hinzukriegen.

1:19:02 Marco

Der Prozess ist eigentlich ganz einfach. Du versuchst, nur einmal zu diskutieren und das ist beim Runterbrechen. Aber du nimmst alle Meinungen mit beim hochkaskadieren. D.h., es gipfelt alles in diesem OKR-Workshop. Jeder Mitarbeiter, jede Mitarbeiterin formuliert seine bzw. ihre OKRs, dann wird es verdichtet auf Teamleiter-Ebene. Da wird es dann kurz vorgestellt. Vielen Dank für eure Vorschläge, ich habe das mal so aggregiert, ich würde mal damit ins Rennen gehen. Ja, okay, passt. D.h., dann kriegt die oberste Ebene lauter Vorschläge, dann kommt der OKR-Workshop, die großen Bausteine werden diskutiert und gerade gerüttelt. Dann wir das OKR-Set für die Company festgezurrt, die Abteilungs-Sets werden festgezurrt und beim Runterbrechen wird ausführlich diskutiert: Wenn das jetzt die zentralen Ziele sind, die wir verfolgen wollen – wie können wir das bestmöglich unterstützen. Also, wie können wir als Team, als Abteilung den größtmöglichen Beitrag dazu wählen. Dann wird das festgesetzt und verabschiedet und dann daran gearbeitet.

1:20:26 Teilnehmer

Okay, d.h., es sind nicht alle Mitarbeiter dann wieder mit den Unternehmenszielen beschäftigt, sondern das geht dann wieder über die Stufe Abteilung – Abteilungsziele.

1:20:36 Marco

Ja. Du willst ja eine Sache nicht machen, je nachdem, wie viele Stufen es sind, das ist ja in Teilen a) sehr abstrakt und b) will ich als Mitarbeiter zwar wissen, wozu trage ich denn im Großen und Ganzen bei, aber ich will es ja auch sehr konkret haben. Und der konkrete Teil steht auf meinem Zettel und das direkte Verhältnis muss ich ja in meinem Team sehen. Die anderen, mit denen ich sozusagen zusammen daran arbeite, machen die Gegenstücke, die dazu passen, was ich mache und das zusammen führt zu einem Gesamtergebnis. Wie das wieder auf das ganze „Puzzle“ einzahlt, muss ich zwar verstehen und auch sehen können, aber das muss ich ja nicht dauernd vor Augen haben. Denn ich gucke einmal auf den Gipfel und dann gucke ich den Rest des Weges auf den Weg, denn da liegen die Steine, über die ich stolpere. Also muss ich irgendwie das Hier und Jetzt gut im Auge behalten und das findet in meinem OKR-Set und dem von meinem Team und meinen Peers statt.

1:21:42 Teilnehmer-Frage: Wie nehme ich denn sinnvoll die Unternehmensziele als Abteilungsziele und die Abteilungsziele dann als Mitarbeiterziele?

Super.

Und meine zweite Frage wäre: Wie nehme ich denn sinnvoll die Unternehmensziele als Abteilungsziele und die Abteilungsziele dann als Mitarbeiterziele? Also laut diesem simplen Google-Prinzip, da mit dem Football-Team, nimmt man sich dann einfach ein Key-Result aus dem Unternehmensziel und macht das als neues Objective.

1:22:04 Marco

So einfach ist es leider nicht. 

1:22:07 Teilnehmer

Ja, genau.

1:22:08 Marco

Also, ich habe es noch nie hingekriegt, dass es so geklappt hat. Demzufolge musst du dir eine andere Frage stellen. Diese Zuordnung ist als N zu N-Zuordnung zu verstehen. Es ist eher die Flughöhe und wenn ich das Teamziel kenne, kann ich jetzt überlegen, welches Objective kann ich erreichen, das dem Teamziel und diesem Key-Result auf der Teamebene am meisten zuträglich ist. Das erreiche ich nicht, indem ich das einfach abschreibe, denn sonst habe ich ja das Gleiche, ich habe ja die Flughöhe nicht verändert. Sondern ich verändere die Flughöhe und gehe von der Team-Flughöhe auf meine persönliche Flughöhe und sage, welche Ziele ich erreichen muss, dass ich möglichst viele Key Results auf der Teamebene möglichst weit nach vorne pushe.

Ich muss sie also übersetzen und dann kommt etwas dabei heraus, was auch funktioniert. Und das schaffst du mit der Frage: Wie kann ich bestmöglich dazu beitragen, dass die Key-Results über mir so viel wie möglich und so groß wie möglich positiv beeinflusst werden?

1:23:18 Teilnehmer

Super, danke.

1:23:21 Marco

Gerne.

Dann machen wir noch ein, zwei Fragen… XY!

1:23:26 Teilnehmer-Frage: Wie schafft man es, OKRs in einer großen Organisation bis auf die operative Ebene einzuführen?

So. Ich versuche mich kurz zu fassen. Mehr geht leider nicht. Ich habe ein ähnliches Thema. Ich komme auch aus einem internationalen Konzern. Wir haben in unserem Bereich eine Transformation oder Change laufen und haben das Flight-Level-Modell von Klaus Leopold als Basis gewählt. Und da haben wir auch grad angefangen, mit OKRs zu arbeiten.

Wir sind aber im Moment quasi bei diesem OKR-Start-Level noch auf der obersten Ebene, also auf dem strategischen Flight-Level 3 und jetzt steht die Aufgabe an, wie wir das ganze durch die Organisation in Summe durchgebrochen kriegen. D.h., wir haben den Startpunkt gesetzt, haben aber im Moment noch die Schwierigkeit, dass die Einschätzung des Worklimits, das hinter diesen ganzen Themen steckt, auf den andern Flight-Level nicht sichtbar ist. Genauso wie das Problem, was am Anfang auch Paul erwähnt hatte, dass wir eben noch nicht alle operativen ongoing-Themen mit im strategischen Wort haben. Ich glaube, wir brauchen sie dort auch nicht alle.

Jetzt suche ich grade noch ein bisschen nach einer Methode oder einer Möglichkeit, wie ich so eine Systematik am besten in eine Organisation rein kriege, die aus 1‘500 Leuten besteht, die sich auch weltweit verteilen?

Hast du da einen Tipp?

1:24:50 Marco

Erstmal habe ich keine Ahnung von dem Flight-Level-System. Aber ich habe quasi eine Ahnung und wenn man unterschiedliche Flight-Levels annimmt, dann hätte das ja unterschiedliche – wie wir vorhin gesagt haben - „Flughöhen“. Die unterschiedlichen Flughöhen sind ja in den unterschiedlichen OKR-Sets abgebildet. Demzufolge sollte es daneben nichts geben, was auch was mit unterschiedlichen Flughöhen versucht abzubilden, sonst versuchen zwei Systeme, das gleiche abzubilden und das gibt erstaunlicherweise in der Regel immer Chaos.

Also hier muss man sich vielleicht das erste Mal schon entscheiden, ob man zwei Systeme braucht, die ähnliche Sachen versuchen zu lösen. Das ist mal wertfrei. Wenn ich das eine oder das andere als besser ansehe, dann sage ich, man braucht nicht zwei, die versuchen das Gleiche zu tun.

Wenn du den OKR-Weg gehen willst, dann hast du auf dem obersten Level Strategien, wie wir vorhin gesagt haben, Vektoren von 18-24 Monaten Perspektive, keinen Wegpunkt, respektive kein Ziel, was über drei Monate hinausgeht. Und dann sagst du einfach: Okay, was ist jetzt für die ganze Organisation auf dem obersten Level ein konkretes Ziel für drei Monate? Damit operationalisierst du eine Strategie, also einen Vektor, in ein Ziel, einem Wegpunkt für drei Monate.

Dann kaskadierst du’s runter und sagst: So, was kann jetzt Team A dazu beitragen, was kann Team B dazu beitragen, was kann Team C dazu beitragen? So kaskadiert sich das durch die gesamte Organisation runter. Das fokussiert sich auf drei Monate, man erreicht Ziele, man lernt etwas, man bricht das zurück, man reflektiert es auf das OKR-Set von der Company, man zieht Rückschlüsse auf den Strategie-Layer, passt da vielleicht was an, wenn erforderlich. Wenn nicht, fährt man sonst weiter und dann geht das Spiel von vorne los.

Das ist Operationalisierung von Strategien. Braucht man jetzt noch etwas dazu? Aus unserer Erfahrung nicht. Aber wenn ihr noch was habt, musst du halt gucken, dass das nicht irgendwie in einem Interessenkonflikt steht.

1:27:11 Teilnehmer

Das steht es glaube ich nicht. Ich finde es eher interessant: Du würdest diese Kaskadierung nach unten quasi in Workshop-Themen abarbeiten?

1:27:20 Marco

Na ja, die obersten zwei Ebenen auf jeden Fall, weil da so viel unterschiedliche Wahrnehmung und unterschiedliche Sachen drin sind, die man ausdiskutieren muss, damit man zu einem gemeinsamen Zielbild kommt. Dann sagt man: Ja okay, auf der obersten Ebene haben wir alle Perspektiven in Betracht gezogen, angehört, abgebogen und entschieden. Und das ist dann fix auf dem Company-Set. Von da aus bricht man’s runter. Weil man sagt: Die größten Entscheidungen haben wir jetzt ja getroffen. Und jetzt muss man von der jeweils darunter liegenden Ebene sagen: Was können wir als Team jetzt am besten tun, um das, was wir entschieden haben, zu erreichen?

1:28:07 Teilnehmer

Okay, danke dir.

1:28:09 Marco

Gerne.

Jetzt kommen wir zeitlich langsam ans Limit, aber zwei machen wir noch.

XY, bitte.

1:28:18 Teilnehmer-Frage: Wie gehen wir am besten damit um, dass wir einerseits Teamziele, andererseits aber auch Product-Owner einzelne Ziele haben. Zudem werden noch immer an einzelne Personen Boni ausbezahlt.

Ja, wunderbar. Das hatte ich gar nicht erwartet, hallo Marco.

Also, wir kommen so aus diesem klassischen System MBOs und in dem Team haben einige eine Bonuszahlung, andere nicht. Und wir haben dann auch OKR eingeführt, weil wir einfach festgestellt haben, dass es besser und transparenter ist. Man hinterfragt mit den Retros immer wieder alles und das läuft eigentlich auch ganz gut.

Nichtsdestotrotz ist so ein bisschen eine Sache aufgekommen, die dann auch schon angesprochen wurde. Wir haben Teamziele, auf die alle ziemlich gut mit einwirken können. Dann haben wir aber auch eher so individuelle Ziele durch Product Owners. Da ist so ein bisschen die Frage, wie kriegt man das zusammen, widerspricht sich das oder passt es so, dass Einzelne das haben? Denn auch hier ist ja immer noch so ein bisschen die Sache, es werden immer noch Boni ausbezahlt, sind aber nicht mehr so gekoppelt an diese individuellen Boni. Das ist halt so ein System, das da wahrscheinlich noch nicht so hundertprozentig reinpasst. Wie gehen wir am besten damit um? Das ist die Frage.

1:29:32 Marco

Klingt so ein bisschen nach „Wasch mich, mach mich aber nicht nass“. Am Ende mit Konsequenz.

Was würde man unterstellen, was bei MBO nicht so gut geklappt hat, was bei OKRs besser klappt? Die Zielerreichung auf Jahreszielen hat aufgrund der Unplanbarkeit der Jahresscheibe nicht so gut getroffen? Was jetzt nicht den jeweiligen Personen anzulasten war, die sich einfach nicht bemüht haben, sondern es war eher der Sachverhalt wahr, dass man die Zukunft nicht so gut abschätzen konnte, um gemeinsam sinnvolle Ziele zu definieren. Das vorausgeschickt, führt ja dazu, dass man in kürzeren Iterationen gemeinsam drauf blickt und sagt: Jetzt haben wir die Ressourcen zur Verfügung. Was machen wir da am sinnvollsten daraus? Das entscheide ich jedes Mal wieder neu und zwar gemeinsam. Demzufolge habe ich ja dauernd eine gemeinsame Zielvereinbarung, weil du und ich glauben, dass das das sinnvollste ist, was ich mit meiner Zeit in den nächsten drei Monaten anfangen kann.

Wenn ich dir jetzt Geld dafür gebe, was wir vor zwölf Monaten auf den Zettel geschrieben haben, habe ich ja eine Kraft, die den Vektor in eine andere Richtung lenkt. Dann brauche ich mich nicht wundern, wenn die Leute natürlich versuchen, dem hinterher zu fahren, weil es dahinten Geld gibt und hier möglicherweise nicht.

Also muss ich das Anreizmodell möglichst schnell anpassen und idealerweise dafür sorgen, dass die Zielvereinbarung alle auf dem gleichen Takt laufen. Also weg von dieser Jahresscheibe, weil wir eben nicht genau einsortieren können, was innerhalb eines Jahres passiert. Und das, was in den meisten Zielvereinbarungen passiert, ist nicht, dass jemand seine Ziele nicht erreicht, sondern dass zwei Parteien drauf gucken und sagen: Es hat doch keinen Sinn gemacht, dieses Ziel weiter zu verfolgen. Jetzt muss ich darüber entscheiden, was ich denn dafür kriege. Also, du kannst mich nicht dafür bestrafen, dass ich es nicht erreicht habe, weil wir ja beide der Meinung waren, dass es keinen Sinn macht, es zu erreichen. Demzufolge haben wir ja jetzt den Salat.

Das musst du einfach weglassen, weil es offensichtlich nicht so gut funktioniert hat, sonst würde man es ja weitermachen. Ich glaube, das ist so die Antwort, dass man sich dann auf ein Zielsystem einigt, das gleich taktet und dann versucht, das Anreizmodell nicht außerhalb des Systems zu stellen, sondern zu sagen: Hey, wir als Team müssen so und so viel von bestimmten KPIs erreichen, wenn wir das hinkriegen, ist alles gut, dann können wir uns unsere Gehalt leisten. Wenn wir mehr hinkriegen, dann teilen wir ein bisschen was davon und dann gibt es einen Teambonus oder ein Company-Bonus oder was auch immer. Und wir machen euch zu Mitunternehmern im weitesten Sinne. Das wäre das, was wahrscheinlich am besten funktioniert.

1:32:20 Teilnehmer

Aber das heißt auch, trotz allem kann man das durchaus in dem OKR-System so nebeneinander herlaufen lassen, dass wir halt durch die Product-Owner her starke, individuelle Ziele haben und auf der anderen Seite dann so Teamziele. Sagen wir mal so, bei gewissen Produkten können nur eine bestimmte Anzahl der Leute einzahlen, bei anderen Sachen können halt viele daran mitarbeiten.

1:32:48 Marco

Ich würde es so sehen, dass es ein einheitliches Zielsystem ist und du brichst dann halt runter, wer den größten Impact darauf hat. Dann habe ich vielleicht in meinem persönlichen OKR-Set mehr Impact auf das eine Produkt und du in deinem persönlichen mehr Impact auf die zwei, drei anderen Produkte.

Aber nicht, dass es Zielsysteme gibt, die nebeneinander bestehen, sondern, wir haben EIN Zielsystem und versuchen, die unterschiedlichen Ziele innerhalb von einem OKR-Set so zu gewichten, dass es passt.

1:33:20 Teilnehmer

Ja, okay, da kann ich auf jeden Fall etwas damit anfangen, in welche Richtung wir das treiben müssen. Vielen Dank.

1:33:29 Marco

Gut. Gerne.

Dann die letzte Frage, XY.

1:33:33 Teilnehmer-Frage: Wie nutzt man OKRs in einer Organisation, die sowohl in Gilden als auch in Projektteams organisiert ist, aus denen sich jeweils eigene Ziele ergeben?

Hi, guten Abend, schön, dass es noch geklappt hat.

Meine Frage wurde durch deine Antworten schon total verändert. Es geht nämlich um dieses agile Mindset und um das Chaos, das dadurch passieren kann. Wir sind eine agile Organisation, wir sind IT-Dienstleister und wir haben die Herausforderung, dass verschiedene Projekte verschiedene crossfunktionale Teams erfordern.

Ich bin jetzt eher so in einem Innovations-Consulting-Umfeld unterwegs und das ist etwas, worüber wir uns noch gar nicht so sehr im Klaren sind, wie unsere Produkte aussehen sollen. Die wollen wir weiter entwickeln – das ist eben „Gilde“ genannt. Das bedeutet aber, dass die Gilde nicht nur dazu da ist, dass wir uns fachlich austauschen, sondern sie hat so ihre eigenen Ziele. Sie möchte ein Marktsegment aufbauen, sie möchte von uns als IT-Dienstleister ein Produkt gestalten. Jetzt habe ich den großen Konflikt: Ich bin in zwei Projektteams, ich bin in dieser Gilde. Die Gilde plant im Moment, sich OKRs zu geben, um so ein Ziel zu erreichen, aber das ist natürlich ein kleiner Aspekt von meiner Arbeit. Dann sollte ich mir jetzt persönliche OKRs geben, was gibt sich dann diese Gilde? Hast du eine Idee, wie das zusammenspielen kann – abgesehen von einem Riesenchaos?

1:34:52 Marco

Also zurückgespult zu relativ nah am Anfang, ist da erstmal die Frage: Wir als Unternehmen sollten definieren, welche Probleme wir eigentlich wie lösen wollen und dann haben wir Produkte. Um ein Produkt zu entwickeln, brauche ich Ressourcen. Um jetzt in deiner Gilde zu sprechen – die Gilde hat eigentlich keine Produktverantwortung, sondern, die kennt sich nur ein bisschen aus. Wenn du jetzt aber sagst: Wir sind das Produktteam. Dann bist du nicht die Gilde, sondern du bist eben doch ein Produktteam, das versucht, bestimmte Produkte zu entwickeln und dafür brauchst du Ressourcen.

Also solltest du einen bestimmten, festen Pool an Leuten haben, die sich diesem Produkt widmen. Wir sehen immer dieses klassische Projektgeschäft und dann auch noch den Versuch, daraus Produkte zu machen und dann auch noch den Versuch, Personen zu entwickeln, und das in Projekten, wo die Leute mehreren Projekten gleichzeitig zugeteilt sind. Das endet immer im Chaos. Ich habe das selten anders gesehen und derweil die Ehre zu geben, OKRs sind dafür nicht die Lösung. Denn die Anforderung bleibt immer noch chaotisch.

Wenn ich das Modell, wie du das beschreibst, so fahren wollen würde, würde ich versuchen, die Ressourcenzuteilung irgendwie aus dem Poolmodell zu fahren und würde sagen: Wie viele Ressourcen brauche ich von einer bestimmte Eigenschaft, um ein bestimmtes Produkt zu erfüllen und würde dann die Zuteilung aus dem Pool so machen, dass die Anzahl der Projekte möglichst nah an Eins ist. Ideal wäre eins, möglichst nah an eins wäre maximal zwei. Alles darüber hinaus würde ich versuchen zu vermeiden. Das würde ich versuchen, IT-gestützt zu machen und aus dem Pool heraus bestimmte Tickets zu bauen, die sich dann – je nachdem, welche Eigenschaften man braucht – den Projekten zuordnen. Das hat aber mit der Produktecke von OKRs recht wenig zu tun.

Wenn ich versuchen würde, dieses Thema mit OKRs zu lösen und meine Firma so aufzubauen, würde ich eben überlegen: Was sind denn die Produkte, die ich an den Markt bringen will? Respektive, welche Probleme will ich eigentlich mit welchen Produkten lösen? Dann habe ich idealerweise ja eine Vorstellung von a) einem Problem und b) einer Produktlösung als Produkt. Danach überlege ich mir, wie viele Ressourcen ich brauche, um das Produkt erstmalig zu lösen, um es besser zu machen und wie viele Probleme ich in einem Quartal mit einem gegebenen Team davon lösen kann. Und dann würde ich mir Projekte suchen, die dazu passen.

Also, so machen wir unser Business. Das ist aber andersherum gedacht, das ist nicht aus einer Projektecke gedacht, sondern aus einer Produktecke. Was erfahrungsgemäß nicht klappt, ist, weiter in Projekten zu denken und OKRs darüber zu stülpen. Dann würde ich – wie gesagt – wieder so ein Poolmodell machen. Andernfalls würde ich versuchen, das Denkmodell zu ändern und in Produkten zu denken und daraus dann Produkte zu bauen. Ein Teil der „Problemlösung beim Kunden“ kann ja in so einem Produktteam stattfinden. Aber eben so viel, wie sich in einem Quartal davon lösen lässt. So kann z.B. ein Team drei Kundenprojekte dieses Produkts im Quartal lösen. Und dann gucken wir, dass die immer drei Produkte verkauft haben, damit sie dreimal diese Produkte an die Kunden bringen, um das Problem zu lösen.

Von der Denkweise her kannst du das langsam aufbauen, dann wird auch das Chaos gelöst, weil ein Team dann klar EIN Team ist und sie verantworten dann einen Bereich. Und wie jedes Produkt hat das dann auch möglicherweise Schnittstellen, also wenn sich Produkt A und Produkt B beim Kunden treffen, gibt es klar definierte Schnittstellen, aber wir wissen, wie der Prozess läuft. Und wir versuchen nicht alles, jedes Mal aufs Neue zu lösen.

Das ist aber ein massives Umdenken und Umbauen der gesamten Organisationsstruktur, bzw. auch Denkweise. Aber das habe ich schon mit vielen Dienstleistern, Agenturen usw. gemacht und es funktioniert extrem gut, aber es führt zu einem anderen Geschäftsdenken.

1:39:28 Teilnehmer

Ich habe das Gefühl, dass ich in meinem Kopf sozusagen einen Zwitter dazwischen habe. Ich habe auch schon die Vorstellung davon, dass wir eher ein Beratungsprodukt entwickeln. Das macht ihr ja auch, ihr entwickelt, wie man eine Zielsetzung macht, wie ich meine Organisation gestalte und dennoch, die gleichen Leute, die dieses Produkt gestalten, bieten dieses Produkt ja auch am Markt an. Das sind ja nicht verschiedene Personen.

1:39:51 Marco

Meine persönliche Erfahrung ist, es sind unterschiedliche Personen.

1:39:57 Teilnehmer

Ach was.

1:39:58 Marco

Ich habe es mit Organisationen getestet, die mehrere hundert Mitarbeiter auf den Themen haben und es war immer eine Illusion, dass aus den Projektteams Produkte wurden. Und es hat erst immer dann funktioniert, wenn du auf die Produkte dezidierte Ressourcen gesetzt hast und die auch nicht in dem Projekt verwurstelt wurden, sondern das waren Produktressourcen, das andere waren Projektressourcen. Wenn du anfängst, auch die Sachen ressourcenmäßig voneinander zu trennen, dann entwickelt es sich. Und das ist bei uns genauso.

1:40:28 Teilnehmer

Ach was. Cool. Vielen Dank. Das war eine unangenehme Wahrheit.

1:40:34 Marco

Kannst mal nachlesen, Stefan Wess von Empolis hat bei uns auf dem Blog so ein Interview gegeben. Da haben wir einige dieser Erfahrungen gemeinsam gemacht. Vielleicht ist das eine Inspiration, die so ein bisschen dein Problem löst.

1:40:52 Teilnehmer

Vielen, vielen Dank.

1:40:55 Marco

So. Dann danke euch für eure Zeit. Jetzt haben wir ein bisschen den Zeitrahmen überstrapaziert und leider nicht alle Fragen gelöst, aber dann bleibt uns noch ein bisschen was für die nächste Zeit. Ich hoffe, es hat allen Spaß gemacht und ein bisschen was gebracht.

Ich würde mich freuen, wenn wir uns an dieser Stelle wieder sehen.