¿Cómo explicas un gasto de £20M en ingeniería?

Conozco el dolor de justificar los costes de ingeniería de software. Da igual si explicas desvíos de proyecto a directivos de finanzas en una gran empresa o proyectas la tasa de consumo de caja a inversores en una startup. La conversación es siempre la misma.

El director financiero o el inversor pregunta: “Gastamos £15 millones en ingeniería. ¿Qué recibimos a cambio?”

Abres tu hoja de cálculo. Tienes el número de personas. Tienes las bandas salariales. Tienes una lista de proyectos en curso. Pero cuando te preguntan “¿cuánto costó realmente la reconstrucción del checkout?” o “¿cuál es el ROI de esa migración de plataforma de seis meses?”, improvisas.

He liderado equipos de ingeniería en startups y en organizaciones más grandes, con 30 ingenieros como mucho a la vez. La escala cambia, pero el problema es idéntico en todas partes: nadie sabe decirte cuánto cuesta realmente nada.

Ni las funcionalidades. Ni los proyectos. Ni las “iniciativas estratégicas” que se comen trimestres enteros. El dinero desaparece en un agujero negro con la etiqueta “Ingeniería” y todo el mundo espera que salga por el otro lado convertido en ingresos.

Y no son solo salarios. Esos £15 millones incluyen a las personas, sí, pero también el gasto en IA, las licencias de software, la infraestructura en la nube y el hardware. La factura completa de ingeniería. Aun así, la mayoría de las organizaciones no sabe desglosar ni una parte.

Mi experiencia abarca los dos mundos. En startups, he tenido que proyectar costes a inversores que querían entender la economía unitaria antes de la Serie A. En entornos corporativos, he tenido que explicar a directivos de finanzas por qué un proyecto de seis meses ahora se proyecta a doce. Las excusas cambian, el problema de fondo no: nos falta la infraestructura básica para medir lo que cuesta de verdad el trabajo de ingeniería.

El problema no es nuevo, pero va a peor

Esto es lo que oigo a casi todos los líderes tecnológicos con los que hablo:

“Acabamos agrupando los costes en una bolsa central porque no podemos cerrar el círculo dentro del mes.”

Traducción: no sabemos en qué gastamos qué, así que lo metemos todo en un cajón de sastre y lo llamamos “Equipo de Plataforma T3”. Finanzas lo odia. El consejo lo cuestiona. Pero ¿qué otra cosa se puede hacer?

“Si recortamos un 20% de la plantilla o movemos equipos, quiero ver el impacto al instante.”

Pero no puedes. Porque tu “herramienta de planificación” es una hoja de cálculo con 47 pestañas que se rompe si borras una fila. Cuando has modelado el escenario, el consejo ya ha decidido a ojo.

“Gastamos £20 millones en personas. Necesito demostrar que los gastamos bien.”

Esta es la que quita el sueño a los CTO. Sabes que gastas bien. Sabes que tus equipos son buenos. Pero no puedes demostrarlo con datos, porque los datos no existen.

“Tenemos que replanificar cada pocos meses, cuando cambian las prioridades o las personas.”

Y cada replanificación te cuesta tres días de reuniones, otra ronda de hojas de cálculo y el mismo proceso doloroso del trimestre pasado.

Por qué la planificación muere en cuanto la publicas

La mayoría de las organizaciones de ingeniería planifica por trimestres. Pasas 4-6 semanas construyendo el plan del siguiente. En la semana siete, alguien se va. En la nueve, aparece de la nada una “prioridad estratégica”. En la doce, tu plan original es ficción histórica.

Así se reparte de verdad el tiempo de los líderes de ingeniería:

Reuniones (planificación, asignación, revisiones): 17,9 horas/semana, 7 horas más que los colaboradores individuales
Tiempo fragmentado: 7,1 horas/semana, con una penalización del 40% en productividad
Tiempo de concentración: 10,4 horas/semana, de las cuales solo 2,6 horas sin interrupciones

¿Esas 17,9 horas semanales de reuniones? Buena parte tiene que ver con la planificación: arranques de planificación trimestral que se alargan 4-6 semanas, revisiones a mitad de trimestre, debates de asignación de recursos, justificaciones de presupuesto. Si haces la cuenta, los líderes de ingeniería dedican más o menos un tercio de cada trimestre a planificar el siguiente. Vas siempre seis semanas por detrás de la realidad, porque cuando terminas de planificar, el mundo ya ha cambiado.

¿Y qué planificas? Según McKinsey, los equipos de ingeniería dedican entre el 40% y el 60% de su tiempo a mantenimiento y operaciones en lugar de a capacidades nuevas¹. Pero ¿puedes decirme qué 40-60%? ¿Puedes enseñarme qué ingenieros trabajan en qué proyectos y si esos proyectos son CapEx u OpEx?

Claro que no. Porque seguirlo exige actualizar una hoja de cálculo cada semana, y todos sabemos que eso no pasa.

El punto ciego entre CapEx y OpEx

Aquí empieza a doler. Tu director financiero necesita saber si el trabajo de ingeniería construye capacidades nuevas (CapEx) o mantiene las existentes (OpEx). No es purismo contable. Cambia por completo cómo se financia y se mide el trabajo.

McKinsey encontró que en algunas organizaciones los desarrolladores dedican más del 50 por ciento de su tiempo solo a lidiar con la deuda técnica ². Esa es la diferencia entre una organización de ingeniería estratégica y un equipo que se pasa la vida apagando fuegos.

En cambio, las empresas del cuartil superior (según el Developer Velocity Index) dedican un 33 por ciento menos de tiempo a trabajo manual sin diferenciación, y eso las libera para innovar ³.

Pero atención: el problema es casi universal. Una encuesta de 2023 halló que el 91% de los responsables de TI señala la deuda técnica como su mayor obstáculo para innovar ⁴. Aun así, muchas empresas solo “reservan entre el 15 y el 20 por ciento del presupuesto de TI para abordar la deuda técnica”, una asignación que McKinsey considera a menudo insuficiente ².

¿Puedes enseñarle a tu consejo en qué categoría cae cada ingeniero? ¿Puedes demostrar que pasas de un 50% de lastre por deuda técnica a un 30%? ¿O solo esperas que nadie pregunte?

La olla a presión del capital riesgo

Por esto importa más que nunca: las operaciones de compra de los fondos de capital privado se recuperaron hasta los $602 mil millones en 2024, un 37% más que el año anterior ⁵. El sector tecnológico fue el motor principal y acaparó el 33% de todas las operaciones de compra por valor en todo el mundo ⁵.

Pero las reglas han cambiado. Mira cómo crean valor los fondos con el tiempo:

La excelencia operativa pasó de 18% a 47% de la creación de valor. La ingeniería financiera (apalancamiento y expansión de múltiplos) cayó de 51% a 25%.

¿Qué significa para ti? Si diriges la ingeniería de una empresa participada por un fondo, tienes 90 días para demostrar cómo gastas el dinero y de 12 a 24 meses para demostrar mejoras de eficiencia reales.

“Estamos contratando más ingenieros” no es un plan. “Asignamos 8,5 FTE a estos tres proyectos con estos retornos esperados” sí lo es.

¿Y sabes qué piden los socios operativos de los fondos?

El coste real por proyecto (ni estimaciones ni corazonadas)
La asignación entre OpEx y CapEx en toda la organización de ingeniería
Tasas de utilización de recursos
Costes de desarrollo de funcionalidades con cifras reales
Una hoja de ruta de expansión de márgenes con los factores de eficiencia de ingeniería

La mayoría de los líderes tecnológicos no sabe responder a nada de esto.

El impuesto del error en las hojas de cálculo

Esto debería aterrarte: las revisiones académicas, incluido un análisis reciente de 35 años, encuentran de forma consistente que entre el 88% y el 94% de las hojas de cálculo que se usan en decisiones críticas de negocio contienen errores ⁶. No es una errata. Casi todas las hojas que mueven tu planificación de costes de ingeniería tienen fallos.

Y aun así, PwC cuenta que el 80% de las organizaciones sigue dependiendo de hojas de cálculo para su planificación y análisis financiero (FP&A) ⁷.

Esto no es un problema técnico. Es una crisis de organización. Cuando tu director financiero no se fía de tus números porque están hechos en Excel, pierdes credibilidad. Cuando te pide un análisis de escenarios y necesitas tres días para copiar pestañas de un lado a otro, pierdes influencia.

Este desajuste es endémico. Workday halló que solo el 30% de los directores financieros dice estar muy alineado con sus CIO en la hoja de ruta digital y tecnológica de sus empresas ⁸. ¿Cómo vais a alinearos si habláis idiomas distintos? Finanzas habla de centros de coste y previsiones trimestrales. Ingeniería habla de story points y velocidad de sprint.

Lo que nos falta: una unidad mínima viable

El problema no es que necesitemos mejores diagramas de Gantt. Es que no tenemos una unidad mínima viable para medir el trabajo de ingeniería.

Finanzas tiene una jerarquía clara:

Partidas → Centros de coste → Departamentos → Gasto total

La fabricación tiene:

Componentes → Productos → Líneas de producción → Producción

¿Y el software?

Story points (no significan nada fuera de tu equipo)
Funcionalidades (demasiado granulares)
Productos (demasiado amplios)
“Inversión en plataforma” (puede significar cualquier cosa)

Las startups están especialmente ciegas. Pregunta a cualquier fundador cuánto costó construir su nuevo flujo de pago, no en story points, sino en dinero gastado en salarios, estructura y coste de oportunidad, y te encogerá los hombros.

Esto es lo que arreglamos en flowstate. He empezado a llamar a esta disciplina Workforce Engineering: diseñar a propósito cómo una organización despliega su trabajo para producir resultados. Más sobre esto pronto.

El método flowstate: Workforce Engineering en la práctica

No construimos otra herramienta de gestión de proyectos. Construimos un marco para cómo deben planificar, seguir y medir el trabajo las organizaciones de ingeniería.

Piénsalo así:

Agile fue la metodología de desarrollo de software
The Linear Method es para el seguimiento de incidencias y el flujo de producto
El método flowstate es para la economía de ingeniería y la visibilidad de costes

El principio central: la inversión en ingeniería debe estructurarse en torno a apuestas, no a backlogs.

Proyectos como apuestas mínimas viables

Aquí tenemos opiniones propias. En el método flowstate, un proyecto es:

Mínimo 1,0 FTE de la capacidad mensual de un equipo
Máximo 4 proyectos simultáneos por equipo y trimestre
De un solo equipo siempre que sea posible
Alineado con un centro de coste para que finanzas pueda seguirlo
Ajustado a las habilidades para asegurar que los equipos tienen las capacidades adecuadas

¿Por qué 1,0 FTE como mínimo? Porque algo más pequeño no es una apuesta, es una tarea disfrazada de estrategia. Si no estás dispuesto a dedicar al menos una persona-mes a algo, no te lo tomas en serio.

¿Por qué un máximo de 4 por trimestre? Porque la concentración es un recurso escaso. Un equipo que intenta hacer más de cuatro cosas importantes a la vez no está haciendo bien ninguna.

Esta estructura te da:

Visibilidad real de costes: sabes lo que costó “reconstruir el checkout” porque ves los proyectos que lo componen y su asignación de FTE
Planificación de escenarios que funciona: ¿mueves un equipo? Ves al instante qué proyectos pierden capacidad
Seguimiento real del ROI: puedes medir si la apuesta salió bien porque sabes lo que apostaste
Equilibrio de habilidades: ajusta los requisitos del proyecto a las capacidades del equipo, no solo al número de personas, sino a sus habilidades reales

Las personas son más que FTE

Aquí es donde fallan la mayoría de las herramientas de planificación de ingeniería: tratan a todo el mundo como recursos intercambiables. flowstate no.

Registramos:

Rol (Frontend Engineer, Backend Engineer, DevOps, etc.)
Nivel (Junior, Mid, Senior, Staff, Principal)
Habilidades (React, Python, AWS, PostgreSQL, etc.)

Así, cuando planificas un proyecto nuevo, puedes preguntar: “¿Tenemos las habilidades adecuadas disponibles?” y no solo “¿Tenemos capacidad?”

Puedes ver que tu equipo tiene 4,0 FTE disponibles, pero solo 1,5 FTE con las habilidades de React que necesita el trabajo de frontend. Eso cambia tu planificación. Quizá tengas que contratar de otra manera. Quizá tengas que ajustar el alcance del proyecto. Quizá tengas que formar a alguien.

Pero al menos lo sabes. Y eso es mejor que descubrir el desfase de habilidades seis semanas después de empezar el proyecto.

Las iniciativas se descomponen hacia abajo, no hacia arriba

El trabajo estratégico grande, las iniciativas, no existe en flowstate como un bloque monolítico. Se descompone en proyectos, cada uno con un solo equipo responsable y una asignación clara de FTE.

Así, cuando el director financiero pregunta “¿cuánto costó la reconstrucción del checkout?”, puedes responder:

“Tres proyectos que suman 12,5 FTE entre el T2 y el T3. Unos £340k de coste total imputado. Entregado en plazo. Vemos una mejora de conversión del 15%, que se traduce en £2,1M de ingresos anuales adicionales.”

Eso no es una corazonada. Son datos.

El marco de las apuestas

Cada proyecto de flowstate se vincula a:

Valor de negocio: impacto en ingresos, ahorro de costes o posicionamiento estratégico
Centro de coste: dónde se contabiliza el gasto
Flujo de valor: qué parte del negocio se beneficia
Asignación de FTE: el compromiso exacto de recursos en el tiempo
Habilidades necesarias: qué capacidades requiere el proyecto

Cuando estructuras así el trabajo, la conversación sobre CapEx y OpEx se vuelve sencilla:

Tipo de proyecto	Asignación típica	Impacto en el negocio	Tratamiento contable
Capacidades nuevas	20-30% de la capacidad	Crecimiento de ingresos	CapEx
Modernización de la plataforma	15-20%	Eficiencia y escala	Mixto
Reducción de deuda técnica	15-20%	Velocidad a largo plazo	OpEx
Mantenimiento y soporte	20-30%	KTLO	OpEx
Experimentos de innovación	10-15%	Valor de opción	CapEx

Asignación recomendada por el método flowstate para una organización de ingeniería equilibrada

No solo registras tiempo. Registras inversión y retorno.

Cómo se ve en la práctica

Trabajamos con empresas como RAC en la planificación de costes de ingeniería. Así cambia la conversación:

Antes de flowstate:

“Necesitamos cinco ingenieros más para el equipo de plataforma.”

Después de flowstate:

“Este trimestre asignamos 8,5 FTE a tres proyectos:

Migración a API v3 (4,0 FTE, £110k, se espera que desbloquee £2M en ahorros operativos)

Infraestructura de observabilidad (3,0 FTE, £82k, reduce el MTTR de incidentes un 40%)

Refuerzo de seguridad (1,5 FTE, £41k, requisito mínimo para el nivel enterprise)

Coste total este trimestre: £233k. Capacidad actual: totalmente asignada.

Si añadimos cinco ingenieros (£150k al trimestre con todos los costes), podemos asumir el proyecto de modernización de pagos en el T4. Se proyecta un impacto de £5M en ingresos anuales por menos carritos abandonados y nuevos métodos de pago.

Eso sí, necesitamos 2,0 FTE con experiencia en procesamiento de pagos y 1,5 FTE con conocimientos de cumplimiento PCI. Nuestro pipeline de contratación todavía no cubre esas habilidades.”

¿Ves la diferencia? No discutes por el número de personas. Hablas de inversión, retorno y carencias de capacidad.

La interfaz de planificación que querrías usar de verdad

Las herramientas de planificación tradicionales se diseñaron para jefes de proyecto en 2005. Necesitas un máster en MS Project para entenderlas.

flowstate es distinto:

Arrastrar y soltar personas entre proyectos
Cálculo instantáneo de costes mientras asignas
Vistas de capacidad en tiempo real que muestran lo que de verdad es posible
Cruce de habilidades para ver si tienes las capacidades adecuadas
Planificación de escenarios sin copiar hojas de cálculo
Registro de auditoría automático de cada cambio y su motivo

Puedes modelar “¿y si contratáramos tres ingenieros senior el próximo trimestre?” en unos 30 segundos. Comparar escenarios lado a lado. Ver el impacto en fechas de entrega, costes y capacidad.

Dentro de seis meses, cuando alguien pregunte “¿por qué sacamos a esos ingenieros del equipo de pagos?”, podrás enseñarle:

La asignación original y el plan del proyecto
Quién lo cambió y cuándo
El comentario que explica el motivo de negocio
Qué impacto tuvo en los proyectos que dependían de él
Si la apuesta salió bien

Planificación colaborativa que funciona de verdad

Aquí se pone interesante. La planificación de escenarios en flowstate es colaborativa y en directo.

Piénsalo como Git para tu plan de ingeniería.

Puedes:

Crear tantos borradores de escenario como quieras
Compartir escenarios con las partes interesadas para que los revisen
Recibir comentarios e iterar
Aprobar un escenario y que se convierta en el nuevo plan
Hacer que los borradores de todos se actualicen solos con los cambios aprobados

Es colaborativo. Se actualiza en directo para todos los que lo miran. Puedes tirar tantos borradores como quieras. Pero solo hay una fuente de verdad al día, y actualiza como por arte de magia los borradores de cada uno con los cambios aprobados, así que siempre trabajas sobre la última versión.

Se acabó el “¿qué versión del plan estamos mirando?” Se acabó mandar hojas de cálculo por correo. Se acabó descubrir que finanzas trabajaba con las cifras de la semana pasada.

Commit. Merge. Rebase. Pero con más magia.

Replanificar sin sufrir

El mercado del software cambia rápido. Hay giros estratégicos. Se va gente clave. Las prioridades se mueven.

En el método flowstate, replanificar no significa empezar de cero. Significa:

Arrastrar proyectos para ajustar el calendario
Ver el impacto al instante en costes y entregas
Comparar escenarios antes de comprometerte
Dejar escrito el porqué para consultarlo en el futuro
Publicar el nuevo plan a las partes interesadas de forma automática

Lo que antes llevaba tres días ahora lleva treinta minutos.

Y como todo queda registrado como es debido, puedes responder a “¿por qué se pasó este proyecto de plazo?” con datos reales:

“Reasignamos 2,0 FTE a la incidencia de seguridad en la semana 3”
“La migración de la API tardó 6 semanas más por problemas de calidad de datos que descubrimos”
“Ampliamos el alcance en la semana 7 a raíz del feedback de clientes. Aquí está el cambio aprobado”

Ni corazonadas ni suposiciones. Hechos.

El método guía el producto (y no al revés)

No solo construimos software. Codificamos las mejores prácticas de líderes tecnológicos de distintos sectores.

El método flowstate es nuestra respuesta a:

¿Cómo debe estructurarse el trabajo de ingeniería para que sea visible?
¿Cuál es la unidad mínima viable de planificación que equilibra granularidad y sobrecarga?
¿Cómo equilibras la concentración (pocos proyectos) con la flexibilidad (prioridades cambiantes)?
¿Cómo se traducen las apuestas de ingeniería en los resultados financieros que de verdad le importan a finanzas?
¿Cómo haces que la planificación de escenarios sea lo bastante rápida para ser útil?
¿Cómo registras habilidades y capacidades, y no solo el número de personas?

Hablamos con:

CTO de empresas participadas por fondos y sometidas a escrutinio operativo
Scale-ups con crecimiento rápido y varios ciclos de planificación al año
Empresas medianas que intentan controlar por primera vez su gasto en ingeniería
Líderes de ingeniería hartos del infierno de las hojas de cálculo

Los problemas son los mismos. Las soluciones no deberían hacerse a medida.

Adónde vamos desde aquí

El escrutinio sobre el gasto en ingeniería nunca había sido tan alto. Los fondos exigen excelencia operativa. Los consejos presionan para expandir márgenes. Los directores financieros quieren ver en tiempo real adónde va el dinero.

A la vez, la naturaleza del trabajo de ingeniería está cambiando. Las referencias de productividad se mueven. Los modelos históricos de costes de ingeniería quedarán obsoletos en cuestión de meses.

Las organizaciones que lo resuelvan, las que puedan planificar de forma dinámica, medir con precisión y adaptarse rápido, tendrán una ventaja enorme. Las que sigan copiando pestañas de hojas de cálculo se quedarán atrás.

Construimos flowstate porque yo estaba harto de no tener respuestas. Harto de hojas de cálculo que se rompen. Harto de una planificación de escenarios que tarda tres días. Harto de explicar a los consejos por qué no podemos decirles lo que cuestan las cosas.

El método flowstate es nuestro intento de resolverlo bien. No con otro gestor de tareas. No con otro sustituto de hojas de cálculo. Sino con un marco de verdad para cómo deben planificar y medir el trabajo las organizaciones de ingeniería en 2025 y más allá.

Ayúdanos a pulirlo

Todavía estamos al principio. El software funciona, RAC y otros ya lo usan hoy, pero estamos afinando el método en conversaciones con líderes tecnológicos.

Si lidias con alguno de estos problemas, quiero hablar contigo:

¿Cómo haces ahora la planificación de escenarios? Cuando tu director financiero pregunta “¿y si recortamos un 20%?”, ¿cuál es tu proceso? ¿Hojas de cálculo? ¿Intuición? ¿Tres días de reuniones?

¿Cómo sigues el coste de las funcionalidades? ¿Puedes decirme ahora mismo lo que costó construir tus últimas tres funcionalidades grandes? No estimaciones. Costes reales.

¿Cómo justificas las peticiones de personal? ¿Cuál es tu argumento? ¿“Necesitamos más gente” o “Necesitamos 3,0 FTE durante seis meses para construir [cosa], que generará [valor]”?

¿Cómo gestionas las replanificaciones frecuentes? Si las prioridades cambian cada mes, ¿cómo mantienes los planes al día sin quemar semanas en administración?

¿Cómo cruzas habilidades con proyectos? ¿Puedes ver de un vistazo si tu capacidad disponible tiene las habilidades adecuadas para el trabajo que viene?

Los mejores marcos nacen de la sabiduría colectiva, no de la experiencia individual. Construimos flowstate para resolver problemas que yo he vivido, pero quiero asegurarme de que resolvemos también los que vives tú.

Si te suena, escríbenos: flowstate.inc

References

McKinsey & Company, How high performers optimize IT productivity for revenue growth: A leader’s guide ↩
McKinsey & Company, Breaking technical debt’s vicious cycle to modernize your business ↩ ↩²
McKinsey & Company, Developer Velocity: How software excellence fuels business performance ↩
OutSystems, Driving IT innovation forward: 3 imperatives for success ↩
Bain & Company, Global Private Equity Report 2025 ↩ ↩²
Panko, R. R. (2008). “What We Know About Spreadsheet Errors” & Poon, J., et al. (2024). “A review of spreadsheet errors: 35 years of research.” (The foundational academic papers.) The original link for Panko’s publication is dead, but I’ll leave it here for reference: panko.shidler.hawaii.edu/SSR/Mypapers/whatknow.htm ↩
PwC (2023). “FP&A Survey Results” ↩
Bruno J. Navarro, Workday (2022). “CFO-CIO Alignment Can Help Drive Digital Finance Transformation Goals, Global Research Finds.” ↩