1 pontos por GN⁺ 2024-02-19 | 1 comentários | Compartilhar no WhatsApp
  • Depois de trabalhar 7 anos como desenvolvedor front-end, ao me tornar team lead e depois engineering manager em tempo integral, meu impacto sobre o produto e a equipe aumentou, mas a natureza do trabalho mudou bastante
  • Um gerente pode intervir, com autoridade formal e informal, em problemas que eram difíceis de mudar quando eu era IC, como escrever testes, melhorar processos e ajustar o clima da equipe
  • No longo prazo da carreira, a função oferece remuneração mais alta do que cargos gerais de engenharia, oportunidades mais amplas do que posições staff+ IC e habilidades transferíveis que facilitam migrar para outras áreas técnicas, gestão de projetos, gestão de produto ou empreendedorismo
  • Por outro lado, é preciso executar procedimentos corporativos como avaliação de desempenho, prazos absurdos e políticas organizacionais, além de assumir diretamente conflitos, insegurança psicológica e a pressão de estar sempre disponível
  • No trabalho de gestão, é difícil ver resultados em menos de um mês, e até mudanças corretas — como dividir equipes ou contratar — podem piorar a situação no curto prazo, exigindo resistência a ciclos longos de feedback

Como aconteceu a transição de engenheiro para gerente

  • Há cerca de 2 anos, migrei para team lead e, depois da expansão da equipe, me tornei engineering manager em tempo integral
  • Antes disso, trabalhei 7 anos como desenvolvedor front-end e, no início, havia escolhido a trilha de carreira de contribuidor individual (IC) sênior antes de migrar para gestão
  • A transição teve altos e baixos, mas foi interessante, e no meu trabalho atual há coisas de que gosto e coisas de que não gosto

O que eu gosto no papel de gerente

  • Autoridade para mudar o produto e a equipe

    • Ao se tornar gerente, você ganha autoridade para melhorar o estado geral do produto e da equipe
    • Quando você é IC, pode ser difícil mudar problemas como daily muito cedo, baixa qualidade de código ou novas funcionalidades difíceis de entender
    • Um EM pode usar autoridade formal e informal para ajustar a forma como a equipe — e ele mesmo — trabalha para melhor
    • A mesma frase, “precisamos escrever testes”, tem um peso diferente quando dita por um IC e quando dita por um EM, e a fala do EM pode de fato resultar na escrita de testes
  • Oportunidades de carreira mais amplas

    • O cargo de engineering manager oferece oportunidades de carreira mais amplas do que a trilha tradicional de engenharia
    • Um EM normalmente recebe mais do que cargos de engenharia em unidades básicas de equipe, como junior, middle e senior
    • Também existem cargos IC mais altos, como staff e principal, com faixas salariais equivalentes ou superiores às de EM
    • Mas, enquanto vagas staff+ IC tendem a se concentrar em grandes empresas de tecnologia com desafios técnicos mais difíceis, quase toda equipe de software em qualquer empresa tem posições de liderança
    • A escada de carreira em gestão vai mais longe do que a de IC
    • Mesmo que a chance de se tornar CTO seja baixa, isso abre opções que um IC puro sem experiência de gestão não tem
    • A demanda por EM é mais estável do que a demanda por engenheiros staff+ e oferece mais oportunidades nas fases mais avançadas da carreira
  • Habilidades fáceis de levar para outras áreas

    • Habilidades de gestão têm aplicação mais ampla do que um papel específico de engenharia como IC
    • Um engenheiro front-end com experiência em React pode migrar para outro framework front-end ou mudar para back-end ou mobile, aceitando talvez uma pequena perda de senioridade
    • Com experiência como engineering manager, fica mais fácil assumir equipes com focos diferentes, como um time de desenvolvedores mobile, de infraestrutura ou de engenheiros de ML
    • Ainda leva tempo para entender as grandes dificuldades técnicas do novo time, mas muitas empresas aceitam esse tipo de transição
    • Se você não quiser continuar como EM, fica em uma boa posição para migrar para gestão de projetos ou gestão de produto
    • Mesmo se o mercado de tecnologia como um todo estiver em baixa, muitas habilidades de gestão continuam valendo em outros setores
    • A experiência de lidar com pessoas e decisões de negócio também é útil como preparação para empreender
  • O conhecimento envelhece mais devagar

    • Se acompanhar os frameworks e ferramentas front-end mais recentes já te causa cansaço, um papel de gestão pode aliviar esse peso
    • As metodologias “novas” de agile, kanban e scrum são conceitos com 20 ou 30 anos, e tipos básicos de reunião como demo, daily e 1:1 evoluíram ao longo de muito tempo
    • No centro da gestão estão trabalho em equipe e interação humana, e isso não mudou tanto desde o começo da humanidade
    • Ainda é preciso observar as mudanças tecnológicas, mas com menos urgência para mergulhar fundo nelas
  • Novos desafios fora dos problemas técnicos habituais

    • Depois de 4 ou 5 anos trabalhando em uma área técnica específica, você consegue resolver a maior parte dos problemas práticos com competência suficiente
    • Há limites para como um engenheiro experiente pode buscar desafios maiores
    • Mudar um pouco a stack, como adotar um novo framework front-end, dificilmente mantém o interesse por muito tempo
    • Uma transição maior, como sair de front-end para back-end, pode render alguns anos interessantes, mas costuma acontecer por acaso ou pode afetar a remuneração
    • Criar problemas artificiais, como reescrever tudo com uma nova biblioteca ou tentar suportar 9000 RPS “pensando no futuro”, pode até ser divertido, mas muitas vezes prejudica a equipe e o negócio
    • Para um engenheiro experiente, migrar para gestão oferece a maior quantidade de coisas novas para aprender sem reduzir a remuneração

O que eu não gosto no papel de gerente

  • Ter de executar procedimentos corporativos

    • Quando eu era engenheiro, odiava baboseira corporativa como avaliação individual de desempenho, prazos inúteis e restrições impostas pela empresa a processos e stacks tecnológicos
    • Ao se tornar gerente, você vira a pessoa que executa essas práticas, acreditando nelas ou não
    • Em organizações com calibragem de desempenho, a liderança da equipe precisa indicar, a cada 6 meses, uma pessoa que não tenha trabalhado duro o suficiente
    • Se você não entregar alguém da equipe para ser sacrificado, existe a chance de alguém ser escolhido aleatoriamente depois, o que dificulta eliminar o processo
    • Alguns procedimentos podem ser negociados ou contornados; por exemplo, dá para distribuir a classificação de “abaixo do esperado” em esquema de rodízio
    • Do ponto de vista da equipe, o gerente às vezes pode parecer um monstro corporativo
    • Ainda não passei por situações mais difíceis, como demissões, fechamento ou reorganização
  • Ter de lidar com tensões entre pessoas

    • O ponto de partida para virar engineering manager foi a capacidade de construir bem alguma coisa, e eu imaginava que passaria meu tempo apoiando decisões técnicas, dando orientação de carreira, ajustando processos e criando automações
    • Na prática, grande parte do trabalho é debugar tensões sociais e inseguranças psicológicas das pessoas
    • Exemplos:
      • Um engenheiro júnior comentou alguns testes para conseguir publicar uma prévia de funcionalidade
      • A pessoa de QA ficou furiosa porque sentiu que a equipe não respeitava o papel nem o valor do QA
      • O gerente precisa restaurar a confiança
    • Outro exemplo:
      • Um project manager fez uma piada sem graça, e uma designer se sentiu ofendida e começou a chorar
      • O gerente precisa fazer o PM pedir desculpas
    • Como não sou psicólogo e também não sou especialmente bom com pessoas, essa parte é difícil e parece mais um processo de aguentar até se acostumar
  • Uma estrutura de trabalho em que é difícil ficar offline

    • A vida de um engenheiro pode ser relativamente tranquila
    • Se não houver nada urgente, dá para passar meio dia fora pensando no futuro do projeto, e até faltar de repente a algumas reuniões sem grandes consequências
    • Se um EM fica fora por algumas horas, os problemas se acumulam no mensageiro
      • Um estagiário esqueceu como usar npm install e não consegue trabalhar
      • Um gerente sênior quer discutir uma funcionalidade em potencial
      • O release deu errado
    • Reuniões que você conduz ou precisa organizar são difíceis de pular sem preparação prévia
    • Isso pode melhorar quando a equipe amadurece e os processos ficam melhores, mas, em geral, o gerente sente muito mais o peso de horário de atendimento
    • O equilíbrio entre vida e trabalho passa a depender diretamente da sua capacidade de executar bem o próprio trabalho
  • O ciclo de feedback é longo e não linear

    • A maior parte do trabalho de engenharia mostra resultados relativamente rápido
    • Uma nova funcionalidade traz resultados em algumas semanas ou meses, e, se você corrige um bug, pode ver a reação dos usuários no dia seguinte
    • Em refatoração, muitas vezes dá para perceber a redução de complexidade em poucas horas
    • Ações de um gerente raramente produzem resultados visíveis em menos de um mês
    • Se a equipe ficou grande demais e precisa ser dividida, isso exige várias etapas
      • Definir uma composição adequada de engenheiros para a nova equipe
      • Conversar com as pessoas envolvidas sobre os sentimentos em relação à mudança
      • Criar novas reuniões recorrentes
      • Configurar processos e comunicação
      • Resolver o trabalho relacionado ao Jira
      • Em alguns casos, separar a base de código de um subproduto
    • Se você acha que consegue concluir isso em uma semana, está enganado
    • Até mudanças corretas podem piorar antes de melhorar
    • Se você decide contratar porque falta gente, no curto prazo o resultado é gastar muito tempo em entrevistas, e a nova pessoa não ganha velocidade de imediato, pois precisa de onboarding
    • Mudanças de gestão se parecem mais com uma refatoração em larga escala do que com resolução rápida de problemas, e pode ser frustrante não ver melhoria imediata

Para engenheiros pensando nessa transição

  • Sair de IC e ir para gestão é uma experiência de montanha-russa, com lado bom e lado ruim
  • As vantagens são ter um impacto mais amplo sobre o produto e a equipe, contar com mais oportunidades e flexibilidade como trilha de carreira de longo prazo e ganhar novos desafios quando a área técnica começa a parecer monótona
  • As desvantagens são executar políticas corporativas, lidar com tensões sociais e inseguranças psicológicas, trabalhar em uma estrutura em que é difícil ficar offline e conviver com satisfação muito atrasada e ciclos longos de feedback
  • Se você gosta de desafio e responsabilidade e tiver a oportunidade, vale a pena tentar
  • Gestão não é para todo mundo, mas pode ser uma experiência que amplia seu repertório técnico e faz você enxergar o trabalho de engenharia por outro ângulo
  • Se não combinar totalmente com você, ainda haverá tempo de sobra para voltar a programar

1 comentários

 
GN⁺ 2024-02-19
Comentários do Hacker News
  • Já fui gerente quatro vezes, incluindo duas em empresas FAANG, mas discordo de muita coisa no texto original.
    A carreira de gerente não é, na prática, necessariamente mais alta; a maioria dos gerentes de engenharia se concentra no equivalente a L6/engenheiro staff. Promoções para gerente sênior ou acima dependem muito do contexto e são raras, enquanto colegas na trilha de engenharia, quando estão prontos, são promovidos sem ter que esperar os astros se alinharem.
    Pessoas que ficaram como gerentes de engenharia puros e foram demitidas muitas vezes ainda estão procurando emprego e quase desistindo, mas quem aceita voltar a ser IC não costuma ter grandes problemas para se recolocar. A cultura de gestão varia muito de empresa para empresa e é difícil de transferir diretamente; a meu ver, a habilidade mais transferível deste setor é a estrutura interna do Linux.
    Também acho estranha a ideia de que, com 5 anos de experiência, dá para resolver a maioria dos problemas. Mesmo trabalhando há 18 anos, ainda há muita coisa que não sei e muitos pontos em que preciso melhorar, e engenheiros excelentes com 40 anos de experiência continuam aprendendo.
    A melhor parte de ser gerente é passar bastante tempo pensando no futuro e aumentar a chance de entrar “naquela sala” onde se conversa com o C-level. Ao mesmo tempo, isso também é a pior parte, porque você passa a enxergar de perto demais como as decisões são tomadas.
    Concordo com as partes de que o texto original não gostou, mas elas melhoram com o tempo. Dito isso, se você é um gerente novo, talvez ainda não tenha passado pelo ponto de que mais vai detestar: em muitas empresas, a alta gestão se comporta como panelinhas de ensino médio, e problemas de comportamento de VPs, C-level e às vezes diretores são tolerados mesmo quando seriam motivo de demissão se viessem de um funcionário comum.

    • A afirmação de que “colegas na trilha de engenharia são promovidos quando estão prontos” soa como uma anedota com uma mistura de viés de confirmação e viés de sobrevivência.
      A maioria dos engenheiros de software fica travada no nível sênior, especialmente no Google, então o próprio fato de haver uma concentração no L6 já é relativamente privilegiado. Promoção para L6 não é extremamente rara, mas também não é algo que a maioria receba; L7 ou acima é difícil. Se você sente que a maioria dos seus colegas chega lá naturalmente, talvez esteja desconsiderando quem saiu por não conseguir promoção, ou talvez tenha tido poucas oportunidades de se aproximar de pessoas em níveis abaixo do seu.
      Concordo que a trilha de gerente de engenharia não abre tantas portas quanto as pessoas costumavam imaginar, mas as oportunidades de promoção não parecem mais estreitas do que as de IC.
    • Também achei estranho o texto original ver gerente de engenharia como um bom caminho para virar fundador.
      Construir algo do 0 ao 1 tem pouquíssima relação com gestão de engenharia. As habilidades mais importantes são programar rápido e conversar com potenciais clientes com naturalidade, e nenhuma das duas está diretamente ligada ao papel de gerente de engenharia. Também não há garantia de que você vá contratar pessoas para gerenciar.
      Cargos de gestão são estruturalmente muito menos numerosos do que funções de engenharia, e a fronteira entre engenheiro líder e gerente de primeira linha é bastante difusa nos dois sentidos, então o pool real de concorrência não fica tão menor assim.
    • Nunca trabalhei em big tech e nunca trabalhei com ICs acima do nível staff. Imagino que promoções a principal ou fellow também sejam bem raras, e a maioria das empresas “comuns” nem sequer tem esses níveis.
      Quando digo que algo é transferível, quero dizer uma habilidade útil também fora da bolha das big techs. O dinheiro pode ser bom a ponto de você não querer sair, mas é bom saber que há coisas que você pode fazer além de mexer com computadores apitando.
    • Que bom saber que não sou o único que sente que a estrutura interna do Linux é a habilidade mais transferível.
    • O ponto em que minha experiência divergiu do texto original talvez tenha mais a ver com as características do lugar onde a pessoa trabalha do que com uma diferença essencial entre os papéis.
      Por exemplo, a ideia de que uma fala como “precisamos testar mais” é levada mais a sério quando vem de um gerente de engenharia do que de um IC.
      Na verdade, quando eu tinha acabado de ser promovido a IC de nível staff, também sentia que me faltava credibilidade e cheguei a pensar em migrar para gestão porque me esconder atrás do cargo ajudaria. Na prática, isso não era necessário; hoje, como IC em outra empresa, minhas ideias e feedbacks são levados a sério tanto no nível organizacional quanto pelos colegas.
      Um sistema que, a cada semestre, força um ranking para identificar os funcionários de baixo desempenho é quebrado. É uma realidade triste que a gestão de desempenho funcione assim em muitos lugares, mas não é uma verdade universal de que, como gerente, você necessariamente precise fazer isso. Conversas difíceis sobre problemas reais de desempenho são estatisticamente inevitáveis, mas há empresas em que você não precisa ter conversas como “neste semestre, todos da equipe tiveram desempenho melhor que o seu” ou “alguém precisava ser escolhido, e desta vez sobrou para você”.
  • Eu gosto de resolver problemas e enxergar o panorama geral, e gosto de encontrar soluções para remover obstáculos. O papel que mais combinou comigo foi o de “arquiteto”, mas parece ser um cargo que está sumindo como título. Ainda assim, isso não muda o fato de que esse trabalho continua sendo necessário.
    Também já atuei como líder/gerente de equipe, Scrum Master e gerente de produto, e as habilidades necessárias para um bom gerente são muito diferentes das de um engenheiro. O ponto central é ter neuroticismo extremamente baixo, ou seja, a capacidade de tomar boas decisões sob estresse prolongado e manter uma aparência calma e racional.
    90% dos gerentes de nível inferior não têm essa característica e, quando ficam estressados, acabam prejudicando a equipe e a empresa. Se você quer virar gerente, precisa avaliar honestamente como reage a um estresse duradouro. Coisas que parecem entediantes, como se você desconta a raiva nas pessoas ao redor, se se esconde ou congela e não consegue decidir, ou se culpa os outros para proteger sua própria reputação, são as diferenças reais entre gerentes eficazes e o restante.

    • Este resumo é muito bom. É por isso que gestão parece um pouco com criar filhos. Um bom gerente precisa conseguir fazer o papel de adulto.
      Normalmente isso inclui o trabalho nada divertido de trazer à tona problemas que todos evitam, deixar as pessoas reclamarem em grupo das minhas decisões e continuar envolvido mesmo quando a outra pessoa se desconecta e afasta.
      Para mim, gestão parecia algo que exigia todas as colheres que eu tinha e ainda pedia mais. Mas acho que isso tem mais a ver com adequação a mim do que com a essência da gestão. Pelos padrões de testes da internet, meu neuroticismo é médio, mas sou ruim em parar no “bom o suficiente”, e sinto que o escopo ampliado de responsabilidade da gestão cria um problema de escalabilidade emocional.
    • Os gerentes mais eficazes com quem trabalhei vinham de países calmos e de baixo estresse, com culturas de trabalho parecidas.
      Talvez a chave para resolver crunch e burnout seja criar um ambiente regulatório em que toda a subsistência do trabalhador — saúde, aluguel, pagamento de empréstimos estudantis de universidades públicas etc. — não dependa exclusivamente de manter um emprego.
    • Pela minha experiência, a maioria das “pessoas que enxergam o panorama geral” só fala sem entender o significado do que está dizendo, as consequências, como executar, ou por que aquilo é uma má ideia.
    • Eu também sou um resolvedor de problemas generalista parecido e cheguei à mesma conclusão depois de gerenciar por pouco mais de um ano. A habilidade central é resiliência ao estresse.
      Como IC, você pode desenvolver a carreira aprendendo novas tecnologias ou domínios, mas, como gerente, o desenvolvimento de carreira passa a depender cada vez mais de crescimento pessoal, como maturidade, perspectiva e resiliência emocional. Talvez seja por isso que senioridade e interesse por coisas como meditação mindfulness tendem a crescer juntos.
      O HN vai odiar isso, mas, embora eu também seja solteiro, fico me perguntando se pais não acabam se tornando gerentes melhores. Talvez por serem menos propensos a perder a perspectiva e se estressar com coisas que não importam no panorama geral. Curiosamente, parece que a gente gerencia melhor quando consegue dar um passo emocional para trás.
      Descobri que, por temperamento, sou bastante sensível, e isso me faz pessoalmente temer se não sou constitucionalmente inadequado para cargos de gestão. Também é difícil lidar com o caráter às vezes hipócrita de ideias como “não é controlar, é motivar”. Eu só queria circular pela organização corrigindo problemas, simplificando processos e redesenhando sistemas de trabalho.
  • Estou há 12 anos como engenheiro de software e não tenho nenhuma vontade de virar gerente. Eu só quero construir coisas, não gerenciar.
    Trabalho de perto com gerentes e vejo como é o trabalho, mas não acho nem um pouco atraente. Como engenheiro sênior, minha opinião também costuma ter influência, mas gosto de não ter a enorme responsabilidade que recai sobre um gerente. Não quero aumentar o estresse na minha vida.
    Provavelmente passarei os próximos 30 anos de carreira na mesma posição em que estou hoje.

    • O quanto a opinião de um engenheiro sênior é levada a sério depende muito da gestão. Sua situação pode ser boa agora, mas isso pode mudar.
      Alguns anos atrás eu estava em uma situação parecida. Meu chefe gostava de mim e tinha muitos contatos, compartilhava todas as informações, me colocava nas reuniões de decisão, pedia minha opinião sobre a direção e dizia que, se necessário, me apoiaria nos bastidores caso eu falasse em nome dele ou de outros gerentes.
      Agora entrou uma estrutura de gestão totalmente nova, muito top-down, com ego forte e pouca disposição para receber feedback. Gerentes de nível mais baixo ou engenheiros que se manifestavam foram sendo continuamente afastados, e a autonomia e a voz que eu tinha praticamente desapareceram.
      Até muitas coisas que eu considerava decisões de engenharia foram tiradas de mim. Eu precisava de X para o serviço que estava construindo, então criei uma solução automatizada que funcionava bem. Alguns meses depois me disseram que eu tinha feito errado, porque havia outros planos para X, e mandaram apagar a solução totalmente automatizada e substituí-la por um processo corporativo manual de outra equipe. Esse trabalho falha com frequência, reduzindo a confiabilidade do meu serviço.
      Fico feliz por não ser o gerente que precisa brigar com essas pessoas. Se fosse, provavelmente já teria perdido o emprego e sido substituído por um amigo deles. Ainda assim, a influência de um engenheiro sênior pode variar muito no longo prazo, mesmo dentro da mesma empresa e equipe.
    • Gerentes também constroem coisas. A ferramenta deles apenas são os engenheiros.
    • Engenheiro sênior é uma posição relativamente baixa. Em algum momento você pode se cansar do salário estagnado e de continuar recebendo ordens.
      Existem cargos técnicos mais altos com nenhuma responsabilidade de gestão, ou muito pouca. Engenheiro sênior principal, arquiteto etc.; depende de quanto a empresa valoriza você.
      O melhor exemplo que vi foi o de um engenheiro com doutorado e décadas de experiência que trabalhava como guru de pesquisa/arquitetura, sem equipe nem subordinados diretos, usando muito Matlab, e que era “VP of technology” em uma empresa de algumas centenas de pessoas.
    • Fui gerente da nossa equipe por 6 meses e, no fim, não foi tão ruim assim, mas é um trabalho completamente diferente. Volto a ser IC no mês que vem, e essa provavelmente foi a primeira e última experiência de gestão da minha carreira de 15 anos.
    • A melhor conclusão não é “nunca vire gerente”, mas algo mais próximo de não virar um gerente corporativo que administra a visão dos outros.
      O difícil não é só o aprendizado em si nem apenas as pessoas, mas todo o contexto ao redor. Ter uma perspectiva de gestão ajuda muito a entender o que está sendo construído e por quê, e por que o trabalho parece ineficiente e quebrado. Também traz insights sobre soluções e sobre o contexto que não é comunicado adequadamente.
  • Atualmente sou desenvolvedor sênior e estou participando de entrevistas para uma posição de líder de equipe em uma startup. Acho que tenho alta competência técnica, mas o que mais me frustra no dia a dia são problemas relacionados ao trabalho em equipe
    Falta de confiança, membros da equipe que não querem conversar entre si, outros sêniors que entregam trabalho abaixo do esperado e deixam passar, ausência de um propósito claro para o time e de uma visão de produto, e falta de consenso sobre práticas comuns de engenharia. Ao virar gestor de pessoas, para o bem ou para o mal, esses problemas passam a estar dentro do escopo em que devo exercer influência e pelo qual devo me responsabilizar

    • Faz sentido para mim, porque muitos dos problemas que vivi em equipes anteriores poderiam ter sido resolvidos com gestão
      Mas, quando virei líder de equipe de fato, descobri que o alcance em que eu conseguia exercer influência era muito menor do que imaginava. Há muita gente, incluindo meu chefe, que quer operar tudo diretamente, e esperam de mim apenas o carimbo de aprovação
      Acabo ficando ainda mais em apuros, porque preciso levantar em nome da equipe assuntos sobre os quais as pessoas têm medo de falar. Por exemplo: “para uma história estar pronta, a API precisa estar definida”. Como o QA pode criar testes automatizados em paralelo se nem sabe o que precisa ser testado?
      Scrum Masters, Product Owners, gerentes e arquitetos dizem, a cada dia, o que lhes convém como se fosse uma verdade evidente e, no dia seguinte, reclamam de por que os testes atrasaram
      No fim, tudo entra na política de quem é responsável pelo estado atual, e as pessoas que escolheram essa direção e essa estratégia têm bons contatos e sabem muito bem transferir a culpa
    • As pessoas realmente têm dificuldade de conversar umas com as outras. No fim, talvez seja preciso até usar joguinhos de jardim de infância para fazer esse tipo de coisa acontecer
    • Fico curioso para saber como você acha que esses problemas passariam mais para dentro da sua esfera de influência
  • Certa vez, eu estava no escritório quando meu chefe da época terminou com sucesso uma ligação pedindo algo a alguém de outro departamento
    Ele olhou para mim da mesa, deu um leve sorriso e disse, em tom intrigado: “Não é como se eu tivesse ficado mais bonito só porque meu cargo mudou de ‘Specialist’ para ‘Manager’, mas isso com certeza ajuda a fazer as coisas acontecerem”. Foi um momento em que o poder do cargo realmente funcionou

    • Dizer “vocês realmente precisam escrever testes” é ótimo, mas, para uma equipe que já tem falta de pessoal e tecnologia insuficiente, é só colocar mais uma tarefa em cima de um roadmap que já deveria ter sido concluído ontem
    • No meu caso, como IC sênior da equipe, é o gerente que me pede para levantar certos assuntos com o time. Porque as pessoas da equipe de fato me escutam
      O gerente pode ser facilmente ignorado se não ameaçar uma consequência real, e esse tipo de carta precisa ser usado com parcimônia
  • Comecei como gerente de engenharia há alguns anos, como CTO de uma pequena startup, e minha vida mudou bastante. Sinto o mesmo em relação a todos os pontos que o texto original diz amar e odiar
    Um conselho adicional é: medite de verdade. Antes de tomar decisões importantes e influentes que podem prejudicar pessoas, você precisa se sentar em silêncio por tempo suficiente para que o cérebro desligue
    No começo, vira uma espécie de relação genial de pai/mãe e filho. Você precisa aceitar as pessoas e entender o jeito delas. Quanto mais controle você impõe, menos controle real tem. As pessoas vão tentar contornar e reagir contra burocracias desnecessárias e, sinceramente, eu também faria isso
    O segundo conselho é sempre agir como alguém que vai embora amanhã. Assim, sua equipe e seus colegas ficam preparados, e seu próprio estilo de vida também melhora

    • De forma parecida, minha técnica definitiva de gestão é tirar férias e fazer meus subordinados assumirem meu papel. Deixo pelo menos 2 semanas com eles
      Eles crescem muito rápido, e é estranhamente reconfortante confirmar que a organização funciona sem mim. Ao mesmo tempo, parece que eles crescem mais rápido quando não estou por perto, então também fico pensando se isso é um sinal de que estou fazendo algo errado
    • Virei pai recentemente, e a transferência de habilidades entre gerente de engenharia e pai/mãe é muito alta
      Em alguns dias, sinto que estou gerenciando minha família com habilidades que aprendi no trabalho
  • Meu histórico é o oposto. Sou um engenheiro de software comum, mas tenho uma habilidade bem boa para lidar com pessoas
    Tenho experiência suficiente para saber o que leva tempo e quais partes do sistema são mais importantes. Há alguns engenheiros sênior que realmente ouvem, e eu dou a eles muita confiança e autonomia
    Não sou eu quem toma as decisões de design; são eles, e eu acrescento minhas opiniões. Se algo falha, assumo a responsabilidade e aprendo; se dá certo, atribuo o mérito à equipe. Mesmo falando com humildade, vejo o papel de gerente como algo, acima de tudo, sobre pessoas

    • Sinceramente, acho que esse é o caminho de carreira ideal para gerente de engenharia. É uma pena que muitas empresas não tenham um mecanismo formal de transição para gerente em uma etapa intermediária
  • O único motivo pelo qual eu gostaria de sair do papel de coder/IC para a trilha de gestão é a entrevista de whiteboard necessária toda vez que mudo de emprego
    É quase doloroso ter que me preparar de novo do zero todas as vezes; existem cargos sem esse processo, mas são muito raros. Quando penso nessa preparação, muitas vezes acabo ficando no mesmo emprego com um “ah, por favor, de novo não”

  • Um mau gerente de engenharia pode causar muito mais dano do que um mau IC. Acho que essa questão não é discutida com frequência suficiente
    Ao longo de uma carreira longa, encontrei 1 gerente excelente, alguns gerentes razoáveis e muitos gerentes péssimos. Gerentes péssimos tornam o trabalho muito mais difícil e, às vezes, completamente miserável
    A combinação de um mau gerente de engenharia com um IC júnior pode ser especialmente ruim. Com a idade, aprendi que dá para trabalhar mesmo com um mau gerente e mover a situação para um lugar melhor, ou sair quando sinto que não há esperança

    • Fico curioso para saber como você definiria aquele gerente excelente. Que personalidade, comportamentos e habilidades fizeram essa pessoa se destacar?
      Estou assumindo mais responsabilidades de gestão hoje em dia e gostaria de saber
  • Certa vez liderei uma equipe composta por ICs com doutorado. Eu precisava encontrar trabalho para eles, segurar os sonhadores e mantê-los felizes
    Sem brincadeira: eu passava seis horas seguidas conversando individualmente, fazendo o papel de conselheiro de carreira e de pessoa que consola. Nunca imaginei que isso faria parte do meu trabalho
    Um dos membros da equipe ajudou a fechar dois contratos separados de 1 bilhão de dólares, então meu tempo acabou sendo recompensado