Deuda técnica no es lo que crees: el marco para negociarla con producto
Llevas seis meses pidiendo tiempo para reducir deuda técnica. Producto asiente en cada reunión, dice que lo entiende, y luego prioriza tres features nuevas. Cada vez que abres la boca, estás perdiendo la negociación antes de empezar.
Estás usando la palabra "deuda" para describir algo que producto no puede evaluar, y luego te sorprende que no lo priorice.
Voy a defender algo incómodo: la mayoría de los Tech Leads que fracasan en esta negociación fracasan porque tienen razón sobre la técnica y están equivocados sobre qué están negociando. Presentan la deuda técnica como un problema de código. Y quien la presenta como problema de código ya perdió.
La metáfora financiera que te está saboteando
La analogía de la deuda es de Ward Cunningham, y en su formulación original era precisa: escribes código que no entiendes del todo bien, envías, y aprendes. La refactorización posterior es pagar el préstamo. Interés bajo, préstamo consciente, devolución planificada.
Lo que llegó a las reuniones de roadmap es una mutación de esa idea. En The Phoenix Project, Erik lo describe con la imagen del interés compuesto: si no pagas la deuda, cada caloría de la organización se gasta pagando intereses en forma de trabajo no planificado. La imagen es correcta y por eso es peligrosa. Porque una vez que aceptas el marco "deuda = préstamo con intereses", producto tiene todo el derecho a preguntarte lo que le pregunta a cualquier acreedor.
¿Cuánto debemos exactamente? ¿Cuál es la tasa de interés? ¿Qué pasa si no pagamos este trimestre?
Y ahí es donde te quedas mudo. Porque no lo sabes. Nadie lo sabe. La deuda técnica no tiene un principal cuantificable ni una tasa fija. Tiene un comportamiento mucho más difícil de comunicar, y al aceptar la metáfora financiera te comprometiste a responder preguntas que la metáfora sugiere pero que la realidad no permite responder.
Producto no está siendo obtuso. Está aplicando correctamente el marco que le diste. El marco es el problema.
Un stock que nadie decidió acumular
Aquí está la parte que cambia la conversación. La deuda técnica no es una lista de decisiones malas que alguien tomó y que ahora hay que revertir. Es un stock que crece por el funcionamiento normal del sistema, incluso cuando todo el mundo hace su trabajo bien.
Thinking in Systems de Donella Meadows tiene el vocabulario exacto para esto. Un stock es una acumulación —agua en una bañera, dinero en una cuenta, complejidad en un código— que sube y baja según dos flujos: lo que entra y lo que sale. El nivel del stock en cualquier momento no lo causó un evento. Lo causó el diferencial entre flujos sostenido durante meses.
Will Larson usa exactamente esta lente en An Elegant Puzzle cuando habla del Dust Bowl. La catástrofe agrícola de los años treinta no la causó un granjero ni un año de mal cultivo. La causaron años de un flujo de extracción que superaba al flujo de regeneración del suelo. Nadie lo decidió. Cada granjero, individualmente, hacía lo racional. El stock —la degradación del terreno— creció hasta colapsar.
La deuda técnica se comporta igual. El flujo de entrada es la complejidad que cada feature añade al sistema: cada endpoint nuevo, cada caso especial que el negocio pidió, cada integración que pareció simple. El flujo de salida es el trabajo de simplificación, refactor y consolidación que reduce esa complejidad. Cuando el flujo de entrada supera al de salida de forma sostenida, el stock crece. Sin que nadie tome una mala decisión.
Esto tiene una consecuencia que rara vez se dice en voz alta: la deuda técnica no es evidencia de negligencia del equipo. Es el resultado esperado de entregar valor a la velocidad que el negocio pidió. Si tu equipo entregó rápido durante dieciocho meses, tiene deuda técnica. No a pesar de haber trabajado bien, sino precisamente porque lo hizo.
Cuando entras a la reunión con este marco, la conversación deja de ser "el equipo tomó atajos y ahora hay que pagar" y pasa a ser "el sistema acumula complejidad como función del ritmo de entrega que decidimos juntos". El segundo marco no reparte culpa. Describe un mecanismo. Y producto no puede discutir un mecanismo del mismo modo en que discute una petición.
Por qué "necesitamos refactorizar" no es una estrategia
Hay un momento en toda negociación de deuda técnica en el que el Tech Lead dice algo parecido a "necesitamos dedicar un 20% del tiempo a reducir deuda". Suena razonable. Es una de las peores cosas que puedes decir.
Good Strategy Bad Strategy de Richard Rumelt tiene un nombre para esto: fluff y objetivos disfrazados de estrategia. Un porcentaje de tiempo no es un diagnóstico ni un plan de acción. Es una aspiración numérica que no le dice a nadie qué problema concreto se resuelve ni por qué ese problema, entre todos los posibles, es el que importa ahora.
El núcleo de una estrategia real, según Rumelt, es un diagnóstico honesto seguido de una política que ataca ese diagnóstico y de acciones coherentes con la política. Aplicado a la deuda técnica, esto significa que "reducir deuda" no es estrategia. Es como decir "mejorar la empresa".
La versión estratégica es distinta. Larson lo formula como identificar el constraint central: el único componente que limita el throughput de trabajo terminado. No toda la deuda importa. La mayoría de la deuda técnica de tu sistema es irrelevante porque vive en zonas del código que nadie toca. La deuda que importa es la que está en el camino crítico de lo que el negocio quiere hacer en los próximos dos trimestres.
Larson añade una advertencia que conviene tomarse en serio: nombrar "deuda técnica" y "toil" se ha vuelto poco convincente precisamente porque se ha usado para eludir tanta responsabilidad que ya no significa nada. Cuando dices "es que tenemos mucha deuda técnica", producto oye "los ingenieros quieren tiempo para hacer cosas de ingenieros". Y tienen motivos para oír eso, porque lo han oído de equipos que lo usaban como excusa.
La diferencia entre el equipo al que producto ignora y el equipo al que escucha no es el volumen de deuda. Es la especificidad del diagnóstico.
El diagnóstico que producto sí puede evaluar
Nadie en producto puede evaluar "el módulo de pagos tiene mala arquitectura". No tienen el contexto técnico para valorarlo, y no deberían tenerlo. Pero cualquier persona de producto puede evaluar esto: "cada cambio en el flujo de checkout tarda tres veces más que hace un año, y el 40% de nuestros incidentes de los últimos dos trimestres tocaron ese módulo".
La primera afirmación es una opinión técnica que le pides que acepte por autoridad. La segunda es un dato sobre velocidad de entrega y riesgo de negocio que puede contrastar con su propia experiencia de roadmaps que se retrasaron.
El conocimiento para hacer este diagnóstico no lo tienes tú solo. Está repartido en tu equipo, y la mayoría de las veces el Tech Lead que intenta cuantificar la deuda desde su cabeza produce una lista que refleja sus propias obsesiones técnicas, no el constraint real. Los ingenieros que trabajan en el checkout saben qué zona les hace perder horas. Quien lleva las guardias sabe qué componentes generan incidentes recurrentes. Esa información existe, pero no en un solo sitio.
El trabajo de diagnóstico consiste en extraer ese conocimiento disperso y traducirlo a las dos únicas magnitudes que producto entiende: velocidad de entrega futura y riesgo de negocio. No cuánta deuda hay. Qué te impide entregar lo que ya está en el roadmap.
Una forma concreta de hacer esto: toma las tres o cuatro iniciativas que producto quiere entregar en los próximos dos trimestres. Para cada una, pregunta al equipo qué zonas del sistema toca y cuál es el estado de esas zonas. La deuda que aparece en la intersección de "producto quiere esto" y "esta zona nos frena" es la única que vas a negociar. El resto no lo menciones. Mencionarlo diluye tu credibilidad y confirma la sospecha de que quieres tiempo para limpiar por limpiar.
La migración como única salida real
Hay un punto de Larson que conviene incorporar porque contradice la intuición de casi todo el mundo. Las migraciones son el único mecanismo que gestiona deuda técnica de forma efectiva a medida que la empresa y el código crecen. Si tu organización no se vuelve buena ejecutando migraciones, languidece en deuda —y acabarás haciendo una reescritura completa de todos modos, solo que más tarde y más cara.
Esto importa para la negociación porque cambia lo que estás pidiendo. No estás pidiendo "tiempo para refactorizar" en abstracto, algo que produce cero valor visible y que puede posponerse indefinidamente. Estás proponiendo una migración con un antes y un después: del estado que frena la entrega al estado que la desbloquea.
Una migración tiene principio, mitad y final. Tiene una definición de terminado. Se puede meter en un roadmap junto a las features, porque compite en el mismo lenguaje: entrega esto para desbloquear aquello. La refactorización difusa no compite en ese lenguaje. La migración sí.
Larson también advierte del fallo de ejecución más común, y es uno que producto teme con razón. El equipo desaparece dentro de la reducción de deuda y, desde la perspectiva de los usuarios, deja de entregar. Los stakeholders se ponen nerviosos esperando que el equipo vuelva a producir cosas nuevas. Un equipo que se mete tres meses en un refactor sin entregar nada visible confirma el peor miedo de producto y quema el capital político que necesitará la próxima vez.
La ejecución que funciona mantiene entrega visible mientras paga deuda. Un poco de valor nuevo cada iteración, aunque el grueso del esfuerzo vaya a la migración. No porque sea óptimo desde la ingeniería, sino porque la impaciencia de los stakeholders es una fuerza real del sistema y un plan que la ignora se revierte a mitad de camino.
El precio de tu credibilidad futura
Queda una pieza, y es la que separa al Tech Lead que gana una negociación del que gana todas las siguientes. The Trusted Advisor de David Maister construye toda su tesis sobre una idea simple: la influencia no viene de tener razón, viene de que la otra parte confíe en que tu recomendación sirve a los intereses de ella, no a los tuyos.
El Tech Lead que pide tiempo de deuda técnica sin cuantificar el impacto en el negocio parece —y a veces es— alguien optimizando para su propia comodidad. El que llega con el diagnóstico traducido a velocidad y riesgo, que solo menciona la deuda en el camino crítico y que propone una migración con entrega visible, demuestra que ha hecho el trabajo de entender qué le importa a producto.
Esa demostración es lo que se acumula. La primera negociación que ganas así te da algo más que el tiempo de esa migración. Te da que la próxima vez que digas "esto nos va a frenar", producto te crea sin pedirte el desglose. Has convertido tu palabra en una señal fiable. Y esa señal, en una organización, vale más que cualquier argumento individual.
Hay un protocolo concreto para conducir esta negociación paso a paso —cómo preparar el diagnóstico con el equipo, cómo estructurar la conversación con producto, qué decir cuando te piden números que no existen y cómo cerrar el acuerdo sin quemar capital político. Lo desarrollo completo en la membresía.
Esta semana, antes de tu próxima reunión de roadmap, haz un solo ejercicio. Escribe las tres iniciativas que producto quiere entregar en los próximos dos trimestres. Pregunta a tu equipo qué zona del sistema frena cada una y cuánto la frena. Lo que aparezca en esa intersección es lo único que vas a llevar a la mesa. Todo lo demás que querías pedir, guárdalo. No importa menos, pero pedirlo ahora te cuesta la credibilidad que necesitas para lo que sí importa.
Cada semana analizo un problema real de liderazgo técnico. Con el mismo nivel de profundidad.