Cuando "Developer Advocate" significaba otra cosa

El distribuidor de pegatinas

Cuando me presento como “Developer Advocate”, a menudo recibo una mirada muy específica. Es una mezcla de anticipación y cálculo. La persona al otro lado de la mesa —generalmente un organizador de conferencias o un community manager— se pregunta en silencio: ¿Tienes pegatinas? ¿Tienes presupuesto para pizza? ¿Puedes patrocinar nuestro hackathon?

Tengo que decepcionarlos. No tengo pegatinas. No tengo presupuesto de marketing. Tengo una profunda preocupación por el hecho de que su pipeline de despliegue tarda 45 minutos y falla aleatoriamente, y estoy aquí para abogar por el equipo que tiene que sufrir eso.

En algún momento de los últimos quince años, perdimos la definición de este rol. Pasó de ser un “Ingeniero Senior que protege el ecosistema” a una “Persona carismática que genera leads”. Y al igual que con el término “Agile Coach”, la comoditización del título ha dejado un vacío donde solía haber autoridad técnica.

El título robado

Hubo una breve era dorada —impulsada principalmente por empresas como Google y Mozilla alrededor de 2010— donde un Developer Advocate era un rol aterradoramente técnico.

En esos días, la distinción entre “Evangelista” y “Advocate” (defensor) era precisa. Un Evangelista (término heredado de los días de Guy Kawasaki en Apple) miraba hacia afuera. Llevaban las “Buenas Nuevas” desde la montaña del proveedor hacia las masas.

Un Advocate miraba hacia adentro. Eran el “Cliente Cero”. Eran ingenieros senior que intentaban construir aplicaciones reales con la plataforma, encontraban dónde estaba rota y tenían el capital político interno para marchar a la oficina del gerente de producto y decir: “Esta API es basura. No podemos lanzar esto”.

Abogaban por el desarrollador ante la empresa.

Entonces explotó la “Economía de las API”. Twilio, Stripe, SendGrid y mil herramientas SaaS respaldadas por capital de riesgo necesitaban adquirir usuarios. El rol de “Developer Advocate” fue absorbido por la maquinaria del “Top of the Funnel” (parte superior del embudo de ventas). Las líneas de reporte cambiaron del CTO al CMO. El KPI cambió de “calidad del SDK” a “registros de usuarios”.

El “Advocate” se convirtió en una cara amigable que genera entusiasmo, no en un ingeniero senior que genera fricción.

La parábola del Agile Coach

Hemos visto esta erosión del significado técnico antes. Es la misma tragedia del “Agile Coach”.

Si volvemos a los orígenes de Extreme Programming (XP) a finales de los 90, el “Coach” (tal como lo definía Kent Beck) era un maestro practicante. Se sentaba a tu lado. Programaba en pareja (pair programming). Veía que escribías una prueba después del código y te corregía. Veía que te saltabas la refactorización y te detenía. Era un mentor técnico que enseñaba el oficio de la entrega de software.

Luego vino el complejo industrial de la certificación. Scrum reemplazó a XP. Los “Scrum Masters” reemplazaron a los Coaches Técnicos. Decidimos que no necesitabas saber programar para “facilitar el proceso”.

Hoy en día, un “Agile Coach” es a menudo un terapeuta para la disfunción organizacional: alguien que gestiona el tablero de Jira, facilita “Retrospectivas” que resultan en cero acción, y habla de “seguridad psicológica” mientras el equipo se ahoga en deuda técnica.

El título permaneció. La competencia fue vaciada.

El incentivo para diluir

¿Por qué ocurre este cambio semántico? ¿Por qué los roles técnicos y poderosos se degradan inevitablemente en roles de soporte de habilidades blandas?

La fuerza impulsora es el conflicto entre competencia y escala.

Primero: escalar la excelencia es imposible. Es increíblemente difícil encontrar un Senior Staff Engineer que también sea un comunicador brillante y esté dispuesto a pasar la mitad de su tiempo analizando la disfunción organizacional. Es mucho más fácil contratar a un “growth hacker” junior o a un gerente no técnico y darle un título que suene autoritario.

Segundo: la competencia genera fricción. Un verdadero defensor técnico que dice “Esta arquitectura colapsará bajo carga” es un obstáculo para un gerente que solo quiere marcar el proyecto como “Verde”. Un coach que se enfoca en los “sentimientos del equipo” es mucho menos amenazante para el statu quo que uno que señala que el código es imposible de probar.

La industria elimina sistemáticamente los requisitos “duros” (técnicos) de estos roles para que sean más fáciles de cubrir y más fáciles de gestionar. Al hacerlo, elimina precisamente lo que los hacía valiosos: el mordiente.

El vacío en la sala de juntas

¿Por qué importa esto? Porque la eliminación del Defensor Interno ha dejado un vacío peligroso en nuestras organizaciones.

Cuando el “Developer Advocate” está fuera dando charlas, y el “Agile Coach” está gestionando tickets, ¿quién queda para decir la verdad a los ejecutivos?

¿Quién tiene el mandato para decirle al CEO: “Su fecha límite es una fantasía porque no tenemos pruebas automatizadas”? ¿Quién le dice al CTO: “Estamos perdiendo talento porque nuestra arquitectura heredada es inoperable”? ¿Quién aboga por el equipo de desarrollo interno contra la presión del negocio?

Este es el vacío que estamos reclamando.

Integrando el rol

Cuando usamos el término “Developer Advocate” en nuestra consultoría, estamos volviendo a la definición original y estricta.

Significa un Desarrollador Senior que:

1. Está Integrado: Se sienta con el equipo, comparte el dolor y experimenta la fricción del trabajo diario.
2. Tiene Autoridad: Reporta al liderazgo pero actúa en nombre de los ingenieros.
3. Entrega Código: No solo habla de “buenas prácticas”, sino que las demuestra en el repositorio.

Puede llamarlo “Embedded Advocacy” o “Autoridad Técnica” si lo prefiere. Pero la función no es negociable. No se puede arreglar una organización de software desde fuera. Tienes que estar en el código, sintiendo el calor, para saber qué incendio apagar primero.

No tenemos pegatinas. Pero podemos ayudarle a desplegar a producción el viernes.