El coste oculto del conocimiento tribal

El conocimiento tribal es la comprensión informal y no documentada de cómo funcionan las cosas que existe únicamente en la cabeza de las personas que llevan el tiempo suficiente para adquirirlo. Por qué el sistema de facturación gestiona los reembolsos de la forma en que lo hace. Con quién hablar sobre la API heredada. Qué ocurrió durante el incidente de marzo que dio forma a la configuración actual de alertas. Qué valores de configuración son estructurales y cuáles se pueden cambiar de forma segura.

En un equipo pequeño, el conocimiento tribal es eficiente. Todos se conocen, el contexto se comparte por proximidad y conversación diaria, y la sobrecarga de la documentación formal en realidad ralentizaría las cosas más de lo que ayuda. La tribu es lo suficientemente pequeña como para que el conocimiento circule de forma natural.

El problema es que el conocimiento tribal no escala, y el punto en el que deja de escalar suele llegar antes de que el equipo se dé cuenta.

La ruptura de escala

La ruptura suele ocurrir entre los diez y los veinte ingenieros. Por debajo de diez, la mayoría de los ingenieros tienen un modelo mental razonable de todo el sistema y saben a quién preguntar sobre cualquier componente dado. Por encima de veinte, el sistema ha crecido más allá de la comprensión de cualquier individuo, el equipo incluye a personas que se han incorporado hace poco y no tienen el contexto histórico, y los ingenieros que poseen el conocimiento tribal están cada vez más divididos entre su propio trabajo y la creciente carga de responder preguntas.

Los síntomas son reconocibles: reuniones que existen principalmente para compartir contexto más que para tomar decisiones. Hilos de Slack donde la mitad de la discusión consiste en reconstruir los antecedentes antes de que se pueda abordar la pregunta real. Procesos de incorporación que tardan meses porque el nuevo empleado tiene que absorber el contexto por ósmosis en lugar de leyendo. Decisiones que se vuelven a debatir porque nadie recuerda (o el equipo actual nunca supo) que esa misma pregunta ya se debatió y se resolvió hace seis meses.

Cada uno de estos síntomas tiene un coste, y los costes se acumulan en algo mucho mayor de lo que la mayoría de los equipos reconocen porque cada caso individual parece menor.

Por qué bloquea el trabajo asíncrono

El conocimiento tribal es fundamentalmente incompatible con el trabajo asíncrono. Cuando el contexto necesario para tomar una decisión vive en la cabeza de alguien, la decisión solo puede ocurrir cuando esa persona está disponible para compartirlo. Esto obliga a que todo pase a canales síncronos: reuniones, conversaciones en tiempo real por Slack, toques en el hombro.

En un equipo distribuido o híbrido, la incompatibilidad es aún más aguda. El ingeniero que está en una zona horaria diferente y necesita contexto sobre el sistema de pagos tiene que esperar hasta que el ingeniero que posee ese contexto esté conectado. La decisión que podría haberse tomado de forma asíncrona a partir de un documento se bloquea en cambio a la espera de un hueco en el calendario.

Convertir el conocimiento tribal en documentación indexable desbloquea la toma de decisiones asíncrona porque el contexto está disponible para cualquiera, en cualquier momento, sin requerir la presencia del poseedor del conocimiento. Un ingeniero que puede leer el registro de decisiones de por qué el sistema de pagos está estructurado de la forma en que lo está no necesita programar una reunión para averiguarlo.

El problema de la conversión

El desafío de convertir el conocimiento tribal en documentación es que las personas que lo poseen suelen ser las más ocupadas del equipo: los ingenieros sénior y los primeros empleados, cuyo tiempo es el más valioso y el que más comprometido está. Pedirles que se sienten y escriban todo lo que saben es pedirles que asuman una tarea grande e ilimitada además de su trabajo actual.

La documentación de auto-escritura aborda esto capturando el conocimiento tribal de los canales donde ya se está compartiendo. Cuando un ingeniero sénior explica una decisión de diseño en Slack, esa explicación se captura y se estructura. Cuando una reunión cubre la historia detrás de la arquitectura actual de un sistema, la discusión se convierte en parte de la documentación. Cuando la descripción de una PR explica por qué se eligió un enfoque particular, el razonamiento se preserva junto con el código.

El ingeniero sénior no escribe documentos. Hace su trabajo normal y los documentos surgen de él.

Preguntas frecuentes

¿Cómo identificamos nuestro conocimiento tribal? Busque preguntas que se hagan repetidamente y que solo puedan ser respondidas por personas específicas. Busque hilos de Slack donde los primeros mensajes sirvan para establecer el contexto antes de la pregunta real. Busque reuniones que existan para compartir información en lugar de para tomar decisiones. Todos estos son síntomas de conocimiento que debería estar documentado pero no lo está.

¿Cuál es el conocimiento tribal más valioso para capturar primero? Decisiones de arquitectura del sistema (por qué las cosas se construyen como se construyen), historial de incidentes (qué falló y qué se cambió como resultado) y límites de integración (cómo se comunican los diferentes servicios y por qué). Estas son las áreas donde la falta de contexto provoca los errores más costosos.

¿Se puede eliminar por completo el conocimiento tribal? No, y tampoco se debería. Algunos conocimientos son inherentemente contextuales y se desarrollan a través de la experiencia de formas que la documentación no puede capturar por completo. El objetivo es reducir la proporción de conocimiento operativo crítico que existe únicamente en la cabeza de las personas, no eliminar por completo la transferencia informal de conocimiento.

Lectura relacionada: El factor autobús, Deuda de documentación, Por qué importan los documentos de ingeniería. Páginas relacionadas: Documentos auto-escritos, Retención del conocimiento, Para equipos de ingeniería.