Plattform & Developer Experience
Developer Experience braucht Produktverantwortung, kein weiteres Tool
Die meisten DX-Programme bleiben aus demselben Grund stecken: Alle finden es wichtig, niemand verantwortet es. Ich führe Developer Experience als Produktdisziplin, gemessen und nach oben verteidigt wie jede kundenseitige Linie. Über zehn Jahre bei Revolut, GitLab, Jimdo und Hermes Germany.
Die Ausgangslage
Wo DX-Programme hängen bleiben
Dein DX-Vorhaben hat ein Budget, einen Slack-Channel und niemanden, der es verantwortet.
Engineers beschweren sich über Tooling. Niemand kann sagen, was die Reibung das Unternehmen kostet.
Das Plattform-Team liefert verlässlich, aber die interne Adoption bleibt flach.
Leadership will eine Zahl zur Entwicklerproduktivität. Du hast keine, der du traust.
Die Arbeit
Vier Dinge, die DX-Produktverantwortung bedeutet
Messung, die ein Board-Meeting übersteht
Ein zusammengesetzter Index aus Entwicklerbefragung und Systemsignalen: Build-Zeiten, Review-Latenz, Deploy-Frequenz. Mit Baseline, Benchmark gegen vergleichbare Organisationen und Quartalsreporting neben den kommerziellen Kennzahlen. Kein Dashboard fürs Schaufenster.
Plattform als Produkt
Interne Plattformen bekommen, was kundenseitige Produkte bekommen: eine Roadmap, benannte Nutzer, Adoption-Ziele und jemanden, der für Ergebnisse einsteht. Eine Ticket-Queue ist keine Produktstrategie.
Reibung beseitigen, nach Kosten sortiert
Lokales Setup, CI-Dauer, instabile Tests, Doku, Review-Durchlaufzeit. Jeder Kandidat wird daran gemessen, was er real an Engineering-Stunden kostet, und danach priorisiert. Die lauteste Beschwerde ist selten die teuerste.
Adoption und interne Überzeugungsarbeit
Eine Plattform, die niemand nutzt, ist ein Kostenblock mit Zwischenschritten. Interne Tools brauchen Onboarding, Migrationspfade und einen Grund zu wechseln. Das ist Go-to-Market und muss so geführt werden.
Die Methode
Die ersten 90 Tage
Tag 1-30
1.Baseline vor Meinung
Engineering-Organisation befragen, Systemdaten ziehen, in Standups und Retros sitzen, die Incident-Historie lesen. Im ersten Monat ändere ich nichts. Reibung, die nicht gemessen ist, lässt sich nicht priorisieren. Und ein DX-Programm, das mit dem Lieblingsfix von irgendwem startet, verliert Glaubwürdigkeit, die es nie zurückbekommt.
Tag 31-60
2.Drei sichtbare Erfolge
Die drei teuersten Punkte aus der Baseline beheben. Klein genug für einen oder zwei Sprints, groß genug, dass Engineers es merken, ohne dass man es ihnen sagt. Diese Erfolge kaufen die Geduld für die strukturelle Arbeit danach.
Tag 61-90
3.Dauerhaft machen
Verantwortungsmodell, Reporting-Rhythmus und eine Roadmap, die meinen Abgang übersteht. Erfolg heißt: DX bleibt nach dem Engagement auf der Leadership-Agenda, und die Zahl hat intern einen Eigentümer.
Meine Philosophie ist seit über zehn Jahren dieselbe: Großartige Plattformen sind unsichtbar. Wenn deine Entwickler über die Plattform nachdenken müssen, ist es noch ein Produktproblem.
Track Record
Belege, keine Theorie
Developer Experience
75. Perzentil
DXI einer mittelgroßen SaaS-Organisation: von ungemessen ins obere Viertel des Vergleichsfelds
Plattform-Uptime
99,999 %
Web-Delivery-Uptime, gehalten über rollierende 90 Tage
Reporting
Quartalsweise
DXI als fester Punkt im Leadership-Reporting, neben Produkt- und Umsatzkennzahlen
Alle Case Studies ansehen (auf Englisch) →
Unternehmen, mit denen ich gearbeitet habe
Engagements
Wie das geliefert wird
Fractional
2-3 Tage pro Woche · Typisch 6-12 Monate
Eingebettete Produktführung auf Senior-Level: Roadmap, Stakeholder, Delivery. Teilzeit-Kadenz, volle Verantwortung.
Interim
Vollzeit · Befristet, 3-9 Monate
Lückenlose Vertretung bei fehlender Produktführung: von der Triage in Woche eins bis zur sauberen Übergabe.
Advisory
Wenige Stunden pro Monat · Fortlaufend
Sparring für Founder und Product Leads: Strategie stresstesten, Blockaden lösen.
DX-Arbeit läuft meist im Fractional-Modus. Wenn du breitere Produktverantwortung brauchst: Fractional CPO oder Interim Head of Product.
FAQ
Fragen & Antworten
Ist Developer Experience nicht ein Engineering-Thema?
Engineering verantwortet die Umsetzung. Die Priorisierung verantwortet meist niemand, und genau daran scheitern die meisten DX-Programme. Zu entscheiden, welche Reibung zuerst wegfällt, die Investition zu begründen und die Organisation an einem Ziel zu halten: das ist Produktarbeit. Engineers stehen dem Tooling in der Regel zu nah, um es nach Geschäftskosten zu sortieren.
Was ist ein DXI und brauchen wir den?
Ein Developer Experience Index ist eine zusammengesetzte Kennzahl: qualitative Befragungsdaten plus quantitative Systemsignale, verdichtet auf eine Zahl mit Verlauf. Du brauchst etwas in der Art, wenn Leadership regelmäßig nach Entwicklerproduktivität fragt und die ehrliche Antwort ein Schulterzucken ist. Du brauchst ihn nicht, wenn es schon eine Kennzahl gibt, der CTO und CFO beide trauen.
Wie rechtfertige ich DX-Ausgaben gegenüber dem CFO?
In Stunden und Risiko, nie in Entwicklerzufriedenheit. Langsame Builds und manuelle Release-Schritte lassen sich in Engineering-Zeit umrechnen. Schlechtes Onboarding in Einarbeitungswochen pro Neueinstellung. Zuverlässigkeitslücken in Incident-Kosten. So formuliert ist es keine Kulturbitte mehr, sondern ein Kapazitätsargument.
Schreibst du Code?
Nicht in euren Produktions-Repos. Ich lese Code, richte mir euer lokales Setup ein und gehe durchs Onboarding wie ein neuer Kollege, weil das der schnellste Weg zu den echten Reibungspunkten ist. Die Fixes baut euer Team. Ich verantworte, was gebaut wird und warum.
Worin unterscheidet sich das von einem Platform Engineering Manager?
Ein Platform EM führt das Team und die technische Roadmap. Ich verantworte die Produktseite: wer die internen Kunden sind, was priorisiert wird, wie Erfolg gemessen wird und wie die Investition nach oben verteidigt wird. Beides ergänzt sich gut. Eines ersetzt das andere nicht.
Wie lange bis zu ersten Ergebnissen?
Sichtbare Erfolge bei der Reibung innerhalb von 60 Tagen. Eine belastbare Baseline-Kennzahl innerhalb von 90. Eine ganze Organisation ins obere Viertel ihres Vergleichsfelds zu bringen hat bei mir knapp ein Jahr gebraucht, weil der schwierige Teil nicht das Tooling ist, sondern die Frage, wie das Unternehmen den Wert von Engineering-Kapazität bewertet.
Setz eine Zahl dahinter
Ein Erstgespräch: 30 Minuten, kein Pitch. Bring deine schlimmste Entwicklerbeschwerde mit, wir rechnen aus, was sie kostet.