A Cada Canto Um Grande Conselheiro

O problema dos conselheiros de plantão

Você já entrou num grupo de WhatsApp profissional e encontrou aquele típico comentário não solicitado sobre como você deveria estar fazendo seu trabalho. Ou melhor, sobre como todos deveriam fazer. A cada canto um grande conselheiro é uma frase que descreve exatamente esse cenário: alguém aparecendo com uma opinião formatada, mesmo sem ter nenhum compromisso real com o resultado. O que vou explicar aqui não é apenas sobre identificar esses personagens. É sobre como lidar com isso no dia a dia, sem precisar demitir todo mundo ou sair do grupo.

a cada canto um grande conselheiro

A expressão em si já carrega uma ironia interessante. Não existe uma versão original grega ou latina que eu conheça. O que temos é uma adaptação livre de algo como "onde há muita gente, há muitas opiniões", mas com um tom mais seco, mais cansado. Serve para qualquer situação em que alguém decide dar sua contribuição sem ser chamado. No ambiente técnico, isso aparece frequentemente em reuniões de design review. Um colega que nunca tocou no código passa vinte minutos sugerindo uma arquitetura completamente diferente. Outro que foi contratado ontem já acha que o sistema legado deveria ser refatorado do zero. Ambos estão certos no sentido de que têm opinião. Ambos estão errados no sentido de que não têm contexto. Minha experiência prática com isso começou quando eu estava gerenciando a migração de um banco de dados MySQL 5.6 para PostgreSQL num projeto interno. A cada canto um grande conselheiro surgia com sugestões de ferramentas que já estavam obsoletas ou que exigiam uma infraestrutura que a empresa simplesmente não tinha. Um deles recomendou até mesmo uma reescrita completa em Rust, por razões que eu ainda hoje não consigo entender.

O workaround que eu desenvolvi foi simples e burocrático. Criei um documento único de decisões técnicas, acessível para qualquer pessoa, mas que pedia para quem fosse dar sugestões preencher três campos: qual problema específico aquela solução resolve, quantas linhas de código isso alteraria, e qual era o tempo estimado de implementação. A maioria dos conselheiros voluntários simplesmente desistiu. Os que persistiram tiveram que trabalhar com dados concretos em vez de achismos.

Como identificar e filtrar conselhos ruins

A regra prática mais útil que eu encontrei é verificar se o conselho vem de alguém com pele no jogo. Alguém que sofre as consequências diretas da decisão tem muito mais probabilidade de dar uma orientação útil do que alguém que será transferido para outro projeto semana que vem. Conselhos sem responsabilidade compartilhada são apenas entretenimento intelectual disfarcado de contribuição técnica. Eles soam bem na hora, mas na prática acabam gerando mais trabalho do que valor. Outro filtro que funciona é o teste do "como você saberia". Se a pessoa diz que algo deve ser feito de outra forma, pergunte especificamente como seria a implementação. As respostas vagas que você receber provavelmente vão revelar que o conselho nunca passou pela fase de detalhes práticos. Na minha equipe, costumamos chamar isso de "conselho de elevador": funciona bem em oito andares, desaba quando sobe pro décimo quinto.

Aqui vai algo que poucos percebem: os melhores conselheiros que eu já encontrei eram justamente aqueles que primeiro listavam o que não sabiam sobre o assunto. Um engenheiro sênior comigo uma vez passou dez minutos explicando tudo o que ele desconhecia antes de sugerir uma abordagem. Isso é raro. A maioria das pessoas apresenta a opinião como se fosse fato consolidado, sem qualquer menção às áreas cinzentas.

Quando ignorar é a melhor resposta

Nem todo conselho precisa ser enfrentado diretamente. Há situações em que a melhor estratégia é simplesmente não engajar. Se você está em uma fase crítica de entrega e recebe uma suggestion fora do escopo, um "vamos discutir isso na próxima sprint" é suficiente. Não precisa ser rude, mas também não precisa ser vulnerável a cada opinião aleatória. O problema é que muita gente sente obrigação de justificar suas decisões. Eu já passei por isso. Durante meses, eu expliquei por que não íamos adotar determinada ferramenta, detalhadamente, e no final das contas o conselho nunca saiu do papel mesmo assim. A cada interação, eu gastava mais tempo justificando do que ganhava de produtividade real. Parei de explicar. A partir daí, as sugestões infundadas começaram a diminuir naturalmente. Existem casos, no entanto, em que o conselho ruim pode ser aproveitável. Se alguém sugere uma solução errada, mas aponta para um problema real que você estava negligenciando, o mérito está em reconhecer o problema mesmo rejeitando a solução. Separe o diagnóstico do remédio. O diagnóstico às vezes é válido mesmo quando o conselho é horrível.

Uma limitação importante que vale mencionar é que esse processo de filtragem não funciona bem em ambientes com alta rotatividade. Quando as pessoas estão sempre chegando e saindo, o custo de construir critérios comuns de avaliação de sugestões pode superar o benefício. Nestes casos, o mais pragmático é ter um canal formal para receiving ideias, como um issue tracker ou um formulário estruturado, e deixar claro publicamente que sugestões fora desse canal não serão consideradas fora do prazo de trinta dias. Isso evita o cansaço de responder sempre às mesmas perguntas mal formuladas. O efeito colateral mais comum que eu observo é o esgotamento do moderador. Quem fica responsável por triar conselhos alheios acaba absorvendo uma carga cognitiva extra que raramente aparece nas descrições de cargo. Se isso está acontecendo com você, considere delegar a triagem ou criar regras automáticas de descarte para sugestões que não sigam um template básico.