In der AMA Episode 42 diskutieren wir die spannende Frage, was der Unterschied zwischen Output und Outcome ist, und wie es gelingen kann, messbare Key Results, als agile Alternative zu Konzepten & Co., zu finden. Wir untersuchen, ob und wie sich Salesteams durch OKRs imcentivieren lassen und beleuchten den Konflikt, der entstehen kann, wenn man sowohl mit PMO als auch mit OKRs arbeitet oder sie einführen möchte. Wir diskutieren dieses Szenario ausführlich und erläutern, warum diese beiden Steuerungsprozesse sich gegenseitig ausschließen. Wir haben zudem den OKR Prozess genauer betrachtet, und sprechen darüber, welche wichtige Rolle die Ressourcenplanung hier spielt, wie man OKR Sets kaskadiert und wie sich das Alignment zwischen Teams optimieren lässt.

Themenübersicht:

Wie formuliere ich messbare Key Results?
Konzeptplanung vs. agiler Denkansatz
Steuerung der Metrik mit dem Confidence Level: Wie funktioniert das?
Messbarkeit von Key Results am Quartalsende: Umgang und Lösungsansätze
Incentivierung mit OKRs im Sales
PMO Vs. OKR - Teil 1: Vergleich der Steuerungsprozesse
PMO Vs. OKR - Teil 2: Konflikt oder Koexistenz
Kaskadierung von OKR-Sets - Wie funktioniert es und warum ist es wichtig?
Sinnvolle Teileinführung eines OKR-Piloten: Erfolgsstrategien und Tipps

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.

Transkript der Folge:

[00:00:00] Marco: Hallo und herzlich willkommen zur Episode 42 von Ask Me Anything About OKRs. Wir haben diskutiert, was der Unterschied zwischen Output und Outcome ist und wie man es schafft, wirklich messbare Key Results zu finden und weg von Erstellung von Konzepten und Co zu kommen. Wir haben die Frage diskutiert, wie man Sales Teams am besten incentiviert, wenn sie mit OKRs arbeiten, und wir haben den Konflikt beleuchtet, der möglicherweise da drin steckt, wenn man Projektmanagement mit einem PMO, also einem Project Management Office, hat und gleichzeitig OKRs eingeführt hat oder einführen will.

Darüber hinaus haben wir uns noch so ein bisschen den Prozess angeguckt in Bezug auf die Frage, wie kaskadiert man eigentlich OKRs? Wie schafft man das Alignment zwischen den Teams? Und wie geht man mit der Ressourcenplanung um? Diese und wie ich finde viele weitere spannende Themen in der am 42. Jetzt also direkt rein und viel Spaß!

Also ganz herzlich willkommen zur Episode 42 heute schon. Und wenn ich es richtig sehe, ist die erste Frage von dir, Richard.

[00:01:30] Richard: Okay, das war nicht Korbinian, der hier geschrieben hat, er wollte einfach nur sagen, hier ist ein Chat.

[00:01:33] Marco: Genau, der wollte nur sagen, dass da der Chat ist. Damit wärst du der erste mit einer richtigen Frage.

[00:01:39] Richard: Also ich hätte ich hätte zwei Fragen.

Die erste Frage ist: Wir wollen OKRs ja immer messbar machen, mit outcome-basierten Key Results, und dann wenn es geht, auch noch mit einer schönen Metrik dran. Wir werden immer besser darin, dass sie outen-basiert sind, aber nur weil es ein Outo ist, muss es ja noch nicht messbar sein, und wir streben immer so an, dass wir sagen 50% unserer Key Results sind outo-basiert und halt auch mit einer Metrik versehen, und da wollte ich mal fragen: Was ist so aus deiner Erfahrung da eine gute Zielgröße? Weil ich find da total schwierig was, was danach zu sehen, was ist so der Durchschnitt? Weil ich lese immer nur okay, man sollte das machen, aber was ist denn wirklich, wirklich erreichbar als Prozentsatz? Weil manchmal hast du ja wirklich Ziele, wo du sagst okay, das ist halt einfach ein out, den kann ich aber nicht mehr in meiner Erfahrung messen.

[00:02:36] Marco: Das ist wahrscheinlich so. Ich würde es mal versuchen mit einer Betrachtung: Wir glauben, dass der Outcome das Objective ist und der Output das Key Result. Und deswegen, also ich würde deine Aussage unterstreichen, dass der Outcome sich in der Regel eher mäßig gut messen lässt und deswegen misst du auch den Output, also das, das Messbare, Zählbare, Wiegbare, was dann zu einem gefühlten Nutzen führt, weil sonst hängst du ja im luftleeren Raum. Der Gegenspieler zu dem Output ist wahrscheinlich ein langfristig zu beobachtendes KPI, aber sozusagen die Korrelation herzustellen zwischen dem, was wir getan haben, und der messbaren Reaktion auf einer Output-Ebene, ist in der Regel schwierig bis unmöglich, weil es sowieso multivariant und multikausal ist.

Und selbst wenn du dann sagen würdest, ich hätte etwas gemessen, wäre noch nicht bewiesen, dass das auf deine Handlung zurückzuführen ist. Also um es nochmal neu zu sortieren: Das Objective ist der Outcome, das Key Result der Output und der Output, der gemessen wird, der sollte schon, also da sollte schon ein Großteil messbar sein. Die Frage ist, was sind denn dann die anderen 50% in welcher Dimension sich die bewegen, denn dann sind die ja möglicherweise eher auf der Input-Ebene oder?

[00:04:03] Richard: Ja, also ich würde sagen, wir haben bei uns, und so seh ich auch oft in der Literatur noch eine, noch eine Ebene dazwischen. Also das, was du als Outcome auf Objective-Ebene beschrieben hast, nennen wir bei uns auf den Impact, dass wir sagen wir, also wir sagen nicht, dass wir zum Beispiel ein neues Feature in der App, ist bei uns kein Objective, sondern das ist dann immer: Welchen Impact wollen wir denn damit erreichen?

Also das da würde ich sagen, verwenden wir Outcome und Impact quasi auch mit einem Synonym und uns dann haben wir aber unter unseren Objectives und das ist also wir arbeiten mit dem Tool Perdoo, da haben wir die Key Result-Ebene und da drunter sagen wir dann halt die Initiative-Ebene und das, was wir auf Initiative-Ebene machen, sehe ich bei uns das, was du als den Output nennst, das ist unsere, unsere Kontrolle, das sind Sachen, die wir machen, wie zum Beispiel...

[00:05:01] Marco: Das habe ich nicht gesagt, ich habe nicht gesagt, dass mein Output die Sachen sind, die wir machen, sondern die Resultate, die wir durch das Machen erzeugen.

[00:05:10] Richard: Ja, ja, okay, verstanden, also das ist, das ist dann bei dir, dass der, der Output nur wir, also bei uns wir nennen den Out-Kamm quasi die Key Results und da ist es halt wichtig, dass der Outcome immer etwas ist, was Business-Wert hat oder was nicht, was ist, was wir selber machen, sondern das ist was, was wir erzeugen, also meinetwegen 20% mehr Nutzer in der App pro Woche oder so was...

[00:05:33] Marco: Das ist aber in unserer Welt ein KPI, wahrscheinlich, wenn die App das Zentrale ist.

[00:05:39] Richard: Ja, zum Beispiel, genau, oder sagen wir 10%.

[00:05:43] Marco: Ja, halt. Dadurch wird's für uns kein Key Result. Sondern also, wenn die, die Nutzerquote einer App, die du langfristig betreibst, wahrscheinlich dauerhaft ein guter Indikator ist für sagen wir mal die Qualität der App, dann taugt sie nicht als Key Result. Weil das Kleine Bewegen des Zeigers von hier nach da auf einer dauerhaft langfristig sinnvollen Metrik ist nach unserem Dafürhalten kein schlau zu adressierendes einzelnes Result, sondern wir glauben, dass das eben deswegen heißt ja Key Performance Indicator und zwar dauerhaft und auch nur ein Indicator und kein Treiber.

So und wenn wir diesen Key Performance Indicator dauerhaft in eine Richtung bewegen wollen, also mehr Leute benutzen die App regelmäßig, dann muss ich darunterliegend mir die Frage stellen: Was führt denn dazu, dass die Wahrscheinlichkeit gesteigert wird, dass das mehr Leute tun und wie viel das in dem Quartal mehr tun? Na, ist das sowieso multivariant. Sondern das sozusagen den Outcome einzukreisen: Was kann denn die App dem User dieses Quartal Gutes tun, was sie davor nicht konnte? Und was treibt diesen Outcome konkret und nicht übergeordnet? Na ja, aber hoffentlich benutzen es 20% mehr Leute, sondern was genau muss ich an messbaren Results erzeugt haben, dass dieser Nutzen dafür sorgt, dass mehr Leute die App benutzen müssen?

Der Kausalzusammenhang ist konsistent in dem Modell.

[00:07:18] Richard: Ja, verstanden.

[00:07:19] Marco: Ist das klarer?

[00:07:21] Richard: Ja, macht es klarer. Also so gehen wir auch vor, also sagen wir mal Key Performance Indicator auf oberstem Level ist für uns, dass wir User generieren. Das ist was, was ein oberer KPI ist, und dann können wir da drunter sagen: Okay, was machen wir, was können wir denn machen, um da mehr User zu generieren? Und dann sagen wir da drunter: Okay, Time Spent in App ist vielleicht was, was das positiv beeinflusst und dann versuchen wir, versuchen wir das zu erhöhen.

[00:07:49] Marco: Wie kann das sein?

[00:07:51] Richard: Ich weiß keine Ahnung, ob dieser logische Zusammenhang tatsächlich stattfindet, aber schon. Also wir arbeiten schon so, dass wir sagen, die die Key Performance Indicators werden durch Results unten drunter positiv beeinflusst oder eben nicht. Wenn das Quatsch war, was wir uns überlegt haben, nur selbst wenn wir dieses Verständnis schon haben, haben wir es schon noch oft, dass wir, dass wir sagen: Okay, das kann ich jetzt noch nicht messen.

Ein Beispiel wäre, glaube ich, ein Kollege hat gesagt, wir glauben Gamification könnte ein Teil sein, um mehr Leute in unserer App zu kriegen und dann muss ich jetzt aber erst mal erst mal mir Gedanken zu machen, wie wir das überhaupt, wie wir es überhaupt benutzen können, am besten schreibe ich ein Konzept dafür und ein Outcome-Outcome-basiertes Key Result, was wir dann haben, wäre gewesen: Wir haben verstanden, wie wir Gamification in unseren Produkten bestmöglich einsetzen können.

8:55 - 28:30

[00:28:30] Elena: Hallo, ähm, ich arbeite in einem mittelständischen Unternehmen in Köln und äh, wir haben OKRs seit 2 Jahren. Ähm, wir haben also das heißt, wir haben das Problem, aber wir sind ähm sehr projektgetrieben, das heißt, wir haben alle Themen immer in äh mit Projekten gemacht, unser PMO ist ja sehr groß und professionalisiert. Und dann kam OKR und wir haben ja gesagt, wir möchten unsere Strategie mit OKR ähm operationalisieren.

Und äh mittlerweile ähm glaube ich, gibt das ein bisschen Verwirrung. Ähm, wann machen wir denn Projekt und wann machen wir äh OKR? Weil ähm die Projekte werden ja auch auf Strategie abgestimmt und wir wissen ja, dass äh Projekte in gut ergebnisorientiert sind und OKR äh auch kam orientiert. Wir auch anfangs die äh Frage von Richard glaube ich ähm: Wir versuchen ein paar Kriterien zuzurechtzulegen, damit wir wissen: Okay, ich habe ein Thema - ist das jetzt ein OKR oder ist es ein Projekt?

Und ich habe mich sehr damit beschäftigt und ich habe auch viele Podcasts von dir gehört. Und mittlerweile bin ich, würde ich sagen, ich, ich könnte - ich wollte glaube ich nicht - konkret sagen: Das ist ein Projekt und das...

[00:29:54] Marco: Was sagt denn euer PMO dazu?

[00:29:58] Elena: Also unser PMO sagt dazu: Wenn es ein Produkt sein soll, die Entwicklung eines Produktes, wäre das ganz klar ein Projekt.

[00:30:09] Marco: Okay, jetzt wird's spannend. Also ich glaube, dass die Frage nicht so wirklich situativ ist, sondern das eher eine generelle Frage. Also das ist die Frage: Will ich tendenziell meine Ressourcen in Form von Projekten durch ein zentrales PMO steuern oder wenn die gleichen Ressourcen in Form von OKRs steuern? Aber die gleichen Ressourcen mal so und mal so zu steuern, ist wahrscheinlich relativ hinfällig.

Also der, der Weg erschließt sich mir nicht. Von daher würde ich nicht nach einer Regel suchen, wann es ein PMO-Thema ist und wann es ein OKR-Thema ist, sondern ich würde mich einmal hinsetzen und mir die Frage beantworten: Will ich den Laden nach Projekten steuern, dann lasse ich das, oder will ich den Laden agil anders über OKRs steuern, dann mach ich das.

Aber ich höre auf, die Leute zu verwirren durch "Was, was ist denn jetzt das Ding?" oder "Was ist denn jetzt das?" Und allein schon der - Also du gehst ja auch dann - das ist auch eine Aufbau-Frage: Ein Stück weit du gehst ja davon aus, dass die Teams nach Produkten schon gebaut und geschnitten sind. Und das heißt: Sobald du was in einem Produkt oder ein neues Produkt entwickeln willst, ist es kein Projekt, weil es ja schon alle Ressourcen hat, die es braucht, um sich selbst zu entwickeln.

Also, da treffen einfach zwei unterschiedliche Grundhaltungen aufeinander und ich sage nicht, die eine ist gut und die andere ist schlecht. Ich sag nur, was ich noch nie habe funktionieren sehen, und was ich ehrlicherweise für eine Qual von allen Beteiligten halte, ist, versuchen beides gleichzeitig zu machen.

[00:33:41] Elena: Ja, das merken wir ja auch, diese Spannung. Wir versuchen ja auch tatsächlich ein bisschen zu planen, in dem Unterschiedliche...

[00:33:48] Marco: Ne, entscheiden! A oder B. Nicht verzahnen, mit einem von beiden aufhören.

[00:33:54] Elena: Das ist sehr radikal.

[00:33:56] Marco: Nein, das ist der einzig, das ist der einzig sinnvolle Weg. Das andere ist, jedes Mal wieder auszurutschen und zu sagen: Ja, stimmt, hatte ich mir auch schon überlegt, es kann wahrscheinlich nicht funktionieren.

Hier ist der Beweis, wie das hat wieder nicht funktioniert. Dann lasst mal anders verzahnen, nee, lasst mal aufhören, Sachen, die nicht kompatibel miteinander sind, miteinander zu verzahnen, sondern entscheidet euch für eine Sache und dann macht die konsequent in voller Montur. Und dann ist allen Beteiligten wahrscheinlich auch eine Menge Frustration und Stress und Schmerz erspart geblieben, was dann nur das neue System im schlechtesten Fall frustriert.

[00:34:21] Elena: Okay, ich glaube der Weg wäre ja tatsächlich, aber ja, also ich nehme das mit und bin sehr gespannt.

[00:34:28] Marco: Du kannst den Ausschnitt gerne weiterleiten und ich stehe auch für die Diskussion gerne zur Verfügung, aber das ist wirklich, das ist wirklich das Qual aller Beteiligten, wenn Sachen einfach nicht die, die sind nicht kompatibel und dann zu versuchen sie kompatibel zu machen, ist genau so als wenn wir Leute sagen: Ja, lass mal das Geld abschaffen und los zusammen machen. Nee, lass mal nicht, mach eins oder das andere und dann wird's glücklich damit, aber nicht alles mit allem.

[00:34:54] Elena: Danke dir! Das war sehr klar und deutlich.

[00:34:59] Marco: Das freut mich. Thilo!

[00:35:03] Thilo: Ja, danke erst noch so für die Verspätung vorhin. Ähm, ich wollte eigentlich was anderes fragen, aber jetzt durch den Punkt von der Elena gerade, würde ich doch eine andere Frage vorziehen. Ich hatte nämlich noch eine notiert: Wie können OKRs und ein PMO koexistieren in einem, in einem Multi-Management?

Ähnlicher Hintergrund bei mir also: Maschinenbau, 150 Jahre altes Unternehmen, 5000 Mitarbeiter, so die Größenordnung. Ja, wir haben ein PMO, wir haben noch keine OKRs. Bisher hatte ich mir das so zurechtgelegt, dass sie sagen: Okay, OKRs macht halt irgendwie Objectives und Key Results, aber natürlich brauchst du Initiativen, um dann auch Dinge zu tun und die Initiativen wiederum werden durch das PMO gemanaged. Und so konnte ich das jetzt zumindest in meinem Kopf mal sortieren, dass sie tatsächlich koexistieren können.

[00:35:44] Marco: Es fängt doch schon an sich zu beißen, wenn du es an eine Ebene weiter runterbrichst. Dann hat ja quasi eine Abteilung ein Team und dann hat das Team auch OKRs und dann kommt von der Seite ein PMO und sagt: Du machst jetzt übrigens was anderes. Und dann sagt das Team: Wer sagt denn das? Ja, wir. Was, warum denn?

[00:36:02] Thilo: Ja, ich - Ich würde so verstehen, dass die OKRs die Priorisierung der Initiativen sage ich mal im PMO vorgeben, also nicht das PMO alleine unabhängig, sondern das PMO macht quasi oder verwaltet, verfolgt, wer auch immer das, was über die OKR-Zyklen vorgegeben wird.

[00:36:20] Marco: Aber schau, jetzt sagen wir wir haben eine Abteilung, also ich bin ja offen, vielleicht irre ich mich auch, aber jetzt haben wir eine Abteilung, da sind zehn Teams drunter und dann da drüben ist eine andere Abteilung mit anderen zehn Teams und die einen sagen jetzt: Abgeleitet vom Company Set haben wir diese Ziele. Und die anderen sagen: Wir haben diese Ziele. Und die passen möglicherweise so zueinander, dass unten, wenn man diese Einzelteile, die die einen und die anderen versprochen haben, wenn man die am Ende des Quartals zusammenführt und steckt, funktionieren die auch.

Natürlich gibt es da Arbeits-Meetings, wo jemand sagt: Puh, wo muss denn jetzt der Knopf hin oder warum passt denn das Ding jetzt da dran, dass es am Ende auch passt, das ist ja auf der Arbeitsebene alles okay. Aber ich weiß genau: Das Ende des Quartals habe ich dieses Bauteil mit den Eigenschaften in der Menge und so und so und es darf nicht mehr kosten als das, das habe ich dir versprochen.

So und jetzt sagst du: Darüber hinaus über die Ebene, die es ja dann auch gibt mit wöchentlichen Meetings und so, das ist ja so ein bisschen der Teil, der dabei möglicherweise vergessen wird, das ist ja nicht nur ich schreibe das mal auf und leg das dann irgendwo hin, sondern ich arbeite damit aktiv. Ich sehe mich mit den Teams jede Woche, wir sehen uns mit den Abteilungen jede Woche, wir sehen uns mit dem Leadership jede Woche, wenn es eskaliert habe ich es auf dieser Ebene bereits eskaliert, weil ich sage die aus der Abteilung da drüben, die kommen ins Straucheln mit ihrem Teil, mein Teil läuft, aber jetzt kann ich denen irgendwie helfen, dass es anders geht, wozu genau brauche ich dann noch jemanden, der da zentral drauf bleibt?

[00:37:58] Thilo: Ja, okay, als Suggestivfrage verstanden. Die Antwort wäre damit: Irgendein CEO kriegt alle seine Informationen, die er meint haben zu müssen, aber das ist logischerweise keine Rechtfertigung dafür.

[00:38:08] Marco: Genau, weil nämlich - und jetzt ist die Frage: Wer ist der Alleroberste, der nicht interessiert dem lustigen Schauspiel zuschaut und seine Verantwortung auslagert, sondern der Orchestrator dieses lustigen Schauspiels ist und bleibt diejenige Person, die die oberste Verantwortung trägt. Und da steht in der Regel hier auf der Visitenkarte.

[00:38:34] Thilo: Ich glaube, so okay, ich glaube so kann man das argumentieren. Ja, ja, ja, fein. Also hintergrund ist, ich möchte eigentlich auch gerne machen und wir haben ein starkes PMO, ich dachte ursprünglich, das geht nicht zusammen, aber jetzt einen Weg gefunden, vielleicht doch, aber wahrscheinlich doch eher nicht. Ja. Da wird halt nur die Einführung Hürden werden höher damit.

[00:38:51] Marco: Das ist so. Nee, aber es ist halt - also mir ist schon wichtig, dass wir Leuten ersparen, Frustrationen zu erleben, die vor ihnen schon Hunderte von Leuten durchlebt haben. Und noch keiner hat den Beweis hinten angetreten: Die Koexistenz ist nicht nur möglich, sondern sinnvoll.

Es ist ja nicht nur so: Ah, ich lass beides - warum? Damit keiner weint. Nee, es muss ja auch die Hypothese sein, es bringt es auch noch, es so zu tun. Wenn da und da habe ich noch keinen gesehen. So, also ich habe nur eine begrenzte Auswahl derer Sachen, die ich gesehen habe, offensichtlich, aber da war keiner dabei.

Und wenn die Antwort ist: Es hat nicht mal jemand eine Hypothese, warum es mit beiden Sachen gleichzeitig besser laufen sollte, würde ich mir schon die Frage stellen: Entweder oder! Und dann das richtig und zwar in voller Montur. Und dann ist allen Beteiligten wahrscheinlich auch eine Menge Frustration und Stress und Schmerz erspart geblieben, was dann nur das neue System im schlechtesten Fall frustriert.

[00:39:56] Thilo: Ja, oder es kann da gelähmt werden für immer, wenn er was nicht wollen. Ja, okay, cool. Nee, danke. Ähm, wenn es zeitlich und so weiter... Anders, also ähnliche Richtung ist jetzt mehr so eine, so strukturelle Frage. Also diese große Organisation, ich gehe mal davon aus, wir hätten irgendwie so drei Level an OKR-Sets, ja? Also was die oder so etwas, also mal als Annahme.

Ähm, was ich öfter gehört, gelesen habe ist, dass du ja OKR irgendwie kaskadieren sollst, ja? Ähm, was genau wird denn da, wie kaskadiert, weil also Hintergedanke ist: Ich will nicht einfach, dass ich oben irgendwie die Key Results nehme, die kann man ja auch schön messen, und dann soll die ganze Company irgendwie danach ticken und die im Prinzip als KPI irgendwie heiligen. Das ist ja nicht die Idee, sondern was genau wird kaskadiert? Wie funktioniert das mit dem Kaskadieren?

Das war die eine Frage, die andere Frage in dem Zusammenhang: Wie funktioniert es mit den Alignment Meetings? Wenn ich sag mal mehrstufig unterwegs bin, also mache ich dann, ich nehme mir eine ganze Woche oder was? Und Montag Dienstag machen die unteren Ebenen und dann Mittwoch...

[00:40:55] Marco: Ne, wir wollen schon noch arbeiten, währenddessen.

[00:40:56] Thilo: Genau, richtig. Und das Letzte da dran, auch große Org: Wie mache ich das eigentlich mit der, also praktisch mit der Ressourcen-Planung, nenn ich mal? Also ist das so klassisch mit was weiß ich, wie Storypoints, T-Shirt-Sizes und sonst irgendwas? Ja, was du ja wahrscheinlich bei einer großen Org irgendwie haben musst, oder doch irgendwie anders und schlauer und nicht so schwerfällig?

[00:41:17] Marco: Ich versuche, mich mal durch die Fragen durchzuarbeiten. Ich habe mitgenommen: noch Kaskadieren, Alignment und Ressourcen-Planung. Wären jetzt mal die drei Stichworte. Zum Kaskadieren muss man wahrscheinlich zwei Sachen sagen. Ich geb dir ein einfaches Beispiel, nur um es modellhaft klar zu machen.

Wenn wir jetzt sagen, wir wollen unsere Webseite neu machen, dann kann ich fotografieren, du kannst vielleicht ähm Texte schreiben und Elena kann programmieren. So und dann verspreche ich in meinem OKR-Set, dass ich die abgefahrensten Bilder mache, du sagst, irgendwie dass du die Texte so schreibst, dass jemand total versteht und juhuu schreit, was wir machen und jemand anders sagt: So ich mach das mit der und der Qualität, versuche ich das irgendwie mit den Ladezeiten so umzusetzen, dass wir SEO-mäßig an allen vorbei ballern.

So das sind die drei Sachen, die wir abgeleitet haben aus unserem Company-Set, wie die einzelnen Bausteine zusammenpassen. So, jetzt kann ich das möglicherweise nicht alleine, sondern ein ganzes Team hinter mir. Und die, dann nimmt auch wieder jeder irgendwie einen Teilbereich davon und das Kaskadieren heißt: Das, also die Grundidee ist so, dass wir möglichst trennscharf, nicht in diesem Nebel "Ja, die neue Website, das hat leider nicht geklappt, weil wissen wir auch nicht so genau", sondern wir können am Ende des Tages genau sagen, da der Engpass wahrscheinlich meine nicht vorhandenen Fotos sein werden und möglicherweise können wir es dann noch anders lösen, bevor es in die Hose geht. Oder wenn es in die Hose ging, wissen wir auf jeden Fall auch, wo die Ursache ist und was wir beim nächsten Mal anders machen können, damit das nicht so geht.

Das heißt, wir versuchen das große Ziel in Teilbereiche und Teilziele zu zerlegen, die möglichst trennscharf voneinander sind und wo jemand sagt: Ich verspreche A und andere das Team verspricht B und ein Dritter verspricht C. Und die Summe aus A, B und C wird hoffentlich zu dem führen, was wir uns oben vorgestellt haben.

Und das gleiche Modell lässt sich ja beliebig kleinteiliger runterbrechen, bis du irgendwann da auf der Ebene bist, wo du aufhörst. Nicht zu verwechseln mit: Ich mache 100 Millionen Umsatz ganz oben, sag dir in deinem Bereich 20 Millionen Euro und den anderen auch 20 Millionen Euro und die sagen dann: Okay, keine Ahnung, wie das gehen soll, ich verteile einfach 20 Ziele à eine Million Euro an die Leute unter mir, dann wird das schon irgendwie klappen. Dies ist nicht das, wovon wir reden, sondern es ist quasi ein inhaltliches Versprechen auf den Teil des Outcomes: Den hab ich, den hast du, den hat jemand anders. Und daraus resultiert irgendwas anderes. Und das ist ein Gegenstrom-Prinzip, nicht: Hier ist die Lösung und du sagst jetzt, was du tust, damit du das, was ich da oben hingeschrieben habe, damit ich dann sicher sein kann, dass du schon deine Hausaufgaben machst, sondern du kommst ja mit deinen Hausaufgaben und das ist vielleicht so Teil der zweiten Antwort.

Dieses Alignment oder dieser Entstehungsprozess ist gegenstromläufig, das heißt von oben nach unten und von unten nach oben idealerweise gleichermaßen und gleichzeitig. Das heißt, wir gehen davon aus, dass ich dir als Teamleiter bestimmte Rahmenbedingungen erklärt hab. Du weißt unser Geschäftsmodell, du kannst wie wir im Wind stehen, du kennst die Ressourcen, die du hast, du kennst die Strategien. Das heißt du weißt, wo wir die nächsten 1-2 Jahre hinsteuern, sehr explizit. Und du weißt genau, wie viel Leute du hast und das ist so ein bisschen auch diese Ressourcen-Planung.

Also du kennst ja deine Ausstattung. Das heißt: Der Rahmen ist fix. Die drei Monate sind gegeben und in der Regel fallen nicht neue Leute vom Baum. Das heißt, du kannst so ungefähr adressieren, wie viel Ressourcen du hast und jetzt ist ja nur die Frage, wie viel Ziele mappst du auf die Ressourcen, die du hast?

Sind es nicht andersrum so: Ah, ich habe so viele Ziele, wie kriege ich die denn alle erreicht? Sondern: Wie viel Ziel passt in das Quartal, weil das ist ja gegeben für die Anzahl der Ressourcen, die ich ja schon weiß, dass ich hier haben werde? Und dann kommst du damit und triffst auf meine Überlegungen, die von weiter oben kommen.

aus, dass die Teams nach Produkten schon gebaut und geschnitten sind. Und das heißt: Sobald du was in einem Produkt oder ein neues Produkt entwickeln willst, ist es kein Projekt, weil es ja schon alle Ressourcen hat, die es braucht, um sich selbst zu entwickeln.