- Developer Relations oder Developer Advocacy
→ eine Rolle, die vor allem in Unternehmen existiert, deren Zielmarkt aus Entwicklerinnen und Entwicklern besteht
→ umfasst Aktivitäten wie den Aufbau von Communities, die Erstellung von Inhalten oder die Verbesserung der Developer Experience eines Produkts, um Entwicklerinnen und Entwickler auf ein bestimmtes Produkt oder eine bestimmte Technologie aufmerksam zu machen
3 Typen von DevRel
- Community Builder: auf die Community fokussiertes DevRel
- zuständig für den Aufbau von Entwickler-Communities
- Entwicklerinnen und Entwicklern Mehrwert bieten, indem man Events organisiert, Livestreams macht, Slack/Discord betreibt und Feedback austauscht
- Developer Educator: auf Inhalte fokussiertes DevRel
- das Produkt durch Artikel oder Vorträge bekannt machen
- Blog, Videos, Workshops, Podcasts, Tweets usw.
- kurzfristig Kampagnen betreiben oder langfristig auch SEO berücksichtigen
- DX Engineer: auf das Produkt fokussiertes DevRel
- verantwortlich für die Developer Experience des Produkts (also dafür, zu verbessern, wie Entwicklerinnen und Entwickler das Produkt wahrnehmen)
- direkt mit Entwicklerinnen und Entwicklern sprechen und anhand ihres Feedbacks Dokumentation und Guides verbessern
- auch an Dingen wie Codebeispielen, Templates und Integrationen arbeiten
Einen Job im DevRel finden
- ein sehr gefragtes Feld
- viele Startups suchen nach gutem DevRel
- wichtige Skills für eine Bewerbung im DevRel
- Coding-Fähigkeiten: Um sich in Entwicklerinnen und Entwickler hineinversetzen zu können, sollte man programmieren können
- Community-Building-Fähigkeiten: Erfahrung darin, Communities aufgebaut und betrieben zu haben, ist hilfreich, etwa an der Universität, im Open Source oder in Online-Communities
- Fähigkeit zur Content-Erstellung: Vorträge halten, YouTube-Videos produzieren, twittern und Blogartikel schreiben
Tipps für DevRel
- How to engage developers
- Show, don’t tell.: Nicht nur darüber reden, sondern es zeigen (damit man das Produkt schnell ausprobieren kann)
- Features not benefits: Funktionen intuitiv zeigen und mit anderen Produkten vergleichen.
- Be genuinely helpful: In hochwertiges Material investieren (API-Dokumentation, gut gepflegte Hilfeseiten, How-to-Videos, Beispiel-Use-Cases usw.). Und es leicht machen, Kontakt aufzunehmen, wenn zusätzliche Hilfe nötig ist
- Be Direct: Kenne die Entwicklerinnen und Entwickler und stelle dir vor, du würdest direkt an jede einzelne Person schreiben. So entsteht wirklich hilfreicher Content statt Marketing-Sprech
- Think beyond the 9-to-5.: Viele Entwicklerinnen und Entwickler arbeiten innerhalb oder außerhalb ihres Jobs an Side Projects zu ganz unterschiedlichen Themen
- Repurpose Content: Dieselben Inhalte so weit wie möglich wiederverwenden. Eine Pipeline aufbauen wie Tweet → Blog → Video → Konferenzvortrag
- Have a "breakable toy": Eine echte App haben, an der man neue Technologien ausprobieren und Kennzahlen zu den Änderungen zeigen kann. Sie sollte klein, aber real sein. Zum Beispiel ein einfacher Fitness-Tracker, ein Ernährungsplaner oder ein Notiz-Tool. Idealerweise gibt es ein paar echte Nutzerinnen und Nutzer, etwa du selbst und einige Freunde
- weitere DevRel-bezogene Materialien
2 Kommentare
Ich denke genauso. Mit der Weiterentwicklung der Softwareentwicklungskultur sollte sich natürlich auch die Art der Aufgaben diversifizieren und stärker ausdifferenzieren. Statt sich künftig einfach nur auf die Erstellung von Produkten zu konzentrieren und alles in Entwicklungs- und Managementrollen aufzuteilen, wäre es schön, wenn verschiedene Rollen entstehen würden, die nötig sind, um Produkte weiterzuentwickeln und bekannt zu machen. Dass zu der bisherigen Einteilung in DevRel/Advocate nun auch DX hinzukommt, finde ich sehr gut. Ob es wohl ein gutes Beispiel ist, dass viele Mitglieder des Chrome-DevRel-Teams zu Spotify in den DX-Bereich gewechselt sind, weiß ich nicht. Mich persönlich interessiert das sehr, aber passende Stellen sind wirklich rar...
Die Protagonisten dieses Artikels gehören größtenteils zum DevRel-Team von Vercel, daher ist es interessant zu sehen, wie DevRel eher in einem jungen Startup(?) definiert wird als in einer lang etablierten DevRel-Organisation.
Im Ausland ist das ein ziemlich heißes Thema, aber hierzulande … hm … seufz
Trotzdem halte ich es für eine unbedingt notwendige Rolle.