Senioridade: o papel das horas de voo e do upgrade pessoal no crescimento de um time de tecnologia

Para começar a cumprir a promessa feita em meu artigo sobre como construir times de engenharia de forma sustentável, quero falar sobre um assunto muito importante e que gera controvérsia — a métrica de maturidade do time. Como comentei em meu artigo anterior, essa métrica é composta basicamente de 2 fatores: a senioridade das pessoas do time e se o time já tem uma dinâmica eficiente de grupo.

Esse artigo é sobre o primeiro fator: senioridade das pessoas e como devemos equilibrá-la no time.

E dentro desse tópico — no artigo de hoje — vou primeiro falar um pouco de como olhar para experiência e, em seguida, te dar algumas ferramentas para ajudar a crescer o seu time olhando experiência de forma sustentável.

Mas — antes de ir para o pragmatismo usual — vamos filosofar um pouco…

O mundo de hoje tem muita ansiedade e — no afã de mudar o mundo — vejo que muitos líderes acabam colocando o carro na frente dos bois e não dando tempo para algumas coisas acontecerem.

Não me entenda mal, acho importante tentar mudar o mundo para melhor. Como dizia Steve Jobs, devemos tentar “poke life” e “make a little dent in the universe”. No entanto, o como fazer isso é muito importante. Você agora pode dizer:

“Bernardo, basta de filosofia! O que tempo tem a ver com a senioridade na formação de times?”

Bem, indo direto ao ponto, tudo!

Tempo tem a ver com experiência. E, a experiência dos profissionais que contratamos e como treinamos o nosso time é essencial para o sucesso da nossa empresa. E, para treinar bem o nosso time, precisamos de “mentores” experientes. Logo, a experiência é chave para criar um ciclo virtuoso de crescimento.

Horas de voo e o “upgrade pessoal”

Primeiro — como sempre gosto de fazer — é importante ilustrar um pouco do porquê a experiência é importante e qual a sua relação direta com o tempo. Para fazer isso acho que vale trazermos um conceito — que conheci pela primeira vez no livro Fora de Série — Outliers de Malcolm Gladwell — conhecido como a regra das 10.000 horas. O livro é um de meus favoritos e nele Malcolm ensina que para se atingir excelência em uma tarefa complexa — como liderar times ou escrever software — um nível de prática mínimo é necessário.

O número mágico de 10.000 horas — que equivalem a cerca de três horas por dia, ou 20 horas por semana, de treinamento durante 10 anos — é o que estudos mostram como o mínimo necessário para se atingir o grau de destreza pertinente a um expert de nível internacional.

E, pasmem! Isso vale para diversas áreas: desde esquiadores até mestres do crime. Pasmem mais ainda: isso se aplica até a pessoas que consideramos prodígios. O livro lembra que Mozart, por exemplo, é famoso por ter começado a compor aos seis anos, mas o fazia com ajuda — o que mesmo assim é muito impressionante — e só atingiu sua plena forma — compondo suas maiores obras — seguindo a regra das 10 mil horas.

Espero que a regra da dez mil horas tenha aguçado a sua curiosidade — como aguçou a minha — e recomendo fortemente a leitura de Fora de Série — Outliers e, em especial, o capítulo “A regra das 10 mil horas”

Uma coisa que acho importante é não confundir o conceito de expert de nível internacional com o de especialista. Expert em software é uma pessoa que opera no nível internacional de excelência e — em minha visão — segue um modelo diferente do especialista. Escrevi sobre isso em meu último artigo sobre o perfil PaintDrip para quem quiser ler mais sobre o assunto.

Mas, voltando ao tema principal: com a regra das 10.000 horas acho que fica claro que “horas de voo” — que é como eu apelidei carinhosamente a quantidade de horas que uma pessoa tem de experiência — são importantes para qualquer profissional e na hora de montar sua equipe você deve levar isso em consideração.

Depois de conhecer o conceito das 10.000 horas uma coisa que sempre me intrigou — e que já me perguntaram bastante também — era se bastava apenas horas de voo. Apenas o tempo não parecia intuitivo para mim. O como fazer as coisas sempre me pareceu fundamental também.

A “resposta formal” só veio anos depois quando conheci Morten Hansen em um treinamento que ele deu à liderança na OLX sobre seu livro Great at Work

Esse é outro de meus favoritos — acho que vocês já perceberam que sou daqueles que anda com o kindle a tiracolo. Ainda bem que não faço mais como o Bill gates e carrego uma sacola lotada de livros por aí! 😉

Morten publicou o seu estudo de anos — analisando 5000 pessoas — tentando identificar o que diferencia pessoas de performance excepcional.

Sua conclusão: existem “7 hábitos” — que ele chamou de “work smart practices’’ — que são responsáveis pela maior parte da performance das pessoas, como pode ser visto na imagem abaixo.

práticas: work smart

Recomendo que você investigue a fundo todas as 7 práticas de forma a aproveitá-las em seu trabalho. A minha favorita ele chamou de “Do Less, Then Obsess — tem a ver com priorização e certamente vocês vão ouvir mais dela em próximos artigos. Mas, para a nossa conversa de hoje, a prática da qual quero falar é a de número quatro — que Morten batizou de Don’t Just learn, Loop.

Em seu estudo, Morten conta a história de Dan McLaughlin. Dan — com a regra das 10.000 horas na cabeça — largou a bem sucedida carreira de fotógrafo e — após 5.200 horas de treino — saiu de um zero à esquerda no golfe para figurar entre os 5% melhores golfistas dos EUA. Em um país com 24 milhões de golfistas — e em apenas 4 anos — ele conseguiu um feito extraordinário. No entanto, uma das coisas mais interessantes da história de Dan foi observar que não foi apenas um jogo de repetição ao longo do tempo.

Lendo o livro — e eu te encorajo a fazer o mesmo — percebi que minha intuição não estava errada. Não é apenas um jogo de força bruta. “Horas de voo” são importantes mas, como mostra a história de Dan — e diversas outras do livro — é muito importante também durante a nossa jornada manter um learning loop — ou ciclo de aprendizado — como na imagem abaixo

loop de aprendizado

O ciclo de aprendizado nos possibilita aprender e fazer um “upgrade” de nós mesmos. Simples em palavras, mas na vida real vocês sabem que fazer esse “upgrade” não é nada fácil e requer bastante esforço.

Em Great at Work, Morten explica a técnica do Learning Loop em detalhes. Dá também algumas dicas de como implementá-la. Um exemplo é a técnica que ele chama de “the power of one” que nos ajuda em nosso “upgrade” focando 15 minutos diários em melhorar uma nova habilidade. Uma curiosidade: Na pandemia aprendi datilografia, por exemplo, usando esta técnica e a plataforma keybr. Bem, agora já estou fugindo do assunto principal do artigo, mas — definitivamente — recomendo a leitura.

Até aqui o que queria ilustrar são dois pontos importantes quando você estiver: montando, participando ou — até mesmo — avaliando entrar em um time.

  1. É muito importante olhar se as pessoas têm a experiência necessária analisando “horas de voo”, ou seja, horas em que a pessoa efetivamente trabalhou naquela posição
  2. É muito importante analisar se ao longo do tempo a pessoa consegue demonstrar que ela melhorou — AKA — faz seu “upgrade pessoal”.

Estruturando o time

Agora que vocês já sabem que horas de voo e o upgrade pessoal são muito importantes — e também — o porquê são, vamos começar a ilustrar como olhar para estes atributos na formação de nossos times.

Lembrando que o modelo de times que recomendo é o que o Marty Cagan chama de empowered product teams e do qual falei um pouco em meu primeiro artigo desta série. Se você ainda não estiver familiarizado com este modelo, acho importante ler o artigo antes e buscar as referências nele.

Em primeiro lugar, gostaria de apresentar algumas estruturas e proporções — além do modelo empowered product teams falado antes — que acho que são importantes e uso no meu modelo de construção de times.

A primeira estrutura que gostaria de falar é o time de liderança de engenharia. Essencial para um bom funcionamento do time de tecnologia, esta estrutura é onde fica a linha de reportes dentro da engenharia e é ortogonal a de squad multifuncionais — ou empowered product teams.

A proporção que gosto de usar entre líderes de pessoas e contribuidores individuais é de 1 para 8 — no máximo — dependendo da maturidade do líder, do nível que ele está na hierarquia e da maturidade dos contribuidores individuais sob sua responsabilidade. Desta forma, o líder consegue dar tempo de qualidade às pessoas.

A ideia aqui não é entrar demais no papel de um líder de engenharia — uma excelente fonte é o site rework do google e o seu projeto oxygen. O importante para esse artigo é lembrar que essa camada é fundamental para garantir que criemos um ambiente onde estamos sempre recrutando o talento que precisamos e treinando o nosso time — para que ele esteja sempre fazendo o “seu upgrade pessoal”. Ou seja, quem mantém o equilíbrio da experiência do time é essa camada.

É importante lembrar também que dependendo do tamanho da equipe a árvore de reportes tem 1 ou mais níveis.

Tipicamente em um time com até 8 pessoas desenvolvedoras, o líder de pessoas é a CTO e todo mundo reporta para ela. À medida que o time vai crescendo, a CTO — ou o cargo de liderança mais sênior na engenharia — começa a ter a necessidade de recrutar líderes de pessoas para ajudá-la. Dessa forma, começa a se formar uma camada que chamamos de liderança de engenharia.

A segunda estrutura que a liderança de engenharia — junto com o departamento de pessoas — deve construir é uma carreira em Y bem estruturada — onde se tenha uma caminho claro de liderança de pessoas e liderança técnica.

carreira em Y

Acima podemos ver um exemplo de uma carreira em Y com cargos bem estruturados — se você quiser outros exemplos de estruturas em diversas empresas referência o site levels.fyi ajuda bastante nesta tarefa.

É claro que devemos ter cuidado para não fazer over-engineering e ter estruturada uma carreira como a do exemplo acima em uma startup de 10 pessoas. No entanto, desde o início de qualquer empresa é importante que os líderes tenham conversas sobre o futuro e o desenvolvimento das pessoas de seus times — fazendo mentoria de forma pró-ativa permitindo com que o “update pessoal” do time esteja sempre acontecendo.

Também acho muito importante — desde o início — a empresa ter uma visão de caminhos diferentes para líderes de pessoas e contribuidores individuais. É importante entender que são dois trabalhos diferentes, ambos de extrema importância para que tenhamos êxito em atrair, treinar e reter o talento necessário.

Outro equívoco comum é que profissionais encarem o caminho de liderança de pessoas como uma promoção. Não é o caso, ambos são essenciais para criar uma empresa de tecnologia sólida — e, a diferença é a natureza do trabalho e o conjunto de habilidades que precisa ser desenvolvido.

Uma proporção que acho importante trazer é a de senioridade dos contribuidores individuais de um squad — que mostrei em meu artigo sobre como escalar um time de engenharia de forma sustentável. Como disse lá — em minha experiência — uma boa proporção seriam 25% de devs mais seniores, 50% em estágio intermediário de experiência e 25% de iniciantes. Para efeitos de ilustração podemos usar a carreira em Y da imagem anterior:

  • devs mais seniores — seriam desenvolvedor V para cima
  • devs em estágio intermediário — seriam IV
  • devs em estágio iniciantes — seriam IV e abaixo

Importante também equilibrar a liderança usando proporções. Acabei não falando de proporções de liderança de pessoas com um olhar de senioridade antes. Porém, da mesma forma que para os contribuidores individuais, senioridade também é importante para a liderança de pessoas.

Vamos usar novamente a carreira em Y da imagem anterior para ilustrar as proporções que uso:

  • Gerente de Desenvolvimento I — teria um squad — lembrando que o squad médio em meu modelo tem em geral de 4 a 6. Portanto, essa pessoa tem sob sua responsabilidade de 4 a 6 pessoas.
  • Gerente de Desenvolvimento II — responsável em geral por até 2 squads –
  • Gerente de Desenvolvimento Sênior — já é um líder de líderes de pessoas — em geral tem sob sua responsabilidade um grupo de gerentes e eventualmente contribuidores individuais — em geral mais seniores.
  • Diretor de Desenvolvimento — é um líder de líderes com bastante experiência e em geral é responsável por uma divisão grande do time de engenharia

O importante aqui é que em geral um líder não deve ter mais de 8 reportes senão não consegue — como falamos antes — ter tempo de qualidade para dedicar às pessoas.

Estratégia para o time

Com estes artefatos e proporções podemos criar o último artefato que gostaria de apresentar neste artigo, que é o que chamo de mapa dos times.

Esse mapa é a materialização da estratégia de pessoas do time e começa com a previsão do número de squads que você vai ter baseado na estratégia da empresa e — na consequente — estratégia do produto.

Se você está em dúvida do que é a estratégia de produto e como seu uso é diferente de um roadmap tradicional sugiro dar uma olhada no artigo do Marcello Quintella sobre isso

No mapa devemos ter:

  1. Topologia do time.
  2. Squads e seus componentes(pessoas e papéis).
  3. Squads que você quer construir — baseado na estratégia — e quem você precisa contratar ou treinar
  4. Lista de líderes responsáveis pelos squads

Esses itens compõem um diagnóstico parcial de como está o seu time e quais são os “gaps” que você tem em termos de pessoas e responsabilidades.

Olhando para ele, o time de liderança de tecnologia pode criar ações de recrutamento e treinamento de forma a equilibrar o time e possibilitar — de forma estratégica — que ele cresça.

Este mapa também é uma ferramenta essencial de comunicação para a alta liderança e para todo o time.

Bem, espero que este artigo tenha te ajudado a entender o papel da experiência em um time de tecnologia e como olhar para o time de forma estruturada com a ótica da senioridade.

Uma coisa que você pode estar se perguntando é: em um mercado de tecnologia incipiente, aquecido e com menos oferta de profissionais do que vagas, como fazer isso?

Esse é assunto para o meu próximo artigo. Nele vamos falar como é fundamental formar pessoas e como criar incentivos em sua cultura de forma que o seu time esteja sempre fazendo “seu upgrade” de forma orgânica. Até breve!

Publicado por Bernardo Carneiro

I love building teams and technology

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google

Você está comentando utilizando sua conta Google. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s

%d blogueiros gostam disto: