As 4 dimensões da Liderança em Tecnologia

Ser um Tech Lead é ser a melhor pessoa tecnicamente da equipe, certo? 🤔
Não necessariamente!

Esse é um erro muito comum que jovens líderes e aspirantes a Tech Lead cometem: Achar que ser líder na área de Tecnologia tem a ver somente com Tecnologia.

Entender o seu papel de líder é o primeiro passo para entregar melhores resultados, ser melhor avaliado e crescer na carreira. 📈

É comum acharmos que o próximo passo na carreira tem a ver com fazer mais ou fazer melhor aquilo que já fazemos hoje. Até um certo estágio isso pode ser uma verdade, já que é esperado que um Engenheiro de Software foque quase que 100% do seu esforço em criar sistemas que tenham bom desempenho, qualidade, segurança etc.

Mas, especialmente na transição para Tech Lead, as expectativas são bastante diferentes.

As 4 Dimensões

Liderança na área de Tecnologia é apoiada em quatro dimensões:

1. Tecnologia
2. Pessoas
3. Negócio
4. Processos

Ser bom em Tecnologia garante que a equipe vai mandar bem em uma das dimensões. Focar somente em tecnologia abre espaço para que os pratinhos das outras três caiam, o que pode ter consequências péssimas para a equipe.

Eu quero deixar bem claro que o fato de existirem quatro dimensões não significa que a pessoa pode ser ruim tecnicamente e mesmo assim atuar como líder. Muito pelo contrário! A barra para uma liderança é alta em todas as dimensões, em especial na de Tecnologia, uma vez que, se a equipe não é capaz de solucionar os problemas de negócio, essa liderança seria praticamente inútil para a equipe.

Em outras palavras, caso você esteja se perguntando se é importante ser bom tecnicamente para assumir a posição de Tech Lead, a resposta é SIM. Isso não significa que a pessoa precisa ser a mais técnica da equipe, mas ela precisa ser boa o suficiente (o que já não é simples).

Deixa eu te contar sobre cada uma dessas dimensões, começando por Tecnologia:

💻 Tecnologia

É importante mencionar logo no começo que a função da Tecnologia é gerar valor para o negócio. Só isso. Tendo isso em mente, a forma de escolher uma linguagem de programação, arquitetura, paradigma, ferramentas e outras tecnologias deve se ater a responder à seguinte pergunta: Como podemos entregar a solução para o negócio com o menor custo, maior qualidade e o mais rápido possível?

Um técnico pode pensar de diferentes formas:

Vou escrever o código do jeito mais rápido de chegar lá.
Vou fazer uma arquitetura de microsserviços para escalar mais fácil.
Vou adicionar 100% de cobertura de testes pra garantir que não teremos bugs.

Eu poderia listar algumas dezenas de pensamentos comuns, mas decidi me limitar a estes três.Nenhum destes três pensamentos está necessariamente certo nem errado. É importante analisar o contexto e avaliar os trade-offs de cada alternativa para se chegar a alguma conclusão.

Por exemplo: Se o projeto está com um bug crítico em produção, então é aceitável escrever o código o mais rápido possível. Por outro lado, trabalhar o tempo inteiro dessa maneira seria problemático.

Outro exemplo: Se está difícil que diversos times colaborem em um código monolítico e fica muito caro escalar a aplicação, mover na direção de microsserviços pode ser interessante. De outro modo, fazer microsserviços para tudo pode aumentar a carga cognitiva e tornar o custo de infraestrutura muito maior que o necessário.

Mais um exemplo: Adicionar 100% de cobertura de testes pode fazer sentido em uma parte da aplicação muito crítica, onde qualquer bug traria consequências pesadas demais para o negócio. Por outro lado, adicionar 100% de cobertura de testes em todas as aplicações pode aumentar o tempo de entrega sem necessariamente compensar tanto em qualidade.

A mensagem principal é: Tecnologia é um meio para se alcançar resultado de negócio. Sempre que você puder simplificar a solução para alcançar o mesmo resultado, faça isso. Se para um dado problema você não consegue enxergar trade-offs da sua decisão de como resolvê-lo, então é capaz que você não tenha dedicado tempo o suficiente para pensar em soluções alternativas.

😁 Pessoas

Você é um excelente técnico e os sistemas que seu time mantém são muito bem estruturados. Mas o clima na equipe é muito ruim, o turnover é alto, e as pessoas não têm nenhuma perspectiva de crescimento.

Nesse cenário você diria que está sendo um bom líder? Suponho que não.

São pessoas que constroem todas as entregas do time. Se elas não se sentirem bem no local onde passam grande parte de seu dia, a geração de resultados pode ficar comprometida, a velocidade de entrega pode não ser boa o suficiente e até a qualidade pode sofrer um baque.

É necessário que a liderança se preocupe com cada membro da equipe.

• Como as pessoas têm se sentido?
• O que buscam na carreira?
• Como elas se relacionam com os colegas?
• Onde precisam de ajuda?
• Quais feedbacks você pode dar?

Mesmo que na empresa onde você trabalha não exista a exigência de você fazer a gestão das pessoas, nada impede, por exemplo, que você converse com cada uma delas a cada quinze dias para saber como estão e como você pode contribuir.

Esse pequeno gesto pode ser a diferença entre a pessoa se sentir ouvida/suportada ou se sentir abandonada.

📊 Negócio

Geralmente quando falo que é importante que um líder técnico entenda de negócio, a resposta quase padrão é: Não sou Product Manager!

Na realidade entender do negócio onde atua não tem nada a ver com exercer o papel de Product Manager, mas sim entender quais são os desafios do negócio e como você pode usar Tecnologia para resolvê-los.

Preocupar-se com o negócio leva um Tech Lead a fazer perguntas mais pertinentes e desafiar a pessoa de negócio para que melhores decisões sejam tomadas.

Boas perguntas permitem que as entregas sejam dimensionadas de maneira adequada. O que é melhor, monolito ou microsserviços? Python ou Java? Sempre acessar diretamente o banco de dados ou resgatar dados de um cache? Somente entendendo as necessidades do negócio (e dos usuários) é possível responder a essas e outras perguntas.

Ao mesmo tempo, desafiar o Product Manager ou stakeholder, levantando alternativas às soluções propostas, abre espaço para que melhores decisões sejam tomadas. Talvez o stakeholder peça para seu time desenvolver um sistema de blog, nesse momento você pode sugerir, por exemplo, usar um sistema pronto para isso, o que abrirá espaço para a equipe entregar outra funcionalidade mais rápido. A discussão em torno de cada possibilidade enriquece demais os resultados.

Use seu conhecimento de Tecnologia para ajudar pessoas não técnicas a tomarem melhores decisões. Conheça as necessidades do negócio e dos usuários para você tomar melhores decisões. Isso é ser Tech Lead.

⏩ Processos

Se, por um lado, olhar para o negócio garante que o time está priorizando corretamente, olhar para os processos garante que o time está entregando o mais rápido possível.

Daí você pode se perguntar: Uma vez que o time já sabe o que fazer, não basta escrever código? Em tese sim, mas na prática não é tão simples assim.

Lembre que o pipeline de entrega de software normalmente contempla outras etapas além da codificação, como revisão de código, verificação de qualidade em ambiente de testes etc.

Por mais contraintuitivo que possa parecer, é justamente na passagem de uma etapa para a outra que as tarefas tendem a ficar bloqueadas.

Seu trabalho como líder é justamente garantir que há o mínimo de gargalos possível e que as tarefas “fluam” no board da equipe. Essa gestão é uma tarefa diária que você precisa estar próximo.

Tornar-se bom com processos é um passo para que sua equipe vire uma máquina de entregas. E sim, velocidade de entrega importa.

🤩 O que fazer daqui em diante?

Diversas vezes já ouvi Tech Leaders falando algo nessa linha: “É um absurdo falar que eu devo aprender essas outras coisas. Tecnologia já é difícil o suficiente.”

Em vez de pensar no volume de conhecimento necessário para exercer um dado papel, eu entendo que é mais interessante olhar para meu próprio trabalho através da seguinte pergunta: Como eu posso ser um profissional o mais efetivo possível? Responder a essa pergunta que me fez chegar às quatro dimensões acima.

Vou finalizar te deixando duas perguntas para que você tenha mais clareza de qual o próximo passo que você pode dar.

1. Qual das quatro dimensões acima mais pode contribuir para que seu time seja mais efetivo?
2. Qual das quatro dimensões acima você vê mais potencial nos próximos 6 meses para se desenvolver como profissional?

Um abraço e até a próxima!