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 é:

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 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 , 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 é:

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 é para conseguir fazer O risco que sempre corremos é abrirmos mais frentes que conseguimos lidar por vez e perdemos nossa capacidade de ter e 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 de um

E, para entender a vazão da “máquina” que é o time de tecnologia, temos que entender a unidade fundamental deste time: .

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 .

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 — máxima de um squad depende de diversas variáveis, as principais são: no squad, sua e sua .

4 possíveis estágios de um squad

O diagrama acima — retirado de an elegant puzzle — mostra os 4 estágios possíveis de um squad. O ideal é termos o squad no ( ) — esse seria o squad trabalhando com sua . Consequentemente, se quisermos ter nossa equipe de produto e tecnologia com a vazão máxima todos os squads deveriam estar no . 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 . 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 () — e, consequentemente, podemos do time colocando mais pessoas. Mas isso também é papo para outro artigo.

Outra variável importante é a 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 . 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, ou , dos squads que são as . Essas métricas são bons de um time e nos ajudam a buscar e . 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 para a e acho que já está claro que nosso objetivo como líder de engenharia é buscar a de de . É claro que a é uma . Porém, em minha experiência, o na busca da faz com que a vazão do time de engenharia sempre esteja crescendo e — como ilustrado em accelerate — isso tem um .

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 , que teremos a oportunidade de abordar em breve no próximo artigo da série e também a . 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 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 ou 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 . 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 seria o equivalente a estarmos no estágio inovando. O relatório 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: , , , and 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 e 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 e ?

A resposta é . 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, 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.

--

--

I love building teams and technology. If you want to read my articles in portuguese please go to:https://bernardocarneiro.com.br/

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store