Em novembro de 2020, topei o desafio de assumir o papel de Principal Software Engineer. Porém, eu não tinha noção das responsabilidades que eu teria e o impacto que o meu trabalho traria para a organização, para meus colegas e para mim. De lá para cá, tem sido uma jornada de descobertas, adaptações e um processo de melhoria contínua sobre as minhas responsabilidades e o meu modo de enxergar as coisas. Tem sido um processo super desafiador, e vou compartilhá-lo com vocês.

O Início

Antes de ocupar o novo cargo, pesquisei muito e conversei com algumas pessoas sobre o que elas conheciam em relação ao perfil/papel de um Principal Software Engineer. Para resumir a resposta, entendi que tudo depende. Muitas empresas tratam o papel como chefe de alguma área, precisando gerenciar pessoas. Já outras, usam essa nomenclatura para Arquitetos de Software. Também, há as que usem o papel do Principal apenas para criar um path de carreira para o time de Tecnologia e para reter talentos.

Na minha opinião, todos eles fazem sentido, por isso decidi estruturar a visão que mais se adequa à minha realidade. O processo de construção é contínuo, tem exigido de mim derrubar muitas crenças e vícios que eu carrego.

Mudança na forma de pensar

A primeira mudança foi entender que o Principal Software Engineer (PE) é um contribuidor individual. E o que isso quer dizer? No meu caso, eu gosto de traduzir assim: atuar em vários lugares e não pertencer a nenhum deles. Parece algo solitário, pelo menos eu enxergava assim, até entender que a palavra pertencer tinha um escopo deturpado se tratando da minha atuação.

Seu trabalho agora não é ser o produtor de valor, é ser o multiplicador de força que ajuda todos ao seu redor a entregarem produtos melhores e mais sustentáveis. E não é um trabalho que você possa medir em pontos ou sprints. É um trabalho com trimestres e até anos de ROI. Silvia Botros

Entendi que pertenço a vários times de outra forma. Posso não estar no dia a dia, participando das dailies ou fazendo pair programming a todo momento, mas percebi que as pessoas confiavam em mim. Isso me fez entender que deixei de ser um “resolvedor de tarefas” e passei a ser um multiplicador de forças, explorando oportunidades e auxiliando as pessoas a atacarem coisas que elas não conseguiam por várias razões.

Conflitos

Um Principal Engineer verdadeiramente valioso torna toda a sua equipe melhor, defendendo as melhores práticas, lembrando as pessoas dos motivos pelos quais os processos existem e ajudando as pessoas engenheiras menos experientes a encontrarem maneiras de “subir de nível”. Um bom PE pode falar sobre aspectos técnicos do produto, conectar o trabalho planejado à estratégia de negócios e ao que torna a empresa mais bem-sucedida e, talvez o mais importante, ter as habilidades interpessoais para influenciar outras pessoas ao seu redor em direção a esses objetivos. On Being A Principal Engineer

Minhas habilidades de influenciar pessoas nunca foram tão testadas quanto agora e já falhei em algumas ocasiões. Mesmo ocupando um papel técnico, não gerencio ninguém diretamente, passo a maior parte do tempo me comunicando com as pessoas, fazendo 1:1, debatendo possíveis soluções arquiteturais, montando estratégias a serem implementadas ou entrando em salas de guerra para apagar incêndios.

Isso exige um poder de comunicação cada vez melhor e é um dos pontos em que mais tenho focado para evoluir. Como os temas que preciso atacar impactam muitas pessoas, é natural que parte delas tenham alguma resistência e isso acaba gerando conflitos. Um livro que tem me ajudado nesse processo é o Crucial Conversations.

Monotonia nunca mais?

Como um contribuidor individual, não tenho um direcionamento de “faça isso ou aquilo”. Um dia normal de trabalho, troco de contexto várias vezes. Atuo muito próximo ao time de Cloud e ao mesmo tempo estou envolvido em problemas de escalabilidade de um sistema específico. Além disso, preciso estar alinhado com a liderança, pois mudanças nos times podem impactar o meu planejamento de médio e longo prazos.

Dedico uma parte considerável do meu tempo à pesquisa e testando conceitos em pocs. Devido a atuação em contextos diferentes, preciso me atualizar constantemente para conseguir auxiliar os times em diferentes problemas. Por exemplo, descobrir porque a CPU da máquina está com load alto, analisar código em uma linguagem de programação que não tenho domínio ou verificar por que os custos de uma ferramenta subiram no último mês.

Participar desses contextos de forma dinâmica exigiu outra mudança importante. Escrever código para produção é uma das minhas paixões. Porém, hoje não consigo focar por longos períodos para produzir algo devido a dinamicidade do contexto em que vivo. Isso me frustrou muito no começo. Com o tempo, fui construindo uma visão de que é mais importante identificar uma oportunidade, iniciar o debate sobre ela e me juntar a algum time para auxiliar a desenvolver essa ideia pensando em plataforma para a empresa.

Resumo

Como falei, o processo de definir como eu atuo como Principal é contínuo. Tem sido um desafio prazeroso, pois eu preciso derrubar barreiras que carrego. Abaixo, deixo um resumo de algumas reflexões sobre minha atuação como Principal Software Engineer:

  • Enfrentar desafios técnicos que abrangem vários sistemas técnicos e organizacionais;
  • Fazer um trabalho exploratório, identificando os problemas que poderiam ser trabalhados em curto prazo;
  • Desenvolver protótipos para explorar e apoiar ainda mais as ideias que vêm dessa pesquisa;
  • Auxiliar os times a atacarem problemas e ajudar a construir algo mais resiliente;
  • Criar estratégias, escrever propostas e lançá-las em toda a empresa. Exemplo, novos modelos arquiteturais e/ou abordagens de comunicação;
  • Estar em contatos com várias áreas da empresa, a fim de conhecer os desafios e oportunidades;
  • Ser voz para a mudança, às vezes sendo a voz para não mudar. Sempre pesando as compensações, sempre ouvindo.
  • Ser ligeiramente independente da cadência normal do trabalho da Engenharia.
  • Ter pouca orientação ou supervisão. Possivelmente estando um tanto isolado. Estar bem com isso.
  • Usar essa posição de independência e poder para apoiar e influenciar outros desafios legais / difíceis / interessantes na organização.
  • Não ter medo: questionar o status quo, recusar decisões que julgue serem prejudiciais ou enfrentar desafios em território desconhecido.
  • Incentivar a participação das pessoas de Tecnologia em eventos que auxiliem na disseminação de conhecimentos;
  • Entender a estratégia da empresa e conectá-la à realidade, preparando a arquitetura para desafios.

Se curtiu este post não deixe de compartilhar! 😉

Abraços e até a próxima.