De Dev Sênior a Tech Lead: Lições que Ninguém Me Ensinou
Porque virar Tech Lead é menos sobre código e mais sobre gente.
Você começa achando que ser promovido é uma questão de escrever código limpo, cumprir tasks, entender e ser “rápido”. Aí um dia te chamam numa sala (ou numa call) e dizem: “Parabéns, agora você é o tech lead do time.”
O que ninguém te conta é que a partir daí, seu teclado pesa mais. As cobranças mudam. E seu dia passa a ser dividido entre código, conflitos, decisões que afetam todo mundo e aquela sensação de estar no meio de um incêndio sem poder demonstrar desespero.
Neste artigo, compartilho lições que aprendi na prática. Não foi em curso de liderança, nem em tutorial no YouTube. Foi errando, ouvindo, segurando rojão e aprendendo a liderar sem deixar de ser dev.
Técnica te leva até a vaga. Mas são as soft skills que te mantêm no cargo.
Quando você é promovido a Tech Lead, ninguém te entrega um manual dizendo:
"Parabéns! Agora, além de resolver problemas técnicos complexos, você também vai lidar com conflitos, frustrações, decisões políticas e crises de ego… inclusive o seu." 😅
A ficha demora a cair.
No começo, você tenta seguir o que te trouxe até ali: codar bem, entregar rápido, resolver bugs difíceis. Mas aos poucos percebe que o jogo mudou.
Agora, o seu código já não é mais o que tem mais impacto. O que realmente pesa é sua postura quando o caos bate na porta.
Situação 1: A daily tensa
Um dev do time solta, visivelmente irritado:
“Já faz três dias que estou travado esperando a API da equipe X. Não dá pra continuar assim.”
Se você age puramente como engenheiro, sua cabeça vai direto para a solução técnica: “Vamos mockar a API deles, isolar essa parte do fluxo e seguir.”
Mas o time está frustrado. O problema não é só técnico, é emocional.
Se você ignora isso e responde com frieza, passa a mensagem errada:
“Problemas humanos são menos importantes do que o código.”
O resultado? O time se fecha. A confiança diminui. E a frustração cresce em silêncio.
Situação 2: O bug em produção (que não foi seu)
Sexta-feira, 17h30. Um bug grave vai pro ar. O time entra em pânico. Você revê os commits, percebe que foi algo feito por um dev júnior que está visivelmente abalado.
Você tem duas opções:
Reagir com raiva e buscar culpados
Assumir a liderança, manter a calma, corrigir rápido, e depois conversar com empatia
Se você escolhe a primeira, o time começa a esconder erros e ter medo de tomar iniciativa. Se escolhe a segunda, constrói segurança psicológica e um time que cresce com você.
Os três pilares que ninguém te ensina…
Ser Tech Lead não exige só saber codar, mas desenvolver três competências que normalmente não aparecem no currículo técnico:
1. Inteligência emocional
Não é sobre “ser calmo”. É sobre reconhecer seus gatilhos, controlar reações automáticas, e entender que as emoções do time impactam diretamente a entrega.
Você vai:
Receber críticas injustas
Ser pressionado por decisões fora do seu controle
Ter que manter a postura mesmo quando quiser gritar
2. Comunicação
A falha de comunicação é o bug mais difícil de debugar.
Saber explicar problemas técnicos para pessoas não técnicas é crucial. Mas mais que isso:
Você precisa falar com clareza, escutar com atenção e alinhar expectativas antes que elas virem decepções.
Exemplo clássico:
PO: “Mas eu entendi que isso estaria pronto hoje…”
Você: “A gente precisa revisar juntos o escopo e os riscos antes de estimar. Vamos marcar 15 minutos pra isso?”
3. Maturidade para lidar com erros (seus e dos outros)
Como Tech Lead, você vai errar. E o time também. O que muda é que agora você não pode simplesmente dizer: “não era comigo”.
Você vai:
Assumir responsabilidades que não foram suas
Corrigir bugs em crises sem expor quem cometeu
E quando tudo der certo... provavelmente não receber crédito algum
Então…
Liderar engenharia não é sobre ter todas as respostas, é sobre manter a direção quando o terreno muda, o tempo fecha e o GPS falha.
Por isso, antes de pensar em ser Tech Lead ou aceitar, pergunte:
Eu consigo manter a calma quando tudo está dando errado?
Eu sei ouvir sem reagir?
Eu sei comunicar minhas ideias sem parecer agressivo ou passivo?
Se a resposta for “ainda não”, não tem problema.
Mas é aí que você precisa investir antes da próxima promoção.
Gerenciar sem virar chefe: quando o caos bate, sua postura define o rumo
Ninguém me avisou que ser Tech Lead significava estar no meio do fogo cruzado entre código mal documentado, fluxo quebrado, regra de negócio frágil e pressão vinda de cima.
E o pior: tudo isso acontecendo ao mesmo tempo — numa sexta-feira às 16h.
Já trabalhei em sistemas onde:
Um campo invisível numa planilha alterava o cálculo de pagamento de centenas de clientes.
Uma regra tributária mal interpretada por um dev gerou prejuízo real — financeiro.
Um fluxo mal desenhado no backend deixou o time refém do “jeitinho” por meses.
Nessas horas, o instinto natural é explodir:
“Por que isso foi feito assim?”
“Quem aprovou isso?”
“Esse fluxo não faz o menor sentido!”
Mas explodir não resolve. Procurar culpados só espalha insegurança.
O que um Tech Lead precisa fazer é observar, entender e trazer clareza… mesmo no meio do caos.
O que você faz define o clima do time (e a confiança da gestão)
Quando tudo dá errado, as pessoas esperam de você:
Calma
Clareza
Capacidade de encontrar o primeiro passo da solução
Se você se desespera, o time desmorona junto.
Se você mantém a postura, transmite confiança para o time e segurança para gerentes e coordenadores.
Tech Leads bons estancam sangramentos antes de buscar a cura ideal
Você não vai conseguir consertar tudo de uma vez.
Então você aprende a fazer perguntas melhores:
“Onde esse bug começou?”
“Qual é o real impacto disso hoje?”
“Tem algo que podemos fazer agora para mitigar sem quebrar o sistema ou o time?”
Às vezes a solução perfeita não cabe no tempo ou na estrutura da empresa.
Você vai precisar propor soluções viáveis, mesmo que imperfeitas, que:
Atendam a expectativa
Evitem que o time enlouqueça
Reduzam o impacto até que dê pra resolver direito
A regra que mudava de acordo com o humor da diretoria
Em uma das empresas em que trabalhei, a regra de faturamento mudava com base em exceções “não documentadas”. Todo o cálculo da comissão era um monstro mutante. A cada semana, surgia uma regra nova que invalidava a anterior.
Era impossível testar tudo. Ninguém entendia as mudanças.
O time estava exausto. A coordenação, pressionando. E os erros, indo pra produção.
O que eu fiz? Eu não era tech lead e não tinhamos um líder técnico! Mas eu tinha um cargo de Sênior. Então eu arrisquei… 👇🏼
Chamei o PO e pedi que oficializássemos pelo menos a regra atual vigente.
Pedi ao time para mapear os fluxos em um Miro simples, só pra visualizarmos o caos.
Sugeri a implementação de feature flags nos pontos de divergência, para isolar riscos.
Montei um documento vivo com as “exceções não documentadas” e sugeri uma reunião mensal de revisão técnica com o negócio.
Não resolveu tudo.
Mas criou uma linha de estabilidade no meio do caos.
E isso aliviou o time, melhorou a comunicação com o negócio e reduziu erros graves.
Ser Tech Lead não é virar chefe.
É ser quem observa com calma, entende onde a ferida começou e guia o time pra solução mais sensata mesmo quando ela não é perfeita.
Porque quem mantém a cabeça no lugar quando todo mundo tá perdendo a sua… é quem lidera de verdade.
Aprender a dizer “não” sem parecer arrogante (ou virar o chato da squad)
Ser promovido a Tech Lead não vem com superpoderes. Mas vem com uma missão ingrata: saber quando dizer “não” — e como dizer isso sem paralisar o time ou entrar em conflito com o negócio.
E aqui está a verdade:
Dizer “não” não é ser negativo.
É ser responsável.
Só que quando você nega algo como Tech Lead, você precisa justificar com clareza, empatia e dados — mesmo que ninguém queira ouvir.
O jogo dos trade-offs
Antes de ser Tech Lead, você pensa em código.
Depois, você precisa pensar em compromissos:
Velocidade vs. Qualidade
Flexibilidade vs. Manutenibilidade
Prazo curto vs. Custo futuro (inclusive financeiro)
Quer subir uma feature com pressa, ignorando uma validação crítica?
Tudo bem. Mas saiba que se der problema, pode custar tempo, dinheiro e até reputação da empresa.
Você consegue bancar esse risco?
Essa é a pergunta que comecei a fazer e que todo sênior deveria aprender antes de virar Tech Lead.
Comunicação transparente: a habilidade que ninguém valoriza (até dar problema)
Você não pode florear. Nem usar jargão técnico pra esconder uma má decisão.
Se há riscos graves, eles precisam ser ditos — com clareza e sem medo de desagradar:
“Se lançarmos isso agora, com a arquitetura atual, há risco de quebra em produção com impacto direto no faturamento. Podemos mitigar? Sim. Mas exige tempo e alinhamento.”
Sim, pode ser desconfortável.
Sim, o PO pode torcer o nariz.
Sim, o gerente pode te pressionar.
Mas é aí que entra o seu papel:
Ser transparente mesmo quando a verdade incomoda.
E fazer isso com respeito, bom senso e espírito de parceria.
A feature que ia sair “de qualquer jeito”
Uma vez, recebemos uma solicitação para lançar uma nova funcionalidade que alterava um cálculo sensível de comissão e o prazo era de 3 dias.
Era inviável. Não só pelo tempo, mas porque a lógica afetava outros módulos e não havia cobertura de testes confiável.
O que eu fiz:
Mapeei o impacto técnico (quais partes do sistema seriam afetadas)
Estimei o risco financeiro caso algo desse errado (baseado em erros anteriores)
Chamei o PO e o gerente para uma conversa objetiva:
“Fazer isso em 3 dias é possível... se aceitarmos o risco de erro em produção e clientes reclamando.
Em 5 dias, podemos fazer com testes e deploy seguro.
Vocês preferem correr ou entregar com controle?”
Eles optaram pelo segundo caminho. Por quê? Porque eu fui transparente, dei opções e mostrei as consequências. Sem dramatizar. Sem fugir da responsabilidade.
Bom senso e contexto: o combo que diferencia um sênior de um líder
Negar por negar é arrogância.
Negar com base em contexto, riscos e empatia é liderança técnica.
Antes de virar Tech Lead, todo sênior precisa entender que:
Negar uma demanda maluca pode salvar o time de uma crise
Negar sem explicar pode te isolar
Negar com sabedoria pode construir confiança até com quem discorda de você
Mas isso, meus caros leitores, não se aprende de uma hora pra outra.
É um treino diário:
Saber o momento certo de falar
Entender o público que te escuta (dev, PO, gerente)
Ter coragem de ser o adulto na sala
Ser Tech Lead não é sobre agradar. É ser realista, transparente e estratégico!
E isso só é possível com uma comunicação transparente, firme e respeitosa.
Porque esconder os riscos pra “não causar conflito” não é diplomacia —
É omissão.
A arquitetura bonita no papel vai falhar na vida real
Eu acreditava, com convicção, que uma arquitetura bem desenhada resolvia 90% dos problemas de um sistema. Se o diagrama estava limpo, as camadas bem separadas, os fluxos bem definidos… o resto era “só implementação”.
A ilusão durou pouco.
Na prática, aprendi que os sistemas não falham só por código ruim — falham porque pessoas, contexto e pressa quebram até os melhores desenhos.
O problema não é só técnico. É social.
A arquitetura que você desenha no Miro pode ser linda.
Mas na empresa real:
O dev que precisa implementar aquilo não teve tempo de entender os conceitos.
O PO está pressionando por uma entrega em 7 dias.
O QA ainda nem sabe que haverá mudança.
E o gerente está perguntando se dá pra “subir um MVP sem testes”.
Resultado? A arquitetura vai pro espaço na primeira curva.
E você assiste sua ideia ser diluída, mal adaptada, e culpada por algo que ninguém conseguiu seguir.
Lições que aprendi no tapa:
Não adianta ter uma arquitetura perfeita se ninguém entende por quê ela existe.
A arquitetura precisa ser pedagógica, não só correta.
Você não implementa diagramas. Você implementa decisões.
E cada decisão tem um custo político, emocional e prático.
Gargalos acontecem nas bordas humanas — não nos blocos técnicos.
Uma interface mal combinada entre duas squads destrói mais que uma má escolha de framework.
A arquitetura que ignorou o time
Em um projeto, criamos uma arquitetura com separação de bounded contexts, filas assíncronas, comunicação via eventos, camada de orquestração, ports & adapters… tudo redondo no papel.
Só que:
O time não teve onboarding decente.
Ninguém explicou os princípios com exemplos reais.
Os devs começaram a misturar os contextos.
As filas viraram mecanismos de “retry automático”.
E a orquestração foi parar no controller porque “tinha que entregar até sexta”.
O sistema virou um monstro.
A arquitetura não falhou porque era ruim. Ela falhou porque ninguém teve tempo de aplicá-la direito.
Então o que funciona?
1. Arquitetura viável > arquitetura ideal
Sempre pergunte: “Com o time e o tempo que temos hoje, o que é o mínimo necessário pra manter esse sistema saudável?”
2. Explique a arquitetura como se fosse para um dev júnior
Porque se ela não for entendida por todos, ela não vai ser respeitada.
3. Entenda o contexto antes de aplicar o padrão
Não implemente Event Sourcing se seu time não tem maturidade para lidar com eventual consistency.
Não force ports & adapters se o sistema nem tem regras de domínio claras ainda.
Diagramas não salvam sistemas. Pessoas bem alinhadas sim.
A arquitetura precisa ser clara, executável e apropriada ao momento do time.
A beleza de uma arquitetura está na sua resiliência frente ao caos, e não na sua estética de conference talk.
Se ela não aguenta a realidade da squad, do negócio, da urgência e da limitação humana — ela não serve.
Você ainda vai errar e vai precisar aprender a lidar com isso
Ser promovido a Tech Lead não te blinda de errar.
Na verdade, os erros ganham outra escala:
Agora, seus erros não quebram só código. Afetam o time. Impactam o negócio.
E a parte mais difícil?
Você vai errar mesmo tentando fazer o certo.
Erros que Tech Leads cometem mesmo com boas intenções:
Apressar uma decisão arquitetural pra evitar atraso… e criar uma dívida técnica que vira bola de neve.
Aceitar uma estimativa otimista demais pra “não travar o negócio”… e falhar em entregar.
Delegar algo delicado sem acompanhar de perto… e ver o time cair em armadilhas evitáveis.
Confiar que “o time entendeu o alinhamento”... e só descobrir na hora do deploy que não entendeu.
Você não errou por ser irresponsável.
Você errou porque é impossível liderar engenharia sem risco.
O que separa bons Tech Leads dos inseguros é o que fazem depois do erro
Quando algo quebra, você tem duas escolhas:
Gastar energia tentando justificar ou culpar alguém
Ou levantar a cabeça, assumir, entender e corrigir
Quem assume com maturidade:
Traz calma para o time
Constrói confiança com gerentes
E aprende lições que viram bagagem — não trauma
Exemplo: o bug que só apareceu no último passo
Num projeto crítico, eu garanti: “Testamos tudo. Pode subir.”
Mas o fluxo tinha uma exceção escondida, ligada a uma feature flag esquecida. O sistema quebrou pra 5% dos usuários… os 5% mais sensíveis.
Eu poderia ter dito:
“Não foi minha culpa. A flag foi ativada sem avisar.”
Mas preferi dizer:
“Eu não antecipei esse risco. Aqui está o que estamos fazendo pra corrigir. E aqui está o plano pra que isso não aconteça mais.”
Doeu. Mas fortaleceu a confiança do time.
E me ensinou algo fundamental:
Como Tech Lead, você não é culpado de tudo. Mas você é responsável por tudo.
Transformar erro em aprendizado exige humildade
Errar é inevitável.
Negar o erro é opcional.
E crescer com ele é uma decisão que você precisa tomar — todas as semanas.
É por isso que, antes de virar Tech Lead, um sênior precisa estar pronto para:
Admitir quando falha
Corrigir sem esconder
Pedir ajuda sem perder o respeito
O respeito que você constrói como Tech Lead não vem por nunca errar, vem da forma como você responde quando tudo dá errado.
E essa maturidade, meus caros leitores, não nasce com o cargo.
Ela vem com cada bug, cada entrega mal alinhada, cada conversa difícil e com a coragem de continuar mesmo depois de falhar.
O que um sênior precisa saber antes de aceitar (ou buscar) uma vaga de Tech Lead
Ser Tech Lead não é um prêmio pela sua senioridade.
É um novo tipo de responsabilidade… mais humana do que técnica.
Você não vai passar o dia só codando.
Vai passar o dia tomando decisões difíceis, dizendo “não” com empatia, filtrando pressão da gestão, protegendo o time e sendo cobrado por resultados que muitas vezes não dependem só de você.
Antes de buscar esse cargo, se pergunte com sinceridade:
Eu sei manter a calma quando tudo está desmoronando?
Eu sei me comunicar de forma clara, mesmo em situações tensas?
Eu consigo assumir responsabilidades sem precisar de aplauso?
Eu tenho maturidade para errar — e aprender com isso?
Eu sei priorizar o bem do time, mesmo que isso custe a minha zona de conforto?
Se a resposta for "não" para alguma dessas perguntas, tudo bem.
Não significa que você não está pronto. Significa que você precisa se preparar além do código.
Porque no fim das contas, o que sustenta um Tech Lead não é o conhecimento técnico, é o caráter em meio ao caos.