Notion + Airtable: el sistema de retención que armé después de que Google me robara dos ML engineers en la misma semana

Perdí a mi primer ML engineer un martes. Luego, el segundo se fue el jueves. Ambos se unieron a Google Cloud AI. Sin embargo, no fue el salario ni las opciones lo que motivó su salida; fue que nunca supe que estaban buscando cambios hasta que ya habían firmado. Así que, construí este sistema para que no me vuelva a pasar.

Photo: ThisisEngineering on Unsplash

Este no es un artículo sobre "engagement" ni sobre pizza los viernes. Aquí, te presento la arquitectura completa de un sistema de inteligencia de retención. Integra Notion como frontend humano y Airtable como motor de datos. Lo curioso es que lo he estado utilizando desde hace ocho meses. Ha identificado cuatro situaciones críticas antes de que escalaran y ha mantenido a mi equipo de IA intacto durante dos ciclos de fundraising competitivos.

La anatomía real de la fuga de talento (y por qué el problema es de información)

El problema no es solo que tu gente se vaya. Realmente, el problema radica en que te enteras de su decisión cuando ya es demasiado tarde. La conversación real sucede tres meses antes de la renuncia: cuando empiezan a mirar LinkedIn, cuando actualizan su portfolio personal, y cuando dejan de participar en planning sessions con la misma energía.

En equipos de IA, esto es crítico porque el conocimiento está distribuido. Tu ML engineer senior no solo entrena modelos; también conoce los edge cases del pipeline de datos, las decisiones arquitectónicas que no están documentadas y los hacks que mantienen tu inferencia bajo 200ms. Cuando se va, no solo pierdes a una persona; pierdes un contexto acumulado que vale seis meses de onboarding.

Dicho esto, la solución no son más one-on-ones ni encuestas de clima. Es instrumentación: convertir señales dispersas en datos estructurados que puedas monitorear de manera sistemática. Notion se utiliza para la captura cualitativa y Airtable para el análisis cuantitativo. Son herramientas que, seguramente, ya usas conectadas de forma que expongan patrones antes de que se conviertan en renuncias.

Arquitectura del sistema: tres capas sobre dos herramientas

Photo: Compagnons on Unsplash

Capa 1: Captura en Notion (el frontend humano)

Notion funciona como interfaz de entrada porque es donde tu equipo ya convive. No estás añadiendo una herramienta nueva; en realidad, estás estructurando información que ya existe.

Creas una base de datos llamada "Talent Signals" con estas propiedades:

• Person (relación a tu database de equipo)
• Signal Type (select: Technical Growth, Career Path, External Interest, Team Dynamics, Compensation)
• Severity (select: Monitor, Caution, Critical)
• Date Detected (date)
• Context (rich text)
• Action Taken (rich text)
• Status (select: Open, Addressed, Resolved)

Cada manager, incluido tú, registra señales durante one-on-ones o al observar comportamientos. Aquí unos ejemplos reales de mi base:

• "María mencionó que le gustaría liderar el nuevo proyecto de LLMs pero no ve cómo encaja en el roadmap actual" → Career Path, Caution
• "Javier actualizó su LinkedIn por segunda vez este mes y añadió certificaciones de AWS" → External Interest, Monitor
• "Laura dejó de participar en code reviews del equipo de NLP" → Team Dynamics, Caution

La disciplina radica en registrar sin juzgar. No es un sistema de vigilancia; es un CRM de contexto humano. Si te incomoda escribir algo, es probable que sea importante.

Capa 2: Motor de análisis en Airtable (el backend de inteligencia)

Airtable recibe los datos de Notion a través de Zapier o Make; cualquiera de estas plataformas funciona. Personalmente, utilizo Make porque me resulta más económico a gran escala. Es aquí donde ocurre el análisis real.

Tu base en Airtable tiene las siguientes tablas relacionadas:

Tabla "Signals" (espejo de Notion):

• Todas las propiedades de Notion
• Campo calculado: Days_Open (TODAY - Date Detected)
• Campo calculado: Risk_Score (fórmula que explico abajo)

Tabla "People":

• Datos del empleado
• Rollup: Total_Signals (count de signals relacionadas)
• Rollup: Critical_Signals (count donde Severity = Critical)
• Rollup: Average_Risk_Score
• Lookup: Last_Signal_Date
• Campo calculado: Attrition_Risk (High/Medium/Low basado en fórmulas)

Tabla "Actions":

• Registro de acciones tomadas
• Relation a Signals y People
• Fecha, tipo de acción, resultado

La fórmula de Risk_Score que utilizo es la siguiente:

IF(
  {Severity} = "Critical", 10,
  IF({Severity} = "Caution", 5, 2)
) * 
IF(
  {Days_Open} > 30, 2,
  IF({Days_Open} > 14, 1.5, 1)
) *
IF(
  {Signal Type} = "External Interest", 1.5,
  IF({Signal Type} = "Career Path", 1.3, 1)
)

Es claro que esta fórmula es arbitraria pero funcional; puedes ajustarla según tu realidad. Lo importante es que convierte intuición en números comparables.

Capa 3: Automatización y alertas (el sistema nervioso)

En esta capa, conectas comportamientos a acciones automáticas:

En Make/Zapier:

• Cuando se crea un signal con Severity = Critical → Slack DM al CEO + email al manager directo
• Cuando Days_Open > 21 y Status = Open → Slack reminder al manager
• Cuando Attrition_Risk cambia a High → Evento en calendar del manager para "retention check-in" en 48 horas
• Cada lunes → Report automático a Slack: personas con Average_Risk_Score > 15

En Airtable Automations (nativo):

• Cuando Total_Signals para una persona > 5 en 30 días → marca record como "High Activity - Review Needed"
• Cuando una acción está en Status "Pending" por > 7 días → notificación a quien la creó

Lo crítico aquí es que las alertas deben requerir acción; no son solo para informar. Si envías un mensaje de Slack, debe incluir un link directo al record y sugerencia de próximos pasos. Nada de "FYI" pasivo.

Implementación real: de cero a producción en una semana

Día 1-2: Setup en Notion

1. Duplica tu database de equipo si no existe una central.
2. Crea la database "Talent Signals" con las propiedades descritas.
3. Añade views filtradas:
   • "Open Criticals" (Status = Open, Severity = Critical)
   • "My Team" (filtrado por manager)
   • "Last 30 Days" (Date Detected en últimos 30 días)
4. Configura permisos: los managers solo ven su equipo; liderazgo ve todo.

Template de signal que funciona:

Person: [Relation]
Signal Type: Career Path
Severity: Caution
Context:
En 1:1 del 15/01, mencionó interés en roles de research más que engineering.
Específicamente preguntó sobre papers que publicamos y si hay oportunidad de
coautorizar. Actualmente está en feature development que no tiene componente
de investigación.

Action Taken:
[Vacío inicialmente - se llena después]

Día 3-4: Setup en Airtable

1. Crea una nueva base llamada "Talent Intelligence".
2. Importa un CSV inicial desde Notion (Export → CSV) o usa la API de Notion si tienes un developer.
3. Construye las tablas relacionadas (Signals, People, Actions).
4. Configura las fórmulas calculadas descritas anteriormente.
5. Crea views críticas:
   • "High Risk Dashboard" (Attrition_Risk = High)
   • "Aging Signals" (Days_Open > 21, Status = Open)
   • "Action Pipeline" (Status = Pending)

La fórmula de Attrition_Risk que utilizo:

IF(
  AND(
    {Average_Risk_Score} > 20,
    {Critical_Signals} > 0
  ),
  "High",
  IF(
    OR(
      {Average_Risk_Score} > 12,
      {Total_Signals} > 4
    ),
    "Medium",
    "Low"
  )
)

Día 5: Automatizaciones

1. En Make/Zapier: conecta Notion → Airtable (trigger: nuevo record en Notion, action: crear record en Airtable con mapping de campos).
2. Configura las alertas en Slack (usa Slack API, no email).
3. Testea con datos ficticios: crea signals de prueba y verifica que todo el pipeline funcione.

Snippet de Make automation (conceptual, adapta a tu setup):

Trigger: Notion - New Database Item
Filter: Severity = "Critical"
Action 1: Airtable - Create Record
Action 2: Slack - Send Direct Message
  Channel: @founder
  Message: "🚨 Critical talent signal detected for {{Person}}
  Type: {{Signal Type}}
  Context: {{Context}}
  View in Airtable: [link]"

Día 6-7: Rollout y calibración

No lo implementes en frío. Reúne a tu equipo de managers y:

1. Explica el sistema (transparencia total).
2. Haz training: qué registrar, qué no, cómo calificar severity.
3. Registra signals retrospectivos de los últimos 30 días (esto calibra el sistema).
4. Revisa juntos los primeros 10 signals para alinear criterios.

Lo que más me sorprende es que lo más importante es comunicar que esto no es vigilancia ni persecución. Es el equivalente a tener un CRM para clientes, pero para tu equipo. No actúas sobre cada signal; actúas sobre patrones.

Tres patrones que este sistema detecta (y que tú no verías manualmente)

Patrón 1: El "silent checkout"

Tu ML engineer sigue entregando, asiste a meetings y responde en Slack. Sin embargo, deja de sugerir mejoras y no participa en decisiones técnicas estratégicas. Esto puede parecer sutil, pero es una señal de alarma.

El sistema lo detecta cuando acumula 3-4 signals de tipo "Team Dynamics" con severity "Monitor" en 45 días. Individualmente, son ruido, pero juntos forman un patrón.

En mi caso, Carlos tuvo una excelente performance review en septiembre. Luego, en diciembre, el sistema mostraba 5 signals en 60 días. Investigué. Resultó que había aplicado internamente a un rol de research del que nunca supimos, lo rechazaron por timing, y nadie le dio feedback. Lo resolvimos en dos conversaciones: movimos su scope hacia investigación aplicada y coautorizó un paper en ICLR 2026. Afortunadamente, sigue en el equipo.

Patrón 2: El "compensation drift"

Alguien menciona salarios de la competencia una vez. Luego pregunta sobre equity refresh. Semanas después, comenta que un ex colega está en OpenAI.

El sistema correlaciona signals de "Compensation" con "External Interest". Cuando ambos aparecen en ventanas de 30 días, el Risk_Score se dispara porque la fórmula multiplica factores.

Un caso real es Ana. Recibió tres signals en 25 días (dos de compensation, uno de external interest). Activó una alerta. Gracias a una conversación proactiva, descubrimos que estaba considerando ofertas porque su equity del inicio ya no parecía competitivo tras nuestra Serie B. Hicimos un refresh anticipado (lo teníamos presupuestado para Q2, lo adelantamos). Y, lo más importante, se quedó.

Patrón 3: El "growth ceiling"

Tu senior engineer se siente estancado, pero no lo dice explícitamente. Pregunta sobre el roadmap, sobre nuevos proyectos y sobre oportunidades de mentorear. Señales positivas, ¿no?

El sistema detecta que son signals de "Career Path" repetidos sin acciones tomadas. Si Days_Open crece y no hay entries en la tabla de Actions, es claro que algo está roto.

Miguel tuvo 6 signals de Career Path en tres meses, todas con Severity "Monitor" o "Caution". El dashboard mostró que nunca las habíamos abordado formalmente. Aunque no era urgente individualmente, juntas gritaban "quiero crecer y nadie me está ayudando". Creamos un IC track explícito para senior a staff engineer. Afortunadamente, sigue aquí.

Lo que este sistema NO hace (y por qué eso es bueno)

Primero, no predice el futuro. No te dice "X se va en 45 días". Te dice "X está mostrando patrones que históricamente preceden decisiones de salida". La diferencia es clave: actúas con contexto, no con paranoia.

Segundo, no reemplaza conversaciones. El sistema te indica cuándo hablar y sobre qué. Sin embargo, la conversación la sigues teniendo tú. Automatizar la respuesta ("aquí está tu equity refresh automático") puede hacer que pierdas la humanidad que retiene a la gente.

Por último, no es un panóptico. Los signals que registras deben ser observables en conversaciones normales o comportamientos públicos (commits, participación en meetings, menciones en 1:1s). Si monitoreas actividad privada o infieres intenciones sin base, el sistema se vuelve tóxico.

Mantenimiento: lo que hago cada...