Existe uma transição na carreira de desenvolvimento que considero particularmente difícil: o momento em que aquilo que fez você crescer como profissional começa a não ser suficiente para o papel que você passou a ocupar.
Durante boa parte da nossa carreira, somos reconhecidos principalmente pela capacidade técnica. Aprendemos uma tecnologia nova, resolvemos um problema complexo, encontramos a causa daquele bug que ninguém conseguia reproduzir, melhoramos uma arquitetura ou nos tornamos aquela pessoa que o restante do time procura quando alguma coisa fica complicada. Naturalmente, quanto mais desenvolvemos essa capacidade, maior tende a ser nossa influência dentro do time.
O problema é que, em algum momento, podemos começar a confundir essa influência técnica com liderança. Ser uma referência técnica é importante para um Tech Lead, claro, mas liderar exige uma mudança de perspectiva que vai muito além de saber mais ou programar melhor. A pergunta deixa de ser apenas “como eu resolvo esse problema?” e passa a ser também “como faço o time ser capaz de resolver problemas como esse?”
Parece uma diferença pequena, mas ela muda bastante a forma como enxergamos nosso próprio trabalho.
De resolver problemas para desenvolver capacidade
Imagine uma situação bastante comum. Um desenvolvedor precisa tomar uma decisão importante e procura o Tech Lead. Como o líder conhece bem o sistema e provavelmente já enfrentou algo parecido, ele analisa rapidamente o cenário, apresenta uma solução e o trabalho continua. Até aqui, tudo certo.
O problema aparece quando isso começa a se repetir. Sempre que surge uma decisão mais difícil, alguém chama o Tech Lead. Sempre que existe uma dúvida de arquitetura, alguém chama o Tech Lead. Quando acontece um incidente, quando um PR é mais complexo ou quando ninguém sabe exatamente qual caminho seguir, a resposta também é chamar o Tech Lead.
Individualmente, cada uma dessas situações parece demonstrar eficiência. Existe alguém experiente conseguindo destravar o time rapidamente. Quando olhamos para o funcionamento da equipe como um todo, porém, começamos a perceber outra coisa: o time está aprendendo a depender daquela pessoa para funcionar.
Essa é uma armadilha complicada justamente porque parece competência. Quanto mais problemas você resolve, mais importante parece ser para o time. Só que ser indispensável não deveria ser o objetivo de uma liderança. Na verdade, gosto de pensar quase no sentido contrário: quanto melhor você lidera, menos o time deveria depender de você para conseguir avançar.
Isso não significa se afastar, deixar as pessoas se virarem ou simplesmente distribuir responsabilidades. Significa usar sua experiência para criar condições para que outras pessoas também desenvolvam conhecimento, contexto e capacidade de decisão.
O código continua importante. O escopo é que aumentou.
Quando falamos dessa mudança, também é fácil cair no extremo oposto e imaginar que o Tech Lead deveria parar de programar e passar o dia inteiro em reuniões. Não é essa a ideia.
A capacidade técnica continua sendo uma parte importante do papel. É ela que permite discutir arquitetura, avaliar riscos, orientar decisões, revisar soluções e entender as dificuldades que o time encontra no dia a dia. O que muda é que código deixa de ser a única ferramenta disponível para gerar resultado.
Uma forma que gosto de usar para visualizar esse novo escopo é pensar em três dimensões: Pessoas, Processos e Produtos.
Quando falamos de Pessoas, entram questões como desenvolvimento profissional, feedback, competências, conflitos e autonomia. Se um desenvolvedor ainda não possui segurança para participar de uma decisão arquitetural, por exemplo, identificar essa dificuldade é apenas o começo. A liderança precisa pensar em como criar oportunidades para que essa pessoa desenvolva a competência que está faltando.
Em Processos, começamos a olhar para priorização, planejamento, qualidade, acompanhamento, revisões e para a própria forma como o time trabalha. Não basta saber se uma tarefa foi entregue. Também é importante perceber se o processo está ajudando a equipe ou criando dificuldades desnecessárias, se o conhecimento está circulando e se determinadas rotinas realmente fazem sentido.
E existe Produto, que às vezes acaba ficando em segundo plano quando estamos muito concentrados na tecnologia. Liderança técnica também envolve compreender o negócio, conversar com stakeholders, avaliar riscos e entender por que determinada decisão técnica faz sentido naquele contexto. Afinal, uma solução tecnicamente interessante que não resolve o problema certo continua sendo uma solução ruim.
Quando começamos a olhar para essas três dimensões, fica mais fácil entender por que definir Tech Lead simplesmente como “o programador mais experiente do time” é tão limitado.
Quando a senioridade começa a criar gargalos
Talvez uma das partes mais difíceis dessa transição seja perceber que alguns comportamentos que demonstravam senioridade antes podem começar a gerar problemas depois.
Se você era responsável principalmente pela própria entrega, resolver um problema rapidamente quase sempre era positivo. Como líder, resolver pessoalmente todos os problemas pode impedir que outras pessoas aprendam a resolvê-los. Da mesma forma, tomar uma decisão difícil pode ser necessário, mas tomar todas as decisões cria dependência. Revisar código ajuda a manter qualidade, mas ser a única pessoa capaz de aprovar mudanças importantes concentra conhecimento e transforma você em um gargalo.
A questão não é simplesmente parar de fazer essas coisas. Um Tech Lead ainda vai resolver problemas, tomar decisões e revisar código. A diferença está em perceber quando sua participação aumenta a capacidade do time e quando ela apenas reforça a dependência em você.
É justamente nesse ponto que começam a aparecer competências de liderança que normalmente não aprendemos estudando programação. Delegação é uma delas, e gosto bastante de uma ideia do Management 3.0 chamada Delegation Poker porque ela evita tratar delegação como uma escolha entre dois extremos: ou eu decido ou entrego completamente a decisão para outra pessoa.
O modelo trabalha com sete níveis de delegação: Dizer, Vender, Consultar, Concordar, Aconselhar, Indagar e Delegar. A ideia por trás disso é interessante porque mostra que autonomia pode ser construída aos poucos e que decisões diferentes podem exigir níveis diferentes de participação da liderança.
Uma decisão crítica relacionada à segurança do sistema, por exemplo, pode exigir uma participação muito maior do Tech Lead. A escolha de uma biblioteca pode ser discutida com o time. Já uma decisão sobre a organização interna de um componente talvez possa ficar completamente com quem está trabalhando nele. Não existe um único nível de autonomia adequado para qualquer situação.
Por isso, delegar bem não significa simplesmente abrir mão do controle. Significa entender quanto controle aquela decisão realmente precisa ter e quem já possui contexto e competência para tomá-la.
Autonomia não significa deixar o time sozinho
Essa discussão sobre delegação também leva a outro conceito que considero importante: autonomia não é ausência de liderança.
Um time consegue tomar boas decisões quando possui contexto suficiente para isso. As pessoas precisam entender os objetivos, as restrições, as prioridades, os critérios de qualidade e os possíveis impactos das escolhas que estão fazendo. Sem essas informações, delegar uma decisão pode acabar sendo apenas uma maneira elegante de transferir responsabilidade.
Por isso, prefiro pensar no trabalho do Tech Lead não apenas como alguém que toma boas decisões pelo time, mas como alguém que melhora progressivamente a capacidade do próprio time de tomar boas decisões.
Na prática, isso pode acontecer de várias formas. Em algumas situações você vai ensinar algo diretamente; em outras, vai fazer perguntas para ajudar alguém a chegar à própria conclusão. Pode colocar duas pessoas para trabalhar juntas, incentivar uma discussão de arquitetura, documentar um conhecimento que estava concentrado, dar feedback ou simplesmente resistir à vontade de apresentar imediatamente uma solução quando alguém chega com um problema.
Esse último ponto é especialmente difícil para quem construiu boa parte da carreira sendo justamente a pessoa que resolve problemas. Às vezes você já sabe a resposta e poderia encerrar aquela discussão em cinco minutos. Só que resolver o problema mais rápido nem sempre significa desenvolver o time melhor.
O objetivo também não é construir uma equipe que nunca precise da liderança. Isso seria pouco realista. O que queremos é um time que não precise do líder para tudo.
Então, o que significa liderar tecnicamente?
Para mim, essa é uma maneira mais interessante de enxergar a transição para Tech Lead. Você não deixa de ser desenvolvedor quando começa a liderar e também não precisa abandonar arquitetura, código ou decisões técnicas. O que muda é a forma como você passa a observar a própria contribuição.
Antes, boa parte do seu impacto podia ser percebida diretamente naquilo que você produzia. Conforme assume responsabilidades de liderança, uma parcela cada vez maior desse impacto aparece naquilo que o time consegue produzir, decidir e aprender.
Seu código continua importando, mas também importam as pessoas que você ajudou a desenvolver, o conhecimento que deixou de ficar concentrado, as decisões que o time aprendeu a tomar, os processos que foram melhorados e os problemas que deixaram de depender exclusivamente de você.
Talvez seja justamente essa uma das principais diferenças entre ser a referência técnica de um time e realmente exercer liderança técnica. O objetivo deixa de ser apenas demonstrar o quanto você consegue resolver e passa a incluir aumentar o que o time inteiro consegue resolver sem depender de você.
