Como você explica os £20M gastos com engenharia?

Eu conheço a dor de tentar justificar o custo de engenharia de software. Seja explicando estouro de projeto para diretores financeiros de uma grande empresa, seja projetando o burn rate para investidores de uma startup, a conversa é sempre a mesma.

O CFO ou o investidor pergunta: “Estamos gastando £15 milhões em engenharia. O que a gente recebe por isso?”

Você abre a planilha. Tem número de headcount. Tem faixa salarial. Tem uma lista de projetos em andamento. Mas quando perguntam “Quanto custou de verdade a reconstrução do checkout?” ou “Qual foi o ROI daquela migração de plataforma de seis meses?”, você chuta.

Liderei times de engenharia em startups e em organizações maiores, com no máximo 30 engenheiros por vez. A escala muda, mas o problema é idêntico em qualquer lugar: ninguém sabe dizer quanto as coisas realmente custam.

Nem as funcionalidades. Nem os projetos. Nem as “iniciativas estratégicas” que consomem trimestres inteiros. O dinheiro some num buraco negro chamado “Engenharia” e todo mundo torce para que saia do outro lado como receita.

E não são só salários. Esses £15 milhões incluem pessoas, claro, mas também gasto com IA, licenças de software, infraestrutura de nuvem e hardware. A conta completa da engenharia. Mesmo assim, a maioria das organizações não consegue abrir nada disso.

Minha experiência passa pelos dois mundos. Em startups, tive que projetar custos para investidores que queriam entender a unit economics antes da Série A. Em empresas grandes, tive que explicar para diretores financeiros por que um projeto de seis meses agora estava projetado para doze. As desculpas mudam, o problema de fundo não: falta a infraestrutura básica para medir o que o trabalho de engenharia realmente custa.

O problema não é novo, mas está piorando

Isto é o que ouço de quase todo líder de tecnologia com quem converso:

“Acabamos jogando os custos num balde central porque não conseguimos fechar o ciclo dentro do mês.”

Tradução: a gente não sabe quanto gasta com o quê, então joga tudo num balde genérico e chama de “Time de Plataforma, 3º tri”. O financeiro odeia. O conselho questiona. Mas o que mais você pode fazer?

“Se eu cortar 20% do headcount ou mover times, quero ver o impacto na hora.”

Mas você não vê. Porque a sua “ferramenta de planejamento” é uma planilha com 47 abas que quebra se você apagar uma linha. Quando você termina de modelar o cenário, o conselho já decidiu no feeling.

“Gastamos £20 milhões com pessoas. Preciso mostrar que estamos gastando bem.”

Essa tira o sono de CTO. Você sabe que está gastando bem. Sabe que seus times são bons. Mas não consegue provar com dados, porque os dados não existem.

“Temos que replanejar a cada poucos meses, quando as prioridades ou as pessoas mudam.”

E cada replanejamento custa três dias de reunião, mais uma rodada de planilhas e o mesmo processo doloroso do trimestre passado.

Por que o planejamento morre no dia em que sai do forno

A maioria das organizações de engenharia faz planejamento trimestral. Você gasta de 4 a 6 semanas montando o plano do próximo trimestre. Na semana sete, alguém pede demissão. Na semana nove, aparece do nada uma “prioridade estratégica”. Na semana doze, o plano original virou ficção histórica.

Veja como o tempo da liderança de engenharia realmente se divide:

Reuniões (planejamento, alocação, revisões): 17,9 horas/semana, 7 horas a mais que os contribuidores individuais
Tempo fragmentado: 7,1 horas/semana, gera uma perda de 40% de produtividade
Tempo de foco: 10,4 horas/semana, só 2,6 horas sem interrupção

Essas 17,9 horas semanais de reunião? Uma parte grande é planejamento: kickoffs trimestrais que se arrastam por 4 a 6 semanas, revisões no meio do trimestre, discussões de alocação de recursos, justificativas de orçamento. Fazendo a conta, líderes de engenharia passam cerca de um terço de cada trimestre planejando o próximo. Você está sempre seis semanas atrás da realidade, porque quando termina de planejar, o mundo já mudou.

E o que você está planejando? Segundo uma pesquisa da McKinsey, times de engenharia gastam de 40 a 60% do tempo com manutenção e operação, e não com novas capacidades¹. Mas você consegue me dizer quais são esses 40 a 60%? Consegue mostrar quais engenheiros estão em quais projetos e se esses projetos são CapEx ou OpEx?

Claro que não. Porque acompanhar isso exige atualizar uma planilha toda semana, e todos nós sabemos que isso nunca acontece.

O ponto cego entre CapEx e OpEx

Aqui a coisa fica dolorosa. Seu CFO precisa saber se o trabalho de engenharia está construindo novas capacidades (CapEx) ou mantendo as existentes (OpEx). Isso não é frescura contábil. Muda por completo a forma como o trabalho é financiado e medido.

A McKinsey descobriu que, em algumas organizações, os desenvolvedores passam mais de 50% do tempo só lidando com dívida técnica ². É a diferença entre uma organização de engenharia estratégica e um time que vive apagando incêndio.

Já as empresas do quartil superior (segundo o Developer Velocity Index) gastam 33% menos tempo com trabalho manual e indiferenciado, o que libera esse tempo para inovar ³.

Mas o pior é isto: o problema é quase universal. Uma pesquisa de 2023 constatou que 91% dos líderes de TI apontam a dívida técnica como o maior obstáculo à inovação ⁴. Mesmo assim, muitas empresas só “reservam de 15 a 20% do orçamento de TI para tratar a dívida técnica”, uma fatia que a McKinsey considera muitas vezes insuficiente ².

Você consegue mostrar ao conselho em qual balde cada engenheiro cai? Consegue demonstrar que está saindo de 50% de peso de dívida técnica para 30%? Ou está só torcendo para ninguém perguntar?

A panela de pressão do private equity

Por que isso importa mais do que nunca: o volume de aquisições de private equity voltou a crescer e chegou a $602 bilhões em 2024, uma alta de 37% em relação ao ano anterior ⁵. O setor de tecnologia foi o principal motor, com 33% de todas as aquisições por valor no mundo ⁵.

Mas o jogo mudou. Olhe como os fundos criam valor ao longo do tempo:

A excelência operacional passou de 18% para 47% da criação de valor. A engenharia financeira (alavancagem e expansão de múltiplo) caiu de 51% para 25%.

O que isso significa para você? Se você comanda a engenharia de uma empresa controlada por um fundo, tem 90 dias para mostrar como gasta o dinheiro e de 12 a 24 meses para mostrar ganhos de eficiência que façam diferença.

“Vamos contratar mais engenheiros” não é um plano. “Vamos alocar 8,5 FTE em três projetos com estes retornos esperados” é um plano.

E adivinhe o que os operating partners dos fundos estão pedindo?

Custo real por projeto (não estimativa, não chute)
Alocação de OpEx e CapEx em toda a organização de engenharia
Taxas de utilização de recursos
Custo de desenvolvimento de funcionalidades com números de verdade
Roadmap de expansão de margem com os vetores de eficiência da engenharia

A maioria dos líderes de tecnologia não responde nada disso.

O imposto do erro de planilha

Isto deveria te dar pavor: revisões acadêmicas, incluindo uma análise recente de 35 anos, concluem de forma consistente que 88 a 94% das planilhas usadas em decisões críticas de negócio contêm erros ⁶. Não é erro de digitação. Quase toda planilha que guia o planejamento de custo da sua engenharia tem falhas.

Ainda assim, a PwC relata que 80% das organizações continuam dependendo de planilhas para o planejamento e a análise financeira (FP&A) ⁷.

Isso não é um problema técnico. É uma crise organizacional. Quando seu CFO não confia nos seus números porque eles foram feitos no Excel, você perde credibilidade. Quando ele pede análise de cenários e você precisa de três dias copiando abas, você perde influência.

Esse desalinhamento é endêmico. A Workday constatou que só 30% dos CFOs dizem estar bem alinhados com seus CIOs sobre o roadmap digital e de tecnologia da empresa ⁸. Como alinhar quando vocês falam línguas diferentes? Finanças fala de centros de custo e previsões trimestrais. Engenharia fala de story points e velocidade de sprint.

O que falta: uma unidade mínima viável

O problema não é que precisamos de gráficos de Gantt melhores. É que não temos uma unidade mínima viável para medir o trabalho de engenharia.

Finanças tem uma hierarquia clara:

Itens de linha → Centros de custo → Departamentos → Gasto total

A manufatura tem:

Componentes → Produtos → Linhas de produção → Volume produzido

E software?

Story points (não significam nada fora do seu time)
Funcionalidades (granulares demais)
Produtos (amplos demais)
“Investimento em plataforma” (pode ser qualquer coisa)

As startups são especialmente cegas. Pergunte a qualquer fundador quanto custou construir o novo fluxo de checkout, não em story points, mas em dinheiro gasto com salários, custos indiretos e custo de oportunidade, e você vai receber um dar de ombros.

É isso que estamos resolvendo na flowstate. Comecei a chamar essa disciplina de Workforce Engineering: projetar de forma deliberada como uma organização emprega sua força de trabalho para produzir resultados. Em breve falo mais sobre isso.

O método flowstate: Workforce Engineering na prática

Não estamos construindo mais uma ferramenta de gerenciamento de projetos. Estamos construindo um framework para como as organizações de engenharia devem planejar, acompanhar e medir o trabalho.

Pense assim:

Agile foi a metodologia de desenvolvimento de software
O Linear Method foi para o controle de issues e o fluxo de produto
O método flowstate é para a economia da engenharia e a visibilidade de custos

O princípio central: o investimento em engenharia deve ser estruturado em torno de apostas, não de backlogs.

Projetos como Apostas Mínimas Viáveis

Aqui a gente tem opinião. No método flowstate, um projeto é:

No mínimo 1,0 FTE da capacidade mensal de um time
No máximo 4 projetos simultâneos por time por trimestre
De um único time, sempre que possível
Alinhado a um centro de custo, para o financeiro conseguir acompanhar
Casado com as habilidades certas, para garantir que os times tenham as capacidades necessárias

Por que no mínimo 1,0 FTE? Porque qualquer coisa menor não é uma aposta. É uma tarefa fantasiada de estratégia. Se você não topa dedicar pelo menos uma pessoa-mês a algo, você não leva aquilo a sério.

Por que no máximo 4 por trimestre? Porque foco é um recurso escasso. Um time que tenta fazer mais de quatro coisas relevantes ao mesmo tempo não está fazendo nenhuma direito.

Essa estrutura te dá:

Visibilidade real de custo: você sabe quanto custou “reconstruir o checkout” porque vê os projetos que o compõem e a alocação de FTE de cada um
Planejamento de cenários que funciona: moveu um time? Veja na hora quais projetos perdem capacidade
Acompanhamento de ROI de verdade: você mede se a aposta valeu a pena porque sabe o que apostou
Equilíbrio de habilidades: case os requisitos do projeto com as capacidades do time, não só o headcount, mas as habilidades de fato

Pessoas são mais do que FTEs

É aqui que a maioria das ferramentas de planejamento de engenharia falha: elas tratam todo mundo como recurso intercambiável. A flowstate não.

Nós acompanhamos:

Função (Engenheiro Frontend, Engenheiro Backend, DevOps etc.)
Nível (Júnior, Pleno, Sênior, Staff, Principal)
Habilidades (React, Python, AWS, PostgreSQL etc.)

Isso significa que, ao planejar um projeto novo, você pode perguntar: “Temos as habilidades certas disponíveis?” E não só: “Temos capacidade?”

Você pode ver que seu time tem 4,0 FTE disponíveis, mas só 1,5 FTE com as habilidades de React que o trabalho de frontend exige. Isso muda o seu planejamento. Talvez você precise contratar diferente. Talvez precise ajustar o escopo do projeto. Talvez precise qualificar alguém.

Mas pelo menos você sabe. E isso é melhor do que descobrir a lacuna de habilidades seis semanas depois do começo do projeto.

Iniciativas se desdobram para baixo, não para cima

O trabalho estratégico grande, as iniciativas, não existe como bloco único na flowstate. Ele se desdobra em projetos menores, cada um pertencente a um único time, com alocação clara de FTE.

Assim, quando o CFO perguntar “Quanto custou a reconstrução do checkout?”, você responde:

“Três projetos, somando 12,5 FTE entre o 2º e o 3º trimestres. Aproximadamente £340k em custos totais. Entregue no prazo. Estamos vendo uma melhora de 15% na conversão, o que se traduz em £2,1M de receita anual adicional.”

Isso não é chute. São dados.

O Framework de Apostas

Todo projeto na flowstate se liga a:

Valor de negócio: impacto na receita, economia de custos ou posicionamento estratégico
Centro de custo: onde a despesa é contabilizada
Fluxo de valor: qual parte do negócio se beneficia
Alocação de FTE: o compromisso exato de recursos ao longo do tempo
Habilidades necessárias: quais capacidades o projeto exige

Quando você estrutura o trabalho assim, a conversa sobre CapEx e OpEx fica simples:

Tipo de projeto	Alocação típica	Impacto no negócio	Tratamento contábil
Novas capacidades	20-30% da capacidade	Crescimento de receita	CapEx
Modernização de plataforma	15-20%	Eficiência e escala	Misto
Redução de dívida técnica	15-20%	Velocidade no longo prazo	OpEx
Manutenção e suporte	20-30%	KTLO	OpEx
Experimentos de inovação	10-15%	Valor de opção	CapEx

Alocação recomendada pelo método flowstate para uma organização de engenharia equilibrada

Você não está só acompanhando tempo. Está acompanhando investimento e retorno.

Como isso funciona na prática

Estamos trabalhando com empresas como a RAC no planejamento de custos de engenharia. Veja como isso muda a conversa:

Antes da flowstate:

“Precisamos de mais cinco engenheiros para o time de plataforma.”

Depois da flowstate:

“Estamos alocando 8,5 FTE em três projetos neste trimestre:

Migração da API v3 (4,0 FTE, £110k, com expectativa de gerar £2M em economia operacional)

Infraestrutura de observabilidade (3,0 FTE, £82k, reduz o MTTR de incidentes em 40%)

Reforço de segurança (1,5 FTE, £41k, o mínimo exigido para o plano enterprise)

Custo total neste trimestre: £233k. Capacidade atual: totalmente alocada.

Se contratarmos cinco engenheiros (£150k por trimestre, custo total), podemos assumir o projeto de modernização de pagamentos no 4º trimestre. A projeção é de £5M de impacto anual na receita, com menos abandono de carrinho e novas formas de pagamento.

Porém, precisamos de 2,0 FTE com experiência em processamento de pagamentos e 1,5 FTE com conhecimento de conformidade PCI. Nosso pipeline de contratação atual ainda não cobre essas habilidades.”

Viu a diferença? Você não está discutindo headcount. Está discutindo investimento, retorno e lacunas de capacidade.

A interface de planejamento que você realmente gostaria de usar

As ferramentas de planejamento tradicionais foram feitas para gerentes de projeto em 2005. Você precisa de um diploma em MS Project para entender.

A flowstate é diferente:

Arrastar e soltar pessoas entre projetos
Cálculo instantâneo de custo conforme você aloca gente
Capacidade em tempo real, mostrando o que de fato é possível
Casamento de habilidades para ver se você tem as capacidades certas
Planejamento de cenários que não exige copiar planilhas
Trilha de auditoria automática de cada mudança e do motivo

Você consegue modelar “e se contratássemos três engenheiros seniores no próximo trimestre?” em uns 30 segundos. Compare cenários lado a lado. Veja o impacto em datas de entrega, custos e capacidade.

Seis meses depois, quando alguém perguntar “Por que tiramos aqueles engenheiros do time de pagamentos?”, você pode mostrar:

A alocação original e o plano do projeto
Quem mudou e quando
O comentário explicando o motivo de negócio
Que impacto isso teve nos projetos seguintes
Se a aposta valeu a pena

Planejamento colaborativo que funciona de verdade

Aqui fica interessante. O planejamento de cenários na flowstate é colaborativo e ao vivo.

Pense nele como o Git do seu plano de engenharia.

Você pode:

Criar quantos rascunhos de cenário quiser
Compartilhar cenários com as partes interessadas para revisão
Receber feedback e iterar
Aprovar um cenário e ele vira o novo plano
Os rascunhos de todo mundo se atualizam sozinhos com as mudanças aprovadas

É colaborativo. Atualiza ao vivo para todos que estão olhando. Você pode jogar fora quantos rascunhos quiser. Mas existe uma única fonte da verdade atualizada, e ela, como mágica, atualiza os rascunhos de cada pessoa com as mudanças aprovadas, então você sempre trabalha na versão mais recente.

Chega de “qual versão do plano estamos olhando?” Chega de mandar planilha por e-mail. Chega de descobrir que o financeiro estava trabalhando com os números da semana passada.

Commit. Merge. Rebase. Só que mais mágico.

Replanejamento dinâmico sem dor

O mercado de software muda rápido. Viradas estratégicas acontecem. Pessoas-chave saem. Prioridades mudam.

No método flowstate, replanejar não significa recomeçar do zero. Significa:

Arrastar projetos para ajustar o cronograma
Ver o impacto na hora em custos e entregas
Comparar cenários antes de confirmar
Registrar o porquê para consulta futura
Publicar o novo plano para as partes interessadas automaticamente

O que antes levava três dias agora leva trinta minutos.

E como tudo fica registrado direito, você responde “Por que esse projeto estourou?” com dados reais:

“Realocamos 2,0 FTE para o incidente de segurança na semana 3”
“A migração da API levou 6 semanas a mais por causa de problemas de qualidade de dados que descobrimos”
“Adicionamos escopo na semana 7 a partir do feedback de clientes. Aqui está a mudança aprovada”

Não são chutes. São fatos.

O método move o produto (e não o contrário)

Não estamos só construindo software. Estamos codificando boas práticas de líderes de tecnologia de vários setores.

O método flowstate é a nossa resposta para estas perguntas:

Como o trabalho de engenharia deve ser estruturado para ter visibilidade?
Qual é a unidade mínima viável de planejamento que equilibra granularidade e sobrecarga?
Como equilibrar foco (poucos projetos) com flexibilidade (prioridades que mudam)?
Como as apostas de engenharia se ligam aos resultados financeiros que o financeiro de fato valoriza?
Como tornar o planejamento de cenários rápido o bastante para ser útil?
Como acompanhar habilidades e capacidades, e não só headcount?

Estamos conversando com:

CTOs de empresas controladas por fundos de private equity, sob escrutínio operacional
Scale-ups em crescimento acelerado, com vários ciclos de planejamento por ano
Empresas de médio porte tentando controlar o gasto com engenharia pela primeira vez
Líderes de engenharia cansados do inferno das planilhas

Os problemas são consistentes. As soluções não deveriam ser sob medida.

Para onde vamos daqui

A pressão sobre o gasto com engenharia nunca foi tão alta. Fundos de private equity exigindo excelência operacional. Conselhos cobrando expansão de margem. CFOs querendo visibilidade em tempo real de para onde vai o dinheiro.

Ao mesmo tempo, a natureza do trabalho de engenharia está mudando. As referências de produtividade estão se movendo. Os modelos históricos de custo de engenharia ficarão obsoletos em questão de meses.

As organizações que descobrirem isso, que conseguirem planejar de forma dinâmica, medir com precisão e se adaptar rápido, terão uma vantagem enorme. As que continuarem copiando abas de planilha vão ficar para trás.

Construímos a flowstate porque eu estava cansado de não ter respostas. Cansado de planilhas que quebram. Cansado de planejamento de cenários que leva três dias. Cansado de explicar para conselhos por que não conseguimos dizer quanto as coisas custam.

O método flowstate é a nossa tentativa de resolver isso direito. Não com mais um gerenciador de tarefas. Não com mais um substituto de planilha. Mas com um framework de verdade para como as organizações de engenharia devem planejar e medir o trabalho em 2025 e daqui para frente.

Ajude a gente a refinar isso

Ainda estamos no começo. O software funciona (a RAC e outras empresas já usam hoje), mas estamos refinando o método em conversas com líderes de tecnologia.

Se você enfrenta algum desses problemas, quero falar com você:

Como você faz planejamento de cenários hoje? Quando seu CFO pergunta “e se cortarmos 20%?”, qual é o seu processo? Planilhas? Feeling? Três dias de reunião?

Como você acompanha o custo das funcionalidades? Você consegue me dizer agora quanto custou construir suas três últimas funcionalidades grandes? Não estimativa. Custo real.

Como você justifica pedidos de headcount? Qual é a sua narrativa? “Precisamos de mais gente” ou “Precisamos de 3,0 FTE por seis meses para construir [coisa], que vai gerar [valor]”?

Como você lida com replanejamentos frequentes? Quando as prioridades mudam todo mês, como você mantém os planos atualizados sem queimar semanas em burocracia?

Como você casa habilidades com projetos? Você consegue ver de relance se a capacidade disponível tem as habilidades certas para o trabalho que vem aí?

Os melhores frameworks nascem da sabedoria coletiva, não da experiência individual. Estamos construindo a flowstate para resolver problemas que eu vivi, mas quero ter certeza de que estamos resolvendo os problemas que você vive também.

Se isso fez sentido para você, fale com a gente: 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.” (Os artigos acadêmicos de referência.) O link original da publicação de Panko está morto, mas deixo aqui para referência: 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.” ↩