Tem time que passa o dia inteiro se mexendo e, ainda assim, termina a semana com a sensação de que quase nada realmente andou. A agenda enche, o Slack não para, o calendário vira um Tetris de alinhamentos e todo mundo parece ocupado. Mas ocupado e útil não são a mesma coisa.
Essa foi a faísca de um Ask HN que explodiu nos últimos dias. O autor do post perguntou se boa parte dos empregos corporativos de engenharia de software não teria virado algo meio performático: muita ação que parece importante para a gestão, enquanto poucas pessoas empurram o produto de verdade. O tópico passou de 240 pontos e 280 comentários. Em uma frase curta, um comentário resumiu a sensação: “Work is performance art.”
Não dá para tratar um relato desses como verdade universal. Empresa boa existe, gestor bom existe, e até a agenda lotada pode fazer sentido em certos contextos. Mas o volume de resposta ao caso mostra que a dor é real o bastante para merecer uma leitura mais séria: quando o time começa a premiar visibilidade em vez de impacto, o trabalho de engenharia degrada rápido.
O caso real bateu porque muita gente reconheceu a cena
No relato original, o autor diz que trabalhou em empresas grandes, inclusive FAANG, e passou a enxergar um padrão incômodo. Segundo ele, boa parte do reconhecimento interno parecia ir para ações vistosas, não necessariamente úteis. Ao mesmo tempo, os poucos nomes que realmente aproximavam o time do objetivo acabavam perdidos no meio do teatro corporativo.
O ponto mais espinhoso do post foi a crítica às agendas cheias de 1:1s e alinhamentos que, na visão dele, tinham pouco valor prático. A discussão nos comentários ficou interessante justamente porque não veio só validação. Muita gente concordou com a crítica às métricas ruins e à cultura de parecer produtivo. Outras pessoas lembraram que 1:1 bom não é enfeite: pode destravar carreira, contexto, conflito e priorização. O problema não é a reunião existir. O problema é ela virar prova de trabalho.
Essa nuance importa. O alvo aqui não é gestão em si. É a lógica em que o time aprende que aparecer trabalhando rende mais do que entregar algo que melhora o produto, a operação ou a vida de quem depende daquele sistema.
O nome disso já existe: trocar resultado por proxy
Essa discussão conversa muito com um problema antigo da engenharia: a obsessão por medir produtividade com sinais fáceis e ruins. O Stack Overflow resumiu bem isso em um texto clássico sobre métricas de desenvolvimento: horas trabalhadas, presença no escritório, volume de commits e linhas de código são proxies frágeis. Parecem objetivos, mas incentivam comportamento distorcido.
É o tipo de ambiente em que ficar até tarde vira símbolo de dedicação, responder tudo na hora parece comprometimento e produzir volume dá mais status do que cortar ruído. O efeito colateral é perverso: a equipe aprende a otimizar aquilo que é visível para cima, não aquilo que gera valor para fora.
Em software, isso costuma aparecer de um jeito bem familiar. A pessoa que simplifica um fluxo, reduz incidentes futuros ou evita retrabalho nem sempre fica “vistosa” no dashboard político da semana. Já quem circula muito, opina em tudo, marca presença em toda frente e empilha artefatos pode parecer indispensável mesmo quando o ganho real é discutível.
Quatro sinais de que o time está premiando visibilidade em vez de impacto
- Métrica de esforço virou métrica de valor. O time discute mais quantidade de PRs, mensagens, horas e cerimônias do que qualidade da entrega, redução de risco ou melhora concreta para o usuário.
- Reunião virou reflexo, não decisão. O síncrono ocupa o dia inteiro, mas pouca coisa sai com dono claro, prioridade definida ou desdobramento útil.
- Quem protege foco parece menos engajado. A pessoa que some para resolver problema difícil começa a parecer “menos presente” do que quem performa disponibilidade o tempo todo.
- Trabalho invisível para manter a casa em pé perde prestígio. Refatoração cirúrgica, documentação boa, revisão cuidadosa e prevenção de incidente valem menos do que trabalho barulhento.
O excesso de síncrono ajuda a fabricar essa ilusão
Aí entra um ponto prático que muita equipe brasileira conhece na pele. Em TI, nem todo gargalo nasce de ferramenta ruim ou gente ruim. Às vezes ele nasce de coordenação demais no formato errado. Um texto recente da GeekHunter lembra uma distinção simples que muita empresa esquece: trabalho síncrono é melhor para decisão; trabalho assíncrono costuma ser melhor para execução, revisão e foco.
Quando tudo vira urgência compartilhada, a equipe perde blocos longos de concentração. E sem concentração, engenharia boa começa a virar manutenção de contexto quebrado. O dev passa o dia provando que está disponível, mas quase nunca entra fundo o bastante para resolver o que interessa.
Isso ajuda a explicar por que tanta gente leu o caso do Hacker News e pensou: “ok, eu conheço esse filme”. Não porque toda reunião seja inútil, mas porque em muito lugar a operação foi montada de um jeito que favorece interrupção constante e recompensa quem navega melhor o ritual.
Nem todo trabalho invisível é desperdício — e nem toda agenda cheia é teatro
Também seria fácil demais cair no cinismo completo. Liderança técnica, gestão de pessoas, alinhamento entre times, onboarding, revisão e negociação com produto fazem parte do trabalho real. O erro começa quando a empresa perde a capacidade de diferenciar o que é coordenação necessária do que é só encenação de produtividade.
Um 1:1 pode evitar saída de talento, destravar conflito político e corrigir prioridades antes de um projeto azedar. Um bom review pode economizar semanas de retrabalho. Uma decisão de arquitetura tomada em conjunto pode poupar meses de remendo. O ponto não é demonizar esse trabalho menos visível. É exigir que ele tenha função, e não apenas presença.
O que esse caso ensina para quem trabalha com TI no Brasil
A leitura mais útil do caso não é “grande empresa é tudo igual” nem “gestor não faz nada”. A leitura útil é mais desconfortável: times de engenharia também podem virar ambientes onde o incentivo informal está torto. E quando isso acontece, as pessoas mais conscienciosas costumam sentir primeiro, porque percebem que esforço real e reconhecimento deixaram de andar juntos.
Se você lidera, vale fazer uma pergunta simples: o que hoje ganha prestígio no time? Resolver problema difícil? Melhorar clareza? Evitar caos futuro? Ou parecer permanentemente ocupado?
Se você é dev e está sentindo esse desgaste, talvez o problema não seja falta de entrega sua. Talvez você esteja dentro de um sistema que confunde movimento com progresso. E isso muda bastante a conversa.
No fim, o relato do Hacker News não prova que a maioria dos empregos corporativos em software é performática. Mas ele acerta em cheio ao expor uma distorção bem conhecida: quando a empresa mede mal, coordena demais e protege pouco o foco, o trabalho começa a parecer grande por fora e vazio por dentro.
