Voglio diventare... DevRel
Il “Buongiorno da Edo” è perfetto per chi vuole cominciare la giornata informandosi sulle ultime novità nel mondo #tech: conosciamo più da vicino Edoardo Dusi, DevRel @ SparkFabrik e Content Creator.
Descriviti in 100 parole
Una volta il mio nutrizionista osservò che muovevo continuamente e ritmicamente la gamba su e giù mentre ero seduto di fronte a lui, e annotò sul mio programma “bere meno caffè”.
Eppure il colpevole di quell’agitazione non era la caffeina, ma il mio bisogno di continuo movimento, fisico o intellettuale, che in quella situazione aveva trovato modo di sfogarsi sul mio polpaccio.
Mi sembra questa una descrizione di me stesso molto appropriata: una persona che ha un bisogno incessante di fare qualcosa, qualunque cosa, meglio se qualcosa che mi stimoli intellettualmente ma va bene anche tenere il tempo di un tormentone pop che mi si è infilato in testa. Sono probabilmente i Maneskin. Manco mi piacciono i Maneskin.
Ah, sono un DevRel in SparkFabrik e conduco due podcast, un bi-settimanale Continuous Delivery e un quasi-giornaliero Buongiorno da Edo.
In cosa consiste il ruolo di DevRel?
DevRel è la contrazione di Developer Relations, una sorta di termine ombrello che abbraccia le varie strategie che un’azienda adotta per interfacciarsi con i developer, questo gruppo molto complesso ma anche piuttosto eterogeneo di individui che stanno sia dentro che fuori l’azienda stessa, e ha interesse a farlo per vari motivi. Ne sto scrivendo una serie di post sul nostro tech blog, ma qui cercherò di riassumere.
Se sei una tech company oggi ti trovi in una di queste due situazioni: o il tuo business è vendere qualcosa ai dev, ad esempio sei Unity e vendi un game engine agli sviluppatori di videogiochi, oppure è vendere a un pubblico generico (o ad altre aziende) che include i dev nella sua sfera di interesse, ad esempio sei Spotify e vendi musica online.
In entrambi gli scenari hai bisogno degli sviluppatori e dovrai trovare delle strategie per farti conoscere e apprezzare in questo target specifico, e se nel primo caso il motivo è evidente, nel secondo caso è molto più evanescente ma diventa più facile afferrarlo se consideri quali opportunità può creare per il tuo business avere il supporto da una community di dev - pensa appunto a Spotify con Backstage.
E tutto questo senza menzionare gli apporti fondamentali in ambito di hiring e di retention. Quali sono nel concreto le attività da fare? Come sanno tutti quelli che cercano di essere visibili nella nostra community, è necessario creare qualcosa che gli altri trovino utile, di valore. Può essere un tech talk, un blog post, un video, un podcast, una libreria open source. Questi sono i percorsi diciamo “classici”, e poi bisogna seguire un po’ la creatività.
Il lavoro si svolge in un team, e il più delle volte lo troverai nei team marketing o comunque associato a questo budget nelle aziende. Una scelta che abbiamo fatto anche noi in Spark, perché queste attività per essere efficaci devono essere inserite in una strategia di medio/lungo periodo e non possono limitarsi a isolate azioni individuali, anche avessero successo.
Per finire, non esiste una definizione univoca per tutti gli scenari: questo ruolo si declina in forme diverse a seconda delle esigenze dell’azienda, o meglio dell’organizzazione di cui si fa parte.
Qual è la soft skill più importante che deve possedere una DevRel?
L’incoscienza. Un DevRel deve pensare che sia opportuno salire sul palco di una tech conf di espertissimi, parlare dopo un maintainer di React, un core contributor di Kubernetes e un membro del Technical Steering Committee di Node.js, prendere il microfono e dire “e adesso vi dirò qualcosa di altrettanto interessante”. Scherzi a parte, empatia, un pizzico di carisma, creatività q.b.
La maggior parte di noi utilizza i social per parlare dei propri successi, ma la realtà è che siamo quel che siamo grazie al 90% dei nostri errori. Racconta il tuo più grande fallimento da quando lavori nel settore, che però ti ha reso ciò che sei.
Errori e fallimenti non sono la stessa cosa, eh.
Un’impresa può fallire anche senza aver commesso alcun errore, perché l’obiettivo era irraggiungibile o perché è intervenuto un fattore esterno imprevedibile e incontrollabile.
Al contrario, può avere successo nonostante evidenti errori. Nel 1985 Coca-Cola stava perdendo mercato a favore di Pepsi e decise di cambiare ricetta creando la “New Coke”.
Fu un flop tremendo, e appena tre mesi dopo tornarono alla formula originale lanciando “Coca-Cola Classic”, che invece fu un successo enorme e fece aumentare tremendamente le vendite del brand.
Il fallimento in un sistema complesso non dipende praticamente mai da un singolo errore, e sono molte di più le cose fuori dal nostro controllo che quelle che invece dipendono dalle nostre azioni dirette.
Dobbiamo quindi rassegnarci all’inazione? Assolutamente no.
Dobbiamo invece essere ancora più incisivi sulle cose che possiamo controllare, perché a quel punto la misura del successo sarà data dalla nostra azione e il fallimento non sarà imputabile a un nostro errore.
Il mio più grande fallimento è stato quando ho lasciato che fattori esterni decidessero un risultato senza che io agissi in modo deciso per tentare di cambiarlo. Quando ti trovi in queste situazioni perdi tutto, non ti rimane neanche quello che avresti potuto ottenere cercando di agire.
Come fare per diventare una DevRel?
Intanto bisogna avere un background da software engineer, o cloud engineer, insomma venire da un’esperienza tecnica nell’ambito di cui si voglia fare DevRel. Ecco perché il mio job title completo è Developer Relations Engineer, non è perché suona bene (anche se devo ammettere che suona bene).
A quel punto i primi passi possono essere in direzioni diverse perché come dicevamo ci sono molte declinazioni diverse del ruolo.
Potrebbe piacerti scrivere la documentazione tecnica e allora intraprendere la carriera di Technical Writer in, che ne so, in Red Hat. Oppure adori stare sul palco e allora potresti diventare un Advocate per Docker. Pensa a quanti contenuti di tipo diverso ti trovi a dover consumare come dev nel corso di una sola giornata: dietro ognuno di quei contenuti c’è un’attività riconducibile allo spettro delle Developer Relations!
Quindi se questa è la carriera che decidi di intraprendere, cara lettrice o caro lettore di TheRedCode, inizia provando a creare qualcosa adesso, nel contesto in cui ti trovi in questa fase della tua carriera.
Potrebbe essere aiutare un nuovo membro del team nel processo di onboarding, oppure provare un talk a un meetup locale, scrivere un blog post, commentare la issue GitHub di quel progetto di cui tante volte hai detto con i colleghi “se solo migliorassero questo aspetto…”.
Ti potrai poi formare in vari modi se desideri, la letteratura consigliata è più o meno sempre la stessa, ma il mio consiglio è di iniziare trovando il tuo modo di condividere le tue conoscenze, diverso da quello degli altri, che ti renda riconoscibile in mezzo alle centinaia di voci.
Parlando di successi, qual è il tuo prossimo obiettivo? Quale ruolo vorresti ricoprire entro i prossimi 3 anni?
Entro i prossimi 3 anni vorrei lanciare il Panedone, una linea di panettoni brandizzata. Ovviamente tutti i proventi servirebbero a finanziare uno scopo più alto, cioè le mie vacanze in Giappone.
Ma tornando al mio lavoro, il prossimo obiettivo è quello di rivolgermi di più al mercato internazionale, per ora sono stato piuttosto riferito al mercato nazionale e per questo la maggior parte dei miei contenuti sono in italiano, per il futuro l’idea potrebbe essere di allargare gli orizzonti e puntare sull’inglese. Anche se, insomma, avere contenuti di qualità nella nostra lingua non è male.
Conosci il tema gender gap in ambito STEM? Se sì, come fare per superarlo?
La mia opinione è che la situazione attuale sia il risultato di una serie di messaggi sbagliati, a partire dagli anni 70, che ha portato allo squilibrio attuale.
Credo che la nostra industry sia tra quelle che hanno adottato i comportamenti più virtuosi in questo senso, e posso dire con orgoglio di far parte di un’azienda e di community dove l’attenzione all’inclusività è sempre altissima.
Questo però non basta a riequilibrare il gap, che è dovuto appunto a fattori sociali e culturali e arriva da lontano, dalle famiglie, dalle scuole.
E allora sono favorevole alle azioni dirompenti, forzare la parità nelle selezioni degli speaker alle tech conf, nei commitee delle organizzazioni, ovunque ci sia esposizione: questi sono i role model che possono, nel lungo periodo, influenzare il percorso dei giovanissimi e delle loro famiglie.
In molti casi questo porta a una situazione artificiosamente svantaggiosa per gli speaker “maschi” (semplifico) perché riduce i posti a disposizione a fronte di candidature non bilanciate, ma il vantaggio è stato tanto e tale finora che lo ritengo un giusto prezzo da pagare per rimettere le cose in carreggiata.
In ultimo, non c’entra nulla ma è un appello personale rivolto a giornalisti, blogger, titolisti: smettetela, vi prego, di scrivere “al femminile” ogni volta che vi riferite all’iniziativa di un gruppo di persone volutamente o incidentalmente composto da sole donne. Mi viene un dolore al fianco. C’è anche il peggiorativo “tutto al femminile”, che mi provoca proprio disidratazione.
