Tem problema de trabalho em TI que aparece primeiro como piada interna.
Foi mais ou menos assim que um post no r/webdev começou a circular entre desenvolvedores nesta semana. O título já vinha pronto como desabafo: “1 developer, 3 layers of project management. My daily standup is a joke.” E o corpo do relato explicava o cenário com uma clareza que dói: o autor era o único dev daquela frente, mas entrava todos os dias numa call em que era superado por três camadas de gestão.
O trecho que fez o caso bater forte não foi um grande escândalo técnico. Foi a banalidade burocrática. Segundo o relato, a daily chegou a gastar 14 minutos discutindo por que uma estimativa financeira mudou depois de o prazo sair de duas para três horas. Não era uma conversa para remover impedimento. Era uma conversa para justificar variação mínima de percepção para gente demais.
É esse detalhe que transforma o post em algo maior do que um simples rant. Muita gente de TI já viveu algum grau dessa distorção: menos energia indo para construir, testar e decidir; mais energia indo para explicar, alinhar, sinalizar e provar que está “andando”.
Quando a daily deixa de ser coordenação e vira prestação de contas
Daily boa é ferramenta de fluxo.
Ela existe para responder rápido o que foi feito, o que travou e o que precisa de ajuda. Quando funciona, economiza tempo. Quando degrada, vira outra coisa: um pequeno tribunal operacional repetido todos os dias.
No caso do r/webdev, o sintoma central nem é a presença de gestor. Gestão boa faz falta. O problema é a proporção. Quando um único desenvolvedor passa a reportar para múltiplas camadas ao mesmo tempo, a reunião tende a parar de servir ao trabalho e passar a servir ao sistema de observação do trabalho.
Isso muda tudo:
- a estimativa deixa de ser instrumento de planejamento e vira peça de defesa;
- o standup deixa de destravar e passa a registrar performance;
- o atraso deixa de ser um risco técnico e vira ruído político;
- e o dev para de responder só ao produto e começa a responder à ansiedade da estrutura.
Esse tipo de desenho costuma parecer “normal” por dentro porque ninguém chama de desperdício. Chama de alinhamento.
O ponto que a comunidade reconheceu na hora
O caso ficou forte porque ele não soa excêntrico. Soa familiar.
Em paralelo, uma discussão aberta no Hacker News sobre “fake work” em empresas de tecnologia fez um argumento que encaixa perfeitamente aqui: muita operação corporativa já funciona em torno de proxies de produtividade. Como produtividade real é difícil de medir, cresce o peso de sinais mais fáceis de enxergar — presença em reunião, ritual de status, volume de alinhamento, documentação para cima, performance visível.
O problema é que proxy vira jogo. E, quando vira jogo, o time aprende rápido que parecer coordenado pode importar mais do que estar realmente destravado.
Outro Ask HN recente, agora sobre cultura técnica ruim, mostrou a mesma sensação por um ângulo diferente: gente experiente entrando em ambientes onde o trabalho real parece andar sempre atrás do teatro de processo. Não é exatamente a mesma história do r/webdev, mas a família do problema é a mesma. O profissional sente que não está sendo puxado para fazer engenharia melhor. Está sendo puxado para sobreviver à mecânica da empresa.
A burocracia pesa mais quando o time já está enxuto
Esse caso também importa porque ele aparece num momento em que muito time está mais magro do que antes.
Quando sobra menos gente para construir, cada camada extra de ritual custa mais caro. Uma reunião ruim de quinze minutos já não é “só uma reunião ruim”. Ela consome foco do gargalo principal.
No relato do Reddit, o gargalo principal era explícito: havia um desenvolvedor. Isso torna a cena quase didática. Se a pessoa que efetivamente entrega é minoria extrema na conversa diária, alguma coisa no desenho gerencial saiu da proporção.
E aqui vale um cuidado importante: esse não é um texto contra PM, gerente ou liderança. Times bons precisam dessas funções. O ponto é outro. Liderança que melhora fluxo protege tempo de execução. Liderança que multiplica checkpoints sem reduzir ambiguidade vira custo operacional com crachá melhor.
O sinal prático que vale observar no seu time
Nem todo time com muita reunião está doente. Mas existe um teste simples que costuma separar coordenação saudável de teatro de controle:
depois do standup, o trabalho anda mais leve ou mais defensivo?
Se a reunião deixa clareza, prioridade e desbloqueio, ela está cumprindo função.
Se a reunião faz o time sair calibrando discurso, refinando justificativa e imaginando quem vai reagir mal a uma mudança pequena de prazo, o ritual já mudou de natureza.
Nesse estágio, o problema raramente é só da daily. Normalmente ele aponta para uma estrutura com excesso de observação e escassez de confiança.
O que esse caso ensina para quem vive de TI
O desabafo do r/webdev é pequeno, mas o recado é grande.
Ele mostra como uma equipe pode continuar “organizada” no papel enquanto perde eficiência no cotidiano. Mostra também por que tanta gente boa anda cansada sem conseguir explicar direito de onde vem o cansaço. Nem sempre é volume puro de trabalho. Às vezes é a fricção de trabalhar sob monitoramento ritualizado demais.
Para quem está em posição técnica, esse tipo de caso serve de alerta para nomear o problema cedo.
Para quem lidera, serve de alerta ainda mais importante: processo só é maturidade quando reduz atrito para quem entrega. Quando aumenta atrito para produzir visibilidade gerencial, ele pode até parecer sofisticado — mas já começou a falhar.
No fim, talvez a melhor síntese do caso seja desconfortavelmente simples: daily que existe mais para satisfazer a estrutura do que para ajudar o time não é rotina de alinhamento. É teatro operacional.
Fontes
- Reddit r/webdev — feed mensal aberto do subreddit — post “1 developer, 3 layers of project management. My daily standup is a joke.”
- Hacker News — AI is supercharging fake work
- Ask HN: Rant, Am I bad or is this a company with a poor tech culture?
