Rosicléia Frasson
Staff Software Engineer II no Banco Neon
A Rosicléia trás ótimas dicas e experiências. Entrevista imperdível.
Conte um pouco sobre sua posição atual. Qual é o seu título e que tipo de trabalho você faz geralmente?
Atualmente eu atuo como Staff Engineer II no Banco Neon, na área de cartões. Minhas atividades diárias são bem diversificadas. Para novos produtos, eu sou responsável pelo estudo de viabilidade técnica, cálculo de esforço, decisões arquiteturais, alinhamento com os managers, times de produtos e demais envolvidos. No dia-a-dia fico de olho qualidade, boas práticas, padronização e documentação. Quanto temos incidente em produção relacionado ao contexto de cartões, ajudo a restabelecer a normalidade.
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?
Eu preciso navegar entre diversas equipes e áreas e normalmente os projetos que eu sou responsável tem grande relevância para a organização. Embora eu já tenha trabalhado em projetos de grande impacto na posição anterior, nesse momento, eu tenho mais autonomia, mais poder de decisão e o nível de cobrança é maior. Outra coisa que vale destacar, é que as minhas decisões são baseadas no patamar que a empresa quer alcançar a médio e longo prazo. É minha responsabilidade que o conjunto de softwares que eu atuo esteja preparado para a Neon do futuro.
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?
Nesse momento, eu procuro desempenhar na maior parte do tempo um papel de liderança técnica. Eu sou a pessoa que os desenvolvedores e outros staffs procuram quando precisam de alguma ideia/solução para um problema que envolve tecnologia. Hoje, formalmente, eu não tenho nenhum subordinado, mas ocasionalmente ajudo na organização do time, distribuição das demandas e priorização.
Posso dizer que em torno de 80% do meu tempo é gasto com o que eu chamo de atividades de engenharia: design de solução, implementação, documentação, code review, testes e monitoramento. O percentual restante é usado em mentorias, alinhamentos e acompanhamento de atividades.
Como é um dia normal na sua rotina? Ou como é uma semana normal para você? Quais são suas rotinas principais?
A minha rotina é bem diversificada. Mas como devem imaginar, eu tenho muitas reuniões: eu participo de discussões sobre novas features e produtos, tenho alinhamentos recorrentes com outros times e parceiros sobre projetos em andamento, participo quinzenalmente de uma agenda com o time de CX para entender os principais problemas reportados pelos clientes, tenho agendas recorrentes com outros líderes da área.
Eu tenho separado 3 períodos da minha agenda para atividades que exigem concentração. Uso esse tempo pra corrigir bug, desenvolver alguma task do board, montar algum system design, fazer code review, mapear próximos passos, fazer triagem de débitos técnicos.
Ao longo do dia respondo pessoas nos canais e DMs do Slack, algumas pessoas me procuram para quick meetings, para tirar alguma dúvida ou debater alguma ideia. Também atuo na remoção de impedimentos.
Esporadicamente dou uma olhada nos projetos que outros staffs estão trabalhando: acompanho o andamento, principalmente nas atividades designadas para os times fora do contexto de cartões. Dou alguns pitacos na montagem da solução, discuto trade-offs, melhorias e priorização das atividades.
Tenho um tempo reservado para auxiliar no processo seletivo, conduzindo entrevistas técnicas. Faço mentoria com algumas pessoas e participo de algumas talks da empresa.
Eventualmente, olho os dashboards de monitoramento e se identifico alguma anomalia, tento descobrir a causa ou peço para alguém dar uma atenção. Quando acontecem problemas em produção, dependendo da criticidade, a minha prioridade zero passa a ser restabelecer a normalidade.
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?
Sim, hoje meu sucesso está relacionado ao trabalho entregue por inúmeras pessoas, e não exclusivamente as minhas entregas. Ser um facilitador para que as entregas aconteçam, aumentar o conhecimento técnico de um grupo de pessoas, garantir a qualidade e a resiliência dos softwares que estão sob minha responsabilidade são medidas de sucesso que eu costumo aplicar.
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?
Sim, garantir que optamos pelo melhor caminho levando em consideração o escopo, prazo e quantidade de pessoas disponíveis é uma das minhas responsabilidades.
Eu não curto tomar decisões de tecnologia/arquitetura sozinha, normalmente uma decisão dessas impacta o trabalho na área e as evoluções por alguns anos. Então, eu prefiro montar um fórum com algumas pessoas para essas tomadas de decisão. Algumas vezes eu faço um pré-work e trago sugestões para o time, outras vezes, algum outro membro do time (um outro Staff ou dev senior) traz sugestões e eu os guio para encontrar a melhor alternativa.
Dependendo do tamanho do problema e do impacto que isso vai gerar, a elaboração de um system design pode levar dias ou semanas de discussão. Quando temos problemas diferentes dos habituais, é bem comum trabalharmos com experimentação/POC para testarmos o comportamento de algumas tecnologias no contexto que precisamos, antes da tomada de uma decisão
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?
Acredito que a principal soft-skill é a influência. As pessoas precisam acreditar que eu estou guiando o projeto para o melhor caminho, considerando o conjunto de variáveis que temos naquele momento. As vezes o melhor caminho é cortar uma parte do escopo, para entregar em um prazo que é interessante para o negócio. Em outras, o melhor caminho é escolher uma tecnologia que temos domínio, mesmo não sendo a mais adequada para o problema. Em alguns momentos, é necessário deixar um débito técnico para lidar no futuro.
A segunda mais importante, na minha opinião, é saber negociar. Eu trabalho com muitas áreas, cada uma delas tem suas próprias metas e seus objetivos, e é muito importante estar aberto para que a escolha seja a mais confortável para todos.
E a terceira é liderança. Eu preciso escalar o meu trabalho. Eu não posso ser o gargalo. Então, eu preciso orientar as pessoas, para que elas também tomem decisões pensando no futuro da empresa e na qualidade e resiliência dos produtos.
Você dedica tempo para mentorar as demais pessoas dos times?
Sim, eu preciso elevar a qualidade técnica das pessoas que trabalham próximas. As vezes, isso acontece formalmente através de 1:1s, criação de PDI, processo de avaliação. Outras vezes, de forma informal, explicando um conceito no meio de um refinamento ou em um code review, montando uma talk sobre um assunto que vai ser importante para o time conhecer.
Também faço um trabalho constante com outros staffs, orientando-os como estruturar um projeto, pensando em cronograma, alinhamento com os envolvidos e discussão dos trade-offs. Também tento conduzi-los a escolher as batalhas que vão lutar no sentido de priorização e a lidar com o trabalho em múltiplas iniciativas ao mesmo tempo.
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?
Foi uma progressão. Eu trabalho há bastante tempo com desenvolvimento e os últimos 9 anos foram em empresas de grande porte. Eu brinco que a maioria dos brasileiros já foi impactada direta ou indiretamente por um produto que eu trabalhei na construção.
Cada projeto que eu trabalhei foi importante pra desenvolver alguma habilidade na minha carreira. Lá no passado eu trabalhei em projetos que o arquiteto pensava na solução e a minha responsabilidade era transformar aquilo em código. Depois eu passei a atuar em todo o ciclo, desde a concepção até o deploy/manutenção. Tiveram projetos que eu precisei me dedicar muito a priorização das demandas, organização dos times, em outros minha atuação foi 100% arquitetural. Tiveram alguns projetos que eu precisei trabalhar com muitos times e saber negociar foi o fator primordial. Já precisei trabalhar com pessoas que não conhecem muito de tecnologia e precisei me adaptar a linguagem utilizada por essas pessoas para que conseguíssemos nos comunicar com eficiência e resolver os problemas.
Acredito que toda essa estrada me ajudou a estar na posição que estou hoje. Mas, além disso, deixar bem claro para minha gestão que eu tinha interesse em ir além, foi fator primordial. Eu fiquei bastante tempo como dev sênior, e a preparação para o próximo step só aconteceu foi quando eu falei: eu quero ir para o próximo nível, me diz o que eu preciso para chegar lá.
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?
Na verdade as pessoas que trabalhavam comigo, meus gestores e afins sempre me incentivaram a escolher o caminho da gestão. E eu tenho uma veia de gestão bem evidente.
No meu caso, eu tive a oportunidade de fazer um teste. Quando eu já estava atuando como Senior há alguns anos e já estava preparada ou quase para o próximo nível, a minha gestora pediu demissão e eu fiquei 5 meses fazendo praticamente todo o trabalho que ela fazia. No meu caso, eu não gostei muito. Por esse motivo eu resolvi tentar continuar como IC.
Minha decisão foi baseada no que eu estava disposta a deixar de lado. Tanto um gerente como um staff atuam com pessoas e com tecnologia. A grande diferença, na minha visão, está relacionada ao percentual de tempo que um gerente ou um staff dedica para cada uma das coisas. Um staff eu acredito que seja 70% tec e 30% gestão e para um manager, acho que esses valores se invertem. Hoje, eu prefiro passar a maior parte do meu tempo focada em problemas de tecnologia. Mas pode ser que algum dia eu mude de ideia.
Você lembra de algum conselho ou dica que recebeu quando entrou nesta posição e que foi importante para você?
Tem alguns que valem citar:
Eu fui desenvolvedora senior por 6 anos. É muito tempo. E isso aconteceu porque eu não fui em busca de uma promoção, eu deixei a vida me levar. Profissionalmente é bem ruim deixar que isso aconteça. Foi uma gestora que trabalhou comigo pouquíssimo tempo, que abriu meus olhos. Segundo ela, a minha atuação já era de um nível mais alto, que eu deveria ir em busca de uma promoção.
Saber identificar o nível que estamos e explicitar/lutar por ele é importante. Também é importante entender qual é o próximo passo. Normalmente nós temos gestores que nos ajudam a montar PDI, a traçar o caminho para o próximo level, mas eu particularmente gosto de agendar mentorias com pessoas que estão no próximo level, mas que não atuam na mesma área que eu. Essas pessoas te ajudam a chegar no próximo nível com orientações de uma perspectiva diferente da tua gestão imediata. Eu acho muito enriquecedor.
Quais fontes você usa para se especializar? Blogs, livros, canais do Youtube.
Para assuntos mais perenes eu prefiro livros, eu acredito que eles dão o embasamento necessário para auxílio na tomada de decisões. Tem alguns que eu recomendo muito: System Design Interview, Design Data-Intensive Application e Debugging Teams.
Gostei desta pergunta!
"Quais fontes você usa para se especializar? Blogs, livros, canais do Youtube."
Obrigado por compartilhar, muito enriquecedor.