Der Architektur-Workshop
Der Architektur-Workshop
Es ist Montagmorgen. Der Besprechungsraum einer kommunalen IT-Dienstleisterin füllt sich. Bereichsleitungen, die Geschäftsführung und das frisch benannte OKR-Kernteam nehmen Platz. An der Wand hängt ein großes Plakat mit dem Titel „OKR-Systemkonfiguration". Darunter: eine Tabelle mit über zwanzig leeren Feldern. Keine Häkchen, keine Kreuze. Noch nicht.
Dieser Workshop ist anders als ein OKR-Training. Hier lernt niemand, was ein Objective ist oder wie Key Results formuliert werden. Das kommt später. Heute geht es um etwas Grundlegenderes: Wie soll OKR in dieser Organisation funktionieren? Welche Stellschrauben drehen wir? Welche lassen wir bewusst in Ruhe?
Ich nenne diesen Workshop den Architektur-Workshop. Andere nennen ihn „Systemdesign" oder „OKR-Konfiguration". Der Name ist zweitrangig. Entscheidend ist die Erkenntnis dahinter: OKR ist kein fertiges Produkt. Es ist ein Rahmenwerk. Und ein Rahmenwerk braucht bewusste Entscheidungen, bevor es wirken kann.
Warum ein eigener Workshop?
Viele Organisationen stürzen sich direkt in die OKR-Formulierung. Sie schreiben Objectives, basteln Key Results – und wundern sich drei Monate später, warum das System nicht trägt. Der Grund ist fast immer derselbe: Sie haben die Architektur übersprungen.
Natalija Hellesoe und Sonja Mewes haben mit ihrem „OKR System Design Guide" als Erste systematisch beschrieben, dass eine OKR-Einführung mit Konfigurationsentscheidungen beginnt. Ihre zentrale Botschaft: Es gibt keinen einzig richtigen Weg, OKR einzusetzen. Aber es gibt viele Variablen, die bewusst gestaltet werden müssen. Die beiden unterscheiden drei Bereiche: die OKR-Systemgrundlagen, die OKR-Set-Definition und den OKR-Zyklus-Prozess.
Cansel Sörgens geht einen ähnlichen Weg. In ihrer Praxis arbeitet sie mit einem Ansatz, der OKR nicht isoliert betrachtet, sondern als Teil eines größeren Steuerungssystems versteht. Jede Organisation braucht ihr eigenes Design.
Die Beratungsfirma die.agilen hat den Architektur-Workshop als eigenständiges Format etabliert. Ihr Ansatz unterscheidet drei zeitliche Horizonte: einen langfristigen strategischen Rahmen, eine mittelfristige Jahresperspektive und den kurzfristigen OKR-Zyklus.
Was all diese Ansätze verbindet: Der Architektur-Workshop steht vor dem ersten OKR-Zyklus. Er schafft die Grundlage. Ohne ihn baut man ein Haus ohne Fundament.
Die drei Konfigurationsbereiche
Ich arbeite in meinen Projekten mit einer Systemkonfigurationstabelle. Sie basiert auf der Arbeit von Hellesoe und Mewes, angepasst für den Verwaltungskontext. Die Tabelle gliedert sich in drei Bereiche.
Bereich 1: OKR-Systemgrundlagen
Hier treffen Sie die grundsätzlichen Entscheidungen.
Wie lang ist ein OKR-Zyklus? In der Verwaltung empfehle ich vier Monate. Das gibt genug Zeit für Wirkung, ohne den Lernrhythmus zu verlieren. Quartalszyklen funktionieren bei Startups. In einer Verwaltung mit Gremienprozessen und politischen Abstimmungen ist das oft zu kurz.
Welche Inhalte deckt OKR ab? Nur strategische Themen? Oder auch operative? Ich empfehle: Beginnen Sie strategisch. Die Versuchung, alles in OKR zu gießen, ist groß. Widerstehen Sie ihr. OKR entfaltet seine Kraft durch Fokus. Wenn alles ein OKR wird, ist nichts mehr ein OKR.
Auf welchen Ebenen arbeiten Sie? Verwaltungsspitze, Fachbereiche, Teams? Nicht jede Organisation braucht alle drei Ebenen. Manche starten bewusst nur auf der Team-Ebene. Andere setzen zuerst auf der Leitungsebene an. Es gibt kein Richtig oder Falsch – nur die Frage: Passt es zu Ihrer Ausgangslage?
Wie viele OKR-Sets pro Einheit? Meine Empfehlung: eines. Maximal zwei. Alles darüber verwässert den Fokus.
Wie ambitioniert sollen die Ziele sein? Die OKR-Welt kennt den Begriff „Moonshot" – Ziele, die bewusst unerreichbar scheinen. Für die Verwaltung rate ich zur Vorsicht. Starten Sie mit einem Ambitionsniveau von 80 bis 90 Prozent. Mutig genug für Bewegung. Realistisch genug für Vertrauen. Moonshots funktionieren in Organisationen, die gelernt haben, mit Scheitern umzugehen. In einer Verwaltung, die OKR gerade erst kennenlernt, erzeugen sie Frustration.
Bereich 2: OKR-Set-Definition
Hier legen Sie fest, wie OKR-Sets entstehen.
Brauchen Sie eine Jahresperspektive? Ich bin überzeugt: Ja. OKR überbrückt die Lücke zwischen langfristiger Strategie und täglichem Handeln. Ein mittelfristiges Zielbild – manche nennen es MOAL, andere „Jahreszielbild" – gibt den einzelnen Zyklen Orientierung.
Wie werden OKR-Sets abgeleitet? Top-down aus der Strategie? Bottom-up aus den Teams? Oder ein Mix? Für die Verwaltung empfehle ich den gemischten Ansatz. Die Verwaltungsspitze gibt strategische Leitplanken vor. Die Teams formulieren ihre OKRs eigenständig innerhalb dieser Leitplanken. Das verbindet Orientierung mit Eigenverantwortung.
Wer nimmt am Definitionsprozess teil? Hier liegt einer der sensibelsten Punkte. In der Verwaltung erlebe ich häufig: Die Führung definiert die Ziele, die Teams setzen um. Das ist kein OKR. Das ist Management by Objectives mit moderner Verpackung. Echtes OKR braucht die Beteiligung der Teams. Die Frage ist nicht ob, sondern wie.
Wie definieren Sie Ihre Objectives? Als Aufgaben, die zu Ergebnissen führen? Oder als Reflexion von Zweck und Werten? Für den Start empfehle ich den aufgabenorientierten Ansatz. Er ist greifbarer. Mit wachsender Reife können Sie den Übergang zur wirkungsorientierten Formulierung wagen.
Bereich 3: OKR-Zyklus-Prozess
Dieser Bereich beschreibt, wie der OKR-Prozess im Alltag abläuft.
Wann findet das Alignment statt – vor oder nach der OKR-Definition der Teams? Wie sieht das Format aus: über ein Tool, in Workshops, durch Meetings?
Wie oft finden Check-ins statt? Wöchentlich? Alle zwei Wochen? Was wird dort besprochen: nur der Status der Key Results? Oder auch die Zuversicht, dass die Ziele erreichbar sind?
Wo findet die Review statt: nur auf Unternehmensebene oder auch in den Teams? Und die Retrospektive: Reflektieren nur die OKR-Verantwortlichen oder das ganze Team?
Jede dieser Entscheidungen formt den Charakter des OKR-Systems. Ein System mit wöchentlichen Check-ins auf allen Ebenen fühlt sich grundlegend anders an als eines mit monatlichen Reviews nur auf Leitungsebene.
Die Tooling-Frage: Unterschätzt und entscheidend
Ich gebe zu: Lange habe ich die Werkzeugfrage für nachrangig gehalten. OKR ist ein Denkmodell, kein Software-Projekt – so dachte ich. Mittlerweile sehe ich das anders.
Ein OKR-Tool muss zwei Dinge leisten. Erstens: Es muss das Alignment sichtbar machen. Die Zusammenhänge zwischen Unternehmens-OKRs, Bereichs-OKRs und Team-OKRs müssen auf einen Blick erkennbar sein. Wer nicht sieht, wie sein Beitrag ins Gesamtbild passt, verliert die Orientierung. Zweitens: Es muss sich in die gewohnte Arbeitsumgebung der Mitarbeitenden einfügen. Wenn OKR in einem separaten System schlummert, das niemand öffnet, stirbt es leise.
Die entscheidende Frage im Architektur-Workshop lautet deshalb nicht „Welches Tool?", sondern „Mit welchem Tool ist die Organisation schon vertraut?"
In der Verwaltung treffe ich auf gewachsene Werkzeuglandschaften: Aufgabenmanagement in Planio oder Jira, Projektsteuerung in Excel, Kommunikation per E-Mail. OKR muss sich in diese Welt einfügen. Nicht umgekehrt. Ich habe gute Erfahrungen damit gemacht, OKR zunächst in bestehenden Tools einzubinden. Ein neues Tool einzuführen und gleichzeitig OKR zu lernen – das überfordert die meisten Teams. Eine gut strukturierte Ansicht im vorhandenen Aufgabenmanagement reicht für die ersten Zyklen.
Hellesoe und Mewes weisen auf einen wichtigen Zusammenhang hin: Wenn eine Organisation so viele OKR-Sets definiert, dass sie ein komplexes Verwaltungswerkzeug braucht, ist das ein Warnsignal. Es deutet auf mangelnden Fokus hin. Das Tool soll die OKR-Arbeit unterstützen. Nicht die fehlende Priorisierung kompensieren.
Wie der Workshop abläuft
Der Architektur-Workshop dauert einen Tag. In manchen Fällen zwei halbe Tage. Die Teilnehmenden sind die Entscheider: Geschäftsführung oder Verwaltungsspitze, Bereichsleitungen und das OKR-Kernteam.
Ich beginne mit dem Warum. Warum führen wir OKR ein? Was erhoffen wir uns? Was soll in zwölf Monaten anders sein? Diese Fragen klingen banal. Sind sie nicht. In vielen Organisationen gibt es auf diese Fragen fünf verschiedene Antworten von fünf Führungskräften. Der Architektur-Workshop macht das sichtbar – und schafft Klarheit.
Dann arbeiten wir uns durch die Konfigurationstabelle. Feld für Feld. Option für Option. Ich stelle die Alternativen vor, erkläre Vor- und Nachteile, bringe Beispiele aus der Praxis. Die Teilnehmenden diskutieren und entscheiden. Am Ende des Tages steht ein ausgefülltes Blatt: die OKR-Konfiguration dieser Organisation.
Das ist keine Theorie. Das ist ein konkretes Arbeitsergebnis. Schwarz auf weiß. Und es gehört der Organisation, nicht dem Berater.
Was der Workshop nicht ist
Der Architektur-Workshop ist kein OKR-Training. Niemand lernt hier, wie gute Key Results entstehen. Er ist auch kein Strategie-Workshop. Die strategische Ausrichtung muss vorher stehen – als Vision, als Leitbild, als strategische Ziele. Ohne Strategie fehlt OKR die Richtung.
Und er ist keine Demokratieveranstaltung. Die Teilnehmenden diskutieren. Aber am Ende entscheidet die Leitung. OKR-Konfiguration ist eine Führungsentscheidung. Wer die Verantwortung für die Organisation trägt, trägt auch die Verantwortung für das Managementsystem.
Die Konfigurationsentscheidungen auf einen Blick
Die folgende Übersicht zeigt die wichtigsten Stellschrauben. Sie erhebt keinen Anspruch auf Vollständigkeit. Jede Organisation setzt eigene Schwerpunkte.
OKR-Systemgrundlagen:
| Stellschraube | Optionen | | Zykluslänge | 2, 3, 4 oder 6 Monate | | Inhaltliche Abdeckung | Strategisch, operativ oder beides | | OKR-Ebenen | Unternehmen, Bereich/Abteilung, Team | | OKR-Baum-Schwerpunkt | Themen, Produkte, Funktionen | | Anzahl OKR-Sets | 1–2 pro Einheit | | Ambitionsniveau | 70 %, 80 %, 90 % oder 100 % | | Rollen | OKR-Experte, OKR-Botschafter, OKR-Pate, OKR-Sponsor || Stellschraube | Optionen | | Zykluslänge | 2, 3, 4 oder 6 Monate | | Inhaltliche Abdeckung | Strategisch, operativ oder beides | | OKR-Ebenen | Unternehmen, Bereich/Abteilung, Team | | OKR-Baum-Schwerpunkt | Themen, Produkte, Funktionen | | Anzahl OKR-Sets | 1–2 pro Einheit | | Ambitionsniveau | 70 %, 80 %, 90 % oder 100 % | | Rollen | OKR-Experte, OKR-Botschafter, OKR-Pate, OKR-Sponsor |
Tooling und Integration:
| Stellschraube | Optionen | | OKR-Tool | Bestehendes Aufgabenmanagement, Spreadsheet, dediziertes OKR-Tool | | Alignment-Sichtbarkeit | OKR-Baum im Tool abbildbar, Zusammenhänge zwischen Ebenen erkennbar || Stellschraube | Optionen | | OKR-Tool | Bestehendes Aufgabenmanagement, Spreadsheet, dediziertes OKR-Tool | | Alignment-Sichtbarkeit | OKR-Baum im Tool abbildbar, Zusammenhänge zwischen Ebenen erkennbar |
OKR-Set-Definition:
| Stellschraube | Optionen | | Jahresperspektive | Keine, strategische Ziele, Unternehmens-OKR, Bereichsziele | | Ableitung der OKR-Sets | Top-down, Bottom-up oder Mix | | Beteiligte | Alle, Delegierte, nur Führungskräfte | | Reifegrad Objectives | Aufgabenorientiert oder wirkungsorientiert | | Reifegrad Key Results | Binär, Meilensteine, absolute oder relative Zahlen || Stellschraube | Optionen | | Jahresperspektive | Keine, strategische Ziele, Unternehmens-OKR, Bereichsziele | | Ableitung der OKR-Sets | Top-down, Bottom-up oder Mix | | Beteiligte | Alle, Delegierte, nur Führungskräfte | | Reifegrad Objectives | Aufgabenorientiert oder wirkungsorientiert | | Reifegrad Key Results | Binär, Meilensteine, absolute oder relative Zahlen |
OKR-Zyklus-Prozess:
| Stellschraube | Optionen | | Alignment-Zeitpunkt | Vor, nach oder gleichzeitig mit OKR-Definition | | Alignment-Format | Tool, Workshop, Meetings | | Check-in-Rhythmus | Wöchentlich, alle zwei Wochen | | Check-in-Inhalt | Status Key Results, Zuversicht, Gesundheitsmetriken | | Review-Ebenen | Unternehmen, Bereich, Team | | Review-Zeitpunkt | Mitte und/oder Ende des Zyklus | | Retrospektive-Ebenen | Unternehmen, Bereich, Team || Stellschraube | Optionen | | Alignment-Zeitpunkt | Vor, nach oder gleichzeitig mit OKR-Definition | | Alignment-Format | Tool, Workshop, Meetings | | Check-in-Rhythmus | Wöchentlich, alle zwei Wochen | | Check-in-Inhalt | Status Key Results, Zuversicht, Gesundheitsmetriken | | Review-Ebenen | Unternehmen, Bereich, Team | | Review-Zeitpunkt | Mitte und/oder Ende des Zyklus | | Retrospektive-Ebenen | Unternehmen, Bereich, Team |
Drei Fehler, die ich immer wieder sehe
Fehler 1: Alles auf einmal konfigurieren. Eine Verwaltung muss nicht sofort alle Stellschrauben bedienen. Beginnen Sie mit den Grundlagen: Zykluslänge, Ebenen, Rollen. Den Rest justieren Sie nach dem ersten Zyklus. Das ist kein Zeichen von Schwäche. Es ist gelebtes Lernen.
Fehler 2: Die Konfiguration delegieren. Wenn die Geschäftsführung den Architektur-Workshop an die mittlere Führungsebene delegiert, sendet sie eine Botschaft: OKR ist nicht mein Thema. Diese Botschaft kommt an. Und sie tötet die Einführung, bevor sie begonnen hat.
Fehler 3: Konfiguration mit Perfektion verwechseln. Die erste Konfiguration ist eine Hypothese. Nicht mehr. Sie wird sich ändern. Nach dem ersten Zyklus justieren Sie Stellschrauben nach. Nach dem zweiten erneut. Das ist gewollt. OKR ist ein lernendes System. Die Konfiguration lernt mit.
Was bleibt
Am Ende des Architektur-Workshops liegt eine ausgefüllte Konfigurationstabelle auf dem Tisch. Die Teilnehmenden haben diskutiert, abgewogen und entschieden. Sie haben nicht nur verstanden, was OKR ist. Sie haben festgelegt, wie OKR in ihrer Organisation funktionieren soll.
Das ist ein großer Schritt. Denn jetzt beginnt die eigentliche Arbeit: die Foundation-Trainings, die ersten OKR-Planungen, die Check-ins, Reviews und Retrospektiven. All das braucht die Grundlage, die im Architektur-Workshop gelegt wurde.
Bevor Sie ein Haus bauen, brauchen Sie einen Bauplan. Der Architektur-Workshop ist dieser Bauplan. Er garantiert nicht, dass das Haus schön wird. Aber er stellt sicher, dass es stehen bleibt.
