Tech + Lead
Rogerio Angeliski
No último ano eu assumi a posição de Tech Lead dentro da RD Station. Nesse artigo eu vou contar algumas coisas que eu aprendi (e outras que eu consolidei) vivendo diariamente nessa função.
Eu não vou entrar em definições desse papel aqui, pois já existem diversas abordagens e explicações a respeito (vou deixar alguns links no final) além de variar entre cada empresa. Meu objetivo nesse texto é trazer algumas provocações para te tornar um Tech Lead melhor, pois essas provocações me ajudaram a crescer ao longo do ano passado.
Você é um líder
Um papel de liderança não é sobre poder, mas sobre responsabilidade. Seu time é sua responsabilidade. Não me entenda mal, no caso de um Tech Lead não estamos falando especificamente de gestão, mas é importante ter clareza de que, em um time onde as pessoas não estão bem, não vai ter habilidade técnica que faça seu time gerar valor para ninguém.
Se você não se enxerga como um líder, vai deixar a desejar nesse quesito, deixar de estudar e crescer como um líder. Não cometa esse erro.
Como destaque eu deixo duas habilidades a serem olhadas com carinho nesse papel: a influência e a delegação.
Essas duas habilidades vão te ser fundamentais para evitar que você tenha que estar presente a todo momento.
Exemplo prático: ao longo desse último ano, eu tive oportunidade de entender mais sobre as habilidades que meu time tinha, e pouco a pouco deixar de resolver as coisas para delegá-las para cada um deles. Em vários casos a resposta mais rápida seria eu ir lá e executar, mas isso ia roubar duas coisas: meu foco em outra atividade e a oportunidade do meu time crescer junto comigo. E se no final, eles não conseguirem resolver, eu estava pronto pra ajudar (não é delargar não viu?)
Liderança pelo exemplo
Eu repito isso praticamente todas as semanas: você precisa liderar pelo exemplo.
As palavras são baratas, qualquer um pode juntar um punhados delas e construir um discurso (se ele vai ser bom é outra história).
Mas o que você faz é o que conta.
Você quer que seu time entregue com mais qualidade? Revise a qualidade com que você está entregando.
Quer que eles escrevam mais testes? Escreva mais testes com eles. Ensine-os como testar melhor.
Aqui eu tenho dois exemplos práticos:
Antes de virar oficialmente o Tech Lead, eu tinha o hábito de mergear alguns PRs sem pedir revisão do restante do time. Como eu poderia cobrar isso do meu time se eu não fizesse?
Então hoje eu simplesmente não faço mais, sem exceções (mas a zueira será eterna com a Paula que odeia que eu faça isso haiahua)
O segundo exemplo tem a ver com documentação. Essa é uma prática pela qual eu tenho muito apreço. Durante o ano, por diversas vezes eu me esforcei por cobrar e executar mais documentações, por revisar as que o time fez, dar feedback, elogiar, estar presente nesse assunto. Isso inclusive levou nosso time a ter um Tech Writer.
Se eu puder resumir: não seja um hipócrita
Multiplicação de valor
A senioridade na minha carreira veio com um plot twist com o qual eu não contava: meus líderes não esperavam que minhas entregas fossem apenas relacionadas a escrever código.
E isso sem dúvida nenhuma cresceu ainda mais agora que eu estou no papel de um Tech Lead. A execução não é onde eu posso gerar mais valor.
Não estou dizendo que você precisa parar de escrever código, é longe disso (eu pessoalmente gosto muito), mas o balanço entre a execução e o estratégico ganha maior destaque. Seu papel passa a ser multiplicar o valor que seu time entrega.
Usar o seu conhecimento para guiar seu time de forma que eles consigam ter mais impacto, errar menos e crescer mais.
Isso pode se desenrolar através de revisão de código, construção de prioridade na hora de atacar as dívidas técnicas do produto, escrever documentação e muitas outras coisas. Tenha em mente que você precisa gerar valor através do seu time.
Aqui tem um ponto que eu sempre gosto de dizer: eu permito que meu time erre num espaço controlado (e seguro). Às vezes, aquela solução não é a melhor, mas ela carrega um aprendizado. E experiência vem de se experienciar, então cuidado para não virar a mãe coruja 🦉. Aqui vale um destaque até para uma estudo que o Google fez e constatou que equipes de alta performance tem um espaço seguro para cometer erros (e aprender)
Não é sobre fazer, é sobre ensinar
Outra coisa que eu digo sempre pro meu time: eu não dou respostas prontas.
Na verdade, eu digo isso para todo mundo que já aprendeu comigo. Na terapia eu descobri que o meu método de ensino tem uma base na maiêutica , que resumidamente consiste em perguntar ao invés de responder. Isso tem seu nível de frustração envolvido, mas eu acredito que no longo prazo constrói um conhecimento (e uma atitude) que torna a pessoa um indivíduo melhor.
Mas porque eu acredito que isso é importante para um líder técnico?
Porque em muitas situações o caminho mais fácil é executar, ou simplesmente dar a resposta. Existem situações em que isso é necessário, como em um incidente, mas no dia a dia isso pode ser prejudicial, pois vai criar uma dependência do seu time em você.
Prepare seu time para executar num nível de excelência mesmo que você não esteja presente.
Achar o balanço certo entre a entrega de valor e o crescimento do time é essencial, tanto para que a equipe consiga encarar cada vez desafios maiores, quanto para que você possa preparar seu time para assumir seu papel (o que permite que você assuma novos papéis).
Outro aspecto que eu aprendi a ter cuidado é em dividir coisas que eu sei com meu time. Desde conhecimento específico como kubernetes até em como revisar um PR (mérito para o meu grande Team Lead Almeida que levantou essa bola).
Eu já falei sobre ilhas de conhecimento, é importante que vocês estejam atentos a isso.
À procura do desafio certo
Alguns anos atrás eu li o livro Engajamento, do Rogério Chér, e nele eu aprendi um conceito que é chamado de estado de flow.
De maneira simples, o estado de flow é aquele momento que você “se perde no tempo” de tão envolvido que está numa tarefa.
Mas o que eu realmente quero chamar atenção é o gráfico que sempre vem acompanhado desse conceito, que fala da relação desafio x habilidade
Eu já mostrei esse gráfico pelo menos uma vez para todo mundo do meu time, pois eu acredito que ele está intimamente relacionado com um dos meus deveres dentro do time.
Conhecer as habilidades de cada indivíduo vai me permitir ajudar essa pessoa a atuar em algo que não seja nem fácil de mais, nem difícil demais. Só o suficiente para que essa pessoa tenha espaço para crescer. E quando ela cresce, o desafio aumenta.
Quando eu erro nessa etapa, as pessoas vão invariavelmente ficar na linha do tédio (fácil demais) ou na ansiedade (difícil demais).
E acredite, você vai errar. Então estar atento e escutar as pessoas vai te ajudar a corrigir isso e aprender mais sobre seu time.
Claro, existem situações que não tem o que fazer de fato: Tem a tarefa fácil demais que precisa ser feita, ou um problema que é complicado. Faz parte do trabalho (se só tivesse coisa legal ia ser diversão, não trabalho né?)
Explicar, mostrar, corrigir, repetir
Ajudar pessoas a se desenvolverem passa por um processo repetitivo, onde você explica um conceito (como fazer card X), você mostra como isso pode ser feito (esse PR faz X), você corrige (deixei um Review no seu PR) e começa tudo de novo (às vezes até para o mesmo conceito). Repetição é parte do processo de aprendizagem.
Se você já trabalha com seu time a mais tempo, isso tem uma velocidade maior, pois você já sabe que eles conhecem certas coisas, e que não sabem outras.
E esse feedback os ajuda a ter mais confiança, pois eles têm alguém mais experiente olhando e dando um selo de confiança, por isso é importante você também falar sobre os acertos e não só sobre os erros. Aqui fica inclusive a recomendação do Conventional Comments (que a grande Marcela Sisiliani me apresentou) que ajuda muito a alinhar comunicação nas revisões de código.
Um dos meus atuais desafios é entender onde as habilidades de cada integrante do meu time estão concentradas. Essa pessoa conhece mais dessa linguagem? Dessa tecnologia? Desse framework? Compreender isso me ajuda a combinar as tarefas para permitir que pessoas aprendam mais e que as que conhecem o assunto possam passar esse conhecimento adiante. E quando ninguém sabe? Ai eu tenho que ensinar (mesmo que eu não saiba também XD)
Um exemplo prático: Ano passado nós começamos a trabalhar com o Backstage na empresa. Minha expertise não era tão profunda em Typescript, React e outros componentes que envolvem o front dessa aplicação. Ao mesmo tempo que eu quebrava tarefas para o meu time executar e entender mais sobre a arquitetura do Backstage em si, eu aprendia o suficiente sobre o ecossistema para me permitir dar bons feedbacks e orientações sobre como e onde eles podiam fazer algo.
Comunicação, Alinhamento e Comunicação de novo
Um aprendizado poderoso na minha carreira que ganhou destaque para mim esse ano foi o alinhamento de expectativas e a comunicação constante.
Eu já falei que não acredito em coisas óbvias, mas quero destacar o quão importante é o alinhamento. Em muitos cenários, você acaba chegando em uma conclusão e deixa de comunicar ela para os envolvidos. Isso gera ruído, porque você espera algo, ou alguém espera algo de você, que não vai acontecer.
Por diversas vezes eu fazia questão de ressaltar o alinhamento que eu tinha feito, para que diversas pessoas estejam na mesma página. Além disso, comunicação constante.
E comunicação não é micro-gerenciamento tá? Não usa comunicação como desculpa pra isso.
Dois exemplos do meu dia-a-dia: Em um projeto que estávamos trabalhando envolvendo dois times, eu sempre deixava no canal público o alinhamento que eu tinha feito com as lideranças sobre os passos que íamos seguir. Isso deixava todo mundo na mesma página e abria espaço para questionar caso algo estivesse estranho.
Outro cenário foi o da daily: Nosso time é totalmente distribuído e por vezes a daily era nosso ponto central de alinhamento. Mas e se alguém faltar? Filhos, médicos, internet, são muitos os imprevistos que podem fazer alguém precisar não estar presente nesse momento. Nossa alternativa foi deixar no canal do time um alinhamento sobre os combinados que fizemos, principalmente nos casos em que alguém não estava presente. E se a gente esquecer, a pessoa que faltou cobra a gente.
Conclusão
O ano foi intenso, mas duas coisas eu vi acontecer: meu time entregou MUITO e cresceu MUITO ao longo dele. Eu tive a oportunidade de falar e aprender com outros Tech Leads, de aprender com meu time e com meu líder como estar nesse papel.
Você deve ter reparado que ao longo desse texto eu não falei praticamente nada sobre aprender e aprimorar novas habilidades técnicas e o motivo é simples: eu não acredito que isso é o mais importante.
“Quer dizer que o Tech Lead não precisa ter habilidade técnica?”
Longe disso, precisa ter muita. Um exemplo trivial é que ao longo do ano passado, enquanto eu aprendia tudo isso que eu falei ali em cima, ainda tirei a minha certificação da CKA (depois de estudar muito).
O meu argumento é que ao longo da nossa carreira técnica, nós focamos em aprender e desenvolver as habilidades específicas a tecnologia, mas deixamos de lado as famosas “Soft Skills” e quando você assume um papel de líder elas são essenciais e quanto menos você tiver delas, mais complicada sua vida vai ser. Então tem que correr atrás das habilidades comportamentais E da sua habilidade técnica.
Um exemplo prático, esse ano eu vou assumir um novo desafio envolvendo duas coisas que não são parte da minha expertise: novas tecnologias (React por exemplo) e um contexto de negócio novo (CRM).
Não significa que eu não saiba nada desses dois itens, mas eu vou precisar colocar mais energia para aprender e me aprimorar nesses contextos. Ao mesmo tempo, o último ano foi mais intenso no aprendizado das habilidades comportamentais que eu vou precisar bastante no novo desafio: delegação e influência, então eu posso colocar menos energia nessas duas habilidades.
Claro que achar o balanço disso vai ser novamente um desafio, mas aí que está a graça: continuar crescendo, como profissional, como pessoa, como Tech Lead.
Eu vou deixar uma lista de referências abaixo, inclusive uma live que eu fiz tempos atrás falando disso (na época eu nem me imaginava nesse papel).
E se você quiser vir trocar uma ideia sobre, só me chamar no Linkedin :) (pode demorar mas eu respondo todo mundo)
Referências:
(Online Course) Shortcut to Tech Leadership: Accelerate Your Journey From Maker to Multiplier (Eu não fiz esse curso, só assisti muitos vídeos do Patrick)
Talking with Tech Leads - Patrick Kua (Ainda não terminei de ler, são várias entrevistas com Tech Leads. Tem sido legal até onde eu li)
Guides for reaching Staff-plus engineering roles - StaffEng (O site eu já li tudo, o livro ainda não. Mas é bem legal)
When It Comes to Communication from the Top, Less Isn’t More | Stanford Graduate School of Business
Subscribe to my newsletter
Read articles from Rogerio Angeliski directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by