¿Te falta documentación?

¿Cuántas veces hemos dicho (o escuchado) “esto tiene que estar documentado”?

En nuestros equipos, invertimos horas en Confluence, en READMEs y en manuales de onboarding. Creemos que con eso, el conocimiento está a salvo.

Pero seamos honestos: ¿cuántas veces se ha ido un senior del equipo y, a pesar de toda esa documentación, el conocimiento crítico se fue con él?

Esa sensación de seguridad que da la documentación es, en gran parte, una ilusión.

Recientemente leí un artículo excelente en la newsletter de ManagerPro (https://newsletter.managerpro.team/p/lo-que-los-manuales-no-pueden-ensenar) que pone nombre a este problema. Diferencia entre dos tipos de conocimiento:

1. Conocimiento Explícito: Lo que podemos escribir. Son los manuales, los diagramas de arquitectura, los procesos.
2. Conocimiento Tácito: Lo que no se puede escribir. Es la “intuición” de ese devops para saber qué log mirar en una crisis. Es la habilidad de un tech lead para navegar la arquitectura legacy o gestionar la presión de una caída en producción.

El problema es que el conocimiento explícito (el manual) siempre descansa sobre el tácito (la experiencia).

Como líderes técnicos, nuestro mayor desafío no es solo crear documentación, sino transmitir ese conocimiento tácito. Este no se aprende leyendo; se aprende por inmersión.

El artículo propone 5 formas prácticas de hacerlo, muy aplicables a nuestros equipos:

1️⃣ Shadowing Consciente: Más que solo pair programming. Es observar activamente a un experto tomando decisiones en tiempo real (ej. durante un debug complejo).

2️⃣ Hacer Juntos: Diseñar esa nueva feature en grupo, no solo asignarla. La práctica y el feedback son inmediatos.

3️⃣ El Poder de las Historias: Un buen post-mortem no es un documento frío. Es una historia que explica el por qué de las decisiones tomadas bajo presión.

4️⃣ Participar en Reuniones Clave: Invitar a ingenieros mid-level a las reuniones de arquitectura o de definición de producto. Dejar que absorban cómo se negocia y se toman decisiones estratégicas.

5️⃣ Comunidades de Práctica (Guilds): Crear espacios (ej. Guilds de Frontend, DevOps o QA) donde la gente comparta problemas y soluciones de forma natural.

En resumen, los manuales son necesarios, pero no suficientes. La verdadera transferencia de conocimiento es un proceso activo y social.

¿Qué estrategias usáis vosotros para asegurar que el conocimiento tácito se comparte y no se pierde?