📣Developer Relations
Developer Relations es una displina relativamente nueva que combina tecnología, divulgación, comunicación y relaciones interpersonales. Es una carrera muy interesante y que a mí me apasiona. Además está teniendo bastante boom últimamente y encontrar a gente capaz de combinar todas esas cualidades es difícil, por lo que los sueldos suelen estar bastante bien.
Las empresas que suelen tener un equipo de DevRel son empresas de software que, o bien las usuarias de su software son desarrolladoras, expertas en seguridad, sysadmins, etc. o bien tienen una API externa y desarrolladoras externas a su organización integran su producto mediante esa API.
El motivo por el cual esta displina comenzó a crearse fue porque para este tipo de empresas el marketing tradicional no funciona tan bien como en otros verticales. Si yo soy una desarrolladora que quiero saber si el producto Foo es lo que necesito para integrar en mi aplicación, una página web estática explicándome los beneficios me ayudará menos que un repositorio en GitHub con una aplicación de ejemplo, o un blog post escrito por otra desarrolladora donde me explique como puedo integrarlo.
Este vídeo en YouTube de Jono Bacon explica muy bien qué es DevRel y por qué es tan importante para algunas empresas de software.
La primero es aclarar un poco los términos. Al ser una disciplina tan nueva, aún no existe consenso a cómo se deben llamar estas organizaciones dentro de las empresas, o qué título tienen que tener las personas que lo ejercen.
En general, a la disciplina que engloba todas estas actividades se llama Developer Relations, o DevRel como diminutivo.
Los posibles títulos que puedes encontrar cuando busques trabajo en DevRel pueden ser:
Developer Relations Engineer
DevRel Engineer
Technical Evangelist
Developer Evangelist
Developer Advocate
...
¿Hay alguna diferencia entre estos títulos? Yo diría que no, que la gran diferencia es la estrategia que siga la empresa respecto a DevRel, y no tanto el título. Algunos dirían que "Evangelist" realiza más contenido, mientras que "Advocate" realiza más código de ejemplo.
En realidad esto no es una relación tan clara, y depende mucho de la empresa. Mi recomendación es que en las primeras entrevistas hagas muchas preguntas de qué tipo de trabajo se hace en DevRel en esa empresa, para que tengas claro que se alinea con lo que quieres hacer.
En general, y esto es una opinión personal, DevRel no es una carrera que recomendaría para personas que estén empezando en el mundo del software. Evidentemente, el tema de "años de experiencia" es muy relativo, pero recomendaría que al menos llevaras unos 5 años (o más) como desarrolladora, devops, experta en seguridad, o lo que sea que sea tu disciplina, antes de aventurarte al mundo DevRel.
¿Por qué? Pues porque gran parte de tu trabajo va a ser hacer la vida más fácil a otras expertas, y para ello se require cierta experiencia y haber estado en el otro lado durante un tiempo para saber qué tipo de material es útil. ¿Recuerdas ese bug que te tuvo atascada varios días y qué finalmente resolviste gracias a ese blog post que encontraste googleando? Pues eso.
Las empresas que contratan equipos de DevRel entienden que al ser una disciplina nueva y que requiere de experiencia previa como desarrolladora (o devops, seguridad, ...) muchas de las mejores candidatas pueden que sean aquellas que nunca hayan tenido experiencia previa en DevRel, pero que son expertas en lo suyo y saben comunicar.
El problema es que sin nada que demuestre que sabes comunicar, va a ser difícil que confíen en que sepas hacerlo, por lo que es interesante ir construyendo nuestro portfolio.
Si te gusta escribir, ábrete un blog y empieza a publicar. No hace falta que sean posts súper elaborados, pero sí que sean útiles. ¿Acabas de resolver un bug y crees que puedes ayudar a otras personas que se encuentren con lo mismo? Blog post. ¿Has encontrado un proyecto open source interesante en tu ámbito? Pruébalo y explícalo en un post. ¿Has creado una integración interesante? Crea un repositorio en GitHub con un ejemplo y un post para explicarlo.
Cuando digo "blog post" en realidad me refiero a cualquier tipo de comunicación. Si prefieres el vídeo, hazte un canal de YouTube. Si te mola el streaming, abre canal en Twitch. El formato de lo que elabores es menos importante, ya que depende mucho de preferencias personales.
Además, incluso si finalmente no quieres dar el salto a DevRel, construirte el portfolio te va a servir igualmente para construir tu marca personal de experta.
Dar charlas en conferencias es una de esas cosas que una vez que haces una vez, te abre las puertas para dar charlas en otras conferencias.
Dar charlas no solo te hace mejorar como oradora, pero además te ayuda a conocer a mucha gente de tu ecosistema, ya que las asistentes a la conferencia te harán preguntas, te charlarán en los pasillos, etc.
Nina Zakharenko tiene un buen artículo de cómo escribir una buena Call For Proposal (CFP).
¡Depende de lo tuyo!
Aquí es importante que entiendas que no es tan importante leer libros o artículos sobre DevRel en sí como disciplina (que también dejaré algunos enlaces más abajo), sino que entiendas que dependiendo de en qué ámbito te encuentres, siempre estés al día de lo que se cuece.
Gran parte del trabajo en DevRel es estar al día de las novedades, y eso depende mucho de a lo que te dediques. ¿Qué proyectos open source están siendo interesantes? ¿Qué tipo de APIs se están utilizando en tu ecosistema? ¿Cuál han sido los últimos zero-days que hay que conocer?
¿Eres desarrolladora frontend? Pues lee artículos sobre frontend. Elabora mini demos que puedas colgar en GitHub y puedan ayudar a otras desarrolladoras frontend. Sigue a gente de la comunidad frontend, etc.
¿Eres backend? Pues lo mismo ¿Eres SRE? Pues sigue a la comunidad "cloud native" ¿Eres experta en seguridad? Pues sigue blogs de seguridad.
🇬🇧 Inglés
Tener un inglés que te permita comunicarte, tanto hablado como escrito, es importantantísimo en software, aunque no te vayas a dedicar a DevRel. Soy de las que opina que el inglés es el conocimiento que más va a beneficiar tu carrera, subiendo los rangos de salario de las ofertas.
Si quieres estar en DevRel, es casi imprescindible. La mayoría de las empresas cuyo producto está orientado a desarrolladoras tienen un mercado global, por lo que el contenido que creas estará en inglés en muchas ocasiones.
La mayoría de las conferencias de desarrollo son en inglés, y poder dar charlas en estas conferencias es un punto bastante importante.
Además de estar al día de las novedades de tu área de conocimiento y de mejorar el inglés, puedes echar un vistazo a algunos recursos específicos de DevRel.
Ten en cuenta de que estos recursos son generales, y que algunas de las cosas que recomiendan van a variar mucho dependiendo del ecosistema en el que te encuentres. Nadie mejor que tú para saber qué cosas aplican, y que cosas no :)
The Developer Advocacy Handbook (ebook gratis)
(¡Pero recuerda que lo más importante es seguir a la gente de tu ecosistema!)
¡Hola! Soy Ara Pulido (she/her), Senior Technical Evangelist en @datadoghq . Si tienes cualquier duda sobre Developer Relations, no dudes en contactarme en Twitter, en @arapulido, y yo encantada de charlar un rato sobre el tema.
En Datadog estamos buscando a mucha gente para contratar en mi equipo, si te interesa, hazme ping.
Última actualización
