Por que feedback é difícil em times de TI
Desenvolvedores são treinados para resolver problemas com lógica. Quando recebem feedback vago, a resposta natural é rejeitar — não por ego, mas porque "você precisa se comunicar melhor" não tem parâmetros suficientes para gerar ação. É como reportar um bug sem stack trace.
Por outro lado, gestores que vêm da área técnica carregam outro problema: sabem exatamente o que está errado no código ou na decisão técnica, mas têm dificuldade de comunicar problemas de comportamento, postura ou colaboração sem soar pessoal ou sem entrar em modo de "code review verbal".
O resultado é que a maioria dos times de TI opera com feedback insuficiente — ou feedback técnico demais que ignora o lado humano, ou feedback genérico demais que não muda nada. Nenhum dos dois funciona.
O modelo SCI (Situação-Comportamento-Impacto)
O SCI é a estrutura mais eficiente para dar feedback técnico com precisão. A lógica é simples: você separa o que aconteceu (fato) do que isso gerou (consequência), e evita qualquer julgamento sobre a intenção ou o caráter da pessoa.
Situação
Descreva o contexto específico onde o comportamento ocorreu. Não "você sempre atrasa", mas "na última sprint, durante a planning de terça-feira". Quanto mais específica a situação, menos espaço para negação ou desvio de foco.
Comportamento
Descreva o comportamento observável — o que você viu ou ouviu. Não "você ficou com mau humor", mas "você interrompeu dois colegas durante a apresentação deles e descartou as sugestões sem argumentar tecnicamente". Comportamento é algo que uma câmera poderia capturar.
Impacto
Explique o efeito concreto daquele comportamento. "Isso fez com que dois devs parassem de contribuir na reunião. Nas próximas três plannings, ninguém mais trouxe sugestões de melhoria de processo." O impacto precisa ser real, não hipotético.
"Feedback sem especificidade é ruído. O desenvolvedor ouve, acena com a cabeça e sai da conversa sem saber o que exatamente precisa mudar."
Feedback positivo versus feedback corretivo
A maioria das pessoas que gerencia times técnicos tende a dar feedback corretivo quando algo vai mal — e silêncio quando vai bem. Esse é um dos erros mais custosos em gestão, porque o silêncio é interpretado como indiferença ou aprovação morna, não como reconhecimento genuíno.
Feedback positivo com o modelo SCI tem o mesmo poder transformador que o corretivo. "Na code review de ontem, quando você explicou o problema de acoplamento para o Pedro de forma gradual, usando exemplos do próprio código dele, isso acelerou o entendimento dele de uma forma que eu não tinha visto antes. O Pedro comentou depois que aquela conversa mudou como ele pensa sobre separação de responsabilidades." Isso reforça um comportamento específico que você quer ver mais.
O timing importa mais do que você pensa
Feedback dado semanas depois do evento tem menos de 30% da eficácia de um feedback dado no mesmo dia. O cérebro conecta aprendizado com eventos recentes — quanto mais distante o feedback da situação, mais difícil é para o desenvolvedor reconstruir o contexto e entender o que, especificamente, precisa mudar.
A regra prática: feedback positivo deve ser dado imediatamente, no mesmo dia, de preferência em público. Feedback corretivo deve ser dado em privado, no mais breve possível, mas com preparo mínimo — nunca no calor da emoção.
Existe uma exceção: quando o comportamento gerou um conflito ou situação de alta emoção para você ou para a outra pessoa. Nesse caso, aguarde algumas horas, deixe a adrenalina baixar, e então abra a conversa. Feedback dado com raiva ou frustração óbvia perde a precisão e cria defensividade.
Como dar feedback sobre código versus comportamento
Esses são dois tipos de feedback com dinâmicas completamente diferentes. Feedback técnico — sobre código, decisões de arquitetura, escolhas de design — é mais fácil de dar porque existe um artefato concreto. Você pode apontar para o arquivo, a função, o PR.
Feedback comportamental — sobre como a pessoa se comunica, colabora, reage sob pressão, recebe crítica — é mais sensível porque toca identidade. O desenvolvedor que ouve "sua comunicação com produto é fraca" pode ouvir "você é uma pessoa ruim". A precisão do SCI protege contra isso: quando o feedback é sobre um comportamento específico em uma situação específica, ele fica separado da identidade da pessoa.
Um erro comum: dar feedback técnico em tom de feedback comportamental. "Seu código está sempre confuso" mistura técnica com julgamento de caráter. Melhor: "Nesse PR, as funções helpers não têm nome que comunique a intenção. Isso aumentou o tempo de revisão em 40 minutos porque precisei reconstruir o raciocínio sem contexto." Objetivo, específico, acionável.
O feedback sandwich — positivo, negativo, positivo — não funciona com desenvolvedores sêniores. Eles reconhecem o padrão imediatamente, ignoram os elogios, e esperam pelo "mas" no meio. Se você tem algo difícil para dizer, diga diretamente. A clareza é mais respeitosa do que a diplomacia performática.
Os erros mais comuns de gestores de TI ao dar feedback
Além do feedback sandwich e da falta de especificidade, existem outros padrões que enfraquecem o feedback em times técnicos:
- Acumular feedback para a avaliação semestral: o desenvolvedor fica meses operando com informação errada, e o gestor chega na avaliação com uma lista de problemas que podiam ter sido corrigidos semanas antes.
- Dar feedback em público sobre comportamento: corrigir um dev na frente do time cria vergonha, não aprendizado. O dev aprende a não ser pego, não a mudar o comportamento.
- Confundir estilo com problema: nem todo código diferente do seu estilo é problema. Antes de dar feedback técnico, pergunte-se se aquilo é preferência ou impacto real no sistema.
- Feedback sem follow-up: dar o feedback, o desenvolvedor concordar, e nunca mais falar no assunto. Mudança de comportamento precisa de acompanhamento — não vigilância, mas check-ins leves nas semanas seguintes.
Criando uma cultura de feedback no time
Cultura de feedback não é ter um processo formal de avaliação. É o time se sentir seguro o suficiente para dar e receber feedback entre si, sem precisar do gestor como intermediário. Isso leva tempo e começa pelo exemplo.
Como gestor, quando você recebe feedback do seu time — sobre uma decisão que tomou, uma reunião que conduziu, uma prioridade que estabeleceu — a forma como você reage define o teto do que é possível naquele time. Se você fica na defensiva, o time aprende que feedback vai para uma via de mão única. Se você agradece, processa em voz alta e volta com o que vai mudar, você cria o modelo.
Times com cultura de feedback forte têm ciclos de aprendizado mais rápidos. Um problema que levaria semanas para chegar ao gestor via hierarquia é resolvido entre os próprios devs em dias. E quando um problema chega ao gestor, geralmente já vem com contexto e proposta de solução.