AMA13: Ask me anything about OKRs - Die OKR Q&A Session
Marco Alberti
In dieser Episode beschäftigen wir uns mit einem „Klassiker“ - nämlich, wie sich das Tagesgeschäft in OKRs integrieren lässt und ob das so überhaupt richtig ist. Zusätzlich behandeln wir das Thema der agilen Organisation vs. dem agilen Managementsystem, in dem diese Organisation stabil funktioniert. Zudem haben wir einen Überblick bekommen, wie wir Ressourcen besser allokieren können und ein gesamtheitliches Verständnis dafür bekommen, wie viele Ressourcen in den OKR-Sets verplant sind.
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
0:01:51 Teilnehmer-Frage: Wie kann man Zeiterfassung von OKR klar trennen? Wie kann ich mit OKR intrinsisch motivieren?
Dankeschön. Wir haben uns vor rund einem dreiviertel Jahr das erste Mal über Keyresults und Objectives in der Firma unterhalten. Wir sind ein Unternehmen im Software-Bereich, im Dokumentenmanagement-Bereich. Wir hatten eine ganze Weile eine Situation, wo „ungerichtete Agilität“ stattgefunden hat, so ein bisschen das „Managergame: Agilität zum Selbstzweck“, mehr als tatsächlich agile Ziele zu erreichen.
Deswegen hat das Thema OKR auch bei der Geschäftsführung Anklang gefunden. Wir sind dann hergegangen und haben das im Produktmanagement und im Projektbereich diskutiert und soweit als gut befunden. Jetzt ist es so, dass die Geschäftsführung an der Stelle am Thema OKR mehr oder weniger alles Mögliche festmacht, u.a. auch so dieses „Ich möchte möglichst wissen, was überall im Unternehmen passiert.“ Für mich ist das so ein bisschen das Thema: Da wird anders, als es gedacht ist, ein Kontroll-Framework aufgezogen. Ich habe explizit darauf hingewiesen, dass das eben nicht sein sollte, dass ich mit intrinsischer Motivation arbeiten will und nicht durch Kontrolle, Druck und dergleichen, eben nur extrinsisch motivieren.
Wir haben seit einer ganzen Weile eine sehr, sehr unübersichtliche Erfassung beispielsweise von Projektzeiten, die anfallen, die also auch irgendwo in Rechnung gestellt werden müssen. Jetzt wird das Stichwort OKR so verstanden, dass wir damit endlich das Thema Zeiterfassung, Protokollierung und Auswertung, Reporting und dergleichen verbinden.
Meine Frage ist jetzt, also, ich hab ja geschildert, wie ich OKR sehe, und die Geschäftsführung sieht das jetzt in Teilen etwas anders: Wie würde man am besten vorgehen, die Zeiterfassung von OKR irgendwo zu trennen und klar zu machen, dass das unterschiedliche Dinge sind. Und: Wie gehe ich her und packe so eine berechtigte Aufwandsauswertung, beispielsweise für Projekte, an, um trotzdem genau das mit OKR an sich zu erreichen, was ich möchte, dass intrinsische Motivation erzeugt wird und das nicht vermischt wird?
0:04:54 Marco
Ich würde das erstmal inhaltlich voneinander trennen.
Eine Rückfrage: Du hast gesagt Projektgeschäft. Habt Ihr auch Produktgeschäft? Nur Projektgeschäft?
0:05:08 Teilnehmer
Also, das Produktgeschäft ist relativ stark Projekt-getrieben, also da kommen quasi Ideen und Wünsch, sodass aus einem Projekt heraus auch Produkterweiterungen stattfinden können.
0:05:19 Marco
Das klappt erfahrungsgemäß über die Summe aller Kunden, die wir dabei begleiten durften, nicht so toll. Das ist schon mal die erste Erkenntnis, dass man das wahrscheinlich voneinander trennen müsste und das Produkt erstmal unabhängig vom Projekt entwickelt. Und wenn sich ein Kunde ein Feature wünscht, das andere brauchen könnten, dann kann man das vielleicht sinnvoll implementieren. Andernfalls vielleicht auch eher nicht.
Das ist der eine Teil, an dem die OKR Implementierung möglicherweise schon spannender wird. Wenn man jetzt mal nur den Projektteil anschaut, dann hast du natürlich die Grundüberlegung: Was will denn OKRs eigentlich? D.h., wir wollen für ein festes Team, für einen definierten Zeitraum von drei Monaten definieren, welche Ziele wir erreichen werden.
Das Projekt kommt wahrscheinlich von der anderen Seite und dann kommt man von einem fest definierten Ziel und muss jetzt möglichst schnell und Ressourcen schonend oder vielleicht auch nicht Ressourcen schonend, wenn man den Teil verkauft, dieses Projekt umsetzen. Also treffen da auch schon mal Welten aufeinander, die grundsätzlich anders ticken.
Da müsst ihr für euch erstmal definieren, wie ihr das künftig machen wollt. Grundsätzlich ist es kein Projektsteuerungssystem, sondern ein Zielvereinbarungs- und Zielsteuerungstool, womit ich davon ausgehe, dass ein Team, das sich kennt und vertraut, für drei Monate definiert, was der Scope ist. Und eben nicht anders herum.
Also müsste man erstmal hingehen, die „unterschiedlichen“ Kundenprojekte in OKRs zu übersetzen, in einzelne Teams zu zerlegen und zu sagen, welches Team jetzt welchen Scope im OKR-Set für die drei Monate definiert hat. Damit weiß man inhaltlich, was zu tun ist, bzw. welche Ziele man versucht zu erreichen. Da kannst du durchaus im Vorfeld mal eine realistische Schätzung machen, was du glaubst, was der Zeitaufwand dafür ist, um danach rauszufinden, wo denn die Zeit hingegangen ist. Aber es geht eher darum, dass es kein Kontrolltool ist, sondern eher, die Selbsteinschätzung besser zu kalibrieren um rauszufinden, was denn eigentlich ein Team in drei Monaten leisten kann.
Da kommt natürlich nochmal die Frage dahinter: Ist Zeit die beste Einheit, um Software-Projekte zu schätzen? I don’t know! Da gibt es unterschiedliche Sichtweisen. Wenn ihr Zeit verkauft, werdet ihr am Ende irgendetwas mit Zeit zu tun haben.
Aber agil steuern und Wasserfall verkaufen, ist nicht spannungsfrei. Vielleicht muss man dahingehend irgendwie auch mit dem Kunden anders denken, als klassisch ein Wasserfall-Projekt zu verkaufen und das dann versuchen, agil zu steuern und dann auch noch zu berichten. Da sehe ich eine Menge Spannungsfelder, die wahrscheinlich nicht extrem gut miteinander harmonieren.
0:08:36 Teilnehmer
Man muss dazu auch sagen, unsere Verträge sind nicht auf agile Modelle abgestimmt. Wir haben keine Verträge, die als Einheit verwendet werden und dann tatsächlich Dienstleistungstage verkauft werden. Im Produktbereich gibt es beispielsweise keinen großen Überblick, wo die Zeit eigentlich hingeht.
Die Frage ist also: Wo geht die Zeit hin? Wo ist die Zeit gut investiert? Wo ist sie nicht gut investiert? Dass das Ganze über die Zeit aufgezogen wird, anstatt zu schauen: Wo habe ich denn meine definierten Objectives erreicht? Das ist das Problemfeld, das ich an der Stelle gerade sehe. Da passiert etwas in der Firma, das haut nicht so hin, d.h. ich habe als Daily, der die Fragen stellt, schon selber ein gewisses Misstrauen. Auf der anderen Seite erzeuge ich damit natürlich auch Misstrauen, wenn ich damit komme und sage: Da passt doch etwas nicht, wo geht denn die Zeit hin, das kann doch nicht sein, wir sollten mal wieder Produkte entwickeln, Projekte machen, anstelle um uns selbst herum zu kreisen.
0:09:44 Marco
Lass mal trennen, denn die verkaufte Zeit ist nicht daran interessiert, dass die Lösung schneller ist, als die Zeit, die du verkauft hast. Da ist schon eine Fehlanreiz drin.
Was den Produktteil betrifft, da ist klar: In ein Team von zehn Personen investierst du drei Monate und auf dem OKR-Zettel steht am Ende, was du für dieses Investment, in welcher Zeit und in welcher Qualität zurück kriegen würdest. Das ist durch die Keyresults ein Stück weit auch messbar. Dann kannst du schauen, ob das das Investment wert war oder nicht. Das ist ja die spannende Herausforderung. Denn wie gesagt, die Sachen sind ja komplex und demzufolge in ihrer Ursache-Wirkung-Beziehung nicht vorhersehbar. Deshalb ist Zeit nicht zwingend die richtige Einheit.
Beantwortet das ein wenig deine Frage?
0:10:39 Teilnehmer
Ja, richtig, Dankeschön.
0:10:41 Marco
Gerne. Dann geht es weiter mit XY.
0:10:49 Teilnehmer-Frage: In einem kleinen Unternehmen lässt es sich nicht vermeiden, dass ein Champion unabhängig von den inhaltlichen Zielen agiert. Was ist eure Empfehlung dazu?
Ja, das bin ich, glaube ich. Ich habe mich über meinen Mann eingeloggt.
Ich habe mehrere Fragen. Wir stehen kurz vor der Implementierung, bzw. entscheiden wir uns morgen, ob wir implementieren. Ich hatte auch eine Frage unter anderem zur Rolle des Champions. Wir sind ein eher kleines Unternehmen und wir haben deshalb auch keine klassische Assistenzfunktion. Ihr sagt ja, eigentlich sollte das jemand sein, der keinen Stake in den OKRs, bzw. in den Champions selber hat. Wenn sich das aber nicht vermeiden lässt, was wären denn dann deine oder eure Empfehlungen?
0:11:32 Marco
In der Realität muss man mit dem arbeiten, was man hat. Wenn wir niemand anders finden, der dieses OKR-Thema ohne Eigeninteressen ordentlich orchestrieren kann, weil es keine Kapazitäten gibt oder weil er vielleicht nicht die geeigneten Befähigungen hat, dann kann man schon auf die Rolle zurückgreifen und das in dieser Doppelfunktion machen. Man muss sich aber in Teilen bewusst sein, dass man dann in der Form, in der man operativ auch Inhalte vertritt, gegen sich selber Schach spielt. Das ist erfahrungsgemäß nicht so einfach. Sich selber zu coachen funktioniert dann nicht. Und den inhaltlichen Teil vom funktionellen Part eines OKR-Champions zu trennen, ist dann auch nochmal eine gesonderte Herausforderung. Du darfst ja nicht aus deiner inhaltlichen Rolle diskutieren, sondern eben nur aus der Coaching-Perspektive.
Wenn du sagst, du kriegst das hin oder derjenige, der das bei euch machen soll, dann würde ich das so machen. Der Realität geschuldet.
0:12:40 Teilnehmer
Ok, alles klar, Dankeschön. Ich habe noch ein paar mehr Fragen, die kann ich ja noch später stellen. Ich lasse mal den anderen den Vortritt.
0:12:47 Marco
Gerne. Ja.
0:12:53 Teilnehmer-Frage: Mich schreckt der große Aufwand zur Einführung von OKR ab. Kann man das auch schlanker umsetzen?
Wir sind ein sehr kleines Unternehmen und ich traue mir einerseits zu, die OKR-Fokussierung einzuführen. Andererseits schreckt mich so dieses ganze OKR-Instrumentarium, der Riesenprozess, die langwierige Einführung ab. Ich frage mich, wie man das kleiner, schlanker, nicht so fett, einführen kann. Denn irgendwo, wenn man es mal herunterbricht und von ein paar Schalen befreit, ist ja OKR für mich auch so eine Art Zielvereinbarungssystem mit Objectives und Keyresults. Wie geht die Einführung eine Potenz kleiner?
Du bist vielleicht der falsche Adressat, also jemand, der lieber große, fette Lösungen verkauft.
0:13:35 Marco
Nein. Wenn es mir ums Verkaufen ginge, wäre ich ja nicht hier, sondern dann würde ich meine Zeit verkaufen. Mir geht es ja darum, irgendwie herauszufinden, wie das ganze wirklich funktioniert. Wir haben das auch schon sehr oft in sehr, sehr kleinen Unternehmen sehr zielführend eingesetzt.
Das Grundmodell ist ja gar nicht aufwändig. Sondern es geht darum, dass du auf einem Zettel 20 klare Punkte formulierst, also 20 Keyresults, die solide messbar sind, die du am Ende auch messen kannst, um klar zu machen, was die ganze Firma will und was die jeweilige Abteilung oder der jeweilige Mitarbeiter – vielleicht gibt’s auch gar keine Abteilung, sondern nur Mitarbeiter - will.
So rüttelst du das Puzzle zusammen zwischen dem großen Ganzen und den voneinander zu trennenden Teilen. Und wie wir vorhin gesagt haben: Wann bin ich bereit, drei Monate dieser Person oder dieses Teams zu investieren, um das, was auf dem Zettel steht, als Value for Investment sozusagen entgegen zu nehmen. Das ist grundsätzlich der Kern des Ganzen.
Und dann stellst du irgendwann mal fest, zwischen den drei Monaten… Also, ich habe das noch nicht geschafft, dass man das aufschreibt und geht und wiederkommt und es ist passiert. Blöderweise muss man sich dazwischen noch drum kümmern. Der Teil ist so schlank orchestriert, wie er eigentlich nur sein kann, weil er dir ja die Möglichkeit gibt, alles das, was dir jetzt wahrscheinlich aufwändig erscheint, aber strukturiert abzufahren. Unsere Beobachtung ist: Wenn du’s weg lässt, hast du nicht das Bedürfnis weggelassen zu kommunizieren, diese Themen zu diskutieren und Entscheidungen zu treffen. Sondern, du hast nur die Struktur weggelassen, wie du das tun willst.
D.h., das wird irgendwo wiederkommen, die Anzahl deiner E-Mails, die Anzahl deiner Telefonate, Zoom-Calls, Sprechnachrichten, an der Kaffeemaschine hast du mal ein paar Minuten spontane Meetings - wie auch immer sich das ausprägen wird – das wird nicht weggehen.
Der Teil ist deswegen nicht durch OKR mächtig, sondern OKR orchestriert den Teil, der sowieso da ist, so schlank wie möglich. Er wird so drauf gucken und gucken, was sonst passieren würde. Das ist erfahrungsgemäß mächtiger als das, was passiert, wenn du das strukturiert machst. Denn du hast ja eine klare Agenda, du hast Vorbereitung, du hast Regeln, du hast einen Weg. Bei einem Kleinunternehmen wahrscheinlich nicht ganz so wichtig, aber mittelgroße Unternehmen können innerhalb einer Woche von ganz unten nach ganz oben und wieder zurück ein Problem eskalieren, Entscheidungen treffen und es wieder zurück strukturieren, ohne dass man irgendein Notfallmeeting oder sonst irgendwas einberufen muss. Also von daher ist es schon eigentlich relativ schlank und erfahrungsgemäß auch gut investierte Zeit.
Hilft dir das soweit?
0:16:51 Teilnehmer-Frage: Wie viel Zeit muss man denn für die vollständige Implementierung einplanen?
Vielleicht zu der Frage noch. Wie viel Zeit muss man denn für die Implementierung einplanen? (Sorry, dass ich da dazwischen gehe).
0:16:55 Marco
Kannst du kurz spezifizieren, ob du meinst, wie lange es dauert, bis es das Unternehmen vollständig „verinnerlicht“ hat? Oder wie viel Zeit man als OKR-Champion braucht, um den Prozess zu begleiten?
0:17:10 Teilnehmer
Beides ist interessant, aber ich meine das Erste.
0:17:13 Marco
Das ist stark abhängig von dem Unternehmen. Je kleiner, desto schneller. Je „mehr Konzern“, je eingefahrener, je traditioneller, desto langsamer.
Wir arbeiten in drei Ebenen. Die erste Layer ist: Man versteht, wie OKR funktioniert, also das reine Framework. Der zweite Layer ist der Content im Kontext. Also auszusortieren, was die möglichen nächsten Ziele wären und welche nächsten Ziele sollten wir in dem Quartal angehen? Das ist der logische Layer. Wenn du saubere Strategien hast und wenn die Leute gut ihre Erfolgstrauer im Griff haben, ist der recht schnell überrissen. D.h. in so einem Start-Up Umfeld kannst du das in drei bis sechs Monaten total easy implementieren. Aber wir treffen auch auf viele Mittelständler oder größere Unternehmen oder Konzerne, wo explizit keine Strategie vorhanden ist, wo explizit nicht klar ist, was die Erfolgstreiber sind, wo es keine KPIs gibt. Das musst du alles drauf addieren. Der dritte Layer ist der emotionale Layer, der heißt: Ich bin in der Kindheit nicht so behandelt worden, wie ich mir das gewünscht hätte und das muss ich jetzt an meinen Mitarbeitern auslassen. Der kommt noch on top!
Mit einer Horde von Leuten wird das dann halt so komplex, wie das menschliche Zusammensein komplex werden kann. Das kann auch Jahre dauern, bis hin zum Scheitern und gar nie Ankommen, weil die Kultur das nicht will. Irgendwo dazwischen findet sich die Wahrheit. Also, eure Wahrheit. Aber kleinere Unternehmen: zwischen drei und sechs Monaten, um dir da die Angst zu nehmen.
0:18:51 Teilnehmer
Vielen Dank.
0:18:55 Marco
Sehr gut.
0:19:02 Teilnehmer-Frage: Wie kann man Objectives und Keyresults in einem nicht klar abgrenzbaren Tätigkeitsfeld, wie das Netzwerken, formulieren?
Dann glaube ich, bin ich an der Reihe, hallo. Ich grüße euch aus der Schweiz. Wir sind einer der größten Konzerne in der Schweiz und wagen uns ganz waghalsig an das Thema, die OKRs einzuführen. Jedoch nicht im ganzen Konzern. Ich bin jetzt in einem Bereich tätig – Organisationsentwicklung – wo wir das mal ausprobieren. Und ich habe natürlich eine Reihe von Fragen. Aber die, die mir grad am wichtigsten erscheint ist diese: Wir haben ja diese Prinzip der Selbstwirksamkeit, d.h. dass die Ziele und die KRs, die man sich formuliert, mit den Ressourcen des Teams gemacht werden sollten. Jetzt arbeiten wir z.B. in unserem Bereich sehr stark in Netzwerken, auch in Communities, wo wir uns engagieren und da merke ich, ich komme ins straucheln. Also das, was wir als Team gemeinsam erarbeiten, ist eigentlich der geringste Teil unserer Arbeit. Wir sind quasi immer abhängig von anderen Dingen, abgesehen von so Aufgaben wie einen Antrag an den Verwaltungsrat zu machen, wie da die Schwierigkeit ist, das in Objectives und vor allem Keyresults zu formulieren. Aber dieses Thema eigentlich, was mit der künftigen Arbeit vermehrt zusammen hängt, das Netzwerken, d.h. ich arbeite gar nicht so in Teams, die ganz klar voneinander abgrenzbar sind. Da merke ich, da hänge ich in den ganzen Gedanken.
0:20:35 Marco
Also das ist vor allem eine strukturelle Frage. Was du schon willst, ist, dass der Verantwortungsbereich und der Ressourcenbereich klar umrissen sind. Wir sehen oft, dass man Agilität auch mit einer agil, sich dauernd neu zusammen würfelnden Organisation interpretiert. Das haben wir noch nicht funktionieren sehen. Wir wären offen für Gespräche, aber so wirklich beweisbar, dass das irgendwie sinnvoll ist, habe ich in meiner Laufbahn noch nichts gesehen.
D.h., das Team ist stabil und klar für eine Rolle und deren Funktionen verantwortlich. Da versucht man möglichst störungsfrei selbstwirksam die Ziele zu erreichen. Um dir das so ein bisschen zu übertragen: In der Software-Welt würde man das mit Schnittstellen machen. D.h., die anderen Teams, die auch klein und schlagkräftig und selbstwirksam sind, machen andere Teile eigenverantwortlich, aber über eine Schnittstelle arbeitet ihr zusammen. Und die Schnittstelle ist klar beschrieben. Wenn ich etwas von dir will, muss ich a) liefern, und zwar in der und der Form, und dann krieg ich von dir b) zurück.
Das ist in der Softwarewelt über eine LPI, aber vielleicht auch über Regeln und Prozesse in so einer Netzwerk denkenden Organisation geregelt. Aber schon so, dass klar abgegrenzt ist: Was ist unser Verantwortungsbereich? Was ist euer Verantwortungsbereich? Was wollen wir eigentlich erreichen? Was wollt ihr erreichen? Ideal-typischerweise passt das zusammen.
Wenn du das auf die Personen runterbrichst und jetzt ständig zwischen den Leuten in deinem und in meinem Team ein Austausch stattfindet, kann ich die Leute nicht mehr einschätzen und die Leute mich nicht mehr und dich genauso wenig und keiner weiß mehr, worum es hier genau geht, wer was kann und wie viel wir verkraften können. Also, versuche kleine Teams stabil zu halten und die Schnittstellen klar zu machen, das ist glaube ich, die Antwort auf deine Frage.
0:22:45 Teilnehmer
Ok. Aber ich kann nur jene Keyresults immer in meinem kleinen Team definieren, die wir wirklich selber beeinflussen können.
0:22:55 Marco
Das ist die Grundidee. Du versprichst sozusagen etwas für das Investment: dein Team: Du plus zehn Leute für drei Monate. Der Aufwand ist weg. Was krieg ich dafür? Das ist ja eine Investitions-Entscheidung. Am Ende des Tages muss sich das Investment gelohnt haben. Wenn du sagst: Ja, ich habe bei ganz vielen Sachen mitgemacht, aber so wirklich was hingekriegt habe ich jetzt nicht. Dann ist die Frage, ob das a) zufriedenstellend ist, b) effizient und c) ob ich dann das Investment gut abgrenzen kann, weil ich nicht genau weiß, was denn die Assets hier eigentlich sind.
0:23:32 Teilnehmer
Ja, dieser Investitions-Entscheid hilft mir nochmals hier. Super, danke.
0:23:38 Marco
Du hast noch ein Stichwort gesagt, da möchte ich auch noch kurz darauf springen. Eine Vorstandsvorlage – oder wie war das?
0:23:44 Teilnehmer
Ja, ein Antrag an den Vorstand für die Einführung von Smartwork, z.B.
0:23:55 Marco
Das passt in meiner Welt überhaupt nicht mehr. Ich kann dir auch sagen, warum. Denn nicht ein bestimmtes Team macht die Arbeit und sagt: Schau lieber Vorstand, wir haben hier drei Alternativen ausgearbeitet. Könntet ihr bitte eine entscheiden und euch aussuchen? Sondern, bevor ich anfange zu arbeiten, sage ich: Lieber Vorstand, sag mir mal, wann ist es gut und wann ist es schlecht, was sind die Dimensionen von Erfolg und Nicht-Erfolg? Und dann mache ich das so, dass möglichst Erfolg herauskommt. Aber wie ich das mache, ist meine Sache, weil ich damit dann wieder selbstwirksam bin. D.h. die Grundidee von „Ich arbeite mehrere Varianten aus“ und mache dann so eine Art Entscheidungsvorlage und jemand anders entscheidet, entsteht schon total konträr im Kopf zu dem, was wir eigentlich versuchen zu erreichen.
Das ist vielleicht auch noch ein Punkt, auf dem du ein bisschen rumdenken kannst.
0:24:55 Teilnehmer
Das ist gut. Das wird noch eine Weile dauern, aber ist nochmal ein wichtiger Punkt. Vielen Dank.
0:24:59 Marco
Gern. Dankeschön.
Dann ist glaube ich XY dran.
0:25:05 Teilnehmer
Erstmal vielen Dank, dass du diese Sprechstunde da anbietest.
0:25:07 Marco
Sehr gern.
0:25:09 Teilnehmer-Frage: Die Einführung von OKRs haben wir direkt mit Quartalen angefangen und die langfristige Perspektive ignoriert. Sollten wir uns nun doch mal über einen langfristigeren Zeitraum Gedanken machen? Zudem sind 80% unserer Keyresults nicht über ein Quartal messbar; wie sollen die in Quartalen untergebracht werden?
Das ist ja wirklich sehr spannend. Ich habe eine Frage zu den Zeiträumen. Wir sind ein Team von ungefähr ein Dutzend Leute, fangen gerade an, OKRs einzuführen. Ich habe mich im Vorfeld mit ein paar Menschen ausgetauscht, die sehr strukturiert angefangen haben, mit Jahreszielen und das dann herunter gebrochen haben, was man sich in den verschiedenen Quartalen so zutraut. Uns ist es sehr viel leichter gefallen, direkt mit dem aktuellen Quartal anzufangen und wir haben zuerst Mal die langfristige Perspektive ignoriert. Ist es da ratsam, nochmals die Bremse reinzutun und zu sagen: Moment, wir müssten vielleicht auch nochmal über einen längeren Zeitraum sprechen? Oder ist es eigentlich schöner, das Momentum mitzunehmen und direkt quasi in Quartale einzusteigen und zu sagen, von Quartal zu Quartal zu gucken, wie man die Methode weiter verfeinert?
Ich habe noch eine kleine Anschlussfrage: Ungefähr 80% unserer Keyresults sind bisher so, dass man eben nicht über das Quartal messen kann, wie es weiter geht. Wir haben dann noch ein paar Ziele, da steht dann „Downloads von XY“, da können wir dann jede Woche nachgucken, wie wir weiter gekommen sind. Bei den meisten anderen Keyresults steht einfach ein Projekt mit dem Fertigstellungsdatum, das ist uns leicht gefallen. Ist das trotzdem richtig, diese Ziele so beizubehalten oder ist schon ein großer Punkt von den Keyresults, dass man sie auch unter dem Quartal umfassender messen kann?
0:26:45 Marco
Am Ende des Quartals musst du sie messen und bewerten können. Wenn du sie am Ende des Quartals nicht messen und bewerten kannst, musst du sie kleiner schneiden oder die so Sachen suchen, die man messen kann.
Du hast gesagt, Projekt XY ist gemacht. Also, gemacht ist mir ja ziemlich egal. Die Frage ist: Was hat es gebracht? Was ist heraus gekommen? Und das muss ich irgendwie nachvollziehen können. Warum? Weil ich nachher nachsteuern will. D.h., ich versuche ja die Ressourcen im nächsten Quartal mit dem Wissen vom letzten Quartal zu investieren. Demzufolge, wenn du mir nicht sagst, was rausgekommen ist, kann ich auch nicht sagen, ob es ein besseres Investment ist oder nicht.
0:27:33 Teilnehmer
Ok.
0:27:35 Marco
Nachvollziehbar? Also, die drei Monate sind ja weg und wir wollen ja wissen, und das kam dabei raus, gehen wir nun den Weg weiter oder gehen wir einen anderen? Versuchen wir, es mal generell anzupassen. Wenn wir nicht wissen, was rausgekommen ist und du nur sagst, die Arbeit ist weg, also die Zeit ist weg, wir haben was getan… Wir wollen ja wissen, ob es was gebracht hat, was wir getan haben, dann müsste man sich wahrscheinlich noch andere Keyresults überlegen, die den Output sozusagen messbar machen. Und nicht den Input, im Sinne von „Ich hab den ja abgeliefert“, aber ich will ja den Effekt der Bemühungen messen. Darum geht es ein Stück weit.
Die erste Frage war, ob es quasi Sinn macht, im Quartalsrhythmus zu denken oder ob man Jahresziele braucht.
0:28:22 Teilnehmer
Ja, beziehungsweise, wenn man mit Quartalen schon mal gestartet ist, ob man dann eigentlich sagen soll, wir müssten einen längeren Horizont denken und das Ganze dann auf Quartale herunterbrechen. Oder ob man einfach ins Laufen kommt.
0:28:35 Marco
Also, am besten bleibst du, wo du bist, denn Jahresziele haben in der ganzen Sache überhaupt nichts verloren. Das ist sozusagen schon in sich inkonsistent: Ich mache auf agil – aber dann mache ich ein Jahresziel. Wenn ich drei Mal unterwegs im Jahr etwas gelernt habe, aber an dem Jahresziel festhalte, je näher ich dem Jahresziel komme, desto unstimmiger wird das Jahresziel, weil es ja die Erkenntnisse der letzten drei Monate nicht in die Entscheidungsfindung einbezieht. Also, das Jahresziel macht überhaupt keinen Sinn.
Das zweite ist, dass das Denkmodell meistens verkehrt rum ist. Es heißt immer „Jahresziel“ und dann muss ich von da weg rückwärts rechnen, um herauszufinden, wie ich das erreichen könnte. Wir denken aber anders rum. Wir versuchen, die Sachen zu beeinflussen, die wir inhaltlicher Natur beeinflussen können, weil ich z.B. weiß, was dem Kunden wichtig ist. Dadurch weiß ich, was ich auf der Strategieebene, also langfristig, beeinflussen kann und was nicht, und davon suche ich mir jedes Quartal das aus, womit ich den Zeiger mit den Ressourcen, die ich habe, am weitesten in die richtige Richtung bewegen kann. So, und dann kann ich irgendeine Voraussage treffen, wie: Wenn sich der Zeiger wirklich von danach da bewegt, wird in einem halben Jahr das herauskommen und in einem Jahr das. Nicht anders herum. Wir kommen vom Inhalt, hangeln uns über die wesentlichen Erfolgstreiber, versuchen die Ressourcen gut zu investieren und dann kommt hinten raus ein Ergebnis.
Die Denkweise von „Ich habe ein Jahresziel“ - und ehrlicherweise sind die in 95% aller Fälle monetär getrieben – das dann runter zu brechen, ist das größte Nicht-OKR, das du machen kannst. Also jedenfalls nicht, wenn du mich fragst.
Wenn man’s so rum macht, kann man zwar OKR draufschreiben – das hat aber nichts damit zu tun, was du aus dem Ding rausholen kannst. Es hat nichts damit zu tun, irgendwelche Finanzzahlen in Quartalen runter zu brechen und sich dann zu überlegen, was man machen könnte. Sondern es hat etwas damit zu tun, inhaltlich zu verstehen, worum es eigentlich geht. Und das schlau mit den Ressourcen zu investieren, schnell zu lernen, nachzusteuern, besser zu werden. Und dann kommt raus, was raus kommt. Nur weil dir einer sagt, er will 10 Mio. EBIT machen – das ist der Realität egal. Das kannst du in Dreijahrespläne oder in Jahrespläne schreiben – das ist einfach Wurst. Es interessiert die Realität nicht...
0:31:12 Teilnehmer
Ja, super. Sehr ermutigend! Und sehr interessant, dass zwei Quellen unabhängig voneinander offenbar etwas ganz Falsches mit dem System machen.
0:31.20 Teilnehmer
Richtig oder falsch möchte ich an der Stelle nicht sagen. Ich sage nur, wir haben in den letzten sieben, acht Jahre viel getestet und – was ich sage, ist meine tiefe Überzeugung - ich habe auch schon bewiesen, dass das funktioniert. Ich sage nicht, dass das die anderen falsch machen, ich sage nur, ich glaube, dass das besser funktioniert. Machen kann jeder, was er will, ich kann es eh nicht aufhalten. Ich kann nur versuchen, einen Weg zu definieren, wie es vielleicht besser funktionieren könnte.
Du wirst ganz viele Sachen im Internet finden, die genau das Gegenteil von dem behaupten, was ich erzähle. Damit müsst ihr klarkommen und euch entscheiden, welcher Philosophie ihr folgt.
Danke dir.
0:32:13 Teilnehmer-Frage: Wie sollen wir mit der Integration oder Anbindung von Product-Roadmaps im OKR-Framework umgehen?
Hallo.
Wir sind ein mittelständischer Bauzulieferer und wir haben vor einem knappen Jahr einen neuen Bereich gegründet, der sich Digitalisierung nennt. Wir haben jetzt vor ungefähr vier Monaten auch OKR bei uns eingeführt, erstmals als Pilot nur in unserem Bereich. Wir sind jetzt beim zweiten Zyklus angelangt, also bei der Erarbeitung eines zweiten OKR-Zyklusses und stoßen jedes Mal – also jetzt schon zum zweiten Mal – auf die Frage: Wie gehen wir mit der Integration oder Anbindung von Producut-Roadmaps im OKR-Framework um?
Wir haben ein Objective, das das Ziel hat, digitale Produkte einzuführen und zu entwickeln. Da haben wir uns schon auf vier Produkte festgelegt, also da ist schon relativ klar, was wir machen wollen. Wir haben vier Product-Owner, die sich jeweils mit einem Produkt beschäftigen und 80-90% ihrer Zeit dafür verwenden. Allerdings werden die im nächsten Zyklus noch nicht eingeführt. Die Produktentwicklung wird noch nicht abgeschlossen sein, es wird auch noch keine MVP geben, die wir schon in den Markt einführen. Jetzt ist die Frage: Wie können wir die Entwicklung dieser Produkte in den Keyresults messbar machen, ohne jetzt einfach einen Meilenstein aus der Product-Roadmap herauszunehmen, was ja irgendwie so…
0:34:07 Marco
… nicht erlaubt ist.
0:34:10 Teilnehmer
Wir haben eine Product-Roadmap, der wir folgen, und wir haben auch ein OKR-System, das wir verfolgen…
0:34:17 Marco
… ihr habt keine Product-Roadmap, die ihr verfolgt, sondern ihr habt eine Strategie und aus der Strategie leitet ihr OKRs ab. Dann hast du so etwas wie eine „Voraussage“, was in drei Quartalen passieren könnte. Aber wenn du dich in zwei Quartalen fragst, was im dritten Quartal passiert, ist die Wahrscheinlichkeit hoch, dass was anderes passiert, als ich dir vor drei Quartalen gesagt, was dann passieren würde.
Das ist ja der Kerngedanke von dem agilen Ding. Wenn man das nicht akzeptiert, dann will man ja nicht agil, sondern dann will man ja klassisch etwas Geplantes so liefern, wie wenn man sich das einmal überlegt hat.
Die Frage ist: Wenn man die Realität anguckt, passt das mit der Roadmap eigentlich nie. Entweder geht es schneller oder langsamer, aber stimmen tut es nie. Deswegen hat man ja angefangen, das umzudrehen und zu sagen: Ich habe grundsätzlich meine Vorstellung, wo das hingehen soll und jetzt mache ich, so gut ich kann. Und zwar im Gleichtakt und dann kommt rauskommt, was rauskommt. Damit hat nur immer jener ein Problem, der sagt: Ich muss doch wissen, was rauskommt. Dadurch wird es halt nicht genauer.
Das ist, glaube ich, mal der eine Aspekt.
Sind die Entwickler-Ressourcen den POs eindeutig zugeordnet?
0:35:46 Teilnehmer
Ja, die sind aber extern. Wir arbeiten da mit Dienstleistern, die sind nicht bei uns im Unternehmen. Wir haben nur die POs, die das steuern.
0:35:55 Marco
Das heißt aber trotzdem, hätte ein PO, sagen wir mal, 10 Entwickler-Personen in seinem Team. Die versuchen nicht, untereinander um die Ressourcen zu konkurrieren oder das unterschiedlich zu priorisieren?
0:36:12 Teilnehmer
Nein.
0:36:14 Marco
Ok. Dann hast du ja sozusagen im Großen schon die Buckets definiert, dass die vier Produkte X Entwickler-Ressourcen für das eine Quartal haben. Jetzt muss man sagen: Was davon kann ich denn messbar machen? Da hilft es ja auch, das agile Grundprinzip vom Bild her zu verinnerlichen: Ich sage nicht, ich baue ein Auto und schraube da drei Jahre dran herum. Sondern in einem Quartal schraube ich mal vier Reifen an ein Brett und einen Seilzug dran und versuche irgendwie zu lenken. Und wenn ich unten bin, stelle ich fest, dass Bremsen ganz hilfreich gewesen wären.
Das musst du jetzt quasi in eure Unternehmensrealität übertragen um zu sagen: Worum geht es denn dem Kunden eigentlich? Was will der denn geliefert und bewiesen haben? Wie können wir schnell beweisen, dass das das trifft, was wir eigentlich an Nutzen versprechen wollen? Und wie können wir das messbar beweisen? Und das halt in kleinen Iterationen. Das dann immer weiter und grösser und nach den entsprechenden Dimensionen.
Daraus kannst du ja dann Quartal für Quartal Ziele ableiten, die sagen: Gut, schnell unten waren wir, das hat schon mal geklappt, aber schnell gebremst hat nicht geklappt. Das müssten wir vielleicht im nächsten Quartal nochmal optimieren. Dann musst du dich vielleicht darum kümmern. So kannst du Quartal für Quartal definieren, was eigentlich genau am Ende des Quartals im Inkrement sozusagen besseren Nutzen stiftet, als es vorher getan hat.
Das kannst du durchaus auf der Zeitschiene abtragen und sagen: Das ist quasi meine Roadmap im Sinne von „Wenn es weiter so läuft, dann könnte in drei Quartalen das fertig sein.“ Aber es ist nicht ein Plan und es ist auch nicht so, dass ich dir gesagt habe, es wird so sein. Sondern ich sage dir nur: So, wie es heute aussieht, könnte es passieren. Und in drei Monaten sage ich dir, wie es in drei Monaten aussieht. Und dann sage ich dir, es passiert leider drei Monate später. Warum? Weil es länger dauert, weil wir was Besseres gefunden haben, weil die Lösungen nicht das Problem des Kunden beheben, weil Corona, weil Geld ausgegangen… Man weiß nie.
Diese Unsicherheit auszuhalten und trotzdem das Gefühl zu haben, es unter Kontrolle zu haben, ist natürlich der spannende Change in dem Mindset. Zu sagen: Nur weil ich es plane, stimmt es ja trotzdem nicht. Also akzeptiere ich die Unsicherheit und versuche, damit besser umzugehen. Damit hast du die Realität besser unter Kontrolle, als zu planen und darauf zu hoffen, dass es doch irgendwie aufgeht.
0:39:03 Teilnehmer
Ok. Ich habe es so verstanden: Man könnte z.B. festlegen, welche Features wir am Ende des Quartals umgesetzt haben wollen.
0:39:18 Marco
Idealerweise hast du nicht ein Feature, um ein Feature zu haben. Sondern du hast ein Feature, um eine Funktion zu erfüllen. Und du musst dir die Frage stellen: Wie gut erfüllt das Feature die Funktion? Vielleicht fragst du Test-Kunden, vielleicht kannst du irgendwie was messen, vielleicht hast du ein Benchmark von einem Wettbewerbs-Produkt, vielleicht hast du was-auch-immer. Aber es geht nicht darum, „das Feature zu haben“.
0:39:45 Teilnehmer
Ok. Das ist eine andere Perspektive.
0:39:49 Marco
Das ist so. Es geht nicht um die Input-Dimension. Feature haben ist uninteressant. Den Nutzen besser erfüllen oder so gut erfüllen, dass jemand, der es danach benutzt, sagt: Hey, genau das löst mein Problem. Wenn du dann sagst: Das hat aber ganz viele Features, und ich sage, dass ich die alle nicht brauche, dann hast du halt nichts gewonnen.
0:40:08 Teilnehmer
Dann müsste es heißen: Wie können wir den Nutzen des Features messbar machen?
0:40:16 Marco
Genau. Ist es schneller als der Wettbewerb, ist es billiger, ist es einfacher zu bedienen. Eine Testgruppe sagt, es gefällt ihnen besser als das, was sie vorher hatten. Ich weiß es nicht. Das musst du halt von Fall zu Fall herausfinden. Aber DARUM geht es und nicht um die Umsetzung des Aufwandes.
0:40:36 Teilnehmer
Ja. Komplett andere Sichtweise. Spannend. Danke.
0:40:43 Marco
Gern.
0:40:48 Teilnehmer-Frage: Wie kommen wir am sinnvollsten auf die ersten OKRs für die Einführungsphase?
Hallo. Wir sind noch ganz am Anfang, würde ich sagen. Wir haben uns entschieden, dass wir OKRs generell mal einführen wollen und sind gerade in der herausfordernden Situation, dass wir uns die ersten OKR-Sets mal überlegen müssen. Jetzt stellt sich mir die Frage: Wie kommen wir am sinnvollsten, am besten auf die ersten OKRs für so eine Einführungsphase? Ist das etwas, was wir am besten Top-Down quasi vorgeben oder sollten wir erstmal Ideensammlungen bei den Mitarbeitern machen, um dann möglichst schon so einen Ansatz zu verfolgen? Und die findige Idee ist der Umstand zu sagen: Die Einführung des OKR ist das Einzige, was wir jetzt im ersten Quartal quasi angehen. Hältst du das prinzipiell überhaupt für eine sinnvolle Idee, so etwas zu formulieren? Und dann erstmal die Schulung der Mitarbeiter einhergehen zu lassen usw.
0:41:58 Marco
Die Einführung von OKRs ist das Einzige, was ihr in dem Unternehmen in dem Quartal machen wollt?
0:42:06 Teilnehmer
Wir haben ja noch Tagesgeschäft und Themen, die jetzt momentan laufen, ohne dass wir OKR schon aktuell eingeführt haben. Die werden wir ja dann auch weiterhin tun müssen. Aber momentan haben wir noch nicht die Kennzahlen, die das dann widerspiegeln. Und die jetzt aus einem Team zu erarbeiten, das noch nicht geschult ist, wir sind mittlerweile 50 Mann im Unternehmen, stelle ich mir aktuell sehr schwierig vor. Deswegen war die erste Idee zu sagen: Wir führen das schon mal ein, aber der erste Schritt wäre ja zu sagen, OKR ist die Einführung. Was hängt da alles dran?
0:42:43 Marco
Jetzt verstehe ich dich.
Ich beantworte die mehreren Fragen, die da drin stecken, vielleicht mal nacheinander. Die erste Frage war ja Bottom-Up, Top-Down – wo kommt es in der ersten Runde her.
Wir machen erst mit einem empathischen Top-Down Ansatz. Das heißt nicht, dass jemand dem anderen „vorsagt“, was er zu tun hat, sondern man sagt, die ersten beiden Führungsebenen versuchen, mal rauszufinden, was das sinnvollste für das Unternehmen für die nächsten drei Monate ist. Sagen wir mal, die Teamleiter oder die Abteilungsleiter tun das für sich, eine CEO oder ein CEO tut das für sich und dann bringen wir das in einem Workshop übereinander und gucken, wie gut das zusammen passt. Wenn das nicht gut zusammen passt, ist die Wahrscheinlichkeit hoch, dass die Vision nicht klar ist, dass die Strategie nicht vorhanden oder explizit oder klar ist, oder dass die Interpretationslage hier unterschiedlich ist.
Wenn das gut zusammen passt, ist die Wahrscheinlichkeit relativ hoch, dass wir das ganz gut für das erste Quartal eingerüttelt haben.
Empathisch deswegen, weil ich jetzt als Teamleiter natürlich hingehe und sage: Ich rede mal mit den Leuten, ich weiß ja, was so dran ist. Ich versuche, mir ein Gespür zu verschaffen. Dann versetze ich mich in die einzelnen Personen des Teams und mache die Summe draus. Das ist dann das, womit ich mal ins Rennen gehe, und versuche so gut wie möglich, für uns einen Aufschlag zu machen, wissend, was euch wichtig ist, und wissend, worauf ich sozusagen den Schwerpunkt lege und worauf nicht.
Das wird dann im Company-OKR-Workshop verhandelt, definiert, glatt gezogen und mal für das Quartal gesetzt. D.h., wir nehmen nicht den ersten Bottom-Up-Ansatz mit, weil das nach unserer Erfahrung die Organisationen überfordert. Sondern wir gehen vorerst empathisch aus den ersten zwei Ebenen vor, versuchen die richtigen Inhalte zu definieren und kaskadieren die einmal runter, weil es viel einfacher ist, an konkreten Inhalten dieses OKR-Thema zu leben, zu erlernen, zu implementieren. Ohne auch noch die Verwirrung „Wie geht denn das“ mit der Verwirrung „Was soll ich denn im nächsten Quartal tun“ miteinander zu vermischen.
Empathisch deswegen, weil wir natürlich versuchen, die Meinungen und Sichtweisen der einzelnen Teams so gut wie möglich einzubeziehen. Dann brechen wir das entsprechend runter und versuchen anhand dessen, das OKR-Framework erlebbar zu machen, zu erklären, direkt damit zu arbeiten.
Wo meine Verwirrung ein Stück weit herkommt, ist die Grundannahme, dass du gesagt hast: Tagesgeschäft machen wir ja sowieso und die anderen Dinge auch. Das sehen wir genau nicht so.
Alles, was rauskommen soll, musst du irgendwie in OKRs formulieren. Dann kannst du einen Thread aufmachen, ob du noch dieses Tagesgeschäft machen willst, weil es ein guter Deal ist. Oder ob du vielleicht weniger vom Tagesgeschäft und lieber mehr von dem anderen Zeug machen willst, weil der Deal besser ist. Immer abhängig davon, wo das Unternehmen gerade steht, wie viel du in die Zukunft investieren kannst, wie viel Firefighting du hast, was die Rahmenbedingen sind, usw. Deswegen wirst du dich mal mehr, mal weniger mit dem Hier und Heut beschäftigen, und mal mehr und mal weniger mit der Investition in die Zukunft. Gut beraten bist du, wenn es über den Zeitverlauf ein ganz solides Verhältnis hat.
Um das aber gegeneinander abzuwiegen und genau zu steuern, was du dir dieses Quartal leisten kannst und willst, musst du alles auf einen Tisch legen. Du kannst nicht sagen: Ich mache sowieso das, was ich immer mache plus die Sachen, die noch irgendwo herkommen, und dann mache ich noch die OKRs. Denn dann sind die Ressourcen schon weg.
0:46:44 Teilnehmer
Nein, nein, das ist generell schon klar, deswegen war die Idee zu sagen, gerade jetzt beim ersten Intervall, würden wir nur die Einführung von OKR priorisieren und erstmal so weitersteuern, wie wir es bisher haben, um jetzt die Methode auch mal dem Team zu erklären. Aber jetzt habe ich herausgehört, dass ihr das i.d.R. quasi mitmacht.
0:47:08 Marco
Wir steuern mit OKRs, denn was willst du sonst mit dem Team machen? Du hast ja denn keinen Inhalt, über den du reden kannst, weil OKRs als Solches sind ja… Du kannst ja nicht sagen: Ich habe ein OKR-Meeting gemacht, aber über nichts gesprochen, weil das, was ich steuern will, darüber spreche ich woanders.
Weißt du, was ich meine? Die OKRs dient ja dazu, um die Ziele zu setzen und die Wahrscheinlichkeit der Zielerreichung zu steigern, indem du darüber steuerst. Aber wenn du jetzt gar keine Ziele hast, kannst du auch nichts steuern. Deswegen wäre das ein sehr theoretisches Konstrukt.
Um es konkret zu beantworten, ich glaube, das macht keinen Sinn.
0:47:50 Teilnehmer
Also so etwas wie Schulungen für alle Mitarbeiter planen und mit den Abteilungsleitern jeweils abzustimmen, ob da auch für jeden Mitarbeiter genügend Zeit eingeplant worden ist, durchgeführt worden ist, um zu sehen, wie weit die einzelnen Abteilungen schon in dem Grundlagenaufbau überhaupt bereit sind, ein entsprechendes Tool für OKR versuchen zu finden, was ja alles für mich jetzt im Raum steht, dass wir das noch tun müssten, bevor wir überhaupt generell über die Inhalte reden können.
0:48:24 Marco
Unsere Hypothese ist: Die Firma arbeitet ja sowieso schon. Die 50 Leute machen ja was. Demzufolge kannst du ja versuchen, so gut du kannst, diese Inhalte in die OKRs zu übersetzen. Das dauert auch nicht so lange, dass du Monate beschäftigt bist, sondern du machst zwei Tage Workshop und danach hast du einen Frame der so passt. Das ist genauso agil, wie alles andere.
Damit fährst du los und das rüttelt sich dann „während der Fahrt“ schon fest. Aber so trocken schwimmen ist zusätzlicher Aufwand. Ich würde lieber mit den richtigen Inhalten dort rein gehen und dann versuchen das anzuwenden und „unterwegs“ zu optimieren. Denn der Schulungsaufwand ist natürlich da, aber der ist nicht exorbitant. Wir machen Rollouts über unseren Onlinekurs, da ist der Schulungsaufwand zweieinhalb Stunden pro Mitarbeiter. Das kriegt man hin. Vor allem in Zeiten, wo man Netflix schon durchgespielt hat. Vielleicht lohnt es sich, wenn man als Unterhaltung noch was Zusätzliches kriegt.
Also irgendwo so liegt wahrscheinlich die Realität. Demzufolge würden wir versuchen, das real einzuplanen und natürlich ein bisschen von der Erwartungshaltung herunter zu gehen, was möglicherweise den sonstigen Output angeht.
0:49:58 Teilnehmer
Ok, super. Danke.
0:50:00 Marco
Gerne.
0:50:05 Teilnehmer-Frage: Wie kann man SCRUM und OKRs vereinen und Überschneidungen vermeiden?
Ja, hallo. Wir arbeiten aktuell nach SCRUM und wollen auch aktuell OKRs einführen. Da vielleicht einmal die Frage nach dem neuen SCRUM-Guide nochmal mehr zu gucken, ob das Product-Owning irgendwie wie man das mit den OKRs zusammen kriegt. Das ist mir noch nicht so ganz klar. Und vielleicht so ein zweiter Teil in Richtung der Meeting-Dichte. Also bei SCRUM hat man ja einige Events schon dabei. Wie kann man das machen, dass da nicht noch so viel Overhead an zusätzlichen Meetings dazu kommen?
0:50:36 Marco
Um dir ein Bild zu geben, OKR ist sozusagen SCRUM fürs ganze Unternehmen, also so eine Art „SCRUM of SCRUM“ für die Gesamtunternehmung. Wenn du ein SCRUM-Team hast, dann hat das Team OKRs und diese Team-OKRs werden dann in den SCRUM-Prozess in „Sprints“ übersetzt und dann abgearbeitet. D.h., du hättest da dann in dem Team nicht mehr die OKR-Meeting-Struktur, sondern hier würde dann komplett die SCRUM-Logik greifen; du hättest auch keine individuellen OKR-Sets, sondern das SCRUM-Team macht an der Stelle den SCRUM-Prozess mit all seinen Meetings usw. Der Produkt-Owner z.B. ist als Vertreter des SCRUM-Teams dann in den OKR-Prozess mit den anderen in den Meetings eingebunden und würde sich dann entsprechend abstimmen und die Regel-Meetings im OKR-Prozess einsetzen. Da würdest du auch die Schnittstelle finden. Also, das OKR-Set sagt, was die messbaren Ergebnisse sind, die das SCRUM-Team in drei Monaten schafft. Und dann wird es in Sprints übersetzt durch all die SCRUM-Inkremente, die es da an der Stelle so gibt.
0:52:00 Teilnehmer
Ja, vielleicht nochmal zu dem Product-Goal, das nach dem neuen Scrum-Guide hinzugekommen ist. Brauche ich das dann überhaupt oder ersetzen die die OKRs, die ich dann für das Team habe quasi das Goal? Also, das Produkt-Goal sitzt ja über dem Product-Backlog sozusagen. Aber eben nicht nur auf diese drei Monate bezogen, sondern grundsätzlich für das nächste Produkt oder die Produkt-Perspektive.
0:52:27 Marco
Das ist so ein bisschen das, was wir wahrscheinlich auf der Strategie-Ebene manifestieren. Wir sagen: Was sind denn die Sachen, in die wir die Energie investieren? Also z.B.: Welche der Produkte wollen wir denn voran bringen? Und wie sollen die denn aussehen? Was ist denn die Funktion von dem Team? Das würden wir auf dem Strategie-Layer so definieren, dass es entweder schon in der Company-Strategie klar wird, oder, wenn die Organisation grösser ist und du sozusagen eigene Strategien für die Bereiche brauchst oder hast, dass es in dem Strategie-Layer klar wird, sodass ich das wahrscheinlich dann doppelt und von der OKR-Struktur ableiten würde. Denn die ist ja umfassend und überall geltend und SCRUM möglicherweise nur für einen Teilbereich. Demzufolge würden wir den Weg gehen, dass die Produkt-Vision hier von der Produkt-Strategie führend ist und SCRUM sich davon auf Quartalsebene ableitet, wie wir das umsetzen.
Beantwortet das die Frage?
Sehr gut.
0:53:45 Teilnehmer-Frage: Wie sind das Tagesgeschäft und wiederkehrende Aufgaben in den OKRs abbildbar?
Ich glaube, ich bin dran. Ich bin XY, hallo.
Ja, ich habe so ein, zwei mehr Fragen. Eine wurde z.T. schon beantwortet. Kurz vorweg: Wir haben vor einem halben Jahr ungefähr schon einmal versucht OKR zu implementieren, bzw. mein Vorgänger. Der hat das durch Eigenstudium versucht; er hat also nicht an Seminaren oder ähnliches teilgenommen. Es hat sich als ziemlich schwierig erwiesen, das so umzusetzen, wie er es gelesen hat. Jetzt durch das Seminar habe ich einige Erkenntnisse gehabt und habe auch gesehen, das lief nicht so gut und deshalb war es auch so schwierig. Das war auf jeden Fall schon für die Erkenntnis super. Nur habe ich mich teilweise gefragt, wie macht man es denn anders?
So als erste Frage: Wie ist das Tagesgeschäft abbildbar oder auch wiederkehrende Aufgaben? Das wurde erwähnt, das sollte darin wieder zu finden sein. Denn in der Vergangenheit, bei dem Kollegen, war es damals so, dass wir immer das Tagesgeschäft hatten, dann hatten wir das Projektgeschäft und wir hatten OKR. Das war irgendwie kein fest integrierter Bestandteil. Jetzt stellt für mich erstmal die Frage, wie man das macht, z.B. bei banalen Sachen wie Rechnungen müssen immer geschrieben werden, Thema Buchhaltung und so. Sind das auch Tätigkeiten, die auch darin abbildbar sein sollten? Oder ist es so das, was nebenher läuft?
0:55:09 Marco
Lass mal versuchen zu analysieren, warum das schief gegangen ist. Wenn du sagst, ihr hattet Tagesgeschäft, Projekte und OKRs, dann ist ja die Wahrscheinlichkeit hoch, dass für OKRs – was immer da drin stand – du noch 10-15% der Ressourcen übrig hast. Erfahrungsgemäß landen die nicht in OKRs, sondern eher in Facebook und an der Kaffeemaschine, weil man doch ein paar Minuten am Tag irgendwo reinguckt oder aus dem Fenster guckt. Also, die Summe ist nicht 100% produktive Zeit, was man ja immer glaubt, was so geht. Das muss man dann auf der anderen Seite mit mehr Energie und Anstrengung wieder rausholen, was auch immer schwierig wird.
Also, erstmal die Grundannahme: Auf wie viele Zielsysteme verteilst du deine Ressourcen und bleibt dann überhaupt noch viel übrig, dass das Sinn macht? Wenn man das ein bisschen auflöst, muss man sich fragen: Was ist ein Projekt? Ein Projekt ist definiert: Das hat ein Ziel, das hat einen Zeitraum, das hat Ressourcen. Und OKRs sind ein Ziel, Zeitraum und hat Ressourcen. Die Frage ist: Was ist der Sinn der Koexistenz der beiden Sachen, wenn es eigentlich die gleichen Eigenschaften hat, nur unterschiedliche Fixpunkte?
Demzufolge würde sich ja anbieten, ein Projekt in OKRs zu übersetzen, dass man sagt: Der Zeitrahmen ist klar – drei Monate – die Ressourcen sind fix und jetzt definieren wir, was in den drei Monaten rauskommen kann. D.h., das Ziel atmet. Damit kriegst du die Projekte schon mal in das OKR rein. Dann ist die Frage: Was mache ich jetzt mit dem „Tagesgeschäft“, also mit den Sachen, die man halt so macht.
Jetzt hast du den Dauerbrenner „Buchhaltung“ angesprochen. Da wird der Krieg nicht entschieden. Das ist nicht der spannende Teil dafür, da sind OKRs nicht dafür gemacht und da kann dir das System auch nicht helfen. Ja, die Belege sind richtig und möglichst mit wenig Aufwand zu verbuchen und auch noch rechtzeitig und das muss auch jemand bezahlen. Ist das spannend? Nein! Sage ich damit, dass der Job nicht spannend ist? Nein, sage ich nicht. Aber ich sage, es ist für OKRs nicht das, wo sich OKRs wohlfühlen, denn OKRs ist Steuern in Unsicherheit. Rechnungsbelege verbuchen und so ist halt prozessuales Geschäft, demzufolge vermeintlich „sicher“. Ursache und Wirkung sind erforscht, deswegen brauche ich kein „Steuern in Unsicherheit“. Dafür ist es nicht gemacht.
Nehme ich Buchhaltung z.B. mit? Ja, wenn ich das ganze Unternehmen nach OKRs steuere, steuere ich ganzheitlich damit auch die Buchhaltung und gucke, was ich optimieren kann, wie viel sich automatisieren lässt. Denn alles, was ich dreimal manuell mache, wird irgendjemand versuchen zu digitalisieren, rationalisieren oder automatisieren. Wenn das mein Job ist, bin ich gut beraten, es daran selber zu versuchen, bevor es jemand anders versucht und mich und meinen Job weg rationalisiert. Also denke ich schon mal nach, wie es mit weniger Aufwand geht: Wie kann ich den Verbuchungsaufwand automatisieren? Wie kann ich Systeme anschließen, die sich die Belege automatisch aus 500 Portalen ziehen usw. Damit kriegst du Quartal für Quartal den Aufwand pro verbuchten Beleg runter oder die Zeit, wie lange du brauchst, um Taxi-Quittungen einzusammeln oder was weiß ich.
0:58:30 Teilnehmer
Ok. D.h. also, immer wiederkehrende Aufgaben müssen gar nicht so explizit in Keyresults formuliert sein, sondern eher das, was man verbessern kann?
0:58:40 Marco
Eher das, was in Summe rauskommt. Bei diesem Tagesgeschäft-Ding werde ich oft missverstanden. Vielleicht nochmal zur Klarheit: Den Tagesgeschäft-Part gibt es auch in den Bereichen, wo du – sagen wir mal – nicht so klar umrissene Leitplanken hasst, wie jetzt z.B. in der Buchhaltung. Sondern wenn du im Projektgeschäft bist, wenn du Customer-Business machst – das sind ja auch sogenannte „Tagesgeschäft-Aufgaben“, die immer wieder kommen, aber dafür hätte ich trotzdem gern ein Ergebnis formuliert. Wenn ich zehn Personen drei Monate lang beschäftige, sollte dafür eine Handvoll messbarer Ergebnisse dagegen stehen, wo ich sagen kann: Ah, das war im letzten Quartal so, in dem Quartal ist es so. Vielleicht ist es sogar ein bisschen besser, als im letzten Quartal, aber ich krieg zumindest mal ein wahrnehmbares und messbares Ergebnis, wo ich merke, die Investition lohnt sich.
Gleichzeitig werde ich dadurch, dass ich es formulieren muss, motiviert, darüber nachzudenken, wie es vielleicht besser geht, wie ich etwas automatisiert kriege, wie ich eine andere Lösung rein kriege. Und Gleichzeitig krieg ich den Trade-off zwischen „Was ist denn jetzt das, was da Nicht-Tagesgeschäft ist?“ und „Wie viel Ressourcen investiere ich in dieses Tagesgeschäft und lohnt sich das“? Oder muss ich vielleicht meine Erwartungshaltung in diesem Tagesgeschäft runterschrauben, um mehr von den anderen Sachen zu kriegen? Diesen Trade-off musst du sichtbar machen und dann kannst du ihn bewusst entscheiden. Andernfalls passiert irgendwas, aber das ist dann keine bewusste Entscheidung mehr.
1:00:19 Teilnehmer
Okay, das hilft mir auf jeden Fall schon sehr weiter. Und wie ist das denn in Abteilungen, die, sag ich mal, die „Feuerwehr“ sind und spontane Aufgaben oder unplanbare Dinge machen, die auf einen zukommen? Die kann man ja gar nicht miteinbeziehen, oder? Also, lässt man denn dafür extra Raum, oder…?
1:00:40 Marco
Die Regel ist: Meistens ist es nicht unplanbar, sondern meistens ist es vorhersehbar. Wenn du in der Notaufnahme vom Krankenhaus arbeitest, ist es nicht unplanbar, dass da jemand vorbei kommt und sagt: Ich habe hier ein ernstzunehmendes Problem, das wir schnell lösen müssten. Aber es ist unplanbar zu wissen, welches und wie viele davon. DASS da jemand kommt, ist nicht unplanbar, sondern das ist die Regel und nicht die Ausnahme von der Regel.
Demzufolge muss man erstmal gucken: Reden wir über die Ausnahme von der Regel oder reden wir über die Regel. Wenn wir über die Regel reden, dann muss ich natürlich Mittel und Wege finden, Sachen zu kategorisieren, ungefähr einzuschätzen, um vielleicht auch die Kausalität umzudrehen und zu sagen: Wie komme ich denn aus dem Reaktiven ins Pro-Aktive. Wie kann ich das provozieren, was ich eigentlich machen will? Und nicht so lange warten will, bis irgendetwas passiert, worauf ich dann reagieren muss.
1:01:39 Teilnehmer-Frage: Verstehe ich das richtig: Der OKR-Champion darf nicht inhaltlich an den OKRs mitwirken?
Okay. Das ist auch ein guter Ansatz.
Dann hätte ich noch den Punkt: Der OKR-Champion darf kein eigenes OKR-Set haben, das hast du vorhin schon zum Teil beantwortet. Also, ich habe das jetzt so verstanden, dass dann derjenige eher die Coaching-Funktion und die Organisations-Funktion inne hat, sage ich mal, und gar nicht inhaltlich in den einzelnen Sets mitwirkt.
1:02:09 Marco
Der oder die OKR-Champion kann ein eigenes OKR-Set haben. Der Punkt, den wir vorhin gemacht haben, ist: Er oder sie sollte in der Rolle als Führungskraft nicht gleichzeitig im obersten Bereich des Unternehmens eigene Inhalte verteidigen müssen, weil es a) eine Ressourcenfrage ist: Habe ich genügend Kapazität, um die Rolle auszufüllen, und b) Kann ich das frei diskutieren, wenn ich dir sage: Hey, also diese OKR ist wirklich nicht gelungen. Aber gleichzeitig diskutiere ich auch die Inhalte raus, wo ich deine Ressourcen haben will. Das ist nicht ganz Spiel-frei. Demzufolge versuchen wir, das voneinander zu trennen, damit wir einfach den methodischen Part von dem inhaltlichen Part sauber trennen Dann kann man sagen: Das ist eine rein methodische Sache, ich glaube, das ist nicht gut formuliert. Ob du das jetzt machst oder nicht, musst du mit deinen Kollegen aushandeln. Ich sage dir nur, formell ist es kein gutes Ziel. Deswegen ist die Trennung da.
1:03:16 Teilnehmer-Frage: Ich verstehe nicht ganz, weshalb die Cross-Funktionalität nicht Teil eines OKR ist.
Und dann hatte ich noch Differenzierung, Support-Funktion und Cross-Funktionalität. Das habe ich in der Übersicht gesehen, die ihr auch zur Verfügung gestellt hattet, eine Excel-Datei, in der auch der Konfidenz-Level abgefragt wird. Was ich nicht so richtig verstanden habe: Die Tätigkeit der Cross-Funktion taucht ja nicht im OKR auf…
1:03:38 Marco
… nicht in meinem. Der Unterschied ist: Bei Cross-Funktionalität taucht es in meinem Set auf und in deinem Set hast du das Gegenstück dazu. Bei der Support-Funktion taucht es bei mir nicht auf, aber du hast was, weil du meinen Support willst. Also sage ich quasi: Ich werde daran arbeiten, wenn du auf mich zukommst. Dann werde ich dir bei den Meetings helfen, z.B. Aber du kannst nicht von mir erwarten, dass ich das Thema treibe, weil es ja dein Thema und nicht meines ist. Ich werde nicht auf dich zukommen und sagen: Können wir bitte bald dieses Meeting haben. Denn du willst das – nicht ich.
1:04:14 Teilnehmer-Frage: Gibt es einen Anhaltspunkt, wie umfangreich Keyresults sein sollten?
Alles klar. Ich habe noch eine letzte kleine Frage, dann bin ich auch schon durch. Und zwar geht es um den Umfang der Keyresults. Ich habe in der Vergangenheit die Erfahrung gemacht, dass es teilweise so war, dass die im Vergleich zu anderen so viele Aufgaben impliziert haben, dass das dann Ein-Tagesaufgaben waren. Gibt es da irgendwie eine Orientierung oder eine Einschätzung, die man vorher machen sollte, wenn man die Keyresults definiert?
1:04:39 Marco
Es gibt eine Art Faustformel: Wenn du 1/20 der Ressourcen des ganzen Teams für ein Quartal dahinter hast, brauchst du ein eigenes Keyresult. D.h., wenn sie darunter sind, können sie sich möglicherweise subsumieren. Es ist aber hilfreich mal zu überschlagen: Wie viel Anstrengung steckt in den einzelnen Keyresults. Wenn du zwanzig Keyresults hast und i.d.R. 60 Arbeitstage, eher etwas weniger, dann kannst du das überschlagsmäßig ausrechnen. Dann ist es realistisch, mit dem bestehenden Team alle drei Tage ein Ergebnis zu liefern. So kann man sich der Sache nähern. Wenn ich dann ein paar Keyresults weniger habe, dürfen die anderen Themen etwas grösser sein. Das gibt so für den Anfang einen ganz guten Näherungswert.
1:05:40 Teilnehmer
Super. Vielen Dank.
1:05:42 Marco
Gerne.
XY, du hattest dazu eine Frage, glaube ich?
1:05:45 Teilnehmer-Frage: Wie sollen unvorhersehbare Tätigkeiten in den Keyresults abgebildet werden?
Ja, ich fand das ganze spannend, mit der Notaufnahme und dass es vorhersehbar ist, dass da Leute hinkommen, es aber nicht kalkulierbar ist, wie lange das dauert und was die alle haben.
Meine Abteilung kümmert sich um IT-Support, das ist ziemlich vergleichbar, würde ich sagen. Welche Computerproblem reinkommen, kann am Ende auch keiner sagen. Wie würdest du sagen, wie so ein Tagesgeschäft dann überhaupt in den Keyresult abbildbar ist? Das Ziel dahinter kann ja per Definition gar nicht sein, das weg zu automatisieren. Oder geht das irgendwie?
1:06:20 Marco
Ich würde auf jeden Fall immer darüber nachdenken: Wie kommt derjenige, der jetzt auf mich zukommt, das nächste Mal nicht mehr?
1:06:30 Teilnehmer
Ja, gut.
1:06:33 Marco
Na ja, es ist bei jeder Support-Funktion immer das Gleiche: Dass du und derjenige, der Support beansprucht, beide gerne lieber keinen Support brauchen würden. Folglich ist die erste Maxime, darüber nachzudenken, wie man das hinkriegt. Dann bleibt immer noch etwas übrig. Dann kann ich sagen: Jetzt haben wir so und so oft das gleiche Problem gehabt, jetzt mache ich dazu ein Video-Tutorial – dann können sich die Leute irgendwie selber helfen. Dann habe ich schon mal 20% weniger. So könnte man sich iterativ den Dingen widmen. Blöder Vergleich, aber: Das nächste Mal stelle ich eine Schachtel Pflaster an den Eingang und die mit einem kleinen Kratzer können sich selber helfen. Funktioniert nicht ganz in dem Bild, aber du verstehst, die Analogie auf den IT-Support. Man versucht schon, das iterativ immer so zu lösen, dass das Kundenproblem idealerweise a) gar nicht erst auftritt, b) proaktiv verhindert wird und c) wenn es dann doch kommt, dass man sich irgendwie selbst helfen kann, um dann noch das zu machen, was übrig bleibt. Damit bleibt der Teil des Unvorhersehbaren über die Dauer zwar kalkulierbar, aber er wird vielleicht kleiner.
1:07:56 Teilnehmer
Wenn ich es richtig verstanden habe, würdest du gar nicht dazu übergehen und versuchen, das Tagesgeschäft, also das Unvorhersehbare, in Objectives und Keyresults unterzukriegen: Sondern du würdest eher versuchen, den Optimierungsprozess als festen Bestandteil zu sehen, und da nochmal weiter zu überlegen, wie wir das noch besser machen können und das in Objectives formulieren.
1:08:20 Marco
Nein, ich würde den Optimierungsprozess formulieren und das, was übrig bleibt, ebenfalls. Aber mit der Theorie, dass das, was übrig bleibt, von Quartal zu Quartal kleiner wird, weil die Optimierungen greifen und wir weniger von dem unvorhersehbaren, manuellen Support kriegen. Denn nur so kriegst du auch hin, dass du möglicherweise auch entscheiden kannst, wann es zu teuer ist. Das Ideal von Service ist nicht: sofort und immer, sondern: in einem vertretbaren Rahmen. Dadurch wird es leistbar und bezahlbar. Den musst du ja auch definieren: Wie kann denn der vertretbare Rahmen für den Support aussehen? Das zu definieren würde ich schon als Teil des OKR-Sets sehen.
1:09:15 Teilnehmer
Okay. Super, vielen Dank.
1:09:18 Marco
Gern.
1:09:21 Teilnehmer-Frage: Kann man OKRs in Asana abbilden?
Ja, jetzt bin ich an der Reihe. Ich grüße aus der Schweiz. Besten Dank, Marco, für deine Zeit, die du uns zur Verfügung stellst.
Meine Frage ist im Zusammenhang mit Tools: Wir sind im klassischen Projektgeschäft tätig, wir versuchen eigentlich, die Probleme des Kunden in OKRs zu packen und danach eine Roadmap zu setzen. Und dann über monatliche Erfolgskontrollen die Messbarkeit darzulegen. Momentan setzen wir auf klassische Projektmanagement-Tools wie Asana, aber das ist sehr unglücklich, finde ich persönlich.
1:10:01 Marco
Warum?
1:10:04 Teilnehmer
Weil, wie du weißt, Asana ist ja Milestonedreaming. Und OKRs…
1:10:14 Marco
Also, wir benutzen Asana so, dass da, wo der Milestone steht, das Keyresult wäre, glaube ich. Darunter hättest du dann die Tasks, die bleiben die Tasks. Über dem Milestone bist du dann in der Section, glaube ich. Wenn du nicht die Goals-Erweiterung hast, dann kannst du die Section zu Objectives machen, die Milestones zu Keyresults und die Tasks sind die Tasks. Ob das Milestone heißt, was da ein bisschen ein Symbol ist, ist mir an der Stelle egal, solange du weißt, dass das dein Key Result ist und du das dahin schreibst, dann funktioniert das mit Asana eigentlich super.
1:10:57 Teilnehmer
Okay. Also ihr benutzt selbst auch Asana?
1:11:00 Marco
Ja.
1:11:01 Teilnehmer
Spannend.
1:11:03 Marco
Wir haben das dann mit allen möglichen Feldern und mit irgendwelchen Datenauswertungs-Tools, sodass wir aus dem Ding auch unsere Zahlen in Data-Studio und so reinziehen können, um Auswertungen zu erfahren. Weil du Asana ja mit Feldern erweitern kannst, funktioniert das eigentlich ganz gut.
1:11:23 Teilnehmer
Okay. Gut, das wäre es eigentlich schon von meiner Seite. Danke.
1:11:30 Marco
Sehr gerne. Dann XY…
1:11:35 Teilnehmer-Frage: Wie kann ich mit äußerst knappen Ressourcen geschickt OKRs einführen?
Hallo von mir. Danke auch Marco für deine Zeit.
Vieles von dem, was ich gefragt hätte, ist schon abgedeckt worden. Das ist hervorragend.
Wir sind in einer etwas speziellen Situation, als NGO nämlich. Wir sind ein relativ großer Verein mit ungefähr 5‘000-7‘000 aktiven Ehrenamtlichen und ungefähr 50 hauptamtlichen Mitarbeitern an der Geschäftsstelle. Wir sind sehr missionsgetrieben, also Mission und Vision ist überhaupt nicht das Thema. Eine Strategie haben wir auch. Wir denken aber grundsätzlich immer tätigkeitszentriert. Wir tun die Dinge, weil wir sie eben tun, und fragen uns viel zu wenig nach der Wirkung.
Gerade deswegen erscheinen uns OKR spannend und wir sind jetzt gerade an dem Punkt, wo wir in der Führungsebene einig sind, dass wir das ausprobieren möchten, aber nicht so sicher sind, starten wir unter uns erstmal einen kleinen Testballon oder rollen wir das ganze jetzt direkt aus? Dies vor dem Hintergrund, dass in einer NGO die Ressourcen äußerst knapp sind und alle in diesem Geiste arbeiten. Wir müssen sparen und ich habe sowieso viel zu viel zu tun für meine knappe Zeit, zudem jetzt gerade viele in Kurzarbeit sind. Das ist ein etwas ungünstiger Nährboden – vom Setting her ja, vom Emotionalen her nicht so wirklich. Da wäre meine Frage: Wie bekommt man das hin, so eine Art „kontrollierten Rollout“ zu machen, ohne gleich alle zu überfordern und ohne sich auch direkt zum Sklaven der Methode zu machen? Also ohne zu viel Gefühl, zu viel Overhead reinzustecken – was am Ende gar nicht nötig ist. Ich schwanke noch zwischen der …
1:13:28 Marco
Da fragst du den Falschen, weil es nicht zu viel Overhead gibt. Denn wenn ich glauben würde, dass es zu viel Overhead hätte, wäre die Methode, so, wie wir sie bauen, anders. Sonst wäre sie ja nicht lohnend. Das, was du an Overhead hineinsteckst, muss sich ja lohnen. Demzufolge ist das alte Bildnis: Wenn du keine Zeit hast, den Zaun zu flicken, weil du die Hühner fangen musst, ist die Frage, wo du anfängst.
Du bist ja in guter Gesellschaft: Alle anderen haben auch zu wenig Ressourcen für die Sachen, die sie sich vornehmen. Alle, die hier sind, verspüren den gleichen Druck – würde ich mal wetten. Wenn einer sagt: Mir ist immer langweilig, wäre es jedenfalls seltsam.
Ich sehe das in jedem Unternehmen, in jeder Position: Es ist immer zu wenig Ressource für zu viele Sachen. D.h., dann ist die Aufgabe eine reine Priorisierungsaufgabe. Eigentlich geht es darum, bessere Entscheidungen darüber zu treffen, was du mit deiner Zeit anfangen kannst. Alles andere nicht. Die Zeit ist nur einmal da. Du kannst versuchen, das dehnbar zu machen, indem du sagst: Dann arbeite ich halt nicht bis sechs, sondern bis acht und fange nicht um neun an, sondern um sieben. Dann ist auch noch der Samstag dran, aber irgendwann ist das endlich. Das Modell funktioniert nicht.
Wenn du aber sagst: Ich habe einen festen Rahmen definiert und der ist X. Dann versuche ich, aus X das Beste herauszuholen. Dann kann ich das nur einmal investieren. Stell dir vor, du hättest Aktien oder du würdest Geld in Aktien investieren. Du kannst deinen Euro entweder in das eine oder in das andere Unternehmen stecken – beide gleichzeitig geht nicht. Jetzt musst du entscheiden, wo der Euro besser investiert ist. Das ist ja bei deiner Zeit und den Projekten, die du intern machst, genau das Gleiche. Also versuchst du, für deine Zeit die sinnvollste Investitionsentscheidung zu treffen. Da ein bisschen schlauer darüber nachzudenken, im Sinne von: Ich nehme mir mal ein bisschen Zeit, um darüber nachzudenken. Ich reflektiere, dann wird die nächste Entscheidung hoffentlich besser und der Return aus den Investitionen höher. Das rechtfertigt auf jeden Fall die Zeit, die du in deine Überlegungen steckst. Das ist die Hypothese dahinter.
Demzufolge ist das gar kein NGO spezifisches Thema, sondern ein generelles Thema. Ihr müsstet euch halt überlegen: Wollen wir uns ein bisschen Zeit nehmen, um die Investments besser zu prüfen, um dann hoffentlich höhere Returns zu bekommen? Oder schlägst du einfach die Zeitung auf und kaufst die ersten drei Aktien und denkst: Das wird schon passen. Das würde ja auch keiner machen.
Das macht relativ deutlich – hoffe ich zumindest – wie das Modell ist und warum der Overhead nicht Overhead ist, sondern warum schlauer darüber nachdenken schon Teil des Modells ist und sich hinten heraus auszahlt.
Beantwortet das die Frage?
1:16:50 Teilnehmer
Ja. Die Herausforderung wird nicht kleiner.
1:16:57 Marco
Ja, aber du hast zumindest eine Argumentation, den Kollegen klar zu machen: Lasst doch mal kurz darüber nachdenken. Kann auch noch ein paar andere blöde Sprüche ins Rennen schicken, sowas wie: Zuerst mal die Axt scharf machen und dann auf den Baum losgehen – ist auch irgendwie hilfreich. Dieses Bild macht dir dann irgendwann klar, dass dieses: Ich arbeite einfach los und wenn es zu viel wird mache ich schneller – löst das Problem nicht. Nach fest kommt ab. Nach schneller kommt zu schnell und da ist Überforderung. Ich will nicht, dass ihr euch überfordert. Ich will, dass ihr sagt: Die Ressourcen, die wir haben, sind gegeben, lass mal schlau darüber nachdenken, ob wir A oder B machen. Dann dass wir A UND B machen, ist eine Illusion. Wenn du die Illusion auflöst und dann darüber nachdenkst: Ich kann nur A ODER B. Ich mache A.
Und dann machst du A nicht drei Jahre, sondern drei Monate. Wenn A falsch war, machst du danach lieber ein bisschen schneller B. Aber das lernst du dann schon unterwegs. Aber lange an der Illusion festzuhalten: Ich kann A und B gleichzeitig haben, führt halt dazu, dass Leute das versuchen und das führt zu Überforderung, Ausbrennen und all dem, was du als NGO noch weniger haben willst, weil die Leute ja nicht mal …
1:18:25 Teilnehmer
… anständig bezahlt werden.
1:18:26 Marco
Das hast du jetzt gesagt, aber so etwas in der Richtung könnte es sein. Ich habe genug Kunden, die sagen: Ich mach das hier noch drei Jahre und dann… Aber auch das halte ich für falsche Motivation und Anreiz. Aber bei euch muss man ja zweimal drauf aufpassen, dass die Leute sich nicht unnötig kaputt machen. Man will ja den größten Nutzen aus den Ressourcen auch gesellschaftlich herausholen. Somit ist es schon gut, darüber nachzudenken.
1:18:57 Teilnehmer
Alles klar, danke.
1:58:59 Marco
Gerne. Jetzt habe ich ein bisschen den Überblick verloren. XY ist, glaube ich, dran.
1:19:05 Teilnehmer-Feedback: Knappe Ressourcen hin oder her, wir haben uns den OKRs voll und ganz verschrieben und sind zufrieden damit.
Ja, hallo. Wir sind ein Feature-System für Badsanierungen und haben vor 18 Monaten OKRs eingeführt. Ich war vor 24 Monaten mal bei dir auf dem Offside und habe das in unser neues Unternehmen mitgenommen. D.h., vieles von dem, was ich hier gehört habe, haben wir auch erlebt. Eigentlich wollte ich auch auf XY eingehen. Wir haben nämlich auch die Situation, dass wir einen OKR-Champion haben, der auch ein eigenes Set hat, weil wir eben auch nur 10 Leute sind. Aus unserer Erfahrung heraus kann ich dem Marco Recht geben. Er sitzt in der zweiten Führungsebene, diskutiert aber auf Augenhöhe mit der ersten Führungsebene dann auch und sagt: Das war jetzt nicht gut. Dadurch, dass wir eben so klein sind und so durchlässig und offen, ist es auch kein Thema, dass wir uns da irgendwie „angegriffen“ fühlen. Das funktioniert sehr gut, muss ich sagen. Er ist auch sehr der Herr.
Alles in Allem würde ich gerne, wenn ihr mir erlaubt, ich habe genau das Thema mit den Ressourcen, was XY grade geschrieben hat. Das ist auch das, was Marco gesagt hat: Wir haben alle immer zu wenig Ressourcen. Das ist eigentlich unser größtes Problem. Wir haben uns dem System verschrieben, d.h., wir machen OKRs und da gibt es nicht links und nicht rechts und wir probieren das mal aus. Ich weiß auch eine Phrase: Ein bisschen schwanger geht halt nicht.
Also, wir haben gesagt, wir machen OKRs und ziehen die auch durch. Es ist halt wie alles im Leben eine Skalierungskurve, es ist eine Entwicklung, es ist eine Diskussion, die OKR-Meetings, die OKR-Workshops. Wir haben von Mal zu Mal ein besseres Trainingslager. Aber man muss ich halt entscheiden, das zu tun, und kann das nicht so ein bisschen nebenher machen. Oder: Mal gucken, wie das funktionieren könnte, das ist das, was wir mitgenommen haben und was wir auch, vertreten.
1:21:26 Marco
Aber das ist schon mal sehr cool, dass ihr die Erfahrung jetzt so lange gemacht habt und durchhaltet und die positiven Effekte davon spürt.
1:21:35 Teilnehmer
Das kann man sagen. Wenn man einmal in dem System drinnen ist und dieses OKR klingt ja immer so „hart“, dann hast du einen Zustand und versuchst, diesen Zustand zu erreichen. Und wenn du das dann auch erreichst oder zum Teil erreichst oder mit deiner 70%-Regel erreichst, und das über mehrere Quartale – dann bekommt das Ganze am Ende ja ein Bild. D.h., diese Zustände, diese Fortschritte werden ja aus einem Mosaik geformt und dann erst bekommst du das gesamte Bild davon geliefert.
Wenn du dich das erste Mal hinsetzt und ein OKR-Set machst, bist du halt Anfänger.
1:22:18 Marco
Und erfahrungsgemäß sind noch andere Baustellen offen. Meistens sind ja die Strategien nicht ganz so Strategien oder sie sind nicht klar oder nicht so gut formulier oder vielleicht auch eher Ziele. Da kommt eine Menge zusammen.
Vielleicht nochmal der Punkt von vorhin. Wenn man immer zu wenig Ressourcen hat, kann man es auch positiv sehen: Man hat eine Menge Ideen, vielleicht hat man zu viele Ideen, aber das ist ja eigentlich besser, als wenn man zu wenig hätte. So könnte man es auch positiv betrachten. Ausreichend Ideen um die Ressourcen, die man hat, länger zu beschäftigen. Jetzt muss man nur überlegen, welche davon kommen zuerst.
Cool. Vielen Dank. Hast du noch eine Frage im Anschluss?
1:23:05 Teilnehmer-Frage: Hast du einen Tipp, wie man diese lange Fokussierung durchhalten kann?
Wir machen mittlerweile gute OKR-Sets, glaube ich, aber diese Fokussierung, diese Konzentration, wenn du da noch irgendwie diesen Schlüssel-Tipp hast, dass wir das auch alle durchhalten können?
1:23:21 Marco
Jetzt hast du ja Erfahrung. Wie oft ist dir passiert, dass du am Ende des Ziels noch ganz viel Quartal übrig hattest?
1:23:33 Teilnehmer
Selten.
1:23:35 Marco
Selten oder noch nie?
1:23:38 Teilnehmer
Am Ende des Ziels hatten wir noch ganz viel Quartal.
1:23:43 Marco
Also, du hattest nicht genug Ziele für das Quartal.
1:23:46 Teilnehmer
Nein, ich hatte da immer zu wenig Zeit gehabt, aber immer genug Aufgabe.
1:23:52 Marco
Ich habe noch nicht ein einziges Mal gesehen, dass irgendwo ein OKR-Set sozusagen „ausgelaufen“ wäre und ein einziges Team gesagt hätte: Oh, wir waren fertig. Was machen wir denn jetzt noch zwei Wochen? Nicht ein einziges – und ich habe schon ein paar gesehen.
Davon könnte man ableiten, dass man auch jetzt nach den vielen Monaten, die du damit schon läufst, aber immer noch ein bisschen in der Überschätzung darin bist, was man in drei Monaten so hinkriegt. Versuch es doch mal, es noch kleiner anzugehen und zu sagen: Dann stehen da halt nur drei Ziele, aber die sitzen danach und das waren die richtigen. Also, noch ein Stückchen enger ranzugehen, dass die Trefferwahrscheinlichkeit näher an der Realität ist und nicht noch immer fünf Sachen halb sind. Du willst drei Sachen ganz, statt fünf Sachen halb.
1:24:51 Teilnehmer
Wir haben ein antizyklisches Quartal. Das geht jetzt noch fünf Wochen, d.h., wir machen über Weihnachten und Neujahr und gehen bis in den Februar. Wir haben nicht das Kalenderquartal, wir haben drei Monate. Ich werde es das nächste Mal beherzigen.
1:25:12 Marco
Sehr gut.
1:25:14 Teilnehmer
Das Schlimme ist, ich bin nicht alleine, der Kollege ist auch hier, also unser OKR-Champion ist auch hier. Er wird mich also gleich festnageln.
1:25:24 Marco
Hast du’s auch noch aufgenommen? Er kann dann später auch noch hin spulen, wenn es so weit ist.
Super, dann müssen wir ein bisschen auf die Zeit schauen, aber so ein, zwei Fragen kriegen wir noch unter. Ich glaube, XY müsste dann der nächste sein.
1:26:00 Teilnehmer-Frage: Könnte die Anzahl Meetings in kleineren Unternehmen reduziert werden?
Zu den Meetings… Also man kommt immer auf sieben Meetings pro Woche, ja? Kannst du die vielleicht nochmals aufzählen? Die sind auch relativ lang. Die Frage wäre, ob wirklich immer so starr gedacht werden muss, wie es von euch auch „vorgegeben“ wird, oder ob man das eben auch flexibel für seine eigene Organisation adaptieren kann, so, wie es halt Sinn macht.
1:26:56 Marco
Es ist schon so gedacht, dass es Sinn macht, aber man muss vielleicht gucken, ob es bei kleinen Organisationen die eine oder andere Überschneidung gibt.
Ich habe den Kurs schon recht lange nicht mehr selber gemacht, aber ich glaube, ich weiß, in welcher Richtung die Frage geht. Du hast ja als Team-Lead ein Meeting mit deinem Team. Dann hast du die einzelnen OKR-Meetings mit den Direct-Reports. Dann hast du mit dem gesamten Leadership-Team Meetings und ein One-and-One mit dem oder der CEO. Damit ergibt sich dann – je nachdem, wie viele Direct-Reports du hast – z.B. sieben.
Ist dir die Struktur damit klar? Ob sieben oder neun rauskommt, hängt von dem Team ab. Aber die Struktur ist: Immer da, wo es eine Direct-Line gibt, gibt es ein Meeting. Wenn ich mit vielen Leuten am Tisch sitze, nehme ich das obere OKR-Set. Also: Wenn ich als Team-Lead mit vielen Leuten da sitze, dann geht es um MEIN Set. Wenn ich mit meinen Direct-Reports da sitze, geht es um DEREN Set, denn: weniger Augen = kleines Set. Wenn viele Leute dasitzen und der CEO im Raum ist, geht es um das Company-Set, wenn der CEO nur mit einer Person da ist, z.B. mit mir, dann geht es um MEIN Set.
So kriegst du die Struktur, dass du – in Deutschland würde man das Subsidiaritäts-Prinzip nennen – das Problem immer an der kleinstmöglichen Stelle löst. So wenig Leute wie möglich in die Diskussion miteinbeziehen, aber immer so viele, wie nötig, um das Problem zu lösen. Das ist die Idee dahinter. D.h., wie wir vorhin gesagt haben: Du kriegst innerhalb von einer Woche alle Entscheidungen durch das ganze Unternehmen rauf und runter diskutiert und entschieden, weil du immer in das nächst größere Meeting eskalieren kannst, um dort die Entscheidungen zu treffen und die dann wieder runter zu brechen.
Wenn du jetzt z.B. sagst: Ich habe aber nur zwei Leute in meinem Team, muss ich dann ein Team-Meeting machen? Und mit jedem nochmal ein einzelnes One-and-One? Kommt drauf an. Es gibt Konstellationen, da macht das nicht viel Sinn, weil man das dann gleich alles im Team-Meeting macht, wenn es eh nur drei Leute sind. So könnte man das anpassen.
Ist damit die Frage beantwortet?
1:29:36 Teilnehmer-Frage: Können die Meetings den Umständen entsprechend auch weniger lang sein?
Ja, auf jeden Fall. Ich werde es aber mit den sieben nochmals nachgucken, um zu sehen, wie man da drauf gekommen ist.
Aber zur Dauer der Meetings? Das ist wahrscheinlich auch so, wie es dann halt dauert. Man muss jetzt zwei Stunden ja auch nicht unbedingt befüllen, wenn man sie nicht braucht.
1:29:52 Marco
Nein, das auf keinen Fall. Wenn man feststellt, in 20 Minuten haben wir alle Punkte diskutiert und jeder weiß, was der Status ist und es gibt gar keine Probleme. Dann kann jeder wieder an seine Arbeit gehen. Man muss sich da nicht „tod meeten“.
1:30:10 Teilnehmer
Super. Danke.
1:30:15 Marco
So, jetzt machen wir noch eine Frage.
1:30:26 Teilnehmer-Frage: Wie ist die Abgrenzung zwischen OKRs und der Balanced Scorecard?
Wenn ich mich richtig erinnere, ist das die Frage mit der balanced Scoarcard. Ich habe gerne mit der balanced Scoarcard gearbeitet. Ich weiß auch nicht, in welchem Umfang...also wir haben das immer weniger Top-down macht und mehr aus den Teams heraus. Also für mich geht balanced Scoarcard, wenn man es eher von der weniger hierarchischen Ebene denkt, auch sehr stark in die Richtung von OKR. Ich weiß nicht, wo da für dich die Abgrenzung ist oder wie groß die Unterschiede sind.
1:30:58 Marco
Also so wirklich in der Implementierung ist uns in all den Jahren keine balanced Scoarcard begegnet. Wir haben nirgends eine raus operiert und OKRs rein implementiert, weil das Thema in einer voll ausgeführten Implementierung dann doch nicht so verbreitet war. Was wir schon sagen würden, ist, dass unser Strategie-Layer die Grundideen von so einer balanced Scoarcard aufgreift. D.h., ich vereinfache es mal in unterschiedliche Richtungen, sich zu orientieren und zu sagen: Was ist mit einer Kundenperspektive, mit einer Umweltperspektive. Diese sauber zu deklinieren und in Strategien zu formulieren und dann quartalsweise hinzugehen und zu sagen: Wenn das die Strategien sind – wo sind denn in dem Quartal meine Ressourcen auf den unterschiedlichen Strategien am besten eingesetzt, um am weitesten nach vorne zu kommen? Und um natürlich auch im Auge zu behalten, wenn man jetzt drei Mal auf eine Mitarbeiter-Perspektive verzichtet hat. Ein viertes, ein fünftes und ein sechstes Quartal könnte das gefährlich werden, wenn wir diese Dimension immer außer Acht lassen. Vielleicht müssen wir da mal irgendwie mehr investieren und dazu z.B. weniger Feature, oder was auch immer, bringen.
Das ist sozusagen unsere „Übersetzung“ von der Grundidee so einer balanced Scoarcard, unterschiedliche Perspektiven, Betrachtungsweisen und Interessengruppen mit einzusetzen. Und das dann wieder in einem iterativen System in konkrete Ziele übersetzen, um nicht auf dem Strategie-Layer Ziele zu haben, sondern hier eben nur Strategien, also Vektoren ohne Erwartungswert zu definieren, wo wir unsere Energie investieren wollen. Ich glaube, das wäre so ein bisschen die Abgrenzung in Kürze.
Hilfreich?
Sehr gut.
Dann haben wir den Zeitrahmen von heute schon wieder ganz gut ausgenutzt. Ich hoffe, es ist nicht so schlimm, wenn wir ein, zwei Fragen auf die nächste Session vertagen.
XY, du noch?
1:33:14 Teilnehmer-Frage: Wann ist die nächste Session. Werde ich automatisch dazu eingeladen?
Du kommst gerade zu meiner Frage. Wann findet die nächste Session statt und ob ich da automatisch dazu eingeladen werde. Ich fand das sehr interessant. Vielen Dank.
1:33:22 Marco
Die nächste Session findet am 16. Februar um 16 Uhr statt und ihr könnt euch über die Webseite ab morgen anmelden. Da ist dann der neue Anmeldelink im Pop-Up hinterlegt. Da könnt ihr euch dann einfach eintragen, dann erhält ihr die Einwahl-Daten geschickt und seid gerne wieder dabei.
1:33:45 Teilnehmer
Sagst du nochmals, welche Webseite das ist? Ich habe den Link von meiner Frau weitergeleitet bekommen.
1:33:48 Marco
Sehr gut. Murakamy.com
1:33:52 Teilnehmer
Okay, perfekt. Danke dir.
1:33:55 Marco
Dann ganz herzlichen Dank euch für eure Zeit, eure interessanten Fragen und den Austausch. Falls ihr Lust habt, wir probieren am Freitag, um 17.00 Uhr, so ein ähnliches Format in dieser neuen Clubhaus-App aus. Ein bisschen Hype muss ja auch sein. Falls euch das Thema irgendwie nach oben treibt und ihr früher noch ein paar Antworten wollt, wäre das vielleicht auch eine Alternative. Ansonsten gerne am 16. Februar.
Vielen, vielen Dank für eure Zeit und die spannenden Gespräche und bis dahin!