Sexta-feira, 16h30. Voce esta prestes a fechar o laptop quando percebe uma thread no Slack que ja tem 47 mensagens. Dois devs do seu time estao discutindo sobre a abordagem de um refactoring. O tom comecou tecnico, mas agora as mensagens tem frases como “voce claramente nao entende o problema” e “essa sugestao nao faz sentido nenhum”. O resto do time esta em silencio — aquele silencio desconfortavel de quem nao quer se envolver.
Se voce ja viveu algo parecido, saiba que esta longe de estar sozinho. Em 22 anos liderando times de tecnologia, passando por duas exits e atuando como CTO, posso dizer com seguranca: conflitos no time de desenvolvimento nao sao excecao, sao regra. A pergunta nao e “se” vao acontecer, mas “como” voce vai lidar quando acontecerem.
E aqui esta o paradoxo que poucos Tech Leads entendem cedo o suficiente: times que nunca tem conflitos nao sao times saudaveis. Sao times onde as pessoas pararam de se importar. O problema real nao e o conflito em si — e o conflito mal gerenciado, que apodrece em silencio e corroi a confianca do time.
Neste guia, vou compartilhar um framework pratico (o DESC), cinco cenarios reais com resolucao passo a passo, e as tecnicas de mediacao que uso ate hoje. Vamos la.
Por Que Conflitos em Times de Desenvolvimento Sao Inevitaveis
Antes de falar sobre solucoes, voce precisa entender por que times de engenharia sao terreno fertil para conflitos. Nao e acaso — existem caracteristicas estruturais dessa profissao que tornam desacordos frequentes.
Primeiro, desenvolvedores sao treinados para ter opinioes tecnicas fortes. A profissao exige pensamento critico, capacidade de avaliar trade-offs e defender posicoes. Quando voce coloca 5 ou 8 pessoas assim numa sala (ou num canal do Slack), e natural que discordem. E bom que discordem. O problema comeca quando discordancia tecnica se transforma em ataque pessoal.
Segundo, o trabalho de software e intrinsecamente ambiguo. Raramente existe “a” resposta certa. REST ou GraphQL? Monolito ou microsservicos? Testar unitariamente ou com integracao? Para cada uma dessas perguntas, existem argumentos validos dos dois lados. Essa ambiguidade cria espaco para conflitos legitimos de perspectiva.
Terceiro, times de desenvolvimento operam sob pressao constante. Deadlines apertados, bugs em producao, mudancas de requisitos de ultima hora. O estresse amplifica pequenas fricoes. Aquela preferencia de estilo de codigo que ninguem liga na segunda-feira vira uma discussao acalorada na quinta, quando todo mundo esta cansado e o deploy esta atrasado.
Pesquisas do Google (Projeto Aristotle) e do estudo de Patrick Lencioni em The Five Dysfunctions of a Team mostram que times de alta performance nao evitam conflitos — eles os processam de forma saudavel. A chave e o que Lencioni chama de “conflito produtivo”: debate apaixonado sobre ideias, sem ataques pessoais.
O papel do Tech Lead nao e eliminar conflitos. E criar as condicoes para que eles sejam produtivos em vez de destrutivos.
Os 5 Tipos Mais Comuns de Conflito em Times Tech
Nem todo conflito e igual, e a forma de resolver depende do tipo. Depois de mediar centenas de situacoes, identifiquei cinco categorias recorrentes. Reconhecer qual tipo voce esta enfrentando e o primeiro passo para resolver.
Conflito Tecnico: Abordagens e Decisoes de Design
Este e o mais frequente e, quando bem gerenciado, o mais produtivo. Dois devs discordam sobre a melhor arquitetura para um servico, sobre qual framework usar, ou sobre a abordagem de um algoritmo.
Sinais: debates longos em pull requests, reunioes de design que nao chegam a conclusao, code reviews que viram cabo de guerra.
O risco aqui e que o conflito tecnico vire pessoal. “Voce nao entende de arquitetura” e diferente de “essa abordagem tem um problema de escalabilidade”. A primeira ataca a pessoa; a segunda, a ideia. Se voce quer se aprofundar em como conduzir revisoes de codigo que evitam esse tipo de escalada, recomendo ler o artigo sobre como fazer code review que realmente melhora o codigo.
Conflito de Comunicacao: Mal-Entendidos
Times remotos e hibridos sofrem especialmente com esse tipo. Uma mensagem no Slack sem contexto, um e-mail com tom ambiguo, uma decisao tomada numa call que ninguem documentou.
Sinais: pessoas dizendo “eu nao sabia disso”, retrabalho por falta de alinhamento, frustracao com decisoes que “apareceram do nada”.
O curioso e que muitos conflitos que parecem tecnicos sao, na verdade, de comunicacao. Duas pessoas concordam no objetivo, mas estao usando palavras diferentes para descrever a mesma coisa — e acabam discutindo por horas sem perceber que estao do mesmo lado.
Conflito de Ego: Seniority e Reconhecimento
Este e o mais delicado. Acontece quando um dev senior sente que sua experiencia nao esta sendo valorizada, quando um junior percebe que nunca recebe projetos relevantes, ou quando alguem sente que outro dev “rouba” credito pelo trabalho.
Sinais: comentarios passivo-agressivos, pessoas que param de contribuir em discussoes, reclamacoes em 1:1s sobre colegas especificos.
O ego ferido e uma das forcas mais destrutivas num time. E tambem uma das mais dificeis de abordar, porque raramente alguem diz “meu ego esta ferido”. Em vez disso, a pessoa racionaliza: “o problema e que o fulano nao segue boas praticas”.
Conflito de Processo: Como Trabalhar e Priorizar
Sprint planning que vira campo de batalha. Discussoes sobre estimativas. Desacordo sobre o que entra ou nao no escopo. Devs que querem mais autonomia versus gestores que querem mais previsibilidade.
Sinais: retrospectivas repetitivas onde os mesmos problemas aparecem, resistencia passiva a processos (a pessoa “concorda” na reuniao e depois nao segue), tensao entre product e engineering.
Conflitos de processo muitas vezes mascaram conflitos de valores. Quando alguem diz “eu nao concordo com essa prioridade”, o que pode estar dizendo e “eu nao me sinto ouvido nas decisoes que afetam meu trabalho”.
Conflito Interpessoal: Personalidades e Estilos
As vezes, duas pessoas simplesmente nao se dao bem. Estilos de trabalho incompativeis, personalidades que colidem, historico de fricoes acumuladas. Nao e sobre codigo ou processo — e sobre a relacao entre as pessoas.
Sinais: evitacao (as pessoas evitam trabalhar juntas), comunicacao minima e fria, tensao visivel em reunioes.
Este tipo de conflito e o que mais exige inteligencia emocional do Tech Lead. Voce nao vai resolver “consertando” as personalidades das pessoas. Vai resolver criando estruturas que permitam colaboracao mesmo quando a quimica pessoal nao e ideal.
O Framework DESC Para Mediacao de Conflitos
Ao longo dos anos, testei diversos modelos de mediacao. O que mais funcionou na pratica com times de engenharia e o que chamo de Framework DESC. Ele e simples o suficiente para lembrar no calor do momento e estruturado o suficiente para evitar que a conversa desande.
DESC e um acronimo: Descrever, Expressar, Sugerir, Consequencias. Vamos detalhar cada etapa.
D – Descrever a Situacao Objetivamente
Comece descrevendo o que esta acontecendo, usando fatos observaveis. Nada de interpretacoes, julgamentos ou suposicoes sobre intencoes. Isso e mais dificil do que parece.
Errado: “Voces estao sendo imaturos nessa discussao de code review.”
Certo: “Nas ultimas tres pull requests, os comentarios de review tiveram mais de 40 respostas cada, e percebi que o tom mudou de tecnico para pessoal a partir da decima mensagem.”
A descricao objetiva faz duas coisas importantes: tira o julgamento da mesa e cria um ponto de partida que ambos os lados podem concordar. Se voce descreve fatos, ninguem pode dizer “nao e verdade”. Se voce descreve interpretacoes, a outra pessoa imediatamente se defende.
Dica pratica: use numeros e exemplos especificos. “Nas ultimas tres sprints” e melhor que “sempre”. “Na reuniao de segunda” e melhor que “frequentemente”.
E – Expressar o Impacto No Time
Aqui voce conecta o comportamento ao impacto real no time, no projeto ou na empresa. O objetivo e tirar o foco das pessoas envolvidas e colocar no efeito coletivo.
Errado: “Voce esta errado e o Joao esta certo.”
Certo: “Quando essas discussoes se prolongam, o deploy atrasa, o time fica desconfortavel para participar das reviews, e nos perdemos a oportunidade de ter mais perspectivas no codigo.”
Expressar o impacto faz o conflito deixar de ser “eu contra voce” e virar “nos contra o problema”. E a mudanca de frame mais poderosa que voce pode fazer numa mediacao. Se voce quer entender melhor como conduzir essas conversas dificeis em formato 1:1, veja o guia pratico de 1:1 para Tech Leads.
S – Sugerir Solucoes Colaborativas
Em vez de impor uma solucao, envolva as partes na construcao dela. Seu papel como Tech Lead nao e ser juiz — e ser facilitador.
Errado: “A partir de agora, vamos fazer do jeito do Joao.”
Certo: “Quero que voces dois proponham uma abordagem que enderece as preocupacoes de performance que o Joao levantou e a preocupacao de manutenibilidade que a Maria trouxe. Vamos agendar 30 minutos amanha para avaliar juntos.”
Quando as pessoas participam da construcao da solucao, a adesao aumenta drasticamente. Ninguem sabota algo que ajudou a criar. Alem disso, frequentemente a solucao colaborativa e melhor do que qualquer uma das propostas originais, porque combina perspectivas.
C – Consequencias e Combinados
Toda mediacao precisa terminar com combinados claros e consequencias explicitas. O que vai acontecer se o mesmo padrao se repetir? O que cada um se compromete a fazer diferente?
Exemplo: “Vamos combinar o seguinte: discussoes de design que passarem de 10 comentarios no PR vao para uma call de 15 minutos com eu mediando. Se em 15 minutos nao houver consenso, eu tomo a decisao final e seguimos. Todo mundo concorda?”
O combinado precisa ser especifico, mensuravel e aceito por todos. “Vamos nos respeitar mais” nao e um combinado. “Discussoes tecnicas que passarem de 10 comentarios vao para uma call” e um combinado.
Documente os combinados. Envie por escrito apos a conversa. Nao confie na memoria de ninguem em momentos de tensao emocional.
5 Cenarios Reais de Conflito (Com Resolucao Passo a Passo)
A teoria e bonita, mas o que importa e o que voce faz quando o conflito esta acontecendo. Aqui estao cinco cenarios que vivi (com nomes e detalhes alterados) e como resolvi cada um usando o framework DESC e outras tecnicas.
Cenario 1: Senior Que Nao Aceita Feedback no Code Review
Situacao: Ricardo, dev senior com 12 anos de experiencia, sistematicamente rejeitava comentarios de code review de colegas mais juniores. Respondia com “isso funciona, nao precisa mudar” ou simplesmente resolvia os comentarios sem fazer ajustes. O time mais junior parou de comentar nos PRs dele por medo de confronto.
Resolucao com DESC:
D (Descrever): “Ricardo, nos ultimos dois meses, 15 dos 18 comentarios feitos nos seus PRs foram marcados como resolvidos sem alteracao no codigo. Tres devs do time me disseram separadamente que pararam de comentar nos seus PRs.”
E (Expressar): “Isso esta impactando o time de duas formas: primeiro, nos perdemos a oportunidade de pegar bugs e melhorias no review. Segundo, os devs mais juniores nao estao aprendendo com o processo de review, que e uma das nossas ferramentas de desenvolvimento mais importantes.”
S (Sugerir): “Quero propor o seguinte: para cada comentario de review, voce responde explicando por que decidiu manter ou alterar. Se decidir manter, a explicacao se torna documentacao de decisao para o time. O que voce acha?”
C (Consequencias): “Vamos testar por duas sprints. Se o engajamento do time nos reviews nao melhorar, vamos reavaliar e talvez criar um rodizio de reviewers com pair review.”
Resultado: Ricardo inicialmente resistiu, mas ao explicar suas decisoes, percebeu que alguns comentarios dos juniores tinham merito. Em tres semanas, a taxa de resolucao sem alteracao caiu de 83%% para 40%%. O efeito colateral positivo foi que as explicacoes dele viraram uma base de conhecimento informal para o time. Para ir mais fundo nesse tema, veja o artigo sobre como dar feedback dificil para desenvolvedores.
Cenario 2: Dois Devs Que Nao Conseguem Trabalhar Juntos
Situacao: Ana e Pedro tinham estilos de trabalho radicalmente diferentes. Ana era meticulosa, escrevia testes extensivos e revisava cada linha antes de abrir PR. Pedro era rapido, iterativo, preferia “fazer funcionar e depois refinar”. Quando trabalhavam na mesma feature, os PRs viravam campo de batalha. Ana reclamava da qualidade do codigo de Pedro; Pedro reclamava que Ana “travava” o progresso.
Resolucao:
Primeiro, conversei com cada um separadamente em 1:1. Perguntei: “O que voce valoriza no estilo de trabalho do(a) colega?” Forcei cada um a encontrar algo positivo. Ana admitiu que Pedro era excelente em desbloquear situacoes complexas. Pedro admitiu que o codigo da Ana raramente tinha bugs em producao.
Depois, na conversa conjunta, usei uma tecnica chamada “Contrato de Trabalho”. Pedi que definissem juntos:
- Qual o nivel minimo de testes para abrir um PR? (Concordaram em cobertura de 70%% para happy path)
- Qual o tamanho maximo de um PR? (Concordaram em 400 linhas)
- Como dividir features grandes? (Pedro faria o spike/prototipo, Ana faria a versao de producao com testes)
Resultado: O contrato de trabalho eliminou a ambiguidade que alimentava o conflito. Cada um sabia o que era esperado. O curioso e que eles se tornaram uma das duplas mais produtivas do time — a velocidade de Pedro combinada com o rigor de Ana era poderosa quando canalizada de forma estruturada.
Cenario 3: Conflito Entre Produto e Engenharia
Situacao: A Product Manager insistia que a equipe entregasse uma feature complexa em tres sprints. O time estimava seis sprints, considerando a divida tecnica existente no modulo. As reunioes de planning viraram um cabo de guerra. A PM dizia “voces estao inflando estimativas”; o time dizia “voce nao entende a complexidade tecnica”.
Resolucao:
Este conflito exigiu uma abordagem diferente: transparencia radical. Organizei uma sessao de “Show, Don’t Tell” de 1 hora onde:
- O time mostrou o codigo legado no modulo afetado, explicando em linguagem acessivel por que era arriscado mexer sem refatorar
- Criamos juntos tres opcoes com trade-offs explicitos:
- Opcao A (3 sprints): Feature completa, sem refactoring. Risco alto de bugs em producao. Divida tecnica aumenta 40%%.
- Opcao B (4.5 sprints): Feature com 80%% do escopo + refactoring parcial. Risco medio. Divida estabiliza.
- Opcao C (6 sprints): Feature completa + refactoring. Risco baixo. Divida reduz 20%%.
- Colocamos em numeros: “Se escolhermos a Opcao A, estimamos 3 bugs criticos no primeiro mes. Cada bug critico custa em media 2 dias de dev para corrigir + impacto no cliente.”
Resultado: A PM escolheu a Opcao B. O time se sentiu ouvido, a PM teve visibilidade real dos trade-offs, e a feature foi entregue sem drama. O mais importante: esse formato virou o padrao para toda negociacao de escopo dali em diante.
Cenario 4: Dev Que Se Sente Injusticado na Distribuicao de Projetos
Situacao: Lucas, dev pleno com dois anos no time, veio me procurar frustrado. Ele percebia que os projetos mais interessantes e visiveis sempre iam para os mesmos dois devs seniors. Ele se sentia preso em tarefas de manutencao e bug fix, sem oportunidade de crescer.
Resolucao:
Primeiro, validei a percepcao. Fui olhar os dados: nos ultimos tres meses, 80%% das features novas tinham sido atribuidas a dois devs. Lucas tinha razao — nao era paranoia.
Reconheci o erro abertamente: “Lucas, voce tem razao. Eu cai na armadilha de sempre alocar quem ja tem experiencia no modulo para ir mais rapido. Isso criou um ciclo onde voce nunca ganha experiencia e nunca recebe projetos novos.”
Implementamos um sistema de “Shadow and Lead”:
- A cada projeto novo, um dev experiente fazia pair com um dev que queria crescer naquela area
- No projeto seguinte, os papeis se invertiam: o dev que estava aprendendo liderava, com o senior disponivel para consultas
- Criei uma matriz publica de “quem esta trabalhando no que” para que a distribuicao fosse transparente
Resultado: Em quatro meses, Lucas liderou duas features de media complexidade. Seu engajamento voltou ao nivel de quando tinha entrado no time. O bonus: os seniors ficaram aliviados por nao serem o “gargalo” de todo projeto complexo.
Cenario 5: Resistencia a Mudancas de Processo ou Tecnologia
Situacao: O time precisava migrar de uma stack legada para uma mais moderna. Tres devs estavam entusiasmados. Dois devs, ambos com mais de 5 anos na empresa, resistiam ativamente. Nas reunioes, os argumentos eram tecnicos (“a stack atual funciona”), mas o subtexto era claro: medo de se tornar irrelevante numa tecnologia que nao dominavam.
Resolucao:
O erro que muitos Tech Leads cometem aqui e tratar a resistencia como problema tecnico e bombardear com argumentos racionais sobre por que a nova stack e melhor. Isso nao funciona porque o problema nao e racional — e emocional.
Abordei de forma diferente:
- Reconheci o medo sem julgamento: “E natural se sentir desconfortavel com uma mudanca grande. A experiencia de voces na stack atual e valiosa, e nao vamos jogar fora esse conhecimento.”
- Criei seguranca: Aloquei 20%% do tempo da sprint por 6 semanas para estudos da nova stack, com pairing sessions entre os entusiastas e os resistentes.
- Dei protagonismo: Pedi que os resistentes liderassem a definicao do plano de migracao. “Voces sao quem mais conhece o sistema atual. Preciso de voces para garantir que a migracao nao quebre nada.”
- Defini marcos claros: “Vamos migrar um modulo pequeno primeiro. Se os resultados nao forem bons, reavaliamos.”
Resultado: Um dos resistentes se tornou o maior defensor da nova stack depois de perceber que seus anos de experiencia com o dominio do negocio eram mais valiosos que o conhecimento da tecnologia especifica. O outro saiu da empresa tres meses depois — e tudo bem. Nem todo conflito termina com todo mundo feliz.
Quando Intervir e Quando Deixar o Time Resolver
Uma das habilidades mais dificeis de desenvolver como Tech Lead e calibrar quando entrar num conflito e quando ficar de fora. Intervir cedo demais cria dependencia — o time nunca aprende a resolver seus proprios problemas. Intervir tarde demais permite que o conflito escale e cause danos reais.
Aqui esta minha regra pratica, construida na base da tentativa e erro:
Deixe o time resolver quando:
- O conflito e puramente tecnico e ambas as partes estao debatendo ideias (nao pessoas)
- O tom e respeitoso, mesmo que intenso
- O conflito nao esta travando uma entrega critica
- As pessoas envolvidas tem historico de resolver desacordos de forma madura
Intervenha imediatamente quando:
- O tom se tornou pessoal (ataques a pessoa, nao a ideia)
- Uma das partes esta visivelmente desconfortavel ou em silencio forcado
- O conflito esta afetando outras pessoas do time (pessoas evitando reunioes, clima pesado)
- Ha desequilibrio de poder (senior intimidando junior, por exemplo)
- O conflito ja dura mais de dois dias sem progresso
A regra de ouro: quando em duvida, tenha uma conversa informal 1:1 com cada parte antes de decidir se intervem publicamente. Muitas vezes, uma pergunta simples como “como voce esta se sentindo sobre aquela discussao com o [colega]?” revela se a pessoa precisa de suporte ou se esta lidando bem sozinha.
Um erro comum de Tech Leads iniciantes e resolver conflitos “para” o time em vez de “com” o time. Se voce sempre da a resposta, o time aprende que conflito = escalar para o lead. O objetivo e construir a capacidade do time de resolver conflitos autonomamente, com voce intervindo apenas quando o nivel de complexidade ou risco justifica.
Como Criar Uma Cultura Onde Conflitos Sao Produtivos
Resolver conflitos caso a caso e necessario, mas nao escala. O que realmente transforma um time e criar uma cultura onde o conflito produtivo e a norma, nao a excecao. Aqui estao seis praticas que implementei em todos os times que liderei:
1. Estabeleca normas de equipe explicitas
Na primeira semana de qualquer time que lidero, facilitamos uma sessao para definir nosso “contrato social”. Perguntas como: “Como queremos lidar com desacordos tecnicos?” e “O que fazemos quando alguem se sente desrespeitado?” geram regras que o time criou e, portanto, respeita. Documente essas normas e revisem a cada trimestre.
2. Normalize o desacordo publico
Quando um dev discorda de mim numa reuniao, agradeco publicamente: “Boa, eu nao tinha pensado por esse angulo.” Isso envia um sinal poderoso: discordar aqui e seguro, e ate valorizado. Se o lider nao modela esse comportamento, o time nunca vai se sentir seguro para discordar.
3. Use retrospectivas como valvula de pressao
Retrospectivas bem facilitadas sao a melhor ferramenta preventiva contra conflitos destrutivos. Quando o time tem um espaco regular e seguro para expressar frustracao, a pressao nao acumula ate explodir. O segredo e ir alem do formato padrao: use dinamicas que permitam feedback anonimo quando temas sensiveis precisam emergir.
4. Pratique a discordancia e compromisso
Quando nao ha consenso, alguem precisa decidir. Ensine o time o conceito de “disagree and commit” (popularizado pela Amazon): voce pode discordar da decisao, mas uma vez tomada, todos se comprometem a executa-la com o melhor esforco. Isso evita o sabotamento passivo que acontece quando alguem “perde” um debate.
5. Separe a pessoa da ideia — de forma explicita
Nas discussoes tecnicas, ensine o time a usar linguagem que separa identidade de proposta. “Eu vejo um risco nessa abordagem” e diferente de “Sua abordagem e arriscada”. Parece sutil, mas o cerebro processa de forma diferente. No primeiro caso, o risco esta na abordagem; no segundo, esta associado a pessoa.
6. Crie canais de feedback continuo
Nao espere a retrospectiva ou a avaliacao anual para lidar com tensoes. 1:1s regulares sao o momento ideal para captar conflitos nascentes antes que escalem. Uma pergunta simples como “tem algo te incomodando que voce gostaria de falar?” abre espaco. O artigo sobre 1:1 para Tech Leads tem templates especificos para essas conversas.
O Pilar People no First Lead
Tudo que discutimos neste artigo — mediacao de conflitos, construcao de cultura, comunicacao dificil — faz parte do que chamo de Pilar People da lideranca tecnica. No programa First Lead, esse e um dos tres pilares fundamentais (junto com Technical e Process) que todo Tech Lead precisa dominar.
A verdade e que a maioria dos Tech Leads chega ao cargo por competencia tecnica, mas o que determina sucesso ou fracasso na funcao e a habilidade com pessoas. Voce pode ser o melhor arquiteto do time, mas se nao souber navegar conflitos, dar feedback dificil e desenvolver as pessoas ao seu redor, seu time nunca vai atingir o potencial real.
O pilar People no First Lead cobre exatamente isso: frameworks praticos para feedback (como o modelo para feedback dificil), tecnicas de mediacao como o DESC que voce aprendeu aqui, e estruturas para desenvolver cada pessoa do time de forma intencional.
Se voce quer se aprofundar nesses temas, visite liderancatecnica.com.br e explore os conteudos sobre lideranca tecnica e gestao de pessoas em engenharia.
Conclusao
Conflitos no time de desenvolvimento nao sao um problema a ser eliminado — sao uma realidade a ser gerenciada. A diferenca entre um time mediocre e um time de alta performance nao e a ausencia de conflitos, mas a capacidade de transforma-los em oportunidades de melhoria.
Vamos recapitular o que cobrimos:
- Conflitos sao inevitaveis em times de engenharia — e isso e saudavel quando bem gerenciado
- Existem cinco tipos principais de conflito (tecnico, comunicacao, ego, processo e interpessoal), e cada um exige uma abordagem diferente
- O Framework DESC (Descrever, Expressar, Sugerir, Consequencias) e uma ferramenta pratica para mediar qualquer conflito
- Saber quando intervir e quando recuar e tao importante quanto saber como mediar
- O objetivo final e criar uma cultura onde conflito produtivo e a norma
O proximo passo e pratico: na sua proxima 1:1, pergunte a cada pessoa do seu time “existe alguma tensao ou desacordo que eu deveria saber?”. Voce vai se surpreender com o que emerge quando voce abre espaco.
E lembre-se: o melhor momento para aprender a mediar conflitos e antes de precisar. O segundo melhor momento e agora.
Para mais conteudos praticos sobre lideranca tecnica, gestao de pessoas em engenharia e crescimento de carreira em tech, visite liderancatecnica.com.br.