Cada vez que alguien se va, se pierde información: cómo evitarlo
Si solo una persona sabe cómo funciona algo y se va, ¿qué pasa? Cómo evitar que la información se vaya con las personas.
Analizar con IA — elige tu favorita
Obtén un resumen del artículo al instante
El dev senior que llevaba tres años en la empresa anuncia que se va. Dos semanas de preaviso. Un "gracias por todo" en Slack y a otra cosa.
Y entonces empieza el problema de verdad: nadie sabe cómo funciona el sistema de pagos. Él lo montó solo, hace dos años, cuando la startup tenía seis personas. Lo optimizó en tres sprints distintos. Lo parcheó cuando hubo un incidente en producción a las 2 de la mañana. Todo ese conocimiento vive en su cabeza. Y en dos semanas se va con él.
Esto no es un caso extremo. Es lo que pasa en la mayoría de startups entre 8 y 30 personas cuando alguien se va.
Lo que vas a aprender en este artículo:
Qué es el bus factor y cómo calcularlo en tu startup sin necesitar ninguna herramienta
Por qué la pérdida de conocimiento es uno de los riesgos operativos más subestimados en early-stage
Tres soluciones concretas y aplicables (documentación, cross-training y offboarding estructurado) para que la próxima salida no te paralice
Cómo priorizar: no puedes proteger todo, pero sí puedes saber qué proteger primero
El problema no es que la gente se vaya
La rotación existe. Siempre ha existido. Según datos del INE, la tasa de rotación en el sector tecnológico español supera el 25% anual en perfiles junior y mid, y no baja del 15% ni en perfiles senior. No puedes retener a todo el mundo. No es lo que te estoy pidiendo.
Lo que sí puedes controlar es cuánto conocimiento crítico se concentra en personas individuales. Y cuánto de ese conocimiento desaparece cuando esas personas se marchan.
Hay dos tipos de conocimiento en una startup: el explícito y el tácito. El explícito es el que ya está documentado en algún sitio, aunque sea mal. El tácito es el que está en la cabeza de alguien: por qué se tomó cierta decisión, cómo funciona algo que nadie más ha tocado, qué cliente necesita que le llamen antes de renovar.
El conocimiento tácito no se transfiere solo. No aparece en el contrato de offboarding. No se migra automáticamente cuando le das de baja en el correo corporativo.
Y en las startups early-stage, la proporción de conocimiento tácito es enorme. Porque el ritmo es rápido, la documentación siempre "se hará después" y los procesos los ejecuta siempre la misma persona porque "es el que sabe".
"Cada persona que se va sin un offboarding estructurado es deuda operativa que pagas con tiempo perdido, errores y decisiones equivocadas durante meses."
El bus factor: el indicador que nadie mide
El bus factor (también conocido como truck factor o lottery factor) es un concepto que viene del mundo del desarrollo de software, pero aplica a cualquier función de una startup.
La definición es simple: el bus factor de un proceso o sistema es el número mínimo de personas que tendrían que "desaparecer" para que ese proceso dejase de funcionar o ese conocimiento quedase inaccesible.
Si el sistema de pagos solo lo entiende una persona, su bus factor es 1. Si las negociaciones con tu distribuidor principal las lleva solo el founder, el bus factor de ese proceso es 1. Si solo una persona sabe cómo sacar el informe de MRR del CRM, es 1.
Un bus factor de 1 significa que una sola baja, una baja médica larga o incluso unas vacaciones bien merecidas pueden parar parte de tu operación.
La pregunta no es teórica. Es operativa.
Cómo calcular tu bus factor ahora mismo
No necesitas ninguna herramienta. Necesitas 45 minutos y honestidad.
Haz una lista de los 10-15 procesos, sistemas o áreas de conocimiento más críticos de tu startup. No los que están mejor documentados: los que son más importantes para que tu startup funcione. Puedes estructurarlo así:
1. Sistemas técnicos: infraestructura, integraciones, accesos a producción, deploys.
2. Procesos de negocio críticos: ciclo de ventas, renovaciones, gestión de facturación, relación con proveedores clave.
3. Conocimiento de clientes: qué sabe alguien de un cliente que no está en el CRM.
4. Procesos operativos internos: cómo se incorpora a un nuevo empleado, cómo se cierra el mes contable, cómo se gestiona una incidencia.
Para cada elemento de la lista, hazte dos preguntas:
¿Cuántas personas de tu equipo pueden ejecutar esto de forma autónoma hoy?
Si la persona que lo hace habitualmente no estuviese disponible mañana, ¿qué pasaría?
Si la respuesta a la primera pregunta es "una" y la respuesta a la segunda es "un problema serio", ese proceso tiene bus factor 1. Márcalo.
Cuando termines, probablemente tengas entre 5 y 12 procesos con bus factor 1. Ese es tu mapa de riesgo. Ese es lo que hay que proteger.
Las tres soluciones. Por este orden.
No te voy a decir que documentes todo. No es realista ni útil. Lo que sí tiene sentido es atacar el problema en tres frentes complementarios, empezando siempre por lo más crítico.
1. Documentación operativa mínima (pero de verdad)
Documentar no es escribir una novela. En una startup early-stage, un buen proceso documentado cabe en una página de Notion y lo puede ejecutar alguien que nunca lo ha hecho antes en menos de 20 minutos.
El criterio para decidir qué documentar primero es simple: todo lo que tiene bus factor 1 y un impacto alto si falla.
El formato mínimo que funciona:
Qué hace este proceso y por qué existe
Cuándo se ejecuta (desencadenante o frecuencia)
Pasos, en orden, con suficiente detalle para que alguien nuevo lo siga
Qué herramientas o accesos necesita
Qué puede salir mal y cómo manejarlo
Quién es el responsable actual y quién es el backup
No es documentación para que el auditor la revise. Es documentación para que el equipo funcione cuando alguien no está.
Si quieres profundizar en cómo montar un sistema de gestión del conocimiento que tu equipo realmente use, tienes el enfoque completo en este artículo sobre gestión del conocimiento interno en startups sin que todo quede perdido en Slack.
2. Cross-training: más de una persona que sepa hacer cada cosa crítica
Documentar es necesario pero no suficiente. Un documento que nadie ha leído ni practicado no protege nada.
El cross-training (o formación cruzada) es el proceso de asegurarte de que al menos dos personas en tu equipo pueden ejecutar cada proceso crítico. No a nivel experto, pero sí a nivel funcional.
En startups pequeñas, esto no significa duplicar trabajo. Significa diseñar intencionadamente las semanas de trabajo para que las personas críticas se acompañen en sus procesos.
Algunas formas concretas de hacerlo:
Pair working: dos personas ejecutan juntas un proceso que normalmente hace solo una. No en paralelo: una hace, la otra observa, pregunta y toma notas.
Rotación de responsabilidades: en tareas recurrentes (como cerrar el reporte mensual), rotar quién lo hace cada mes, con la primera persona como apoyo.
Sesiones de transferencia: cuando alguien identifica que tiene conocimiento que nadie más tiene, dedica 30-60 minutos a transferirlo explícitamente, con alguien del equipo tomando notas en tiempo real.
El obstáculo habitual es el tiempo. "No tenemos tiempo para hacer esto ahora." Lo entiendo. Pero el tiempo que no inviertes ahora lo invertirás cuadruplicado cuando alguien se vaya sin previo aviso.
3. Offboarding estructurado: la última oportunidad de recuperar el conocimiento
El offboarding es la parte más negligida de todo el ciclo de vida de un empleado en startups. Se hace una entrevista de salida si hay suerte, se revocan los accesos y ya.
Un offboarding estructurado es una de las inversiones de tiempo con mayor retorno operativo que puedes hacer, especialmente cuando se va alguien con conocimiento crítico.
El proceso que recomendamos desde Ebägurin tiene cuatro bloques:
Bloque 1: Inventario de conocimiento (días 1-3 tras el anuncio) La persona saliente hace un listado de todo lo que sabe que nadie más sabe. Procesos, contactos, decisiones pasadas, configuraciones de sistemas, conversaciones con clientes que no están en el CRM. Sin filtros. Todo lo que se le ocurra.
Bloque 2: Sesiones de transferencia (días 4-10) Para cada elemento del inventario que sea crítico, se organiza una sesión específica de transferencia con la persona o personas que van a asumir ese conocimiento. No es una reunión de despedida: es trabajo.
Bloque 3: Documentación de lo no documentado (paralelo) Mientras suceden las sesiones, alguien (puede ser la propia persona saliente, puede ser quien recibe el conocimiento) documenta en tiempo real.
Bloque 4: Revisión de accesos y dependencias (últimos días) No solo revocar accesos. Auditar: ¿qué sistemas dependen de las credenciales de esta persona? ¿Hay algo que solo funciona porque lo configuró así? ¿Hay contratos, suscripciones o cuentas a su nombre que hay que transferir?
El offboarding también conecta directamente con el onboarding: los materiales generados en una salida son la base del proceso de incorporación de quien venga después. Si tienes un proceso de onboarding de nuevos empleados bien montado, el offboarding lo alimenta y lo mejora.
Qué priorizar si no puedes hacer todo a la vez
No puedes hacer todo esto en paralelo sin que algo más sufra. La realidad de una startup de 12 personas es que el tiempo es el recurso más escaso.
La lógica de priorización es esta:
Prioridad máxima: procesos con bus factor 1 cuyo fallo paralizaría el negocio o dañaría directamente a clientes. Si esto falla, el daño es inmediato y visible. Documenta esto esta semana.
Prioridad alta: procesos con bus factor 1 que generarían caos interno importante pero no dañarían clientes a corto plazo. Documenta esto este mes.
Prioridad media: procesos con bus factor 2 (dos personas lo saben) pero donde esas dos personas podrían irse a la vez o en poco tiempo. Aquí el cross-training es la palanca.
Diferido: todo lo demás. Existen, son procesos reales, pero el riesgo de pérdida de conocimiento es bajo porque hay redundancia o el impacto es manejable.
"Proteger el conocimiento crítico de tu startup no es un proyecto de documentación masiva. Es una decisión de qué no puedes permitirte perder."
Esto es parte de lo que cubre un diagnóstico operativo bien hecho: mapear exactamente dónde están las dependencias críticas de personas, cuáles son los procesos con bus factor 1 y qué hay que proteger primero. Si quieres ver cómo se hace ese trabajo completo, el artículo sobre operaciones para startups en fase early-stage cubre el marco general.
Lo que no funciona (y por qué)
Hay tres respuestas habituales al problema de la pérdida de conocimiento que no funcionan:
"Vamos a documentarlo todo." Sin criterio de priorización, esto genera cientos de páginas que nadie lee y un falso sentido de seguridad. La documentación tiene que ser útil antes de ser exhaustiva.
"Contratamos a alguien que aprenda rápido." Una nueva contratación tarda entre 3 y 6 meses en ser autónoma en un rol. Si el conocimiento se fue con quien salió, el nuevo empleado aprende sobre la marcha, con errores que pagáis todos.
"Ya lo haremos cuando alguien avise." Dos semanas de preaviso no son suficientes para transferir años de conocimiento tácito. Para cuando llega el aviso, ya es tarde para hacerlo bien.
Preguntas frecuentes
¿Cuánto tiempo se necesita para hacer un offboarding estructurado?
Un offboarding estructurado para alguien con conocimiento crítico requiere entre 5 y 8 días de trabajo activo distribuidos en las dos semanas de preaviso habituales. Incluye el inventario de conocimiento, las sesiones de transferencia y la revisión de accesos y dependencias. Para perfiles sin conocimiento crítico concentrado, 2-3 días son suficientes.
¿Cómo sé qué procesos tienen bus factor 1 en mi startup?
Haz una lista de tus 10-15 procesos más críticos y pregúntate: si la persona que lo ejecuta no estuviese disponible mañana, ¿tendría alguien más en el equipo suficiente conocimiento para ejecutarlo de forma autónoma? Si la respuesta es no, ese proceso tiene bus factor 1. En la mayoría de startups de 10-20 personas, entre 5 y 12 procesos caen en esta categoría.
¿Tiene sentido documentar procesos que cambian constantemente en una startup?
Sí, pero documentas el proceso actual, no el proceso perfecto. Un proceso documentado aunque cambie en dos meses es mejor que un proceso no documentado que existe solo en la cabeza de alguien. La clave es documentar el flujo y las decisiones clave, no el detalle de cada herramienta, que es lo que cambia más rápido.
¿El cross-training no reduce la productividad individual?
A corto plazo, sí hay un coste: el tiempo de las sesiones de pair working o rotación de responsabilidades. A medio plazo, el coste es negativo porque el equipo gana redundancia, la calidad de los procesos mejora al tener más de una perspectiva y se reduce el riesgo de paralización por baja o salida. En startups donde lo hemos implementado, el tiempo invertido en cross-training se recupera en menos de dos meses.
¿Qué herramienta es mejor para centralizar la documentación operativa?
No hay una respuesta universal. En startups de menos de 15 personas, Notion cubre el 90% de los casos con el plan gratuito o Team (8€/usuario/mes). Es suficiente si el equipo lo adopta de verdad. El problema no suele ser la herramienta: es que nadie tiene responsabilidad clara de mantener la documentación actualizada. Asigna un responsable antes de elegir la herramienta.
¿Qué pasa si la persona que se va no quiere colaborar en el offboarding?
En la mayoría de los casos, la resistencia viene de no tener un proceso claro ni un tiempo asignado, no de mala voluntad. Si defines desde el principio que el offboarding es parte del contrato y del proceso de salida, y lo tratas como trabajo remunerado dentro del preaviso, la colaboración es la norma. Si hay conflicto activo, la prioridad es proteger los accesos críticos y hacer inventario de lo que se puede rescatar sin la colaboración directa.
¿Cuándo es demasiado tarde para empezar a reducir el bus factor?
No lo es nunca, pero el mejor momento es antes de que nadie haya anunciado que se va. Si ya tienes a alguien en proceso de salida, empieza con el inventario de conocimiento el primer día tras el anuncio. Si nadie se ha ido todavía, el momento de mapear el bus factor es ahora, no cuando el problema se vuelva urgente.
La próxima vez que alguien de tu equipo anuncie que se va, la pregunta no debería ser "¿cómo lo vamos a sustituir?". Debería ser "¿cuánto conocimiento crítico se va con esa persona y cuánto tiempo tenemos para recuperarlo?"
Si la respuesta a la segunda pregunta te genera intranquilidad, probablemente ya sabes qué hay que hacer.
¿Quieres saber exactamente cuáles son los procesos con bus factor 1 en tu startup antes de que el problema sea urgente? En el Diagnóstico Express de Ebägurin mapeamos en 1-2 semanas dónde están tus dependencias críticas de personas, qué conocimiento está en riesgo y qué hay que proteger primero. Hablemos sobre tu startup →