Ok, você recebeu uma ligação do seu chefe ou te chamaram na sala de reunião e falaram para você que agora você é o Tech Lead da empresa, e agora?
Se isso é uma novidade para você, provavelmente vai sentir sentimentos paradoxais, por um lado você ficará entusiasmado por ser reconhecido pelo seu trabalho e por outro um certo medo ou receio, pois agora terá um time que dependerá de suas decisões.
Vou compartilhar com você algumas experiências que tive, o que me ajudou e qual a MINHA opinião do que seja um Tech Lead, Lead Developer, Líder de Desenvolvimento, etc.
Resumindo um pouco minha carreira profissional apenas para contextualizar: Trabalho há mais de 7 anos com desenvolvimento de software utilizando .NET, comecei sendo terceirizado no governo em Brasília, assumi alguns papeis de liderança principalmente na área de pesquisa e desenvolvimento, virei consultor e instrutor pelo Brasil, tentei abrir minha própria startup em São Paulo como CTO, entrei para as estatísticas de startups que falham no primeiro ano, e hoje sou Arquiteto de Software na Docway, uma healthtech que está mudando a forma de acesso médico no Brasil.
O que vejo acontecer bastante é um empresa pequena ou uma startup colocar o primeiro desenvolvedor como CTO ou como o Arquiteto de Software ou como Líder de Desenvolvimento, e isso não está errado. Errado é a pessoa que assume essa vaga não correr atrás do conhecimento específico para cada responsabilidade que são bem diferentes, inclusive com vertentes técnicas, gerenciais e até empresariais.
Vamos olhar o meu caso como CTO. Éramos poucas pessoas e eu o único com conhecimento de programação, sozinho eu fiz aplicativos, sites, landing pages, painéis administrativo, integração com ELK, ia em reunião de investimento, montava organogramas, recrutava, desenhar estratégias em longo prazo e planilhas de custos tanto de pessoal quanto de equipamentos e softwares. Inclusive fui até para a Colission Conf de 2017 em New Orleans ficar em pé em um stand apresentando nosso projeto para todo mundo que passava em inglês. Ou seja, sem verba para contratar e o trabalho precisar ser feito você acaba aprendendo a fazer as coisas na raça.
Ok, mas o post é sobre Líder de Desenvolvimento, por que me falar de CTO? Simples, as responsabilidades de um Tech Lead estão mais para gerenciar a equipe e garantir que as coisas aconteçam do que codificar em sí. Imagine o Tech Lead como um meio termo entre CTO e Desenvolvedor Sênior, nem vou colocar Arquiteto aqui pois é outra discussão.
Algumas dicas que dou para quem virou um Tech Lead há pouco tempo são:
Alinhe as expectativas
Acima de qualquer coisa você tem que entender o que a pessoa que te colocou como líder espera que você faça, pois a definição e atribuição de um líder pode mudar de empresa para empresa, e quem cuida do organograma da empresa é exatamente a pessoa que colocou lá, certo? Então tire um tempo para que vocês alinhem o que cada um quer, e uma dica de ouro, peça uma “luz” e que ele compartilhe a visão do time de desenvolvimento para os próximos meses, não vá achando só porque você era do time de desenvolvimento que você sabe o que é melhor, como desenvolvedor as decisões gerencias e até estratégicas não chegam até você, tenha isso em mente, e seja humilde, mas sem deixar seu conhecimento de lado, pois se você virou o Tech Lead algo em você eles viram.
Não se apegue tanto ao ato de codificar
É claro que você tem um background técnico e adora codificar, você não precisa deixar totalmente esse hábito, mas como seu tempo será ocupado pelas mais diversos tipos de reuniões, monitoramento de KPIs e principalmente com várias outras tarefas que surgirão vindas do seu time, simplesmente não irá conseguir se dedicar 100%.
Mas nesse caso você pode e deve se voltar para revisão de código, e quando a maré baixar nada impede de você pegar uma demanda ou outra, mas aprenda a confiar no seu time, e isso demandará tempo, mas depois que você conseguir a confiança recíproca deles, sua vida como Lead se tornará muito melhor.
Gerencie sua agenda
Está ai uma tarefa que para um desenvolvedor não é comum, mas quando se torna Lead o Google Agenda ou qualquer outra ferramenta de invite se torna sua página ou app mais acessado.
Irão aparecer reuniões com o time de operação, reuniões com o gerente ou CTO da sua empresa, reuniões com o seu próprio time, e isso fora os ritos do Scrum se vocês os adotam, ai vem a daily, planning, grooming, retrospective, review, etc.
Uma dica é sempre que surgir um evento, peça para a pessoa te mandar o convite ou você mandar para ela para que esses horários sejam respeitado, se não meu amigo você vai se perder bonito nisso.
Mas não pense que a agenda é dos outros, ela é sua, reserve para você mesmo um tempo seu, um horário que você não marque nada e você consiga fazer coisas suas, sejam estudar uma nova metodologia/tecnologia ou até mesmo um tempo de descompressão, por favor, não preencha 100%, e a próxima dica é a mais valiosa.
Aprenda a dizer NÃO
Certeza que essa é uma das coisas mais difíceis, pelo menos para mim foi, eu sempre fui aquela pessoa que corria atrás, que dizia sim, se não tinha um jeito eu procurava mil e uma maneiras, mas como Lead você tem que entender que dizer um SIM, não é um sim seu, e sim do seu time, dizer SIM para uma nova funcionalidade quer dizer que vai colocar o designer para trabalhar, o desenvolvedor para codificar e o QA para testar, é colocar mais de um card no trello por exemplo.
Mas também não é simplesmente dizer NÃO toda hora. Ai que vem o segredo, quando alguém pedir para você: “Precisamos que a tela X agora tenha o botão Y para fazer Z”. Você vai olhar como estão as atividades do time, vai entender se é possível ou não colocar isso no backlog da sprint, e se não conseguir tem duas alternativas de respostas: “Não conseguimos colocar nessa sprint, espera até a próxima sprint?”, se a resposta for não por ser um demanda urgente você pode responder: “Ok, então vamos ter que conversar com o responsável do produto para saber das demandas da sprint atual qual tem menor prioridade e pode ser realocada em uma próxima sprint”. Óbvio que existem vários fatores em uma situação dessa, como tempo, qual o projeto, como está o time, se todo mundo no time está ok, se alguém teve algum problema e não trabalhará naquela semana, etc.
Delegue
Quando se é um líder boa parte das demandas chegam primeiro até você, e você não irá conseguir fazer todas sozinho, você tem um time que te apoia e conta com você. Então quando um demanda chegar até você não saia correndo loucamente abrindo o Visual Studio, baixando o código do git, e verificando o por quê daquela funcionalidade não está funcionando. Aprenda a delegar e confiar na sua equipe, se é urgente chame a pessoa que fez aquele código, ou alguém do time responsável que seja pelo trecho de código, por exemplo, não é porque o fulano fez aquela linha que tem que ser ele que corrija, mas alguém com habilidades parecidas, seja de back-end, front-end, mobile, design, etc.
De novo, confie no seu time!
Construa uma cultura no seu time
Está ai uma atividade extremamente difícil. Uma cultura é formada pelas pessoas que estão trabalhando juntas, se entendem e já conseguiram construir um sinergia entre eles. Experimente tirar ou colocar uma pessoa no time, as interações mudam completamente, o time acaba construindo outra cultura que interaja com a saída ou entrada de um novo membro, pois o time nunca será o mesmo, e isso acontece também quando alguém adoece e vai ficar vários dias fora, o time acaba mudando por conta própria, seja por necessidade, quando alguém terá que assumir a responsabilidade do outro que saiu, ou quando alguém que entrou tem novas ideias que o time adorou.
Lidar com pessoas é uma arte, existem vários livros, podcasts e videos sobre liderança, tanto no mundo empresarial, quanto no de tecnologia especificamente. Só fica parado e estagnado quem quer.
Aja da forma que a situação exija
Eu gosto de pensar que existem diferentes formas de liderar, e em alguns lugares que eu estudei os definem da seguinte forma:
- Coach – Às vezes a pessoa que vem até você já tem a resposta, ela só precisa ligar os pontos, nesse caso o seu papel é fazer as perguntas para que ela sozinha consiga resolver o problema.
- Shepherd (Pastor) – Existem situações que a pessoa precisa que você a acompanhe naquele problema, seja com uma segunda opinião, ou dando apoio moral e técnico para achar a resposta do problema encontrado.
- Shaman – Quando um problema é encontrado e você precisa explicar o por quê daquilo ser feito daquela forma, ou do por quê existe esse débito técnico, do por quê tal framework foi utilizado ao invés de outro. Esse é um dos papeis mais difíceis, pois nem sempre nós sabemos ou temos capacidade de entender do por quê isso ou aquilo existe, mas é nossa responsabilidade saber do hoje para frente.
- Champion – Às vezes temos que dar ao nosso time espaço para resolver o problema, e não ser interrompido pelas outras áreas da empresa, quando você precisa agir como um “Champion” quer dizer que o time precisa de você mais que tudo para blindar qualquer entrada que possa atrapalhar a resolução do problema, um exemplo é quando acontece um erro crítico em produção e vem todas as áreas perguntando e demandando respostas, é ai que você entrada para impedir que isso atrapalhe as pessoas que estão de fato debruçadas e empenhadas em resolver o problema.
Existem várias outras dicas que poderia compartilhar, mas acredito que essas já dão um norte em como se tornar um líder melhor para seu time.
Lembre-se como líder você interage mais com pessoas que com código, então tenha empatia sempre.