De DEV para Manager, e agora?

"TL;DR"

Minha percepção do que mudou junto de medos e mitos que enfrentei durante este primeiro ano de transição de carreira.

Hoje completo o ciclo de 1 ano como Software Engineer Manager na Azion Technologies.
Para quem trabalhou há mais de 20 anos como desenvolvedor uma série de medos/receios me cercaram antes de me aventurar nessa nova jornada.
Resolvi listá-los e compartilhar nesse material com o que me deparei e o que mudou na minha rotina nesse primeiro ano.

Vou deixar de programar, logo, vou ficar estagnado:

Sim, deixei de programar, mas não fiquei parado no tempo, e explico o porque: como Manager preciso me aprofundar tecnicamente nas soluções com um visão mais macro de como as coisas irão funcionar. Faço algumas POC's (quando posso), mas realmente: raramente toco em código no meu dia-a-dia.
A grande diferença está em precisar abstrair mais conhecimento através de reuniões com outros managers e grupos técnicos com a finalidade de definir e arquitetar como as soluções (no casos Iniciativas) serão entregues. Não tenho o ambiente de desenvolvimento "setupado" no meu PC, porém devo ter condições de entender e saber fazer isso se necessário.

Então como não ficar estagnado se não codifico:

Por incrível que pareça algo que aprendi dando aula é: você aprende muito conversando! Por ser desenvolvedor há um bom tempo, quando alguém me fala que vai "precisar configurar um container Docker para subir um back-end e implementar um end-point de uma API usando Django" eu consigo arquitetar isso perfeitamente em código mentalmente, e isso é algo que amadurece a cada nova interação com outros times, grupos, etc.

Proximidade da comunidade:

Algo que acredito que me ajuda muito a não me distanciar do código mesmo não “codando” no turno integral, são as aulas que ministro a noite. São cursos de programação básica & avançada e independente do nível conteúdo me possibilitam continuar aprendendo e revisando consecutivamente para não deixar o material depreciado. Mantive ativo meu canal no Youtube e procuro sempre que possível gravar algum conteúdo novo. Permanecer conectado a tecnologias que eu já dominava me obriga a me manter atualizado e isso junto com o ensino e troca de experiências deixa o "coração de programador" aquecido.

Realizar talks como já fiz no TDC, ou diretamente para outras empresas ajudam bastante também.

Todo código e POC's que produzo subo no meu GitHub pessoa para poder compartilhar com quem está começando ou aprendendo algo novo, isso se torna mais um meio de interação com os desenvolvedores que por muitas vezes já entraram em contato comigo por diversas plataformas: Linkedin, GitHub, Email e até WhatsApp.

Reuniões ao invés de código:

Diálogo faz parte rotina, muito mais do que quando era DEV. Entender qual a necessidade da área cliente (no meu caso Produtos) e trazer isso para o time de forma que fique claro o que precisa ser feito é um dos novos papéis. Todos sabemos (inclusive eu) o quanto é frustrante construir algo sem saber direito o que é preciso fazer, bem como colocar fora algumas horas de raciocínio e linhas de código — logo preciso alinhar, alinhar e alinhar com as áreas envolvidas cada dependência que possa impactar em esforço X tempo do time, e isso tudo é feito através das reuniões.

Um exemplo de semana "cheia"

Lógico que existem inúmeras ferramentas ao meu favor: Jira, Trello, GitHub, Slack, Google Drive, etc — dessa forma consigo manter um planejamento do que está por vir para mim e para o time.

Menos "gaps" = menos riscos

Eu preciso ter claro na minha cabeça ou em alguma aplicação o que realmente precisa ser feito, e isso envolve:

• Épicos
• Tarefas
• Esforço e tempo
• Pessoas e times envolvidos
• Dependências
• Investigações que precisam ser feitas (de preferência antes do trabalho começar a virar código)
• Roadmap
• Documentações de apoio (uma WBS por exemplo…)

Tudo isso documentado, desenhado e planejado de forma a ter o mínimo de impacto na entrega, principalmente no que diz respeito ao papel principal da funcionalidade em si e consequentemente ao prazo.

Clareza e comunicação: o óbvio precisa ser dito e perguntado

Ainda com relação ao tópico acima, existem perguntas e respostas que para muitos desenvolvedores vão estar implícitas na funcionalidade. Porém como seres humanos temos algumas questões comportamentais que as vezes nos impedem de perguntar algo que para nós talvez seja óbvio, e que lá na frente pode impactar por completo uma entrega ou travar completamente o time. Uma pergunta ou afirmação por mais óbvia que seja pode economizar você de grandes dores de cabeça, principalmente para mapear dependências que não ficam visíveis em um primeiro planejamento.

A transparência precisa existir desde o início do processo até o final, inclusive em momentos que precisamos assumir um erro de percurso, ou um atraso na Dead Line de entrega, isso permite um ajuste de jornada e alinha expectativas quando ao delivery de uma feature — lembre-se que muitas vezes existem outras pessoas, clientes ou times esperando por você, portanto avisar que algo vai atrasar um dia antes da entrega é algo bem complicado.

O bem maior: as pessoas

Gerenciar código é muito mais fácil e menos complexo que gerenciar pessoas. Durante minha carreira passei por inúmeros chefes/gerentes. Alguns excelentes, outros bons e outros ruins, e durante esse tempo sempre apreciei os que valorizavam o nosso trabalho, bem como nos tratavam não só como "recursos" e sim como pessoas.
Gerenciar pessoas envolve empatia, atenção, cuidado e principalmente mais ouvir do que falar, mas isso vou deixar para aprofundar em um outro post…

Alguns livros que me ajudaram a chegar aqui:

• Para novos gerentes (10 leituras essenciais — HBR)
• Gestão de Alta Performance: Tudo o que um gestor precisa saber para gerenciar equipes e manter o foco em resultados
• Gestão do tempo (Sua carreira em 20 minutos — HBR): Concentre-se no que importa. Evite distrações. Faça o que tem que ser feito.
• Feedbacks Produtivos (Sua carreira em 20 minutos — HBR)

Uma breve conclusão:

Como líder e como um Engenheiro apaixonado pelo mundo do Software algumas lições que aprendi e continuo aprendendo: a zona de conforto é um lugar perigoso para ficar, nosso organismo tende a nos afastar de desafios que possam nos tirar dela, mas só saindo desta zona conseguimos ter novas experiências e consequentemente novas recompensas, assim evoluindo.

Como vimos no filme "Procurando Nemo": Dori, continue nadando…