Ik heb de laatste tijd veel geïnterviewd (en nee, ik wil er niet over praten). Er wordt mij bijna altijd gevraagd: “Hoe definieer je ontwikkelaarsrelaties?” en dit bericht is het lange antwoord op die vraag.

Ik schrijf het omdat bijna elke interviewer aan wie ik dit heb verteld op de een of andere manier heeft gezegd: “Dat is een hele goede analogie! Je zou dat als een blogpost moeten opschrijven.” Dus hier zijn we.

Ten eerste is DevRel geen een partij

DevRel is een heleboel dingen, maar een feestje hoort daar niet bij. Sterker nog, het is een van de moeilijkste banen in de technologiesector. Het is alsof je vier of vijf banen tegelijk hebt.

  1. Je bent een ontwikkelaar
  2. Je bent een marketeer
  3. Je bent een verkoper
  4. Je bent productmanager
  5. Je bent een leraar

En als klap op de vuurpijl moet je marketing, engineering, verkoop en productmanagement kunnen beïnvloeden, allemaal zonder enige autoriteit. U kunt niemand rechtstreeks vertellen wat ze moeten doen, omdat geen van hen aan u rapporteert, of vaak zelfs aan uw organisaties rapporteert. Maar je moet ze ervan kunnen weerhouden domme dingen te doen waar ontwikkelaars een hekel aan zullen hebben, en ze overhalen om dingen te doen die ontwikkelaars willen.

Marketing wil wat swag produceren voor een conferentie die… onverstandig is, en je moet ze ervan overtuigen dat niet te doen. Ik heb voorbeelden. Het is beter als je een zodanige relatie met hen hebt opgebouwd dat ze komen en vragen wat voor soort swag goed zou zijn. Of Marketing wil de blogpost of de CFP-inzending (Call for Papers) van de CTO herschrijven, en zij veranderen het allemaal in bloemrijke marketingtaal en je moet het allemaal ongedaan maken zodat de toespraak daadwerkelijk geaccepteerd wordt.

Engineering probeert prioriteit te geven aan bugfixes en functies, en jij moet die keuzes namens de ontwikkelaarsgemeenschap beïnvloeden. Engineering en Product Management willen vooruitgang boeken met hun favoriete functies, maar je weet dat ontwikkelaars schreeuwen om een andere reeks functies. Die keuzes moet je beïnvloeden.

Ik kan nog wel even doorgaan, maar je begrijpt het idee wel. En over het algemeen moet je dat allemaal doen terwijl je technische inhoud schrijft (blogposts, tutorials, enz.), spreekt op conferenties en meetups en andere evenementen organiseert. Vaak gebeurt dat allemaal vanuit een vliegtuigstoel of een luchthavenlounge. Het is geen feest. Het is vermoeiend.

DevRel is een partij

Maar het is een feest

En nu ga ik je vertellen waarom het een feest is. Soort van.

Laten we eerst eens kijken naar wat ik beschouw als de drie pijlers van DevRel: Developer Advocacy, Developer Experience en Community Management. Laten we eens kijken hoe elk van deze onderdelen functioneert in deze partijanalogie.

Belangenbehartiging van ontwikkelaars

De Developer Advocate (DA) is de eerstelijnspersoon die dagelijks met ontwikkelaars communiceert. Ze praten met ontwikkelaars, geven presentaties op conferenties, schrijven technische inhoud en proberen in het algemeen ontwikkelaars naar uw platform te trekken. Ze zijn overal ter wereld bezig om ontwikkelaars naar jouw feest te krijgen. Ze moeten persoonlijk zijn, prettig in de omgang met mensen en technisch genoeg zijn om geloofwaardig met ontwikkelaars over uw platform te kunnen praten.

Uw Developer Advocates moeten uw platform en uw community kunnen promoten als een geweldige plek die waarde heeft voor ontwikkelaars, een inclusieve en gastvrije plek is, en die over de middelen beschikt om hen te helpen. Ze moeten dat kunnen doen op een manier die authentiek en oprecht is, en dat is niet alleen marketingpraat.

De feestgastheer

Ontwikkelaarservaring

Het Developer Experience (DevEx)-team is ervoor verantwoordelijk dat er dingen te doen zijn als ontwikkelaars naar uw feest komen. Zij zijn verantwoordelijk voor de onboarding-ervaring, de documentatie, de SDK’s, de API’s, de CLI en alle andere tools die ontwikkelaars zullen gebruiken om met uw platform te communiceren. Zij zijn ervoor verantwoordelijk dat het feest leuk is en dat er dingen te doen zijn.

DevEx maakt, test en onderhoudt de demo’s, tutorials en andere inhoud die ontwikkelaars zullen gebruiken om meer te weten te komen over uw platform. Als DevEx faalt, zullen alle mensen die Developer Advocacy overtuigt om naar het onderdeel te komen, zich omdraaien en vertrekken. En ze zullen niet snel terugkomen. Het oude gezegde “je krijgt nooit een tweede kans om een eerste indruk te maken” is nooit meer waar dan in DevRel.

Als het nog maar half gebouwd is, zullen ze vertrekken.

Als het niet gebouwd is, zullen ze vertrekken

Gemeenschap beheer

Als laatste, maar zeker niet minder belangrijk, is er Community Management. Dit is de groep die ervoor verantwoordelijk is dat het feest leuk, gastvrij en veilig is en dat mensen zich gewaardeerd en betrokken voelen. Bestaat er een gedragscode? Wordt het afgedwongen? Zijn het duidelijke handhavingsrichtlijnen? Een goede Community Manager zorgt ervoor dat deze zaken allemaal aanwezig zijn en dat ze werken.

De Community Manager is ook (in het algemeen) verantwoordelijk voor een “kampioenen” -programma. Dit zijn de mensen die het leven van het feest vormen. Zij zijn degenen die er altijd zijn, altijd helpen en er altijd voor zorgen dat iedereen het naar zijn zin heeft. Ze beantwoorden vragen, ondersteunen andere leden van de gemeenschap en kunnen over het algemeen worden beschouwd als de ‘pijlers van de gemeenschap’.

Maar een goede Community Manager weet ook wie de lurkers zijn, en kan hen ertoe aanzetten actieve leden te worden. Ze weten ook wie de potentiële onruststokers zijn en houden nauwlettend in de gaten of de gemeenschapsnormen worden nageleefd.

Een feest kan snel kapot gaan, en als dat eenmaal gebeurt, kan het bijna onmogelijk zijn om de zaken weer op de rails te krijgen of de reputatieschade te verzachten.

Er zijn zoveel, veel voorbeelden.

Community manager

Het is een teamsport

DevRel is een teamsport. Er zijn veel mensen nodig, met veel verschillende en uiteenlopende vaardigheden, om er een succes van te maken. Het is geen feest, maar het is een feest. Het is hard werken, maar ook erg leuk. Het is een hoop stress, maar ook een hoop vreugde.

En het is niet iets dat je van de ene op de andere dag bij elkaar kunt krijgen. Het kost tijd en gezamenlijke inspanning om het huis te bouwen, alle onderdelen op hun plaats te krijgen, de juiste mensen aan te trekken en ze vervolgens in een gemeenschap op te voeden. Het is veel werk, maar het is de moeite waard.

DevRel is ook een kostenplaats. Het zal niet direct inkomsten genereren. Maar het is ook een krachtvermenigvuldiger. Het kan uw product beter maken, uw gemeenschap sterker en uw bedrijf succesvoller. Het is een langetermijninvestering en het is de moeite waard. Je zult geen succes zien in 3 maanden. Of 6 maanden. Of waarschijnlijk zelfs een jaar. Ja, u kunt vooruitgang verwachten, maar het zal tijd kosten om het soort gemeenschap op te bouwen dat uw bedrijf succesvol zal maken.

Dat gezegd hebbende, kan DevRel absoluut bijdragen aan het genereren van aanzienlijke inkomsten. Hier zijn mijn suggesties voor hoe:

  • Zorg ervoor dat je weet wie de accountmanagers/verkopers zijn. Bied aan om ze te helpen als ze dat nodig hebben. Zorg ervoor dat ze weten wie je bent en wat je te bieden hebt
  • Weet wat de algemene bedrijfsdoelen en doelstellingen zijn voor het jaar en het kwartaal. Richt uw inspanningen op zaken die het bedrijf helpen deze doelen te bereiken
  • Houd bij welke dingen u doet om de bedrijfsdoelen en doelstellingen te beïnvloeden, en hoe u heeft geholpen inkomsten te genereren
  • Blijf op de hoogte van de mensen in uw gemeenschap die vooruitgang hebben geboekt met uw software, en zoek vooral naar aanwijzingen dat zij bereid zijn om met de verkoopafdeling te praten.
  • Als ze klaar zijn, voer dan de introductie uit. En maak het persoonlijk, zodat zowel de potentiële klant als de verkoopmanager weten dat u de tijd heeft genomen om hun behoeften te begrijpen en deze aan de juiste mensen heeft doorgegeven.

Conclusie

Zoals ik al zei, is DevRel als een partij in de manier waarop het moet worden gepland, beheerd en uitgevoerd. Geen enkel echt episch feest gebeurt ooit ‘gewoon’. Er is werk voor nodig, en er is een heel team voor nodig om het er moeiteloos uit te laten zien. DevRel is ook geen partij omdat het een onheilige hoeveelheid werk is. Er is een enorme verantwoordelijkheid, en het is niet iets dat je zomaar kunt “vluchten”. Die blogideeën en tutorialideeën komen niet zomaar uit de lucht vallen. Ze kosten tijd, onderzoek en moeite.

Dus laten we allemaal een feestje geven voor de DevRel-mensen in uw bedrijf. Vier hun prestaties en zorg ervoor dat, als Devrel uw werk heeft beïnvloed, u ervoor zorgt dat iedereen het weet.