A Spotify é uma empresa Sueca responsável pelas aplicações web e mobile homônimas de streaming de música, que conta com mais de 60 milhões de usuários. A empresa é conhecida por outras organizações de tech como referência na organização de seus times orientados para produto, e por isso resolvemos escrever esse breve case study introdutório sobre como funciona esse desenho organizacional.
A estrutura das equipes da empresa 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 auto-gestã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 têm como objetivo a troca de melhores práticas, experiências, e desafios, onde a empresa tenta obter sinergias internas de conhecimento e produtividade.
Cada Squad é responsável por uma das áreas destacadas na imagem acima.
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 dentro do grupo para desenvolver todos os aspectos do produto: da concepção à prototipação, design, desenvolvimento, edeployment.
A tribo (tribe) é o segundo nível de agrupamento, e pode conter uma série de squadsque tenham funcionalidades e objetivos similares. As squads de uma tribo ficam fisicamente próximas umas das outras, para que haja comunicação fluida.
O tamanho máximo de uma tribo segue, no Spotify, a limitação do número de Dunbar [2] (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 não seria capaz 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), ou seja, em torno de 100 pessoas.
Por fim, as squads-membro das tribos se encontram periodicamente para sincronizarem seus esforços, apresentarem seu trabalho, e trocarem experiências.
Chapter
O chapter é um grupo horizontal (portanto orientado por função/afinidade) que congrega profissionais com responsabilidades e skills parecidos. Pode haver, por exemplo, umchapter 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 idéias, 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.
Guilda
Definição de Guilda (Google):
guilda
-
substantivo feminino 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.
Conclusão
A organização dos times de produto na Spotify está ganhando enorme evidência entre empresas product-centric, como empresas de tecnologia e aplicativos. 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 do output através da metodologia ágil.
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 aqui os principais deles:
-
Falta de organização: “I believe that Agile software development has overlooked the importance of (line) management. If managers don’t know what to do and what to expect in an Agile software organization, how are they supposed to feel involved in a transition to Agile software development? What is the message of Agile here? If it’s ‘we don’t need managers,’ it’s no wonder Agile transitions are obstructed all over the world” [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 da 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 dentro de 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, cuidando dos seus assuntos de carreira, feedback, desenvolvimento, etc.
-
Pouca visibilidade de performance: Outro problema presente nos squads multifuncionais, mas que deriva de uma dificuldade mais ampla de equipes altamente colaborativas, é a dificuldade de achar accountability claro de performance 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 funcionários, 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, vamos imaginar 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 em 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 que possamos 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, vis-a-vis 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 dentro do 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.
O foco desse case study não é discutir o tema de performance em times multifuncionais (se quiser falar mais sobre isso, nos mande um email), 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 uma squad seja uma função dos resultados de negócio produzidos pela squad e por uma avaliação 360-graus, subjetiva, da contribuição desse membro para a performance do time, no formato de idéias, resolução de conflitos, liderança emergente, priorização, etc.
No Brasil, as 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 que tem 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.
A outras indústrias que podem se beneficiar de modelos inspirados nas squads, tribos, chapters, e guildas do Spotify: as empresas de consultoria, que também se organizam em times multi-funcionais e alocados por projeto.
Referências
Lean Software Development: An Agile Toolkit (Amazon)
Peopleware: Productive Projects and Teams (Amazon)
Vídeos da série “Spotify engineering culture"
[1] A diferença entre um PO e um PM não é muito clara, podendo variar bastante de empresa para empresa, especialista para especialista, e de CTO para CTO. Em algumas empresas, há uma maior distinção entre os conceitos de PO e PM: o PM é mais focado em produto do ponto de vista mercadológico, e o PO mais focado em gerir o roadmap de produto do ponto de vista do desenvolvimento. Ambos podem coexistir, ou um dos dois assumir parte da responsabilidade do outro. Na Spotify, o PO tem a responsabilidade de direcionar o roadmap de produto.
[2] “Early in his career, Robin Dunbar, a British anthropologist, found himself observing the dynamics of gelada baboons in Ethiopia, hoping his work might shed light on the evolution of humans. Over time, Dunbar noticed that different species of monkeys, baboons, and apes tended to live in different-sized troops (or troops). Interestingly, the size of a troop seemed to be related to the size of the species’ brain, or more specifically, the size of the neocortex… Dunbar theorised that primate brains evolved to be quite large so that individuals could keep track of their social relationships with others in the loop [3]… The obvious next step was to project the community size that humans might gravitate toward, based on the relative size of the human neocortex. The answer that popped out of Dunbar’s calculations was… 150.” Tom e Mary Poppendieck, The Lean Mindset
[3] É bastante discutível que Dunbar tenha concluído pela relação de causalidade, e não apenas por uma correlação. Seria praticamente impossível dizer se os humanos cresceram cérebros para lidar com grupos, ou se passaram a se agrupar com mais colegas em função do cérebro maior. Um exemplo da falácia da causalidade.