Em algum momento da carreira, é comum você se tornar aquela pessoa que o time procura quando alguma coisa fica complicada. Você conhece bem o sistema, já viu alguns problemas parecidos, consegue discutir arquitetura, encontra bugs difíceis e normalmente tem uma opinião quando alguém pergunta qual caminho seguir.
Ser reconhecido dessa forma é uma conquista. Significa que as pessoas confiam no seu conhecimento e na sua experiência. O problema é que existe uma diferença importante entre ser uma referência técnica dentro de um time e liderar tecnicamente esse time.
Quando você assume uma posição de liderança, não deixa de ser técnico. Você ainda vai programar, discutir arquitetura, revisar código e participar da solução de problemas. O que muda é que seu trabalho começa a ter uma dimensão que antes talvez não existisse: seu resultado deixa de depender apenas daquilo que você consegue fazer e passa a depender também daquilo que consegue fazer o time fazer. E essa mudança aparece em várias situações aparentemente simples do dia a dia.
Você não precisa mais ter todas as respostas
Imagine que alguém do time chega até você com um problema técnico. Você olha o código, entende rapidamente o que está acontecendo e já sabe como resolver. Qual é o caminho mais eficiente? Provavelmente explicar a solução.
Em cinco minutos o desenvolvedor volta para a tarefa e todo mundo segue trabalhando. Parece ótimo, principalmente quando existe pressão por entrega. Só que, se toda vez que essa pessoa encontrar um problema você entregar a resposta, existe uma boa chance de ela aprender outra coisa além da solução técnica: quando eu não souber o que fazer, procuro o Tech Lead.
Esse comportamento pode acabar se espalhando pelo time. Aos poucos, dúvidas de implementação, decisões arquiteturais e problemas mais complexos começam a convergir para a mesma pessoa.
É aí que uma habilidade que foi extremamente útil para você chegar até a liderança pode começar a trabalhar contra você. Como referência técnica, saber a resposta é valioso. Como líder, você precisa desenvolver a sensibilidade para perceber quando deve dar a resposta e quando deve ajudar alguém a encontrá-la.
Às vezes isso significa responder uma pergunta com outra: “O que você já tentou?”, “Quais alternativas você encontrou?”, “Qual o impacto dessa decisão?”, “O que faria você escolher a opção A em vez da B?”.
Isso certamente pode levar mais tempo do que simplesmente dizer o que fazer. Só que existe uma diferença importante entre resolver uma tarefa e desenvolver alguém capaz de resolver as próximas tarefas.
Sua entrega também muda
Essa mudança pode ser particularmente estranha para quem passou anos medindo o próprio trabalho pelo que produziu. É fácil olhar para um dia cheio de código e sentir que ele foi produtivo. Você implementou uma feature, resolveu um bug, abriu alguns PRs e terminou o dia com algo bastante concreto para mostrar.
Na liderança, nem sempre funciona assim. Talvez você passe uma hora ajudando alguém a organizar uma decisão técnica. Depois converse com outra pessoa que está tendo dificuldade em uma tarefa. Em seguida, alinhe com Produto uma prioridade que estava confusa, revise uma proposta de arquitetura e perceba que duas pessoas do time estão trabalhando em soluções parecidas sem saber uma da outra.
No final do dia você pode ter escrito pouquíssimas linhas de código e, ainda assim, ter produzido um impacto enorme no trabalho da equipe.
Isso não significa que reuniões sejam automaticamente trabalho de liderança ou que deixar de programar seja sinal de evolução. Significa apenas que a sua unidade de contribuição aumentou. Você continua tendo suas próprias entregas, mas passa a criar condições para que outras pessoas também consigam entregar melhor.
Você deixa de decidir apenas “o quê” e começa a decidir “quem”
Existe outra mudança que considero especialmente interessante: antes, grande parte do desafio estava em tomar uma boa decisão técnica. Conforme você começa a liderar, surge uma segunda pergunta tão importante quanto: Eu deveria tomar essa decisão?
Parece estranho no começo. Se você possui mais experiência sobre determinado assunto, por que não decidir logo? Porque eficiência imediata e desenvolvimento do time nem sempre apontam para o mesmo caminho.
Se todas as decisões arquiteturais precisam passar pelo Tech Lead, provavelmente teremos consistência. Também podemos criar um gargalo. Se qualquer decisão for completamente delegada, ganhamos autonomia, mas talvez coloquemos nas mãos de alguém uma responsabilidade para a qual ainda não existe contexto ou experiência suficiente.
Por isso, delegação não deveria ser tratada simplesmente como “eu decido” ou “você decide”. O Delegation Poker, uma prática do Management 3.0 que quero explorar com mais profundidade em outro artigo, trabalha justamente com diferentes níveis de delegação. Existem situações em que o líder decide, outras em que consulta o time, algumas em que a decisão é compartilhada e outras em que a responsabilidade pode ficar completamente com a equipe.
A parte interessante dessa ideia não está apenas no framework. Está em perceber que liderar também significa escolher conscientemente onde uma decisão deve acontecer.
Autonomia precisa de contexto
Só que existe um detalhe importante nessa história: não adianta reclamar que o time depende demais de você e, de repente, começar a responder tudo com “vocês que sabem”.
Isso não é autonomia. Para alguém tomar uma boa decisão, precisa entender o contexto daquela decisão. Qual problema estamos tentando resolver? O que é prioridade agora? Quais restrições existem? Quanto risco podemos assumir? Existe alguma decisão anterior que precisamos respeitar? O prazo importa mais do que uma solução arquitetural perfeita nesse momento?
Quando essas informações estão concentradas na liderança, é natural que as decisões também fiquem concentradas nela. Por isso, uma parte importante do trabalho começa a ser distribuir contexto, e não apenas distribuir tarefas.
Quanto mais as pessoas entendem o produto, as restrições técnicas, os objetivos e os motivos por trás das decisões anteriores, melhores tendem a ser as decisões que conseguem tomar sem precisar consultar alguém o tempo inteiro.
Isso também muda a forma como enxergamos comunicação. Documentar uma decisão arquitetural, explicar por que uma prioridade mudou ou compartilhar uma conversa relevante com Produto pode parecer menos importante do que implementar uma feature. Na prática, essas ações podem evitar dezenas de decisões ruins depois.
E então aparecem as pessoas
Talvez essa seja a parte para a qual a carreira técnica menos nos prepara. Código costuma ser relativamente previsível. Quando existe um problema, investigamos, levantamos hipóteses, testamos e tentamos encontrar uma solução. Pessoas não funcionam exatamente assim.
Duas pessoas com o mesmo nível técnico podem precisar de formas completamente diferentes de acompanhamento. Uma pode ter conhecimento suficiente para trabalhar com bastante autonomia, enquanto outra pode precisar discutir decisões com mais frequência. Alguém pode ter excelente capacidade técnica e dificuldade para comunicar suas ideias. Outra pessoa pode participar pouco das discussões não porque não saiba o que dizer, mas porque não se sente confortável naquele ambiente.
A liderança começa então a envolver coisas que dificilmente aparecem em uma documentação de framework: feedback, expectativas, conflitos, motivação, desenvolvimento profissional, comunicação e confiança. E talvez seja justamente aqui que fique mais evidente por que ser o melhor programador do time não garante que você será um bom Tech Lead.
O conhecimento técnico continua sendo fundamental, mas agora você precisa aprender também a desenvolver pessoas que possuem experiências, objetivos, dificuldades e formas de trabalhar diferentes das suas.
Seu impacto começa a aparecer no trabalho dos outros
No artigo anterior eu falei sobre uma ideia que quero carregar durante toda essa série: quanto melhor você lidera, menos o time deveria depender de você para conseguir funcionar.
Não significa que o Tech Lead precise se tornar dispensável ou desaparecer das decisões importantes. Significa que uma liderança saudável deveria aumentar a capacidade coletiva do time em vez de concentrá-la em uma única pessoa. Talvez esse seja um jeito interessante de observar se essa transição realmente está acontecendo.
Se você sair de férias por duas semanas, o time consegue tomar decisões? As pessoas sabem onde encontrar informações importantes? Alguém além de você consegue conduzir uma discussão técnica? Os desenvolvedores entendem o contexto do produto ou apenas recebem tarefas? Existem outras pessoas capazes de revisar uma solução importante?
Essas perguntas dizem bastante sobre liderança porque deslocam nossa atenção do indivíduo para o sistema que construímos ao redor dele.
No começo da carreira, nosso impacto aparece principalmente no código que escrevemos e nos problemas que conseguimos resolver. Conforme assumimos responsabilidades de liderança, parte desse impacto começa a aparecer de outras formas: nas pessoas que ganharam autonomia, no conhecimento que passou a circular, nas decisões que não precisaram chegar até você e na capacidade que o time desenvolveu de resolver problemas cada vez mais complexos.
Você continua sendo técnico. Continua estudando, programando, discutindo arquitetura e tomando decisões difíceis. A diferença é que agora seu trabalho não termina mais em você. E talvez essa seja uma das maiores mudanças entre ser uma referência técnica e realmente começar a liderar.
