Acabei de ler o texto de Juha Korpela sobre arquitetura espaguete e soluções de dados em silos, e concordo com ele. O diagnóstico está correto. A frustração é justificada. O chamado à ação é necessário.
Mas quero acrescentar algo. Estou na liderança e também luto essa mesma batalha todos os dias. Do meu ponto de vista, esse não é apenas um problema de liderança.
Sim, a liderança pode piorar as coisas. Sim, a liderança precisa enxergar tanto o problema pontual quanto o problema sistêmico ao mesmo tempo. Mas quando enquadramos isso principalmente como falha de liderança, todo o resto da organização é liberado de responsabilidade. E esse enquadramento, por si só, é parte do motivo pelo qual o problema se repete.
Deixe-me explicar o que realmente vejo no campo.
Ninguém está pensando dois passos à frente
Existe uma frase que ouço constantemente: precisamos focar em resolver problemas de negócio. E concordo com isso. Claro que devemos. Mas em algum momento essa ideia passou a significar que devemos parar de pensar em como os resolvemos.
Não nos atrasa. Nos alcança.
O padrão mais consistente que vejo é a ausência de pensamento de segunda ordem. Alguém toma uma decisão. Constrói um pipeline rápido. Define uma métrica localmente. Sobe uma ferramenta nova. Cada decisão é avaliada puramente pelo resultado imediato. Resolve o ticket? Sim. Envia.
Mas ninguém faz a pergunta seguinte.
O que acontece quando outro time precisa dos mesmos dados? O que acontece quando a regra de negócio muda? O que acontece quando essa solução precisa interagir com outras cinco construídas da mesma maneira?
As consequências são invisíveis na hora. Aparecem meses depois, espalhadas por vários sistemas, difíceis de rastrear. Ninguém conecta essas consequências à decisão original — então ninguém aprende. E o ciclo continua.
Quem deveria estar fazendo esse pensamento de segunda ordem? Todo mundo.
A liderança deveria perguntar como será a arquitetura em dois anos se continuarmos tomando decisões assim. Arquitetos deveriam perguntar como essa solução se encaixa com todo o resto. E engenheiros — e sinto fortemente isso — deveriam perguntar o que acontece a jusante do código que estão escrevendo agora.
Sempre acreditei que a diferença entre um bom engenheiro e um grande engenheiro é o pensamento de segunda ordem. Um bom engenheiro resolve o problema à sua frente. Um grande engenheiro resolve de uma forma que não cria três problemas novos daqui a seis meses. Isso não é questão de senioridade. É questão de mentalidade. E pode ser ensinado — mas apenas se a organização realmente o valorizar.
E é aí que o papel da liderança realmente se encontra. Não em fazer todo o raciocínio, mas em criar um ambiente onde esse raciocínio aconteça naturalmente. Onde soluções são revisadas. Onde as pessoas conectam seu trabalho ao contexto maior. Onde os times entendem que o que constroem hoje reverbera.
Não vejo isso como apenas uma falha de liderança. Vejo como um hábito de pensamento. Ou, mais precisamente, a ausência de um. E hábitos habitam todos os níveis da organização.
"Precisamos mais rápido" não é uma razão
Ouço isso constantemente. Tivemos que fazer rápido, então pegamos um atalho.
Velocidade não é uma razão. É uma pressão.
Quando velocidade vira justificativa, a conversa para. Ninguém faz a conta. Mais rápido que o quê? Qual o custo desse atalho ao longo do próximo ano? O que estamos trocando?
Na minha experiência, a maioria das pessoas que invocam velocidade não fizeram esse cálculo. Sentiram a urgência e pararam de pensar.
Costumo dizer ao meu time: se leva cinco dias para fazer direito e três para fazer rápido, faça direito. Ninguém jamais vai questionar essa diferença. O único momento em que você será questionado é quando disser que algo vai levar nove meses. O problema real não é a diferença entre rápido e correto. É quando atalhos se acumulam, uma decisão aparentemente razoável de cada vez.
Dívida técnica não se anuncia. Acumula-se silenciosamente até que um dia você gasta mais tempo gerenciando o sistema do que melhorando-o. Já escrevi sobre isso antes. Aí as pessoas culpam a arquitetura. A arquitetura não se construiu sozinha.
Times-sombra de dados são um sintoma
Quando organizações crescem, departamentos param de esperar por equipes centrais e começam a construir suas próprias soluções. E, honestamente, entendo por quê.
Se suas prioridades não se alinham com o backlog central, e seus pedidos ficam semanas ou meses na fila, você segue em frente. Contrata analistas. Define suas próprias métricas. Constrói seus próprios pipelines.
Esse comportamento é racional. É também como a fragmentação se torna estrutural.
Agora você tem múltiplas definições de receita. Múltiplos pipelines puxando das mesmas tabelas. Nenhuma visibilidade compartilhada. Não porque alguém foi descuidado. Porque os incentivos empurraram nessa direção.
É isso que ideias como data mesh tentaram endereçar. Descentralizar a posse mas manter padrões compartilhados. O conceito é sólido. Mas muitas organizações abraçam entusiasticamente a parte da descentralização e silenciosamente pulam a parte dos padrões compartilhados. Então, em vez de resolver o problema de fragmentação, apenas o ratificam e dão um nome melhor.
A liderança pode tentar governar isso, mas times-sombra de dados são um sintoma. A questão real é um desalinhamento profundo o suficiente para que a colaboração pareça mais lenta do que seguir sozinho.
Complexidade cresce silenciosamente
Times de dados constroem coisas. Esse é nosso trabalho. Novos pipelines. Novos dashboards. Novos produtos de dados. Cada um resolve uma necessidade real. Cada um também adiciona complexidade.
Resultado é visível. Coerência arquitetural, não. Então organizações recompensam resultado. Com o tempo, o sistema se torna mais difícil de compreender. Não por causa de uma decisão ruim, mas por causa de muitas decisões "razoáveis".
Construa sistemas mais corajosos que pessoas
Brené Brown capturou isso bem quando disse que deveríamos construir sistemas mais corajosos que pessoas.
Pessoas sentem pressão. Pessoas se cansam. Pessoas respondem à urgência. Sistemas mantêm a linha.
Não se trata de adicionar burocracia. Trata-se de guardrails. Priorização clara. Padrões compartilhados. Estruturas que tornam a decisão certa mais fácil que a decisão rápida.
Então o que é, se não um problema de liderança?
É organizacional. Habita nos incentivos. No planejamento. Na priorização. Na forma como sucesso é medido. Habita em hábitos em toda a organização.
A liderança tem um papel. Absolutamente. Mas não pode ficar lá sozinha.
O engenheiro que entrega sem considerar o impacto a jusante é parte disso. O time que cria suas próprias métricas é parte disso. O gestor que pressiona por velocidade sem discutir trade-offs é parte disso.
Corrigir arquitetura espaguete exige instintos diferentes em toda a organização. Um vocabulário compartilhado. Incentivos que recompensem coerência, não apenas velocidade. E a disciplina de pausar e fazer uma pergunta simples.
Eu luto por isso todos os dias. Não é fácil. Mas espaguete não é inevitável.