No passado, publicamos um artigo traduzido do Blog Tryplebyte sobre como entrevistar Engenheiros de Software. Além disso, entrevistamos Camille Fournier, e ela nos contou um pouco da sua história e mostrou uma visão interessante sobre liderar times de tecnologia. Hoje voltamos a falar sobre times de produto, mas dessa vez abordando as particularidades da metodologia de uma das empresas mais inovadoras de 2018, segundo a Fast Company: o modelo Spotify.

A Spotify é uma empresa sueca, responsável por aplicações web e mobile homônimas de streaming de música, que conta com mais de 200 milhões de usuários. A empresa é conhecida por outras organizações de tecnologia como referência na organização de seus times orientados para produto.

Pensando na relevância do tema e nas implicações dele para times de Gente e Gestão ou, ainda, para lideranças, resolvemos escrever esse breve estudo de caso introdutório sobre como funciona esse desenho organizacional. Adicionamos também uma reflexão sobre a eficiência e o funcionamento de processos de gestão de desempenho nesse tipo de modelo. Acompanhe a leitura!

Como surgiu o Spotify?

O Spotify nasceu numa época em que era relativamente fácil obter arquivos de música no formato MP3 (para quem tinha acesso à Internet, é claro), no entanto, essa obtenção comumente se dava por meio da prática de pirataria.

Estamos falando do ano de 2006. Naquela época, existiam sites que facilitavam a aquisição por meio ilegais não só a músicas, como também a livros, vídeos e filmes. No entanto, um sueco apaixonado por música, chamado Daniel Ek, juntamente ao empresário Martin Lorentzon, resolveu unir o útil ao agradável:

  • de um lado, estavam usuários sedentos por músicas, mas que, para obtê-las por meios legais, precisariam pagar por elas e que, assim, consideravam mais vantajoso se arriscarem a obtê-las pela pirataria;
  • de outro, as empresas do mercado da música (gravadoras e distribuidoras), que entendiam que precisariam se adequar ao novo modelo de disseminação desse tipo de conteúdo, que cada vez mais se disseminava digitalmente.

Assim, criar uma forma com que os usuários pudessem acessar essas músicas a um valor justo e que isso beneficiasse também as empresas de música foi o principal incentivador para a criação do Spotify.

No entanto, o sucesso não foi instantâneo. Foram necessárias inúmeras reuniões para convencer gravadoras e distribuidoras de música a embarcarem na ideia. Isso aconteceu dois anos depois, em 2008. E, em 2011, ao chegar nos Estados Unidos, foi quando o Spotify deslanchou de vez, alcançando atualmente a marca de 205 milhões de assinantes e chegando ao total de mais de 500 milhões de usuários.

Como funciona o modelo Spotify Squads?

Mesmo depois do sucesso mundial, estando presente em mais de 65 países no mundo, o Spotify nunca deixou de se reinventar. Exemplo disso são as já tão esperadas retrospectivas musicais individuais dos usuários ao final de cada ano. Nessa época, são várias as postagens em redes sociais em todo o mundo sobre quais foram as músicas mais ouvidas por cada pessoa.

Mas como esse sucesso se mantém? Bom, uma boa explicação para isso está no modelo Spotify de squads. Ou seja, na forma como os times de tecnologia da empresa se organizam para criar novas features, atualizar design, otimizar o algoritmo, entre outras coisas. Vamos conhecer mais de perto esse modelo adiante!

Estrutura interna

A estrutura interna das equipes da Spotify sofreu enorme influência de práticas ágeis (Agile, Scrum, Extreme Programming, etc), de autores como Tom e Mary Poppoendieck e Tom DeMarco, além de conceitos de autogestão, ligados às metodologias ágeis, como Jurgen Appelo.

A organização básica é a matriz com times orientados vertical e horizontalmente. Os grupos orientados verticalmente (squads e tribos) são agrupados por produto, ou seja, por features ou grupos de features correlacionados. Os grupos orientados horizontalmente (chapters e guilds) são agrupados por skill ou interesse, e visam a troca de melhores práticas, experiências, e desafios, onde a empresa tenta obter sinergias internas de conhecimento e produtividade.

Times de produto Spotify - Captura de tela do aplicativo do Spotify para web, apresentando suas funcionalidades.

Cada Squad é responsável por uma das áreas destacadas na imagem acima. Por serem bastante autogeridos, nos times não existem figuras tão marcantes de liderança formal, mas sim lideranças mais orgânicas, bastante fundadas nos aspectos técnicos/funcionais do trabalho. Assim, apenas chapters e squads tem lideranças claramente identificadas. PO (product owner)/PM (product manager) direciona o quê é feito (what), e o líder de chapter direciona como isso é feito (how).

Você também pode gostar destes conteúdos:

👉 Conheça a cultura organizacional de alto desempenho da Netflix

👉 Missão, visão e valores: o que são, exemplos e como escrever

👉 Missão, Visão e Valores do Google: conheça a cultura da empresa

Squads

Squads são a unidade básica de organização dos times, usualmente em torno de uma feature, ou subsecção de uma funcionalidade. Podem ter de 3 a 10 membros, e devem ser autônomas a ponto de conterem expertise no grupo para desenvolver todos os aspectos do produto: da concepção à prototipação, design, desenvolvimento, e deployment.

Times de produto Spotify - Exemplo de organograma de um squad.

Tribo

A tribo (tribe) é o segundo nível de agrupamento, e pode conter uma série de squads que tenham funcionalidades e objetivos similares. Os squads de uma tribo ficam fisicamente próximos uns dos outros, para haver comunicação fluida.

O tamanho máximo de uma tribo segue, no Spotify, a limitação do número de Dunbar, ou seja, em torno de 100 pessoas: número derivado de pesquisas biológicas e evolutivas que mede a quantidade máxima de espécimes que tendem a conviver juntos em “sociedade” na natureza. Em tese, o ser humano seria incapaz de manter contato social (razoavelmente próximo) com mais de 100 outros humanos, número este que vem sendo constantemente desafiado pelo advento das redes sociais.

Por fim, os squads-membro das tribos se encontram periodicamente para sincronizarem seus esforços, apresentarem seu trabalho, e trocarem experiências.

Times de produto Spotify - Exemplo de  organograma de uma tribo (conjunto de squads relacionados).

Você também pode gostar destes conteúdos:

👉 Clima Organizacional: entenda o que é e a sua importância

👉 Indicadores de clima organizacional: confira os 10 principais!

👉 Pesquisa de clima organizacional: entenda o que é e como aplicar

Chapter

O chapter é um grupo horizontal (portanto orientado por função/afinidade) que congrega profissionais com responsabilidades e skills parecidos. Pode haver, por exemplo, um chapter de designers de UI, ou de desenvolvedores web de front-end. Chapters são geralmente contidos dentro de tribos, e se encontram com frequência para troca de ideias, melhores práticas e desafios que estejam enfrentando. No chapter, há um líder, que serve como “técnico” e guia o aprendizado e o desenvolvimento funcional dos membros.

Times de produto Spotify - Exemplo de organograma de um chapter (time formado por profissionais com funções semelhantes em squads diferentes).

Guilda

Definição de Guilda (Google):

  • associação que agrupava, em certos países da Europa durante a Idade Média, indivíduos com interesses comuns (negociantes, artesãos, artistas) e visava proporcionar assistência e proteção aos seus membros.”

Guilds, ou guildas, são talvez os grupos mais difíceis de se definir no Spotify. Uma guilda é um grupo de profissionais, que pode ser de squads e tribos diferentes, e que se une para trocar experiências, aprendizados, e melhores práticas sobre temas de interesse comum.

Em muitos casos, a guilda é composta por chapters correlacionados (por exemplo, todos os chapters de designers de todas as tribos da Spotify) somado a alguns “agregados" de outras áreas que se interessem pelo tema. As guildas costumam ter coordenadores, que lideram os temas a serem discutidos e organizam os encontros.

Times de produto Spotify - Exemplo de organograma de uma guild (profissionais com interesses semelhantes).

A organização dos times de produto na Spotify está ganhando enorme evidência entre empresas product-centric, como empresas de tecnologia e aplicativos. E esse crescimento vem chegando com cada vez mais força no Brasil.

O agrupamento por produto desponta como provável estrutura ideal que maximiza a colaboração de profissionais com áreas de expertise diferentes, e, ao mesmo tempo, maximizando a qualidade e quantidade dos outputs através da metodologia ágil.

[Material de apoio] Saiba como o Google aplica a gestão de desempenho   Com esse material de apoio você terá em suas mãos um resumo estratégico com todas as práticas de gestão de desempenho aplicadas pelo Google.

Quais são os benefícios do Modelo Spotify Squads?

Agora que já vimos como funciona o Modelo Spotify Squads, confira os seus principais benefícios para a organização e para os profissionais envolvidos.

Multidisciplinaridade das equipes

O principal benefício de qualquer modelo que envolva squads está justamente no fato de essa ser uma organização que se beneficia da multidisciplinaridade das equipes. Isso significa pessoas com diferentes especialidades e conhecimentos atuando em conjunto, de forma complementar.

Com isso, ganha-se muito em inovação, criatividade e resultados, visto que diferentes visões podem trazer transformações ainda maiores comparadamente a um grupo de pessoas com mesma formação e/ou interesses.

Atuação focada

O fato de se dividirem conforme as “áreas” do aplicativo faz com que as squads tenham bastante foco sobre em qual questão vão atuar, podendo se aprofundar na área que lhes é delegada.

Dessa maneira, são maiores as chances de especialização e acompanhamento dos resultados de determinadas estratégias definidas e aplicadas em conjunto à área que lhes cabe.

Quais são os desafios de gente e gestão no modelo Spotify?

A auto-organização desses times, no entanto, cria alguns desafios com os quais as áreas de gente e gestão, people operations, e afins, ainda se descabelam para resolver. Resumimos a seguir os principais deles!

Falta de organização

“Eu acredito que o desenvolvimento do software Agile negligenciou a importância da gestão (de linha). Se os gestores não sabem o que fazer, nem o que esperar da organização do software Agile, como irão se sentir envolvidos em uma transição para o desenvolvimento do software Agile? Qual é a mensagem que o Agile quer passar aqui? Se é 'nós não precisamos de gestores', não é de admirar que as transições Agile sejam obstruídas ao redor do globo” [tradução: Appelo, Management 3.0].

Falta de um líder claro

Em muitos casos os profissionais sentem falta de um “line manager” que seja ultimamente quem os lidera. O PO, muitas vezes, tem menos experiência profissional do que os membros do squad (engenheiros, designers, etc), e não é preparado para liderar temas como feedback, coaching, gestão de carreiras, e compensation.

Ele é o visionário de produto. Ponto. Por outro lado, o líder de chapter (grupo de profissionais em uma tribo com atribuições e skills parecidos) às vezes está pouco presente no dia a dia do profissional, e foca, por interesse pessoal, muito mais nos aspectos técnicos do trabalho. Na Qulture.Rocks, entendemos que o líder de chapter deveria ser o ‘gestor funcional’ do profissional, fazendo one-on-ones e cuidando dos seus assuntos de carreira, feedback, desenvolvimento, etc.

Pouca visibilidade de desenvolvimento

Outro problema presente nos squads multifuncionais, mas que deriva de uma dificuldade mais ampla de equipes altamente colaborativas, é a dificuldade de achar accountability clara de desenvolvimento individual. Empresas estão acostumadas a sistemas quantitativos, que possam quantificar performance como uma nota. Por isso, tendem a preferir cortar caminho e atribuir metas individuais aos colaboradores, sejam eles engenheiros de software, vendedores, ou designers. Mas sabemos que metas boas são metas de resultado de negócio, e fica extremamente difícil conseguir atribuir um resultado de negócio a um indivíduo em um time multifuncional.

Por exemplo, imaginemos que um dos squads da Spotify seja responsável pelo motor de recomendação de músicas e bandas presente na home do aplicativo web. Essa equipe é composta por um engenheiro de back-end, que liga essa funcionalidade aos algoritmos da empresa; por um engenheiro de front-end, que programa a interface visual; por um designer, que desenha a UX e a UI dessa funcionalidade; e por um engenheiro de operações, que cuida do deployment do código.

Podemos atribuir um resultado claro a essa equipe? Penso que sim. Se as recomendações forem boas, imaginemos, a taxa de cliques nas músicas e bandas recomendadas será alta. Além disso, ao clicarem e ouvirem/testarem mais de perto as recomendações, os usuários adicionarão mais recomendações às suas playlists à medida que forem melhores as próprias recomendações. Portanto, temos duas taxas de conversão que podem se tornar as metas/KPIs de resultado a serem medidos como proxy da performance do time.

Pois bem, mas poderíamos quebrar esses resultados de negócio a cada um dos membros da equipe, para podermos medir exatamente a performance de cada um? Será? Quanto do resultado das taxas de conversão pode ser atribuído ao engenheiro de back-end vs. o designer? Impossível.

Assim, dada essa grande dificuldade, gestores e líderes pelo mundo passam a atribuir metas de esforço a esses profissionais: se o designer cumprir com todas as necessidades do time nos sprints, ele terá performado. Algumas empresas estabelecem cerimônias de avaliação das entregas, que passam, se aprovadas, a serem ‘contabilizadas’ como resultados entregues.

No entanto, é importante ressaltar que esforço — nesse caso a entrega das telas prontas pelo designer no prazo estipulado pelo time — não é sinônimo de resultado. O resultado é unicamente passível de mensuração pela taxa de conversão de usuários (ou outra medida de negócio estabelecida pelo time). Fazer exercício não é sinônimo de emagrecimento!

Conclusão

O foco desse estudo de caso não é discutir o tema de performance em times multifuncionais, mas é importante que as empresas praticantes do Agile e da organização de times de produto como a da Spotify entendam que não há fórmula simples adaptável à sua realidade, e que metas individuais não serão a resposta.

Será absolutamente necessário que a performance de cada membro de um squad seja uma função dos resultados de negócio produzidos pelo próprio squad e por uma avaliação 360 graus, subjetiva, da contribuição desse membro para a performance do time, no formato de ideias, resolução de conflitos, liderança emergente, priorização, etc.

No Brasil, duas empresas que conhecemos e que sabemos que se organizam de maneira similar são a ContaAzul, startup de Joinville que lidera uma revolução na gestão financeira de pequenos e médios empresários por todo o Brasil; e a Nubank, startup de São Paulo com o cartão de crédito mais desejado da história dos serviços bancários. Em ambos os casos, o processo vem sendo refinado (e, vale dizer, a experimentação e iteração constante é a regra nas empresas ágeis), e adaptado às necessidades de seus negócios e da cultura brasileira.

Há outras indústrias que podem se beneficiar de modelos inspirados nos squads, tribos, chapters, e guildas do Spotify: as empresas de consultoria, que também se organizam em times multifuncionais e alocados por projeto.

Agora que você já sabe como funciona o Modelo Spotify Squads, quer conhecer a cultura organizacional de alto desempenho da Netflix? É só continuar no Blog e conferir o conteúdo que produzimos sobre o assunto!