In questa serie di articoli esploreremo i diversi aspetti del ruolo di DevRel, il perché e il come lo facciamo in SparkFabrik e come lo vediamo evolvere in futuro.
Le Developer Relations, note anche come DevRel, possono essere definite come l'insieme delle attività che un'azienda intraprende per costruire e mantenere un rapporto con la comunità degli sviluppatori, sia interna che esterna. È un ruolo formalizzato abbastanza di recente, e potrebbe risultare un po' filosofico nella sua job description: come vedrete coinvolge molte unit aziendali, dal marketing allo sviluppo, dalle vendite alle risorse umane.
Nel 2023 abbiamo deciso di avviare un programma DevRel e ora vogliamo condividere ciò che abbiamo imparato. Vogliamo raccontare perché l'abbiamo fatto, il processo che abbiamo seguito per rendere operativi il ruolo e il team, le attività svolte durante l'anno e i risultati ottenuti. Ci auguriamo che questa serie di articoli sia utile sia a chi sta pensando di avviare un programma simile, sia a chi lo sta già facendo e vuole confrontare la propria esperienza con la nostra.
Cominciamo con un po' di storia.
DevRel negli anni
Il ruolo di DevRel esiste da molto tempo, ma solo in tempi recenti è diventato un job title. In passato era spesso associato al ruolo di evangelist, un termine che molti ritengono sia stato coniato da Guy Kawasaki nel 1983, quando lavorava alla Apple. Nel suo libro The Macintosh Way ne ha parlato nel contesto di un'azienda di software:
Un evangelist. Un buon programma di evangelizzazione ha un campione che lo gestisce. Questa persona vive e respira il programma. È la figura di riferimento, la luce guida e il padrino degli sviluppatori. Deve conoscere a fondo il prodotto e la tecnologia dell'azienda.
E ha aggiunto:
Contatto costante. Evangelizzare gli sviluppatori è come instaurare un legame con un bambino. È necessario un contatto costante con loro: parlare al telefono, vedere i loro prodotti e portarli a pranzo. Una buona pratica è l'invio mensile di note tecniche, suggerimenti, trucchi ed esempi. Gli sviluppatori non solo ricevono informazioni, ma percepiscono anche che l'azienda è all'avanguardia e si preoccupa per loro.
Immagine: Guy Kawasaki
Apple vende hardware e software, quindi l'obiettivo dei suoi evangelist era quello di convincere gli sviluppatori a utilizzare i suoi prodotti dimostrando che erano la scelta migliore. Le cose cambiano quando si parla di un'azienda di servizi o di una società di consulenza: torneremo su questo punto più avanti.
I clienti di Apple non erano solo gli sviluppatori, e lo stesso valeva per aziende come Microsoft o Adobe, ma convincerli a promuovere il loro prodotto era un ottimo modo per raggiungere un pubblico più ampio. "Il dentifricio preferito dai dentisti" è un claim che conosciamo tutti, e questa è più o meno la stessa strategia.
In effetti, è stato reso popolare nei primi anni 2010 da aziende come Twilio e New Relic, che sono state tra le prime ad assumere developer advocate e a creare un team di developer relation.
Immagine: Un cartellone pubblicitario di Twilio a San Francisco, inizio anni 2010
Così hanno iniziato a creare contenuti per gli sviluppatori, a parlare alle conferenze, a organizzare meetup e, in generale, a connettersi con gli sviluppatori dove si trovano, usando la loro lingua: la nostra lingua. Questa tendenza si è rapidamente affermata e molte altre aziende hanno seguito l'esempio: oggi praticamente ogni grande azienda tecnologica ha un team di DevRel, così come molte startup e persino alcuni progetti open source.
Ora che il ruolo di DevRel è ben consolidato, la concorrenza è dura e anche per un'azienda che è in grado di investire molte risorse, non è facile emergere dalla massa. Come developer, non solo vogliamo utilizzare i tool di miglior qualità, i framework più trendy, le tecnologie più cool, ma vogliamo anche lavorare con aziende che condividano i nostri valori, che abbiano una cultura, che siano inclusive, che ci facciano sentire parte di una community.
Quando abbiamo iniziato questo percorso in SparkFabrik, avevamo in mente tutto questo: le Developer Relations riguardano la costruzione di una community che includa i nostri dipendenti e tutti gli sviluppatori che entrano in contatto con noi, la condivisione dei nostri principi e della nostra vision, la condivisione delle nostre conoscenze ed esperienze con la community, la contribuzione a progetti open source e la creazione di contenuti utili agli altri.
Quindi, avevamo una comprensione della storia del ruolo nel nostro settore e un'idea piuttosto chiara di ciò che pensavamo dovesse essere, ma poiché siamo un'azienda di servizi e non vendiamo un prodotto, prima ancora di iniziare a pensare a come farlo, dovevamo rispondere a una domanda fondamentale: perché dovremmo farlo?
Perché dovremmo fare DevRel?
La prima domanda che ci siamo posti è stata: perché dovremmo fare DevRel?
Il fatto che sia una tendenza del settore non è una ragione sufficiente per farlo, e ciò che funziona per altre aziende può non funzionare per noi, soprattutto nel mercato italiano dove abbiamo trovato pochi esempi da seguire.
Molti progetti e grandi decisioni in SparkFabrik sono il risultato di un processo collaborativo, e questo non ha fatto eccezione: abbiamo avviato un workshop! Abbiamo coinvolto diversi reparti, dal marketing all'ingegneria, dalle vendite alle risorse umane, perché volevamo identificare l'impatto della figura nelle diverse aree dell'azienda, e fin dall'inizio abbiamo riconosciuto che dovevamo dividerlo in due categorie principali: esterno e interno.
Di solito si può applicare questo concetto anche al marketing tradizionale: si vogliono attrarre nuovi clienti e nuovi talenti, ma si vuole anche fidelizzare i clienti e i dipendenti esistenti. Occorre quindi costruire la consapevolezza del brand, stabilire una thought leadership nel settore, essere un luogo in cui le migliori personalità vogliano lavorare e i clienti vogliano lavorare con loro.
Gli sviluppatori sono coinvolti in tutti questi aspetti, spesso anche nel processo decisionale quando un'azienda cerca un partner per un nuovo progetto. Impegnandosi con la community e dimostrando competenza e valori, i servizi di un'azienda hanno maggiori probabilità di essere scelti quando si cercano soluzioni.
In termini di talent acquisition, abbiamo concordato che i developer tendono a preferire le aziende che si impegnano nella community, contribuiscono a progetti open source e offrono risorse per lo sviluppo delle proprie skill. Partecipando a eventi, sostenendo hackathon e mantenendo una presenza visibile nella community, un'azienda può attrarre potenziali clienti e individui di talento.
Immagine: AngularDay 2023
Tutto questo richiede relazioni. Il successo di un'azienda di servizi è sempre più intrecciato con l'ecosistema degli sviluppatori. Man mano che la tecnologia diventa più complessa e interconnessa, gli sviluppatori giocano un ruolo chiave nel guidare l'innovazione, l'adozione dei servizi e nell'influenzare le decisioni: creando un team di DevRel dedicato, abbiamo riconosciuto l'importanza di avere solide relazioni con la community degli sviluppatori.
DevRel funge da ponte tra la nostra azienda e la community di sviluppatori, facilitando una comunicazione aperta, raccogliendo feedback e creando un ambiente collaborativo.
Investire in DevRel sta diventando una componente fondamentale per rimanere all'avanguardia nel panorama tecnologico competitivo.
Iniziare con una domanda del tipo "Perché abbiamo bisogno di qualcosa?" è un modo efficace per articolare lo scopo e le motivazioni alla base di una particolare iniziativa, richiama l'attenzione dei diversi stakeholder, porta a un processo di analisi critica e pone le basi per una costante valutazione, perché al mutare delle circostanze la risposta può evolvere e la rivisitazione periodica della domanda assicura che l'iniziativa rimanga pertinente e allineata agli obiettivi dell'azienda.
Dopo aver concordato sul "perché" fondamentale dell'implementazione di un programma di Developer Relations, abbiamo iniziato a discutere gli aspetti più pratici del team: definizione di obiettivi e finalità, progettazione di attività e strategie, valutazione dei risultati e dell'impatto.
Questo sarà l'argomento del prossimo articolo di questa serie, quindi se siete interessati a saperne di più, seguiteci.
Scritto daSparkFabrik Team
