Engineering OKRs: Leitfaden + 25 Beispiele aus der Praxis

Entwickler:innen sind täglich mit zahlreichen technischen Problemen konfrontiert – die sie am besten alle gleichzeitig lösen sollten, damit das Produkt einwandfrei funktioniert. Spezielle „Engineering OKRs“ können Entwicklungsteams (engl. Engineering Teams) helfen, den Überblick zu behalten und sich bei der Produktentwicklung auf das Wesentliche zu konzentrieren.

In diesem Artikel erklären wir, wieso OKRs für Engineering Teams sinnvoll sind und wie man gute Engineering OKRs schreibt – Tipps und konkrete Beispiele inklusive.

Das erwartet dich:

• Warum OKRs für Engineering Teams?
• Engineering vs. Product OKRs
• Wie man gute Engineering OKRs schreibt
• 25 Beispiele für Engineering OKRs
• Fazit: Mit OKRs die technische Arbeit verbessern

Warum OKRs für Engineering Teams?

Damit Entwicklungsteams erfolgreich sind, sollten sie ein gemeinsames Verständnis von Erfolg haben. Die gewählten Messgrößen sollten für das Unternehmen relevant und gleichzeitig leicht zu verstehen sein.

OKRs können Engineering Teams dabei helfen, sich darüber klar zu werden, was sie kurz- und mittelfristig erreichen wollen. Sie werden immer gemeinschaftlich im Team erarbeitet und stellen sicher, dass die technischen Entwicklungsziele mit der Unternehmensstrategie übereinstimmen und alle an einem Strang ziehen.

OKRs tragen also dazu bei, sich bei der Produktentwicklung auf das Wesentliche zu konzentrieren. Sie bieten eine Kurzfassung der übergeordneten Strategie für die einzelnen Entwicklungsteams und verknüpfen kurz- und mittelfristige Prioritäten mit dem übergreifenden Warum. Das sorgt dafür, dass sich Entwicklungsteams auf die Aufgaben konzentrieren, die das Unternehmen wirklich voranbringen.

Zusätzlich verändert sich unsere Welt rasend schnell. OKRs liefern dabei Echtzeitdaten zu Veränderungen in der Umwelt. Außerdem machen sie Fortschritte und Herausforderungen sichtbar. So bleiben Entwicklungsteams agil und können von einem OKR-Zyklus zum nächsten schnell auf neue Bedingungen reagieren.

Engineering vs. Product OKRs

In der Praxis haben Engineering OKRs oft Ähnlichkeit mit Produkt-OKRs – also OKRs für das gesamte crossfunktionale Produktteam aus Produktmanager:innen, Entwickler:innen, Designer:innen, Texter:innen und vielen mehr. Es gibt allerdings einen kleinen, aber feinen Unterschied: Engineering OKRs konzentrieren sich auf die Qualität der (technischen) Arbeit, während bei Produkt-OKRs der Mehrwert für den Kunden im Fokus steht. Das ist zwar etwas vereinfacht und pauschalisiert, zeigt aber die beiden Seiten der Medaille.

Wegweisend für Engineering OKRs sind Fragen wie:

• Wie effizient ist unser Entwicklungsprozess?
• Wie hoch ist die Qualität der Releases?
• Ist unser Entwicklungsteam in der Lage, bestmöglich zu arbeiten?

Insgesamt sind OKRs für Entwicklungs- und Produktteams also eng miteinander verknüpft. Teilweise überschneiden sie sich auch. Es gibt aber einige entwicklungsspezifische Dinge, die in Produkt-OKRs nicht abgebildet sind. Dazu zählen vor allem technische Themen, die nicht das gesamte Produktteam betreffen, aber entscheidend sind, um das Produkt erfolgreich zu realisieren.

Technische Herausforderungen mit OKRs lösen

Entwicklungsteams (vor allem in der Softwareentwicklung) stehen im Arbeitsalltag öfter vor komplexen technischen Herausforderungen. Engineering OKRs können helfen, diese zu meistern, indem sie für Fokus sorgen. Sie richten alle Teammitglieder auf die gleichen Ziele aus. Wenn Probleme auftreten, geben die OKRs eine klare Richtung für die Lösung vor. Sie bieten außerdem Orientierung für Entscheidungen und helfen, technische Verbesserungen zu priorisieren.

Entwicklungsressourcen können so gebündelt und effizienter für die Features und Produkte eingesetzt werden, die auf die strategischen Ziele des Unternehmens einzahlen.

Wie man gute Engineering OKRs schreibt

OKRs für Entwicklungsteams festzulegen, kann schwierig sein. Die OKRs müssen mit den Unternehmenszielen übereinstimmen und gleichzeitig spezifisch genug sein, dass alle im Team wissen, was von ihnen erwartet wird. Es gilt, die eher Output-orientierte Arbeitsweise in der Entwicklung in passende Outcome-orientierte OKRs zu übersetzen. Die Betonung liegt dabei auf „orientiert“: Engineering Teams sollten zwar versuchen, sich im Sinne des OKR-Frameworks auf Outcomes zu fokussieren, allerdings nicht um jeden Preis. Für manche Teams oder Themen kann es auch sinnvoll sein, Output-orientierte OKRs zu formulieren.

Generell lassen sich gute Engineering OKRs in vier Schritten formulieren, die wir uns gleich genauer ansehen:

1. OKR-Methode verstehen
2. Input sammeln
3. Schwerpunkte wählen
4. OKRs formulieren

1. OKR-Methode verstehen

Im ersten Schritte sollten die Grundlagen des Frameworks klar sein. Wer Engineering OKRs erstellen möchte, sollte vorher verinnerlicht haben,

• was agiles Arbeiten und ein agiles Mindset bedeuten.
• wie das OKR-Framework grundsätzlich aufgebaut ist und wie sich Objectives, Key Results und Initiativen unterscheiden. Hier lohnt sich ein Blick in unseren OKR-Leitfaden.
• was der Unterschied zwischen Output vs. Outcome ist. Ist dieser nicht klar, sorgt das nämlich oft dafür, dass der Erfolg der OKRs falsch gemessen und nicht ergebnisorientiert gearbeitet wird (mehr dazu in unserem Artikel über OKR-Fehler).
• was ein OKR-Zyklus ist und wie er funktioniert. Dazu gehört auch Wissen über die einzelnen Events, die innerhalb eines Zyklus stattfinden – also das OKR Planning, regelmäßige Check-ins, das OKR Review und die OKR Retrospektive.

2. Input sammeln

OKRs für Engineering Teams sollten nie einfach ins Blaue hinein erstellt werden. Sie orientieren sich vielmehr an der Frage: Wie sieht aus Entwicklungssicht ein Erfolg für unser Produkt am Ende des Zyklus aus? Um darauf eine möglichst gute Antwort in Form von inspirierenden und ergebnisorientierten OKRs geben zu können, ist einiger Input notwendig.

Dazu gehören unter anderem:

• Übergeordnete Unternehmens-OKRs und/oder OKRs anderer Abteilungen und Teams
• Vision und Mission des Unternehmens
• Produktvision und -strategie
• Bestehende OKR-Sets (falls vorhanden)
• Produktentwicklungs-Roadmaps
• Einblick in Nutzerfeedback (z. B. bekannte Probleme oder Lösungen)

Dabei müssen nicht immer alle Informationen vorliegen. Die Liste sollte eher als Orientierung dienen, welches Level an Klarheit idealerweise vorhanden sein sollte, damit sich wirklich gute OKRs formulieren lassen. Falls noch einzelne Puzzleteile fehlen, können die Teams trotzdem OKRs für den aktuellen Zyklus erstellen und die Informationen später vervollständigen. Schließlich gehört es auch zur Arbeit mit OKRs, den Prozess an sich kontinuierlich weiterzuentwickeln.

3. Schwerpunkte wählen

Die Grundlagen sind klar und es liegen alle notwendigen Informationen vor? Dann gilt es als nächstes, den richtigen thematischen Fokus zu wählen. Besonders wichtig für (Software) Engineers sind dabei:

• Functionality: Features und Produktverbesserungen entwickeln.
• Performance: Sicherstellen, dass ein Produkt oder Dienst einwandfrei funktioniert und skalierbar ist.
• Usability: Vorhandene Funktionen verbessern und bestehende Produkte oder Dienste intuitiver gestalten, um die Nutzerfreundlichkeit zu erhöhen.
• Reliability: Sicherstellen, dass ein Produkt oder Dienst immer zuverlässig und wie erwartet funktioniert.
• Security: Schutz verstärken und mit neuen Maßnahmen dafür sorgen, dass die Daten der Nutzer:innen jederzeit sicher und geschützt sind.
• Dev Speed: Entwicklungszyklus optimieren und neue Features oder Produkte schneller veröffentlichen.

Es ist dabei im Grunde unmöglich, gleichzeitig an allen Themen zu arbeiten. Deshalb sollten Entwicklungsteams pro Zyklus immer nur zwei bis drei thematische Schwerpunkte für die OKRs wählen. Um herauszufinden, welche Themen für den nächsten Zyklus am wichtigsten sind, kann es helfen, sich unter anderem folgende Fragen zu stellen:

• Welche strategischen Unternehmensziele sollen erreicht werden? Wie können wir dazu beitragen?
• Gibt es technische Probleme oder Sicherheitslücken, die dringend behoben werden müssen?
• Welche Kundenbedürfnisse oder Marktchancen sollten wir berücksichtigen oder können wir (noch besser) erfüllen?
• Gibt es neue Technologien oder Tools, die wir nutzen können?
• Gibt es Probleme oder Bottlenecks im Entwicklungsprozess, die wir beseitigen sollten?

4. OKRs formulieren

Wenn die thematischen Schwerpunkte feststehen, geht es als Nächstes an die Formulierung der OKRs. Das ist in der Regel der schwierigste Teil, an dem viele Teams scheitern. Grundsätzlich gilt für OKRs diese Regel:

Ein Objective sollte immer die Frage beantworten, was man erreichen möchte. Jedes einzelne Key Result beschreibt dann, woran man erkennt, dass das Ziel erreicht wurde. Entsprechend sollten Objectives immer qualitativ, leicht verständlich und inspirierend formuliert sein. Key Results sollten eindeutig messbar, ergebnisorientiert und SMART sein.

Alle Kriterien für gute Objectives und Key Results sowie konkrete Formulierungshinweise haben wir in unserem Artikel „OKRs formulieren: Tipps für richtig gute Objectives und Key Results“ zusammengefasst. Die Regeln und Hinweise aus dem Artikel gelten für alle Arten von OKRs. Für Engineering Teams (und OKR-Anfänger:innen) kann es dabei besser sein, zunächst vor allem sogenannte Committed OKRs zu formulieren – also OKRs, die zu 100 Prozent erreicht werden sollen (mehr dazu in unserem Artikel zum Thema Aspirational vs. Committed OKRs).

Plus: Engineering Teams sollten beim Formulieren ihrer OKRs zwar den Unterschied zwischen Outcome und Output im Kopf haben. Das heißt aber nicht, dass alle Engineering OKRs zwangsläufig als Outcomes formuliert sein müssen. OKRs funktionieren auch mit Output-orientierten Key Results. Sie haben dann aber einen anderen Fokus. Je nachdem, was man mit den OKRs erreichen möchte, kann es manchmal sinnvoll sein, anfangs auf Output-orientierte Key Results zu setzen und erst später oder nur bei bestimmten Themen Outcomes aufzunehmen.

25 Beispiele für Engineering OKRs

Als Einstieg haben wir hier einige Beispiele für Engineering OKRs zusammengestellt.

⚙️ Functionality

📈 Performance

⛵️ Usability

🤝 Reliability

🔒 (Data) Security

💻 Dev Speed

Fazit: Mit OKRs die technische Arbeit verbessern

Insgesamt helfen Engineering OKRs, klare Ziele für Entwicklungsteams zu setzen, die mit der Unternehmensstrategie in Einklang stehen. So können sich die Teams auf das Wesentliche konzentrieren und Veränderungen in der Umwelt berücksichtigen, während sie die Qualität ihrer technischen Arbeit verbessern. Engineering OKRs beantworten immer die Frage: Wie sieht aus Entwicklungssicht ein Erfolg für unser Produkt am Ende des Zyklus aus? Dabei können sowohl Outcome- als auch Output-orientierte OKRs sinnvoll sein, abhängig von den Bedürfnissen und Zielen der Teams.

So unterstützt Mooncamp

Eine OKR Software wie Mooncamp erleichtert es Entwicklungsteams, OKRs zu erstellen und bei der Produktentwicklung den Überblick zu behalten:

• Sie sorgt für Transparenz und Ausrichtung innerhalb des Teams oder im Unternehmen.
• Sie ermöglicht eine bessere Zusammenarbeit und dient als zentraler Knotenpunkt für die Kommunikation.
• In einer OKR Software lassen sich OKRs viel leichter verwalten als in Excel-Tabellen oder zweckentfremdeten Tools.
• Sie stellt durch integrierte Check-ins und regelmäßige Erinnerungen sicher, dass alle ihre OKRs im Blick behalten.
• Sie ermöglicht jederzeit Einblicke in die Fortschritte und macht es leicht, Daten zu filtern und zu analysieren.