Como driblar gatilhos que fazem líderes técnicos perderem o foco estratégico

Nos últimos anos tenho sido desafiado a pensar muito mais em como gerir pessoas, analisar orçamentos, criar métricas e priorizar solicitações do que em como escrever o melhor código para resolver um problema. Estar dentro de um time de desenvolvimento, mas focado em tudo que está à margem do código, foi uma decisão minha, planejada desde 2015.

E tem sido uma experiência desafiadora — desde a necessidade de melhorar a minha comunicação até o autopoliciamento de não me envolver em cada micro decisão interna, confiando, assim, nas decisões do time. Entretanto, toda a gestão do time (reuniões 1:1 periódicas, análise de desempenho, propósito pessoal de cada membro do time e preocupação com workaholics), as novas funcionalidades dos produtos e as expectativas dos clientes criam um ambiente suficientemente complexo. Isto é, possibilitando que uma pessoa com perfil técnico perca o foco estratégico de sua posição.

Profissionais com perfis técnicos, como eu acredito ser, podem ser traídos por gatilhos técnicos em vários momentos do seu trabalho. Esses gatilhos funcionam como oportunidades de fuga que os leva para um ambiente mais confortável e, possivelmente, mais produtivo. Porém, esta fuga tende a provocar sérios riscos em um médio prazo de tempo, causando prejuízos a todo o time.

Esta frase tem soado diariamente na minha cabeça:

“Se você está fazendo o trabalho de alguém, provavelmente, o seu trabalho não está sendo feito por ninguém.”

Sempre que estou envolvido e gastando muita energia em uma demanda que outra pessoa deveria estar fazendo, por mais que eu seja um especialista naquele assunto, certamente estou deixando acumular um conjunto de atividades que eu deveria realizar.

À vista disso, tenho, semanalmente, adotado três premissas que têm me ajudado bastante:

1.Planejar a semana

Gasto boa parte da tarde da minha segunda-feira planejando tudo o que precisa ser feito nas próximas duas semanas. Isso me ajuda a entender o quanto eu tenho de tempo livre para colaborar em outras atividades. Assim, organizo a minha agenda para me colocar à disposição das outras pessoas do meu time, sem comprometer todo o trabalho que devo realizar. Desta forma, posso gastar uma tarde revisando código e fazendo pair programming. Mas, estarei seguro de que minhas atividades executadas estão de acordo com o planejado.

2. Separar um tempo para estudos técnicos

Não quero me distanciar definitivamente do código fonte, então, separo diariamente um tempo para estudos (treinamentos, leituras, TEDs, feed de atualizações de tecnologias e projetos pessoais). Por exemplo:

• Li 14 Hábitos de Desenvolvedores Altamente Produtivos – Zeno Rocha
• Comecei a ler novamente Clean Code – Robert C. Martin (inclusive iniciei uma thread no Twitter sobre as minhas anotações diárias)
• Iniciei alguns cursos free da AWS para solidificar o conhecimento nesta área

3. Colaborar e não liderar todas as decisões técnicas

Por último e mais complexo: não liderar a maior parte das atividades técnicas, mas atuar próximo ao time para desbloqueá-lo — seja minimizando o tempo de solução ou interferindo na qualidade da solução.

Você pode estar se perguntando se consigo estar disponível para a colaboração com problemas técnicos do time, apesar de todas as minhas atividades estratégicas. Neste caso, minha resposta é: Ainda recebo feedbacks negativos neste sentido. Inclusive, o objetivo é estar em constante aprendizagem, e conseguir estar mais disponível para colaborar com as soluções.

Concluindo

Tenho certeza de que muitas pessoas têm passado por esse mesmo problema, pois é o que tenho percebido no meu círculo de convivência. Cabe destacar que o mais importante é identificar a existência desses gatilhos e criar uma estratégia para que eles não sejam acionados no momentos inapropriados, para não deixar o time sem a visão estratégica.