2026-09 · 4 Min. Lesezeit
Die Arbeit, die verschwindet, wenn sie funktioniert
DesignOps ist erfolgreich, wenn Reibung verschwindet. Wird die Arbeit dahinter jedoch unbeobachtbar, verliert die Organisation die Evidenz, die sie braucht, um diesen Zustand zu erhalten.
Es gibt eine besondere Form von Erfolg, die kaum Belege für sich selbst produziert.
Infrastruktur hat diese Eigenschaft. Straßen treten in den Hintergrund, wenn der Verkehr fließt. Über Wasserversorgung spricht man selten, solange Wasser kommt. Je besser die Infrastruktur funktioniert, desto weniger Aufmerksamkeit verlangt sie von den Menschen, die sie nutzen.
DesignOps funktioniert häufig genauso.
Wenn das Betriebssystem der Organisation trägt, liegen Dateien dort, wo man sie erwartet. Abhängigkeiten werden sichtbar, bevor sie zu Blockern werden. Reviews finden im richtigen Moment statt. Teams können die Arbeit der anderen finden. Das Design System bleibt kohärent. Niemand verbringt den Vormittag mit der Frage, wem ein Problem eigentlich gehört.
Die Reibung verschwindet.
Das ist Erfolg.
Mich interessiert dabei zunehmend eine Unterscheidung: Die Reibung darf unsichtbar werden. Das System, das diesen Zustand erzeugt, darf nicht unverständlich werden.
Gute Operations sollten in der Nutzung leise sein – nicht unbeobachtbar.
Präventive Arbeit erzeugt ein eigenartiges Evidenzproblem.
Ein Designer kann auf ein Interface zeigen. Research kann auf Erkenntnisse zeigen. Operative Arbeit produziert häufig ein Gegenfaktum: die Verzögerung, die nicht eingetreten ist, die Doppelarbeit, die vermieden wurde, die Abhängigkeit, die gelöst wurde, bevor sie dringend wurde, die Inkonsistenz, die nie im Produkt ankam.
Diese Ergebnisse sind real. Sie sind nur schwer nachzuweisen, weil der stärkste Beleg oft eine Abwesenheit ist.
Daraus entsteht ein Legitimationsproblem. Organisationen erkennen Wert besonders leicht, wenn er Artefakte hinterlässt. Features. Reports. Prototypen. Frameworks. Operativer Wert ist häufiger ein Zustand: Arbeit bewegt sich mit weniger Reibung, weniger Überraschungen und weniger vermeidbarer Koordination.
Wird dieser Zustand lange genug selbstverständlich, beginnt die Infrastruktur optional auszusehen.
Meist bis zu dem Moment, in dem sie ausfällt.
Die naheliegende Reaktion besteht darin, operative Arbeit sichtbarer zu machen.
Mehr Statusdecks. Mehr Prozessdiagramme. Mehr Meetings, die erklären, warum es Meetings gibt. Mehr Dokumentation als Beweis dafür, dass Koordination stattgefunden hat.
Ich glaube nicht, dass Sichtbarkeit das richtige Ziel ist.
Nützlicher ist der Begriff Beobachtbarkeit.
In der Systemtechnik hinterlässt ein beobachtbares System genügend Signale, um seinen Zustand zu verstehen, ohne jede interne Aktion verfolgen zu müssen. DesignOps braucht etwas Ähnliches. Nicht den Nachweis, dass jemand beschäftigt war. Sondern Signale dafür, ob die Arbeitsumgebung gesünder oder fragiler wird.
Wie viele Abhängigkeiten bleiben ungelöst? Wo wird Arbeit doppelt gemacht? Wie lange bleiben Teams blockiert, weil eine Entscheidung fehlt? Welche Muster fragmentieren immer wieder zwischen Squads? Wo taucht dasselbe Koordinationsproblem erneut auf?
Keine dieser Kennzahlen misst DesignOps perfekt. Darum geht es nicht.
Gemeinsam machen sie den Zustand des Systems lesbar.
DesignOps sollte nicht seine Aktivität sichtbar machen. Es sollte den Zustand, den es erzeugt, beobachtbar machen.
Damit verändert sich auch mein Blick auf operative Artefakte.
Eine Portfolioübersicht ist nicht wertvoll, weil sie beweist, dass jemand ein Board gepflegt hat. Sie ist wertvoll, wenn sie Arbeit sichtbar macht, die sonst kollidieren würde.
Ein wiederkehrendes Concept-Sharing ist nicht wertvoll, weil noch ein Meeting existiert. Es ist wertvoll, wenn Abhängigkeiten früher sichtbar werden als zuvor.
Ein Quality Review ist nicht wertvoll, weil eine Checkliste ausgefüllt wurde. Es ist wertvoll, wenn dieselbe Problemklasse später nicht wieder auftaucht.
Das Artefakt ist nur Evidenz. Der Zustand ist das Ergebnis.
Diese Unterscheidung verhindert, dass DesignOps performativ wird. Das Ziel ist nicht, mehr Spuren der Arbeit zu hinterlassen. Das Ziel ist, die richtigen Spuren zu hinterlassen – genug, um zu verstehen, ob das Betriebssystem tatsächlich das tut, wofür es entworfen wurde.
Darin steckt ein breiteres Designprinzip.
Die besten Systeme reduzieren oft die Aufmerksamkeit, die sie verlangen. Doch weniger Aufmerksamkeit bedeutet nicht weniger Lesbarkeit. Ein System kann ruhig sein, ohne opak zu werden. Es kann aus der unmittelbaren Aufgabe verschwinden und zugleich für die Menschen überprüfbar bleiben, die es verantworten.
Vielleicht ist genau das auch der richtige Anspruch an DesignOps.
Lasst den Prozess in den Hintergrund treten. Lasst Koordination leichter werden. Lasst Menschen vergessen, wie viel Reibung früher existierte.
Aber bewahrt genug Evidenz, damit die Organisation weiterhin versteht, was die Arbeit zusammenhält – und bemerkt, wenn sich dieser Zustand verändert.
Die Arbeit darf verschwinden. Die Evidenz nicht.
Diese Reflexion greift Susan Leigh Stars und Karen Ruhleders Arbeit über Infrastruktur auf, die bei funktionierender Nutzung in den Hintergrund tritt, sowie die Idee aus dem Site Reliability Engineering, dass zuverlässige Systeme dennoch beobachtbar bleiben müssen.