10 aspectos-chave a considerar ao gerenciar projetos técnicos

Pensamentos sobre como lidar com a progressão natural do trabalho como desenvolvedor de software e como continuar fazendo o que você ama

Carlos Matias 27 de junho de 2017

Atualmente, há uma progressão natural para os desenvolvedores de software sênior (seja em startups ou empresas de estilo corporativo) para dar o salto de seu papel técnico atual para um papel mais orientado a liderança / gerenciamento. Essa progressão é geralmente motivada por várias necessidades que surgem da evolução da empresa / equipe / produto e exigem que o desenvolvedor sênior dedique seu tempo à formação / integração, planejamento / road mapping e liderança da equipe, contribuindo para decisões mais macro e coaching, ao mesmo tempo em que se envolve cada vez menos nas atividades de engenharia do dia-a-dia.

O título do trabalho nem sempre é "Gerente". Geralmente é algo nos moldes de VP de Engenharia ou Tech / Team / Project Lead, que carrega um significado diferente de ter Manager no cargo, mesmo que exija muitas atividades de gerenciamento.

Neste artigo, vou apresentar como e por que o salto de um papel mais técnico para um mais orientado para a gestão acontece e as questões que ele pode carregar. Eu tirei algumas inspirações deste adorável artigo do Charity Majors , você deveria definitivamente dar uma olhada. Também vou aprofundar os desafios que você enfrenta quando fizer o salto.

"Ei, eu convidei você para aquela reunião da qual falamos …"

O salto da tecnologia para a administração é um progresso natural causado pelo crescimento da equipe e pela sua antiguidade no projeto. Se a equipe precisar de mais desenvolvedores, você provavelmente estará envolvido no processo de recrutamento. Então, quando essas pessoas participam da equipe, é seu trabalho treiná-las / integrá-las. Se houver decisões drásticas de design ou arquitetura, você é uma das pessoas responsáveis por tomar as decisões finais. Todas essas tarefas geralmente exigem muito tempo, seja tempo gasto na revisão e aprovação de candidatos, respondendo a e-mails ou preparando e conduzindo reuniões.

Isso significa que você dedicará a maior parte do seu tempo a atividades que estão muito mais diretamente relacionadas ao gerenciamento da equipe do que ao desenvolvimento de software, o que pode ser uma grande desestabilização para muitos desenvolvedores.

No entanto, essa mudança em foco para mais trabalho orientado para a gestão pode ser um mal necessário. Como desenvolvedor sênior, você carrega o conhecimento técnico do projeto e será uma das pessoas que sabem se um recém-chegado é adequado para o projeto. Você também será preciso na estimativa de tarefas e no planejamento do trabalho, desde que você fez parte do projeto desde o início, tomou as primeiras decisões de projeto e conheceu a arquitetura. Todo esse conhecimento é muito valioso, e contratar alguém novo para fazer esse tipo de trabalho, onde todo esse conhecimento prévio é necessário, não é uma opção na maioria das vezes.

Com isto dito, aqui estão algumas das razões pelas quais os desenvolvedores saltam de seu papel tecnológico para um papel mais focado em gerenciamento.

Salário

Verdade seja dita, as empresas estão dispostas a gastar mais em contratações de gerenciamento do que em suas contratações de tecnologia. Eu sei que isso é generalizador e que pode não se aplicar a todas as empresas existentes, mas você atinge o limite salarial muito mais rápido trabalhando como desenvolvedor de software do que gerenciando o trabalho de outras pessoas.

No meu ponto de vista, isso acontece por dois motivos distintos.

A primeira razão é o fato de que soft skills geralmente pagam mais do que hard (habilidades técnicas).

O segundo motivo é a responsabilidade.

Habilidades macias são mais difíceis de aprender do que habilidades técnicas. Claro, você pode ter um engenheiro superstar que é um desenvolvedor 10x e pode trabalhar sozinho como nenhum outro. Mas esse cara é realmente relevante para o seu time se ele só pode trabalhar sozinho? E se ele tiver pouca habilidade de comunicação? Você ainda está inclinado a promovê-lo para uma posição mais orientada para o coaching? Ele estará fazendo um bom trabalho?

As contratações gerenciais precisam fazer o seu trabalho, mas elas também devem possuir fortes soft-skills para abordar o lado humano da construção de um projeto, como comunicação, empatia, espírito de equipe e resolução de problemas.

Prestação de contas significa que você será a pessoa responsável pelos sucessos e deficiências da equipe. Quando tudo está errado, você não culpa a pessoa que executou a operação e fez errado, você culpa a pessoa que deu a ordem, e quando você é a pessoa que deu a ordem e sua cabeça está no bloco de corte que significa mais $$$.

Carreira e Estilo de Vida

O desenvolvimento de software é um tipo de trabalho em que você precisa estar constantemente aprendendo e atualizando seu kit de ferramentas para se manter nítido e executar o melhor trabalho possível. Mas a vida e outras responsabilidades podem afastá-lo de suas últimas noites trabalhando em projetos paralelos ou em sua leitura típica de um blog. Isso tem um impacto psicológico mais do que qualquer coisa. As pessoas começam a se sentir como se não pudessem se manter atualizadas, com habilidades e transferidas para um trabalho que lhes desse mais espaço.

Além disso, à medida que as pessoas amadurecem, elas também ganham uma compreensão mais clara da vida e das interações humanas, de modo que naturalmente adquirem habilidades de comunicação e experiência que podem ser valiosas para as operações de gerenciamento.

Por outro lado, algumas pessoas entram no desenvolvimento de software com o claro propósito de subir na hierarquia e se tornar o gerente da equipe.

Abraçando um novo papel

Para as pessoas que estão pensando em dar o salto, aqui estão alguns aspectos importantes a serem levados em consideração ao fazer a transição. Para esta seção, eu realmente preciso agradecer a Alexander Grosse por sua incrível Masterclass em Como construir uma equipe de tecnologia na Start & Scale Week do ScaleUp Porto .

1) Mudando o foco do trabalho técnico para o trabalho gerencial

Algumas pessoas realmente temem o trabalho administrativo e tentam manter qualquer trabalho técnico que possam fazer. Isso não é uma coisa ruim, já que a maioria dos desenvolvedores que lidam com seu trabalho técnico tendem a ter sucesso em fazê-lo, e isso permite que eles estejam mais em contato com o que a equipe precisa e o que ele pode fazer para desbloquear o trabalho. equipe. Se seus superiores / empresa permitem que você navegue em torno de mais trabalho técnico, vá em frente; se não, ei, sempre há projetos paralelos a serem feitos!

No entanto, se você permanecer ativo como desenvolvedor, não esteja no caminho crítico. A sério.

Seu tempo agora é dividido entre uma infinidade de atividades. Se as revisões ou implementações de código dependerem de você, você estará se tornando um gargalo para a equipe apenas por egoísmo e tentando manter o máximo de trabalho técnico possível. Se você se vê nessa posição e não está disposto a desistir, provavelmente não é adequado para um cargo de gerência.

2) Não seja o Hub da equipe

Engenharia não existe isoladamente. As equipes de engenharia precisam coexistir com outras áreas de especialização para agregar valor ao cliente. Manter sua equipe longe de barreiras ou distrações (que é uma tarefa para o gerente) não é o mesmo que manter a equipe longe de qualquer comunicação externa.

Seus desenvolvedores devem interagir com outras equipes de diferentes disciplinas e usuários finais do produto da empresa, a fim de ajustar o ajuste do produto e encontrar falhas no software. Se isso se tornar difícil de gerenciar, aloque um período em que a equipe possa executar um trabalho dedicado a dependências externas.

3) contratar direito

Recrutamento é sempre um assunto delicado. Normalmente, os processos de contratação demoram muito tempo, e quanto mais tempo leva das pessoas dos escalões superiores, mais onerosos eles são. Se sua empresa está crescendo acima de 20 pessoas, você deve considerar pedir a contratação de pessoal de RH dedicado.

Alguns pontos importantes a serem considerados são:

  • Se você precisa de qualidade, contrate a qualidade. Desenvolvedores de software podem ser caros, mas podem ganhar seu valor rapidamente. Pelo menos, tente conseguir algumas contratações sólidas e estáveis que possam, então, treinar o resto da equipe.
  • Não caia em armadilhas de referência e não deixe que as equipes façam suas próprias contratações sozinhas. As equipes precisam de diversidade, você não quer uma equipe onde todos pensem / seja o mesmo.
  • Contrate para ajuste de valor. Forçar alguém que não acredita em TDD ter que fazer isso é muito mais difícil do que ter alguém que aprenda um novo idioma.

Como uma nota final sobre este tópico, existem várias opiniões sobre o processo atual de entrevista / contratação para trabalhos de desenvolvimento de software que estão sendo quebrados . Reserve algum tempo para revisar o processo atual da empresa e dê sua opinião de acordo.

4) ter intenções de integração

A integração é um assunto vital quando se discute a produtividade da equipe e a felicidade geral das novas contratações.

Em uma empresa pequena (<10), o processo de integração é geralmente espontâneo. No entanto, se a sua equipe crescer além disso, então é hora de crescer além de “hey esse é o seu lugar e por favor, vá falar com [pessoa]”.

É o seu trabalho como líder de equipe e líder dar às pessoas todo o contexto que elas precisam e orientá-las. Você pode apontar o engenheiro recém-contratado para os recursos de que ele precisa, apresentá-lo à equipe e aos processos da equipe e iniciá-lo imediatamente. As pessoas já sabem que serão improdutivas nos estágios iniciais, então não lhes dê mais motivos para se sentirem assim.

Um dos processos mais eficazes (e úteis em termos de crescimento) da integração é o suporte. Ao receber tarefas de suporte, o membro recém-contratado pode trabalhar em suas habilidades de comunicação, entender diferentes problemas e partes do produto e navegar pelo projeto enquanto fecha os tickets de suporte. Isso vai ajudá-lo muito a entender o produto, o mercado e como tudo funciona. É também, na minha opinião, uma experiência de crescimento, já que um, como desenvolvedor, entenderá os problemas do produto a partir da perspectiva do cliente, o que pode levar a entender o que falhou em termos de experiência do usuário e o que pode ser melhorado.

5) Ter 1 em 1

Não há muita ciência nisso. Você deve ter uma conversa em um com os membros da equipe. Nessas discussões, você deve se concentrar em descobrir como estão se saindo, como estão se adaptando à equipe e à empresa e o que eles vêem como possíveis problemas no futuro. Você não apenas estará construindo um relacionamento de confiança com a outra pessoa, mas também descobrirá algumas preocupações subjacentes que podem não surgir nas operações do dia-a-dia.

Você também deve procurar dar (e receber) feedback nesses casos. Aqui está um ótimo artigo sobre como navegar por comentários para desenvolvedores juniores (sou culpado do segundo tipo).

6) Trabalhando em dívida de tecnologia

Sendo um desenvolvedor transformado em gerente, você sabe mais do que ninguém que uma das coisas que mais assombram os desenvolvedores é a dívida técnica. Ninguém quer construir uma casa com uma base defeituosa para que, sempre que puder, dê à sua equipe algum espaço para refatorar e reorganizar.

Dívida de tecnologia pode ser uma daquelas coisas que faz ou quebra a moral da equipe. Se a equipe é capaz de trabalhar com dívidas técnicas, eles sentem que seu trabalho é respeitado e que os compromissos assumidos durante o planejamento podem agora ser tratados adequadamente. No lado oposto, nunca ser capaz de fazer alguma "limpeza" pode levar à frustração, cansaço e, finalmente, ser a causa das pessoas deixarem a equipe.

7) Incentivar a comunicação e colaboração

Você precisa saber o que as pessoas estão fazendo. Se você não sabe, então você não sabe o que está fazendo. Use as ferramentas à sua disposição para acompanhar isso, não apenas para saber se tudo está funcionando como esperado, mas também para desbloquear as pessoas, se necessário.

Além disso, tenha sessões regulares de demonstração. A equipe precisa ser capaz de apresentar o trabalho que eles fizeram para o resto da empresa. Isso manterá todo mundo focado em entregar algo que é feito corretamente (apresentável) e também servirá como uma atualização de status para todos os outros que não estão envolvidos.

8) Definir cultura e valores

O crescimento é um inimigo da cultura. A maioria das empresas se orgulha de ter uma cultura incrível apenas para descobrir que a cultura é um eco das crenças do C * O.

Pergunte a si mesmo e pergunte aos seus colegas de equipe – "Qual é a nossa cultura?"

Se você não tem uma declaração de cultura definida, então talvez seja hora de informar a empresa que algo precisa ser feito sobre isso, caso contrário, cada equipe criará sua própria cultura, que geralmente será definida pelas opiniões das personalidades mais dominantes. Mesmo que os responsáveis sejam honestos, seus valores pessoais podem colidir com os que a empresa define como sua cultura. A definição de cultura é um exercício em que todos devem contribuir. Essa definição evolui com o tempo à medida que a equipe / empresa cresce e mais pessoas contribuem para isso.

Os valores são algo cultivado em nível de empresa, mas também em equipe. No caso das equipes de desenvolvimento de software, os valores podem impor avaliações de TDD e de código ou sempre ter um fluxo de Git claramente definido. Sempre olhe para as pessoas que não aderem aos valores da equipe. Burnout por conflito de valores é real e pode ser a causa de instabilidades na equipe.

9) Obter feedback

Nem todo mundo tem gerenciamento de experiência ou pode gerenciar adequadamente desde o início. Se necessário, procure treinamento adequado. Isso pode ser ler um livro, fazer um curso ou ter um workshop. Certifique-se de que, após o treinamento, todos os responsáveis pelo gerenciamento de diferentes setores ou equipes da empresa se reúnam para conversar sobre o que poderia funcionar e o que não poderia em termos de metodologia de gerenciamento.

Além disso, se possível, revise seu trabalho por outras pessoas com o mesmo status. A revisão por pares é sempre eficaz em encontrar pontos onde o trabalho pode ser melhorado.

10) Não pregue por longas horas

É seu dever como mentor e líder dar o exemplo e se você não sabe até agora as desvantagens de trabalhar longas horas, então você deve se informar. Pode estar prejudicando secretamente sua equipe sem que você saiba. Eu encontrei este artigo para ser muito esclarecedor sobre este assunto.

Conclusão

Dar o salto do desenvolvimento para o gerenciamento não é uma tarefa fácil, mas pode levar as pessoas a um caminho de carreira mais significativo. Pense no que você quer fazer e em quais condições você se vê gerenciando uma equipe de engenharia. Também tenha em mente que essa troca exige que você seja proficiente em muitas áreas que envolvem os esforços da equipe.