Ein Platform-Team hat keinen Produktmanager, der es mit einer Roadmap versorgt. Es gibt keine Einnahmenlinie, der man folgen könnte, keinen Markt, den man verlieren könnte. Arbeit existiert nicht, es sei denn, ein Entwickler erfindet sie. Das ist die zentrale Idee von „A Staff Engineer’s Guide to Inventing Work“, einem Artikel, der die These aufstellt, dass Signale für die nächste Bauaufgabe bereits existieren.
Der Artikel argumentiert, dass diese Signale aus vier Richtungen kommen: den Systemen selbst, den Nutzern des Systems, der Organisation und der breiteren Industrie. Der Autor, der sich als Staff Engineer signiert, möchte diese Erfindung erleichtern, indem er die Quellen dieser Signale benennt.
Signale, die das System aussendet
Abstürze sind das unmittelbarste Signal, das der Autor hervorhebt. Postmortems, wenn sie richtig durchgeführt werden, weisen auf das hin, was behoben oder ersetzt werden muss. Manchmal weisen sie auch auf etwas Neues hin, das gebaut werden kann, besonders wenn man beobachtet, wie sich Benutzer während einer längeren Ausfallzeit angepasst haben. Der Autor warnt vor einer Voreingenommenheit gegenüber den lautesten und neuesten Ausfällen und bezeichnet die durch Abstürze getriebene Entdeckung als einen „maximal verzögerten Indikator“.
Kosten sind ein weiteres offensichtliches Signal. Die Cloud-Rechnung ersetzt einen Umsatz-Nordstern. Der Autor geht über die Datenbankoptimierung und den reduzierten Datenverkehr hinaus und fordert die Leser auf, ihre Team-Vendorverträge und Cloud-Rechnungszeilen zu prüfen oder jemanden mit Zugriff auf die Kostenstellen zu fragen. Die Kernlektion: Buy-versus-Build ist keine einmalige Entscheidung. Umfang, Teammitgliedschaft, Technologie und Märkte verschieben sich alle, und es ist erlaubt, diese Entscheidung zu überdenken.
Mühe ist das dritte Signal. Jedes Team hat Arbeit, die sich endlos wiederholt, und sie wird fast nie priorisiert. Der Autor räumt ein, dass dies ein Punkt ist, den viele Leser bereits wissen, aber dennoch erwähnenswert ist. Die Falle: Die Behebung der Mühe des eigenen Teams verbessert die Einheitenökonomie, während die Behebung der Mühe der Benutzer ihre Erfahrung verbessert. Die beiden sind nicht dasselbe Problem.
Signale, die die Benutzer aussenden
Benutzerinterviews sind eine Falle, argumentiert der Autor. Menschen zu fragen, was sie wollen, führt oft zu schnelleren Pferden, nicht zu einer Vision der Zukunft. Aber das ist kein Grund, um aufzuhören, mit Benutzern zu sprechen. Kontinuierliche Entdeckung bedeutet, ein laufendes Gespräch zu führen:
- Sprechen Sie mit N Benutzern pro Woche/Monat/Quartal.
- Führen Sie sie durch ihre letzte Aufgabe im Zusammenhang mit der Plattform.
- Fragen Sie sie nach ihren drei größten Problemen.
- Fragen Sie sie, was die Lösung dieser Probleme für sie bedeuten würde.
- Fragen Sie sie, wer sonst dasselbe Problem hat.
- Hinterfragen Sie ihre Lösungsansätze – fast jedes echte Problem hat bereits einen.
- Stellen Sie ihre vorgeschlagenen Lösungen in Frage und prüfen Sie, ob sie zu Ihrem aktuellen Design passen.
- Dokumentieren Sie die Probleme, geordnet nach ihrer Häufigkeit.
Die Gestaltung des Lösungsraums sei ein separates Forum, betont der Autor. Das Interview bleibe darauf ausgerichtet, das Problem zu verstehen.
Überlastete Anwendungsfälle seien der Lieblingsheuristik des Autors. Einige Plattformen werden für Aufgaben eingesetzt, für die sie nie konzipiert wurden. Der Autor bittet die Leser, zu verstehen, warum Nutzer die Plattform gegenüber Alternativen wählen, selbst wenn die Plattform nicht dafür gedacht war. Diese Anwendungsfälle agieren als Prototypen, die von den Nutzern selbst erstellt wurden. Der Lackmustest: Wer von Ihren Nutzern hat dasselbe Problem?
Partner-to-Prototyp sei die bewusste Version derselben Idee. Anstatt die Überlastung nachträglich festzustellen, arbeiten das Team und die Nutzer zusammen, um einen Prototypen auf der Plattform zu erstellen. Ein Prototyp ist keine Zusage, dass die Funktion offiziell wird. Es ist eine gemeinsame Erkundung. Der Lackmustest bleibt derselbe: Wer von Ihren Nutzern hat dasselbe Problem?
Signale, die die Organisation aussendet
OKRs werden hier der Vollständigkeit halber aufgeführt. Wenn Ihr Team eines festgelegt hat, oder eines vorgegeben bekommen hat, haben Sie dieses Arbeitsfeld bereits erfunden. Der Autor fährt fort.
Die Manager-Wiederholungsheuristik sei einfacher. Wenn Sie Ihren Manager, oder dessen Manager, oder jemanden weiter oben in der Hierarchie zweimal innerhalb einer Woche das Gleiche hören, gibt es wahrscheinlich eine ungelöste Besorgnis dahinter. Der Autor empfiehlt, in 1:1-Gesprächen Notizen zu machen, oder die von der LLM generierten zu lesen. Dies sei nach der Meinung des Autors die schwächste der Heuristiken, da je höher man in der Hierarchie steht, desto weiter entfernt man von der eigentlichen Arbeit ist.
Ein Vergleich der Signale
| Signal (Signal) | Bias (Bias) | Stärke (Stärke) |
|---|---|---|
| Crash-bedingte Entdeckung (Crash-bedingte Entdeckung) | Jüngste/Lauteste Misserfolge (Jüngste/Lauteste Misserfolge) | Eindeutige Nachuntersuchungssignale (Eindeutige Nachuntersuchungssignale) |
| Kosten (Kosten) | Unit Economics (Unit Economics) | Sporadische Muster (Sporadische Muster) |
| Mühsal (Mühsal) | Interne Ausrichtung (Interne Ausrichtung) | Unsichtbar für andere (Unsichtbar für andere) |
| Kontinuierliche Entdeckung) | Fallstrick „schnellere Pferde“) | Laufende Diskussion) |
| Überlastete Anwendungsfälle) | Wert eines Prototyps) | Prüfstein: Wer sonst noch?) |
| Von Partner zum Prototyp) | Gemeinsame Erkundung) | Derselbe Prüfstein) |
| OKRs) | Festgelegt/weitergegeben) | Klare Zielsetzung) |
| Manager-Wiederholung ( | Aufwärtige Distanz ( | Schwache Heuristik ( |
Was das für Plattformteams bedeutet (
Das zentrale Argument des Artikels ist, dass Plattformteams proaktiv darin sein müssen, Arbeit zu finden. Ohne einen Produktmanager, der ihnen eine Roadmap gibt, müssen sie in den Systemen, den Nutzern, der Organisation und der Branche nach Signalen suchen. Der Autor bietet konkrete Methoden dafür an, von Crash-Postmortems bis hin zu Nutzerinterviews und OKRs. (
Die stärksten Signale kommen von den Nutzern, so der Autor. Überlastete Anwendungsfälle und Partner-zu-Prototyping behandeln Nutzerverhalten als einen Prototyp dessen, was die Plattform werden könnte. Der Lackmustest – wer hat das gleiche Problem – verwandelt einzelne Beschwerden in kollektive Beweise. (
Die schwächste Signale ist die Manager-Wiederholungs-Heuristik. Die eigene Bewertung des Autors ist explizit: Je höher man in der Hierarchie steht, desto weiter ist man von der eigentlichen Arbeit entfernt. Deshalb empfiehlt der Autor, in 1:1-Gesprächen Notizen zu machen und von LLM-generierten Notizen zu lesen, selbst wenn die Heuristik selbst schwach ist. (
Warum das jetzt wichtig ist (
Plattformteams sind jetzt überall präsent. Cloud-Rechnungen haben für viele von ihnen Umsatzziele abgelöst, und die Arbeit, Mehrwert für Nutzer zu schaffen, wird nicht von oben vorgegeben. Die Signale, die der Autor beschreibt, sind real, und die Methoden, um sie zu lesen, sind praktikabel und nicht vage. (
Der Autor bietet keine vagen Plattitüden über Innovation. Sie bieten konkrete Schritte – die Erkennung von Mustern bei Postmortems, Nutzerinterviews, Vertragsprüfungen und OKR-Tracking – die jeder in einem Plattformteam ab morgen nutzen kann. (
Die Schwäche der Manager-Wiederholungs-Heuristik ist erwähnenswert. Der Autor tut so, als ob sie stark wäre. Diese Ehrlichkeit verleiht den anderen Signalen Gewicht, die der Autor eindeutig bevorzugt. (
Der Artikel bietet echte, umsetzbare Ratschläge für ein Problem, vor dem Plattformteams täglich stehen: wie man Arbeit findet, wenn niemand einem eine Roadmap gibt. (
„A Staff Engineer’s Guide to Inventing Work“, sujithjay.com.
Das Notizbuch abonnieren.
Die besten Geschichten des Tages und jedes neue Urteil, in klarem Deutsch, um sieben im Postfach. Eine Mail am Tag, nicht mehr.