Minha liderança técnica está sobrecarregada, liderando vários projetos. Que sugestões você teria para aliviar essa carga ?
Da série traga soluções e não problemas queria iniciar este post com mais uma pergunta.
Será que uma mesma pessoa sendo ela com um papel de líder técnico deve sempre liderar todos os projetos em uma equipe de desenvolvimento ?
Tanto em startups de alto crescimento quanto em Big Techs, é comum que desenvolvedores de todos os níveis liderem projetos de acordo com seu nível e complexidade.
Como desenvolvedor, é importante desenvolver as habilidades necessárias para fazer isso se você quiser crescer em cargos sênior ou virar uma refência para sua equipe.
Como estamos falando aqui de projetos acredito que devemos antes de tudo dar um pouco mais de contexto no que se diz respeito para poder diferenciar um.
O que considero ser um “Projeto” ?
Se você trabalha em uma empresa de tecnologia, sua equipe quase certamente possui um produto, uma plataforma, um serviço ou alguma funcionalidade.
Sua equipe certamente tem uma missão e, em equipes organizadas, você terá alguns indicadores de saúde e de negócios mensuráveis, como KPIs (Key Performance Indicators) com os quais a empresa e sua equipe se preocupam.
Então uma das primeiras perguntas a se fazer é :
Em que sua equipe estará trabalhando para o próximo período ?
Na maioria das grandes empresas de tecnologia e startups de alto crescimento, a organização tende a executar o planejamento aproximadamente a cada seis meses mais isso pode variar de empresa a empresa então fique atento nesta periodicidade.
O resultado do planejamento é um roteiro para sua equipe. Este roteiro incluirá iniciativas de produto e engenharia, cada iniciativa tendo algum tipo de estimativa de impacto e uma ordem de prioridade.
Minha definição de “projeto” aqui é que este seja um trabalho não trivial que produz um impacto mensurável.
Mas o que seria um trabalho não trivial ?
Se o trabalho pode ser feito em poucos minutos, isso é um projeto ? Na prática eu acredito que não. A maioria das pessoas chamaria isso de tarefa.
E na maioria das vezes tarefa não requer muita coordenação com os outras pessoas. Embora tenha pessoas que possam insistir em chamá-las de projeto, seria tolice tratá-lo como tal, pois os projetos carregam uma sobrecarga que vem com a coordenação de algo que não é trivial e pode envolver várias outras equipes e partes interessadas.
E como saber se é mensurável ?
Bom para isso se você tratar cada parte do trabalho que não é trivial e que esse mesmo requer coordenação como um projeto, logo você se verá com muitos itens de trabalho. Isso vai desde novas solicitações de recursos, passando por bugs complexos a serem corrigidos, até a redução da dívida técnica.
Sabendo agora o que pode ser considerado um projeto, podemos entrar um pouco mais a fundo sobre algumas vantagens da rotatividade desde papel.
Por que acredito ser uma boa prática essa alternância ?
Não teria como iniciar esta parte do texto sem primeiro citar alguns benefícios que vejo para a sáude de uma equipe a médio e longo prazo e um do papel mais benefíciado é o do atual lider técnico.
Benefícios para os atuais lideres técnicos da equipe
São muitas coisa que os lideres técnicos vem a ganhar. Listei algumas aqui:
- Habilidades crescentes que são difíceis de fortalecer de outra forma. Comunicar-se com as partes interessadas, influenciar sem autoridade, capacitar outros membros da equipe, delegar para baixo, para o lado, para cima e estabelecer um processo de mentoria: essas são algumas das habilidades que os lideres técnicos poderão exercer. Embora muitas dessas habilidades possam ser fortalecidas de outras maneiras, liderar um projeto geralmente é o melhor custo-benefício.
- Uma equipe mais resiliente. Tomemos, por exemplo, uma equipe na qual a única pessoa que conduz os projetos é o atual líder técnico. O que acontece se essa pessoa se demitir ou ficar fora do cargo por um longo período de tempo ? Agora compare isso com uma equipe na qual a maioria dos membros da equipe liderou projetos e não tem problemas para assumir a liderança de um projeto. As responsabilidades de liderança rotativas criam uma equipe muito mais resiliente.
- Empatia pelo “outro lado”. Como desenvolvedor de software muitas vezes eu tinha pouca compreensão e empatia pelo trabalho que os líderes e gerentes de tecnologia estavam fazendo até liderar meu primeiro projeto. Um desenvolvedor que assume a liderança ganhará muita empatia sobre o que a atividade realmente implica. Eles serão melhores parceiros para outros líderes de projeto e gerentes, ganhando empatia que é difícil de obter sem experiência em primeira mão.
- Investir em futuros líderes técnicos. Todo lider técnico precisa ter experiência direta de liderança. Ao capacitar mais desenvolvedores para assumir essa responsabilidade no início de suas carreiras, ajudará muitos deles a adquirir esse conjunto de habilidades. Nem todos os desenvolvedores vão querer seguir este caminho dentro da equipe porém é muito importante que esses desenvolvedores experimentem desde cedo como é liderar. Mas para aqueles que têm interesse neste papel você estará os ajudando a progredir mais rapidamente.
Mas nem tudo são flores e algumas situações podem impedir essa alternância
Se há tantos benefícios, por que vemos muitas organizações se esquivando de apoiar mais novos desenvolvedores a liderarem projetos ?
Existem várias razões listei algumas aqui.
- Apoio gerencial: Para que qualquer desenvolvedor lidere um projeto com sucesso, seu gerente precisará apoiá-lo. Isso muitas vezes significa separar mais tempo para essa atividade para ajudar a criar oportunidades encorajando essas pessoas a aceitar esse novo desafio e orientá-las e treiná-las sobre como fazê-lo.
- Gerentes que não querem mentorar: Liderar projetos de software é uma habilidade que melhora com a prática e feedback. Os gerentes que não estão dispostos ou são incapazes de orientar novos líderes geralmente evitam delegar responsabilidades de liderança a pessoas que não tem experiência. Se a gerencia simplesmente delegar, sem um devido suporte os desenvolvedores certamente irão falhar, alimentando o ciclo negativo que a gerencia tinha antes mesmo de delegar o papel.
- Medo de atrasos: Um medo comum que vejo os gerentes terem ao delegar a liderança para pessoas menos experientes está ligado ao resultado. Um resultado negativo fará com que a equipe e o gerente se pareçam ruins. Na minha opinião a expectativa deve se resumir a saber se o gerente apoia o crescimento profissional e visa o crescimento dos desenvolvedores de sua equipe e se eles estão dispostos a apoiar o novo lider técnico a gerenciar suas expectativas de primeira viagem enquanto obtêm mais experiência.
- Desenvolvedores que não querem liderar: Alguns desenvolvedores dirão que não têm interesse em liderar. Os motivos mais frequentes que já ouvi são não estar compátivel com a sua função e não ter interesse além do código. “Não sou pago o suficiente para fazer mais” é uma resposta cínica, mas não incomum. Se alguém genuinamente não quer assumir mais responsabilidades por qualquer motivo, é importante que eles não sejam forçados. Tão importante quanto é delinear caminhos de carreira e oportunidades que podem se abrir para eles, se quiserem assumir mais desafios, e também garantir que o motivo para recusar a chance não seja um gerente ou equipe sem apoio.
- As expectativas de ‘liderar’ não são claras: Poucas pessoas vão querer assumir um papel de liderança que seja muito vago. Para ter sucesso como líder técnico de um projeto, o conceito de “liderança” precisa ser esclarecido pelo gerente. Os gerentes que não fazem isso muitas vezes ficam desapontados com a forma como o desenvolvedor lidera, embora tenham sido eles que falharam em preparar a pessoa para o sucesso.
- “Nunca foi feito assim”: Especialmente em organizações tradicionais, a noção de liderança está muitas vezes ligada a anos de experiência, um título sofisticado e um salário mais alto. Nessas organizações, alguém sem isso pode ser visto como uma ameaça a um modelo que funcionou por tanto tempo. Tudo o que posso dizer é que esta é uma atitude que raramente promove o crescimento ou o sucesso.
Seja qual for o motivo pelo qual os novos desenvolvedores não têm poder para liderar, sugiro encontrar a causa raiz e ver se ainda é válida. Quando bem feito, há muito a ganhar e pouco a perder ao capacitar os novos desenvolvedores a se apropriarem mais do projeto em que trabalham.
Conselhos para desenvolvedores se prepararem para liderar
Nesses meus anos de experiência desenvolvendo software e atuando em papéis de liderança técnica e também como desenvolvedor consegui tirar 5 “insights” que gostaria de compartilhar com todos que almejam essa trajetória.
1. Não espere permissão para liderar: tome a iniciativa.
Supondo que você trabalhe em um local onde os desenvolvedores tenham autonomia, não espere que seu gerente lhe dê o sinal de positivo para liderar uma iniciativa. Se você vir um problema com o qual possa ajudar, intensifique-se e faça-o.
2. Ofereça-se para assumir tarefas de liderança
Nos projetos em que você já está envolvido. Supondo que os projetos tenham uma liderança, deixe-os saber que você está interessado em se desafiar mais e ficará mais do que feliz em ajudar no trabalho e estar aberto a delegar e dar-lhe feedback. O trabalho que você pode oferecer para assumir inclui:
- Facilite uma das reuniões regulares da equipe, como standups, planejamento, retrospectivas e outras reuniões. Venha preparado, faça anotações à medida que a reunião progride e resuma os pontos-chave no final.
- Voluntário para ser o ponto de contato para uma parte interessada específica. Por exemplo, você pode se oferecer para trabalhar com uma parte interessada de negócios específica, mantendo o líder do projeto no circuito e gastando mais tempo com essa pessoa do que o líder do projeto teria largura de banda.
- Lidere uma fase específica do projeto, como um recurso menor, o lançamento, a experimentação ou a coleta de feedback após o lançamento.
3. Colete as dívidas técnicas acumulada durante o projeto
Aqui vai um “disclaimer“:
“Todo projeto gera independente do tamanho ou tecnologia envolvida dívidas técnicas e não seja imaturo em pensar algo diferente disso, faz parte da maturidade de um desenvolvedor saber lidar com esta questão”.
Sugira como mitigá-la e trabalhe com o líder do projeto e a liderança da equipe para priorizar esse trabalho, para que não seja esquecido.
4. Obtenha contexto sobre a empresa, o negócio e o trabalho que está envolvido.
Leia documentos de planejamento de négocio e outros contextos que o ajudem a entender como as equipes ao seu redor trabalham, o que estão fazendo, o que está funcionando e o que não está.
5. Se capacite.
Aprenda que neste papel muitas vezes o sucesso não depende exclusivamente só de você e só o seu conhecimento em programação talvez não seja o suficiente.
Vejo poucos materiais disponíveis atualmente falando sobre esse tema. Eu sempre recomendo o excelente livro Leading Snowflakes by Oren Ellenbogen para pessoas que veem da área de programação e estejam interessadas neste papél.
Este livro contém uma série de hacks que irão ajudar você a se organizar melhor e separar o seu lado “Maker” do seu lado “Manager” ele contém uma série de lições práticas que podem ser aplicadas no seu dia a dia.