OKR in der Praxis – Im GesprĂ€ch mit Nikolaus Neuerburg, Software AG

OKR in der Produktentwicklung ist ein Match – zumindest fĂŒr mich. Doch wie sehen das andere Produktmenschen? Das wollte ich im GesprĂ€ch mit Nikolaus Neuerburg, Senior Director of Product Management bei der Software AG herausfinden. Wie steuert er die Produktorganisation rund um die Themen IoT (Internet of Things)? Was wĂŒrde er retrospektiv bei der OKR-EinfĂŒhrung anders machen? Und wann machen OKRs aus seiner Sicht keinen Sinn?

Heute im Interview

  • Nikolaus Neuerburg, Senior Director of Product Management, Software AG 
  • Die Software AG bietet smarte Softwarelösungen und Services fĂŒr Unternehmen an.

Christina: Schön, dass wir heute miteinander sprechen. In welchem Kontext bist du unterwegs und wo setzt ihr das Rahmenwerk “OKR” ein?

 

 

Ich leite ein Team von Produktmanagern bei der Software AG. Wir sind zustĂ€ndig fĂŒr den Bereich IoT & Analytics. Wir bauen Plattformen, die Maschinen mit dem Internet verbinden und dann mit den angebotenen Daten schlaue Sachen machen, zum Beispiel Fernwartung. 

Wir sind stark gewachsen und haben mittlerweile fast 20 Teams mit TeamgrĂ¶ĂŸen von 5 bis 13 Personen. Die bestehen hauptsĂ€chlich aus Entwickler:innen (Backend, Frontend) sowie einem Designer.in und einem Product Owner. Das Team, das ich leite, besteht aus sieben Produktmanager, die mit einem oder mehreren Teams zusammenarbeiten. Da gibt es immer mal wieder Diskussionen zur Rolle Product Manager vs. Product Owner. OKR sind bei uns das erste Mal aufgekommen, als wir ĂŒber die Probleme gesprochen haben, die wir in unseren Teams haben. Unser Produkt “Cumulocity” ist ein Zukauf der Software AG gewesen und wir haben das sehr schnell skaliert und an mehr Kunden verkauft. Wir hatten dann einige der ursprĂŒnglichen Produktteammitglieder in neuen Rollen innerhalb der Software AG und eine “Delivery Mannschaft” in den Teams.  Über die “Empowered Team”-Initiative wollten wir wieder viel mehr Verantwortung in die Teams geben (z.B. indem sie bestimmte Bereiche unserer Plattform viel eigenstĂ€ndiger gestalten) und sie viel aktiver in die Strategieumsetzung einbinden. 

In dieser ganzen Transformation kamen dann wichtige Fragen in den Teams auf. Was ist unsere Strategie? Wo wollen wir hin? Wenn wir nicht einfach nur irgendwelche Features bauen wollen, was wollen wir dann? Wie können wir zum Produkt wirklich beitragen? 

Da kam von einem Kollegen die Idee, weil er das in seinem vorherigen Unternehmen kennengelernt hatte: Könnten das Rahmenwerk “OKR” uns nicht helfen, da eine Synchronisation zwischen Firmen-, Produktstrategie und Erwartungen an das Team zu ermöglichen? Heute nutzen wir OKR als Framework im Bereich Cumulocity IoT und auch dort nur in der Produkt- und nicht in der Vertriebsorganisation. 

 

 

Christina: Was lÀuft gut?

 

 

Nikolaus: Der grĂ¶ĂŸte Nutzen ist meines Erachtens, dass wir uns zwingen, ein GefĂŒhl dafĂŒr zu bekommen, was realistisch und machbar ist. Wir haben natĂŒrlich große Ambitionen und auch eine Tendenz, 100 Objectives und 300 Key Results zu formulieren. Es ist sehr wertvoll diese Diskussionen und eine gemeinsame Ausrichtung zu haben. Da hatten wir natĂŒrlich eine Lernkurve, weil wir zu Beginn mit völlig unrealistischen Zielen losgelaufen sind. Jetzt haben wir zwei Ziele und da schauen wir alle zwei Wochen drauf und dadurch haben wir einen guten Fokus. Ein Ziel zu haben, löst gute Diskussionen aus, weil man dann sehr schnell anfĂ€ngt kreativ zu werden. 

 

Was ebenso gut lĂ€uft, ist die Transparenz ĂŒber unsere Strategie. Dadurch, dass die Teams jetzt Ziele definieren, sind sie erstmal per se viel mehr daran interessiert, die Strategie auch zu verstehen.  Das heißt, wir haben jetzt viel mehr vom Team getriebene Diskussionen zur Produktstrategie. Ich spĂŒre ein viel aktiveres Interesse in den Teams mitzureden und mitzugestalten. Dadurch entsteht ein stĂ€rkeres ZugehörigkeitsgefĂŒhl. 

 

 

Christina: Wo gibt es Verbesserungsbedarf?

 

 

Nikolaus: Unsere Grundproblematik bei OKRs war, dass die Teams sehr viel zu tun haben, zum Beispiel Maintenance-Aufgaben, Support oder Commitments, die wir Kunden gegeben haben. Es hat sich fĂŒr die Teams angefĂŒhlt, als komme OKR jetzt noch “on top”. Das ist dann umgeschwenkt, als wir uns entschieden haben, OKRs erstmal nur fĂŒr “Prozessverbesserungen” zu nutzen (z.B. bessere CI/CD-Entwicklung). Das hat allerdings dann dazu gefĂŒhrt, dass wir drei Backlogs hatten: Feature, Support, Prozessverbesserung. Da sind wir aktuell dabei, das zu Ă€ndern und auch OKRs viel vernetzter zu betrachten. Die Guideline ist, dass es ein OKR-Set jeweils fĂŒr Feature, Support und Prozessverbesserung/ Lieferung gibt. Das wichtigste Thema, was wir aktuell angehen, ist, wie die Planung und das Alignment zwischen den Teams besser lĂ€uft. Wir denken gerade darĂŒber nach, beispielsweise zweimal im Jahr einen Sprint eben genau fĂŒr die Strategiearbeit und Planung zu nutzen und auch viel regelmĂ€ĂŸiger auf die OKRs zu schauen. Wenn du erst am Ende des Zyklus auf die OKRs schaust, kannst du es auch sein lassen. Wir binden die GesprĂ€che ĂŒber unsere Ziele viel stĂ€rker in unsere Team-Meetings ein. 

 

 

Christina: Ihr habt vor zwei Jahren mit OKR angefangen. Was wĂŒrdest du retrospektiv anders machen?

 

Nikolaus: Wir hatten bei der OKR-EinfĂŒhrung externe UnterstĂŒtzung durch einen Change-Consultant. Im Nachhinein wĂ€re es glaube ich besser gewesen, jemanden mit dezidierter OKR-Expertise zu haben. Wir haben einfach unterschĂ€tzt, wie viel (Überzeugungs-) Arbeit das ist, OKR in den Teams zu etablieren. Heute wĂŒrde ich auch nur mit einem Team anfangen und mir gleichzeitig Gedanken machen, wie wir das schrittweise auf die anderen Teams ĂŒbertragen können. Das alles braucht Zeit und eben Menschen, die den Mehrwert von OKRs fĂŒr unsere Organisation verstehen und immer wieder kommunizieren. Auch ist es vollkommen in Ordnung, wenn der erste OKR-Zyklus nichts wird, solange man diesen als “learning opportunity“ sieht und dran bleibt.

 

 

Christina: Wann macht OKR aus deiner Sicht keinen Sinn?

 

Nikolaus: Erstens, muss man vorsichtig sein, wenn es bereits andere Zielsetzungs-Frameworks gibt und Incentivierungen hieran geknĂŒpft sind. Bei uns war dies der Fall mit persönlichen MbOs & Team OKRs. 

Zweitens wird es schwierig, wenn es keine scharfe Produktstrategie gibt. OKRs als Zielsetzungsframework helfen nicht, wenn es nicht eine klare Strategie gibt, aus der sich Ziele und PrioritĂ€ten ableiten lassen. Daher sollte man meines Erachtens erst mit OKRs starten, wenn es eine klare Vision und Strategie gibt. In unserem Fall hatten wir im Vorfeld der OKR-EinfĂŒhrung sehr viel Zeit in die Weiterentwicklung und Kommunikation der Produktstrategie gesteckt und die Teams haben sehr viele GesprĂ€che mit Kund:innen gefĂŒhrt und konnten so eine relativ klare Idee entwickeln, wohin die Reise gehen soll.

OKRs haben uns dann geholfen, die Strategie Schritt fĂŒr Schritt zu schĂ€rfen und die Teams hatten gerade genug Guidance, selbststĂ€ndig in die Richtung zu laufen.  

Drittens ist es eine Herausforderung, Fortschritt zu messen und Key Results zu definieren, ohne eine gute Datengrundlage zu haben. Bei uns war dies eine große Herausforderung, weil wir uns nicht nur dafĂŒr interessieren, was Nutzer mit unserer Plattform anstellen, sondern auch welche Art von GerĂ€ten mit unseren Systemen verbunden sind und wir nicht nur eine zentrale Instanz haben, sondern viele große Kunden haben, die ihre eigene Installation unserer Systeme haben. Wir haben da zum GlĂŒck vor zwei Jahren fĂŒr uns einen Weg gefunden, wie wir mehr Nutzungsdaten erfassen können.

Diese Datenbasis erleichtert auch die Arbeit mit Key Results, weil du Dinge viel einfacher messen kannst, als einfach einen weiteren Fragebogen rauszusenden. 

 

Christina: Vielen Dank fĂŒr das GesprĂ€ch und ich bin gespannt, wie eure OKR-Reise weitergeht.

 

Nach oben scrollen
Cookie Consent mit Real Cookie Banner