Cómo presentar la deuda técnica al consejo sin perder presupuesto

Reunión de consejo de administración analizando una propuesta de inversión tecnológica

Ninguna de las veintitrés reuniones de dirección a las que hemos acompañado a un responsable de tecnología en los últimos cuatro años se perdió por falta de argumentos técnicos. Se perdieron por traducción. El CTO llegaba con razón y salía con un recorte del 40%.

La deuda técnica, dicha así, en voz alta, delante de siete personas que gestionan un P&L, suena exactamente a lo que no es: una petición de dinero para arreglar algo que ya se pagó una vez. Y ahí termina la conversación, normalmente en el minuto cuatro, que es justo donde se decide cómo presentar la deuda técnica al consejo sin perder presupuesto.

¿Por qué ese pasivo suena a excusa en la sala de dirección?

Presentar la deuda técnica ante un órgano de gobierno consiste en traducirla a tres magnitudes financieras: el importe anual que la compañía ya desembolsa repartido en otras partidas, el riesgo con probabilidad e impacto asignados, y el coste de oportunidad medido sobre objetivos ya aprobados. No se pide dinero nuevo: se propone reasignar gasto existente.

Porque la palabra tiene trampa. En contabilidad, un pasivo aparece en el balance, tiene vencimiento y tiene acreedor. El nuestro no aparece en ningún sitio, nadie lo firmó y el acreedor es abstracto. Cuando un consejero oye el término, busca mentalmente la línea en el balance, no la encuentra y clasifica la petición como opinión de ingeniería.

Hace dos años, acompañando a una scaleup de logística con 38 personas en producto, vimos el patrón en directo. El CTO abrió con una frase que nos pareció impecable: «arrastramos siete años de decisiones apresuradas». El presidente contestó: «esos siete años nos han dado 11 millones de facturación». Conversación terminada. Tenía razón él, por cierto.

¿Cuál es el fallo de fondo? Que presentar el problema como herencia convierte a quien lo presenta en acusador de los presentes. La mitad de esas decisiones apresuradas las aprobó la propia mesa, normalmente para cerrar un cliente grande en diciembre. Nadie financia un relato en el que sale como culpable.

El error de llevar métricas de ingeniería a una sala de decisión financiera

Cobertura de tests al 34%. Complejidad ciclomática media de 18. Cuatro mil ochocientas advertencias del linter. Todo cierto, todo irrelevante en ese contexto. Son métricas que describen el estado del activo, no su efecto sobre la caja.

La cosa es que ese tipo de dato obliga al oyente a hacer una traducción que no sabe hacer y que, sobre todo, no le corresponde. Si en el minuto tres alguien tiene que preguntar «y esto qué significa para nosotros», la partida ya está perdida: has trasladado la carga de la prueba a quien decide sobre tu dotación. En las cinco presentaciones que más dinero consiguieron de las que hemos revisado, no apareció ni una sola métrica de código en la diapositiva principal. Aparecían en el anexo, para quien preguntara.

Hoja de cálculo con el coste anual oculto de un sistema heredado

Lo que nadie dice: ese gasto ya se está pagando, solo que en otra partida

Aquí está el giro que cambia la reunión entera. No estás pidiendo dinero nuevo. Estás proponiendo mover una cantidad que la compañía ya desembolsa, disfrazada, repartida entre cuatro centros de coste distintos y sin que nadie la haya sumado jamás.

Esa suma es el documento. No la hoja de ruta de refactorización, no el diagnóstico, no las dependencias desactualizadas. La suma.

En una plataforma de reservas con la que trabajamos durante el primer semestre de 2023, el ejercicio arrojó 412.000 euros anuales. Treinta y un por ciento del tiempo de los diez ingenieros senior dedicado a incidencias repetidas (189.000 €), dos personas de soporte contratadas en 2022 exclusivamente para gestionar errores de un módulo de pagos (64.000 €), descuentos comerciales por SLA incumplido (38.000 €) y, la línea que nadie había mirado nunca, seis meses de retraso en el lanzamiento del módulo de facturación B2B que comercial ya tenía vendido a once cuentas.

Cuando pusimos esa cuarta cifra sobre la mesa, el director financiero pidió repetir el cálculo. Lo repetimos dos veces. Salía igual.

Honestamente: la primera versión de ese análisis nos la tiraron atrás. Habíamos estimado el coste de oportunidad con una proyección de ventas propia, inventada por nosotros, y el CFO la desmontó en noventa segundos. Tuvimos que rehacerlo usando exclusivamente el forecast que el propio comité comercial había firmado en enero. Lección cara: el dato tiene que venir de ellos, no de ti.

Dónde aparece realmente en la cuenta de resultados

Rara vez bajo la etiqueta de tecnología. Aparece en rotación de personal de ingeniería, en contrataciones de soporte que crecen más rápido que la base de clientes, en notas de crédito por indisponibilidad, en primas de seguro ciber, en el sobrecoste de infraestructura por arquitecturas que escalan vertical cuando deberían escalar horizontal.

Un cálculo que suele funcionar: compara el gasto de infraestructura por cliente activo entre 2022 y hoy. Si ha subido (en siete de las diez últimas compañías que hemos auditado subió entre un 15% y un 60%, por si sirve de referencia), tienes una curva que explica el problema sin pronunciar una sola palabra técnica. Una línea ascendente en una gráfica de coste unitario es un idioma que esa mesa domina perfectamente.

Qué cifra hace que un consejero levante la cabeza del dossier

El porcentaje de capacidad de desarrollo no disponible para roadmap. Punto. Es la única métrica interna que hemos visto producir silencio en una sala.

Formulada así: «de cada euro que esta compañía invierte en producto, 41 céntimos se consumen en sostener lo existente y 59 llegan a funcionalidad nueva». No hay quien no haga inmediatamente la cuenta de qué pasaría si esa proporción fuera 25/75. Y en ese momento el que pregunta eres tú, no él.

Si no tenéis ese número, no lo inventéis. Sacarlo requiere entre tres y cinco semanas de clasificación honesta de tickets, y es exactamente el tipo de entregable que produce nuestra auditoría técnica cuando se plantea con criterio de negocio y no como inventario de hallazgos. Sin esa cifra verificable, la propuesta vuelve a ser opinión.

¿Qué ocurre cuando se pide una pausa para refactorizar?

Que te la deniegan. Siempre. Y con buen criterio.

Una pausa significa cero entregas durante un trimestre a cambio de una promesa de velocidad futura no verificable. Ninguna mesa de gobierno aprueba eso, y nosotros tampoco lo aprobaríamos. La alternativa que sí pasa el filtro es la asignación permanente: reservar un porcentaje fijo de capacidad (entre el 15% y el 25%, según el estado del sistema) de forma indefinida, con entregas de negocio continuas en paralelo. Lo que buscan arriba no es velocidad máxima, es previsibilidad. Una pausa destruye la previsibilidad; una reserva constante la construye.

Comparativa de tres escenarios de inversión con sus costes y riesgos asociados

El marco que sí convence: riesgo, opción y coste de oportunidad

Tres palabras que esa sala usa a diario y que describen el problema con una precisión que el vocabulario de ingeniería nunca alcanzará.

Riesgo: probabilidad de un evento con impacto económico cuantificable. Caída del sistema de cobros en campaña de Navidad, 72 horas, impacto estimado sobre facturación del trimestre. Opción: capacidad de hacer algo mañana que hoy no se puede hacer. Integrar a un partner, abrir un mercado, soportar un contrato enterprise con requisitos de auditoría. Coste de oportunidad: lo que se deja de ganar mientras el equipo sostiene en lugar de construir.

Formulado en esos tres ejes, el asunto deja de ser un problema de ingeniería y pasa a ser lo que realmente es: una decisión de asignación de capital bajo incertidumbre. Y eso es literalmente la función del órgano que tienes delante.

Vamos, que no estás cambiando los hechos. Estás cambiando la categoría mental en la que se archivan. Este es el orden que mejor nos ha funcionado:

  1. Suma el gasto anual ya pagado en otras partidas.
  2. Calcula la capacidad de desarrollo no disponible para roadmap.
  3. Asigna probabilidad e importe al riesgo principal.
  4. Vincula cada euro a un objetivo estratégico ya aprobado.
  5. Presenta tres alternativas con precio y consecuencia.
  6. Lleva las cinco objeciones respondidas por escrito.
  7. Cierra con tres indicadores de revisión trimestral.

Tres escenarios cuantificados en lugar de una petición

Una petición se recorta. Un menú de opciones se elige. La diferencia operativa entre ambas cosas vale, por nuestra experiencia, entre un 30% y un 50% del importe solicitado.

Escenario Inversión Plazo Consecuencia esperada
A. No actuar 0 € adicionales Indefinido 412.000 € anuales mantenidos, con crecimiento del 18% interanual del sostenimiento según los últimos ocho trimestres
B. Contener 180.000 € 12 meses Tres puntos de mayor riesgo cubiertos, 40% menos de incidencias críticas, sin mejora de velocidad de entrega
C. Remediar 340.000 € 18 meses Capacidad de roadmap recuperada hasta el 78% y habilitación del módulo que comercial necesita para cuentas enterprise

En los seis casos en los que hemos presentado este formato, el órgano eligió B o C. Nunca A. Curiosamente, dos veces eligieron C siendo la opción más cara, porque el primer escenario tenía un número asociado y esa cifra daba más miedo que el desembolso.

Cómo anclar cada euro a un objetivo del plan estratégico

Si el plan a tres años dice «expansión a DACH en 2026», entonces el trabajo sobre multimoneda, multiidioma y residencia de datos en la UE no es mantenimiento: es la condición previa de un objetivo aprobado y presupuestado. Deja de competir con el roadmap comercial y empieza a formar parte de él.

Este anclaje requiere algo que muchos equipos técnicos no tienen a mano: haber leído el plan estratégico completo, con sus anexos financieros. Nos ha pasado encontrarnos con responsables de tecnología brillantes que nunca habían visto el documento que gobierna las decisiones de su propia compañía. Ahí es donde nuestra labor de dirección técnica senior aporta más valor que cualquier refactorización: en saber qué frase exacta del plan justifica cada línea de la propuesta.

Consejero formulando una objeción durante la defensa de una partida de ingeniería

Preguntas incómodas en la sala y respuestas que no erosionan la partida

Son siempre las mismas cinco. Las hemos oído, con mínimas variaciones, en prácticamente todas las sesiones. Llevarlas respondidas por escrito, con cifra, es lo que separa una aprobación íntegra de un recorte «para empezar».

¿Esto no debería haberse hecho bien la primera vez?

La respuesta honesta es que sí y que no habría sido rentable. Construir en 2019 la arquitectura que hoy necesitáis habría costado dieciocho meses adicionales y la compañía no existiría. La decisión de entonces fue correcta con la información de entonces. La incorrecta sería mantenerla ahora, con diez veces más clientes.

¿Qué pasa si aplazamos esto seis meses?

Nunca contestes «sería un desastre». Contesta con el importe del primer escenario dividido entre dos, más el incremento de probabilidad del evento de riesgo principal. En el caso de la plataforma de reservas: 206.000 euros de gasto mantenido y un salto de la probabilidad de caída crítica en campaña del 12% al 29%.

¿No es esto responsabilidad del equipo que ya pagamos?

Lo es, y por eso el 59% de su capacidad está dedicada a ello. Lo que se solicita no es personal nuevo para hacer su trabajo, es un cambio en la proporción de ese reparto.

¿Cómo sabremos si ha funcionado?

Tres indicadores con fecha de revisión trimestral: capacidad disponible para roadmap, incidencias críticas por mes y tiempo medio desde commit a producción. Comprometeos solo con valores que podáis sostener. Prometer una reducción del 70% de incidencias en el primer trimestre es la forma más eficaz de perder la renovación de la segunda fase.

¿Necesitamos a alguien de fuera para esto?

Depende de si el problema es de ejecución o de criterio, y conviene tenerlo claro antes de plantearlo arriba. Merece la pena revisar con frialdad si de verdad te hace falta un CTO o si lo que falta es sencillamente traducción financiera de un diagnóstico que el equipo interno ya tiene hecho desde hace meses.

Lo que de verdad se decide en esa reunión

No se decide sobre código. Se decide si quien lo presenta entiende el negocio lo suficiente como para que le confíen 340.000 euros. Esa es la evaluación real, y es silenciosa.

Por eso la deuda técnica bien presentada nunca pide comprensión técnica a cambio de dinero. Ofrece una decisión con tres precios, un riesgo con probabilidad asignada y un vínculo explícito con objetivos que esa misma mesa aprobó. Cuando el planteamiento llega en ese formato, la pregunta deja de ser cuánto recortamos y pasa a ser cuál de las tres.

Y sí, a veces eligen la barata. Pero eligen.

Founder & Software Engineer
Ingeniero de Software y Desarrollador Full Stack con más de 10 años de experiencia operativa. Dirige MVPtoSaaS aplicando los mismos estándares de fiabilidad y rendimiento exigidos en sistemas industriales y de alta criticidad. El enfoque de Felipe asegura que cada producto que transita por MVPtoSaaS cuente con código limpio, bases de datos optimizadas para alta concurrencia y despliegues automatizados preparados para el crecimiento sostenido sin deuda técnica.