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

In der AMA11 haben wir uns der klassischen Frage der Jahresziele und Ihrer Planung gewidmet und darüber gesprochen, wie man gute Key Results in der Software-Entwicklung formuliert. Darüber hinaus wurde diskutiert, welche Herausforderungen zu meistern sind, wenn die richtigen Voraussetzungen um OKRs einzuführen noch nicht geschaffen sind. Auch der Frage ob es sich lohnt, einen Veränderungsprozess als solchen in den OKRs abzubilden oder durch OKRs einzuleiten, sind wir nachgegangen.

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 

Da freue ich mich, dass ihr so zahlreich zur neuen Episode von AMA erschienen seid. Wir starten auch gleich mit schon fast einem Stammgast, würde ich sagen. XY du bist der erste auf der Liste, du kannst gerne anfangen.

0:00:21 Teilnehmer

Einen wunderschönen guten Tag zusammen. Ja, ich bin tatsächlich sehr häufig dabei, das mag sein. Das letzte Mal ist aber eine Weile her, oder?

0:00:30 Marco

Ja, aber das freut mich auch. Hoffentlich bringt es auch etwas. Das Thema scheint ja einen Ticker komplexer zu sein, als dass es mit einer Frage beantwortet ist. Das ist ja dann ganz hilfreich.

0:00:43 Teilnehmer-Frage: Wie sollten aus deiner Sicht die regelmäßigen Checkings auf Teamleiter- und Geschäftsführerebene ablaufen?

Effektiv. Also erstmal vielen Dank für das neue Angebot der Q&A Session.

Meine Frage geht so in Richtung der regelmäßigen Checkings auf Teamleiter- und Geschäftsführerebene, wenn es darum geht mal zu gucken, wie so der Fortschritt gewesen ist. Da stolpern wir im Moment noch so ein bisschen über verschiedene Problemchen. Es würde mich interessieren, wie dein best Practise-Fall aussehen würde und wie so ein Meeting sinnvollerweise abläuft.

0:01:15 Marco

Kannst du mir kurz sagen, ob ihr über den Ablauf stolpert oder vor allem darüber, dass das Meeting stattfindet oder nicht stattfindet?

0:01:27 Teilnehmer

Es findet jede Woche statt, wir treffen uns jede Woche in dieser Runde und wollen dann halt schauen, wo es Fortschritte und wo es Blockaden gegeben hat. Gleichzeitig möchte die Geschäftsleitung auch auf den aktuellen Stand gebracht werden und eben auch ihre Ziele aufgrund der neuen Informationen  entsprechend aktualisieren. Da haben wir noch keine schöne Struktur gefunden, die nicht fast zwangsläufig ins Unendliche führt.

0:01:55 Marco

Ja, kann ich dir beantworten. Der kritische Satzteil war, dass die Geschäftsführung auch wissen will, wie es steht.

Wir würden sagen, dass das dazu das falsche Meeting ist. Wir sagen ja, wenn du mit mehreren Leuten am Tisch sitzt, musst du natürlich dafür sorgen, dass die Zeit aller Anwesenden am besten eingesetzt wird. D.h., wenn sich einige wenige einen Überblick verschaffen wollen, ist das wahrscheinlich nicht für alle Anwesenden die am besten genutzte Zeit.

Dieser Teil gehört aus unserer Definition in die One and Ones zwischen Geschäftsführung und den jeweiligen Direct Reports. Daraus resultierend gibt es eine Vorbereitung auf das bevorstehende Meeting. Der Ablauf ist immer der gleiche, unabhängig von der Ebene. Die höchst anwesende Ebene der OKRs definiert das Meeting, also das wäre in dem Fall ja dann – wenn die Geschäftsführung anwesend ist – das Company-Set, und ist entsprechend auch so vorzubereiten, damit man aus dem Basiswissen, das man aus den One and Ones hat, zeigt: Hier komme ich gut voran. Deswegen ist es nicht so, dass das Confidence-Level der Company-Ebene in diesem Meeting gegraded oder herausgefunden wird, sondern das ist schon da und wir beleuchten sozusagen die Punkte, die entsprechende Aufmerksamkeit erfordern, um gelöst zu werden.

Also, das ist der erste zwingende Punkt: Die One and Ones dienen dazu, Transparenz herzustellen und festzustellen, wo wir eigentlich stehen. Das große Leadership-Meeting dient dazu, die Probleme aus dem Weg zu räumen und sich nicht erst einen Überblick zu verschaffen. D.h., die anderen Meetings müssen stattfinden und dann muss das Leadership-Meeting vorbereitet sein, und zwar mit den Sachen, die man diskutieren will, Team A, Team B, Team C, wir drei zusammen finden jetzt eine Lösung für diese Herausforderung. Damit ist die Zeit auf jeder Ebene am besten verwendet.

0:04:20 Teilnehmer

Das ist ein interessanter Ansatz, den hatte ich so noch gar nicht aufgeschrieben. Wir haben verschiedenste Varianten ausprobiert und auch mit unserer Software herum experimentiert. Doch wir sind zu keinem befriedigenden Ergebnis gekommen. Weil es entweder zu lang oder zu unübersichtlich war. Diesen Ansatz werden wir mal ausprobieren.

0:04:40 Marco

Ich habe ihn schon ausprobiert und er funktioniert eigentlich ganz gut!

Der Nachteil ist, dass man sich vorbereiten muss. Aber das ist halt so, wenn da 8, 10, 12 Leute am Tisch sitzen. Da geht dann ja richtig Zeit drauf. Also ist man ganz gut beraten, wenn man sich vorher vorbereitet und weiß, was man aus dem Meeting herausholen will und sich vorher schon die Informationen verschafft hat, die man braucht, damit das Meeting sauber ablaufen kann.

0:05:08 Teilnehmer

Ja, das macht Sinn. Macht ihr das dann auch wöchentlich oder macht ihr das vierzehntägig?

0:05:11 Marco

Wöchentlich.

Na ja, du willst ja die Probleme und die Blocker so schnell wie möglich aus dem Weg räumen. Wenn du nicht wöchentlich iterierst, dann hast du entweder zwei Wochen bis zur nächsten Entscheidung oder bis zum nächsten Gremium, an dem sich alle Beteiligten austauschen können. Oder du hast dauernd irgendwelche „kannst du mal grad“-Meetings. Wir brauchen hier, wir brauchen da, wir haben irgend so ein „Firefighting-Mode“. Erfahrungsgemäß kommen die ja doch während der einen Woche und wenn sie sowieso kommen, nur unstrukturiert, dann kann ich mir auch die Koordinationsaufwand sparen, dauernd spontan einen Termin finden zu müssen, wo ein paar Leute Zeit haben. Dann kann ich es auch einfach regelmäßig machen. Und falls wir feststellen: Oh Wunder, wir haben gar nichts zu besprechen! Dann macht jeder seinen Job weiter. Das ist ja auch kein Problem. Passiert gar nicht so oft, um ehrlich zu sein.

0:06:12 Teilnehmer

Das ist cool. Also vielen Dank.

Ich halte für mich jetzt fest: Von unten nach oben oder von oben nach unten:  One on One, und wenn dann quer irgendetwas zu besprechen wäre, das kommt dann ins Teamleiter-Meeting.

0:06:25 Marco

Genau. Das folgt ja gedanklich dem Subsidiaritätsprinzip: Du willst das Problem auf der kleinstmöglichen Ebene lösen. Wenn du und ich als Direct Reports z.B. das Thema schon aus der Welt schaffen können, warum sollen wir dann damit acht Leute damit belästigen?

0:06:43 Teilnehmer

Okay.

0:06:45 Marco

Das war jetzt ein Effizienz-Gedanke.

0:06:47 Teilnehmer

Vielen Dank.

0:06:48 Marco

Gern.

Dann nächste Frage.

0:06:52 Teilnehmer-Frage: Eignen sich OKRs als Instrument bei Veränderungsprozessen?

Dann bin ich der Nächste. Hallo.

Ich finde dieses Format genial. Echt super. Ich bin ja erst seit zwei Wochen auf dem OKR-Trip, aber jetzt so richtig, und finde das echt super.

Erst mal zum Einsteigen was meine Frage ist. Ich habe ein bisschen einen anderen Zugang, weil ich selbstständig bin. Ich berate Unternehmen schwerpunktmäßig bei New Work-Themen. New Work ist ein Riesenthema, das kann Agilität sein, das kann Employer Branding sein, was auch immer. Ich würde gerne diesen Bottom-Up und Top-Down-Prozess, der in den OKR drin ist, verwenden. Meine Frage wäre, ob ich jetzt OKRs für diesen Veränderungsprozess verwenden kann.

Beispiel: Es kommt eine Firma und sagt, sie möchte Digitalisierung machen und das soll ja etwas sein, das das gesamte Unternehmen betrifft. Sie haben aber keine OKRs. Ich würde aber gerne versuchen, diesen ganzen Veränderungsprozess auf OKR-Basis aufzuziehen und gleichzeitig auch als Leuchtturmprojekt fortgeschritten ist. Wir haben gesehen, dass es funktioniert, wir wollen jetzt überall OKRs einführen.

Aber generell wäre die Frage: Wenn ich jetzt nur diesen Veränderungsprozess habe und ich komme jetzt als Externer herein und sage, dass ich das gerne mit OKRs abwickeln möchte. Was hältst du davon?

0:08.12 Marco

OKRs kommen in traditionsreichen Unternehmen auf jeden Fall in einem Veränderungsprozess einher. OKRs sind der Katalysator für die Veränderung.

Wenn ich deine Frage richtig verstehe, willst du den Veränderungsprozess über OKRs steuern.

0:08:32 Teilnehmer

Ja, richtig.

0:08:35 Marco

Ich weiß nicht genau, ob man Veränderungsprozesse steuern kann. Keine Ahnung. Ich glaube meistens nicht. Wir glauben, die brauchen einen katalytischen Prozess und der findet durch OKRs statt. Also, dass du sagst: Wir brauchen eine Mission, Vision und Strategie und zwar eine, die was taugt und nicht den generischen Quatsch, der immer auf Power Point steht. Wir brauchen eine klare Zuordnung zu Teams und Personen und nicht ein theoretisches Organigramm, wo es ganz viele OKR-Sets gibt, aber gar keine Köpfe dahinter oder viel zu viele OKR-Sets für viel zu wenig handelnde Personen usw. Diese ganzen Rahmenbedingungen plus eine Kultur, in der offen und ehrlich miteinander umgegangen wird, und jemand, der versteht, dass Steuern in Unsicherheit etwas damit zu tun hat, dass ich von all dem auch keine Ahnung habe, sondern dass wir das zuerst Mal herausfinden müssen.

Das sind ja alles Rahmenbedingungen, die da drinstecken und OKRs zwingen dich, das in regelmäßigen Iterationen zu trainieren.

Als messbares Ergebnis damit abzubilden, wie gut du jetzt kulturell aufgeschlossen oder verändert bist, kann ich nicht beurteilen, glaube ich an der Stelle begrenzt daran. OKR als katalytisches Tool einzuführen, die Rahmenbedingungen zu erklären und dann über die Iteration die Kultur zu verändern, die Rahmenbedingungen glatt zu ziehen und anhand dessen zu zeigen, dass es anders besser geht. Da glaube ich nicht nur sehr daran, das machen wir in den Projekten immer so. Demzufolge ist der OKR-Prozess auf jeden Fall – wenn du jetzt nicht auf eine Start-Up-Kultur triffst – in der Regel ein Veränderungsprozess.

Damit hast du auch schon sozusagen auch schon deinen Piloten, also dass du auf den obersten beiden Ebenen mal sagst: Jetzt arbeiten wir mal ein, zwei Quartale mit OKRs und merken mal, was das mit uns macht und wo das vielleicht ein bisschen sperrig anfühlt. Dann nehmen wir auch wahr, wo ich mich denn verändern muss. Also, ich ganz persönlich als Führungskraft oder wo muss ich denn als Team vielleicht noch etwas am Schnitt ändern oder wie auch immer. Wenn ich das dann so ein bisschen erlebt habe, dann habe ich auch eine gute Vorstellung, was dieses ganze Veränderungsthema und New Work eigentlich heißen könnte. Und dann kann ich mich als Organisation entschließen, das in die Tiefe zu geben und gemeinsam auszurollen. Da kommt dann auch dieser Top-Down Bottom-Up Ansatz eigentlich gut ins Spiel, weil es eine Führungsetage schon erlebt hat und nicht nur darüber gelesen hat oder jemanden beauftrag hat, sich damit zu beschäftigen, sondern es halt auch wirklich angefasst hat.

Hilft das?

0:11:39 Teilnehmer

Ja, danke.

0:11:43 Marco

Cool. Dann der nächste Teilnehmer.

0:11:45 Teilnehmer-Frage: Ist es möglich, das Konzept „Roadmap“ mit OKRs zu kombinieren oder stoßen die sich gegenseitig ab? Wie sind deine Erfahrungen dazu?

Hi. Ich kann mich auch nur für das Format bedanken. Ich habe Ihre Seite schon des öfteren konsultiert, fand ich das Q & A…

0:11:54 Marco

Du warst das!

0:11:56 Teilnehmer

… ja, ja, ich war da.

Es kam mir vom Timing auch sehr gut, weil unsere Geschäftsführung eigentlich schon Anfang des Jahres wollte, dass OKRs jetzt implementiert werden. Ich habe dann immer wieder dumme Fragen gestellt und das hat sich jetzt einfach in die Länge gezogen, weil man einfach gemerkt hat, der Geschäftsführung ist noch nicht so ganz klar, warum wollen sie das eigentlich tun und sind ihre Motive wirklich passend für das Framework oder ist es doch eher ein Control Tool. Das führt dazu, dass wir grad in so einer spannenden Situation sind, dass sie einerseits Roadmaps total lieben und dabei ganz toll festhalten wollen, obwohl die in der Vergangenheit nicht so funktioniert haben, und jetzt irgendwie die Hoffnung haben, dass durch die OKRs jetzt endlich das Roadmap nochmals irgendwie mehr Fahrt aufnimmt.

Das finde ich alles ein bisschen komplex. Daher meine Frage vielleicht ein bisschen genereller: OKRs versus oder und Roadmaps – was ist da dein Erfahrungswert? Ich habe schon mal gelesen, dass die sich vertragen. Ich habe das Gefühl, dass das an manchen Stellen etwas redundant ist, wenn man beides macht. Aber wie gesagt, da fehlt mir einfach die Erfahrung. Roadmap versus OKR oder Roadmap und OKR.

0:13:13 Marco

Es stellt sich immer die Frage: Was definierst du als Roadmap? Du wirst Zeichnungen von uns finden, da kommt der Begriff „Roadmap“ auch darin vor. Er ist aber in keiner Weise so zu interpretieren, dass es heißt, ich sage dir jetzt, was in drei Quartalen passieren wird.

0:13:33 Teilnehmer

Das ist aktuell so, wie es gelebt wird oder sollte, also wirklich zeitbasierende Roadmaps: Wann kommt welcher Rollout der Software oder wann kommt welches wichtige Feature oder wann kommt welche wichtige Integration. Das war bisher der Inhalt der Roadmaps.

0:13:49 Marco

Lass mich noch eine Frage stellen: Jeder, der agil entwickelt und meistens sind das ja irgendwie die Software-nahen Teams. Die werden ja in diesen Roadmap-Prozessen von wem auch immer gezwungen zu sagen: Jetzt sag doch mal, wann ist denn nächstes Jahr Weihnachten. Und dann sagen sie etwas und dann stimmt das nicht. Das Spiel machen wir jetzt die letzten zehn Jahre und dann ist irgendeiner auf die Idee gekommen und hat gesagt: Ich sage dir nicht mehr, wann nächstes Jahr Weihnachten kommt, das stimmt nämlich sowieso nicht.

Das ist ja sozusagen die Grundidee der Agilität. Ich kann es dir nicht sagen, weil ich es nicht weiß. Ich habe so etwas noch nie gemacht, deshalb kann ich dir auch nicht sagen, wie lange es dauert und deshalb kann ich dir auch nicht sagen, wann es kommt.

0:14:25 Teilnehmer

Das kannst du aber bei Sachen sagen, die wir schon mal gemacht haben. Das ist nur ein Thema, ganz ehrlich, da reißt du andere Wunden auf. Das ist etwas, mit dem ich auch schon lange mit der Geschäftsleitung das Gespräch suche.

Das wissen die aber eigentlich.

0:14:42 Marco

Na ja, wissen und eigentlich und dann wissen wollen und die Konsequenzen davon ertragen, das sind wahrscheinlich auch nochmal unterschiedliche Paar Schuhe. Denn du musst doch sagen: Wenn wir doch wissen, dass es nicht stimmt, warum versuchen wir es dann trotzdem?

Es gibt Forschungen, die zeigen, dass sich der Mensch mit einer Straßenkarte von Paris in Athen wohler fühlt als wenn er gar keine Karte hat. Das macht aber nicht so viel Sinn, also offensichtlich sind da zwar auch Straßen und Bushaltestellen und weiß der Geier was drauf, aber er ist halt in der falschen Stadt.

Analog ist es mit der Roadmap ja auch ein bisschen so. Du hast eine Planung und du versuchst dann Marketing und Salesaktivitäten darauf abzustellen, aber am Ende des Tages hat es nicht gestimmt. War dann die Sicherheit, die ich aus dieser Roadmap ziehe unterwegs heilsam oder nicht?

Und jetzt muss man mal die grundsätzliche Frage stellen: Glaubt man in der obersten Führungsebene an das Thema Agilität oder glaubt man an das Thema „Ich weiß schon, wie es wird und ich kann das auch planen. Und wenn ich es nur oft genug plane, dann wird es schon klappen.“ Das ist ja so eine Grundsatz-Überzeugungsfrage.

0:15:55 Teilnehmer

Das ist richtig. Agilität wird als positiv benannt, selbst hält man sich aber nicht daran. Das hat aber auch mit den Geldgebern zu tun. Wir sind eigentlich eine IT-Bude von einer größeren Gesellschaft, die das Geld gibt. Das kommt noch hinzu.

Diese Grundsatzfragen:“ Wie wollen wir arbeiten? Wollen wir agil arbeiten? Brauchen wir eine Zeitplanung?“ liegt schon lange auf dem Tisch. Dazu kommt jetzt aber trotzdem das Thema OKRs noch mit rein. Ich konnte, wie gesagt, noch etwas auf die Bremse drücken, denn das wäre total unreif gewesen, das Anfang des Jahres einfach rauszuballern. Trotzdem sehe ich es auf uns zukommen. Plus eben die Roadmap-Geschichte. Die scheinen super davon überzeugt zu sein, deswegen wäre es einfach interessant gewesen, erste Erfahrungen zu berichten und zu sagen: Es bringt nichts, es ist doppelte Arbeit oder man hält es ganz toll, aber dafür muss man folgende Dinge beachten.

0:16:58 Marco

Na ja, wie gesagt, da stecken ja grundsätzlich unterschiedliche Überzeugungen drin. Also, wenn du sagst Roadmap-Prozess jetzt starten, ich sage dir, was in drei Quartalen wann kommt und ein agiles System. Das kann ja nur zu Spannungen führen. Irgendwo wird es zu Enttäuschungen kommen. Irgendwann muss man die Trauer erleben, dass die Planung nicht gestimmt hat. Entweder war sie zu gut oder zu schlecht, aber getroffen hat sie noch nie.

Jetzt muss man ja die Frage stellen: Was soll denn da rauskommen, wenn ich versuche, einen statischen Plan mit einem agilen System umzusetzen? Da ignoriere ich ja die Grundidee, dass man es nicht planen KANN und dass man deswegen das System umdreht. Wenn ich das jetzt versuche – egal, ich ignoriere die Grundannahme von einem agilen System. Da würde ich mich gerne fragen lassen, was denn die Grundhypothese ist und wohin das führen soll.

0:17:58 Teilnehmer

Ja.

0:18:00 Marco

Um deine Frage konkret zu beantworten: Das ist genauso blödsinnig, wie ein Budget vorzugeben oder einen Businessplan zu erstellen und drei Monate später zu sagen: Ja, aber vor 18 Monaten hatten wir gesagt, dass nächstes Quartal die Zahlen so aussehen müssen. Jetzt mach, dass das passiert. Das ist halt nicht Agilität in ihrer grundsätzlichen Idee von „Steuern in Unsicherheit - Wir wissen ja auch nicht genau, was passiert und lernen unterwegs, das besser anzupassen“.

Ich glaube, da musst du einfach die Grundsatzentscheidung mal herbeiführen, ob man das mag oder nicht. Wenn nicht, dann kann man ja auch weiter in der Roadmap-Idee bleiben und versuchen, das runter zu brechen und gucken, wie gut es trifft.

0:18:47 Teilnehmer

Ja, da bin ich bei dir. Ich glaube, ich bin ganz schön dran, am System zu rütteln, aber es gibt manche Stellen mit viel Macht, die da noch recht resistent sind.

0:18:58 Marco

Bring die mit!

0:19:01 Teilnehmer

Hierher?

0:19:03 Marco

Ja, die kannst du gerne hierher mitbringen. Dafür ist es ja da. Ich mache ja grundsätzlich nichts anderes, als in den Zentren der Macht ein bisschen rum zu rütteln.

0:19:09 Teilnehmer

Ja, ich habe ihnen auch dich bzw. eure Firma empfohlen, falls sie noch eine externe Expertise haben wollen. Mal gucken, vielleicht kommen sie auf euch zu.

0:19:19 Marco

Man kann ja auch einfach mal hier reinschleifen und gucken, das kann man ja mal mit mehreren Leuten diskutieren, da profitieren ja glaube ich einige davon. Das Problem hast nicht nur du.

Hilft dir das soweit?

0:19:30 Teilnehmer

Das hilft mir grundsätzlich erst mal weiter. Das ist noch mal so ein Punkt, den ich anklopfen kann oder eben diese Diskrepanz zwischen dem, was wir mit einer Roadmap erreichen und was für eine Haltung dahinter steht, und was OKRs sind. Das ist schon mal gut.

Ich habe noch eine andere Frage, aber ich glaube, wir machen erst mal weiter.

0:19:50 Marco

Kannst gerne später nochmals einsteigen.

0:19:52 Teilnehmer

Danke.

0:19:55 Marco

So, weiter geht es mit XY glaube ich.

0:20:00 Teilnehmer-Frage: Macht es Sinn, nur Jahres-Objectives zu definieren und die Jahres-Key-Results jeweils iterativ zu bestimmen?

Hi. Ich bedanke mich auch erst mal für das Format. Wir werden in zwei Wochen offiziell OKRs offiziell einführen und deswegen ist das  super hilfreich. Wir sind am Kämpfen. Wir waren eigentlich kurz davor, Jahres-OKRs einzuführen, die im Dezember zu bestimmen und uns im Januar dann für das 1. Quartal hinzusetzen. Jetzt haben wir selbst langsam gemerkt, irgendwie ist das voll kompliziert. Wenn wir Jahres-Objectives haben, dann ist das noch ok. Aber Jahres-Key-Results wollen wir natürlich nicht einfach nur auf Quartal eins, zwei, drei und vier runterbrechen, dann wären wir ja nicht agil. Das haben wir jetzt also auch verstanden. Trotzdem wollte ich wissen, was du da empfehlen würdest. Also unser Weg wäre jetzt, nur Jahres-Objectives zu definieren, damit wir wenigstens so eine grobe Richtung haben. Macht das Sinn oder ist das nicht so klug?

0:21:00 Marco

Also, wir glauben nicht, weil die grobe Richtung ja eine Strategie definiert. Wenn eine Strategie das macht, was eine Strategie machen soll, dann definiert sie die Richtung. Eine Strategie definiert einen Vektor, also quasi die Energie in eine bestimmte Richtung zu investieren. Ein Ziel hingegen definiert einen Wegpunkt. Wenn man sich der Diskussion von eben anschließt und sagt: Na ja, wir wissen es ja nicht so genau, wie es sich entwickelt und ob der Weg ein bisschen weiter links oder ein bisschen weiter rechts ist. Was soll ich denn sagen, damit ich in 12 Monaten genau da bin? Und daran auch festzuhalten, ohne iterativ etwas zu lernen?

Deswegen glauben wir, dass diese Jahresziele, diese Wegpunkte auf der Zwölfmonats-Achse, aus unserer Perspektive nicht so viel Sinn machen. Die Strategie sortiert, wohin es grundsätzlich geht, also sie gibt die Richtungen vor, wo wir unsere Energie investieren wollen. Dann ist die Logik ja, wir kommen, soweit wir können. Ich habe keine Ahnung, wo wir in 12 Monaten ankommen könnten, weil wir da ja wieder bei dieser Unsicherheit sind. Aber auf drei Monate kann ich das relativ gut abschätzen, dann kann ich nachjustieren und dann kann ich die nächsten drei Monate mit dem Gelernten der letzten drei Monate wieder schauen. Auf den unterschiedlichen Vektoren der Strategie komme ich am meisten nach vorne.

Man muss ja mit der Realität klar kommen. Der Realität ist es ziemlich egal, was in einem Zwölfmonatsplan steht. Hingegen kommen wir da an, wo die Organisation fähig war anzukommen. Das müssen wir halt aushalten, akzeptieren, ertragen, durchleiden, was auch immer. Wenn wir da mal durch sind, kann man sagen: Jetzt weiß ich, wo ich meine Energie investieren will und das mache ich iterativ Quartal für Quartal für Quartal. Nur dass ich dachte, dass ich dieses Jahr 10 Mio. Umsatz mache, macht es keinen Meter besser oder schlechter. Die Realität weiß das nicht.

0:23:17 Teilnehmer

Verstehe ich. Aber eigentlich glaube ich, dass wir das gleiche wollen. Wir wollen ja diese Richtung vorgeben.

0:23:22 Marco

Ja, nur eine Strategie ist kein Ziel. Eine Strategie sagt mir, in welche Richtung du dich bewegst. Nicht, was du in 12 Monaten erreicht haben willst.

0:23:36 Teilnehmerin

Das heißt, wir können jetzt im Dezember, wenn wir dieses Meeting haben, sollten wir eher bestimmen, in welche Richtung es gehen sollte.

0:23:46 Marco

Genau. Die Strategien für die nächsten 12-18 Monate festlegen und dann auf einer iterativen Basis zu sagen: Jetzt kennen wir unsere 18 Strategien. Jetzt fragen wir uns mit dem, wo wir gerade sind und was wir gerade haben: Wo kann ich in den nächsten drei Monaten mit der Energie, die wir zur Verfügung haben (Manpower, Budget etc.), die größtmöglichen Schritte in diese Richtung machen. Das versuche ich jedes Quartal iterativ wieder zu machen und immer wieder den Blick auf die Strategie zurück zu führen und zu fragen: Ist das noch immer die richtige Richtung? Vielleicht muss man das aus dem Gelernten auch anpassen? Aber wenn wir sagen, das passt noch, dann fahren wir in dieser strategischen Richtung weiter und überlegen uns von Quartal zu Quartal weiter, was ich als konkretes Ziel dafür tun kann, damit ich hier so weit wie möglich vorankomme.

Denn, du willst ja nicht ein Ziel formulieren, das 12 Monate Bestand hat. Es gibt schon auch Leute, die das sagen, aber wir glauben, dass das nicht so gut funktioniert. Du willst ja innerhalb der drei Monate beweisen, ob das Ziel dazu beiträgt, deine Strategie sozusagen positiv zu untermauern oder sich in die Richtung fort zu bewegen. Wenn du daran aber 12 Monate festhältst und an den Zielen nichts änderst und das nicht in drei Monate unterteilst, sondern in 12 Monate, wirst du auch in sechs Monaten nicht feststellen, dass das Ziel falsch ist, um die Strategie zu bewegen. Demzufolge ist der Lernprozess einfach auf einer Jahresscheibe und nicht auf einer Quartalsscheibe.

Du musst die Hypothesen so bauen, dass du iterativ innerhalb des Quartals abgeschlossen sagen kannst, die Key-Results haben zu den Ojectives geführt und das Objective hat deutlich einen Sprung in die richtige Richtung auf der strategischen Achse geführt. Wenn du das beweisen kannst, geht es da weiter. Wenn du festgestellt hast, die Energie war es nicht wert, dann hör auf und mach etwas anderes.

Klarer?

0:26:00 Teilnehmer

Ja. Mir würde ein Beispiel helfen, um zu verstehen, was jetzt der große Unterschied ist. Abstrakt gesehen kann ich sagen, Objectives sind eher das Was und die Strategie ist eher das Wie und die Richtung, wo wir hinwollen. Aber vielleicht hast du spontan ein Beispiel, damit ich das besser verstehen kann?

0:26:19 Marco

Sag mal zwei Sätze zu eurer Firma, was ihr so macht.

0:26:25 Teilnehmer

Wir sind eine Unternehmensberatung mit Fokus Projektmanagement.

0:26:30 Marco

Kenn ich mich zufällig aus. Du müsstest jetzt unterschiedliche Theorien haben, welche Probleme im Bereich Projektmanagement die Leute da draußen haben. Dann müsste es ja Möglichkeiten geben, das ein Stück weit zu „produktisieren“ und zu sagen: Wir haben folgende Ideen, Ausbildungsformate und Framework-Ansätze. Wenn wir bewiesen haben, dass – ich mache jetzt ein Beispiel aus unserer Welt – ich hundert Mal im Jahr in der Gegend herumgefahren bin und habe so eine Masterclass vorgetanzt. Ich habe dann irgendwann festgestellt, dass das a) ganz schön anstrengend ist und b) kann ich mich selber nicht mehr motivieren. Folglich muss da ein anderer Ansatz hin. Dann war klar, wir müssen die Strategie irgendwie skalierbarer gestalten, dass nicht einige wenige Personen durchs Land fahren und den „Basiscontent“ stumpf und Frontalunterrichts-massig verbreiten, sondern wir brauchen da für den reinen Knowhow-Transfer irgendwie eine skalierbare Lösung. Strategie Knowhow-Transfer muss total skalierbar und ohne 1:1 Interaktion oder 1:n Interaktion stattfinden. Wenn 1:n Interaktion stattfindet, muss das irgendwas mit einer Interaktion zu tun haben. Das wär die Strategie.

Der dreimonats-Block daraus abgeleitet war: Wir müssen beweisen, dass sich das mit einem Onlinekurs machen lässt. Also haben wir in drei Monaten einen Onlinekurs produziert und haben gesagt: In drei Monaten erklärt keiner mehr so grundsätzlich, wie denn OKRs geht, sondern jeder, mit dem wir arbeiten, muss das quasi einmal anschauen. Und danach stellen wir fest, ob die gewonnene Zeit zur deutlichen Steigerung der Qualität der Workshops führt oder ob wir eigentlich dastehen und das, was wir glauben, dass es sich jemand anders schon digital beigebracht hat, eigentlich wiederholen müssen, weil das Produkt nicht funktioniert hat. Das zu beweisen ist ein dreimonats-Ziel gewesen, dass wir es hinkriegen, dass wir es danach nicht nochmals erklären müssen, sondern dass das irgendwie digital transportiert werden kann. Danach kommt der nächste Schritt, was machst du dann auf dem skalierbaren digitalen Weg.

Macht es das klar?

0:29:16 Teilnehmer

Ja, total. Verstanden, danke.

0:29:19 Marco

Sehr gut.

0:29:21 Teilnehmer

Ich habe auch nochmal eine Frage, aber ich stelle mich auch hintendran.

0:29:23 Marco

Nein, mach direkt noch mit!

0:29:25 Teilnehmer-Frage: Was kann den in der agilen Produktentwicklung ein gutes Key-Result sein?

Ja, ganz schnell. Ich habe nicht ganz verstanden: In der agilen Produktentwicklung, wenn ich jetzt eine Software entwickle, was kann ein gutes Key-Result sein? Weil Key-Results meiner Meinung nach nie agil sind, weil das Ergebnis dann ja feststeht. Also beispielsweise wäre jetzt ein gutes Key-Result: Ich möchte die Funktionen Log-In, Startseite und Kundenseite fertig haben.

0:29:53 Marco

Nein. Aber ein Schritt zurück: Es ist agil, wenn das Ergebnis feststeht, nur der Weg nicht. Also, wir bauen ja eine Hypothese, dass wir sagen: Wir glauben in der Range könnten wir mit den Ressourcen, den Mitteln, dem Knowhow und dem heutigen Wissenstand, die wir haben, Ergebnisse erzielen. Das ist ja gegeben und wir wissen, wann wir happy und wann wir nicht happy sind. Das macht ja die Skala am Key-Result. Was jetzt genau herauskommt, wissen wir auch nicht, aber wir wissen, in der Range 70-100 wäre es cool und das müsste machbar sein. Sonst würden wir die Hypothese so nicht bauen. Wir können uns total irren, aber grundsätzlich ist das mal so die Annahme.

Wenn du auf „Feature fertig“ oder was auch immer zielst, dann hast du ja nicht den Nutzen definiert, sondern du hast halt was gemacht. Aber dass man was gemacht hat, hat ja noch keinem etwas gebracht.

Die Frage ist, hat ein Log-In Feature dazu geführt, dass a) alle Inhalte geschützt waren und b) die Leute, die da reinkommen wollten auch reinkamen oder gab‘s 47'000 Anfragen beim Customer Care Team mit „Hier ist so eine Wall, da kommen wir nicht durch.“ Und wie sicher ist das.

Das sind ja wahrscheinlich die Ergebnisse, die man zu adressieren versucht. Also das Finale ist so ein bisschen User-Story-Denken. Was bringt das Ganze und das versuchen, in einer skalierbaren Metrik zu definieren.

0:31:44 Teilnehmer

Ja, richtig. Ok, cool, vielen lieben Dank. Das hat mir sehr geholfen.

0:31:48 Marco

Gern. Dann kommen wir zur nächsten Frage.

0:31:55 Teilnehmer-Fragen: 1) Macht es Sinn, OKR nur in einem Pilotbereich einzuführen oder sollte das gleich im ganzen Unternehmen geschehen. Was ist eure Erfahrung bzw. Empfehlung dazu? 2) Sollte für die Einführung von OKR ein externer Berater herbei gezogen werden oder sollte sich das Unternehmen zuerst alleine damit auseinander setzen?

Ja, hallo. Erst mal Danke für das Format. Das ist irgendwie ganz cool. Wir haben gestern das erste Mal mit der Geschäftsleitung über OKRs diskutiert und heute läuft mir das Format über den Weg.

0:32:08 Marco

Gutes Timing.

0:32:10 Teilnehmer

Gutes Timing oder hat irgendjemand zugehört.

Wir stehen ziemlich am Anfang und wir haben die Idee, mit OKR unser relativ oldfashioned statisches jährliches Zielsystem abzulösen. Das ist jetzt eher aus dem HR heraus, aber die Geschäftsleitung ist mehrheitlich mit dabei, weil sie auch weg wollen von diesem jährlichen Targetsetting-Thema. Jetzt haben wir überlegt, ob wir das Thema erst mal in einem Pilotbereich einführen und das dann irgendwie naheliegend in der Entwicklung oder ob wir das nicht gleich im ganzen Unternehmen einführen sollten. Denn wenn wir was in einem Pilotbereich machen, wie synchronisieren wir dann das Thema „Ziele und Ausrichtung“ im gesamten Unternehmen, dass das zusammen spielt? Da wäre meine Frage, was eure Empfehlung oder eure Erfahrung dazu ist, ob man das durchaus in einem Piloten starten sollte oder ob man das dann über das ganze Unternehmen zieht.

Die nächste Frage, die ich anschließend habe, lautet: Wäre es nicht besser, wir würden uns da jemanden zur Seite holen, der uns ein bisschen bei der Einführung hilft und auch den Teams unter die Arme greift oder sollten wir erst mal mit Trial & Error selber loslegen?

0:33:39 Marco

Machen wir die Fragen nacheinander. Die erste Frage ist nach der Pilotierung:
Die Pilotierung mit drei von der IT-Abteilung zum Beispiel macht i.d.R. wenig Sinn, weil alle werfen ihre Wünsche auf die IT-Abteilung und die Frage ist ja: Welche Ziele sollte die IT verfolgen? Es müssen ja alle darum herum definieren. Die IT-Abteilung kann das ja nicht sozusagen alleine entscheiden, sondern es ist ein Company-wide decision making process. Also, du musst alle Möglichkeiten, die IT-Unterstützung brauchen, in die Überlegung miteinbeziehen. Danach ergibt sich, was die Prioritäten auf IT-Seite sein sollten. Die Pilotierung der Umsetzungsabteilung, wenn es denn so geschnitten sein sollte, das macht recht wenig Sinn.

Wir haben gute Erfahrungen damit gemacht, die Pilotierung auf den oberen beiden Ebenen zum Beispiel zu machen, also die gesamte Breite abzufahren und dann zu sagen, wir brechen das noch nicht in alle Teams oder Abteilungen runter, sondern wir lassen es auf dem Level 1 und 2 und haben damit die Diskussionen geführt, was die wichtigsten Topics sind und was nicht. Das kann man dann sozusagen einem IT-Team übergeben und kann so sagen: Schau das sind die wichtigsten Key-Results die ihr verfolgen müsstet, bitte. Also, da waren wir ja alle dabei, das wurde ja gemeinsam diskutiert. Wenn man damit gute Erfahrungen hat, dann kann man das im nächsten Quartal auch runter brechen.

Die zweite Frage ist, sollte man das alleine machen oder sollte man das mit externer Begleitung machen. Ich weiß nicht, ob ich die richtige Zielgruppe bin, die du das fragen solltest. Aber grundsätzlich würde ich sagen: Wenn man es kann, sollte man’s alleine machen. Wenn nicht, ist es hilfreich, wenn man jemanden fragt, der das schon mal gemacht hat. Das Risiko, es alleine zu machen, ist: Das Ding ist komplexer, als es aussieht. Man kann eine Menge verbrennen. Wenn man zum zweiten oder dritten Mal kommt und sagt: Hey, wir machen jetzt OKRs, aber diesmal richtig. Jetzt haben wir echt verstanden, wie es geht, vorher nicht so ganz. Dann könnte es sein, dass der eine oder andere denkt: Jetzt habe ich aber keinen Bock mehr.

Wenn man das verhindern will, dann müsste man sich vorher gut damit auseinander setzen, wie das geht und was man damit erreichen will. Wenn man sich dann selbstsicher genug fühlt, das alleine zu machen, halte ich das für total machbar. Wenn man hingegen sagt: Puh, da sind wir früher schon ein bisschen hängen geblieben. Das ist ja ein massiver Change-Prozess, der berührt so etwas wie Mission, Vision-Strategie, Aufbauorganisation, Kultur, eine Menge Egoprobleme… Da steckt schon intellektuell ein bisschen was drin, wenn man Hypothesen getrieben arbeiten soll, etwas, das man vorher noch nicht gemacht hat.  Das sind eine Menge Handlungsfelder, da ist es hilfreich, wenn man es vorher schon einmal gesehen hat.

So würde ich das mal möglichst neutral beantworten.

0:36:48 Teilnehmer

Zu diesem Pilotansatz nochmal: Würdest du das dann pilotieren, aber wirklich dann z.B. auf erster und zweiter Ebene konzentriert und die Teams drunter mal rauslässt, dafür aber über die gesamte Unternehmensstrategie und –ziele. Weil die ja ineinander spielen.

0:37:06 Marco

Ja, die komplette Breite abbilden, nicht aber die Tiefe.

0:37:15 Teilnehmer

Danke.

0:37:16 Marco

Gerne.

Dann geht es mit XY weiter.

0:37:22 Teilnehmer-Frage: Sollen Key-Result-Owners die Retros alleine moderieren?

Ja, hallo. Schönen guten Tag. Vielen Dank für die Einladung.

Wir sind ein Versandhändler und arbeiten schon im dritten Jahr mit OKRs. Klappt auch wirklich gut, die Geschäftsleitung hat das initiiert und steht voll dahinter. Wir haben Unternehmens-Sets mit ungefähr 20 Bereichs-Sets und es wird auch sehr viel Wert auf Retros gelegt. Am Anfang hatten wir pro Quartal vielleicht fünf Retros, da war das natürlich ganz gut abbildbar. Wir haben zwei HR-Coaches und hatten auch externe Unterstützung.

Inzwischen ist es aber so, dass wir eigentlich, wenn es jeder so macht, wie es auch angedacht ist, an die 25 Retros pro Durchgang haben, vielleicht sogar doppelt so viele, je nachdem, ob man eine Retro alle sechs Wochen oder alle drei Monate ansetzt. Das ist natürlich schon ein großer administrativer Aufwand. Es ist so, dass die HR-Coaches das nicht mehr alleine schaffen können. Jetzt sind einige Key-Result-Owner auf die Idee gekommen, diese Retros alleine zu moderieren. Dazu wollte ich gerne deine Meinung hören.

0:38:40 Marco

Ich muss vorher zwei Sachen glatt ziehen. Das eine ist – nur so um ein gemeinsames Verständnis hinzukriegen – Retro ist eher, wie wir zusammen arbeiten, Review ist eher, wie wir die Ziele erreicht haben und warum nicht.

0:39:00 Teilnehmer

Richtig. Es geht um die Zusammenarbeit innerhalb des Teams. Zuerst wurde das jeweils am Ende des Quartals gemacht, um eben Learnings für die nächsten Key-Results zu ziehen. Und jetzt wird gebeten, dass das alle sechs oder sogar alle vier Wochen passieren sollte, damit man innerhalb des Key-Results auch schon von den Learnings in der Zusammenarbeit profitieren kann.

Die Frage ist eben: Braucht man dafür einen externen Moderator oder kann das der Key-Result-Owner oder vielleicht der Mentor, der dem Key-Result-Owner zur Seite steht, machen.

0:39:39 Marco

Also grundsätzlich  glauben wir, dass jede Führungskraft in der Lage sein sollte, Review und Retro sauber durchzuführen, weil das ja die DNA des Arbeitens einer Führungskraft ist. Du hast zwei Dimensionen. Die eine ist: Passt hier strukturell, kulturell oder in Bezug auf die Zusammenarbeit etwas nicht? Oder passt hier was intellektuell nicht, nämlich die angestrebte Ursache führt nicht zu der Wirkung, die wir uns vorgenommen haben.

Demzufolge ist es hilfreich, wenn du einen Bereich verantwortest, dass du die beiden Dimensionen langfristig abdecken kannst. Auf dem Weg dahin gibt es sicher Schritte, das gemeinsam zu erlernen, das ist die eine Perspektive. Die andere ist, eine Perspektive von außen zu haben, ist total hilfreich, solange du nicht eine Kultur hast, die sowieso eine Außenperspektive einnimmt. Wenn du eine Groß-Mindset-Kultur hast guckst du ja immer mit einer Brille von außen auf dich selber und versuchst das zu simulieren.

Um es konkreter zu machen, ich glaube, es ist ausreichend, einmal im Quartal so eine richtige Retro zu machen. Ich glaube, die darunter liegenden Learnings, die kannst du ja tagtäglich mitnehmen. Natürlich können wir feststellen: Oh, da fehlt jemand im Verteiler oder da ist irgendwie kulturell etwas gerade im Argen, dann können wir uns hinsetzen und Kaffee trinken und das lösen. Damit muss ich ja nicht bis zum offiziellen Format warten. Aber die Formate überzustrapazieren, ist wahrscheinlich an der Stelle schwierig. Das könnte so ein Stück der Ausweg für euch sein, dass man sagt, die kleineren Topics sortiert das Team selbst und die größeren Learnings auf dieser Quartalsebene, da kriege ich nochmal einen Blick von außen und werde sozusagen nochmal gechallenged, um das noch ein Stück offener oder mit Abstand zu betrachten, als ich das vielleicht bisher schon getan habe.

0:42:00 Teilnehmer

Prima. Wunderbar, Dankeschön.

0:42:04 Marco

Ich habe eine Gegenfrage: Was ist ein Key-Result-Owner?

0:42:10 Teilnehmer

Das ist der Inhaber des Key-Results. Wir haben das Unternehmens-Set oder das Bereichs-Set. Das Unternehmens-Set hat beispielsweise drei Objectives und da darunter sind eben Key-Results. In unserem Fall vom Unternehmens-Set sind das neun. Jedes Key-Result hat einen Key-Result-Owner, der eben das Key-Result zusammen mit seinem Team leitet.

0:42:47 Marco

Wir glauben, das ist Quatsch.

0:42:50 Teilnehmer

Warum?

0:42:52 Marco

Ich habe das schon ganz oft gesehen. Wir haben damit bei XY angefangen, dass das genau dazu führt, dass ich als CEO all meine Probleme weg delegiert habe, weil der Einzige, der dafür verantwortlich ist, kann nur ich sein. Ich bin für den Laden verantwortlich – Ende der Geschichte. Verantwortlichkeit lässt sich nicht delegieren. Erster Teil der Wahrheit.

Zweiter Teil der Wahrheit ist der Teil, den XY gesagt hat: Dann sitze ich ja nur da und sage: Ach, ist ja dein Key-Result, aber erzähl mal, wie läuft es denn. Ich habe es ja delegiert.

Der dritte Teil der Wahrheit ist, ich habe etwas delegiert, was sich auch inhaltlich nicht delegieren lässt, weil jemand, dem ich das delegiere, kann es gar nicht durchholen, aus der Definition der Rolle, sonst wäre er oder sie nämlich nicht CEO.

Ich gebe dem Marketingleiter etwas, weil das eher etwas aus der Ecke Marketing ist. Jetzt muss der mit der Vertriebschefin eigentlich etwas entscheiden. Aber das kann er gar nicht entscheiden, weil er ja gar nicht in der Lage ist, das zu entscheiden. Wie soll er denn jetzt die Verantwortung dafür übernehmen, wenn es außerhalb seines Entscheidungsbereichs liegt?

In meiner Welt funktioniert das viel besser, wenn man sagt: Es gibt nur einen Owner eines OKR-Sets. Punkt. Und ein CEO verantwortet das Company-Set. Eine Marketingleiterin verantwortet das Marketing-Set. Und jetzt schauen wir, was aus dem Set der Marketingleiterin zu dem Company-Set beigetragen werden kann. Hier ist die Schnittstelle zwischen der Verantwortung sauber geregelt, weil zu den Sets auch Ressourcen und Geld usw. gehören. Dann geht das Spiel total gut auf und es ist auch so trennscharf, dass am Ende jeder das, was er verspricht, auch erreichen kann. Weil er darüber in der Lage ist, Entscheidungen zu treffen, und nicht die ganze Zeit im Randbereichen mit rumwurstelt, in denen er nichts zu suchen hat.

0:45:07 Teilnehmer

Interessanter Ansatz. Ich gebe dir Recht, die Bereich-Sets werden von den Bereichsleitern verantwortet, das ist so. Damit haben die ihren Bereich unter ihrer Kontrolle. Bei den Unternehmens-Sets müssten wir vielleicht nochmals 1:1 darüber sprechen. Das funktioniert eigentlich wunderbar. Wir daten uns in wöchentlichen Meetings up, da ist die Geschäftsleitung immer dabei. Und die Planung ist natürlich auch zusammen gemacht worden. Es wird niemand…

0:45:33 Marco

Das ist schon klar, aber was ist denn noch die Rolle der Geschäftsführung in dem Modell. Weil dann gehe ich auf den Golfplatz.

0:45:39 Teilnehmer

Na ja, es ist so, dass jeder Key-Result-Owner einen Mentor hat. Das ist oft ein Mitglied der Geschäftsführung, das den Key-Result-Owner berät. Und im weekly, das ist immer 20 Minuten einmal pro Woche, wird über jedes Key-Result kurz geredet. Da kann das sein, dass der Geschäftsführer im Nachgang doch noch den einen oder anderen Gedanken an den Key-Result-Owner gibt.

0:46:05 Marco

Über den Zaun würfeln sozusagen. Dann ist es nämlich plötzlich gar nicht mehr so wie Mentoren und Berater. Gut, ich bin sehr pauschal in meinen Aussagen, ich kenne den vorliegenden Fall auch nur begrenzt.

Unsere Erfahrung ist: Es funktioniert nicht. Das hat auch irgendwie eine komische Rollendefinition, weil ich nun mal als CEO nicht der Mentor oder der Berater bin. Ich bin für die ganze Nummer verantwortlich. Demzufolge muss ich auch die Verantwortung übernehmen. Dass ich natürlich mein Unternehmen so baue, dass die alle möglichst ohne mich klar kommen, ist per Definition moderner Führung ja selbstverständlich. Natürlich sage ich: Ich stehe euch nicht im Weg. Und natürlich sage ich: Ich komme eher aus einer Coaching-Perspektive. Damit alle anderen sozusagen ihre Ziele erreichen, tu ich noch das nötigste, den Rahmen zu halten, die Learnings zu generieren und Knowhow zur Verfügung zu stellen, wo es vielleicht noch nötig ist. Aber wir haben es zumindest oft erlebt, dass es ist dann alles so nett Mentoren-mäßig heißt, aber am Ende des Tages hat es dann entweder ein Ownership-Thema oder es ist gar nicht so Mentoren-mäßig. Irgendwo dazwischen. Das aufzulösen kann heilsam sein. Wenn ihr damit kein Thema habt…

0:47:29 Teilnehmer

Also, wir haben bis dato eigentlich gar kein Thema. Trotzdem kann man sich darüber nochmal Gedanken machen. Ich nehme das einfach mal mit. Dankeschön.

0:47:37 Marco

Falls ihr das mal anders ausprobiert, würde mich freuen zu hören, was dabei herauskam.

0:47:42 Teilnehmer

Das machen wir. Danke dir.

0:47:47 Teilnehmer-Frage: In welchem Verhältnis stehen KPIs, Key-Results und OKRs zueinander?

Gut, ich glaube, ich bin die nächste. Ich hatte meine Frage schon in den Chat reingeschrieben.

Wir sind, zufälligerweise wie die XY, denn wir sind auch eine Tech-Company, gerade dabei OKR einzuführen. Wir haben uns in den Vorbereitungen auch gefragt, wie denn dann die Rolle von KPI zu Key-Results ist. Also, wir haben immer KPIs definiert und ich hätte auch nicht das Gefühl, wir müssten davon weg. Wir können das schon weiterhin machen. Die Frage, die ich mir stelle, ist: Wie können Key-Results und KPIs bzw. OKRs und KPIs gut nebeneinander funktionieren. Was muss ich dabei beachten, wie muss ich auf die beiden Themen blicken, dass die gut zusammen funktionieren und nicht irgendwie gegeneinander oder sich gegenseitig obsolet machen.

0:48:28 Marco

Ganz einfache Antwort: Das KPI wohnt auf der Ebene der Strategie. Das KPI ist der messbare Zeiger, den ich in mein Dashboard baue, der die Veränderung der Strategie irgendwie zeigt. Key Performance Indikator - wie der Name schon sagt, hat ein Indikator keinen Erwartungswert, sonst wäre es ein Goal. Also habe ich einen lockeren Zeiger in ein Dashboard gebaut, der zu den Strategien passt. Das ist ein guter Indikator um anzuzeigen, ob ich auf dem Weg, den wir vorher auf dem Strategie-Layer beschrieben haben, in die richtige Richtung fahre. Wo ich da in 12 Monaten bin und wie der Zeiger steht, weiß ich nicht. Es gibt KPIs, die rauf müssen, und es gibt KPIs, die runter müssen. Viel mehr gibt’s nicht.

Jetzt musst du sagen: Wie schaffe ich es denn, die, die hoch müssen, mit der wenigsten Energie nach oben zu kriegen, und die, die runtermüssen, mit der wenigsten Energie nach unten zu kriegen. So weit, wie es geht. Am Ende des Tages ist das ganze Spiel ja ein Optimierungs-Spiel. Das ist eine äußerst komplexe Maschine, die Teile stehen alle im Verhältnis zueinander. Wenn ich an der linken Seite etwas ziehe, passiert rechts außen irgendetwas. Das vorherzusagen grenzt gegen unmöglich. Deswegen versuchen wir es erst gar nicht.

Wichtig ist, dass ich die Ursache- / Wirkprinzipien herausfinde. Wenn ich links ziehe, bewegt sich rechts was. Und wenn ich an dem ziehe, bewegt es sich mehr, wenn ich an jenem ziehe, bewegt es sich weniger. Wenn ich die zwei Sachen mache, gehen die zwei Zeiger in die richtige Richtung. Das will ich herausfinden, um dann die Sachen zu machen, wo sich die Zeiger ja am schnellsten in die richtige Richtung bewegen. D.h., das KPI ist der Zeiger im Dashboard, das zur Strategie gehört. Das OKR ist auf der Quartalsebene eine Hypothese, wo das O abgeschlossen ist und dann den Zeiger bewegt. Die Key-Results sind die Wetten, die dazu führen, dass das O abgeschlossen wird.

Du hast also mehrere Hypothesen, bzw. mehrere Objectives, die dazu führen, damit sich die einzelnen Zeiger in die richtige Richtung bewegen und du glaubst, dass die drei oder vier Key-Results dazu führen, dass die Objectives Wirklichkeit werden. Damit kannst du Hypothesen getrieben arbeiten. Nach drei Monaten kannst du sagen: Objective erfüllt, Zeiger hat sich nicht bewegt, hier geht es offensichtlich nicht lang. Oder: Objective erfüllt, aufgrund von Key-Results eins und drei, die anderen zwei waren es offensichtlich nicht, aber auch das ist gut zu lernen. Zwei Zeiger haben sich in die richtige Richtung bewegt – hier müssen wir weiter arbeiten, um dieses Verhältnis von „Ich mache etwas und woanders passiert etwas“ so zu entscheiden, dass ich die Sachen zuerst mache, wo sich am wenigsten Arbeit am meisten bewegt.

Klingt leider ziemlich komplex – ist es in der Realität auch. Aber wenn man es mal so auf einer systemischen Ebene versteht, kann man sich da rantasten und es funktioniert sogar.

0:51:54 Teilnehmer

Ja. Ich glaube vor allem, dass wir noch mehr Zeit investieren müssen, um überhaupt erstmal die richtigen KPIs zu definieren. Denn von dem, was ich jetzt gerade gehört habe, habe ich das Gefühl, unsere sind vielleicht relativ Standard und vielleicht sollten wir erstmal den Schritt zurückgehen und überlegen: Strategie, dann, was sind die KPIs und das zu messen und dann überlegen, was unsere OKRs im ersten Quartal sein könnten, um in die Richtung zu gehen. Für das, was ich jetzt grad gehört habe, haben wir die KPIs ein bisschen zu klein gemacht.

0:52:22 Marco

Ich darf dir verraten, dass sowas wie „billable hours“, Umsatz, Auslastungsquoten oder EBIT-Beitrag, das ist alles Lagging, das ist langweilig. Das wirst du irgendwann beobachten können, wenn es passiert ist. Aber wenn du’s beobachten kannst, ist es zu spät. Du brauchst etwas Leading, du musst gucken, was dazu führt, dass ich zu einer Bilebilauer, zu einer Auslastungsquote, zu einem Verkauf von irgendwas, etc. komme. Der Rest kommt schon, kannst du schon auch angucken, vor allem finanziell, dass das ganze Puzzlespiel hinten raus passt. Aber das ist nicht das, wonach du steuerst. Du steuerst nach den Leadingindikatoren und wenn du die sauber definieren kannst, dann kannst du ja auch sagen, wo du deine Energie investieren willst. Wenn du das nicht weißt, könnte jede Wette gut sein, könnte aber auch nicht gut sein. Aber wir haben ja keine Hypothese, worauf soll sich das denn gesamthaft positiv auswirken? Nur zu sagen, auf den Umsatz, ist halt schlussendlich ein multivarianter Test, weil sich alles irgendwie mittelbar und unmittelbar irgendwann mal in Umsatz und Kosten auswirkt. Aber aus multivarianten Tests kann man nicht so viel heraus ziehen.

Klarer geworden?

0:53:40 Teilnehmer

Ja. Vielen Dank.

0:53:48 Marco

XY bitte?

0:53:50 Teilnehmer-Frage: Wer bestimmt denn, was eine Supportfunktion ist? Wer teilt diese wem zu?

Jetzt habe ich noch eine Frage zu den Support-Funktionen. Es gibt ja dieses Extra-Sheet, wo man vorher in der ersten Spalte die aktiven Aufgaben einträgt, dann gibt es die zweite Spalte, wo man sagt, das sind Supportfunktionen, die zu klein für ein Key-Result sind und zusammen gefasst werden. Meine Frage wäre: Wer bestimmt denn, was die Supportfunktion ist? Oft kenne ich, dass dann einer sagt, das sei eine kleine Aufgabe, der andere meint, das sei eine große Aufgabe. Wer teilt die denn zu? Ist es so, dass der Manager oder einer aus der Führungsmitte mit den Objectives kommt und schon weiß: Da habe ich ein ganzes Set von Supportfunktionen, die teile ich jetzt irgendjemandem in meinem Team zu.

0:54:32 Marco

Nicht das Team. Das ist Eye-Level. Die Funktion dieser Spalten nennt sich „crossfunctional Alignement“, d.h. auf Augenhöhe, deine Peers sozusagen, z.B. Marketing und IT-Abteilung.

Sagen wir, ein Newsletter-System muss neu eingeführt werden. Marketing hätte das gerne, IT muss das aber irgendwie unterstützten, weil Marketing mit der Anwendung alleine nicht klar kommt. Jetzt ist ja die Situation die: Einer möchte etwas und der andere muss helfen. Jetzt muss man erstmal herausfinden, wer das möchte. Marketing möchte das und zwar müssen die ja nicht sagen: Ich will ein neues Newsletter-System. Sondern die müssen sagen: Am Ende des Quartals kann ich irgendwie jedem in unserem Verteiler eine Geschichte erzählen, die ihn auch wirklich interessiert. Ich kann Zielgruppen genau targeten oder was auch immer. Das konnte ich vorher nicht. Deswegen brauchen wir jetzt diese News und dabei musst du mir helfen. So muss die Geschichte erzählt werden.

Jetzt ist die Frage schon mal geklärt, wer das denn eigentlich will. Das ursprüngliche Key-Result gehört in die Marketing-Abteilung. Jetzt ist es natürlich ein Stück weit erst einzusortieren, wie groß das ist. Du kannst eine Faustregel nehmen: 1/20 deiner Ressourcen darf es auf keinen Fall übersteigen, denn sonst müsstest du das ja in deinen Key-Results irgendwie repräsentieren, sonst würdest du ja durch die Hintertür eine starke Verwässerung einbauen.

Die andere Aussage ist, wenn es um eine Supportfunktion geht. Jetzt bin ich IT und du bist Marketing und wir haben das bei mir als Supportfunktion gekennzeichnet, dann kannst du nicht davon ausgehen, dass ich jemals auf dich zukommen werde und sage: Hey, wann geht es denn endlich mit deinem Newsletter-System los? Ich unterstützte dich, ich habe keinerlei Eigeninteresse.

Wenn ich crossfunctional Alignement im Sinne von „Ich habe auch ein Key-Result“ habe, dann bin ich Teil der Treiber. Ich verspreche einen Teil und sorge dafür, dass das passiert, und du sorgst für den anderen Teil. Solange ich nur Supportfunktion bin, mache ich meine Sachen, bis zu dem Zeitpunkt, wo du sagst: Hey, da ist ein Meeting, da bräuchte ich dich. Ich definiere mit dir, was wir mit dem Newsletter-System alles anstellen müssen. Die Frage ist ja, wer was treibt und wie groß ist das. Anhand dieser zwei Fragen kannst du das eigentlich sehr gut einsortieren. Gehört es eher zu dem einen oder eher zu dem anderen?

0:57:25 Teilnehmer

Aber es wird schon immer einer Einzelperson zugeteilt?

0:57:28 Marco

Es wird immer dem OKR-Set zugeteilt. Auf Augenhöhe. Du kannst nicht nach unten oder nach oben, sondern du kannst nur sagen, Marketing- und IT-Abteilung. Quasi um sicherzustellen, dass du die Ressourcen, die du nicht in deiner Abteilung hast, die brauche ich ja nicht aufzuschreiben, wenn ich die Marketing-Abteilung bin, ich kann ja sagen, was wir machen. Es geht darum, über die Grenzen hinaus abzustimmen, was kommt. Damit ist aber auch sicher gestellt, dass ich als IT-Abteilung nicht sagen kann: Das habe ich aber noch nie gehört, was soll denn das jetzt, dass du mit einem Newsletter-System um die Ecke kommst. Das geht auch nicht, weil ich es ja gesehen habe und ich dir auch zugesagt habe, ich werde dich unterstützen, wenn es ungefähr so groß ist, wie du beschrieben hast. Aber geh nicht davon aus, dass ich dir hinterher laufen werde. Ich glaube, das ist die richtige Beschreibung.

0:58:27 Teilnehmer

Ok.

0:58:58 Marco

Cool.

0:58:35 Teilnehmer-Frage: Wie stellt man sicher, dass das Alignement zwischen den Teams gut funktioniert.

Ich erzähle kurz, was wir machen. Wir haben vor einem Jahr zusammen mit der Geschäftsführung und der Bereichsleitung entschieden, OKRs auszuprobieren. Wir haben dafür ein crossfunktionales Team ausgewählt und arbeiten seit Anfang des Jahres in diesem Team mit OKR. Also haben wir sozusagen das Vorgehen anders gewählt, als du das vorher erwähnt hast. Wir sind in tiefere Teile und haben uns einen Bereich heraus gepickt, um zu gucken, funktioniert es in diesem Nukleus  und können wir das eventuell später auf der Unternehmens-Ebene umsetzen. Jetzt haben wir aus diesem Team heraus entschieden, wir werden eine ganze Abteilung nach OKRs umstrukturieren. Zu diesem Thema hatte ich jetzt die Frage: Wie funktioniert am besten die Organisation zwischen einzelnen Teams. Diese Teams sind bei uns nach einer bestimmten Wertschöpfungskette nach der Sales-Familie angeordnet. [....]

Wie stellst du in der Praxis sicher, dass da das Alignement zwischen den Teams gut funktioniert? Das ist jetzt die erste Frage.

1:00:24 Marco

Das würde ja dadurch gelöst sein, dass all diese Teams Teil des OKR-Workshops sind. Dadurch wissen Team 1, Team 2 und Team 3 über mehrere Quartale: Ah, das, was Team 1 jetzt macht, kommt nächstes Quartal als Ergebnis zu mir, dann kann ich da weitermachen. So gesehen, würden wir alle Teams mitnehmen, die an diesem Sales-Funnel sozusagen in einem gemeinsamen OKR-Workshop mitarbeiten, und das gesamte OKR-Set overall definieren, auf das alle gucken und sagen: Ja, das ist eine total realistische Sicht der Dinge und erstrebenswert. Das sollten wir so tun und wir glauben, das kriegen wir auch hin. Gleichzeitig in dem OKR-Workshop die Transparenz herstellen, was jedes Team einzeln macht. Dann weiß das jeweils andere Team ja auch, was daraus resultiert und wie es danach damit weitergehen könnte.

Grundsätzlich muss man sich die Frage stellen, ob die Orientierung an einem Prozess der beste Schnitt für Teams ist. Grundsätzlich ist die Idee ja a) überschneidungsfrei und b) machen die Teams ihren Job möglichst selbstwirksam. D.h. so, dass sie in der Regel keinen anderen brauchen und es sind Produkt-Teams und nicht Prozess-Teams. Also Teilabschnitte eines Prozesses haben wir schon öfter nicht so toll funktionieren sehen, weil es an der Grundidee der Produktteams, die autark ihre Sachen lösen können, vorbei geht. Sondern, sie handeln einen Teilbereich eines Kunden und geben den dann weiter. Aber sie sind nicht wirklich für etwas verantwortlich, weder für den Kunden in Gänze noch für das Produkt in Gänze. Ohne jetzt zu wissen, ob das bei euch der Fall ist, aber das haben wir öfter beobachten dürfen und das hat nicht so optimal funktioniert. Wir würden eher versuchen, Produkt-Teams zu bauen und uns nicht an Prozessen zu orientierten.

1:02:34 Teilnehmer

Das ist bei uns eine komplett neue Organisation, die entsteht da vom 1.1. und wir haben eine Matrix-Organisation, wo wir auch Produkt-Manager in der Vertikalen haben und diese entsenden wir zu den jeweiligen Teams.

1:02:52 Marco

Ja. Also ich sehe das oft. Ich verstehe nicht, wer sich das ausdenkt. Wer 2020/21 auf die Idee kommt, eine Matrix einzuführen – Hut ab! Ich weiß nicht…

Meistens heißt das dann so „Customer Journey-Teams“ und die sind dann auch noch matrixiert. Ich glaube, das ist großer Käse, aber vielleicht täusche ich mich auch. Jedoch überall, wo ich das gesehen habe, hat es nicht funktioniert. Wenn du mich fragen würdest, ob ich das so machen würde, ist meine Antwort darauf: Nein, würde ich nicht. Ich würde versuchen, eher Produkt-Teams mit „Community-of-Practise-Gilden“ oder wie immer man das auch nennen mag, so zu bauen. Das Matrixieren ist das größte Chaos, was es gibt. Mit OKRs wollen wir genau das vermeiden: Nämlich mehrere Leute ziehen mit unterschiedlichen Interessen an dem gleichen Team oder Ressourcen. Das ist das originäre Gegenteil von dem, was ich versuche zu erzählen. Da sind wir wieder an einem Punkt, wo möglicherweise die Rahmenbedingungen – Teamschnitt & Co. – ein größeres Problem sind, als das Formulieren der richtigen Ziele. Denn wenn ich mit meinem Team ein Ziel formuliert habe, aber mir dauernd irgendwie einer was anderes über den Zaun wirft oder mir die Hälfte meines Teams klaut – was soll ich denn da sagen, was in drei Monaten rauskommt. Und ohne am Ende der drei Monate zu sagen: Ja gut, kein Wunder. Doppelt so viele Ziele, halb so viele Leute. Dass das nicht klappen kann, kannst du ja mathematisch irgendwie auf einem Blatt Papier in der Regel lösen, bevor man’s ausprobiert.

Also, sehr generische Antwort wieder, aber…

1:04:37 Teilnehmer

Ich finde das sehr interessant, weil wir auch jetzt aktuell so eine Verantwortung teilweise in den Teams haben, die geht von Leadgenerierung bis Customer Support, und die würden wir dann sozusagen später aufschneiden. Wie gesagt, …

1:04:57 Marco

Komm gerne wieder und berichte uns, wie es läuft. Wir sind auch dankbar, Sachen zu lernen, von denen wir glauben, dass sie anders gehen. Aber wenn du uns fragst, ob wir’s so machen würden – nein, würden wir nicht.

1:05:10 Teilnehmer-Frage: Wie überzeuge ich die Geschäftsführung davon, dass ein Unternehmen mit OKRs erfolgreich geführt werden kann?

Okay. Dann komme ich jetzt zur zweiten Frage. Die ist für mich sehr spannend. Ich bin auch im Austausch mit der Geschäftsführung und sie gucken sich natürlich gerne an, wie das funktioniert. Sie haben sich bisher aber nicht getraut, das unternehmensweit auszuführen. Das ist für mich jetzt die Frage: Wie schaffen wir diesen Schritt, sie zu überzeugen, dass wir damit effektiv und effizient das Unternehmen führen können und dass Erfolge auf diese Art spürbar gemacht werden.

1:05:50 Marco

Das ist eine zentrale Fragestellung. OKRs kann man sich nicht auf Geschäftsebene anschauen. Das muss man anfassen und mitmachen, weil man sonst nicht spürt, was das macht. Man kann zwar versuchen, das intellektuell zu überreißen, aber wie wir vorhin gesagt haben, ist es halt ein Katalysator für ganz viele unterschiedliche Dinge.

Wenn wir jetzt mal davon ausgehen, dass möglicherweise eine matrixierte Struktur schlussendlich das Problem ist und die Kultur das Problem ist und die fehlende Strategie das Problem ist, weil keine KPIs da sind. An dem Punkt sind wir ja gerade schon ein bisschen vorbei gefahren. Wenn ich dann jemand frage: Hey, wie sind denn deine Erfahrungen mit OKRs? Dann ist die Antwort: Ja, geht so. Dann brauche ich mich ja nicht wundern.

Wenn ich das aber sozusagen miterlebt habe, weiß ich ja, was mir der katalytische Prozess vor die Füße gespült hat, nämlich: die KPIs sind vielleicht noch nicht durchdacht, die Strategien sind noch nicht sauber, der Aufbau ist noch nicht richtig, die Kultur harzt. Dann kenne ich meine Baustellen und dann kann ich darauf entscheiden, ob OKRs über die Iteration helfen, die Baustellen langsam zu schließen und zu einem Steuerungssystem zu gelangen. Und das ist ein System für Steuern in Unsicherheit. D.h., ich muss eine hohe Zuversicht kriegen, dass ich einen Apparat baue, in dem die Organisation mit einer hohen Treffsicherheit zu den richtigen Zielen kommt. Das kann ich mir nicht von außen angucken, sondern ich muss sozusagen meine eigenen Entscheidungen überlegen und finden und die mit denen abgleichen, die der Prozess mit dem Rest der Organisation zutage fördert. Je mehr ich sozusagen feststelle, dass das, was der Rest der Organisation erfindet und entscheidet, zu dem passt, was ich erfinde und entscheide, desto höher ist mein Zuversichts-Level, dass das in die richtige Richtung geht. Das kann ich aber nicht machen, wenn ich keine eigenen Entscheidungen getroffen habe, sondern dann gucke ich immer drauf und sage: Irgendwie kann ich auch nicht sagen, was ihr da entschieden habt, weil ich es für mich selber nicht durchlebt habe.

Demzufolge wäre hier der Hinweis wahrscheinlich heilsam, so schnell wie möglich die obersten beiden Ebenen zum „Mitleben“ zu bewegen und nicht zum Angucken auf die unteren Ebenen und sagen: Berichte denn mal, wie läuft denn dieses Framework. Es ist halt ein ganzheitliches Steuerungstool als Rückgrat eines Unternehmens. Das ist wie wenn du sagst: Ich probiere den Selfdrivingmode von Tesla aus, aber ich darf nur das hintere linke Rad steuern. Was habe ich daraus gelernt? Wie gut ist der Test schlussendlich? Wahrscheinlich nicht so zufrieden stellend.

Hilft das?

1:08:56 Teilnehmer

Ja.

1:08:57 Marco

Ob es hilft, wissen wir nicht, aber für den Moment beantwortet es vielleicht deine Frage.

1:09:00 Teilnehmer

Für mich ist bestätigt das meine Vermutung.  Danke.

1:09:06 Marco

Gerne.

So, XY nochmal.

1:09:14 Teilnehmer-Frage: Wie teile ich große Arbeitspakete in kleinere ein, damit sie in meine Planung hinein passen?

Ja, tatsächlich. Ich hätte allerdings auch eine Frage, die nicht direkt auf OKR zielt, sondern auf die etwas übergeordnete Ebene, Richtung Strategie. Da wird der eine oder andere wahrscheinlich aufhorchen, weil wir nämlich die Erfahrung gemacht, dass man ohne das Dach oben drüber nur relativ schwer in das Thema OKR reinkommt. Also ohne Mission – Vision – Strategie ist es ein bisschen schwierig, da so eine Richtung zu finden.

Deshalb haben wir uns da reingestürzt und haben uns unsere ganzen Arbeitspakete mal auf die Matrix ein Jahr, ein bis zwei Jahre, länger als zwei Jahre draufgepinnt. Meine Frage ist jetzt zweigeteilt: Wenn ich jetzt ein großes Arbeitspaket habe, wie z.B., ich will eine Sprachsteuerung einbauen, was ja nicht in einem Jahr abzuschließen ist, sondern zwei oder sogar drei Jahre dauert, bis man das wirklich komplett integriert hat. Da kann ich ja nur schlecht sagen, das machen wir irgendwie in drei Jahren, sondern ich muss es ja wahrscheinlich aufteilen. D.h. Wie klein muss ich dieses Arbeitspaket oder wie klein soll ich diese Arbeitspakete schneiden, damit ich sie vernünftig in meine Planung reinkriege?

1:10:30 Marco

Das sind keine Arbeitspakete.

1:10:33 Teilnehmer

Ach so.

1:10:34 Marco

Das ist ja sozusagen „alte Planungswelt“ zu sagen: Ich weiß schon, wie es geht, ich schneide das in Teile, zerlege das in kleine Päckchen, klebe da einen Namen drauf und sage: Du bist verantwortlich und in drei Monaten machst du das und danach...

KEINE AHNUNG.

Eine Strategie sagt: Man muss mit der Stimme das Produkt steuern können. Das Thema „Ich habe mal was eingebaut“ endet ja da nicht. Wie du bei Siri und ihren Freunden feststellen kannst, scheint das nicht so schnell abschließbar zu sein. Siri irgendwo einzubauen ist noch lange nicht das Ende der Geschichte. Demzufolge scheint „Voice“ eine Strategie zu sein und die Strategie heißt: Ich muss mit meinem Telefon so reden können, wie mit einem normalen Menschen. Andernfalls macht das auf lange Sicht keinen Sinn.

Jetzt kannst du dir Quartal für Quartal für Quartal überlegen: Was kann ich? Wie viel Geld habe ich? Wen kenne ich? Was für technologische Entwicklungen gibt es? Was machen die anderen so? Da machst du sozusagen den Schnitt in der Dreimonats-Richtung auf der Strategie „Ich muss mit diesem Telefon so reden können, wie mit einem Menschen.“ 

Wie soll ich das abtragen? Keine Ahnung! Offensichtlich sind wir da noch nicht, aber es scheint sinnvoll zu sein, sich dahin zu entwickeln. Das heute schon in Arbeitspakete zu zerlegen, unterliegt ja der Illusion, dass wir wissen, wie es geht. Wir wissen das aber nicht.

1:12:25 Teilnehmer

Also ist im Prinzip diese Aufteilung in ein Jahr, ein bis zwei Jahre, länger als zwei Jahre, eigentlich nicht so zu sehen, dass wir sagen, wann wir das tun wollen, bzw. womit wir dieses Jahr anfangen wollen und was wir nächstes Jahr oder vielleicht danach anfangen wollen.

1:12:43 Marco

Keine Ahnung, was du danach anfangen willst. Sorry, aber es ist auch total hinfällig, sich jetzt darüber Gedanken zu machen, was du nach dem Quartal anfangen willst. Wenn du in drei Monaten etwas gelernt hast, was sozusagen die Technologie A mit der du gedacht hast, Sprachen implementieren zu können, komplett über den Haufen wirft, würde ja nach sich ziehen, dass du B, C und D und alles, was danach kommt, auch wieder anfassen musst.

Wenn wir sagen, der Vektor ist: Ich muss mit dem Produkt ganz normal reden können, dann sortierst du auf so einer Art – das kannst du Roadmap nennen, das kannst du Backlog nennen – Grundsatzthemen, wo du sagst: Das könnte passen, das und das könnte passen. Die sortierst du nach der Logik mit am wenigsten Aufwand, dem größten Impact in Richtung „Ich kann mit dem Ding reden“. Von dem Stapel nimmst du oben so viel, wie in drei Monaten reingehen. Der Rest von dem Stapel ist egal, weil während der drei Monate noch sieben Ideen kommen, die sich irgendwie ganz oben, mitten drin und ganz unten in den Stapel reinsortieren, nach der Logik „kostet, schadet, nutzt“. Deswegen sortiere ich ja nicht jedes Mal den Stapel auf die nächsten zwölf Monate, sondern habe eine klare Logik, eine klare Richtung und überlege mir dann, was ich von dem Stapel in den nächsten drei Monaten am sinnvollsten mache. Was in neun Monaten kommt – keine Ahnung.

Also du kannst eine Vorhersage haben, das ist dann eine „Roadmap“, die heisst aber: Wenn sich alles so entwickelt, wie wir glauben, wenn wir unterwegs keine besseren Ideen haben, könnte es so aussehen, dass in neun Monaten Feature X kommt. Wenn aber morgen einer was erfindet, was mit der Hälfte der Arbeit doppelt so viele Kunden glücklich macht, kannst du Feature X auf drei Jahre vergessen. Wenn du dazu nicht bereit bist, ist dieses „agile Ding“ ja irgendwo wieder blockiert.

Also der Trick ist, dem System zu vertrauen. Wenn du die richtigen Regeln und die richtigen Denkmuster hast, liefert dir das Ding schon die richtigen Sachen, die du in den nächsten drei Monaten machen musst. Planung ist nicht hilfreich. Es ist hilfreich zu wissen, was ich erreichen will, also was der Vektor ist, was die KPIs sind und was die vorliegende Idee, respektive Hypothese, bringen könnte und wie viel Aufwand das ist. Daraus ergibt sich logisch eine Priorisierung.

Das ist ganz schön mies, ich weiß. Das ist ein fieses Thema, aber wenn man sich der Sache hingibt, funktioniert das. Wenn man hingegen sagt, ich muss wissen, was in neun Monaten kommt, weil irgendeiner einen Marketingdeal gemacht hat, z.B. hat er für zwölf Monate Printanzeigen gekauft, ist man wahrscheinlich gut beraten, nochmal darüber nachzudenken, ob man nicht auch das Einkaufen von Printanzeigen generell, aber vor allem das Einkaufen von Marketingressourcen dem agilen Prinzip unterwirft. Weil man erst dann feststellt: Passt das überhaupt zum Produkt, funktioniert das überhaupt? Keine Ahnung! Dann zahle ich lieber eine kleine Prämie für die Freiheit, in drei Monaten zu entscheiden, ob ich weiter Print für das Produkt machen will oder nicht.

1:16:31 Teilnehmer

Ja, ich glaube, es ist aber angekommen, was du sagen möchtest, zumindest bei mir. Vielen Dank.

1:16:38 Marco

Cool.

Dann nächste Frage. XY, du hattest noch eine.

1:16:50 Teilnehmer-Frage: Wie kann man Argumente entkräftigen, dass agiles Arbeiten auch weniger Perfektion und Unvollständigkeit bedeutet?

Ja. Ich habe noch eine Frage und zwar heißt es ja, agiles Arbeiten geht in die Richtung, dass ich lieber etwas schnelles, unfertiges mal veröffentliche, damit arbeite und mir Feedback einhole, bevor ich warte, bis es perfekt ist. Wie ist deine Erfahrung damit, wenn du mit solchen Argumenten kommst und sagst: Jetzt habe ich das gemacht und es heißt immer, das ist unfertig und es ist quick and dirty, das schaue ich mir gar nicht mehr an, denn ist es eh nie fertig. Dieses Argument vom Perfektionismus, den ich in einigen Firmen kenne, bedeutet, wenn ich damit rausgehe, habe ich sofort einen schlechten Ruf. Das ist irgendwie gleich. Wie kann man das entkräftigen? Hast du damit irgendwelche Erfahrungen?

1:17:32 Marco

Eine Menge. Es gibt eine Menge schlauer Sprüche. Ohne die jetzt alle zitieren zu wollen, aber „better done than perfect“ triffts glaube ich ganz gut. Es geht ja darum etwas schnell rauszubringen und zu testen, klein zu testen und demzufolge nicht lange große Fehler von Sachen zu bauen, die am Ende das Problem des Kunden nicht lösen oder überhaupt kein Problem lösen oder vielleicht überhaupt keiner haben will. Sondern es geht darum, kleine Tests zu machen, die schon einen Teil des Problems gut lösen. Und dann auf dieser Erkenntnis weiterzufahren. Der größte „traditionistische Fight“ der letzten Jahre war: Tesla baut Autos, da würde ein Deutscher sagen: Da kannst du die Hand durchstrecken. Komischerweise ist Tesla der einzige, der irgendwie eine vernünftige Reichweite auf die Straße bringt. Warum? Weil die gesagt haben, das mit dem Spaltmaß hat schon mal jemand gemacht, das werden wir schon hinkriegen. Dann klauen wir den Jungs von VW & Co. halt ein paar von den Ingenieuren. Das ist bewiesen, das ist nicht unsicher, dass man Autos bauen kann, die ein Spaltmaß haben, das irgendwelchen Standards entspricht. Der Teil ist verhältnismäßig trivial, den können wir lösen, wenn es soweit ist. Die Frage ist: Wie fährst du mit der Karre 500km? Die scheint nicht ganz so trivial zu sein, lass mal darum kümmern, lass das mal iterativ herausfinden.

Die Folge war, dass eine Menge Leute gesagt haben, das wird nie ein Auto, das irgendwie gefährlich wird, und plötzlich ist es dann trotzdem recht gefährlich geworden, weil sich offensichtlich so ein Thema wie Spaltmaß nachziehen lässt. Der Erkenntnisgewinn in einer Core-Technology, die unsicher ist, kriegst du halt nicht mit dem typischen alte Autoindustrie-Denken „sieben Jahre brauche ich, bis ein Produkt auf dem Markt ist“.

Offensichtlich scheint das für die traditionelle Industrie ein Problem zu sein und das ist ja ein Feindbild, bzw. ein Angstszenario, womit man eine Diskussion eröffnen kann, um zu sagen: Ja, stimmt, das wollen wir in unserer Industrie so nicht erleben. Lass mal darüber nachdenken, wie wir unterwegs schon was lernen können, anstatt zu sagen: Wir wissen alles und in sieben Jahren bringen wir dann endlich was raus, was besser ist als das, was die anderen heute haben.

Das war ja so. Ein Porsche sagt immer noch „Wir schlagen den Tesla“. Ist ja klar, ein sieben Jahre altes Auto zu schlagen, ist echt eine Leistung.

1:20:28 Teilnehmer

Es ist wohl generell nur noch ein Einzelthema. Da kommst du doch schwer dagegen an und die sind noch gar nicht bereit für so etwas, wenn du noch in diesem alten Denkmuster steckst. Okay.

1:20:42 Marco

Aber mit so Diskussionen machst du dir nicht zwingend Freunde, ist schon klar. Aber du kriegst zumindest mal das Denkmuster aufgebrochen zu sagen: Das geht bei uns nicht anders, weil offensichtlich schafft der es auch noch, Raketen wieder aus dem All zurückzuholen und wieder zu verwenden, als Hobby. Das schaffen die anderen auch nicht als Hauptberuf. So gesehen scheinen da ein paar Sachen dabei zu sein, die irgendwie ganz gut funktionieren.

Haben wir noch wen? Für ein, zwei Fragen hätten wir noch Zeit. Keiner mehr?

1:21.38 Teilnehmer-Frage: Kann man OKRs einführen, auch wenn man eine ungeeignete Vision hat?

Ich hätte noch eine, wenn keiner mehr will. Wenn du jetzt eine echt bescheuerte Vision hast. Z.B. „Wir wollen die Größten werden.“ Also irgendetwas, womit sich überhaupt keiner identifizieren kann. Dann kommt so jemand zu uns und möchte OKRs. Wie wichtig ist es deiner Meinung nach, zuerst mal an diesem Grundprinzip, an dieser Vision zu arbeiten, mit der ich sage, da können sich die Mitarbeiter identifizieren. Sagst du dann, er kann das mal zur Seite schieben, das ergibt sich vielleicht durch die Arbeit mit OKRs und dadurch erkennt, dass diese Vision eigentlich Blödsinn ist.

1:22:18 Marco

Wir hängen sehr an dem Thema und wir legen sehr viel Wert darauf, es klar zu machen, dass das ein hilfreicher Faktor ist. Ich bin ja auch ein großer Freund von diesen Visionen wie „Wir sind die Größten/ der Marktführer / der Ansprechpartner und so weiter“. Das hilft alles nicht. Vor allem hilft es nicht, die darunterliegende Komplexität auszusortieren. Das wird durch den Katalysator OKR relativ schnell klar.

Wir machen das sehr explizit, dass wir glauben, dass die Qualität noch nicht da ist, wo sie sein müsste, um ein richtig rundes Ergebnis hinzukriegen. Aber man kann schon auch losfahren, man muss sich einfach bewusst sein, dass dieser katalytische Prozess es einem dann irgendwie deutlich macht. Die Frage ist, ob man dann in der Lage ist, das a) schnell nachzuziehen oder b) verbrennt man ein Thema oder verbrennt man eine Mannschaft. Es ist natürlich so, dass wenn Leute lang genug mit blöden Visionen gelangweilt werden und dann heißt es: Jetzt machen wir etwas Neues / Modernes / Agiles usw. Und die Leute freuen sich: Hey, jetzt kommt ein bisschen ein anderer Blickwinkel herein. Aber eigentlich versuchen wir auch wieder nur unsere langweilige Marktführerschaft mit „neuen“ Sachen durchzudrücken. Dann ist natürlich die Reaktion der OKRs wie ein MBO, aber nur in drei Monaten. Klar, wenn sich der Inhalt nicht ändert, kann sich der Rest auch nicht ändern. Das ist dann aber weder OKR noch sinnvoll, sondern das ist dann einfach KPIs, die wir vorhin hatten, runtergedampft und in Dreimonats-KPIs verpackt. Aber das ist nicht dieses Ursache-Wirkung-Prinzip zu einer inhaltlich sinnvollen Vision. Das wird dann schmerzlich klargemacht. Wir sind halt Freunde davon, den Schmerz muss keiner erleiden, wenn man es ja schon weiß, dass es mit hoher Wahrscheinlichkeit so sein wird. Wenn du es vorher lösen kannst, dann lös es, bevor du mit mehreren hundert Leuten losfährst.

1:24:32 Teilnehmer

Okay. Danke.

1:24:34 Marco

Sehr gerne.

Also, eine abschließende Frage.

1:24:39 Teilnehmer-Frage: Wie können OKRs mit Business Cases oder Wirtschaftlichkeit verbunden werden?

Ich habe noch eine Frage. Erst mal Danke für dieses Format, das war echt spannend. Ich bin heute das erste Mal dabei und habe viel gelernt.

Ich hätte eine Frage: Wie kann das ganze Thema OKRs mit Business Cases oder auch Wirtschaftlichkeit verbunden werden? Vielleicht auch allgemein betrachtet agiles Arbeiten. Ich sage mal klassisch: Wir haben irgendeinen Business Case zu irgendeinem Thema versucht zu erstellen, haben gesagt, das lohnt sich. Dann ist man losgelaufen und am Ende versucht man dann nachzumessen ob das geklappt hat. Das ist ja beim agilen Handeln relativ schwierig, wenn ich grundsätzlich davon ausgehe, dass so viel Unsicherheit drin ist und ich eigentlich noch gar nicht genau weiß, wie es funktioniert, nur war es vielleicht meine Strategie, eben diese Voice-Funktion da zu bauen. Wie kann ich damit umgehen.

1:25:40 Marco

Wenn du auf einen Business Case schaust, nehmen wir an, du siehst als Investor auf einen Business Case. Da guckst du ja kritisch drauf und fragst: Was will mir das hier sagen? Bin ich da bereit, mein Geld zu investieren? Stimmen die Zahlen, die da drin stehen? Nein, auf keinen Fall. Entweder sind sie zu gut oder zu schlecht, aber treffen tun sie nie.

Eigentlich geht es darum, das Denkmuster zu verstehen. Das Denkmuster sagt ja, wie sich bestimmte Hebel zueinander auswirken. Die Verhältnismäßigkeit von unterschiedlichen KPIs zueinander, ein gewisses Ratio von einem Wert A zu einem Wert B – das sind ja die Sachen, die einen Business Case am Ende aufgehen lassen oder nicht. Nicht die einmal angenommenen Zahlen, die da drinstehen.

Das ist sozusagen, was du mit OKRs versuchst, in die Realität zu überführen und zu sagen: Jetzt haben wir die Verhältnisse als Hypothesen gebaut, das könnte gut aufgehen, wenn das klappt. Also versuchen wir jetzt in der Dreimonatsscheibe ein bestimmtes Ziel zu erreichen und zu gucken, ob sich der Zeiger in die andere Richtung bewegt. Wenn das so ist, können wir auch auf dem Geldausgabenzeiger weiter in dieser Richtung unterwegs bleiben. Dann stimmt nämlich das Verhältnis.

Wenn das nicht so ist, müssen wir die andere Seite auch anpassen, sonst glauben wir nämlich, auf der einen Seite statisch den Zahlen hinterher zu laufen, die es in der Realität aber gar nicht gibt, aber die Ausgabenseite, sprich die Ressourcen, lassen wir gleich. Das kann ja langfristig nicht aufgehen. Demzufolge ist es hilfreich, zwei Sachen zu machen. Erstens: Diese Verhältnismäßigkeit von den einzelnen Faktoren im Business Case sauber zu verstehen. Zweitens: In den OKRs auf Quartalsebene zu überführen und zu sagen: Damit das langfristig aufgeht, müsste mit den Ressourcen (Zeit und Geld) in dem Quartal ungefähr das Ergebnis rauskommen, damit ich im folgenden Quartal weiter in dieser Richtung fortschreiten kann. Auch das muss ich sozusagen auf einer Quartalssicht übersetzen und danach auch wieder hinterfragen, ob es wirklich aufgeht.

1:28:00 Teilnehmer

Verstanden. Vielleicht noch ganz kurz anschließend, damit ich das ganz verstehe: Wenn ich jetzt ein großes Projekt habe, das beispielsweise über mehrere Quartale oder Jahre geht, und ich in dem Business Case gewisse KPIs drin habe, wie du vorhin schon gesagt hast, KPIs wie Kosten oder Umsatz sind da mit drin. Die Kosten kann ich in den drei Monaten ja schön überprüfen, aber über den Umsatz werde ich im Zweifel ja nichts erfahren, wenn es mir nicht gleich gelingt, da ein MBP zu bauen, mit dem ich vielleicht schon loslaufen und den Umsatz testen kann. Im Zweifel kriege ich den Umsatz her, das Feedback kriege ich ja erst am Ende des Projektes. Wie genau meinst du das mit dieser Verhältnismäßigkeit, wie man das nach drei Monaten testet.

1:28:54 Marco

Der Umsatz ist ja immer der Lagging-Indikator. Wenn man den anguckt, ist es sowieso immer zu spät. Also musst du dir frühere Indikatoren suchen, die sagen, Leute sind bereit, ein Produkt zu kaufen, das X, Y und Z als Eigenschaften hat. Wenn ich das im Großen baue, kann ich es entweder schon im Kleinen bauen oder kann dafür einen Indikator finden.

Um nochmals dieses Tesla-Beispiel zu stressen: Hier werden ja auch Autos verkauft, die es über Jahre nicht gibt, aber es gibt Leute, die zahlen echtes Geld dafür, hundert Dollar, tausend Dollar, um einen Produktions-Slot zu erwerben. Hat das was mit dem am Ende produzierten Auto zu tun? Korreliert, ja, aber nicht jeder, der heute hundert Dollar zahlt, kauft auch einen Cybertruck. Aber daran kannst du ablesen, ob es Leute gibt, die den Cybertruck haben wollen. D.h., wenn du das Ding präsentierst und keiner bestellt es vor, bist du vielleicht gut beraten, nochmal am Gesamtkonstrukt Anpassungen vorzunehmen. So würdest du dich iterativ einem so großen Projekt nähern können.

1:30:08 Teilnehmer

Super, jetzt habe ich das verstanden. Danke, hat Klick gemacht.

1:30:12 Marco

Super.

Dann haben wir heute den zeitlichen Rahmen ganz gut ausgenutzt. Vielen, vielen Dank für eure Zeit, für die spannenden Fragen. Ohne die wäre das ganze Format nämlich ganz schön langweilig. Hat mir Spaß gemacht und euch hoffentlich etwas gebracht.

Wer Freude hat, gerne beim nächsten Mal wieder vorbeischauen.