Liderança Técnica na área da TI

O contexto

Em 2023, fui convidado pra um episódio do podcast da DBC Company, empresa pela qual eu passava na época, prestando serviço pra Unicred. O tema era "Liderança Técnica na área da TI" — conduzido pelo Maicon, com o Glauber Barbosa como outro convidado.

A conversa tinha um formato aberto: três profissionais de TI, todos com mais ou menos o mesmo tempo de casa, falando sobre o que realmente faz um líder técnico — fora do LinkedIn de papel.

Foi gravado em home office, com direito a uma queda de conexão no meio e uma história insusitada que entrou no episódio (eu tive que fazer o parto da minha filha por chamada de vídeo — isso virou parte do papo, não teve como tirar). O tom era de troca entre pares, não de aula.

🔗 Ouvir no Spotify

O desafio real

Falar sobre liderança em formato podcast tem um problema difícil: você está explicando, em tempo real, um papel que você exerce — e o público não sabe ainda se o que você diz combina com o que você faz.

A tentação é cair no discurso. Falar do líder como se fosse uma ideia abstrata, listar boas práticas, repetir o que todo mundo repete.

A regra que a gente seguiu foi simples: falar do que a gente vivia. Se a frase não passava pelo crivo de "eu faço isso ou já fiz parecido", ela não entrava.

Foi o que segurou o papo.

O que faz um líder técnico — na prática

Eu abri a primeira rodada com o que eu realmente entendia como sendo o papel. Glauber completou, Maicon intermediou. O que ficou de comum entre os três:

• Formar pessoas. Quem entrou júnior tem que sair dali mais perto de pleno e sênior. O caminho não é dado pronto, mas vai sendo desenhado.
• Tirar bloqueio técnico. Quando alguém está há dias parado num problema, o líder tem que ser o ponto que destrava — não o que resolve sozinho.
• Traduzir negócio pra tecnologia. Estar junto no discovery, conversar com PO, questionar o design antes que vire tela bonita-impossível.
  Glauber complementou com uma camada que eu não tinha verbalizado na hora, mas concordava: o líder técnico é responsável pela entrega técnica como um todo. Garantir qualidade, garantir que vai pra homologação, garantir que não vai dar problema em produção. Mesmo quando quem está olhando o log em produção não é ele.
  A frase que ficou como resumo, mais ou menos, foi: formar, destravar, traduzir. Três coisas. Não é pouca coisa.

Metodologias ágeis — quando ajudam e quando atrapalham

A segunda rodada foi sobre ágil. Eu falei do meu histórico: tinha vivido cascata no início da carreira — projeto fiscal que ficou meses em desenvolvimento e quebrou porque a regra mudou no final.

Depois disso, nunca mais. Comecei com Scrum clássico (planning, review, retrospectiva), que funcionou bem. Mais recentemente, tinha migrado pra Kanban com Flight Levels — operacional, tático, estratégico — que estava me dando uma coordenação melhor entre os níveis do cliente.

Glauber trouxe uma visão complementar: no mercado de TI, o ritmo não é constante. Tem mês que você trabalha até onze da noite, tem mês que respira. Ágil funciona, mas tem hora que o prazo é o prazo — e adaptar o processo pra caber na realidade é parte do trabalho.

A síntese do Maicon, que eu subscrevi, foi: ágil precisa estar no dia a dia, mesmo quando o formato é adaptado. Não dá pra rodar projeto sério sem ele. Mas também não dá pra fingir que tudo vai caber num sprint fechado quando a entrega tem data fixa e o escopo muda toda segunda.

LT codar ou não codar

Essa pergunta veio do Maicon. Eu respondi: depende do tamanho e da maturidade do time. Recém-formado, inevitavelmente o LT bota a mão. Hotfix em produção, legado que ninguém conhece — vai lá e corrige, depois explica.

Mas o ideal, sempre, é delegar.

Glauber foi mais radical: faz tempo que ele não toca em código. O mais perto que chega é code review. Eu vejo os dois lados. Hoje, em times maiores, o LT que fica no código vira gargalo. Em times pequenos, o LT que não bota a mão vira ausente.

Não existe regra. Existe leitura do contexto.

Feedback — o que funciona, o que só parece que funciona

Esse foi o bloco mais longo e, pra mim, o mais útil. Porque os três tinham visões diferentes sobre a mesma coisa.

Eu trouxe o que eu sentia na pele como dev: feedback tardio e raso é pior que nenhum feedback. Quando eu era desenvolvedor e demorava pra receber retorno sobre o que eu estava entregando bem ou mal, ficava perdido. Mudou minha forma de trabalhar quando comecei a receber feedback com frequência.

O formato que eu uso:

• Conexão primeiro. Antes de falar do trabalho, gente abre espaço humano. Como você está, como está a família, o que está rolando.
• Pontos a melhorar. Específicos, sem generalizar.
• Pontos positivos. Sem esconder o que está funcionando bem.
• Alinhamento de expectativa. O que eu espero de você, o que você espera de mim.
  A regra que virou consenso no episódio: elogio em público, correção em privado. A não ser que o cara se empolgue demais com o elogio e comece a subir régua antes da hora — aí também segura.
  Glauber trouxe um insight que ficou: feedback precisa ler a pessoa. Às vezes o cara não está mal no trabalho, está mal em casa. Dar feedback ruim pra alguém que está no limite é receita pra desastre. Ler o humor, ler o momento, escolher o canal certo.
  A periodicidade? Glauber defende que feedback é a todo momento. Eu defendo um espaço mais formal a cada dois meses com cada pessoa, pra olhar evolução com mais calma. Os dois funcionam. O importante é não esperar o problema virar.

Como medir evolução de uma pessoa

Pergunta do Maicon: como saber se o cara está evoluindo?

Eu respondi com o que eu faço na prática: vou subindo o nível da tarefa e observo. Se o cara entrega bem, aumento a dificuldade. Se ele para de me acionar, está ficando autônomo. Não tem planilha, tem leitura.

Glauber completou: depende do que a pessoa quer. Tem cara que bateu no teto de sênior e não quer ir pra gestão — quer se aprofundar em dados, IA, o que for. Forçar trilha de liderança pra quem quer ser referência técnica é desperdiçar a pessoa.

O ponto é: métricas de evolução são individuais. O que vale pro júnior é diferente do que vale pro sênior. E a única métrica que importa, no fim, é: a pessoa está mais autônoma do que estava há três meses?

Todo mundo pode ser líder técnico?

Última rodada. Maicon perguntou se qualquer pessoa pode ser líder técnico.

Eu respondi com a minha própria história. Entrei como assistente de desenvolvimento. Nunca tinha imaginado liderar nada. Comecei a ajudar os colegas por conta própria — quando meu líder faltava, eu cobria. Ele percebeu, falou que eu já fazia o papel, perguntou se eu queria a posição. Eu disse que nem imaginava que estava tão perto.

A transição foi natural, não uma promoção clássica. Foi a evolução da função falando mais alto que o cargo.

Glauber completou: a liderança chegou pra ele da mesma forma. Aconteceu aos poucos, sem um momento exato de virada.

O ponto de convergência: liderança técnica não é um dom. É um conjunto de habilidades interpessoais que se aprende praticando, com gente real, em time real. Não tem atalho, mas tem caminho.

O que ficou desse papo

Esse episódio não mudou minha carreira. Mas registrou um momento específico dela: 2023, na DBC, ainda como dev/líder em consultoria, antes da Unicred, antes do IB.

Quando eu olho pra trás, percebo que muita coisa que eu falei nesse episódio eu ainda faço hoje. Outra coisa eu já faço diferente. E tem coisa que eu nem lembrava que pensava assim.

O Glauber, o Maicon e eu estávamos no meio do caminho. Não sabíamos onde aquilo ia dar. Mas a honestidade do papo ficou.

Se eu fosse ouvir hoje, ouviria com a curiosidade de reencontrar uma versão anterior de mim — e reconhecer nela a semente do que eu me tornei depois.

Esse projeto é um registro de um episódio de podcast, não um case técnico. Os detalhes técnicos da conversa foram intencionalmente preservados como conversa — o foco aqui é o que foi dito, não o que foi construído depois.