A economia das equipes de software: por que a maioria das organizações de engenharia está financeiramente ‘vendada’

• A maioria das organizações de engenharia opera sem quantificar o custo por equipe e a geração de valor, o que leva a ineficiências financeiras
• O custo anual de uma equipe de 8 pessoas é de cerca de €1,04 milhão (€87 mil por mês, €4.000 por dia), então toda decisão — como desenvolver funcionalidades ou adiar melhorias — tem impacto monetário claro
• Tanto equipes de plataforma internas quanto equipes de produto voltadas ao cliente podem calcular o ponto de equilíbrio e o critério de geração de valor de 3 a 5 vezes, mas poucas organizações de fato acompanham isso
• A cultura dos últimos 20 anos, marcada por juros baixos e foco em crescimento, enfraqueceu a disciplina financeira e transformou grandes organizações e codebases complexas em passivos, não ativos
• Com a chegada dos LLMs, essas ineficiências estruturais ficam expostas, e as organizações que medem quantitativamente custo, valor e rentabilidade por equipe conquistarão vantagem competitiva de longo prazo

---

A economia das equipes de software: por que a maioria das organizações de engenharia está financeiramente ‘vendada’

• Analisa numericamente a estrutura de custos do desenvolvimento de software e a viabilidade econômica no nível da equipe, mostrando que a maioria das organizações opera sem ter consciência desses dados
• Considerando uma equipe de 8 pessoas, o custo é de cerca de €1,04 milhão por ano (€87 mil por mês), o que equivale a aproximadamente €4.000 por dia
• Tanto equipes de plataforma internas quanto equipes de produto voltadas ao cliente podem calcular quanto valor precisam gerar para ultrapassar o ponto de equilíbrio (break-even), mas quase nenhuma organização acompanha isso na prática
• O ambiente de juros baixos e a cultura orientada ao crescimento dos últimos 20 anos enfraqueceram a disciplina financeira, levando muitas empresas a confundir grandes organizações de engenharia e codebases complexas com “ativos”
• Com a chegada dos LLMs (grandes modelos de linguagem), essas ineficiências estruturais ficam evidentes, e as organizações que medem com clareza o custo e a geração de valor de cada equipe passam a obter vantagem competitiva

Estrutura real de custos de uma equipe

• Na Europa Ocidental, o custo total anual por engenheiro de software gira em torno de €120.000~€150.000, com média de €130.000
  • Inclui salário, encargos sociais, aposentadoria, equipamentos, custos administrativos e espaço de escritório
• O custo total anual de uma equipe de 8 pessoas é de €1.040.000, ou €86.667 por mês e €4.000 por dia
• A maioria dos engenheiros e até dos gestores desconhece esses números, e a percepção de custo não entra no processo de definição de prioridades
• Toda decisão — desenvolver uma funcionalidade, adiar uma melhoria ou reconstruir uma plataforma — envolve um custo monetário claro
  • Ex.: 3 semanas desenvolvendo uma funcionalidade para 2% dos usuários é uma decisão de cerca de €60.000

Cálculo do ponto de equilíbrio para equipes de plataforma internas

• Supondo uma equipe de plataforma de 8 pessoas dando suporte a 100 engenheiros
  • Custo mensal de €87.000, que precisa ser compensado pela mesma quantia em valor gerado
• O custo mensal por engenheiro é de €10.800 (€65 por hora)
  • Com base em 100 pessoas, economizar 1.340 horas por mês (3 horas por semana por pessoa) atinge o ponto de equilíbrio
• Além da simples economia de tempo, também pode haver proteção direta de receita por meio da redução de incidentes, por exemplo
• Porém, a maioria das equipes não mede esses números nem os incorpora na tomada de decisão
• Um critério realista de saúde financeira é gerar 3 a 5 vezes o valor do custo (de €260 mil a €430 mil por mês)
  • É preciso considerar custos de manutenção e substituição do sistema, além da taxa de fracasso (50~70%)
  • Não basta apenas “empatar”; é necessário garantir rentabilidade sustentável

A mesma lógica para equipes de produto voltadas ao cliente

• Uma equipe de 8 pessoas voltada ao cliente também tem estrutura de custo de €87.000 por mês
  • Se a receita mensal por usuário for €50, o ponto de equilíbrio exige valor equivalente a 1.740 usuários, e o critério de 3 a 5 vezes exige valor correspondente a 5.000~8.700 usuários
• Melhorar o churn é a alavanca mais direta
  • Ex.: entre 50 mil usuários, um churn mensal de 2% (1.000 pessoas, €50.000 de perda) → eliminar a causa já cobre grande parte do ponto de equilíbrio
• Melhorar a taxa de ativação (activation) também é importante
  • Entre 10 mil novos usuários por mês, se só 30% ativam → uma melhora de 5 p.p. gera 500 conversões adicionais e €25.000 de receita extra
• O aumento da taxa de conversão (conversion) tem efeito semelhante
  • Em 20 mil testes, elevar a conversão de 4% para 4,5% gera 100 pagantes adicionais e €5.000 de receita extra
• Pequenas melhorias em vários indicadores podem se acumular e produzir grande efeito financeiro, mas a maioria das equipes não mede a ligação entre esses indicadores e os resultados financeiros

Por que não se faz medição financeira

• Muitas equipes acompanham apenas velocity, número de tickets, número de funcionalidades, NPS, CSAT e outros indicadores de atividade ou percepção
  • Eles não substituem métricas financeiras; pertencem a uma categoria completamente diferente
• Mesmo que indicadores de atividade melhorem, o desempenho financeiro pode piorar
  • Mais funcionalidades → podem ser as funcionalidades erradas
  • Maior engajamento → os usuários que realmente contribuem para a receita podem estar caindo
• Esses indicadores são escolhidos porque são fáceis de medir, reportar e “empacotar” como resultado
  • Métricas financeiras podem revelar verdades incômodas
• A maioria das organizações não constrói deliberadamente uma cultura de medição financeira transparente

O contexto dos últimos 20 anos

• 2002~2011: os juros eram baixos, mas a aversão a risco dos investidores ainda mantinha a disciplina financeira
• 2011~2022: a combinação de juros zero, volta da tolerância ao risco e lógica de crescimento do SaaS
  • Durante 11 anos, empresas foram “perdoadas” pelo crescimento mesmo com aumento acelerado de pessoal, baixa eficiência e prioridades erradas
• A geração de lideranças formada nesse período cresceu em um ambiente sem cobrança por desempenho financeiro
  • Por isso, mesmo após 2022, com o aumento do custo de capital, o comportamento não se ajusta automaticamente

O passivo das organizações de engenharia confundido com “ativo”

• Grandes codebases e organizações de engenharia foram tradicionalmente tratadas como ativos (asset)
  • Pela lógica de que acumulam regras de negócio, base técnica e capacidade organizacional
• Na prática, porém, constituem uma estrutura de passivos (liability) em que se acumulam carga de manutenção, custo de coordenação e lentidão decisória
  • O aumento da complexidade reduz a produtividade, eleva custos e estagna a receita
• No passado, o ambiente de juros baixos escondia esse passivo

• A realidade exposta pelos LLMs

  • O desenvolvedor Nathan Cavaglione usou agentes baseados em LLM para replicar 95% das funções centrais do Slack em 14 dias
  • O Slack foi desenvolvido ao longo de mais de 10 anos por milhares de engenheiros, com investimento de bilhões de euros
  • Nathan concluiu um produto semelhante em pouco tempo sem complexidade organizacional, arquitetura legada ou custo de coordenação
  • Isso mostra que a suposição de que escala, complexidade e código acumulado de grandes organizações são vantagem competitiva já não é mais válida
  • Existem problemas de manutenibilidade no código gerado por LLM, mas em ambientes agente-agente ele pode ter vantagem em custo e velocidade sobre a manutenção humana

O que define as organizações que sairão na frente

• O núcleo da competitividade é não a tecnologia, mas a capacidade analítica
  • Organizações que entendem claramente os limiares de custo, valor e rentabilidade de cada equipe têm vantagem estrutural
• Essas organizações conseguem:
  • Tomar decisões de Build vs Buy com base em economia real
  • Identificar equipes abaixo do limiar de rentabilidade
  • Quantificar a perda de valor causada por atrasos e reajustar prioridades
• Hoje, a maioria das organizações não tem infraestrutura de medição, fluxo de dados ou hábitos para isso
  • Construir isso é desconfortável, mas essencial
  • Pode revelar que uma equipe consumiu um trimestre inteiro em trabalho sem conexão financeira clara
• No passado, juros baixos e lógica focada em crescimento toleravam isso, mas em um cenário em que a IA derruba o custo de desenvolvimento e investidores exigem resultado financeiro, isso se torna insustentável
• Organizações que cultivam o hábito de questionar e medir claramente a economia por equipe acumulam, com o tempo, uma vantagem competitiva composta

[GN⁺]

Comentários do Hacker News

• O ponto central deste texto é que programar em si não é a parte difícil; o realmente difícil é descobrir o que deve ser programado
  Na prática, grande parte do trabalho consiste em explorar o espaço do problema criando primeiro a coisa errada e depois substituindo-a várias vezes
  Programar muitas vezes não é o produto final, mas sim um meio de esclarecer a definição do problema

  • Não acho que isso esteja sempre correto. Em alguns projetos, está claro o que precisa ser feito, mas a dificuldade de engenharia em si é extremamente alta
    Se for apenas combinar frameworks, pode até ser fácil, mas em ambientes com sistemas complexos, programar por si só é realmente difícil
  • Muito software na verdade não cria valor e às vezes até o reduz
    Já vi várias vezes um pedido simples virar um sistema gigantesco. Mas, se você investir com inteligência em infraestrutura como o Google, isso também pode virar vantagem competitiva
  • Esse conceito também existe fora da engenharia. Como no ditado da internet de que “postar uma resposta errada rende a resposta certa mais rápido”, tentativas erradas às vezes trazem insights melhores
    Mas esse tipo de abordagem muitas vezes parece improdutivo ou faz a pessoa ser vista como “aquela que fala coisas erradas”
  • Programar talvez não seja a parte mais difícil, mas ainda assim não é algo fácil
  • Isso pode ser verdade para desenvolvedores iniciantes, mas engenheiros experientes já sabem como construir de forma eficiente
    Muitos desenvolvedores acham que seu projeto é especial, quando na prática muitas vezes basta copiar um design já validado

• Como o texto diz, a preocupação de que código gerado rapidamente seja difícil de manter é válida, mas o argumento é que isso importa menos quando humanos não precisam fazer a manutenção
  Mas eu acho que a mesma lógica pode ser aplicada também ao “LLM coach ágil”. O LLM já consegue fornecer boa parte desses insights por um custo muito menor
  No fim, talvez os humanos possam relaxar à beira da piscina

  • Se uma AGI substituir meu trabalho, eu ainda ficarei responsável por validação e responsabilização. Se a camada gerencial desaparecer, talvez tudo fique até mais tranquilo
  • Hoje em dia, muitos textos sobre LLM parecem ter sido escritos por LLM. Materiais de treinamento à venda também parecem algo que dá para substituir por uma única linha de prompt
  • Estamos numa era em que o custo de aprender é quase zero, e o instrutor serve apenas para forçar o aprendizado

• Não concordo com a ideia de que “mesmo uma base de código bagunçada pode ser resolvida jogando vários agentes em cima”
  Na prática, existe muito código que por fora parece perfeito, mas por dentro é estruturalmente errado, como um prédio feito de espuma
  Com o tempo, esse tipo de código fica impossível de expandir e acaba endurecendo como tijolo

  • Com arquitetura e guardrails suficientes, agentes podem até funcionar bem. Sem isso, supervisão humana cuidadosa é indispensável
  • Se os agentes escreverem código “inteligente demais”, surge a questão: quem vai fazer o debugging?
  • A expressão “a arte sustenta a carga” foi realmente marcante
  • É uma ilusão perigosa a diretoria acreditar que a IA vai resolver tudo. Só poder computacional não basta
  • Se esse tipo de problema acontece, então não está faltando algo no próprio sistema de testes?

• Eu também já tive dois projetos feitos por IA que fracassaram completamente
  Mesmo adicionando mais agentes, não houve progresso, e o resultado produzido seguia quase sempre na direção errada

  • Tive uma experiência parecida. Apaguei mais de 40 mil linhas de código. Código gerado por IA quase sempre usa abstrações erradas
  • Isso parece uma espécie de fenômeno de Mythical Machine Month. Trocar pessoas por mais máquinas não aumenta a produtividade
  • Ao lidar com IA, vejo com frequência padrões parecidos com falhas de atenção humanas. No fim, é uma questão de contexto e foco
  • A propriedade do código continua sendo humana. O fato de ter sido criado por IA não elimina essa responsabilidade
  • A IA entra em dívida técnica do mesmo jeito que humanos. Mas talvez tenha potencial como ferramenta para facilitar reescritas

• Concordo com a afirmação de que desenvolvimento de software é uma atividade intensiva em capital, mas o contexto varia conforme a indústria
  Empresas de energia ou fabricantes têm custos de manutenção de infraestrutura física muito maiores do que os de TI
  Ainda assim, como o número de contratos de SaaS cresceu demais, mais empresas estão se perguntando se contratar desenvolvedores de LLM não seria economicamente melhor

  • Até em órgãos públicos, como departamentos de transporte, já existe a percepção de que o gasto com SaaS está excessivo. Quando a gestão perceber isso de fato, muitos contratos desnecessários serão cortados
  • Mas SaaS não vai desaparecer totalmente. É preciso uma estrutura capaz de assumir responsabilidade e risco jurídico
  • Construir uma fábrica farmacêutica custa dezenas de bilhões de dólares. Em setores assim, o custo de software é quase irrelevante

• Eu estava lendo o texto com interesse, mas perdi a confiança no exemplo de clone do Slack
  É uma afirmação que não entende absolutamente nada da escala, confiabilidade e funcionalidade reais do Slack

  • Slack não é um produto que dá para simplesmente copiar. É o resultado de inúmeras tentativas e erros, além de muito feeling de produto
  • A expressão “95% de clone” já bastou para destruir minha confiança
  • Universitários também fazem clones do Twitter, mas o concorrente real não é o código, e sim o mercado e o ecossistema
  • Eu também consigo fazer um clone do Slack em duas semanas, mas só implementar direito um recurso de retenção legal já levaria meses
    Produtos corporativos exigem centenas de detalhes desse tipo. Simples cópia não é competição
  • Construir o Slack não foi só codificar, e sim descobrir o que deveria ser construído

• Textos que jogam um monte de números e gráficos parecem escritos por alguém tentando vencer um debate
  Como diz Rory Sutherland, “Finance People” são obcecadas por certeza e previsibilidade
  Mas o mundo não é tão simples assim

  • Cálculos precisos ajudam na decomposição do problema como efeito colateral. Mas, no fim, o que conquista o mercado é entendimento profundo do problema e visão
  • A matemática dele não bate com a realidade. O sucesso de um produto é imprevisível, e investir em si já é uma aposta
  • A verdade sempre está em algum ponto no meio. É preciso equilíbrio entre números e sensibilidade
  • Equipes com as ferramentas e métricas corretas de medição têm desempenho melhor no longo prazo
  • Ainda assim, pelo menos é preciso formular uma hipótese sobre como uma funcionalidade afetará a receita para manter um negócio sustentável

• Mais do que os detalhes do texto, eu me identifiquei com a ideia de uma cultura de engenharia que não pensa em valor versus custo
  Em reuniões ou na resposta a incidentes, muitas vezes são tomadas medidas excessivas sem avaliar custo-benefício
  Com dívida técnica é a mesma coisa: sem conhecer o custo, não dá para fazer escolhas responsáveis

  • Um desperdício ainda maior do que reuniões são projetos ou funcionalidades errados. Eles arrastam manutenção e complexidade indefinidamente

• O cálculo simplista de que “a equipe de plataforma deve provar valor economizando tempo” está errado
  Equipes de plataforma não existem apenas para poupar tempo, mas para reduzir risco de negócio e garantir qualidades essenciais

  • A razão de existir dessas equipes é centralizar esforços duplicados e manter a separação entre segurança e operação
    Isso não é apenas lógica econômica, e sim uma questão de infraestrutura essencial da organização

• No fim, o que importa é se a equipe realmente se importa com o produto
  Só equipes que valorizam o produto mais do que ganhos de carreira de curto prazo conseguem gerar resultados reais além de métricas e técnicas de gestão
  Mas alguns projetos já nascem com uma estrutura em que é impossível criar apego, e aí o limite de produtividade fica claro