Curiosidad, escritura y los feedback loops
El tiempo que dedico a escribir ha crecido exponencialmente y, desde entonces, mi curiosidad por entender lo que pasa a mi alrededor se ha disparado. Pero escribir aplaca mi curiosidad, como cuando después de cenar te apetece algo dulce y decides comer un trocito de chocolate negro: te calma el antojo, aunque al mismo tiempo despierta el deseo de otro más. Entras en un loop: escribo sobre lo que quiero entender mejor. Y cuanto más escribo, más descubro que queda mucho por descubrir, lo que me genera aún más curiosidad por profundizar.
La semana pasada discutí con un amigo sobre los feedback loops, y el coste oculto de externalizar funciones en startups. Los costes más comunes son fáciles de reconocer: la fricción de coordinación, la pérdida de velocidad de respuesta o la dificultad de transmitir cultura. Sobrevolamos rápidamente esos puntos, hasta que un ejemplo concreto sobre el despacho que les apoya en temas legales y compliance nos dejó en reflexionando en silencio durante veinte segundos, al estilo de Elon Musk.
Llevaban dos años trabajando bajo un contrato mensual por horas. La relación era buena y la calidad del trabajo también. Pero lo sorprendente fue que, tras más de 65 clientes nuevos y decenas de contratos cerrados, el despacho nunca sugirió una sola mejora en la plantilla en uso. Y la duda surge por sí sola: ¿cómo es posible que con tantos clientes no haya aparecido ninguna forma de optimizarlo? Porque la fase legal, como en casi todas las empresas B2B, suele ser de las más largas del ciclo de ventas, y un contrato bien diseñado, claro pero robusto, es clave para acelerar el proceso.
Si lo piensas, la respuesta está en los incentivos desalineados. Si el despacho factura por horas, optimizar el contrato base reduciría las idas y vueltas legales. Mejorar la plantilla va en contra de su propio modelo de negocio, por lo que no tienen interés en aprovechar ese feedback ni en cerrar el loop. Y un sistema sin incentivos alineados no puede mejorar, por mucho feedback que reciba.
Como resume Daniel Newman en “How Well Does Your Organization Use Feedback Loops?”
Feedback loops are simple to understand: you produce something, measure information on the production, and use that information to improve production. Around it goes—a constant cycle of monitoring and improvement. To stay healthy, every aspect of a business needs feedback loops.
Situaciones así desconectan el sistema (sea la empresa o el departamento) porque no hay feedback loop. Una organización no es otra cosa que un conjunto de loops, y estos tienden a mejorar solos. Pero si no existen, o los incentivos no están alineados, el sistema se estanca. Diseñar una organización consiste, sobre todo, en construir feedback loops que se refuercen a sí mismos.
Cuando la empresa es pequeña, quizá tenga más sentido enfocar la energía en estrategia y producto que en optimizar procesos legales. Pero al escalar, esos loops necesitan cambiar. Un departamento de marketing en etapa temprana está optimizado en base a los clics en la web; a los pocos meses, ese loop deja de ser útil y necesitas métricas más finas (CAC, LTV).
Todo proceso con un loop de feedback debe estar cerrado y libre de incentivos desalineados que lo obstaculicen. Y si haces zoom-out, empiezas a verlo por todas partes.
Una buena analogía está en el machine learning. Google Maps, por ejemplo, predice tu hora de llegada comparándola después con la real: ese feedback ajusta el modelo para la próxima vez. Lo mismo ocurre con los sistemas de recomendación: Amazon sugiere productos basándose en tu historial de compras y clics; si acierta o no en las sugerencias, esa señal vuelve al modelo para mejorar sus predicciones.
Creo que diseñar feedback loops efectivos no es complicado, pero sí requiere un determinado dominio tanto a nivel departamental como a nivel de organización.
Un feedback loop no tiene por qué ofrecer incentivos positivos1; de hecho, diría que los incentivos positivos son señal de un loop mal diseñado. Creo más bien que el feedback debe introducir dolor cuando el loop no funciona. Como un engranaje que chirría porque está mal alineado: ese ruido inmediato obliga a los operarios a corregir la máquina. Ahora imagina que ofreces un bonus por mantenerla encendida el mayor tiempo posible: ¿pararán la operación para darle un mantenimiento adecuado cuando haga falta? Probablemente no.
Un loop perfecto ocurre cuando los creadores de la herramienta la usan para crear la propia herramienta. Como un lenguaje de programación escrito en sí mismo2. Otro loop, también valioso, es cuando los creadores la usan para vender la máquina. Por ejemplo, una herramienta de ventas que se prueba a sí misma en su propio proceso comercial: allí el feedback es inmediato.
Al final, todo se reduce a incentivos. Un loop sin incentivos alineados es ruido; con ellos, se convierte en motor de mejora. El diseño de organizaciones no es más que esto: construir loops donde el dolor de ignorar el feedback sea mayor que el esfuerzo de incorporarlo.
Quizá la solución al caso legal no sea cambiar de despacho cada cierto tiempo, sino introducir una figura externa que actúe como “taste tester” del contrato o proceso. Alguien que revise periódicamente la plantilla (y el resto del proceso) desde la perspectiva de la experiencia real de los clientes y del equipo comercial. Igual que en un producto, este “catador” no se preocupa por el funcionamiento interno, sino por cómo se siente el proceso de principio a fin. Su función es detectar fricciones, proponer mejoras y cerrar el loop que de otro modo quedaría abierto por los incentivos desalineados del proveedor.
- Los incentivos positivos recompensan comportamientos deseados con beneficios, mientras que los incentivos negativos imponen una penalización o castigo por comportamientos indeseados. Por ejemplo:
- Incentivo positivo: un call center paga bonus a los agentes por el número de llamadas atendidas al día. Resultado: los agentes intentan cerrar las llamadas lo más rápido posible, aunque dejen al cliente insatisfecho.
- Incentivo negativo: si los clientes cuelgan insatisfechos, eso se refleja en bajas puntuaciones de satisfacción y en más llamadas repetidas, lo que genera más carga de trabajo. Ese “dolor” empuja a los agentes y a la organización a mejorar la calidad del servicio en lugar de solo la cantidad.
2. En programación, algunos lenguajes alcanzan tanta madurez que pueden usarse para escribir su propio compilador o intérprete. Al inicio dependen de otro lenguaje para “arrancar”, pero luego se reescriben en sí mismos. C es el ejemplo clásico: los primeros compiladores se hicieron en ensamblador, pero después se programaron en C. Ese cierre del círculo es lo que hace el loop perfecto: la herramienta sirve para crear y mejorar la propia herramienta.