[VIDEO] De dev a Tech Lead: o que você precisa saber

Eduardo Matos começou a trabalhar como desenvolvedor em um trajetória bastante semelhante a muitos outros devs: incentivado por um amigo, começou a “fazer site” quando ainda cursava a graduação em Física na UERJ, lá pelo fim dos anos 2000. Tomou gosto pela programação ao resolver aqueles problemas “que ninguém conseguia resolver”.

Autodidata, foi fundo no aprendizado de back-end e da linguagem PHP a partir de tutoriais na internet. Pouco mais de uma década depois, decidiu migrar para a área de gestão em tecnologia, e atualmente é Engineering Manager na SumUp.

Em um bate-papo com Rodrigo Alencar no CTO Talks, Eduardo conta como foi sua transição na jornada de dev para líder técnico. Neste artigo, pontuamos os principais tópicos dessa conversa.

Quais são as responsabilidades de um Tech Lead?

Um profissional na posição de liderança técnica tem como responsabilidade garantir o sucesso técnico da equipe. Mas, o que é preciso fazer para a equipe chegar lá? Bom, isso pode variar a depender não apenas de cada contexto, como também da capacidade da equipe e até das habilidades do líder em questão.

E existem diversas formas desse sucesso acontecer. Por exemplo: pode começar a partir da reflexão se a intenção é chegar lá com uma boa qualidade, desempenho adequado, ou mesmo uma tecnologia adequada para alcançar o objetivo final. Neste ponto, Eduardo faz uma ressalva importante. “Eu gosto de frisar a palavra ‘adequado’ porque às vezes a gente, como líder técnico, ou mesmo como desenvolvedor, costuma ser muito detalhista ou talvez muito preciosista em relação às soluções, então a gente faz uma coisa que vai muito além do que é realmente necessário para alcançar o objetivo”.

O ponto que ele levanta é importante porque essa prerrogativa pode atrasar de duas a três semanas (com otimismo) a entrega de um projeto que poderia ter sido entregue bem mais cedo. Sendo assim, entender o que é bom o suficiente para resolver um problema é essencial. Para Eduardo, quem está na liderança técnica tem que ser essa pessoa que é mais pragmática nas escolhas que pretende fazer. Ou seja: é pensar mais na resolução do problema sob a ótica do usuário e da empresa, e do resultado que será gerado, para só depois pensar na tecnologia que será usada para embasar a entrega que precisa ser feita.

Essa linha de pensamento diverge do clássico caso (quem nunca) de se construir uma “tecnologia incrível”, capaz resolver todos os problemas, porém quando chega na ponta… mmm, não era bem o que o cliente precisava, ou (tanto pior) não vai gerar receita para a empresa. “Por conta disso, uma pessoa que está na posição de liderança técnica precisa ter uma boa visão de negócios para entender como guiar as soluções técnicas que vai trazer para sua equipe”, aponta ele.

Outro ponto importante é a questão da ambiguidade: não existem respostas certas para todas as situações, ou mesmo aquela “resposta certa para tudo” (alguém pensou na famigerada “bala de prata da TI”?). A conclusão é clara e de certa forma casa com o conceito de Agile development: “a gente vai ter muitos trade-offs no processo, então talvez a gente acabe criando uma solução que tem um desempenho menor inicialmente, mas que vai resolver em parte um problema, e depois a gente decide resolver esse problema de desempenho”, explica ele.

“Ou então, talvez a gente entregue um negócio (sic) com uma qualidade mais ou menos no começo, para tentar resolver um problema para uma parte dos clientes, e depois a gente melhora essa qualidade, ou será que faz mais sentido entregar com mais qualidade agora e resolver para todo mundo ao mesmo tempo”? É uma questão. Ou melhor, questões que fazem parte dos desafios de quem está na posição de Tech Lead.

Soft skills x Hard skills

Algumas dicas sobre hard skills para líderes técnicos: na visão de Eduardo, é importante a pessoa conhecer bem algumas linguagens de programação, de preferência com alguns paradigmas diferentes. Por exemplo, como funciona uma linguagem mais funcional e outra mais voltada para orientação a objetos. Também deve saber desenhar soluções, arquiteturas e sistemas capazes de resolver problemas.

“Por exemplo: vamos dizer que eu vou criar tipo um Google Drive na empresa, ou algo semelhante a isso. Como começar a criar essa solução? Então precisa entender sobre diferentes componentes ali, como usar cada tipo de componente, cada tipo de banco de dados - não que você tenha que conhecer todos os bancos de dados a fundo, a ideia não é essa. A ideia é entender mais ou menos qual problema cada um deles se dispõe a resolver. Como você faz para escalar uma parte do sistema que vai precisar processar uma carga maior, esse tipo de coisa”, explica ele.

A parte de soft skills também é tão ou mais importante para um dev que a de hard skills. Por se tratar de algo mais individual e que depende muito de cada perfil, e também das dificuldades (ou mesmo facilidades) que cada pessoa tem, há um “universo” de possibilidades aqui, por assim dizer. Eduardo até já escreveu um livro onde detalha mais a respeito. Para facilitar o entendimento, ele divide as soft skills em 3 grandes partes:

1) Mentalidade de cada um: Como você enxerga as coisas ao seu redor? Por exemplo: você pode enxergar o problema de uma forma “ruim”, que é basicamente quando referencia um problema a alguém, sem interesse genuíno de resolvê-lo, ou mesmo tendo uma atitude negativa com relação ao problema. Esse é um lado da moeda, e claro, diz respeito a um tipo de mentalidade. O outro lado da moeda, como você pode supor, é o de adotar uma atitude mais positiva, de parar e entender o que aconteceu, e mesmo envolver alguém que possa ajudar a resolver a questão.

2) Entregas: No fim das contas, trabalhamos para conseguir fazer boas entregas e gerar dinheiro para a empresa, certo? Pense em entrega como um “guarda-chuva” para soft skills, porque é ela que vai fazer a diferença lá na ponta se somos considerados bons profissionais ou não. Por exemplo: um profissional pode ser muito bom no lido com pessoas, mas se não sabe usar isso para ajudar as entregas a saírem cada vez melhores, talvez isso não tenha tanta serventia.

3) Relacionamentos: Quando falamos em relacionamentos, é com todo mundo que está à nossa volta: liderados, pares, superiores, Product Manager, designer… aqui é chover no molhado, mas a ideia é buscar manter sempre um bom relacionamento com as pessoas, porque é através desse relacionamento que será possível se organizar e conversar para entender o que é uma boa entrega ali na ponta. Se o relacionamento não for bom, possivelmente o trabalho em equipe não vai funcionar tão bem.

Como começar a liderar um time tech?

Como a gente começa a liderar? Normalmente, isso acontece de repente. E a pessoa pensa: e agora, o que eu faço? A sugestão de Eduardo para quem está fazendo essa virada profissional é: comece olhando para a tecnologia. Porque, em primeiro lugar, é mais fácil, já que o profissional tem mais experiência ali, logo consegue ajudar mais a equipe. Ao longo do tempo, procure se desenvolver em outras habilidades.

Naturalmente, o profissional também tenderá a micro gerenciar muito sua equipe, porque é o que ela sabe fazer. Então ela vai desejar ir bem nos detalhes, e esse não é um caminho ruim. Se os membros do time conseguem fazer o trabalho perfeitamente, não será necessário ficar tão próximo para dizer o que precisa ser feito; agora, se existem pessoas com perfil mais junior na equipe, que talvez não saibam trabalhar tão bem quanto é preciso naquele momento, vai ser fundamental micro gerenciar para ajudar essa pessoa a entender o que é um nível bom de qualidade, o que é um nível bom de desempenho da aplicação, o que é um bom nível de documentação. E claro, quem está na liderança está no papel de se aproximar e mostrar como as coisas devem funcionar.

“Eu chamo isso de microgestão. E vai acontecer durante um tempo, é natural e esperado que aconteça, mas quem está fazendo a microgestão deve entender que isso é temporário. Deve acontecer até o momento de desenvolver as pessoas para que elas sejam capazes de fazer aquilo que você não precisa mais estar tão próximo para que elas façam. Mas o nível de qualidade que existia até quando você estava na equipe precisa se manter quando você começar a se afastar aos pouquinhos conforme a pessoa vai se desenvolvendo em outras habilidades”, explica ele.

E quando a equipe é mais sênior?

Eduardo acredita que 99% do trabalho pode ser delegado. E ele diz isso por acreditar que, quem é líder de uma equipe, deveria, até certo ponto, estar trabalhando para não ser mais necessário nessa equipe. E como isso é feito? Ao longo do tempo, surgirá alguém na equipe que terá o desejo de se tornar líder também, então a ideia é basicamente que alguém na equipe consiga se desenvolver para se tornar líder um dia.

E até o ponto em que a pessoa que está se desenvolvendo possa se tornar também líder de equipe - enquanto você assume uma outra equipe, ou talvez seja promovido para outro cargo - 99% do trabalho pode ser delegado. Na visão dele, apenas algumas atividades não devem ser delegadas, a menos que essa outra pessoa vire líder na equipe. E quais atividades são essas?

1) Contratação: Você não pode simplesmente delegar 100% a contratação, já que essa é uma função diretamente associada ao líder de equipe, portanto é o líder quem deve dar a palavra final sobre quem vai ser contratado ou não.  

2) Demissão: Essa é uma decisão bem crítica e bem difícil de tomar, então também deve ser atribuída diretamente ao líder de equipe.

3) Os chamados “1:1s”: Quem é líder de equipe precisa ter conversas recorrentes com as pessoas que compõem a equipe. Ele precisa entender como as pessoas estão se sentindo, como elas estão fazendo as entregas, o que elas enxergam da equipe, da empresa, o que elas pensam.

A mensagem final do Eduardo Matos para quem está começando como Tech Lead ou deseja fazer uma transição de carreira para um cargo de liderança técnica, é: “entenda o jogo que você está jogando, e se desenvolva em soft skills”. Afinal, a responsabilidade da carreira de qualquer profissional só depende do próprio profissional.

No vídeo abaixo você confere o bate-papo com Eduardo Matos, Engineering Manager na SumUp para o canal da Revelo Community no YouTube:

Indicações de livros:

“De Dev a Tech Lead” - Habilidades essenciais para impulsionar a sua carreira - Conta como é essa trajetória de dev para Tech Lead conforme os aprendizados do autor nessa jornada.

“Implementando o desenvolvimento Lean de software” – Livro sobre processos mas com uma “pegada” bastante técnica sobre implementação Lean na área tech.