Gerência em Tecnologia: Uma Mudança de Carreira, Não Apenas um Upgrade

A Bifurcação IC-Gerente: Mais que uma Promoção, uma Nova Profissão

Quando fui promovido a gerente de engenharia de uma equipe de médio porte na Clorox, pensei que tinha chegado ao topo. Mais dinheiro, mais ações, mais visibilidade e maior proximidade com a liderança sênior. Do lado de fora, e no papel, era claramente uma promoção. Eu ouvia frequentemente a frase: "Gerência não é promoção, é mudança de emprego". Descartei como um clichê de engenheiros tentando parecer sábios.

Acontece que ambas as coisas eram verdadeiras. Era uma promoção e, ao mesmo tempo, um trabalho completamente diferente. E eu estava longe de estar preparado para o que isso implicava.

A Revolução nas Prioridades

É surpreendente a pouca quantidade de treinamento oferecida a novos gerentes. Como engenheiros, somos altamente técnicos e acostumados a dominar sistemas complexos. Muitos de nós presumimos que gerenciar pessoas será mais fácil do que lidar com sistemas distribuídos. Ou assumimos que se trata apenas de "mais reuniões". Ambas as suposições estão erradas.

Sim, tive mais reuniões. Mas o que mudou fundamentalmente não foi minha agenda, foi a forma como meu impacto era medido. Como um contribuidor individual (IC), meu resultado era visível: código entregue, funcionalidades implementadas, bugs corrigidos. Como gerente, meu impacto tornou-se indireto, fluindo através de outras pessoas. Essa mudança foi desorientadora.

Acabei voltando à minha zona de conforto: comecei a escrever mais código, tentando ser o engenheiro mais forte da equipe. Parecia produtivo e mensurável. Foi um erro. Ao tentar ser o engenheiro número um, eu estava negligenciando meu trabalho real. Não estava apoiando os engenheiros seniores, não estava resolvendo problemas sistêmicos e não estava construindo planos de carreira. Estava competindo com aqueles que eu deveria capacitar. Gerenciar é sobre amplificação.

Redefinindo o Impacto: A Chave para o Sucesso Gerencial

O ponto de virada aconteceu quando comecei cada semana com uma pergunta simples: Qual é a única coisa mais impactante que posso fazer agora? Frequentemente, a resposta não era escrever código. Era redigir um documento que clareasse a direção, corrigir um processo quebrado com ponto único de falha, ou redistribuir responsabilidades para que o conhecimento não ficasse concentrado em uma única pessoa.

Comecei a me remover deliberadamente do trabalho de implementação, comprometendo-me a escrever quase nenhum código. Isso forçou a confiança e revelou lacunas no sistema que eu podia abordar no nível correto: através de coaching, documentação, contratação ou mudanças de processo.

Outra grande mudança foi levar as reuniões individuais (one-on-ones) a sério. Muitos engenheiros não gostam delas, achando-as constrangedoras ou apenas uma troca de status. Eu as agendava quinzenalmente, abordando-as com uma mistura de alinhamento tático e um check-in humano. Raramente começava com perguntas de engenharia. Em vez disso:

• Você está feliz com o trabalho que está fazendo?
• Você se sente desafiado ou estagnado?
• O que está te frustrando no momento?

O burnout não aparece em tickets do Jira, assim como o desengajamento silencioso. Essas conversas me ajudaram a antecipar rotatividade, redistribuir carga de trabalho e construir confiança. Dediquei mais tempo a pensar em planos de carreira. Estava oferecendo à minha equipe o tipo de trabalho que os ajudaria a crescer? Estava retendo projetos de alta visibilidade? Estava sendo claro sobre o que significava um impacto de nível sênior? Esse trabalho parecia menos tangível do que código, mas moveu a agulha muito mais.

Por Que Retornei à Posição de IC

No final, retornei à trilha de contribuidor individual. Parte foi prática: fui demitido do meu cargo de gerência e o mercado recompensava mais fortemente cargos de IC sênior na época. Mas, sendo honesto, a razão mais profunda era mais simples: eu amo escrever código.

Gosto de melhorar sistemas e ajudar pessoas, mas a parte do meu dia que mais me energizava ainda era construir. A gerência exigia abrir mão disso. Você não pode estar imerso em implementação técnica e profundamente focado em pessoas ao mesmo tempo. Algo tem que ceder.

Pessoalmente, não preciso subir na escada corporativa para me sentir bem-sucedido. E você também pode não precisar. Muitas organizações oferecem trilhas de liderança técnica que são verdadeiramente equivalentes à gerência em termos de faixas salariais. Engenheiros Staff e Principal direcionam a estratégia sem gerenciar pessoas.

Se você deseja permanecer profundamente técnico, pense muito cuidadosamente antes de migrar para a gestão de pessoas. Isso exige abrir mão do controle sobre a implementação e focar em alinhamento, crescimento e planejamento de longo prazo. Se você não se importa genuinamente com essas coisas, não apenas ficará infeliz, mas também tornará sua equipe infeliz.

Um Teste Simples Antes da Escolha

Antes de aceitar um cargo de gerência, pergunte-se:

• Eu me energizo resolvendo problemas de pessoas todos os dias?
• Estou confortável medindo o impacto indiretamente?
• Ficaria satisfeito se raramente escrevesse código de produção novamente?
• Eu busco alavancagem (leverage) ou ofício (craft)?

Não há resposta certa. A bifurcação IC/gerente não é sobre prestígio, mas sim sobre o tipo de trabalho que você quer que seus dias consistam. Escolha com base na sua energia, não no seu ego.

— Brian