Als "Developer Advocate" noch etwas anderes bedeutete

Der Sticker-Verteiler

Wenn ich mich als “Developer Advocate” vorstelle, ernte ich oft einen ganz bestimmten Blick. Es ist eine Mischung aus Vorfreude und Kalkül. Mein Gegenüber – meist ein Konferenzorganisator oder ein Community Manager – fragt sich stillschweigend: Haben Sie Sticker? Haben Sie Budget für Pizza? Können Sie unseren Hackathon sponsern?

Ich muss sie enttäuschen. Ich habe keine Sticker. Ich habe kein Marketing-Budget. Ich habe hingegen große Sorge darüber, dass Ihre Auslieferungs-Pipeline 45 Minuten dauert und willkürlich fehlschlägt, und ich bin hier, um mich für das Team einzusetzen, das darunter leiden muss.

Irgendwo in den letzten fünfzehn Jahren haben wir die Definition dieser Rolle verloren. Sie driftete ab vom “Senior-Entwickler, der das Ökosystem schützt” hin zur “charismatischen Person, die Leads generiert”. Und genau wie beim Begriff “Agile Coach” hat die Kommodifizierung des Titels ein Vakuum hinterlassen, wo früher technische Autorität war.

Der gestohlene Titel

Es gab eine kurze, goldene Ära – hauptsächlich um 2010 von Unternehmen wie Google und Mozilla geprägt –, in der ein Developer Advocate eine furchteinflößend technische Rolle war.

Damals war die Unterscheidung zwischen “Evangelist” und “Advocate” präzise. Ein Evangelist (ein Begriff, der aus Guy Kawasakis Tagen bei Apple stammt) wirkte nach außen (Outbound). Er brachte die “Frohe Botschaft” vom Berg des Herstellers hinab zu den Massen.

Ein Advocate wirkte nach innen (Inbound). Er war “Kunde Null”. Es handelte sich um Senior-Entwickler, die versuchten, echte Anwendungen mit der Plattform zu bauen, dabei herausfanden, wo sie kaputt war, und über das interne politische Kapital verfügten, um in das Büro des Produktmanagers zu marschieren und zu sagen: “Diese API ist Müll. Das können wir so nicht ausliefern.”

Sie setzten sich für den Entwickler gegenüber dem Unternehmen ein.

Dann explodierte die “API Economy”. Twilio, Stripe, SendGrid und tausend risikokapitalfinanzierte SaaS-Tools mussten Nutzer akquirieren. Die Rolle des “Developer Advocate” wurde von der Maschinerie des oberen Verkaufstrichters (Top of the Funnel) absorbiert. Die Berichtslinien verschoben sich vom CTO zum CMO. Die Kennzahl (KPI) änderte sich von “SDK-Qualität” zu “Anmeldungen”.

Der “Advocate” wurde zu einem freundlichen Gesicht, das Begeisterung weckt, statt zu einem Senior-Entwickler, der Reibung erzeugt.

Die Parallele zum Agile Coach

Wir haben diese Erosion technischer Bedeutung schon einmal gesehen. Es ist exakt die Tragödie des “Agile Coach”.

Geht man zurück zu den Ursprüngen von Extreme Programming (XP) in den späten 90er Jahren, war der “Coach” (wie von Kent Beck definiert) ein Meister seines Fachs. Er saß neben Ihnen. Er machte Pair Programming. Er sah, dass Sie einen Test erst nach dem Code schrieben, und korrigierte Sie. Er sah, dass Sie das Refactoring übersprangen, und hielt Sie auf. Er war ein technischer Mentor, der das Handwerk der Software-Auslieferung lehrte.

Dann kam der Zertifizierungs-Industriekomplex. Scrum ersetzte XP. “Scrum Master” ersetzten technische Coaches. Man entschied, dass man nicht wissen muss, wie man programmiert, um “den Prozess zu moderieren”.

Heute ist ein “Agile Coach” oft ein Therapeut für organisatorische Dysfunktion – jemand, der das Jira-Board verwaltet, “Retrospektiven” moderiert, die zu null Ergebnis führen, und über “psychologische Sicherheit” spricht, während das Team in technischer Schuld ertrinkt.

Der Titel blieb. Die Kompetenz wurde ausgehöhlt.

Der Anreiz zur Verwässerung

Warum geschieht dieser Bedeutungswandel? Warum degradieren mächtige, technische Rollen unweigerlich zu bloßen Soft-Skill-Support-Funktionen?

Die treibende Kraft ist der Konflikt zwischen Kompetenz und Skalierung.

Erstens: Exzellenz lässt sich nicht skalieren. Es ist unglaublich schwer, einen Senior Staff Engineer zu finden, der gleichzeitig ein brillanter Kommunikator ist und bereit ist, die Hälfte seiner Zeit mit der Analyse organisatorischer Dysfunktionalität zu verbringen. Viel einfacher ist es, einen Junior-„Growth Hacker“ oder einen nicht-technischen Manager einzustellen und ihm einen Titel zu geben, der nach Autorität klingt.

Zweitens: Kompetenz erzeugt Reibung. Ein echter technischer Fürsprecher, der sagt: „Diese Architektur wird unter Last zusammenbrechen“, ist ein Hindernis für einen Manager, der das Projekt einfach nur auf „Grün“ setzen will. Ein Coach, der sich auf „Team-Befindlichkeiten“ konzentriert, ist für den Status quo weitaus weniger bedrohlich als jemand, der darauf hinweist, dass der Code nicht testbar ist.

Die Industrie entfernt systematisch die „harten“ (technischen) Anforderungen aus diesen Rollen, um sie leichter besetzen und einfacher steuern zu können. Damit entfernt sie genau das, was sie wertvoll gemacht hat: den Biss.

Die Lücke im Vorstandszimmer

Warum ist das wichtig? Weil die Abschaffung des Internen Anwalts eine gefährliche Lücke in unseren Organisationen hinterlassen hat.

Wenn der “Developer Advocate” draußen Vorträge hält und der “Agile Coach” Tickets verwaltet, wer ist dann noch übrig, um den Führungskräften die Wahrheit zu sagen?

Wer hat das Mandat, dem CEO zu sagen: “Ihre Deadline ist Fantasie, weil wir keine automatisierten Tests haben”? Wer sagt dem CTO: “Wir verlieren unsere besten Leute, weil unsere Altlasten-Architektur nicht mehr wartbar ist”? Wer setzt sich für das interne Entwicklungsteam gegen den Druck des Geschäftsbetriebs ein?

Das ist die Lücke, die wir zurückfordern.

Die Rolle integrieren

Wenn wir den Begriff “Developer Advocate” in unserer Beratung verwenden, kehren wir zur ursprünglichen, strengeren Definition zurück.

Es bedeutet einen Senior-Entwickler, der:

1. Eingebettet ist: Er sitzt beim Team, teilt den Schmerz und erlebt die Reibung der täglichen Arbeit am eigenen Leib.
2. Autorität hat: Er berichtet an die Führungsebene, handelt aber im Auftrag der Ingenieure.
3. Software ausliefert: Er redet nicht nur über “Best Practices”, sondern demonstriert sie im Repository.

Sie können es “Embedded Advocacy” oder “Technische Autorität” nennen, wenn Sie möchten. Aber die Funktion ist nicht verhandelbar. Sie können eine Software-Organisation nicht von außen reparieren. Sie müssen mitten im Code sein und die Hitze spüren, um zu wissen, welches Feuer zuerst gelöscht werden muss.

Wir haben keine Sticker. Aber wir können Ihnen helfen, am Freitag auszuliefern.