Uma das situações mais comuns quando começamos a liderar tecnicamente um time é perceber que alguém precisa desenvolver determinada competência. Talvez um desenvolvedor tenha dificuldade para tomar decisões de arquitetura, outro precise melhorar a comunicação e um terceiro ainda dependa muito de orientação para conseguir trabalhar com autonomia.
A gente identifica a dificuldade, conversa com a pessoa e, quase naturalmente, surge aquela recomendação: “Acho que seria interessante você fazer um curso sobre isso”. Pronto. Problema resolvido. Agora é só esperar a plataforma emitir o certificado e teremos um desenvolvedor melhor, certo?
Bom, não é exatamente assim. Não tenho absolutamente nada contra cursos. Pelo contrário, continuo estudando e acredito que formação contínua é indispensável para quem trabalha com tecnologia. O problema começa quando confundimos oferecer acesso ao conhecimento com desenvolver uma competência. São coisas relacionadas, mas bastante diferentes.
Alguém pode concluir um excelente curso de arquitetura de software e continuar sem conseguir defender uma decisão arquitetural diante do time. Pode estudar comunicação durante semanas e ainda ter dificuldade para explicar uma ideia em uma reunião. Pode conhecer todos os princípios SOLID e continuar sem perceber quando está introduzindo complexidade desnecessária em uma aplicação.
Conhecimento é importante, mas desenvolvimento também exige oportunidade para aplicar, errar, receber orientação, refletir e tentar novamente. E é justamente aí que a liderança técnica começa a fazer diferença.
Antes de pensar na solução, precisamos entender a dificuldade
Imagine que um desenvolvedor tenha dificuldade para participar de discussões de arquitetura. Durante os refinamentos, ele quase não contribui e normalmente espera alguém mais experiente apresentar uma solução.
A conclusão mais rápida seria dizer que ele precisa estudar arquitetura de software. Mas será que esse é realmente o problema?
Talvez ele tenha conhecimento suficiente para participar, mas não se sinta confortável em discordar de profissionais mais experientes. Talvez não conheça o contexto de negócio necessário para avaliar as alternativas. Talvez consiga identificar problemas técnicos, mas tenha dificuldade para organizar os argumentos e apresentá-los. Ou talvez realmente exista uma lacuna de conhecimento sobre os fundamentos de arquitetura. Cada uma dessas situações exige uma abordagem diferente.
Se o problema for conhecimento, estudar pode ajudar bastante. Se for insegurança, talvez a pessoa precise de oportunidades graduais para participar das decisões. Se for falta de contexto, nenhum curso genérico vai substituir uma conversa sobre o produto e suas restrições. Se for comunicação, ela provavelmente vai precisar praticar, receber feedback e aprender a estruturar melhor seus argumentos.
Por isso, antes de recomendar qualquer ação de desenvolvimento, vale entender qual comportamento precisa mudar e o que está impedindo essa mudança. É uma diferença parecida com aquela que encontramos ao investigar problemas técnicos. Não adianta começar a implementar uma solução antes de entender o problema que estamos tentando resolver.
Curiosamente, fazemos isso com bastante disciplina quando estamos analisando software, mas nem sempre aplicamos o mesmo cuidado quando estamos falando de pessoas.
Desenvolvimento não acontece apenas consumindo conteúdo
Existe um conceito bastante conhecido em aprendizagem e desenvolvimento profissional chamado modelo 70-20-10. Ele organiza as experiências de aprendizagem em três dimensões: experiências práticas, interações com outras pessoas e educação formal.
Os números são uma referência conceitual, não uma proporção exata que toda pessoa precisa seguir. O que me interessa nesse modelo é a lembrança de que aprender envolve muito mais do que assistir a aulas ou consumir materiais. E na engenharia de software, isso fica especialmente evidente.
Você pode estudar testes automatizados, mas desenvolver essa competência envolve escrever testes para situações reais, lidar com código difícil de testar, discutir estratégias com colegas e perceber como suas decisões influenciam a manutenção do sistema.
Pode estudar liderança técnica, mas dificilmente vai aprender a facilitar uma discussão entre pessoas com opiniões diferentes sem participar dessas situações.
Pode estudar arquitetura, mas tomar boas decisões arquiteturais exige entender restrições, avaliar alternativas, reconhecer riscos e lidar com consequências que nem sempre aparecem nos exemplos dos cursos.
É por isso que gosto de pensar no desenvolvimento como uma combinação de três elementos: conhecimento, experiência e acompanhamento. O conhecimento ajuda a compreender os fundamentos. A experiência permite colocar esses fundamentos à prova. E o acompanhamento cria oportunidades para identificar o que funcionou, entender o que precisa melhorar e orientar os próximos passos. Um curso pode até participar desse processo. Ele só não deveria ser o processo inteiro.
Às vezes, a melhor oportunidade de desenvolvimento já está no backlog
Imagine que alguém do time queira evoluir em arquitetura de software. Podemos recomendar livros, cursos, artigos e palestras. Tudo isso pode ser útil. Mas também podemos procurar uma oportunidade dentro do próprio trabalho.
Talvez exista uma funcionalidade nova que exija decisões sobre integração entre serviços. Em vez de entregar a solução arquitetural pronta, o Tech Lead pode convidar essa pessoa para investigar alternativas, levantar riscos e apresentar uma proposta para discussão.
Ela não precisa assumir sozinha uma decisão crítica para a qual ainda não está preparada. Podemos definir limites, compartilhar contexto, acompanhar o raciocínio e oferecer suporte durante o processo. O importante é que exista espaço para pensar, propor e decidir.
Em outro cenário, alguém pode precisar desenvolver comunicação. Em vez de apenas recomendar um treinamento, podemos oferecer a oportunidade de apresentar uma solução técnica, conduzir parte de um refinamento ou explicar uma decisão arquitetural para pessoas de outra área.
Se o objetivo é desenvolver colaboração, pair programming, code review e atividades compartilhadas podem oferecer oportunidades de aprendizado que dificilmente seriam reproduzidas em uma aula.
Isso exige um cuidado importante: desenvolvimento não pode ser uma desculpa para simplesmente jogar responsabilidades sobre alguém. Dar uma oportunidade de crescimento é diferente de abandonar uma pessoa diante de um desafio para o qual ela ainda não possui condições de responder.
A responsabilidade do líder também está em calibrar a dificuldade, oferecer suporte e permitir que a autonomia aumente conforme a capacidade se desenvolve.
E isso nos leva de volta ao assunto que discutimos no artigo sobre os níveis de delegação. A autonomia não precisa ser entregue de uma vez. Ela pode ser construída gradualmente, conforme a pessoa ganha experiência, contexto e confiança.
O Tech Lead também precisa aprender a não fazer tudo sozinho
Essa talvez seja uma das partes mais difíceis para quem construiu a carreira sendo reconhecido por resolver problemas complexos.
Imagine que você esteja participando de uma discussão técnica e perceba que alguém está seguindo por um caminho que provavelmente não é o melhor. Você já conhece uma solução mais simples, sabe quais riscos aquela abordagem pode trazer e conseguiria explicar tudo em cinco minutos. A tentação é enorme. Você interrompe, apresenta a solução e economiza meia hora de discussão.
Do ponto de vista da entrega imediata, talvez tenha sido uma excelente decisão. Mas, dependendo do contexto, também pode ter eliminado uma oportunidade importante de aprendizado.
Isso não significa deixar o time cometer qualquer erro apenas para aprender. Existem riscos, prazos e decisões que exigem intervenção direta. O ponto é reconhecer que nem toda situação precisa ser resolvida da maneira mais rápida possível pelo profissional mais experiente. Às vezes vale perguntar:
- “Quais alternativas você considerou?”
- “O que acontece se essa integração falhar?”
- “Como essa decisão afeta a manutenção daqui a seis meses?”
- “Que restrição do negócio estamos tentando atender?”
Essas perguntas ajudam a pessoa a desenvolver critérios de decisão, em vez de apenas memorizar a solução que alguém apresentou. E existe uma diferença enorme entre ensinar alguém a reproduzir uma resposta e ajudá-lo a construir o raciocínio necessário para encontrar boas respostas em situações diferentes.
Feedback transforma experiência em aprendizado
Dar uma oportunidade não garante que alguém vai aprender com ela. Uma pessoa pode conduzir uma reunião, participar de uma decisão importante ou implementar uma solução complexa e sair daquela experiência sem entender muito bem o que fez de maneira positiva e o que poderia melhorar. É aí que o acompanhamento faz diferença.
Imagine que um desenvolvedor tenha conduzido uma apresentação técnica. A reunião aconteceu, a solução foi aprovada e todo mundo voltou ao trabalho. Poderíamos simplesmente considerar a experiência concluída. Mas talvez valha uma conversa depois.
O que funcionou bem? A explicação estava clara? As alternativas foram apresentadas? A pessoa conseguiu responder aos questionamentos? Em algum momento a discussão perdeu o foco? Como ela se sentiu conduzindo aquela apresentação? O feedback ajuda a transformar a experiência em aprendizado consciente.
Também é importante reconhecer aquilo que deu certo. Desenvolvimento não consiste apenas em identificar deficiências. Muitas vezes, ajudar alguém a perceber suas próprias competências é o que permite que essa pessoa assuma responsabilidades maiores.
E o feedback não precisa acontecer apenas depois de uma falha. Ele pode ser uma ferramenta contínua para fortalecer comportamentos positivos, ajustar expectativas e orientar a evolução profissional.
Um PDI não deveria ser uma lista de cursos
Quando falamos em desenvolvimento profissional dentro das empresas, inevitavelmente aparece o Plano de Desenvolvimento Individual, o famoso PDI.
Na teoria, ele deveria ajudar a organizar objetivos de crescimento, competências a desenvolver, ações práticas e formas de acompanhar a evolução. Na prática, às vezes acaba virando uma lista de cursos que a pessoa precisa concluir até determinada data.
O problema é que concluir uma atividade não significa necessariamente desenvolver a competência desejada.
Imagine um PDI com o objetivo “melhorar comunicação técnica”. Se a única ação for “concluir um curso de comunicação”, como saberemos se houve evolução?
Podemos pensar em algo mais concreto. A pessoa pode estudar técnicas de apresentação, conduzir uma discussão técnica, preparar uma proposta de arquitetura, receber feedback sobre sua comunicação e repetir a experiência em outra oportunidade. Agora temos um objetivo relacionado a comportamentos observáveis e oportunidades reais de prática.
A lógica dos objetivos SMART também pode ajudar a organizar esse processo, tornando as metas específicas, mensuráveis, alcançáveis, relevantes e delimitadas no tempo. Mas precisamos tomar cuidado para não transformar desenvolvimento em uma coleção de indicadores que existem apenas para preencher uma ferramenta de RH.
Nem tudo que importa no crescimento profissional pode ser reduzido facilmente a um número. O PDI deveria ajudar a orientar conversas e decisões, não substituir essas conversas. E, principalmente, não deveria ser um documento criado em janeiro para ser redescoberto durante a avaliação de desempenho em dezembro.
Desenvolvimento precisa fazer sentido para a pessoa
Existe outro detalhe que às vezes esquecemos: nem todo desenvolvedor quer seguir o mesmo caminho. Algumas pessoas querem aprofundar conhecimentos técnicos e se tornar especialistas em determinada área. Outras querem ampliar sua atuação, participar de decisões arquiteturais, desenvolver habilidades de liderança ou assumir responsabilidades relacionadas a produto e negócio.
Também existem momentos diferentes na carreira. Uma pessoa pode estar buscando desafios maiores, enquanto outra precisa consolidar conhecimentos ou encontrar mais equilíbrio na rotina.
Não faz muito sentido construir um plano de desenvolvimento olhando apenas para aquilo que a empresa precisa naquele momento, sem considerar os interesses e objetivos do profissional. É claro que desenvolvimento dentro de uma organização precisa ter alguma conexão com as necessidades do negócio. Mas, quando existe alinhamento entre oportunidades reais e interesses individuais, fica muito mais fácil construir um processo que faça sentido para ambos.
E aqui voltamos ao artigo anterior sobre 1:1. É difícil ajudar alguém a crescer profissionalmente se você não conhece seus objetivos, suas dificuldades, suas expectativas e aquilo que essa pessoa considera importante para a própria carreira.
As conversas individuais criam espaço para descobrir isso. O acompanhamento transforma essas descobertas em oportunidades concretas.
O crescimento de alguém também é uma entrega da liderança
Durante boa parte da carreira como desenvolvedor, é natural medir nosso impacto pelas soluções que conseguimos construir, pelos problemas que resolvemos e pela qualidade do código que entregamos. Quando começamos a liderar, essa perspectiva precisa se ampliar.
Talvez uma das entregas mais importantes de um Tech Lead seja ajudar alguém que antes dependia de orientação constante a conseguir tomar boas decisões com autonomia. Ou acompanhar uma pessoa que tinha dificuldade para se comunicar até que ela consiga defender suas ideias com segurança. Ou criar condições para que um desenvolvedor assuma responsabilidades que antes pareciam distantes da sua capacidade.
Esses resultados não aparecem necessariamente em um pull request. Não são tão fáceis de medir quanto uma funcionalidade entregue ou um incidente resolvido. Mas influenciam diretamente a capacidade do time de continuar evoluindo.
E existe algo interessante nisso: quando você desenvolve alguém, o benefício não fica restrito àquela pessoa. O time passa a contar com mais conhecimento, mais autonomia e mais gente capaz de contribuir para decisões importantes.
No fim das contas, desenvolver pessoas não significa ter todas as respostas sobre a carreira delas, escolher os cursos que precisam fazer ou definir sozinho quais competências devem adquirir. Significa entender onde estão, descobrir aonde querem chegar e ajudar a construir oportunidades reais para que avancem nessa direção.
Cursos continuam sendo importantes. Livros, treinamentos e certificações também. Mas talvez o melhor investimento que um Tech Lead possa fazer no desenvolvimento de alguém não seja simplesmente indicar o próximo conteúdo para estudar.
Talvez seja oferecer a oportunidade de fazer algo que essa pessoa ainda não consegue fazer sozinha, com o contexto, o acompanhamento e a confiança necessários para que um dia consiga.
