Este excelente artigo de John Olspau é intitulado "Sendo um engenheiro líder" . A primeira vez que li cerca de quatro anos atrás, quando mudei para o meu emprego atual, isso realmente influenciou as idéias sobre essa área da minha carreira.

Depois de relê-lo agora, uma coisa parece realmente interessante lá: a empatia e a ajuda à equipe são uma parte importante do trabalho do idoso. O que, é claro, é verdade!

Mas agora vejo que a maioria ou todos os engenheiros líderes que conheço têm uma ajuda significativa para outros funcionários, além do trabalho de programação pessoal. Agora parece-me que meus colegas e eu não enfrentamos tanto o problema “O que? Precisa falar com as pessoas? INCRÍVEL ”, quanto custa outro problema:“ Como equilibrar toda essa liderança de trabalho com sua contribuição / programação individual? Quanto e que tipo de trabalho devo fazer? ” Portanto, em vez de falar sobre os sinais do senhor deputado do artigo de Olspau (com o qual concordo plenamente), quero falar sobre o trabalho que estamos fazendo.

Sobre o que é este artigo

“O que um engenheiro líder faz” é um tópico enorme, mas aqui está apenas um pequeno artigo, portanto, lembre-se:

• Existe apenas uma descrição possível do que um engenheiro líder pode fazer. Existem muitas abordagens para o trabalho, e isso não deve ser um dogma.
• Eu trabalhei principalmente apenas em uma empresa, então minha experiência e visões são obviamente bastante limitadas.
• Obviamente, existem muitos níveis de "sênior". É sobre o nível P3 / P4 na hierarquia Mozilla (engenheiro sênior / engenheiro de equipe), talvez um pouco mais próximo do nível "equipe".

Quais são as responsabilidades

Essas são coisas que eu vejo mais como o trabalho de um engenheiro líder e menos como o trabalho de um gerente (embora os gerentes definitivamente façam algumas das opções acima, especialmente criando novos projetos e vinculando projetos às prioridades de negócios).

Quase todo esse trabalho é essencialmente técnico : ajudar alguém a lidar com um projeto complexo é claramente uma interação humana, mas os problemas que trabalharemos juntos serão geralmente técnicos! ("Talvez, se simplificarmos o design, podemos lidar mais rápido!").

• Escreva código (obviamente).
• Faça uma revisão de código (obviamente).
• Escreva e revise a documentação do projeto . Como em outras revisões, é provável que uma aparência de terceiros ajude a melhorar o design.
• Ajude os colegas se eles estiverem presos . Às vezes, as pessoas ficam presas em um projeto e é importante ajudá-las! Eu penso sobre isso, não tanto sobre “pára-quedas do céu e entregar seu conhecimento mágico para as pessoas”, mas sobre “trabalhar juntos para entender o problema e ver se dois cérebros conseguem lidar mais rápido que um” :). Também significa trabalhar em conjunto, não resolver um problema em vez de outra pessoa.
• Mantenha os colegas em alta . Para pessoas diferentes, "nível" tem significados diferentes (para minha equipe, isso significa confiabilidade / segurança / conveniência do produto). Se alguém toma uma decisão que eu não gosto, significa que sei algo que ele não sabe ou ele sabe algo que eu não sei! Portanto, você não precisa dizer: "Ei, você fez errado, você precisa fazer o X", mas é melhor apenas fornecer a eles informações adicionais que eles não tinham, e isso geralmente resolve o problema. E muitas vezes acontece que faltava algo para mim e, de fato, a solução deles era bastante razoável! No passado, às vezes eu via engenheiros líderes tentando manter padrões de qualidade repetindo suas opiniões mais alto, porque achavam que estavam corretas. Pessoalmente, não achei essa abordagem útil.
• Crie novos projetos . A equipe de desenvolvimento de software não é um lugar de soma zero! Os melhores engenheiros que conheço não deixam o trabalho mais interessante para eles mesmos, eles criam novos projetos interessantes / importantes e criam um espaço para que outros façam esse trabalho. Por exemplo, alguém da minha equipe começou a reescrever nosso sistema de implantação. O projeto acabou sendo super bem-sucedido e agora toda a equipe está trabalhando em novos recursos que se tornaram mais fáceis de implementar!
• Planeje o trabalho de seus projetos . Trata-se de escrever / relatar um roteiro para os projetos nos quais você está trabalhando e garantir que as pessoas entendam o plano.
• Relate os riscos do projeto com antecedência . É muito importante reconhecer quando algo não está indo muito bem, notificar outros engenheiros / gerentes e decidir o que fazer.
• Relatório de sucesso!
• Realizar projetos de terceiros que beneficiem a equipe / empresa . Vejo que muitos idosos às vezes fazem projetos pequenos, mas importantes (por exemplo, criam ferramentas de desenvolvimento / ajudam a estabelecer políticas), o que acaba ajudando muitas pessoas a fazerem seu trabalho muito melhor.
• Esteja ciente de como os projetos se relacionam com as prioridades dos negócios.
• Decida quando parar o projeto . Acontece que é surpreendentemente difícil de entender quando você precisa parar / não começar a trabalhar em algo. :)

Eu coloquei "escrever código" em primeiro lugar, porque, na realidade, essa tarefa desliza facilmente a lista de prioridades. :)

Não há nenhum item "fazer estimativas / previsões" na lista. Ainda não sou muito bom aqui, mas acho que um dia vale a pena gastar mais tempo nisso.

A lista parece ser grande. Parece que se você fizer todas essas coisas, elas absorverão todos os seus recursos intelectuais. Eu acho que, em geral, faz sentido isolar uma parte e decidir: “No momento, vou me concentrar em X, Y e Z, acho que meu cérebro explodirá se eu tentar fazer B e C”.

O que não é um dever

Isso é um pouco mais complicado. Não estou dizendo que você não pode lidar categoricamente com essas coisas. A maioria dos engenheiros líderes que conheço passa muito tempo pensando nesses problemas e trabalha um pouco nessa direção.

Mas parece-me que é útil traçar um certo limite, porque algumas pessoas têm um alto senso de responsabilidade pela equipe e pela empresa - e estão prontas para assumir tudo, como resultado do trabalho excessivo e da incapacidade de dar uma contribuição técnica, que na verdade é sua negócio principal. Portanto, o estabelecimento de certos limites ajuda a determinar em quais questões faz sentido pedir ajuda quando a situação se tornar turbulenta. Seus limites reais dependem de você / sua equipe. :)

A maioria dos itens a seguir são de trabalho gerencial. Isenção de responsabilidade: os gerentes fazem muito mais do que o listado aqui (por exemplo, "criar novos projetos") e, em algumas empresas, algumas das opções acima podem realmente ser o trabalho de um engenheiro líder (por exemplo, gerenciamento de sprint).

• Garantir que cada funcionário seja recompensado de acordo com seus méritos por seu trabalho.
• Verifique se o trabalho está bem distribuído.
• Certifique-se de que as pessoas trabalhem bem juntas.
• Garanta a coesão da equipe.
• Converse em particular com cada funcionário.
• Treine novos gerentes, ajude-os a entender o que é esperado deles (embora eu ache que os principais programadores costumam realmente participar dessa atividade?).
• Gerenciar projetos de terceiros (no meu trabalho, esse é o trabalho de qualquer engenheiro que lidera esse projeto).
• Seja um gerente de produto.
• Lidere o gerenciamento de sprint / determine as etapas do trabalho de cada uma / realize reuniões semanais.

É útil definir limites explicitamente.

Recentemente, encontrei uma situação interessante quando discuti minhas responsabilidades com o gerente - e percebemos que as encarávamos de maneira muito diferente! Esclarecemos a situação e agora tudo está em ordem, mas isso me fez perceber que é muito importante concordar com as expectativas. :)

Quando comecei como engenheiro, o trabalho era bastante simples - escrevi código, tentei criar projetos que fizessem sentido e tudo estava perfeito. Meu gerente sempre teve uma ideia clara do meu trabalho, nada muito complicado. Agora a situação mudou! Portanto, agora acredito que devo determinar o trabalho que:

• Eu posso fazer / ajuste a longo prazo para mim.
• Quero fazer / que geralmente é agradável e consistente com meus objetivos pessoais.
• De valor para a equipe / organização.

A redação exata será diferente para pessoas diferentes (nem todos têm os mesmos interesses e pontos fortes, por exemplo, eu não sou muito bom em revisão de código!). Penso que, por esse motivo, é ainda mais importante discutir este tópico e concordar com as expectativas.

Não se contente com o trabalho que você não pode / não quer fazer

Eu acho que é muito importante desistir do trabalho que não posso fazer ou que não trará alegria a longo prazo! Parece tentador assumir muito trabalho, mesmo que você não goste muito ("Oh, isso é bom para a equipe!", "Bem, alguém tem que fazer isso!"). É claro que, às vezes, assumo tarefas apenas porque elas devem ser concluídas, mas acho que para a saúde da equipe é realmente importante que os funcionários façam o que geralmente gostam e o que podem fazer a longo prazo.

Portanto, executarei pequenas tarefas que precisam ser concluídas, mas é importante não dizer: "Claro que passarei a maior parte do tempo com o que faço mal e com o que não gosto, sem problemas" :). E se "alguém" precisar fazer isso, talvez apenas signifique que precisamos contratar / treinar alguém novo para preencher a lacuna. :)

Eu ainda tenho muito a aprender!

Embora sinta que estou começando a entender o que é um "engenheiro líder" (já há 7 anos na minha carreira), mas ainda sinto que preciso aprender muito mais sobre isso e gostaria de saber como outras pessoas definem limites. seu trabalho!