Deuda técnica no es lo que crees: el marco para negociarla con producto
Un Tech Lead lleva cuatro trimestres arrastrando la misma línea al final del roadmap. Se llama "reducción de deuda técnica" y ocupa el último lugar de la lista de prioridades cada vez que se replanifica. En cada reunión de roadmap dice lo mismo: el sistema de autenticación necesita un refactor, la capa de datos acumula parches, los tiempos de build se han duplicado. En cada reunión de roadmap producto asiente, reconoce que es un problema real, y lo mueve al trimestre siguiente. Cuatro veces.
Tiene que decidir cómo entra a la próxima reunión. Y la evidencia empírica de las cuatro anteriores dice que su método no funciona.
Dos formas de pedir lo mismo, ambas razonables
La primera forma es la que ya intentó cuatro veces. Presentar la deuda como un problema técnico con impacto técnico: el código está mal, los tests son frágiles, el acoplamiento es alto. Es honesto, es preciso, y tiene una lógica interna sólida — quien conoce el sistema sabe que estas cosas tienen consecuencias reales. El problema es que traduce mal. Producto escucha "los ingenieros quieren tiempo para limpiar su propio desorden" y lo prioriza como lo que parece: mantenimiento interno sin valor visible para el usuario.
La segunda forma es la que muchos recomiendan como corrección: traducir la deuda a lenguaje de negocio. En vez de "el módulo de pagos está acoplado", decir "cada feature nueva en pagos tarda un 40% más de lo que debería". Convertir problema técnico en coste de oportunidad. Es mejor. Mueve la conversación del terreno donde el Tech Lead siempre pierde — el técnico, donde producto no puede evaluar — al terreno donde producto sí decide — el del coste y el beneficio.
Pero fíjate en un detalle. Las dos formas comparten un supuesto que ninguna cuestiona: que la deuda técnica es un problema, un objeto discreto que existe, que se puede señalar, medir y reparar. Un bug grande. Y si ese supuesto es falso, la segunda forma gana algunas negociaciones pero pierde la guerra — porque sigue presentando el síntoma como si fuera la enfermedad.
Lo que la palabra "deuda" te hace ver mal
Empecemos por la pregunta que el protagonista nunca se hizo en cuatro trimestres: ¿qué es exactamente lo que está pidiendo reparar?
La metáfora de la deuda financiera, que Ward Cunningham acuñó y que The Phoenix Project popularizó con la imagen del interés compuesto, es útil y peligrosa a la vez. Útil porque captura una verdad: los atajos de hoy cobran intereses mañana, y si no pagas el principal, cada caloría del equipo se va en pagar intereses en forma de trabajo no planificado. Peligrosa porque una deuda financiera es un número. Sabes cuánto debes. Sabes cuándo lo contrajiste. Puedes hacer un plan de amortización.
La deuda técnica no es un número. Es un stock.
Aquí entra la lente que cambia todo el análisis. En Thinking in Systems, Donella Meadows distingue entre eventos y stocks. Un evento es puntual: se rompió el deploy del martes. Un stock es una acumulación que crece y decrece según flujos de entrada y salida, como el agua en una bañera. Will Larson lo aplica exactamente a esto en An Elegant Puzzle: los proyectos no fallan de golpe, fallan un sprint cada vez; la deuda técnica no estrangula un proyecto en un día, lo estrangula a lo largo de meses. El Dust Bowl no lo causó un granjero ni un mal año — lo causaron años de flujo sistémico en la misma dirección.
Si la deuda es un stock, la pregunta "¿cuánta deuda tenemos?" está mal planteada. La pregunta correcta es: ¿cuál es el flujo? ¿A qué ritmo entra y a qué ritmo sale?
Y aquí está el error que el protagonista comparte con casi todos los que negocian deuda técnica. Presenta el stock. Muestra la foto del nivel de agua en la bañera: mira cuánto se ha acumulado, dame tiempo para vaciarlo. Producto mira la foto, la reconoce como problema, y la aplaza — porque una foto de un nivel alto no dice nada sobre qué pasa si no actúas. El agua lleva alta cuatro trimestres y el negocio sigue funcionando. Desde la silla de producto, eso es evidencia de que la deuda es tolerable.
Por qué el interés compuesto no lo convence
¿Y si presenta el interés? El argumento del coste de oportunidad — "cada feature tarda un 40% más" — es un intento de mostrar el flujo, no el stock. Es un paso en la dirección correcta. Pero se queda corto por una razón que tiene que ver con cómo funciona la planificación misma.
Ludwig von Mises tenía una observación sobre los planes económicos centralizados que se aplica con precisión incómoda aquí: un plan asume que puedes predecir el futuro con la información que tienes hoy. Cuando el Tech Lead dice "esto nos costará un 40% más en el próximo trimestre", está haciendo exactamente lo que producto hace con su roadmap — proyectar el futuro desde el presente. Y producto es profesional de eso. Sabe que las proyecciones a un trimestre son ruido. Sabe que el 40% es una estimación con un margen de error que probablemente supera el propio 40%.
Cuando compites contra producto en el terreno de "predecir el impacto del próximo trimestre", pierdes. Producto tiene mejores datos que tú sobre lo que el negocio necesita el próximo trimestre. Ese es su trabajo, no el tuyo.
Entonces, ¿dónde tienes tú la ventaja de información que producto no tiene?
La respuesta cambia toda la estrategia. Tú no tienes ventaja prediciendo el impacto puntual de la deuda. Tienes ventaja describiendo el sistema que la genera. Producto ve features entrando y saliendo. Tú ves el mecanismo por el cual cada feature entregada bajo presión añade un poco más al stock, y por el cual ese stock aumenta el coste de la siguiente feature, que se entregará bajo aún más presión. Tú ves el bucle de retroalimentación. Producto ve una lista de tareas.
Ese conocimiento — la estructura del sistema, no el tamaño del problema — es lo único que producto no puede obtener sin ti.
La diferencia entre pedir tiempo y describir un bucle
Volvamos a la reunión. El protagonista tiene que decidir qué presenta. Ya sabemos qué no funciona: la foto del stock (cuatro trimestres de evidencia) y la proyección del interés (compite en el terreno de producto). Lo que queda es describir el flujo y el bucle que lo alimenta.
Concretamente, esto significa que la próxima reunión no empieza pidiendo tiempo. Empieza mostrando una relación. Fíjate en la diferencia estructural entre estas dos afirmaciones:
"El módulo de pagos tiene mucha deuda y necesitamos dos sprints para refactorizarlo."
"En los últimos cuatro trimestres, el tiempo de entrega de features en pagos ha crecido de forma sostenida. No porque el equipo sea más lento, sino porque cada feature que entregamos bajo el plazo actual añade acoplamiento que hace la siguiente más cara. Estamos pagando el plazo de hoy con el plazo de mañana, y el ritmo al que se encarece es medible."
La primera pide un favor. La segunda describe una máquina que produce un resultado indeseado, y lo hace con datos que producto puede verificar contra su propia experiencia de que "las cosas en pagos van cada vez más lentas". La segunda no pide que confíen en tu juicio técnico. Pide que miren un patrón que ya han sentido.
Aquí es donde Good Strategy Bad Strategy de Richard Rumelt aporta la pieza que falta. Rumelt insiste en que una estrategia real empieza por un diagnóstico — nombrar la naturaleza del desafío antes de proponer nada. La mayoría de lo que se llama estrategia son objetivos disfrazados: "reducir la deuda técnica en un 30%" es un objetivo, no un diagnóstico. El diagnóstico es: "tenemos un bucle en el que la presión de plazos genera acoplamiento, el acoplamiento reduce la velocidad, y la velocidad reducida genera más presión de plazos". Una vez que nombras el bucle, la intervención deja de ser "danos tiempo" y pasa a ser "rompamos este punto específico del ciclo".
Y romper un punto específico es negociable de una forma que "danos tiempo" nunca lo fue. Porque ahora producto y tú están mirando el mismo diagrama.
Quién sabe dónde está el punto de ruptura
Hay una tentación en este punto: que el Tech Lead llegue con el bucle diagnosticado, el punto de intervención identificado y el plan de amortización listo. La solución completa, entregada de arriba abajo.
Es un error, y por la misma razón que los planes centralizados fallan. El Tech Lead no tiene toda la información. Sabe que hay un bucle. Puede que sepa que pagos es el foco. Pero el conocimiento sobre qué feature concreta se está encareciendo más rápido, sobre qué parte del acoplamiento duele en el trabajo diario, sobre dónde exactamente el flujo entra con más fuerza — ese conocimiento está distribuido en el equipo que toca el código cada día. Y el conocimiento sobre qué features del roadmap dependen de esa zona del sistema está en producto.
El diagnóstico correcto no lo produce el Tech Lead solo. Lo produce la conversación entre quien ve el sistema técnico y quien ve el sistema de negocio, cada uno aportando la mitad del diagrama que el otro no puede ver.
Esto reencuadra la negociación por completo. El objetivo de la reunión no es que producto apruebe tu plan. Es que producto y tú construyan juntos el diagnóstico del bucle — porque una vez construido, la prioridad emerge de él sin que nadie tenga que imponerla. Si el diagrama muestra que las tres features más importantes del próximo semestre pasan todas por la zona que se está encareciendo más rápido, la decisión de intervenir ahí deja de ser una petición de ingeniería. Se vuelve la conclusión obvia del análisis que ambos hicieron.
David Maister, en The Trusted Advisor, describe el mecanismo exacto por el que esto funciona. La confianza no se gana teniendo razón. Se gana cuando el otro te ve razonar sobre su problema, no sobre el tuyo. El Tech Lead que llega con "necesito tiempo para la deuda" razona sobre su problema. El que llega con "he notado que estas features se están encareciendo, ayúdame a entender cuáles importan más para que decidamos dónde intervenir" razona sobre el problema compartido. Y el segundo consigue lo que el primero no consiguió en cuatro trimestres — no porque tenga mejores argumentos, sino porque ha cambiado de qué lado de la mesa está.
Cuándo la intervención es una migración, no una limpieza
Queda una pregunta que el diagnóstico del bucle vuelve inevitable. Si la deuda es un flujo sostenido y no un stock puntual, entonces "vaciar la bañera" en dos sprints no la resuelve — resuelve el nivel de hoy, y el flujo la vuelve a llenar.
Larson es tajante en esto: las migraciones son el único mecanismo que gestiona deuda técnica de forma efectiva a medida que la empresa y el código crecen. No la limpieza puntual. La migración estructural que cambia el flujo, no solo el nivel. Y esto tiene una consecuencia directa para lo que negocias. No estás pidiendo dos sprints para limpiar. Estás negociando un cambio en cómo se hace el trabajo en esa zona, sostenido en el tiempo, que reduzca el ritmo al que entra la deuda mientras el equipo sigue entregando valor visible.
Porque si desapareces tres meses "pagando deuda" y produces cero features nuevas, habrás validado exactamente el miedo de producto: que la deuda técnica es un agujero donde el negocio deja de recibir valor. La intervención bien diseñada mantiene un flujo de entregas visibles mientras reduce el flujo de entrada de deuda. Las dos cosas a la vez. No porque sea más elegante, sino porque cualquier otra cosa reactiva la impaciencia que te devolvió al último lugar del roadmap cuatro veces.
Lo que esto generaliza
El principio va más allá de la deuda técnica. Cada vez que un Tech Lead pierde una negociación con negocio de forma repetida, con los mismos argumentos y el mismo resultado, la causa suele ser la misma: está presentando un stock donde debería presentar un sistema. Un nivel acumulado donde debería mostrar el flujo que lo produce y el bucle que lo sostiene.
Esto aplica a la fiabilidad presentada como "tenemos muchos incidentes" en vez de "tenemos un bucle donde la presión de features reduce la inversión en fiabilidad, lo que aumenta los incidentes, lo que reduce el tiempo para features". Aplica a la contratación presentada como "necesitamos más gente" en vez de "tenemos un flujo de trabajo que crece más rápido que nuestra capacidad, y aquí está el mecanismo". Aplica a cualquier problema que lleve meses sin resolverse porque quien lo plantea lo describe como un objeto a reparar en vez de como un proceso a modificar.
El que presenta la foto pide un favor y compite en el terreno del otro. El que presenta el mecanismo invita a construir el diagnóstico juntos y gana en su propio terreno — el único donde tiene la información que el otro no tiene.
El protocolo paso a paso para llevar esta conversación a tu próxima reunión de roadmap — desde cómo construir el diagrama del bucle con tu equipo hasta cómo estructurar la negociación con producto sin pedir un solo favor — está en el recurso descargable para suscriptores.
Cada semana analizo un problema real de liderazgo técnico. Con el mismo nivel de profundidad.