La economía de los equipos de software: por qué la mayoría de las organizaciones de ingeniería están financieramente ‘con los ojos vendados’

• La mayoría de las organizaciones de ingeniería operan sin cuantificar por equipo el costo y el valor que generan, lo que conduce a ineficiencia financiera
• El costo anual de un equipo de 8 personas es de aproximadamente €1.04 millones (€87 mil al mes, €4,000 al día), por lo que cada decisión —como desarrollar una función o retrasar una mejora— tiene un impacto monetario claro
• Tanto los equipos de plataforma interna como los equipos de producto orientados al cliente pueden calcular su punto de equilibrio y el umbral de creación de valor de 3 a 5 veces, pero pocas organizaciones realmente lo siguen
• Durante los últimos 20 años, una cultura de tasas de interés bajas y enfoque en el crecimiento debilitó la disciplina financiera, convirtiendo a las grandes organizaciones y a las bases de código complejas en pasivos y no en activos
• La aparición de los LLM deja al descubierto estas ineficiencias estructurales, y las organizaciones que miden cuantitativamente por equipo el costo, el valor y la rentabilidad obtendrán una ventaja competitiva de largo plazo

---

La economía de los equipos de software: por qué la mayoría de las organizaciones de ingeniería están financieramente ‘con los ojos vendados’

• Se analiza con cifras la estructura de costos del desarrollo de software y la viabilidad económica a nivel de equipo, y la mayoría de las organizaciones opera sin tener conciencia de estos datos
• Tomando como referencia un equipo de 8 personas, el costo es de aproximadamente €1.04 millones al año (€87 mil al mes), equivalente a unos €4,000 al día
• Tanto los equipos de plataforma interna como los equipos de producto orientados al cliente pueden calcular cuánto valor deben generar para superar el punto de equilibrio (break-even), pero casi ninguna organización lo rastrea en la práctica
• Durante los últimos 20 años, el entorno de tasas bajas y la cultura centrada en el crecimiento debilitaron la disciplina financiera, haciendo que se confundiera a las grandes organizaciones de ingeniería y a las bases de código complejas con ‘activos’
• La llegada de los LLM (modelos de lenguaje grandes) expone estas ineficiencias estructurales, y las organizaciones que midan con claridad el costo y el valor generado por cada equipo obtendrán ventaja competitiva

Estructura real de costos de un equipo

• En Europa Occidental, el costo total anual por ingeniero de software es de entre €120,000 y €150,000, con un promedio de €130,000
  • Incluye salario, seguridad social, pensión, equipo, gastos de gestión y espacio de oficina
• El costo total anual de un equipo de 8 personas es de €1,040,000, €86,667 al mes y €4,000 al día
• La mayoría de los ingenieros e incluso de los gerentes desconoce estas cifras, y la conciencia del costo no se refleja en el proceso de priorización
• Todas las decisiones —desarrollo de funciones, retrasos en mejoras, reconstrucción de plataformas— implican un costo monetario claro
  • Ejemplo: 3 semanas de desarrollo de una función para el 2% de los usuarios es una decisión de aproximadamente €60,000

Cálculo del punto de equilibrio de un equipo de plataforma interna

• Supongamos que un equipo de plataforma de 8 personas da soporte a 100 ingenieros
  • Su costo mensual es de €87,000, por lo que debe generar un valor equivalente para compensarlo
• El costo mensual por ingeniero es de €10,800 (€65 por hora)
  • Con 100 personas, se alcanza el punto de equilibrio si se ahorran 1,340 horas al mes (3 horas por semana por persona)
• Más allá del simple ahorro de tiempo, también puede haber un efecto directo de protección de ingresos por reducción de incidentes
• Sin embargo, la mayoría de los equipos no mide estas cifras ni las incorpora en la toma de decisiones
• Un criterio realista de solidez financiera es generar de 3 a 5 veces el valor (entre €260 mil y €430 mil al mes)
  • Hay que considerar los costos de mantenimiento y reemplazo del sistema, así como la tasa de fracaso (50~70%)
  • No basta con el simple ‘punto de equilibrio’; se necesita rentabilidad sostenible

La misma lógica para los equipos de producto orientados al cliente

• Un equipo de 8 personas orientado al cliente también tiene una estructura de costos de €87,000 al mes
  • Si el ingreso mensual por usuario es de €50, el punto de equilibrio requiere valor equivalente a 1,740 usuarios, y bajo el criterio de 3 a 5 veces se necesita valor equivalente a 5,000~8,700 usuarios
• La mejora del churn es la palanca más directa
  • Ejemplo: de 50,000 usuarios, una baja mensual del 2% (1,000 usuarios, €50,000 de pérdida) → si se elimina la causa, se cubre la mayor parte del punto de equilibrio
• También es importante mejorar la tasa de activación (activation)
  • De 10,000 nuevos usuarios mensuales, solo el 30% se activa → una mejora de 5 puntos porcentuales genera 500 conversiones adicionales y €25,000 extra de ingresos
• El aumento de la tasa de conversión (conversion) produce el mismo efecto
  • De 20,000 pruebas, pasar de 4% a 4.5% añade 100 usuarios de pago, es decir, €5,000 extra de ingresos
• Pequeñas mejoras acumuladas en varias métricas pueden producir un gran efecto financiero, pero la mayoría de los equipos no mide el vínculo entre estas métricas y los resultados financieros

Por qué no se hace medición financiera

• Muchos equipos solo siguen métricas de velocity, cantidad de tickets, número de funciones, NPS, CSAT y otras métricas de actividad o percepción
  • Estas no sustituyen a las métricas financieras, sino que pertenecen a otra categoría por completo
• Incluso si las métricas de actividad mejoran, el desempeño financiero puede empeorar
  • Más funciones → pueden ser funciones equivocadas
  • Más engagement → puede disminuir la cantidad de usuarios que realmente aportan ingresos
• Estas métricas se eligen porque son fáciles de medir, reportar y “empaquetar” como resultado
  • Las métricas financieras pueden revelar verdades incómodas
• La mayoría de las organizaciones no construye deliberadamente una cultura de medición financiera transparente

El trasfondo de los últimos 20 años

• 2002~2011: las tasas eran bajas, pero la aversión al riesgo de los inversionistas mantenía la disciplina financiera
• 2011~2022: se combinaron tasas cercanas a cero, regreso del apetito por el riesgo y la lógica de crecimiento del SaaS
  • Durante 11 años, las empresas fueron “perdonadas” por su crecimiento aunque aumentaran su plantilla, operaran con baja eficiencia o priorizaran mal
• La generación de líderes formada en este período creció en un entorno donde no se exigía desempeño financiero
  • Por eso, incluso después de 2022, con el aumento del costo del capital, su comportamiento no se ajusta automáticamente

El pasivo de las organizaciones de ingeniería confundido con ‘activo’

• Las grandes bases de código y las organizaciones de ingeniería tradicionalmente se consideran activos (asset)
  • Por la lógica de negocio acumulada, la base técnica y la capacidad organizacional
• En realidad, tienen una estructura de pasivo (liability) en la que se acumulan la carga de mantenimiento, los costos de coordinación y la lentitud en la toma de decisiones
  • A mayor complejidad, menor productividad, mayores costos y estancamiento de ingresos
• En el pasado, el entorno de tasas bajas ocultó ese pasivo

• La realidad que dejó al descubierto el LLM

  • El desarrollador Nathan Cavaglione usó agentes LLM para replicar en 14 días el 95% de las funciones principales de Slack
  • Slack fue desarrollado durante más de 10 años por miles de ingenieros, con inversiones de miles de millones de euros
  • Nathan completó un producto similar en poco tiempo sin complejidad organizacional, arquitectura heredada ni costos de coordinación
  • Esto muestra que ya no es válida la suposición de que la escala, la complejidad y el código acumulado de una gran organización son una ventaja competitiva
  • Existen problemas de mantenibilidad en el código generado por LLM, pero en un entorno de agente a agente tiene ventaja en costo y velocidad frente al mantenimiento humano

Qué condiciones tendrán las organizaciones que se adelanten

• El núcleo de la competitividad es la capacidad de análisis, no la tecnología
  • Las organizaciones que entienden con claridad los costos, el valor y los umbrales de rentabilidad de cada equipo tienen una ventaja estructural
• Estas organizaciones pueden hacer lo siguiente
  • Tomar decisiones de Build vs Buy con base en la economía real
  • Identificar equipos por debajo del umbral de rentabilidad
  • Cuantificar la pérdida de valor causada por retrasos para reajustar prioridades
• La mayoría de las organizaciones hoy carece de infraestructura de medición, flujo de datos y hábitos
  • Construirlos es incómodo, pero indispensable
  • Puede revelar que un equipo gastó todo un trimestre en trabajo sin conexión financiera
• Antes, las tasas bajas y la lógica centrada en el crecimiento lo toleraban, pero en un entorno donde la IA reduce drásticamente el costo de desarrollo y los inversionistas exigen resultados financieros, eso ya no es sostenible
• Las organizaciones que adopten el hábito de preguntar y medir con claridad la economía por equipo irán acumulando con el tiempo una ventaja competitiva compuesta

[GN⁺]

Comentarios de Hacker News

• La idea central de este artículo es que programar en sí no es lo difícil, sino averiguar qué hay que programar; esa es la parte realmente complicada
  En la práctica, gran parte del trabajo consiste en explorar el espacio del problema construyendo primero algo equivocado y reemplazándolo varias veces
  Muchas veces, programar no es el producto final, sino más bien un medio para aclarar la definición del problema

  • No creo que eso siempre sea cierto. En algunos proyectos está claro qué hay que construir, pero la dificultad de ingeniería en sí es extremadamente alta
    Si solo se trata de combinar frameworks, puede ser fácil, pero en entornos donde se manejan sistemas complejos, programar en sí mismo sí es realmente difícil
  • En muchos casos, el software en realidad no crea valor, sino que lo reduce
    He visto muchas veces cómo una solicitud simple termina convirtiéndose en un sistema enorme. Pero si se invierte con inteligencia en infraestructura, como hace Google, también se puede lograr una ventaja competitiva
  • Este concepto también existe fuera de la ingeniería. Como ese dicho de internet de que “si publicas una respuesta incorrecta, obtendrás la correcta más rápido”, los intentos equivocados a veces dan mejores ideas
    Pero este enfoque suele parecer improductivo o hacer que te malinterpreten como “la persona que dice cosas incorrectas”
  • Programar quizá no sea lo más difícil de todo, pero no hay que olvidar que sigue sin ser algo fácil
  • Tal vez esto aplique para desarrolladores junior, pero los ingenieros con experiencia ya saben cómo construir de manera eficiente
    Muchos desarrolladores creen que su proyecto es especial, pero en realidad muchas veces basta con copiar un diseño ya probado

• Como dice el artículo, es válido preocuparse de que si el código se genera rápido será difícil de mantener, pero también se afirma que eso importa menos mientras no lo mantengan humanos
  Pero yo creo que esa misma lógica también puede aplicarse al “LLM coach ágil”. Los LLM ya pueden ofrecer la mayoría de esas ideas a un costo mucho menor
  Al final, quizá los humanos puedan relajarse junto a la piscina

  • Si AGI reemplaza mi trabajo, yo seguiría encargándome de la validación y la responsabilidad. Si desaparece la capa de gestión, quizá hasta sea más tranquilo
  • Hoy en día, muchos textos sobre LLM parecen escritos por un LLM. Incluso el material educativo que se vende parece sustituible por una sola línea de prompt
  • Ahora vivimos en una época en la que el costo de aprender es casi cero, y el instructor solo cumple el papel de forzar el aprendizaje

• No estoy de acuerdo con la idea de que “aunque el código base sea un desastre, metiendo varios agentes se arregla”
  En la práctica, hay mucho código que por fuera parece perfecto, pero por dentro está estructuralmente mal, como un edificio hecho de espuma
  Ese tipo de código con el tiempo se vuelve imposible de extender y termina endureciéndose como ladrillo

  • Si hay suficiente diseño de arquitectura y guardrails, los agentes también pueden funcionar bien. Si no, la supervisión humana minuciosa es indispensable
  • Si los agentes escriben código demasiado “ingenioso”, entonces surge la pregunta de quién va a hacer el debugging
  • La expresión “el arte soporta la carga” me pareció realmente impactante
  • Que la gerencia crea que la IA va a resolverlo todo es una ilusión peligrosa. No se soluciona solo con poder de cómputo
  • Si ocurren este tipo de problemas, ¿no será que al sistema de pruebas le está faltando algo?

• Yo también tuve la experiencia de que dos proyectos hechos por IA fracasaron por completo
  Aunque metieras más agentes, no había progreso, y la mayoría de los resultados iban en la dirección equivocada

  • Yo tuve una experiencia similar. Terminé borrando más de 40 mil líneas de código. El código generado por IA casi siempre usa abstracciones equivocadas
  • Esto se parece a una especie de fenómeno de Mythical Machine Month. Aunque aumentes las máquinas en lugar de personas, la productividad no sube
  • Al trabajar con IA, muchas veces veo patrones parecidos a los fallos de atención humanos. Al final, es un problema de contexto y concentración
  • La propiedad del código sigue siendo del humano. Que lo haya generado una IA no elimina esa responsabilidad
  • La IA cae en deuda técnica igual que los humanos. Aun así, sí tiene potencial como herramienta para facilitar reescrituras

• Estoy de acuerdo con la afirmación de que el desarrollo de software es una actividad intensiva en capital, pero el contexto cambia según la industria
  Para una eléctrica o una manufacturera, el costo de mantener infraestructura física es mucho mayor que el de TI
  Aun así, como ya hay demasiados contratos SaaS, cada vez más empresas se preguntan si no sería más económico contratar desarrolladores de LLM

  • Incluso en organismos públicos como autoridades de transporte, ya existe la percepción de que el gasto en SaaS es excesivo. En cuanto la capa administrativa lo note, seguramente se recortarán muchos contratos innecesarios
  • Pero SaaS no va a desaparecer por completo. Se necesita una estructura capaz de asumir la responsabilidad y el riesgo legal
  • Una planta farmacéutica cuesta miles de millones de dólares solo en construcción. En industrias así, el costo del software es mínimo

• Venía leyendo el artículo con interés, pero perdí la confianza con el ejemplo de copiar Slack
  Es una afirmación que no entiende en absoluto la escala, estabilidad y funcionalidad reales de Slack

  • Slack no es un producto que simplemente se pueda copiar. Es el resultado de innumerables pruebas, errores y mucho criterio de producto
  • Desde lo de “95% de copia” ya se vino abajo mi confianza
  • Los universitarios también hacen clones de Twitter, pero el competidor real no es el código, sino el mercado y el ecosistema
  • Yo también podría hacer un clon de Slack en dos semanas, pero solo implementar correctamente la función de conservación legal ya tomaría meses
    Los productos empresariales necesitan cientos de detalles como ese. Copiar por copiar no es competir
  • Construir Slack no fue solo programar, sino descubrir qué había que construir

• Los textos que solo arrojan un montón de cifras y gráficos parecen escritos por alguien que quiere ganar una discusión
  Como dice Rory Sutherland, la “gente de finanzas” está obsesionada con la certeza y la previsibilidad
  Pero el mundo no es tan simple

  • Los cálculos precisos ayudan a descomponer problemas como efecto secundario. Pero al final, lo que conquista el mercado es una comprensión profunda del problema y una visión clara
  • Sus matemáticas no encajan con la realidad. El éxito de un producto es impredecible y invertir en sí mismo es una apuesta
  • La verdad siempre está en algún punto intermedio. Hace falta equilibrio entre números e intuición
  • Los equipos que cuentan con las herramientas de medición e indicadores correctos consiguen mejores resultados a largo plazo
  • Aun así, por lo menos hay que formular una hipótesis sobre cómo una función impactará los ingresos para tener un negocio sostenible

• Más que los detalles del artículo, me identifiqué con la idea de una cultura de ingeniería que no piensa en el valor frente al costo
  En reuniones o durante la respuesta a incidentes, muchas veces se toman medidas excesivas sin evaluar costo versus beneficio
  Con la deuda técnica pasa lo mismo: si no conoces el costo, no puedes tomar decisiones responsables

  • Un desperdicio todavía mayor que las reuniones son los proyectos o funciones equivocados. Arrastran mantenimiento y complejidad sin fin

• Es incorrecto ese cálculo simplista de que el equipo de plataforma debe demostrar su valor ahorrando tiempo
  El equipo de plataforma no solo ahorra tiempo, sino que reduce el riesgo del negocio y garantiza cualidades clave

  • La razón de existir del equipo de plataforma es centralizar esfuerzos duplicados y mantener la separación entre seguridad y operaciones
    No es solo una lógica económica simple, sino un tema de infraestructura esencial de la organización

• Al final, lo importante es si al equipo realmente le importa el producto
  Solo los equipos que valoran el producto más que su carrera a corto plazo logran resultados reales más allá de métricas o técnicas de gestión
  Pero hay proyectos cuya estructura desde el principio hace imposible encariñarse con ellos, y ahí el límite de productividad queda muy claro