Elton Minetto

Principal Software Engineer no PicPay

Sim! Escrevi um post sobre mim mesmo! Sei que isso parece uma grande ego-trip, por isso demorei bastante para decidir publicar a minha entrevista. No começo deste mês eu completei 6 meses atuando como Principal, por isso achei um momento oportuno para compartilhar um pouco da minha trajetória. Espero que seja útil para vocês, assim como as entrevistas anteriores me ajudaram muito a chegar até aqui.

Conte um pouco sobre sua posição atual. Qual é o seu título e que tipo de trabalho você faz geralmente?

Atualmente sou Principal Software Engineer no PicPay. Eu atuo em uma área chamada Production Engineering e os nossos times são responsáveis por produtos e ferramentas para os outros times de desenvolvimento da empresa. Coisas como CI/CD, portal interno de desenvolvimento, etc, são responsabilidades compartilhadas pelos times onde eu atuo. Como Principal eu participo de discussões de arquitetura com os times, trabalho em temas como padronização e boas práticas de desenvolvimento, faço mentoria com algumas pessoas, desenvolvo provas de conceito de novas tecnologias e soluções. Passo bastante tempo escrevendo RFCs, Design Docs, fazendo code review, escrevendo e respondendo threads no Slack. 

Que tipo de impacto você sente que mais gera na sua posição atual? E como isso é diferente em relação a sua posição anterior?

Antes de vir para o PicPay eu passei alguns anos atuando como CTO e Tech Manager de startups de pequeno e médio porte. Isso me fazia dividir bastante o tempo entre a área técnica e outras responsabilidades, mas agora posso focar 100% na parte onde eu posso causar mais impacto, que é a técnica. A posição de Principal me permite trabalhar em questões mais transversais, que envolvem vários times dentro da minha área e da empresa como um todo. Resumindo, o que mudou muito foi que agora eu tenho um foco muito preciso em tecnologia e a possibilidade de impactar diversos times ao mesmo tempo. 

Qual é o percentual de trabalho entre código e liderança que você desempenha hoje? 50/50? Passa mais tempo trabalhando com tecnologia/codando ou mais tempo liderando pessoas?

Apesar de não ter ninguém respondendo diretamente a mim no organograma da empresa, a posição de Principal tem muita responsabilidade de liderança. Mas é uma liderança mais por influência e exemplo do que por hierarquia direta. Isso é um desafio bem interessante, pois é uma dinâmica bem diferente. Eu posso dizer que passo 100% do tempo pensando e trabalhando com tecnologia, mas escrever código é uma parte menor desse percentual. Faço um bom número de provas de conceito para apresentar para os times, contribuo codando para algumas libs internas que estamos criando, mas a maior contribuição que faço é participando da escrita de RFCs, Design Docs, fazendo code reviews, palestras internas, pair programing com algumas pessoas eventualmente. 

Como é um dia normal na sua rotina? Ou como é uma semana normal para você?  Quais são suas rotinas principais?

Eu gosto de começar a semana definindo quais são as prioridades que eu quero dedicar tempo nos dias seguintes. Compartilho essa lista em um canal no Slack com o outro Principal da área e nosso head para pegar feedbacks se tem algo que é mais importante ou se podemos juntar forças em algum tópico. Com isso definido eu bloqueio horários na minha agenda para trabalhar nestes pontos que são prioritários. O restante da semana eu deixo livre para participar de reuniões de planejamento com os times, refinamentos técnicos, eventos internos, fazer code review. Além disso, monitoro alguns canais do Slack para ficar a par de eventuais incidentes, discussões técnicas que estão acontecendo nos times e que posso contribuir, pull requests importantes que posso revisar, etc. Não existe uma rotina muito rígida, cada semana é diferente e isso é muito empolgante para mim. 

Como você mede seu sucesso? Quando somos pessoas desenvolvedoras de software é comum medirmos nosso sucesso pelo número de commits, pull requests, entregas realizadas. Isso mudou de alguma forma em sua posição atual?

Uma prática que comecei a fazer no começo deste ano e que tem me ajudado muito é manter um Brag Document sempre atualizado. Toda sexta-feira, a última tarefa do meu dia é atualizar esse documento com as entregas que eu fiz na semana e que considero relevantes. Pode ser um documento entregue, a participação em algum code review ou mentoria. Isso tem me ajudado a manter um registro das coisas importantes que tenho feito e me deixado longe da síndrome do impostor. 

Você participa das decisões de tecnologia ou arquitetura? Como gerencia essa influência em relação aos demais times? Você toma boa parte das decisões ou guia os times para que eles cheguem às conclusões?

Esse foi um dos erros que cometi quando comecei nessa posição e tento evitar que aconteça novamente. O que eu tento fazer é levantar perguntas e cenários relevantes para levar o time a chegar as melhores conclusões ao invés de apresentar minha visão logo no começo da discussão. Posso acabar influenciando uma decisão pela minha posição e o ideal é que eu consiga elevar a discussão para o time chegar a melhores conclusões. Claro que em alguns cenários, onde o time tem menos senioridade ou não teve experiências em determinada área ou tecnologia faz sentido um Staff ou Principal guiar as decisões de maneira mais incisiva. Mas o desafio é sempre ponderar qual é a situação para saber onde e como agir. 

Que soft-skills você percebe que fazem a diferença na sua posição? E como eles diferem da posição anterior, como dev senior?

Eu li em algum lugar que deveríamos renomear "soft-skills" para "core-skills" pois são cruciais para a carreira das pessoas. Independentemente do nome, o sucesso da posição de Staff e Principal depende muito dessas skills. Como citei anteriormente, não possuo um cargo oficial de liderança, no sentido de ter pessoas respondendo diretamente a mim, então preciso ser capaz de explicar, ensinar e influenciar por outros métodos. Meu passado de professor, palestrante e tech manager me ajuda muito pois preciso apresentar conceitos complexos, encontrar formas de explicar e exemplificar de diferentes maneiras. Habilidade de comunicação é crucial, tanto oral quanto escrita, especialmente no ambiente remoto e assíncrono que temos hoje em dia. 

Você dedica tempo para mentorar as demais pessoas dos times?

Comecei um processo formal de mentoria com algumas pessoas dos times. Estou aprimorando o formato com eles antes de aumentar o escopo para mais pessoas e times. Acredito que é uma responsabilidade do cargo e algo muito importante para ambos os lados. 

Para chegar a esta posição, você entregou algum projeto especial, ou você sente que foi uma progressão pelo conjunto das suas contribuições?

No livro Staff Engineer: Leadership beyond the management track, Will Larson fala sobre as possibilidades para atingir a posição de Staff+ e uma delas é a que eu fiz: troquei de empresa. A empresa onde eu estava trabalhando era incrível, mas o caminho que eu queria seguir, que era Staff+, iria demorar muito para acontecer lá. Então procurei uma oportunidade em outra empresa, que foi o PicPay. 

Desta forma, não foi um projeto em especial, mas uma soma de várias coisas que eu fiz durante a minha carreira que contribuíram para eu poder desempenhar o papel que faço hoje. Experiência em diversos tipos de projetos, participação em comunidades de software livre, palestras, networking, tudo se somou para me ajudar a continuar crescendo na área. 

Que dicas você pode dar para quem está decidindo se continua o caminho de desenvolvimento ou se deve ir para a área de gerenciamento de pessoas? O que levou você a escolher pelo primeiro caminho?

Quando eu comecei a me questionar sobre qual caminho seguir eu fiz algumas coisas, que comentei neste post. Mentorias, leituras, conversas com minha liderança e com outras pessoas que seguiram caminhos similares. Uma das dicas que recebi em uma das mentorias foi que o melhor a se fazer é testar. Se você tem dúvidas sobre qual caminho seguir, tente ser gestor por algum tempo para ver se é o que você se identifica. Se não for, converse com sua liderança para seguir na área técnica. No pior dos casos essa experiência vai te tornar melhor profissional. 

Quais fontes você usa para se especializar? Blogs, livros, canais do Youtube.

Eu gosto muito de seguir pessoas relevantes no Twitter, acompanho feeds do Hacker News e Product Hunt para ficar de olho em novas ferramentas. O livro do Will Larson é muito bom, bem como a conta do autor no Twitter. A Tanya Reilly escreveu um livro sobre a carreira de Staff recentemente que está na minha lista de leitura, mas tenho visto bons reviews sobre ele. O Twitter da Tanya também é muito bom, bem como o do Kelsey Hightower. Outra referência importante é o https://leaddev.com/ que tem posts e eventos dedicados a área de liderança técnica. 

Onde as pessoas podem te encontrar? Site, Linkedin, Twitter, etc. 

Eu escrevo regularmente no meu site pessoal, o https://eltonminetto.dev e na minha conta no Twitter por isso são os locais principais para me encontrar. Além disso, também compartilho alguns códigos no meu Github e mantenho uma newsletter sobre Go.  E mantenho essa newsletter que você está lendo :)