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 reporte de bug 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](https://en.wikipedia.org/wiki/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 a la que reporta el rol determina para qué se optimiza, y deberías decidirlo de forma deliberada. Alrededor del 35% de los equipos de developer relations reportan a Marketing, la mayor proporción individual, según los datos de State of Developer Relations; otros dependen de Producto para un ciclo de feedback más estrecho, y en las empresas developer-first la función reporta directamente a un CTO o CEO ([Heavybit](https://www.heavybit.com/library/article/collaborating-with-developer-relations-part-1-marketing)). Los advocates que reportan a Marketing optimizan para el alcance. Los que reportan a Producto optimizan para el ciclo de feedback. Elige el que coincida con tu objetivo real, porque la línea de reporte 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. Developer Advocate es un híbrido sin un único código de ocupación, así que la Oficina de Estadísticas Laborales (BLS) ofrece dos referencias útiles. Se proyecta que el empleo de Desarrolladores de Software (SOC 15-1252) crezca un 15% entre 2024 y 2034, "mucho más rápido que la media", con unas 129.200 vacantes anuales ([BLS Occupational Outlook Handbook](https://www.bls.gov/ooh/computer-and-information-technology/software-developers.htm)). Se proyecta que los Especialistas en Relaciones Públicas (SOC 27-3031), que capturan la mitad comunicativa, crezcan solo un 5% en el mismo periodo ([BLS](https://www.bls.gov/ooh/media-and-communication/public-relations-specialists.htm)). La verdad combinada: la demanda sigue la curva de ingeniería 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](https://algeriatech.news/developer-relations-devrel-career-2026/)). 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 reportan problemas de atribución multitáctil ([StateShift](https://blog.stateshift.com/devrel-roi-metrics-how-to-measure-communitys-business-value/)). 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?

Espera aproximadamente entre 90.000 y 160.000 dólares de salario base para perfiles individuales, mientras que los roles senior y de liderazgo superan con holgura los 200.000 dólares en compensación total. Trata cada cifra como una mediana nacional que la geografía y la antigüedad multiplican entre 2 y 3 veces.

Los agregadores salariales discrepan enormemente porque el título abarca roles con sesgo de marketing y otros con sesgo de ingeniería. Glassdoor reporta unos 135.847 dólares al año y PayScale unos 140.000, mientras que ZipRecruiter se sitúa cerca de 86.320 (mezcla roles junior y por contrato) ([Glassdoor](https://www.glassdoor.com/Salaries/developer-advocate-salary-SRCH_KO0,18.htm); [PayScale](https://www.payscale.com/research/US/Job=Developer_Advocate/Salary)). La referencia más defendible es la mediana de Desarrolladores de Software del BLS, de 133.080 dólares (mayo de 2024), con el percentil 10 en 79.850 y el percentil 90 por encima de 211.450 ([BLS](https://www.bls.gov/ooh/computer-and-information-technology/software-developers.htm)). Las encuestas específicas de DevRel se sitúan justo por encima de ese suelo, lo cual es internamente coherente.

Aquí tienes el panorama por antigüedad, orientativo y extraído de una única fuente secundaria, así que úsalo para encuadrar conversaciones más que como dogma:

| Nivel | Rango de comp. total (EE. UU.) |
|-------|--------------------|
| Inicial / Associate | 90k - 120k base |
| Nivel medio | 130k - 160k |
| Senior / Head of DevRel | 170k - 260k |
| Director / VP | 240k - 300k+ base |

Fuente: [DEV Community 2026 guide](https://dev.to/iris1031/developer-advocate-the-complete-career-strategy-guide-for-2026-47bg).

La compensación total en las grandes tecnológicas, que incluye equity, se sitúa más arriba y está bien documentada. Levels.fyi reporta una mediana de unos 217.000 dólares en Google (en torno a 190k en L3 y hasta más de 376k en L6) y alrededor de 190.000 tanto en Amazon como en Microsoft ([Levels.fyi: Google](https://www.levels.fyi/companies/google/salaries/software-engineer/title/developer-advocate)).

Dos palancas de variación con las que planificar. Geografía: San Francisco, Seattle y Nueva York empujan el techo de cada banda, mientras que las startups remote-first suelen pagar entre un 15% y un 25% por debajo de las tarifas de los hubs y 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](https://dev.to/iris1031/developer-advocate-the-complete-career-strategy-guide-for-2026-47bg)). 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](https://handbook.gitlab.com/job-families/marketing/developer-advocate/)).

**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](https://startup.jobs/interview-questions/developer-advocate)).

Una ronda que funciona bien, adaptada de la guía de contratación de daily.dev ([daily.dev](https://recruiter.daily.dev/roles/developer-advocate/)):

1. **Inmersión técnica profunda.** 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 de alta señal 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](https://startup.jobs/interview-questions/developer-advocate))
- "Explícame tu API o conjunto de documentación favorito y el que menos te gusta, y por qué." ([Reelsen](https://spinscale.de/posts/2022-06-15-developer-advocate-interview-questions.html))
- "Describe una vez en la que defendiste internamente las necesidades de los desarrolladores y cambiaste el producto." ([GitHub: Developer Evangelist questions](https://github.com/MurtzaM/Developer-Evangelist-Interview-Questions))

El tutorial para casa es el paso de mayor fidelidad porque refleja el trabajo real. Trátalo como los [ejercicios de código](/blog/how-to-structure-code-assignments) 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 la cultura de 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](https://recruiter.daily.dev/roles/developer-advocate/)). Presencia en la comunidad significa que aparece en GitHub, foros y Discord como un par, no como un vendedor. Cultura de 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 son consistentes 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 con las manos 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](https://www.ziprecruiter.com/career/Developer-Advocate/What-Is-How-to-Become)). 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](https://developers.google.com/program/gear/getcertified)). 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](/users/sign_up) 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 extender una 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 esa evidencia 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](https://blog.stateshift.com/how-to-create-a-devrel-kpi-dashboard-that-actually-proves-roi)).

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

| Métrica | Referencia |
|--------|-----------|
| Tasa de activación (registro hasta el primer éxito) | 20-40% alcanza el primer evento de éxito |
| Tiempo hasta el primer valor | Menos de 15 minutos (herramientas simples) |
| Conversión de prueba a pago (con comunidad activa) | 15-25%, frente al 10-15% de un SaaS tradicional |
| Adopción de funciones (impulsada por la comunidad) | ~37% más rápida que la línea base |
| Reducción de tickets de soporte (usuarios de la comunidad) | 20-40% menos de tickets básicos |

Fuente: [StateShift](https://blog.stateshift.com/devrel-roi-metrics-how-to-measure-communitys-business-value/).

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.

<div class="blog-inline-cta">
  <p><strong>¿Contratando a tu primer advocate?</strong> Las plantillas de rol de Kit incluyen un pipeline preconfigurado para que toda la ronda de DevRel, de la revisión del portafolio al tutorial para casa, la charla de prueba y la votación del equipo, esté lista sin construir las etapas desde cero.</p>
  <p><a href="/users/sign_up">Empieza tu prueba gratuita</a></p>
</div>

## ¿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](https://blog.stateshift.com/future-of-devrel-2026/)). Una agenda llena de ponencias no es una estrategia.

El resto de la lista es igual de costoso:

- **Medir salidas, 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](https://blog.stateshift.com/metrics-for-devrel/)).
- **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](https://blog.stateshift.com/future-of-devrel-2026/)).
- **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 de reporte 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.

Aquí es donde 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 sourcing 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?**
Cuenta con entre 90.000 y 160.000 dólares de salario base para perfiles individuales, y roles senior y de liderazgo que llegan hasta los 200.000 dólares en compensación total. La geografía y la antigüedad pueden multiplicar la banda entre 2 y 3 veces. Consulta la sección de salarios más arriba para ver referencias 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.

**¿A quién debería reportar un Developer Advocate: a Marketing, Producto o Ingeniería?**
Ajusta la línea de reporte a tu objetivo. Los advocates que reportan a Marketing optimizan para el alcance; los que reportan a Producto optimizan para el ciclo de feedback; las empresas developer-first suelen hacer que la función reporte a un CTO o CEO. La línea de reporte 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 sourcing, que es precisamente donde un pipeline genérico se desmorona.

Configura el rol a partir de una [plantilla de rol](/templates) 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](/blog/how-to-hire-backend-engineer) y [cómo contratar a un product designer](/blog/how-to-hire-product-designer). Cuando estés listo, [empieza una prueba gratuita](/users/sign_up) y pon en marcha el pipeline en una tarde.