AMA #48: Outcome vs. Output| OKR Tools | Top-Down OKR Einführung | Lager & Produktion im OKR Kontext
Luisa Lazarovici
In “Ask me anything about OKRs” Episode 48 haben wir uns mit der Frage beschäftigt, welche Tools sich eignen das Leitbild, den Backlog und OKRs gut abzubilden. Wir diskutieren wie die Top-Down-Einführung von OKRs strukturiert sein sollte, um zu verhindern, dass die Themen der OKR Sets als “top-down” wahrgenommen werden. Wir überlegen außerdem, wie man im OKR Kontext mit den weniger agilen Unternehmensbereichen umgeht, wie z.B. Lagerung oder Produktion. Lassen sich auch diese Bereiche etwas agiler oder modularer gestalten, trotz langjährigem Planungsvorlauf? Außerdem erläutern wir das Ursache-Wirk-Prinzip des Murakamy OKR Ansatzes und besprechen, wie man aus Team OKR Sets, Abteilungs-Sets ableitet und ob man diese auch nachträglich noch einführen kann. Und wir diskutieren, wie man Spaß in die Arbeit mit OKRs bekommt, oder ob es hierbei doch um etwas anderes geht…
Themenübersicht:
Welche Tools eignen sich zur Abbildung von Leitbild, Backlog und OKRs?
Wie geht man im OKR Kontext mit weniger agilen Bereichen wie Lager oder Produktion um?
kurz erklärt: Das Ursache-Wirkungs-Prinzip / Outcome vs. Output
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.
ANTWORTEN AUF DIE FRAGEN ZUM NACHLESEN
Welche Tools eignen sich zur Abbildung von Leitbild, Backlog und OKRs?
Antwort: Ich würde in Richtung Notion, Asana oder Confluence schauen. In diesen Tools kann man die komplette Leitbildpyramide sauber formulieren. Dann hat man eine Art Kanban-Board oder Backlog, wo man Ideen sammeln kann - potenzielle zukünftige Ziele sozusagen, aber noch keine festgelegten Ziele.
In Asana zum Beispiel kann man wunderbar diese Ideensammlung, dieses Backlog, in OKRs umwandeln. Man orchestriert sie dann als Objectives and Key Results in der Asana-Funktion. Oder man baut die Projekte ein bisschen anders auf, wenn man sich die große Asana-Lizenz nicht leisten kann oder will. So kriegt man es extrem gut hin, dass man sowohl die Backlog-Items - also die potenziellen Ziele - als auch die Ziele, für die man sich committed hat, und die dazugehörigen Tasks abbilden kann.
Dann macht ein Tool wirklich Sinn: Man kann zu den Zielen kommunizieren und genau sehen, wo man vorangekommen ist, wo nicht, wer gerade eine Frage hat und so weiter. Da entfalten die Tools ihre wahre Power.
Worauf sollte man bei einer Top-Down OKR Einführung achten?
Antwort: Bei einer Top-Down OKR-Einführung empfehlen wir stets einen Versuchsaufbau, der das C-Level plus eine Ebene darunter umfasst. Das bedeutet, wir führen OKRs für alle C-Level-Positionen und die direkt darunter liegende Führungsebene ein - in voller Breite, aber nicht weiter nach unten. Warum machen wir das so? Um zu verhindern, dass Ressourcen und Abhängigkeiten ungeklärt bleiben. Ein unvollständiger oder oberflächlicher Versuchsaufbau würde uns keine klaren Erkenntnisse liefern. Wir wollen ja verstehen, was funktioniert und was nicht.
Der Kerneffekt dieses Ansatzes ist, dass wir alle Unternehmensthemen in ihrer vollen Breite diskutieren. Dadurch wird eindeutig klar, wie wir mit den Zielkonflikten bei knappen Ressourcen umgehen. Ein typisches Beispiel: Alle wollen etwas von der IT-Abteilung. Sieben Leute kommen mit 14 Themen, aber die IT kann realistisch nur fünf davon umsetzen. Wenn jetzt jeder seine Wünsche einfach "über den Zaun wirft" und wegrennt, löst das das Problem nicht. Stattdessen setzen wir uns alle in einen Raum und fragen: Was bringt die Firma als Ganzes am weitesten voran? Wir suchen das globale Optimum für den Einsatz der knappen IT-Ressourcen. Wenn alle an dieser Entscheidung beteiligt sind, kann später niemand sagen: "Ich kriege nie IT-Ressourcen." Stattdessen haben wir als Team Prioritäten gesetzt. Dieser Prozess hilft auch dabei, den ständigen Strom neuer Ideen und Anforderungen zu managen. Wir haben die großen Themen bereits aussortiert und wissen, wofür wir keine Ressourcen haben. Das verhindert, dass ständig neue Kleinteile "über den Zaun geworfen" werden. Um diesen Nutzen zu erzielen - die Allokation knapper Ressourcen für das globale Optimum - muss die gesamte Führungsebene mitmachen. Deshalb simulieren wir den Prozess auf der obersten Ebene.
In der Praxis haben wir festgestellt, dass der Vorstand selbst diesen Prozess durchlaufen sollte, bevor er in einzelne Bereiche ausgerollt wird. So verstehen sie, wie es funktioniert und wie es sich anfühlt, sich einem Framework anzupassen, während man gleichzeitig das Tagesgeschäft und Veränderungsthemen managt. Wir definieren zunächst die Unternehmensvision, die Mission und Fokusthemen. Das gibt uns drei Hauptthemen, auf die wir uns konzentrieren und die für das Gesamtunternehmen relevant sind. Diese Change-Themen kommen zu den typischen Run-Themen hinzu. Das Hauptproblem dabei ist, dass das OKR-Set auf Vorstandsebene definiert wird, aber der Vorstand selbst die Tasks nicht umsetzen kann. Deshalb brauchen wir die nächste Führungsebene. Sie sagen: "Das ist super, was ihr euch da oben überlegt habt. Jetzt sage ich dir, was meine Abteilung oder mein Bereich dazu beitragen kann - unter Berücksichtigung meiner Realität." Sie müssen das laufende Geschäft am Laufen halten, Kunden zufriedenstellen und haben nur begrenzte Kapazitäten für Veränderungsthemen. Diese Diskussion führt hoffentlich dazu, dass man versteht: Es reicht nicht, nur die spannenden Change-Themen in den Fokus zu rücken. Als CEO oder C-Level muss ich den Trade-off machen und das gesamte Orchester richtig einstellen. Ich muss abwägen: Wie viel Veränderung können wir uns leisten, ohne das Kerngeschäft zu gefährden?
Die Grundidee von OKR ist ja: Die Ressourcen sind fix, der Zeitraum auch. Du kannst nur so viele Ziele definieren, wie in diesen Rahmen passen. Es wäre unfair und unrealistisch zu sagen: "Mach alles wie immer und jetzt noch diese drei neuen Themen dazu." Das hat nichts mit agilem Management zu tun. Mein Job als Top-Manager ist es, diesen Trade-off aufzulösen und zu entscheiden: Auf welche fünf Themen können wir uns realistisch konzentrieren, nicht auf welche 20? Wie allokiere ich die Ressourcen?
Deshalb sollten wir nicht nur Change-Themen betrachten, sondern den Trade-off auf Unternehmensebene machen: Was erreichen wir im normalen Geschäft und was in Veränderungsprojekten? Die einzelnen Bereiche bringen dann ihre Perspektive ein: "In unserem Bereich können wir das und das leisten." Wenn das nicht ausreicht, um die Unternehmensziele zu erreichen, müssen wir über eine Neuallokation der Ressourcen sprechen. Das ist der wesentliche Nutzen des OKR-Ansatzes.
Ist eine Teileinführung von OKR sinnvoll?
Antwort: Bei der Einführung von Agilität stoßen wir oft auf ein grundlegendes Problem: In einer agilen Welt lässt sich nicht so gut planen. Die Realität ist weder vorhersehbar noch macht sie das, was wir von ihr wollen. Wir überschätzen uns ständig, unterschätzen Dinge, und am Ende stimmt der Plan sowieso nie. Manchmal war er zu optimistisch, manchmal zu pessimistisch, aber selten richtig. Deshalb kam die Idee auf, dass Agilität eine Antwort darauf sein könnte. Wenn ein Teil deiner Organisation weiterhin davon ausgeht - verzeih mir das etwas strapazierte Bild - die Erde sei eine Scheibe, während der andere Teil agil denkt, wird es schwierig. Man redet dann einfach über unterschiedliche Dinge. Die einen sagen, alles ist planbar und vorhersehbar, die anderen betrachten die Welt anders. Das führt unweigerlich zu kulturellen Konflikten, die viel Frust auslösen können. Man denkt vielleicht: "Wir haben doch schon herausgefunden, wie es funktioniert. Warum kämpfen wir immer noch damit?" Die Antwort ist: Weil andere anders auf die Welt schauen. Ich sage nicht, dass man es trotzdem nicht versuchen sollte - ein Grass-Roots-Ansatz kann durchaus etwas bewirken. Aber es ist verdammt anstrengend. Ist es der Weg, den ich dir empfehlen würde, wenn du nach dem schnellsten und entspanntesten suchst? Nein, ist es nicht. Wenn dir aber keine andere Option bleibt, würde ich es trotzdem machen. Allerdings würde ich zumindest versuchen, einen Diskurs anzuregen: Glauben wir an Agilität oder an die Planbarkeit, die uns zweifellos bisher erfolgreich gemacht hat? Wobei man auch fragen könnte: Waren wir vielleicht trotz und nicht wegen der Planbarkeit erfolgreich?
Für die Zukunft stellt sich die Frage: Glauben wir, dass sie weiterhin so funktioniert wie die Vergangenheit, oder ändert sich jetzt etwas grundlegend? Wir bekommen nicht mehr die Mitarbeiter, der Wettbewerb bedrängt uns von allen Seiten, KI wirft neue Fragen auf - es gibt viele Unsicherheiten. Vielleicht gibt es gute Argumente, sich damit auseinanderzusetzen, dass die Welt heute anders funktioniert als gestern. Ich will das gar nicht bewerten, aber es lohnt sich, das eigene Weltbild zu hinterfragen. Das ist vielleicht eine frustrierende Antwort, aber sie ist realistisch.
Jetzt kommt der positive Teil: Du kannst das lokale Optimum optimieren. Du kannst für dich und deine Teams das Beste herausholen. Das bedeutet aber auch, dass das, was wir vorhin gehört haben - dass ständig Aufgaben von anderen Bereichen "über den Zaun geworfen" werden - nicht weggehen wird. Dieses Störfeuer wirst du nicht los. Aber alles, was wirklich in deinem Einflussbereich liegt, kannst du top optimieren. Es wird deutlich besser, keine Frage. Wenn du OKR nur in deinem Bereich oder Team einführst, wird dieser Teil transparenter und ruhiger. Die Ressourcen sind besser allokiert. Was anstrengend bleiben wird, ist die Abstimmung nach oben. Du wirst weiterhin sagen müssen: "Das ist zu viel" oder "Das geht nicht alles gleichzeitig". Das Framework wird dir diese Probleme nicht lösen, weil die anderen Teile der Organisation nicht Teil des Prozesses sind und nicht die gleiche Transparenz haben. OKR nur in einem kleinen Team einführen, um zu lernen, wie es funktioniert, und die Leute auszubilden. Und dann vielleicht auf einen größeren Teil der Organisation ausrollen, wenn wir einen positiven Piloten haben. Das ist auf jeden Fall denkbar, aber ich würde sagen, es ist die zweitbeste Option.
Wie bringt man mehr Spaß in die Arbeit mit OKRs?
Antwort: Wann sind Menschen mit ihrem Job zufrieden? In der Regel dann, wenn sie etwas machen können, wo sie Selbstwirksamkeit erfahren und wenn sie glauben, dass es Sinn macht. Der größte Demotivator ist das Gefühl, seine Zeit verschwendet zu haben. Wenn ich es schaffe, im Unternehmen den Kram rauszudiskutieren, der Zeit verschwendet, Selbstwirksamkeit reduziert oder das Gefühl vermittelt, nicht relevant zu sein - Halleluja! Muss ich dann auch noch dafür sorgen, dass es irgendwie fancy daherkommt? Ich glaube nicht. Wenn ich das on top noch schaffe, schön und gut, aber ich habe dafür keine Ideen. Ich bin schon mit dem ersten Teil total beschäftigt. Deswegen ist es überhaupt nicht meine Optimierungslogik, etwas zu verpacken, damit Leute es benutzen, weil es Spaß macht. Der Outcome von OKR muss dein Leben besser machen: Ich bin weniger gestresst, ich muss weniger Quatsch machen, ich kann Sachen machen, auf die ich Bock habe, kann selbst Entscheidungen treffen, ich habe einen Rahmen, in dem ich arbeiten kann. Das, was ich mache, fühlt sich sinnvoll an. That's it. Wenn ich das hinkriege, würde ich sagen, sind die meisten Leute auf der Habenseite und sagen: "Hey, irgendwie ganz geil, dieses OKR-Zeug."
Wenn ich das nicht hinkriege, dann hilft meiner Erfahrung nach auch der ganze Versuch, es ein bisschen spaßiger zu machen, nicht. Wenn die Leute nicht motiviert sind, die OKRs zu bearbeiten, dann stimmt wahrscheinlich etwas an den Inhalten nicht. Das heißt, es sind nicht die in der Alltagsrealität relevanten Punkte drin. Ich würde dann sagen, man muss an die Inhalte ran und nicht versuchen, das mit ein bisschen “Feenstaub” aufzumöbeln. Man muss sich fragen: Reden wir über die richtigen Dinge? Stehen da Sachen drin, die gar keine Relevanz haben? Denn wenn die Inhalte relevant sind, dann hast du Bock, darüber zu reden, weil es ja die Sachen sind, die du wirklich vorantreiben willst. Es schwirrt immer noch durch unser Unternehmen dieser Glaube, man dürfe nur strategische Themen in die OKRs schreiben und nicht die operativen. Das versuche ich immer wieder den Leuten auszureden. Wir brauchen die Key Results, die eure Lebensrealität abbilden und nicht nur die Sachen, die von oben kommen. Wenn das so gelebt wird, kann ich schon verstehen, dass der Spaß ein bisschen ausbleibt.
Wie geht man im OKR Kontext mit weniger agilen Bereichen wie Lager oder Produktion um?
Antwort: Die Herausforderung ist nicht einfach, keine Frage. Man kann natürlich nicht alles agilisieren. Die Realität wird nicht so sein, dass man in einem Quartal ein Kraftwerk gebaut hat. Die spannende Frage ist: Wenn es fünf Jahre dauert, ein Werk zu bauen, was macht ihr dann? Was, wenn wir nach fünf Jahren feststellen, dass die Vorhersage totaler Mist war, es niemanden interessiert, und wir jetzt ein Werk haben, in dem nichts produziert wird? Was machen wir dann? Typischerweise schauen wir uns alle betroffen in die Augen und sagen, wir konnten es nicht besser wissen. Dann verfallen wir in diesen Planungswahnsinn und denken, wir müssen unseren Plan verbessern. Aber was machst du mit dem Werk? Ganz operativ gesehen. Fackeln wir es ab und schreiben es ab? Das kommt tatsächlich öfter vor als man denkt.
Ein typischer Cash-Flow-Unternehmer, der sein eigenes Geld verbrennen sieht, würde vermutlich fragen: "Was haben wir hier? Was kann das Ding? Wie kann ich es umbauen?" Wenn Produkt A nicht läuft, kann ich vielleicht Produkt B daraus machen. Was kann ich mit marginalen Anpassungen erreichen, um einen Komplettabschrieb zu vermeiden? Wie kann ich Assets produzieren, die ich anderweitig nutzen kann? Wenn du das ohnehin nach fünf Jahren machst, kannst du auch vorher darüber nachdenken. Wie kriege ich es modularer gebaut? Wie kann ich schneller Erkenntnisse gewinnen? Das ist die Grundidee der Agilität. Wenn du ein Auto bauen willst, musst du mit einem Brett und vier Reifen den Berg runter rollen und unten feststellen, dass Bremsen geil gewesen wären. Dann hast du schon mal ein Auto mit Bremsen. Es geht um dieses iterative Vorgehen. In der Theorie funktioniert es immer einfach, aber die Frage ist: Kann ich meine Produktionsstraße modularer gestalten? Statt jemandem zu sagen, "Bau mir genau diese Produktionsstraße", sollte man vielleicht sagen: "Wir haben fünf Schritte, und ich hätte gerne fünf verschiedene Module, die nicht nur A können, sondern vielleicht auch B." Ja, das kostet vielleicht etwas mehr, aber Agilität ist immer ressourcenaufwändiger als Nicht-Agilität. Dafür habe ich mehr Optionen. Es geht darum, in Optionen zu denken. Wie schaffe ich es, mir in der Realität Optionen zu bauen? Ich weiß zwar nicht genau, was kommt, aber ich kann nicht nur A, sondern auch B und C. Vielleicht hilft mir das, das ganze Werk besser nutzbar zu machen oder mehr daraus zu holen. Oder wie kann ich Dinge schneller anpassen?
Agil denken heißt: Kann ich mir Optionen schaffen, die mir in drei, sechs, neun Monaten oder fünf Jahren Handlungsspielräume offen lassen, die ich mir vorher, wenn ich den Wasserfall-Ansatz gewählt hätte, zugemacht hätte? So würde ich vielleicht darauf schauen.
Wie passen 3-Monatszyklus und langfristige Ziele zusammen?
Antwort: Was den 90-Tage-Rhythmus von OKR betrifft: Wenn die Leute eh schon für die nächsten zwei Jahre verplant sind, warum beschäftige ich mich dann damit, was sie in den 90 Tagen machen? Die Frage ist, ob es Sinn macht, ein zentrales Transparenz-Werkzeug in der Firma zu haben, wo alles drin ist. Am Ende ist die Vision, dass alle da reinschauen und sehen, was die Firma gerade macht und warum. Wenn du einen CTO in einem agilen Umfeld fragst, wann ein bestimmtes Feature kommt, und du fragst über die 90 Tage hinaus, wird er, wenn er gut ist, sagen: "Kann ich dir nicht sagen." Warum? Weil das die Grundidee des Ganzen ist. Er kann dir ungefähr sagen, was nach was kommt, aber nicht genau wann. Man kann diese langfristige Ebene durchaus auf einer Roadmap-Idee basieren lassen, ohne dass es eine verbindliche Planung ist. Man kann sagen: "Okay, dieses Thema kommt vor jenem." Ob das jetzt 90, 180 oder 260 Tage dauert, werden wir sehen, wenn wir es gemacht haben.
Diese Themen miteinander zu verheiraten, bringt den Leuten, die die Arbeit machen müssen, eine enorme Erleichterung. Sie haben nur einen Zettel, auf den sie schauen müssen. Ob ich die unrealistischen Zeitpläne von fünf Projektmanagern treffe? Keine Ahnung. Aber davon mache ich mein persönliches Glück nicht abhängig, denn die Planung ist ja schon unrealistisch. Warum sollte ich mich dann danach richten? Lass uns lieber der Realität die Ehre geben.
Kurz erklärt: Das Ursache-Wirkungs-Prinzip / Outcome vs. Output
Antwort: Das Erste Key Result ist das KPI, weil es am naheliegendsten ist. Das Zweite, Dritte und Vierte sind in der Regel irgendwelche Initiativen auf einer Meilenstein-Ebene, die wir erreicht haben müssen, damit etwas passiert. Aber meistens sind nicht einmal diese auf der gleichen Ebene konsistent. Das ist ein Muster, das man sehr häufig sieht. Wenn das so ist, stellt sich die Frage: Warum versuche ich das überhaupt? Wenn ich beweisen will, dass sich das KPI verändert hat, weil ich bestimmte Dinge gemacht habe, dann müsste die Herleitung ja mathematisch irgendwie funktionieren. Wenn dann in den Daten suchst, stellst du fest, dass du es nicht beweisen kannst. Es ist ein multivarianter Test. Du kennst kein Gegenereignis - Die Frage ist, wie hätten sich die Zahlen dann entwickelt? Wie hätte sich das KPI dann verändert? Wir wissen es nicht. Das heißt, zu behaupten, dass sich das KPI deswegen bewegt hat, weil wir etwas gemacht haben, ist nicht immer folgerichtig. Es kann sein, muss aber nicht.
Jetzt ist die Frage, wie nähern wir uns der Entscheidung am besten an? Indem wir versuchen, Ursache-Wirkungs-Beziehungen herauszufinden. Zu sagen: Immer wenn ich hier ziehe, kommt wirklich ein Ergebnis raus. Und wenn das Ergebnis rauskommt, hat sich reproduzierbar der Zeiger bewegt. Wie viel? Ich weiß es nicht. Das lässt sich eh nicht beweisen. Aber es ist zumindest eine starke Indikation dafür, dass es in die richtige Richtung geht. Umgekehrt, wenn du sagst: "Jetzt habe ich es aber nicht erreicht." Wenn du nur das KPI nicht erreicht hast, dann weißt du nur, dass du das KPI nicht erreicht hast. In einer hypothesengetriebenen Welt weißt du: Das hat den Zeiger nicht bewegt. Aber dann haben wir gelernt: So geht es schon mal nicht. Da ist kein Ursache-Wirkungs-Zusammenhang. Aber vielleicht gibt es einen, wenn ich es anders probiere. Also habe ich einen Erkenntnisgewinn. Bei dem anderen Ansatz sage ich nur: Der Zeiger hat sich nicht bewegt. Warum? Ja, weiß ich nicht. Schlechte Marktlage, schlecht gemacht, kein kausaler Zusammenhang. Wir wissen es nicht. Deswegen versuchen wir es auf Ursache-Wirkungs-Prinzipien herunterzubrechen. Wenn du und ich darüber reden, wie wir das am ehesten hinkriegen, dann habe ich in der Welt, in der wir uns nur über den Endzustand des Ziels unterhalten, keine Plausibilität, die ich hinterfragen kann. Wenn du und ich sagen: "Ey, wäre es nicht geil, mehr Umsatz zu machen?", sage ich: "Ja, wäre geil." "Ja, wäre doch geil, oder?" "Ja, gut, lass es probieren." Und am Ende stehen wir drei Monate später da und sagen: "Hat nicht geklappt." Wenn ich aber vorher sage: "Das ist die Ursache dafür und ich glaube, das kommt dabei raus", dann habe ich eine ganz andere Chance, bevor ich Aufwand investiere, darüber zu diskutieren, ob wir alle gemeinsam glauben, dass das die beste Verwendung unserer Ressourcen ist. Und dann können wir uns reiben. Dann kann ich sagen: "Ne, warte mal, an die These glaube ich nicht. Warum? Hier sind meine Erfahrungen." So würde ich es argumentieren. Das heißt, wir haben einen viel besseren Plan, den wir umsetzen können, weil wir ihn schon auf Sinnhaftigkeit überprüfen können, bevor die Arbeit gemacht wird. Das sind wahrscheinlich die wesentlichen Argumente dafür.
Wie leitet man aus Team OKRs Abteilungs-Sets ab?
Antwort: Um aus Team-OKR-Sets ein Abteilungs-OKR-Set zu entwickeln, muss die verantwortliche Person ein solches Abteilungs-OKR-Set erstellen. Das Set sollte bestmöglich repräsentieren, was diese Abteilung mit den einzelnen Teams im Quartal an Zielen erreichen kann. Danach erfolgt ein Abgleich mit den Unternehmenszielen und den verfügbaren Ressourcen. Diese Konsolidierungsarbeit sehen wir als originäre Führungsaufgabe. Das bedeutet, C-Level plus Abteilungsleitung sollten hier einbezogen werden. Wenn es über die Abteilungsebene gespielt wird, sollte das in einem Workshop mit C-Level plus Abteilungen geschehen.
Der nächste Schritt ist, dass sich die Abteilungen und ihre Teams auf ihre OKRs verständigen. In dem bereits etablierten Prozess läuft das von unten nach oben: Die Teams geben der Abteilungsleitung ihre Vorschläge, die Abteilungsleitung konsolidiert diese und geht damit in den Workshop. Dort wird diskutiert, Zielkonflikte werden gelöst und es wird sichergestellt, dass das Unternehmens-Set bestmöglich ist und erreicht werden kann. Anschließend geht die Abteilungsleitung zurück zu den Teams und bespricht, was das konkret für sie bedeutet. Auf diese Weise füllt jede Person ihre Rolle aus und die Themen werden ausreichend verdichtet und konsolidiert. Das wäre die grundlegende Idee.
Folgende beiden Aspekte sind in diesem Zusammenhang noch wichtig zu erwähnen:
Transparenz zwischen den Teams: Wer macht was? Wo liegen welche Tasks? Das ist dann nicht mehr so offensichtlich, weil man nicht gleichzeitig am Tisch sitzt. Hier stellt sich die Frage, ob es noch einen Tag oder halben Tag geben sollte, an dem sich alle Teams treffen und ihre fertigen OKR-Sets gegenseitig vorstellen. Idealerweise ist das nicht nötig, da es ausreicht, wenn auf Abteilungsebene die bereichsübergreifenden Abhängigkeiten sichtbar sind.
Abhängigkeiten zwischen den Abteilungen: Wenn meine Abteilung an einem Thema mit einer anderen Abteilung arbeitet, ergibt sich daraus eine Abhängigkeit. Wenn das nicht der Fall ist, kann man aus Interesse schauen, was die anderen Teams machen, aber es besteht kein Abstimmungsbedarf. Die Abhängigkeiten zwischen den Abteilungen sind dann von den Abteilungsleitern im Planning abzudecken. Dadurch, dass die großen Themen aufeinander abgestimmt sind, sollte es bei den kleineren Themen nicht zu wesentlichen Abweichungen kommen.