El feedback es más potente que tu propia inteligencia

Don't ever make the mistake of thinking that you can design something better than what you get from ruthless massively parallel trial-and-error with a feedback cycle. That's giving your intelligence much too much credit.

— Linus Torvalds

Torvalds escribió esto discutiendo en la lista de correo del kernel de Linux, y la frase tiene la brusquedad que se le suele perdonar a quien ha sostenido durante décadas uno de los artefactos más complejos jamás construidos. Pero no es una boutade. Es una descripción bastante exacta de cómo funciona el material con el que trabajamos, y merece que nos detengamos en la parte que suele pasar desapercibida: no dice que diseñar sea inútil. Dice que creer que tu diseño puede superar a un bucle de prueba y error masivamente paralelo es un error de cálculo sobre ti mismo.

Lo que un diseño puede saber

Un diseño previo solo puede contener lo que sabías antes de empezar. Esa es su limitación y no es corregible con más talento ni con más tiempo de planificación. Cuando proyectas una solución de producto digital, estás trabajando con información que en su mayor parte todavía no existe: no sabes cómo se va a comportar el sistema sobre el que construyes, no sabes qué hará la gente con lo que le entregues, y no sabes qué otros usos —a menudo los que acaban importando— aparecerán en el margen.

La tentación es tratar esa ignorancia como un déficit temporal: si investigamos un poco más, si documentamos mejor, si hacemos un diseño más detallado, la despejaremos antes de gastar dinero en construir. Y hay una parte de verdad ahí, porque hay ignorancia que sí se despeja leyendo. Pero la mayor parte de lo que necesitas saber en producto digital pertenece a otra categoría: solo se revela cuando algo se pone en juego. No es información que esté esperando a que la busques. Es información que se produce.

Esto explica una experiencia que cualquiera que haya dirigido producto reconoce: el momento en el que un equipo empieza a construir es también el momento en el que aparecen las preguntas que deberían haberse hecho antes. No aparecieron antes porque no podían aparecer antes.

El bucle como órgano de inteligencia

La frase de Torvalds sitúa la inteligencia en un lugar incómodo. No está en la persona que decide, ni en el documento, ni en la calidad del razonamiento. Está en el circuito: en la velocidad con la que una consecuencia vuelve hasta quien la provocó, y en la cantidad de intentos que ese circuito puede procesar.

Es una idea vieja y bastante bien establecida fuera de nuestro oficio. La cibernética la formuló como la condición mínima de cualquier sistema capaz de gobernarse: sin retroalimentación no hay corrección, y sin corrección no hay dirección, solo trayectoria. Deming la llevó a la fábrica insistiendo en que la calidad no se inspecciona al final, se construye dentro del proceso, y que un proceso sin medición interna es un proceso ciego por diseño. La biología evolutiva la describe como un algoritmo que produce diseños extraordinariamente buenos sin ningún diseñador, únicamente a base de variación, selección y repetición durante mucho tiempo.

Lo que la industria del software añadió a esa tradición fue una constatación práctica: el coste de un intento puede reducirse casi a cero. Ese es el hecho estructural que hace que la afirmación de Torvalds sea especialmente cierta aquí y no en la construcción de un puente. Si probar es caro, tienes que pensar mucho antes de probar. Si probar es barato, pensar mucho antes de probar es una forma sofisticada de desperdicio.

Por qué las organizaciones alargan sus bucles

Si esto es tan evidente, la pregunta interesante no es cómo acortar el ciclo de feedback, sino por qué las organizaciones lo alargan sistemáticamente. Y lo alargan, con gran esfuerzo y con buenas intenciones.

Lo alargan cada vez que introducen un paso donde la información se agrega antes de viajar. Un informe semanal es más largo que un dato; un comité es más lento que una conversación; un resumen ejecutivo es más limpio y menos útil que la queja original. Cada capa de agregación mejora la legibilidad y degrada la señal, porque lo primero que se elimina al resumir es precisamente lo anómalo, y lo anómalo es donde vive la información nueva.

Lo alargan también cada vez que separan a quien decide de quien recibe el resultado. Un product manager que no ve el ticket de soporte, un diseñador que no ve la sesión de uso, un directivo que solo ve el gráfico agregado del trimestre: en todos esos casos el bucle sigue existiendo, pero se ha vuelto tan largo que la consecuencia llega cuando la decisión ya ha sido sustituida por otras tres.

Y lo alargan, sobre todo, por una razón que no se dice en voz alta: un ciclo de feedback corto expone errores rápido. Es una máquina de producir evidencia de que alguien se equivocó, y en muchas culturas de management eso se administra como un riesgo reputacional y no como un activo. Una organización que castiga el error no puede tener un bucle corto, por muchas herramientas que compre. Elegirá siempre, y con argumentos razonables, el camino donde la equivocación tarda más en ser visible.

Lo que esto pide a quien dirige producto

La consecuencia operativa es menos glamurosa que la frase. Consiste en tratar la longitud del bucle como una variable de diseño organizativo, tan importante como la arquitectura del producto. Cuánto tarda una consecuencia en volver. Cuántos intentos caben en un mes. Cuántas manos toca un dato antes de llegar a quien puede hacer algo con él. Cuánto cuesta, en tiempo y en reputación, decir en voz alta que aquello no funcionó.

Y consiste, también, en aceptar una cierta modestia sobre el propio criterio. No la modestia retórica de decir que no lo sabemos todo, sino la operativa: montar los procesos como si tu mejor conjetura fuera a ser refutada, porque estadísticamente lo será. Torvalds no está pidiendo que dejes de pensar. Está pidiendo que dejes de apostar tu proyecto a que has pensado suficiente.

¿Cuánto tarda en tu organización una mala idea en dejar de parecer buena?