10 Consejos para Entrar al Mundo de Developer Relations

Por Kevin Blanco — Senior Developer Advocate, Google Developer Expert, y fundador de DevRel Latam
Enero de 2026 marca varios años desde que me convertí en Developer Advocate profesional. Durante este tiempo he tenido la oportunidad de trabajar tanto en startups en etapa Series B como Appsmith, hasta colaborar con corporaciones globales como IBM, Google, Microsoft, Nintendo y Nike. Ha sido un viaje intenso, lleno de aprendizajes, y sin duda el trabajo más gratificante que he tenido.
Mientras escribo este artículo, estoy preparando mi próxima charla para All Things Open AI 2026 en Durham, North Carolina, así como mi presentación para Google Cloud Next 2026 en Las Vegas. Durante mi carrera como speaker he tenido el privilegio de dar conferencias en multiples ciudades en varios continentes y en cada evento, sin falta, alguien se me acerca y me pregunta: "¿Cómo puedo entrar a DevRel?"
No los culpo. Es un rol increíble para quienes disfrutan lo que implica: la mezcla de tecnología, comunicación, comunidad y el privilegio de ayudar a otros desarrolladores a crecer.
En este artículo voy a compartir lo que he aprendido en mi camino — desde mis inicios en Costa Rica con acceso limitado a tecnología, hasta ser Keynote Speaker y viajar por muchas ciudades educando a la nueva generación de tecnólogos. Estas lecciones vienen de mi experiencia personal y de observar a otros profesionales exitosos en este espacio. No es la única forma de entrar a DevRel, pero sí es un camino probado.
1. Aprende a escribir (y hazlo constantemente)
Cuando digo "aprende a escribir", no me refiero a que necesitas ser un perfeccionista gramatical o tener un estilo literario impecable.
Lo que quiero decir es que debes sentirte cómodo volcando tus ideas en una página. Para mí, esto vino con mucha práctica. Me hice el hábito de documentar todo lo que aprendía — tanto en forma de artículos de blog como en READMEs detallados en GitHub.
Escribir te obliga a entender las ideas a un nivel más profundo. Una cosa es poder hacer algo tú mismo, y otra muy diferente es explicárselo a alguien más. Cuando escribes, te enfrentas a las preguntas que aún no sabes responder. Te fuerza a investigar a fondo.
Mi experiencia personal: Uno de mis primeros artículos sobre Headless Drupal hace 13 años tuvo apenas 20 lecturas iniciales. Me sentí frustrado. Tres años después, ese mismo artículo fue citado por uno de los desarrolladores Drupal más reconocidos del mundo en su libro, lo que resultó en una invitación a hablar en DrupalCon. La moraleja: no te desanimes por las métricas iniciales. El contenido evergreen trabaja para ti mientras duermes.
Además, una de las habilidades más importantes en DevRel es la comunicación. Estarás constantemente comunicándote con tu equipo, otros desarrolladores, líderes de comunidad, organizadores de conferencias y muchos más. La gran mayoría de esta comunicación será escrita — tweets, emails, mensajes directos, documentación. Ser un escritor competente amplifica todo lo demás que hagas.
2. Construye puentes, no muros
Una de las charlas más influyentes que he visto fue de Aaron Frost en NG Vegas 2015, titulada "Building Bridges". Su mensaje era simple pero poderoso: otras personas pavimentaron el camino hacia su éxito, y ahora que él tiene la oportunidad, está pagando esa deuda hacia adelante.
La razón por la que muchos de nosotros estamos donde estamos hoy es por el trabajo de otros: los tutoriales que crearon, los proyectos open source que mantuvieron, las preguntas que respondieron en Stack Overflow. La idea es construir puentes y pagar hacia adelante cuando estés en posición de hacerlo.
Mi experiencia personal: Cuando empecé en el ecosistema Drupal, encontré verdadera pasión en contribuir de vuelta a la comunidad. Era increíble ver cómo desarrolladores brillantes eran súper humildes y extremadamente serviciales para sentarse conmigo y explicar las cosas. Eso me marcó profundamente. Hoy, esa misma filosofía guía todo lo que hago — desde mentorías gratuitas hasta organizar meetups y crear contenido educativo.
Dependiendo de tu nivel de experiencia, construir puentes puede verse de muchas formas: mentoría uno a uno, escribir artículos sobre lo que aprendes, organizar o apoyar meetups locales, responder preguntas en foros, contribuir a proyectos open source. Esta filosofía en acción ES lo que Developer Relations significa en esencia.
3. No te cases con una tecnología específica
Muchas personas entran a DevRel porque son especialistas en algo. Yo era (y sigo siendo) muy activo en ciertas comunidades tecnológicas. Pero esto es algo que debes mantener bajo control.
Cuando entras a DevRel, uno de los aspectos más importantes es construir confianza. No hay forma de fingir autenticidad.
Ser demasiado leal a una tecnología específica o a una forma particular de hacer las cosas te hará perder perspectiva del objetivo general. Nuestro trabajo NO es mostrar amor incondicional por nuestro framework o lenguaje favorito.
Mi experiencia personal: En mi carrera he trabajado con Drupal, Wordpress, Jommla, React, Angular, Vue Node.js, Java Spring, PHP, Ruby, Google Cloud, Azure, IBM Cloud, AWS, herramientas low-code como Appsmith y AppSheet, y muchas otras más, como puedes ver muchas de ellas son “competencias entre si” y dependiendo del proyecto una sirve más que la otra. Esta diversidad me ha permitido ver patrones que trascienden tecnologías específicas y me ha hecho más valioso para las empresas donde he trabajado.
Aprende a ser curioso sobre tecnologías competidoras. Muchas veces descubrirás que puedes aprender mucho de su enfoque, o incluso que te gusta más su forma de hacer las cosas. Cuando diriges un podcast, newsletter o comunidad, estás pidiendo a las personas que te den su confianza. Cuando muestras sesgo o impides que otras ideas sean escuchadas, le haces un daño a tu comunidad.
El objetivo no es promover lo que te gusta — es habilitar a las personas para que construyan cosas, resuelvan sus problemas y avancen en sus carreras.
4. Entiende el negocio: Go-to-Market y Difusión de Innovación
Aquí es donde muchos aspirantes a DevRel se quedan cortos. Esta es la diferencia entre ser un creador de contenidos o un verdadero Developer Advocate con madera para ser contratado por una empresa. Para tener conversaciones de valor con tu empresa y realmente aportar estratégicamente, necesitas entender conceptos fundamentales de producto y negocio.
La Ley de Difusión de Innovación
Este modelo, desarrollado por Everett Rogers, explica cómo las nuevas ideas y tecnologías se adoptan a través de una población:
Los cinco grupos de adoptantes:
Innovators (2.5%): Los primeros en probar tecnología nueva, aunque no esté probada. Son tomadores de riesgo.
Early Adopters (13.5%): Líderes de opinión que adoptan temprano y ayudan a normalizar la innovación para otros.
Early Majority (34%): Individuos prudentes que adoptan después de ver evidencia de utilidad.
Late Majority (34%): Consumidores escépticos que adoptan solo después de que la mayoría lo ha hecho.
Laggards (16%): Tradicionalistas, resistentes al cambio, los últimos en adoptar.
El Tipping Point: Existe un punto crítico (aproximadamente 15-18% de penetración de mercado) donde una innovación pasa de ser un nicho a convertirse en mainstream. Como DevRel, tu trabajo frecuentemente es ayudar a cruzar ese abismo entre Early Adopters y Early Majority.
¿Por qué importa esto para DevRel? Porque tu estrategia debe adaptarse según dónde esté tu producto en esta curva. Si estás trabajando para una startup en etapa seed, tu audiencia principal son Innovators y Early Adopters — desarrolladores que disfrutan experimentar con tecnología emergente. Si estás en una corporación establecida, probablemente estés enfocándote en Early y Late Majority, donde necesitas demostrar casos de uso probados y estabilidad.
Entiende la etapa de tu empresa
La posición de crecimiento de tu empresa (pre-seed, seed, Series A, B, C, IPO) debe informar tu estrategia de DevRel:
Pre-seed/Seed: Enfócate en construir comunidad inicial, feedback loops con el producto, contenido que valide el problema que resuelves.
Series A/B: Escala tu alcance, establece métricas claras, construye relaciones con influencers del ecosistema.
Series C+/IPO: Enfócate en enterprise, partnerships estratégicos, programas de certificación, ecosistema de integraciones.
Mi experiencia personal: En Appsmith, una startup Series B, mi enfoque fue muy diferente a mi rol actual en Asana. En la startup, me concentré en crecer la comunidad de 3,000 a más de 20,000 miembros y producir contenido que incrementara nuestro awareness, mi rol era rapidez, tenía mas capacidad de hacer prueba y error. En Asana, mi enfoque es más enterprise, debo tomar en cuenta un numero grande de partners y casos de uso de clientes Fortune 500.
5. Aprende lo básico de Marketing (aunque no seas marketer)
Nuestro rol no es 100% marketing, pero cruza muchas metas con el equipo de marketing de un producto tecnológico. Ignorar esto te pone en desventaja.
Conceptos que debes dominar:
MQLs (Marketing Qualified Leads): Entiende cómo el contenido que creas puede contribuir al pipeline de ventas. No porque vayas a vender directamente, sino porque necesitas hablar el mismo idioma que tus stakeholders.
Posicionamiento: Mi libro favorito es "Las 22 Leyes Inmutables del Marketing" de Al Ries y Jack Trout. Aunque tiene años, los principios fundamentales siguen vigentes. Algunas leyes que aplican directamente a DevRel:
Ley del Liderazgo: Es mejor ser el primero que ser el mejor. Si tu producto no es el primero en una categoría, crea una nueva categoría donde puedas ser primero.
Ley de la Categoría: Si no puedes ser el primero en una categoría, crea una nueva en la que puedas serlo.
Ley de la Mente: Es mejor ser el primero en la mente del cliente que el primero en el mercado.
Ley de la Percepción: El marketing no es una batalla de productos, es una batalla de percepciones.
¿Por qué importa para DevRel? Porque cuando creas contenido, cuando das charlas, cuando construyes comunidad, estás participando activamente en el posicionamiento de tu producto. Si no entiendes estos principios, podrías estar trabajando en contra de los objetivos de tu empresa sin darte cuenta.

6. Las métricas son tu mejor aliado (y tu escudo)
Este es quizás el consejo más importante y el menos discutido: DevRel va MUCHO más allá de crear contenido, dar charlas o ir a eventos.
Cada una de estas actividades debe tener pre-planeamiento con diferentes equipos — producto, ventas, marketing, soporte — para tener:
Metas claras
Audiencia meta definida
User personas específicas
Métricas de éxito establecidas ANTES de ejecutar
Por qué las métricas te protegen
En tiempos de recortes presupuestarios (y créeme, DevRel suele ser uno de los primeros equipos en ser cuestionados), las métricas son tu escudo. Si puedes demostrar que:
Tu video tutorial redujo los tickets de soporte en un 30%
Tu charla en la conferencia X generó Y nuevos usuarios registrados
Tu comunidad tiene Z% de tasa de activación hacia producto de pago
...entonces tienes argumentos concretos para defender tu posición y tu equipo.
Tipos de métricas que debes trackear:
Awareness/Alcance:
Impresiones y alcance de contenido
Seguidores y crecimiento de comunidad
Menciones de marca
Engagement:
Tiempo de visualización (no solo views)
Comentarios y discusiones generadas
Contribuciones de la comunidad
Conversión:
Signups atribuibles a tu contenido
Usuarios activos de la comunidad que convierten a producto
Reducción de tickets de soporte
Retención:
Net Promoter Score de la comunidad
Tasa de retención de miembros activos
Advocacy generado (miembros que crean contenido propio)
Mi experiencia personal
En Appsmith produje más de 500 videos. Pero el número de videos no es la métrica que importa. Lo que importa es que esos videos redujeron significativamente los tickets de soporte — eso es ROI tangible que cualquier ejecutivo puede entender.
He tenido videos con pocas vistas pero altísimo viewership (la gente que los ve, los ve completos) que resolvieron problemas específicos de usuarios. Esos "fracasos" en métricas de vanidad fueron éxitos rotundos en métricas de negocio.
La lección: No te dejes engañar por métricas de vanidad. Un artículo con 20 lecturas que posiciona tu producto correctamente en la mente de los 20 decision-makers correctos vale más que un artículo viral que no convierte a nadie.
7. Aprende a hablar en público
Este parece obvio, ¿verdad? Pero, ¿cómo empezar?
Yo comencé hablando en meetups locales en Costa Rica. Estos son lugares perfectos para iniciar porque las audiencias suelen ser pequeñas. No han invertido mucho dinero para asistir, así que serán menos críticos si tienes algún tropiezo.
También existen grupos de Toastmasters (sí, algo nerds pero increíbles 🤓) que se dedican específicamente a ayudar a las personas a practicar oratoria y mejorar sus habilidades de comunicación.
Las lightning talks (charlas relámpago de 5 minutos) son excelentes para empezar porque es mucho más fácil preparar 5 minutos que 50 minutos de material. Ganarás experiencia hablando en un evento "real" y podrás usar esa referencia para aplicar a eventos más grandes.
Mi consejo: Prepara lo que yo llamo una charla "production-ready" — algo que practiques hasta conocerlo como la palma de tu mano, con un título y descripción pulidos. Puedes usar esta misma charla para aplicar a docenas de eventos. Si te aceptan en más de uno, no tendrás tanto estrés porque ya dominas el material, y ganarás experiencia valiosa.
Un secreto sobre hablar en público: Nunca se vuelve completamente fácil. Se vuelve MÁS fácil, pero probablemente nunca caminarás frente a una audiencia sin sentir al menos algo de ansiedad. He hablado con muchos speakers experimentados que sienten lo mismo. La clave es, como dice Nike, Just Do It. Una vez que abres la boca y empiezas a hablar, la ansiedad comienza a disiparse.
Mi experiencia personal: Hoy en día he sido Keynote Speaker en eventos como Google I/O, DevRelCon, DrupalCon, Nerdearla, etc Pero empecé exactamente igual que todos — nervioso, en meetups pequeños, aprendiendo de mis errores. La diferencia está en la persistencia, he participado en más de 100 “Drupeleadas” que son meetups pequeños mensuales de la comunidad Drupal en Costa Rica, muchas de ellas fueron pésimas, otras un poco mejor.

8. Enseña mientras aprendes
Recuerdo vívidamente escribir mi primer artículo técnico "serio". Estaba aprendiendo algo nuevo, luchando con la documentación, y mientras avanzaba, fui escribiendo lo que entendía. Antes de darme cuenta, tenía algo digno de compartir.
Cuando escribí ese artículo, de ninguna manera era un experto. Pero docenas de personas me contactaron diciéndome cuánto habían aprendido de él.
Esto conecta con el primer punto: enseñar o escribir sobre algo te fuerza a entenderlo a un nivel a veces incómodo, lo cual es bueno si tu objetivo es ayudar a otros a entenderlo también.
El concepto de "Learn in Public" (Aprender en Público), popularizado por Shawn "Swyx" Wang, es algo que deberías considerar adoptar. La idea es compartir tu proceso de aprendizaje públicamente — tus dudas, tus descubrimientos, tus errores. Esto no solo te ayuda a ti, sino que ayuda a otros que están en el mismo camino.
9. Alienta a otros constantemente
Una de las cosas más fáciles que podemos hacer, especialmente con la cantidad de negatividad que existe en el mundo hoy, es levantar a las personas y alentarlas. Esto se vuelve especialmente importante a medida que creces tu red y tienes la oportunidad de ayudar a quienes tienen menos voz o menos privilegios.
Ser una de esas personas que es incansablemente servicial y alentadora no solo te beneficiará como miembro de la comunidad, sino que genuinamente ayudarás a personas a superar barreras mentales, conseguir trabajos, obtener contratos de freelance — incluso ayudarles a compartir su propio conocimiento e ideas.
Lo más importante a recordar: Tu trabajo principal en DevRel es habilitar y abogar en nombre de otros desarrolladores y miembros de la comunidad, NO de la empresa que eventualmente te contrate. Sí, trabajas para una empresa, pero tu lealtad principal es hacia la comunidad.
10. Actúa como si ya fueras DevRel
El punto más importante de todos: simplemente empieza a SER uno, independientemente de tu rol actual.
Sigue a otras personas haciendo lo que te gustaría hacer. Aprende de ellas. Empieza a hacer lo que ellas hacen — escribe, habla, contribuye, construye comunidad.
Si haces esto, ya estás en camino a conseguir el rol. Cuando apliques o tengas una entrevista, será obvio que ya tienes un track record.
Mi experiencia personal: Antes de tener el título oficial de "Developer Advocate", ya estaba haciendo el trabajo. Escribía artículos, daba charlas, contribuía a proyectos open source, ayudaba a otros desarrolladores. Cuando llegó la oportunidad formal, fue una transición natural porque ya había demostrado que podía hacer el trabajo.

Reflexión final
La mayoría de la gente piensa que DevRel significa que tu título debe ser "Developer Advocate" o "Developer Evangelist". Esto no es cierto. Hay cada vez más personas en roles tradicionalmente de ingeniería que también asumen el rol de advocate. Muchas veces, estas personas usan su talento y posición en la comunidad como una oportunidad para ayudar a otros.
Ayudar y empoderar a las personas es de lo que se trata este rol, pero con inteligencia, planeamiento, estrategia y métricas de por medio.
Si estás leyendo esto y sientes que DevRel es para ti, empieza hoy. No esperes permiso. No esperes el título oficial. Empieza a construir puentes, a escribir, a enseñar, a alentar. El rol llegará como consecuencia natural de hacer el trabajo.
¿Tienes preguntas sobre cómo entrar a DevRel? Conéctate conmigo en LinkedIn y únete a nuestra comunidad.
Comparte tus experiences y únete a la conversación en el nuestro chat de discord: https://discord.gg/kwugZvJS





