Gestão de conflitos em equipes de TI: o que fazer quando o dev sênior não colabora em São Paulo?

Quando um desenvolvedor sênior deixa de colaborar, a solução começa com uma conversa direta, diagnóstico claro das causas e definição de expectativas mensuráveis; tudo isso pode ser feito sem perder a autoridade da liderança, mesmo em equipes dispersas entre São Paulo e cidades como Ubatuba.

Entendendo a raiz do conflito

Antes de qualquer ação corretiva, é fundamental mapear por que o dev sênior está se afastando da colaboração. As causas mais comuns incluem:

• Sobrecarga de trabalho: profissionais experientes costumam acumular demandas críticas e podem sentir que seu tempo está sendo consumido por tarefas de baixa prioridade.
• Desalinhamento de objetivos: se a visão do produto ou a estratégia da sprint não foram comunicadas de forma clara, o sênior pode achar que seu esforço não gera impacto.
• Falta de reconhecimento: em ambientes onde a cultura de feedback é fraca, o sentimento de invisibilidade pode gerar resistência.
• Diferenças de estilo: alguns devs preferem autonomia total, enquanto outros se sentem mais confortáveis com pair programming ou revisões de código frequentes.

Um diagnóstico rápido pode ser feito com um formulário anônimo (por exemplo, Google Forms) que pergunte sobre carga de trabalho, clareza de metas e satisfação com o reconhecimento. Os resultados ajudam a priorizar a intervenção.

Como agir como líder imediato

Conversa individual

A primeira reunião deve ser one‑on‑one e focada em escuta ativa. Prepare um roteiro com perguntas abertas, como:

• "Como você vê seu papel nas últimas duas sprints?"
• "Quais obstáculos têm impedido sua colaboração?"
• "O que eu, como gestor, poderia fazer para facilitar seu trabalho?"

Mantenha o tom de curiosidade, não de acusação. Registre os pontos principais em um documento compartilhado (ex.: Confluence) e confirme o entendimento com o colaborador ao final da conversa.

Definir expectativas claras

Depois da escuta, co‑crie um plano de ação com metas mensuráveis, por exemplo:

• Participar de duas revisões de código por semana durante o próximo mês.
• Contribuir com um protótipo de arquitetura para a feature X até a sexta‑feira da sprint.
• Registrar bloqueios no Jira dentro de 2 horas após identificá‑los.

Essas metas devem ter prazos curtos (1‑4 semanas) para que o progresso seja visível e ajustável. Compartilhe o plano com a equipe para criar transparência.

Ferramentas e processos que ajudam a alinhar a equipe

• Ritmo de daily stand‑up: limite a fala a 3 minutos e incentive que o dev sênior destaque bloqueios e sugestões de melhoria.
• Code review automatizado: use o GitHub Actions ou GitLab CI para garantir que todo PR passe por checklist de qualidade antes da revisão humana. Isso reduz a frustração de revisões repetitivas.
• Matriz RACI: para projetos complexos (por exemplo, migração de base de dados para PostgreSQL em um cliente da região da Grande São Paulo), deixe explícito quem é responsável, quem aprova e quem consulta.
• Retrospectiva focada em comportamento: ao invés de discutir apenas o que deu errado tecnicamente, reserve 15 minutos para analisar “como trabalhamos”. Ferramentas como FunRetro ou Miro facilitam a captura de insights.

Essas práticas criam um framework de colaboração que diminui a dependência de personalidades individuais.

Quando a mediação externa é necessária

Se, após duas semanas de acompanhamento, o comportamento não mudar, considere envolver:

1. RH ou People Ops: eles podem oferecer coaching de carreira ou encaminhar para um programa de desenvolvimento de lideranças.
2. Mentor interno: um arquiteto de software sênior que tenha credibilidade pode atuar como mediador informal.
3. Consultoria especializada: empresas como a Cognizant Brasil ou a ThoughtWorks oferecem workshops de cultura ágil que ajudam a re‑estabelecer normas de colaboração.

A mediação deve ser vista como um investimento para preservar a produtividade da equipe, especialmente quando o projeto impacta clientes importantes de São Paulo e do litoral norte, como Ubatuba.

Caso prático: equipe de desenvolvimento em Ubatuba

Imagine uma startup de turismo que desenvolve um app para reservas de pousadas em Ubatuba. O time tem cinco desenvolvedores, sendo João, dev sênior com 12 anos de experiência, responsável pelo módulo de pagamento. Nos últimos dois meses, João tem evitado as revisões de código e entregue commits sem testes. O líder de equipe, Ana, aplicou as etapas descritas acima:

• Diagnóstico: via formulário, João revelou que se sente sobrecarregado com demandas de suporte ao cliente, que não estavam previstas em seu contrato.
• One‑on‑one: Ana renegociou a distribuição de tickets, alocando dois devs juniores para suporte de primeira linha.
• Plano de ação: João se comprometeu a fazer duas revisões de código por sprint e a documentar a arquitetura do pagamento em Confluence.
• Ferramentas: foi implantado um pipeline de CI que executa testes de integração automaticamente, reduzindo a necessidade de revisão manual.
• Resultados: em quatro semanas, o tempo médio de entrega da feature de pagamento caiu de 12 para 8 dias, e a taxa de bugs críticos diminuiu 30%.

Esse exemplo mostra como a combinação de escuta, processos claros e apoio institucional resolve o conflito sem precisar de medidas disciplinares severas.

Dicas rápidas para o dia a dia

• Reserve 15 minutos semanais para checar o “clima” da equipe; use um termômetro de humor no Slack.
• Documente decisões em um repositório acessível; isso evita que o dev sênior precise “reinventar a roda”.
• Reconheça publicamente pequenas vitórias (ex.: “Obrigado ao João por otimizar a API de pagamentos”).
• Promova pair programming em momentos críticos; mesmo desenvolvedores experientes aprendem com a troca de perspectiva.
• Mantenha a agenda flexível para atender a demandas emergenciais de clientes de São Paulo que exigem respostas rápidas.

Seguindo essas práticas, a liderança em TI ganha credibilidade e cria um ambiente onde a experiência do dev sênior se transforma em colaboração, não em obstáculo.

Perguntas frequentes

Como identificar se a falta de colaboração é um sintoma de burnout?

O burnout costuma se manifestar com cansaço crônico, irritabilidade e queda de produtividade. Se o dev sênior relata sobrecarga de trabalho, noites sem descanso e falta de energia, considere oferecer apoio psicológico via plano de saúde e ajustar a carga de tickets.

É adequado aplicar punições formais logo no início?

Não. A política de AdSense recomenda evitar punições imediatas; priorize o diagnóstico e o plano de ação. Punições só são recomendadas quando há histórico de não‑conformidade mesmo após intervenções estruturadas.

Quando devo substituir um dev sênior que não melhora?

A substituição deve ser a última alternativa, após esgotar as etapas de diagnóstico, coaching, mediação interna e externa. Se, após 60‑90 dias, o impacto negativo supera o custo de contratação, a troca pode ser justificada.