Cómo contratar a un Developer Advocate: guía 2026 para empleadores

Para contratar a un Developer Advocate, evalúa tres cosas a la vez: credibilidad técnica (sabe escribir código y leer un stack trace), capacidad de comunicación y creación de contenido (un portafolio existente de tutoriales, charlas o documentación) y presencia genuina en la comunidad. Evita a los candidatos que optimizan para las apariciones en conferencias por encima de la adopción medible entre desarrolladores. Este rol no requiere ninguna certificación; lo que importa como requisito es un cuerpo de trabajo público.

El puesto suena difuso hasta que ves trabajar a un gran advocate. Reducen el tiempo hasta la primera llamada a la API de un producto de 30 minutos a 10, publican el tutorial que mil desarrolladores copian y pegan, y llevan el informe de error que por fin consigue que se rediseñe la API. La contratación equivocada da charlas pulidas que nadie pone en práctica. Esta guía cubre qué hace realmente el rol, cuánto cuesta, cómo entrevistar para él y cómo definir el éxito antes de que la persona empiece.

¿Qué hace un Developer Advocate y quién debería contratar a uno?

Un Developer Advocate se sitúa entre tu equipo de ingeniería y los desarrolladores que usan (o podrían usar) tu producto. Escriben tutoriales y documentación, construyen apps de ejemplo, hablan y responden preguntas en los canales de la comunidad, y trasladan el feedback de los desarrolladores de vuelta al producto. El rol es en parte ingeniero, en parte redactor técnico y en parte constructor de comunidad, y el equilibrio cambia según la empresa.

Las empresas que necesitan este rol son aquellas en las que los desarrolladores son el comprador o el usuario: empresas de API, firmas de developer tooling, plataformas de cloud e infraestructura, y startups respaldadas por open source (Wikipedia: Developer relations). En todas ellas, la adopción entre desarrolladores es el motor de crecimiento, así que un advocate es una inversión en crecimiento más que un lujo de marketing.

El área de la que depende el rol determina para qué se optimiza, y deberías decidirlo de forma deliberada. Alrededor del 35 % de los equipos de developer relations dependen de Marketing, la mayor proporción individual, según los datos de State of Developer Relations; otros se ubican bajo Producto para un ciclo de feedback más estrecho, y en las empresas developer-first la función depende directamente de un CTO o CEO (Heavybit). Los advocates que dependen de Marketing optimizan para el alcance. Los que dependen de Producto optimizan para el ciclo de feedback. Elige el que coincida con tu objetivo real, porque la línea jerárquica fija discretamente los KPI.

¿Vale la pena contratar a un Developer Advocate en 2026?

Sí, si la adopción entre desarrolladores impulsa tus ingresos y estás listo para medir resultados. El rol ha pasado del evangelismo en conferencias a una función estratégica de crecimiento, y las empresas que siguieron invirtiendo en él lo vinculan directamente al crecimiento impulsado por el producto.

La demanda sigue la curva del desarrollador de software, no la más lenta de la comunicación. Como Developer Advocate es un perfil híbrido sin un único código de ocupación, conviene anclarse en los datos de especialistas en TIC de Eurostat, la fuente primaria de la UE. En 2024 había más de 10 millones de especialistas en TIC en la UE (el 5,0 % de las personas ocupadas) y su número creció un 62,2 % entre 2014 y 2024 —unas seis veces más que el 10,6 % de crecimiento del empleo total— (Eurostat). Y contratarlos no es sencillo: en 2023, el 57,5 % de las empresas de la UE que intentaron contratar especialistas en TIC tuvieron dificultades para cubrir esas vacantes (Eurostat). La conclusión es la misma: la demanda sigue la curva tecnológica de alto crecimiento, porque la credibilidad técnica es el requisito imprescindible.

Hay una trampa, y es la razón de ser de esta guía. La ola de despidos de 2024 a 2025 golpeó con fuerza a los equipos de developer relations, eliminando de forma desproporcionada a los que no podían demostrar valor de negocio (Algeria Tech News). La presión es estructural: el 89 % de los equipos de developer relations tienen dificultades para demostrar el ROI con métricas tradicionales, y el 76 % de las empresas centradas en desarrolladores señalan problemas de atribución multicontacto (StateShift). El ecosistema que sobrevive es más ágil y mucho más orientado a resultados. Para ti como empleador, la lección es contundente: contrata pensando en el impacto en la adopción con un objetivo definido, o no contrates todavía.

¿Cuánto cuesta un Developer Advocate?

En España, las bandas de este puesto siguen las del desarrollo de software y son materialmente más bajas que las de EE. UU. No existe una cifra pública específica para el rol: ninguna fuente primaria desglosa el título de «Developer Advocate». Toma como suelo oficial la Encuesta Anual de Estructura Salarial (EAES) del INE y verifica la banda concreta con una encuesta de TI vigente antes de fijarla.

La estadística salarial oficial en España es la EAES del INE. En su edición de 2023 (datos definitivos), el salario bruto medio anual fue de 28.049,94 € a escala nacional y de 32.547,76 € en el sector de «Actividades profesionales, científicas y técnicas», donde se encuadran los puestos tecnológicos (INE, EAES 2023). El INE publica por grupo ocupacional y sector, no por el título exacto de «Developer Advocate», así que toma estas cifras como contexto y suelo oficial, no como la mediana del rol: los grupos técnico-profesionales se sitúan por encima de la media nacional.

Para encuadrar la banda por niveles conviene cruzar la EAES con una encuesta salarial de TI actualizada, como el Informe de Empleo Informático de Tecnoempleo. Ten presente que es una encuesta de un portal de empleo, no una fuente estadística primaria, así que complementa al INE en lugar de sustituirlo (Tecnoempleo). A grandes rasgos, la retribución de DevRel en España sigue las bandas de la ingeniería de software. Trata la tabla siguiente como orientativa y contrástala con los datos sectoriales del INE y una encuesta de TI vigente antes de fijar una banda:

Las filiales españolas de las grandes tecnológicas pagan por encima de las startups locales, pero muy por debajo de las cifras de sus sedes en EE. UU., sobre todo porque allí el grueso de la compensación llega en forma de acciones.

Dos palancas de variación con las que planificar. Geografía: Madrid y Barcelona, los principales hubs tecnológicos, llevan una prima sobre la media nacional (suele citarse en torno al 18-22 %), mientras que los puestos remote-first compiten por la flexibilidad. Modelo de trabajo: más del 70 % de los roles de developer relations son remotos o híbridos, lo que amplía tu bolsa de candidatos mucho más allá de tu ciudad (DEV Community). Ten en cuenta que Kit no ofrece referencias salariales, así que consulta cifras en vivo en las fuentes anteriores antes de fijar una banda.

¿Cómo es una oferta de empleo de Developer Advocate?

Una buena oferta de empleo separa «debe saber escribir código» (un requisito estricto) de «ya conoce nuestro stack exacto» (algo que se aprende). Confundir ambos descarta a advocates excelentes sin motivo. La familia de puestos pública de Developer Advocate de GitLab es la mejor referencia abierta sobre la que modelar la tuya (GitLab Handbook).

Requisitos estrictos:

• Experiencia en desarrollo de software o un historial de contribuciones a open source. Deben saber escribir código, leer un stack trace y razonar sobre arquitectura.
• Al menos alrededor de un año creando demos, talleres, webinars o vídeos técnicos.
• Comunicación escrita y verbal sobresaliente, con la capacidad de traducir tecnología compleja en contenido claro.
• Una presencia consolidada en la comunidad con una audiencia comprometida.
• Disponibilidad para viajar (GitLab indica hasta un 20 % anual; ajusta la tuya a tu estrategia de eventos).

Deseables (no los conviertas en bloqueantes):

• Familiaridad con tu stack específico, ya sea Git, CI, contenedores, Kubernetes u otra cosa.
• Experiencia con metodologías Agile o DevOps.
• Trayectoria en SaaS u open core.
• Formación en medios y relaciones existentes con periodistas.
• Una red ya establecida entre varias comunidades.

El movimiento de redacción más importante: empieza por el reto de adopción concreto del que se hará responsable la persona. «Reducir el tiempo hasta la primera llamada a la API de 30 a 10 minutos» le dice a un buen candidato exactamente cómo es el éxito. «Evangelizar nuestra plataforma» no le dice nada y atrae al arquetipo equivocado.

¿Qué preguntas de entrevista deberías hacerle a un Developer Advocate?

Olvídate de LeetCode, los algoritmos en pizarra y las preguntas trampa. Las entrevistas de developer relations dan mucho peso a la comunicación en todas las rondas, y las señales más predictivas vienen del trabajo real: un portafolio, un tutorial para casa y una charla de prueba (startup.jobs).

Una ronda que funciona bien, adaptada de la guía de contratación de daily.dev (daily.dev):

1. Análisis técnico a fondo. Pídeles que expliquen un concepto de tu dominio y luego sondea si pueden detectar carencias en tu experiencia de desarrollador actual.
2. Revisión del portafolio. Lee sus entradas de blog reales, mira una charla, hojea su documentación. Evalúa la claridad, la conexión con la audiencia y la precisión técnica.
3. Caso práctico de comunidad. Pregunta: «Cuéntanos sobre un desarrollador al que ayudaste a tener éxito. ¿Cuál fue el resultado?». Escucha buscando concreción y empatía.
4. Tutorial para casa. Pide una breve guía de inicio para tu producto. Evalúa la claridad, la exhaustividad y si lo escribieron desde la perspectiva real de un desarrollador.
5. Charla de prueba (15 a 20 minutos). Evalúa la presencia escénica y lo bien que explican algo difícil.
6. Planificación estratégica. Pregunta «¿Cómo medirías el éxito aquí?» y escucha buscando un equilibrio entre contenido, comunidad y promoción interna.

Preguntas reveladoras que conviene intercalar:

• «Explícame tu proceso desde la investigación hasta la publicación de una guía de inicio.»
• «Háblame de una comunidad de desarrolladores que hayas hecho crecer. ¿Qué funcionó y qué no?»
• «¿Qué métricas te dicen que tu trabajo realmente impulsa la adopción?» (startup.jobs)
• «Explícame tu API o conjunto de documentación favorito y el que menos te gusta, y por qué.» (Reelsen)
• «Describe una vez en la que defendiste internamente las necesidades de los desarrolladores y cambiaste el producto.» (GitHub: Developer Evangelist questions)

El tutorial para casa es el paso de mayor fidelidad porque refleja el trabajo real. Trátalo como los ejercicios de código que le darías a un ingeniero: acótalo a algo pequeño, fija un límite de tiempo claro y da feedback real. Si gestionas la contratación técnica en Kit, los ejercicios de código están integrados con GitHub, así que la app de ejemplo o el repositorio del tutorial de un candidato aterriza en el mismo pipeline que el resto de su evaluación, en lugar de quedar dispersos por hilos de correo.

¿Qué deberías evaluar y qué credenciales puedes ignorar?

Evalúa, por orden de prioridad, la credibilidad técnica, un portafolio público existente, una presencia genuina en la comunidad y el dominio de la adopción. El portafolio es la señal más fuerte de todas, porque es el propio trabajo, realizado en público, antes incluso de contratar.

Cómo es la «credibilidad técnica» en la práctica: ha construido SDK, herramientas o muestras de código sustanciales; tiene un historial activo de open source con pull requests y proyectos mantenidos; ha tenido roles previos de ingeniería; es capaz de depurar y revisar código sobre la marcha (daily.dev). Presencia en la comunidad significa que aparece en GitHub, foros y Discord como un par, no como un vendedor. El dominio de la adopción significa que sabe conectar su trabajo con la activación, la retención y los ingresos sin que se lo pidan.

Las señales de alarma coinciden en todas las fuentes: no tiene contenido existente; no sabe explicar con claridad un concepto técnico; está ausente de las comunidades de desarrolladores; solo habla de sí mismo; desdeña la medición del impacto; no programa de forma práctica desde hace dos años o más; un perfil puramente de marketing sin base de ingeniería. Esta última es el error caro más común, porque la comunidad leerá a un «marketero al que le gustan los desarrolladores» como un vendedor y dejará de prestarle atención.

Sobre las credenciales, la respuesta es directa: no se requiere ninguna. No existe una licencia para este rol. Las certificaciones de AWS o Google Cloud pueden añadir credibilidad en puestos específicos de cloud, pero nunca sustituyen a un cuerpo de trabajo público; los empleadores priorizan explícitamente la experiencia demostrada y las contribuciones a la comunidad por encima de las credenciales formales (ZipRecruiter). El programa «Get Certified» de GEAR de Google existe, pero es una credencial de habilidades de desarrollo, no un filtro de contratación para developer relations (Google for Developers). Si la única prueba de un candidato es un certificado, sigue buscando.

Como el juicio central («¿es esta persona un par creíble para los desarrolladores?») es subjetivo, es justamente la decisión que no deberías dejar en manos de un solo evaluador. Aquí es donde la revisión del equipo y la votación estructuradas demuestran su valor: cada entrevistador puntúa el portafolio, el tutorial para casa y la charla de prueba con la misma rúbrica, y ves dónde se percibe la credibilidad de forma distinta dentro del equipo antes de presentar la oferta. La revisión del equipo y el pipeline asistido por IA de Kit (gestionado a través de MCP, para que un asistente de IA pueda mover candidatos y mostrar las hojas de puntuación) mantienen esos datos en un solo lugar en lugar de en la memoria de seis personas.

¿Cómo mides el impacto de un Developer Advocate?

Define el éxito como adopción, no como actividad, y plasma las métricas en la oferta antes del primer día. Un Discord de 5.000 personas no significa nada si nadie lanza algo, y un blog con 50.000 visitas no significa nada si nadie se activa (StateShift).

Las referencias del sector señaladas por StateShift te dan objetivos concretos que incluir en los criterios de éxito del rol:

Fuente: StateShift.

Una forma sencilla de organizar esto es el modelo de tres capas: las Fuentes (documentación, Discord, eventos, GitHub) alimentan los Resultados (activación, retención, expansión), que se producen a partir de los Activos (tutoriales, vídeos, flujos de onboarding). Medido desde el primer día, la visibilidad del ROI suele aparecer en torno a los 90 días. La disciplina de nombrar estas cifras de antemano cumple una doble función: prepara al advocate para ganar y protege al rol de ser lo primero que se recorta en la próxima recesión.

¿Cuáles son los errores más comunes al contratar a un Developer Advocate?

El mayor error es contratar pensando en las charlas de conferencias. La mayoría de los desarrolladores no asisten a conferencias, y las empresas han gastado históricamente de más en viajes de developer relations; el punto óptimo son una o dos buenas charlas al año en eventos de alto perfil, a partir de las cuales llegan los rendimientos decrecientes (StateShift). Una agenda llena de ponencias no es una estrategia.

El resto de la lista es igual de costoso:

• Medir entregables, no resultados. Las visitas al blog y la asistencia a eventos son métricas de vanidad. Mide en su lugar la conversión a usuarios activos, el tiempo hasta el valor y la contribución a los ingresos (StateShift).
• Ignorar el feedback que recogen. Contratar a un advocate, pedirle que recopile feedback del producto y luego ignorarlo se describe como la norma, y es una de las principales razones por las que los advocates renuncian (StateShift).
• Sin definición de resultados. «Involucrar a los desarrolladores» sin un KPI es trabajo de relleno que parece productivo hasta que la siguiente revisión de presupuesto lo recorta.
• La línea jerárquica equivocada. Poner a una contratación de ciclo de feedback bajo Marketing (o a una contratación enfocada en el alcance bajo Producto) la prepara para que se la mida por las cosas equivocadas.

Cada uno de estos errores se remonta a la misma causa raíz: contratar antes de haber definido qué significa la adopción para tu producto.

Sourcing: dónde encontrar Developer Advocates

Los mejores advocates rara vez navegan por los portales de empleo. Están publicando en GitHub, respondiendo preguntas en Discord, escribiendo en sus propios blogs y dando charlas. Eso significa que las candidaturas entrantes infrarrepresentarán a tus mejores candidatos, y tienes que ir a buscarlos.

Empieza por hacer ingeniería inversa de tu propia comunidad. ¿Quién ya escribe grandes tutoriales sobre tu campo? ¿Quién responde las preguntas de otros desarrolladores en tu Discord o en Stack Overflow? ¿Quién mantiene un proyecto adyacente al tuyo? Esas personas ya han demostrado exactamente las habilidades que estás evaluando, en público y sin cobrar. Una nota cercana y específica sobre un trabajo que realmente hicieron supera a cualquier mensaje genérico de reclutador.

Es entonces cuando la captación con IA ayuda sin convertirse en spam. La captación con IA de Kit redacta correos en frío personalizados basados en el trabajo real de un candidato, para que puedas lanzar una campaña de captación pequeña y de alta calidad hacia advocates pasivos en lugar de esperar a las candidaturas entrantes. Combínala con el acceso de candidatos por enlace mágico, que permite a un prospecto pasivo abrir tu ejercicio o mensaje sin crear otra contraseña más, y con plantillas de correo más una agenda integrada para mantener el impulso con personas que probablemente tengan ofertas competidoras. El objetivo no es el volumen; es llegar al puñado de personas que ya son un par creíble para tus desarrolladores.

Preguntas frecuentes sobre la contratación de un Developer Advocate

Respuestas breves a las preguntas que más se hacen los empleadores cuando abren esta búsqueda.

¿Cuál es la diferencia entre un Developer Advocate y un Developer Evangelist? Los títulos se solapan y muchas empresas los usan indistintamente. En la práctica, «advocate» tiende a inclinarse hacia el trabajo bidireccional (llevar el feedback de los desarrolladores de vuelta al producto), mientras que «evangelist» se inclina hacia la concienciación de salida. Lee las responsabilidades reales, no la etiqueta, y redacta la oferta de empleo en torno al resultado de adopción que necesitas.

¿Necesitas un Developer Advocate si aún no tienes encaje producto-mercado? Normalmente no como primera contratación. El rol da frutos una vez que los desarrolladores ya son el comprador o el usuario y tienes algo que puedan adoptar. Antes de eso, los fundadores suelen hacer ellos mismos el trabajo de advocacy y contratan cuando hay un objetivo de adopción definido del que responsabilizarse.

¿Cuánto cuesta un Developer Advocate en 2026?

En España, las bandas siguen las del desarrollo de software y son bastante más bajas que las estadounidenses; no hay una cifra pública específica para el puesto. Toma como referencia oficial la EAES del INE (salario bruto medio anual de 28.049,94 € en 2023 a escala nacional; 32.547,76 € en el sector profesional, científico y técnico) y contrástala con una encuesta de TI vigente, como el Informe de Empleo Informático de Tecnoempleo, antes de fijar la banda. Consulta la sección de salarios más arriba para ver el detalle con fuentes.

¿Necesita un Developer Advocate un título o una certificación? No. No existe licencia ni certificación obligatoria para el rol. Lo que importa como requisito es un cuerpo de trabajo público (tutoriales, charlas, documentación, contribuciones a open source); las certificaciones de cloud pueden añadir credibilidad en roles específicos de cloud, pero nunca sustituyen al trabajo demostrado.

¿De quién debería depender un Developer Advocate: de Marketing, Producto o Ingeniería? Ajusta la línea jerárquica a tu objetivo. Los advocates que dependen de Marketing optimizan para el alcance; los que dependen de Producto optimizan para el ciclo de feedback; las empresas developer-first suelen hacer que la función dependa de un CTO o CEO. La línea jerárquica fija discretamente los KPI, así que elígela de forma deliberada.

Contratar a un Developer Advocate con Kit

Kit es un ATS nativo de IA pensado para startups que hacen exactamente este tipo de contratación con matices. Una búsqueda de Developer Advocate es multietapa, en parte subjetiva e intensiva en captación, que es precisamente donde un pipeline genérico se desmorona.

Configura el rol a partir de una plantilla de rol para que la ronda (revisión del portafolio, tutorial para casa, charla de prueba y votación del equipo) exista desde el primer día. Usa los ejercicios de código para recopilar el tutorial o la app de ejemplo a través de un flujo integrado con GitHub. Usa la revisión del equipo y la votación para que el juicio de «¿es un par creíble?» se puntúe con una rúbrica compartida en lugar del instinto de una sola persona. Usa la captación con IA para llegar a los advocates que nunca se postulan, y los enlaces mágicos más la agenda para mantenerlos comprometidos. Y como todo el pipeline está expuesto a través de MCP, un asistente de IA puede avanzar candidatos, resumir hojas de puntuación y mostrar la siguiente decisión, para que dediques tu tiempo al criterio, no a meter datos. Kit cobra por asiento, así que un equipo fundador de tres personas puede llevar toda la búsqueda sin un contrato enterprise.

Contrata al advocate que pueda demostrar, en público, que hace que los desarrolladores tengan éxito, y luego define la adopción antes de que empiece. Haz esas dos cosas y conseguirás a alguien que mueve tus números, no solo tu presupuesto de conferencias. Para guías hermanas, consulta cómo contratar a un ingeniero backend y cómo contratar a un product designer. Cuando estés listo, empieza una prueba gratuita y pon en marcha el pipeline en una tarde.