Roberta Arcoverde

Diretora de Engenharia na Stack Overflow

Nesta edição temos a honra de contar com a contribuição de uma pessoa que eu admiro muito, desde que comecei a ouvir o Hispters.tech. Com vocês, Roberta Arcoverde!

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

Hoje sou Diretora de Engenharia na Stack Overflow. Gerencio diretamente desenvolvedores no time do Stack Overflow for Teams - onde anteriormente atuava como Staff Engineer e Tech Lead. É um trabalho tanto estratégico quanto tático: sou responsável por revisar e orientar nossa arquitetura, propor novos processos pra aumentar a produtividade do time, coordenar trabalho com outros times e gerenciar as carreiras dos desenvolvedores.

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?

Estar na mesa de discussão com outras lideranças da empresa certamente me abre hoje muito mais oportunidades de impactar o futuro da organização do que quando era desenvolvedora. Mesmo como Tech Lead, muitas vezes minhas ideias e influência estava limitada a atividades - e pessoas - mais próximas, com menor impacto estratégico. Por exemplo, como diretora hoje eu tenho autonomia pra criar times temporários quando preciso lidar com um problema urgente (a migração pra .NET6 foi um exemplo recente). Como Tech Lead, o máximo que conseguiria fazer é escalar o problema pra meu gestor, torcendo pra que ele concordasse com minha avaliação de urgência.

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?

Eu acredito fortemente que gestores devem continuar programando, especialmente no primeiro nível de gestão, quando ainda se gerencia desenvolvedores diretamente. Claro que à medida em que se progride na carreira, o tempo pra programar fica mais escasso;  mas manter-se tecnicamente apto ainda é, em minha opinião, extremamente importante em qualquer cargo de liderança de engenharia. Hoje eu programo menos do que gostaria, em torno de 10% do meu tempo. Porém, como era desenvolvedora no time que hoje gerencio, ainda tenho profundo conhecimento e entendimento dos sistemas. Tenho priorizado revisar código e pull requests, mais como mentora ou revisora secundária. Entretanto, meu foco principal é na liderança das pessoas e do time de forma geral.

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

Cerca de metade do meu tempo é dedicado pra reuniões gerais com os times de gestão e 1:1s - tanto com as pessoas do meu time, quanto com meu gestor, meu VP de engenharia, CTO e outros diretores. A outra metade se divide: tenho reuniões regulares com o time inteiro, como cerimônias de Scrum, mas também várias sessões avulsas pra ajudar a debugar problemas e incidentes. Costumo reservar alguns blocos de 2 horas pra trabalhos que exigem mais concentração: por exemplo, se preciso pensar melhor na nossa estratégia e OKRs, ou escrever proposta de novos processos e políticas, ou até fazer avaliação de desempenho. Por fim, sempre dedico algum tempo na semana pra atividades técnicas: pequenos bug fixes, revisão de pull requests, revisão de documentos de decisão arquitetural, enfim, coisas que permitam que eu me mantenha “técnica”.

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?

Essa é uma pergunta que ainda não sei responder, até por ter pouco tempo ainda no cargo. Mas presto muita atenção nas dinâmicas do time - se estão todos colaborando, participando, dando bons conselhos uns pros outros. Um time funcional, na minha experiência, se comunica bastante, com clareza, respeito e confiança. Conseguir manter o time produtivo e feliz, pra mim, é um grande indicativo de sucesso.

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?

Uma das minhas responsabilidades como diretora é também garantir que a direção técnica do time faz sentido e se adequa aos objetivos da empresa. Pra isso, estou sempre envolvida - mesmo que apenas como revisora ou conselheira. Em alguns momentos específicos, tenho um papel mais ativo de realmente decidir uma abordagem específica, mas tento sempre colaborar com o Tech Lead e outros desenvolvedores mais experientes pra saber se minha visão faz sentido. Minha preferência é sempre de dar autonomia pro time tomar decisões arquiteturais, mas tenho o privilégio de entender profundamente como nossos sistemas funcionam, então consigo ajudar um pouco mais a fundo.

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

Acredito que aprender a negociar é uma habilidade importantíssima em gestão. Também de escutar e entender mais, fazer boas perguntas, e falar menos. Como dev senior, eu tinha um papel muito mais ativo de propor soluções técnicas e responder perguntas; essa relação se inverteu quando passei pra gestão.

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

Não apenas as pessoas dos times, como também outras pessoas de outros times. Tenho hoje 3 mentorandos que não trabalham diretamente comigo com quem me encontro regularmente, tanto pra dar direcionamento de carreira quanto pra tirar dúvidas técnicas. Devo muito do que aprendi a mentores muito generosos, e acredito ser obrigação retribuir e ajudar desenvolvedores, assim como fui ajudada.

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?

Ao longo de oito anos, foram vários projetos especiais de que tive a sorte de fazer parte na Stack Overflow. Sem dúvida o maior e mais complexo deles foi o Stack Overflow for Teams, que começou em 2017 e onde trabalhei desde a primeira linha de código escrita. Mas eu não diria que este ou outro projeto em especial foram determinantes pra minha progressão de carreira; acredito que foi mais um reconhecimento pelo conjunto das minhas contribuições e habilidades de liderança ao longo destes anos.

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 a oportunidade de ir para gestão me foi oferecida pela primeira vez, eu escolhi continuar como desenvolvedora. Tinha já mais de 15 anos de experiência, gostava muito ainda da parte técnica e não estava preparada pra parar de programar. Alguns anos depois percebi que estava ficando confortável demais e sentia falta de aprender habilidades novas. Além disso, sempre gostei muito de mentorar e ajudar a desenvolver novas desenvolvedoras. Assim, a posição de diretora caiu como uma luva: é ainda técnica o suficiente pra exigir que eu permaneça estudando e me informando, mas me dá a possibilidade de impactar a cultura da empresa e a arquitetura dos nossos sistemas de uma forma muito mais ampla. Tive também a sorte de estar em uma empresa que permite que eu volte a ser desenvolvedora, caso não me adapte à carreira de gestão. Pra quem está pensando em trilhar esse caminho, minha sugestão é: trate gestão como uma nova carreira. Leia bons livros, bons autores, converse com outros gestores, e não deixe de se atualizar tecnicamente.

Você lembra de algum conselho ou dica que recebeu quando entrou nesta posição e que foi importante para você?

Dois conselhos foram muito importantes e lembro sempre deles até hoje:

1. Dê feedback construtivo o quanto antes. Pode ser desconfortável, mas quanto mais nos demoramos ou quanto mais relevamos comportamentos que precisam ser ajustados, menores as chances de que a pessoa leve o feedback a sério. Penso sempre na máxima que nenhuma avaliação de desempenho pode ser uma surpresa; se for, o gestor não comunicou o que devia no tempo que devia.

2. Modele a informação de acordo com a audiência. Cometi esse erro algumas vezes, ao escrever verdadeiras dissertações pra explicar uma solução pra meus gestores. Aprender a comunicar de forma objetiva e concisa é extremamente importante quando o fluxo da informação é bottom-up; porém, muitas vezes precisamos ser bem mais detalhistas ao descrever a mesma informação pro time de desenvolvimento ou PM. Aprendi a modelar o nível de detalhes necessário pra cada interlocutor.

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

Eu gosto muito de ler livros. No momento, estou lendo The Making of a Manager, da Julie Zhuo mas também Software Architecture: The Hard Parts, do Neal Ford. Li o Accelerate recentemente e gostei também. Tento ficar sempre de olho em blogs de engenharia de outras empresas: Pinterest, Dropbox, GitHub, Shopify - há várias empresas hoje que compartilham regularmente seus desafios e soluções. Sempre há algo novo pra aprender.

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

Eu tenho um site onde posto minhas reflexões muito raramente, mas também mantenho uma lista atualizada de podcasts em que participei e palestras. É o https://rla4.com

Twitter: @rla4 

LinkedIn: https://www.linkedin.com/in/robertaarcoverde/