Gui

Evoluindo como Engenheiro Sênior: Percepções e Reflexões

No ano passado, minha gerente me informou que ela e alguns colegas acreditavam que eu estava pronto para iniciar meu processo de promoção para Engenheiro Sênior. Na Datadog, nós nos esforçamos para evitar o Princípio de Peter, então as promoções só ocorrem quando todos os envolvidos no processo (diretores, EMs, colegas, etc.) concordam que você já está operando no próximo nível. Mas o que significa operar em um nível sênior?

Claro, a empresa tem suas próprias expectativas para cada nível na “escada” (por falta de um termo melhor, mas já discuti isso antes). Também pesquisei o que outras empresas esperam e comparei com o que engenheiros seniores que admiro fazem. Este post aborda aspectos do papel que não vejo mencionados com muita frequência. É uma coleção das minhas próprias observações.

Perguntando Mais Sobre o Porquê, Menos Sobre o Como

A primeira coisa que me vem à mente é que um Engenheiro Sênior opera com uma consciência maior do que antes. Para um engenheiro de produto (e isso também pode ser aplicado aos engenheiros de plataforma com algumas adaptações), isso significa relacionar aspectos técnicos a aspectos não técnicos, como metas de negócios e abordagens centradas no usuário. Inicialmente, a prioridade de um engenheiro sênior é entender por que um determinado recurso está sendo solicitado e seu contexto.

Isso envolve ganhar um nível mais profundo de compreensão, possivelmente desafiando suposições, revisando os principais casos extremos ou pedindo mais dados. Somente com uma boa compreensão do “porquê” eles começam a pensar sobre o “como”, “onde”, “quando” e “qual”. Como eles resolveriam o problema? Onde podem surgir desafios de desempenho? Quais outros aspectos eles devem cobrir, como documentação, manutenção e testes?

Entender quando parar também é crucial—saber quando eles alcançaram 80% do valor do recurso. Esta última parte, entender quando está tudo bem parar, aumenta significativamente seu impacto.

Impacto vs. Esforço

Vejo uma corrida para entregar tickets menores. Em si, isso não é uma coisa ruim se você entender quando essa técnica é necessária para produzir o maior impacto. Por exemplo, faz sentido quando você quer fechar o maior número possível de lacunas dentro de um período de tempo definido antes de um lançamento. No entanto, se você se concentrar principalmente em tickets menores, perderá oportunidades de mostrar um trabalho mais profundo.

O trabalho mais profundo envolve pesquisar soluções para problemas complexos, adquirir mais dados por meio de métricas ou experimentar o que outros no setor estão fazendo. Você pode rapidamente ficar super ocupado com tickets menores e se sentir sobrecarregado. Há uma distinção entre fazer mais e fazer extra. Assim como você não deve começar a codificar algo antes de entender completamente o problema, tire um tempo durante a semana para refletir sobre seu equilíbrio entre impacto/esforço.

A ciência envolve observar e tirar conclusões. Tirar um tempo para avaliar onde seus esforços são mais bem gastos pode melhorar significativamente suas contribuições e evitar o burnout.

Desenvolvendo uma Opinião

Como aqueles líderes de pensamento na indústria, desenvolva uma habilidade aguçada para observar a dinâmica da equipe e identificar gargalos. Se você está precisando de uma clareza do produto ou design, sinalize isso, mas também compartilhe algumas alternativas potenciais. Fique atento à inovação e aos insights, conectando ideias distintas para trazer novas perspectivas para a equipe.

Defina metas claras para o que você espera das reuniões e dos documentos. Lembre-se, sua carreira é guiada por você, não apenas por seu gerente. Prepare suas agendas 1:1 com antecedência e não foque apenas em si mesmo—discuta a equipe e a direção do produto também.

Forneça feedback aos seus colegas com foco em alcançar o maior impacto enquanto reduz o esforço. Em resumo, seu valor cresce além das funcionalidades que você entrega ao contribuir para o crescimento e a eficiência geral da equipe e do produto.

Estou Fazendo Tudo Isso? Talvez…

Este é o meu padrão de conduta. Semelhante a um sistema PID, às vezes nos desviamos, mas a chave é a capacidade de auto-correção. Tento não cair na falácia de “já sei tudo”. Quanto mais aprendo, mais percebo o quanto não sei.

Enquanto isso, continuo refletindo e me esforçando para crescer. Essa autoavaliação contínua ajuda a me manter com os pés no chão e aberto a novos conhecimentos e melhorias.

Sobre mim Author

Meu nome é

Guilherme Schwade

Engenharia de software é muito mais que código. Ler mais

Artigos relacionados