Escribir como sistema de liderazgo

Hubo una época en la que gestionaba un equipo de 25 personas de ingeniería casi completamente a través de reuniones y hilos de Slack. Las cosas avanzaban. Las decisiones se tomaban. Pero tres meses después, nadie podía explicar por qué habíamos construido ciertas cosas como las construimos. Yo incluido.

Ese fue el momento en que entendí que escribir no es un estilo de comunicación. Es un sistema de memoria para una organización.

El costo real de no escribir

Cuando las decisiones viven solo en tu cabeza o en una grabación de reunión que nadie ve, lo pagas después. Lo pagas en contexto re-explicado cada vez que alguien nuevo entra al equipo. Lo pagas en debates que rehacen los mismos tradeoffs ya resueltos seis meses atrás. Lo pagas en features construidos sobre supuestos que nadie cuestionó porque nunca se escribieron.

El efecto acumulado es brutal. Un equipo que no escribe acumula deuda invisible, no en el código sino en el entendimiento compartido.

Qué cambió cuando empecé a escribir más

Empecé a exigir propuestas escritas para todo lo que tomaría más de un sprint construir. No documentos largos. Una página, a veces menos. Solo lo suficiente para responder: ¿qué problema estamos resolviendo, por qué ahora, y cómo se ve el éxito?

Dos cosas sucedieron casi de inmediato.

Primero, aproximadamente un tercio de las propuestas se derrumbaron durante el proceso de escritura. No porque fueran malas ideas, sino porque escribir obligaba al autor a enfrentarse a las brechas que había pasado por alto en la conversación. El argumento que sonó sólido en una reunión no se sostenía en papel. Ese es el primer filtro, y es gratis.

Segundo, las reuniones que siguieron fueron más cortas y precisas. La gente llegaba habiendo leído el documento. La conversación pasaba de “déjame explicarte lo que quiero construir” a “no estoy de acuerdo con el supuesto tres.” Eso es un nivel de discusión completamente diferente.

Tres documentos que mantengo activos

Todo equipo con el que trabajo termina usando alguna versión de estos tres:

Memo de intención de producto. Una página. Qué estamos construyendo, para quién, y por qué importa ahora. No es un PRD. Sin user stories. Solo el argumento de por qué esto vale el tiempo del equipo. Lo actualizo a medida que cambia cómo entendemos el problema.

Registro de decisiones técnicas. No un sistema completo de ADRs, solo un doc corriente donde registramos las decisiones importantes. La elección de arquitectura que hicimos bajo presión. El proveedor que elegimos y por qué. La cosa que decidimos deliberadamente no construir. El tú del futuro lo agradecerá.

Notas semanales de entrega. De tres a cinco líneas por equipo. Qué salió, qué está bloqueado, qué cambió. Las empecé en parte para visibilidad de stakeholders, pero el principal beneficiario fue el equipo mismo. Escribir lo que entregaste cada semana genera una rendición de cuentas difícil de fingir.

Lo que nadie te dice

Escribir no sale natural en culturas de ingeniería que recompensan la velocidad y el shipping. Siempre hay una razón para saltarse el documento: el sprint está apretado, todos ya saben el contexto, lo documentamos después.

Después nunca llega.

Los equipos que operan con calidad consistente escriben las cosas. No porque tengan más tiempo, sino porque aprendieron que escribir es cómo los equipos rápidos se mantienen rápidos. Elimina la mayor fuente de fricción: la intención poco clara.

Un equipo que puede explicar sus decisiones por escrito puede ejecutarlas. Esa correlación se ha mantenido verdadera para mí en cada contexto en el que he trabajado.