Desde que me tornei advisor de startups tenho conversado com muitas pessoas que precisam formar ou estão formando equipes de engenharia. Umas das perguntas que mais me fazem é: como escalar os times?
Montar o primeiro time parece um pouco mais fácil. Separar a equipe em dois times — ou squads — ainda é tranquilo. Mas depois começa a ficar mais complicado. Devemos criar quantos squads? Criamos tribos? Precisamos de gerentes? Qual o papel do contribuidor individual? Como definir o escopo de cada squad? Quão rápido devemos crescer?
Ao longo da minha carreira tenho focado em resolver essas questões nas empresas que trabalhei. Nos últimos tempos — inspirado pela ideia do Ray Dalio que tudo é uma máquina de máquinas — comecei a “codificar” essa máquina de forma que possa criar times cada vez mais eficientes na geração de valor para a empresa e seus usuários.
A ideia em compartilhar essa série de artigos é que eles funcionem como um SDK para a formação de times de produto e de engenharia. Espero que você possa incorporar pelo menos parte deste “código” em sua empresa de forma que possa construir times cada vez mais eficientes. Claro que, como em todo SDK, parte do código e de sua inspiração foi incorporado de outras bibliotecas e vou, sempre que puder, direcionar no texto a fonte de uma ideia — desta forma posso dar crédito ao autor e permitir que você se aprofunde mais no tópico se achar necessário.
Para facilitar a leitura vou tentar responder apenas algumas perguntas por artigo e a primeira que quero endereçar é: quando dividimos o time?
Antes de começar a responder a pergunta acima é importante explicar porque dividir. Parece óbvio, mas sempre vale ressaltar que a razão fundamental para as empresas dividirem o time de tecnologia é para conseguir fazer mais coisas em paralelo. O risco que sempre corremos é abrirmos mais frentes que conseguimos lidar por vez e perdemos nossa capacidade de ter foco e profundidade e acabar diminuindo a nossa capacidade ao invés de aumentá-la.
Para evitar essa armadilha e fazer a divisão de forma eficiente é importante entender a vazão esperada de um time de tecnologia.
E, para entender a vazão da “máquina” que é o time de tecnologia, temos que entender a unidade fundamental deste time: o squad.
A maior parte das pessoas no mundo da engenharia de software já está familiarizada com o conceito de times multi-funcionais — ou squads. Não vou me aprofundar muito nesse conceito aqui. Boas fontes de consulta para squads são: inspired — que é um dos livros mais completos sobre o “básico” de como construir times de produtos de tecnologia — e an elegant puzzle — que tem bastante em comum com a forma que venho criando times ao longo do tempo.
Recomendo a leitura de ambos, mas para efeito deste artigo o importante é definir o que é a composição de um squad ideal.
O squad ideal é algo “utópico” que devemos modelar com o objetivo de entender e melhorar a “máquina” de produto e engenharia. A capacidade — ou vazão — máxima de um squad depende de diversas variáveis, as principais são: número de pessoas no squad, sua maturidade e sua saúde.
O diagrama acima — retirado de an elegant puzzle — mostra os 4 estágios possíveis de um squad. O ideal é termos o squad no estágio 4( inovando) — esse seria o squad trabalhando com sua vazão máxima. Consequentemente, se quisermos ter nossa equipe de produto e tecnologia com a vazão máxima todos os squads deveriam estar no estágio 4. Apesar de ser a situação ideal ela é utópica e o que devemos fazer em nosso times de tecnologia e tentar sempre levar o máximo de squads para esse estágio.
Quando olhamos para um squad ele é formado por pessoas com papéis específicos: pessoas desenvolvedoras — ou devs, gerentes de produto e gerentes de engenharia.
Em meu modelo temos um gerente de produto responsável pelo squad e o número de devs varia entre 4 e 6. Vamos falar do gerente de engenharia em outro artigo, mas analisando o número de pessoas desenvolvedoras, se tivemos menos que 4 eu não consideraria um squad formado — e certamente estaríamos no estágio 1(falling behind) — e, consequentemente, podemos aumentar a vazão do time colocando mais pessoas. Mas isso também é papo para outro artigo.
Outra variável importante é a maturidade do squad. Ela é composta basicamente de 2 fatores: a senioridade das pessoas do time e se já tem a dinâmica de um time eficiente. Mais sobre isso no próximo artigo sobre formação de squads — estou ficando repetitivo :)
A última variável que devemos olhar é a saúde do squad. Todo mundo que já está há algum tempo trabalhando com software sabe que não é uma ciência exata :0. Entretanto, podemos construir o que eu chamo de painel de instrumentos, ou cockpit , dos squads que são as métricas básicas de saúde. Essas métricas são bons indicadores da saúde de um time e nos ajudam a buscar e identificar o seu equilíbrio. Também não vou entrar muito no detalhe aqui agora. Uma excelente fonte para métricas de performance e equilíbrio do time é o livro accelerate. Em meus últimos times ao longo dos anos temos usado uma mistura das métricas dele com algumas outras que ajudam a entender geração de valor para o usuário, quantidade de débito técnico e toil. Mas, isso vai ter que ficar para outro dia também para nos focarmos em quando e como dividir o time.
Como em todo artigo de engenharia não podia faltar uma fórmula:
vazão_do_squad = número_de_devs*maturidade_squad*saude_squad
A fórmula acima descreve como podemos ter um indicador para a vazão do squad e acho que já está claro que nosso objetivo como líder de engenharia é buscar maximizar a vazão de todos os squads de nossa equipe de engenharia. É claro que a vazão máxima é uma utopia. Porém, em minha experiência, o exercício constante na busca da vazão máxima faz com que a vazão do time de engenharia sempre esteja crescendo e — como ilustrado em accelerate — isso tem um impacto direto no resultado da sua empresa.
Como comentado antes, o número ideal de devs em um squad deve variar entre 4 e 6. Menos de 4 não deveria ser um squad, pois em geral é pouca gente para focar em um problema de forma consistente. Com mais de 6 começamos a ter problemas de comunicação e colocar mais pessoas em geral piora a performance.
Para simplificar a demonstração de como dividir o time, vou pular a discussão sobre a maturidade do time, que teremos a oportunidade de abordar em breve no próximo artigo da série e também a medida de saúde. Vamos assumir que ambas as variáveis estão bem equilibradas e tem uma contribuição positiva para a vazão do squad.
Para ilustrar a divisão vamos começar com o cenário de uma startup que começou a criar o seu time.
A primeira variável de nossa fórmula de vazão que vamos trabalhar é o número de devs. Certamente até contratarmos pelo menos 6 devs não devemos dividir o squad.
Mas a pergunta é o que fazemos quando contratamos a sétima pessoa?
Idealmente não devemos quebrar e ter squads com menos de 4 devs. Então a abordagem que é mais recomendada é “encher” um squad até 8, e depois que tivermos esse squad completo, duplicar. Apesar de estourarmos o “número mágico” de 6. A potencial perda de eficiência em comunicação — em minha experiência — é menor do que o “overhead” de criar um novo squad com pouca capacidade é que vão ficar patinando no estágio 1(falling behind).
Olhando apenas para a variável número de devs do squad a abordagem a seguir para criação de squads subsequentes seria a mesma. Portanto, a partir de 12 devs criaríamos o terceiro squad, de 16 o quarto, de 20 o quinto e assim sucessivamente. Nesse caso, vale lembrar que quando quebramos um squad de 8 devs em 2 de 4 devs cada um desses novos squads certamente não possui a sua vazão máxima. Desta forma, podemos aumentar sua vazão adicionando até mais 2 devs a cada squad.
Certamente agora você está se perguntando, não pode ser tão fácil. E não é mesmo! Olhar as outras 2 variáveis da vazão é muito importante e uma coisa que em geral não vejo líderes de tecnologia olharem de forma bem estruturada.
A idéia deste artigo não é se estender demais nessas duas variáveis mas o porquê elas são importantes e o que devemos considerar em sua composição.
Vamos começar olhando para a maturidade do squad. A primeira parte da maturidade de um squad tem a ver com o nível de senioridade de seus membros.
Um erro muito comum é ignorarmos os diversos níveis de experiência. Não vou entrar muito nesse tópico agora, sim: mais um artigo para escrever — enquanto não escrevo uma leitura interessante sobre isso é esse artigo do Martin Fowler. O importante aqui é notar que não podemos ir criando times sem levar em consideração o nível de experiência de devs. É importante manter uma proporção entre a senioridade de devs do time. 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. Se formos crescendo o time desta forma fica fácil saber o quão perto do equilíbrio o squad está. Atualmente em um mercado onde se tem falta de profissionais, vejo muitas empresas caindo na armadilha de montar squads desequilibrados em termos de senioridade, o que em geral tende a gerar diversos problemas de médio a longo prazo.
Para simplificar o uso da variável de maturidade eu gosto de abordá-la de forma binária — um squad está ou equilibrado ou desequilibrado. Quando temos squads desequilibrados sabemos que não estamos na vazão máxima e o importante aqui é garantir que ao fazer novas quebras e trazer novas pessoas para o time nos atentemos a esta variável e não aumentemos em demasia o desequilíbrio dos squads.
A última variável em nossa fórmula de equilíbrio que com certeza vou dedicar um — ou mais :) — artigos — é a saúde do squad. Para saber se um squad está saudável devemos olhar métricas que indiquem que este squad está gerando valor para o negócio. No diagrama 1 seria o equivalente a estarmos no estágio inovando. O relatório Accelerate State of DevOps ilustra bem quais são as métricas que você deve perseguir para atingir um time de performance e, mais importante: estar em um estado saudável nestas métricas tem um impacto direto na performance do negócio.
Em nossa fórmula de vazão o que considero como estado saudável são as métricas do accelerate em um patamar que consideremos saudável. As métricas que recomendo seguir são: lead time, change fail rate, deployment frequency, availability and time to restore from failure. O estado saudável dessas métricas é algo que você deve definir em sua empresa. O importante é você ser bem transparente nessa definição com todo o time e se estiver fora do estado saudável atuar para levar o time para a saúde de forma a não afetar de forma negativa a vazão do squad — o que impacta diretamente no resultado da empresa no médio a longo prazo.
Agora que você sabe de que são compostas as métricas de maturidade e saúde do squad é importante utilizá-las também na divisão dos squads. Uma coisa importante a notar é que se estas métricas estiverem em desequilíbrio elas podem contar de forma negativa na vazão. Consequentemente, é importante na hora de fazer o exercício de divisão e ou aumento de squads considerar o número de squads que estão em desequilíbrio tanto em maturidade quanto saúde.
Uma pergunta que você pode estar se fazendo agora é: só posso aumentar o número de squads quando todos os outros estão totalmente equilibrados em termos de maturidade e saúde?
A resposta é não. Esse seria um mundo utópico e a realidade das empresas e do mercado não permite isso.
A forma que recomendo é olhar a equipe de engenharia de forma holística e monitorar o quão distante estamos em relação a vazão máxima — que a essa altura já sabemos que é o somatório das vazões dos squads.
É importante entender que esse exercício deve ser feito de forma constante e o quanto mais distante da vazão máxima você está, menos eficiente é o seu time e mais “custa” para levar o time à vazão máxima. Portanto, o exercício de crescimento do time não deve ser confundido apenas com um exercício de volume. Um time menor, porém equilibrado, entrega muito mais e tem um overhead na liderança bem menor que um time grande porém desequilibrado.
Espero que você consiga com esse método crescer seu time de forma mais equilibrada e eficiente. E, one more thing: pode deixar que já estou começando a escrever os outros artigos prometidos ao longo do texto que poderão te ajudar nesta jornada fascinante que é a criação de uma empresa e de times de tecnologia.
