O modelo de #SquadGoals do Spotify falhou

2020 May 18

Artigo de Jeremiah Lee com a tradução livre e adaptação de Flávio Clésio.

…

Cover

Se o Spotify não usa “o modelo Spotify” você também não deveria usar.

…

De todos os fascínios da cultura de startup, poucos são mais desejados do que a velocidade e agilidade de uma equipe pequena. Manter esse sentimento enquanto a empresa cresce é um desafio. Em 2012, o Spotify compartilhou a sua maneira de trabalhar e sugeriu que tinha descoberto uma forma de manter essa velocidade e agilidade. 1

Fiquei empolgado em ver o modelo do Spotify em ação quando fui entrevistado para uma vaga de Product Manager [NT1], em 2017 em sua sede em Estocolmo. No entanto, a recrutadora me surpreendeu antes da primeira entrevista. Ela me avisou para não manter a expectativa de que o Spotify fosse uma utopia ágil.

Entrei para a empresa pouco depois que ela triplicou de tamanho; indo para 3.000 pessoas em 18 meses. Aprendi que o famoso modelo de squads era apenas aspiracional e nunca foi totalmente implementado. Testemunhei o caos organizacional à medida que os líderes da empresa gradualmente transitavam para estruturas de gestão mais tradicionais.

Quando perguntei aos meus colegas por que o conteúdo não foi removido ou atualizado para refletir a realidade, nunca tive uma boa resposta. Muitas pessoas ironicamente achavam que os posts eram ótimos para recrutamento.

Eu não trabalho mais no Spotify, então estou compartilhando minha experiência para esclarecer as coisas. O modelo de squads do Spotify falhou no próprio Spotify, e vai falhar com a sua empresa também.

Você não precisa acreditar em mim…

O co-autor do Modelo2 do Spotify e diversos agile coaches que trabalharam no Spotify têm dito a anos para que as pessoas não copiem este modelo. Infelizmente, a verdade não se espalha tão rápido ou tão amplamente quanto uma idéia em que as pessoas querem acreditar.

“Mesmo na época em que escrevemos, não estávamos fazendo isso [usando o modelo de squads]. Era parte ambição, parte aproximação. As pessoas realmente têm lutado para copiar algo que realmente não existia.”

— Joakim Sundén, Agile Coach no Spotify 2011-20174

“Me preocupa quando as pessoas olham para o que fazemos e acham que é uma estrutura que podem apenas copiar e implementar. … Estamos realmente nos esforçando para enfatizar que também temos problemas. Não é como se tudo fosse ‘brilhante, que tudo funciona bem e que todos os nossos squads são super incríveis’.”

— Anders Ivarsson, co-autor do whitepaper do Spotify3

Recaputulando sobre o que é o modelo de squads

Você pode ler e assistir o conteúdo original em menos de 30 minutos, ou pular para a próxima seção se você já estiver familiarizado com este modelo de squads. Aqui coloco um breve resumo.

O Spotify tinha equipes chamadas squads porque soava mais legal (sem brincadeira).

Um grupo de equipes foram organizadas em um departamento chamado tribe (tribo).

Cada equipe destinava-se a ser uma mini-startup autônoma, com um Product Manager atuando como mini-CEO por cada uma das features (NT: essas features dentro do Spotify são, por exemplo, Descobertas da Semana, Alta Rotação, listas criadas algoritmicamente, etc.).

As equipes tinham designers e engenheiros de software com uma ampla gama de especializações. A intenção era que um time tivesse todas as habilidades necessárias para o desenvolvimento das features sem precisar contar com outra equipe para o sucesso desta implementação.

Os Product Managers tinham uma estrutura de gestão tradicional. Um product manager de um time reportava-se ao diretor de produto de seu departamento (o “líder da tribo”). O mesmo para designers. Os engenheiros de software, no entanto, foram gerenciados fora da estrutura da equipe.

Os “Chapter Leads” gerenciavam os engenheiros de software especializados em um tipo específico de desenvolvimento de software dentro do departamento.

Por exemplo, todos os engenheiros de software que trabalham com APIs de backend em todos os times teriam um gerente, e todos os engenheiros trabalhassem com mobile Android dentro do mesmo departamento teriam um gerente diferente.

A intenção era permitir que os engenheiros fossem deslocados entre times dentro de um departamento para melhor atender às necessidades do negócio sem que eles tivessem que mudar de gerente.

O Spotify tentou uma organização matricial com escolhas de palavras incomuns. 1 Não funcionou bem.

Por que não funcionou?

A organização matricial resolveu o problema errado
O Spotify fixou-se na autonomia da equipe
Colaboração era uma competência assumida
Ficou difícil de mudar a mitologia do modelo de squads

A organização matricial resolveu o problema errado

A equipe ágil “full-stack” funcionou bem, mas a organização matricial dos engenheiros de software introduziu mais problemas do que resolveu.
As equipes do Spotify foram bastante longevas. O benefício de não ter que mudar de gerente ao mudar para outra equipe foi limitado.
Os gerentes de engenharia nesse modelo tinham pouca responsabilidade além do desenvolvimento de carreira das pessoas que gerenciavam. Mesmo assim, a sua capacidade de ajudar no desenvolvimento de habilidades interpessoais de pessoas era limitada. Um gerente de engenharia não gerenciaria o suficiente as outras pessoas da equipe ou estaria envolvido o suficiente no contexto diário para avaliar e gerenciar conflitos dentro da equipe.
Sem um único gerente de engenharia responsável pelos engenheiros de uma equipe, o product manager não tinha um par equivalente — o mini-CTO para sua função de mini-CEO. Não havia uma única pessoa responsável pela entrega da equipe de engenharia ou que pudesse negociar a priorização do trabalho em um nível equivalente de responsabilidade.
Quando surgiam desentendimentos dentro da equipe de engenharia, o product manager precisava negociar com todos os engenheiros de software da equipe.

Se os desenvolvedores não conseguissem chegar a um consenso, o product manager precisava escalar para tantos gerentes de engenharia quanto fossem necessários dentro das especializações de engenharia dentro da equipe para a resolução do conflito.

Para uma equipe com engenheiros de backend, web app e mobile o product manager teria que tentar resolver os desentendimentos com pelo menos 3 gerentes de engenharia. Se esses gerentes de engenharia não chegassem a um consenso, a questão da equipe em questão teria que ser escalada para o diretor de engenharia do departamento.

“Os Chapter Leads são servos-líderes que ajudam você a crescer como indivíduo. Eles não trabalham com nenhuma equipe. Eles têm relatórios diretos sobre todas as equipes. Eles não têm nenhuma responsabilidade pela entrega. Eles não estão assumindo essa responsabilidade. É fácil ver o Product Owner como o gerente da equipe.”

— Joakim Sundén, Agile Coach no Spotify4

Aprenda com os erros do Spotify:

Um time de “produto-design-engenharia” tipicamente tem mais engenheiros do que designers ou product managers. Ter um único gerente de engenharia para os engenheiros da equipe cria um caminho responsavel de escalonamento e resolução de conflitos dentro da equipe.
Os product managers devem ter um par equivalente em relação ao o time de engenharia. Os product managers devem ser responsáveis pela priorização do trabalho. Os gerentes de engenharia devem ser responsáveis pela execução dos engenheiros, o que inclui poder negociar tradeoffs entre velocidade e qualidade com o product manager.

O Spotify fixou-se na autonomia da equipe

Quando a empresa é pequena, as equipes têm que fazer uma ampla gama de trabalhos para entregar, e têm que mudar as iniciativas com frequência. À medida que uma empresa cresce de startup para scale-up, funções duplicadas entre equipes passam para novas equipes dedicadas de forma a aumentar a eficiência da organização, reduzindo a duplicação.

Com mais equipes, a necessidade de uma equipe mudar de iniciativa diminui em frequência. Ambas as mudanças permitem que as equipes pensem mais profundamente e a longo prazo sobre os problemas que estão escopo para resolver. Porém, isto não é uma garantia de uma iteração mais rápida. Toda responsabilidade que uma equipe cede para aumentar seu foco se torna uma nova dependência para com outros times (cross-team dependency).

O Spotify não definiu um processo comum para a colaboração entre equipes. Permitir que cada time tivesse uma maneira única de trabalhar significava que cada equipe precisava de uma maneira única de engajamento no que diz respeito à colaboração. A produtividade geral da organização sofreu.

O modelo do Spotify foi documentado quando o Spotify era uma empresa muito menor. Era para ser uma série de várias partes, de acordo com Anders Ivarsson. A autonomia foi a primeira parte, mas as partes de alinhamento e accountability (responsabilização) nunca foram concluídas.

Aprenda com os erros do Spotify:

Autonomia requer alinhamento. As prioridades da empresa devem ser definidas pela liderança. Autonomia não significa que as equipes podem fazer o que quiserem.
Os processos de colaboração entre os times devem ser definidos. Autonomia não significa deixar os times se auto organizarem para todos os problemas.
Como o sucesso é medido deve ser definido pela liderança para que as pessoas possam efetivamente negociar a priorização de tarefas que tenham dependência entre múltiplas equipes.
Autonomia requer accountability (responsabilização). Product Management é responsável por entregar valor. O time é responsável por entregar incrementos ‘feitos’. Equipes maduras podem justificar sua independência dependendo da sua capacidade de articular valor de negócio, risco, aprendizado e que próximo movimento ideal o time deveria tomar. 6

“Se eu fosse fazer uma coisa diferente, eu diria que não deveríamos nos concentrar tanto na autonomia.”

“Toda vez que você tem uma nova equipe, eles têm que reinventar a roda em como eles devem estar trabalhando. Talvez, apenas talvez, devêssemos ter uma “agilidade mínima viável”. Você pode começar com isso. Você é livre para optar por sair, mas as pessoas não devem ter que optar para entrar o tempo todo.”

“Em que ponto você começa a inserir esse processo? Provavelmente quando é tarde demais.”

— Joakim Sundén, Agile Coach no Spotify4

“Henrik Kniberg falou sobre como não somos tão bons em grandes iniciativas e ainda não somos tão bons em grandes iniciativas.”

“Se você tem formas inconsistentes de trabalhar, é mais difícil para as pessoas se moverem. Se é mais difícil para as pessoas se moverem, é mais provável que você tenha maneiras inconsistentes de trabalhar. Vai reforçar até que, de repente, você não esteja mais trabalhando para a mesma empresa. Você está trabalhando para esse tipo de subculturas estranhas.”

— Jason Yip. Agile Coach no Spotify desde 2015 até apresente data5

Colaboração era uma competência assumida

Embora o Spotify tenha dado às equipes controle sobre sua maneira de trabalhar, muitas pessoas não tinham uma compreensão básica das práticas ágeis.

Isso resultou em times iterando através de ajustes de processo na esperança cega de encontrar uma combinação que os ajudaria a melhorar sua entrega.

As pessoas não tinham uma linguagem comum para discutir efetivamente os problemas do processo, a educação para resolvê-los e a experiência de avaliar o desempenho. Não foi realmente ágil. Era apenas um não-cascata.

“Agile Coaches” eram consultores internos que o Spotify fornecia para ensinar práticas ágeis e sugerir melhorias nos processos. Embora bem-intencionados, não havia Agile Coaches para ajudar todas as equipes. O engajamento de um Agile Coach com um time era raramente o bastante para cobrir a conclusão de um projeto para ajudar uma equipe a avaliar o desempenho. E mais: eles não eram responsáveis por nada.

“Controle sem competência é caos.”

— L. David Marquet, Turn the Ship Around!

Aprenda com os erros do Spotify:

Colaboração é uma habilidade que requer conhecimento e prática. Os gestores não devem assumir que as pessoas têm uma compreensão existente das práticas ágeis.
Quando uma empresa se torna grande o suficiente, as equipes precisarão de suporte dedicado para orientar o planejamento dentro da equipe e a estrutura de colaboração entre as equipes. O time de program management pode ser responsável pelo processo de planejamento. Program Managers dedicados permitem equipes de forma semelhante à forma como product managers e gerentes de engenharia dedicados fazem com suas respectivas competências.

Ficou difícil de mudar a mitologia do modelo de squads

Quando o Agile Scrum introduziu novos significados a um monte de palavras como burn-down e sprint, ele o fez porque introduziu conceitos novos que precisavam de nomes.

O Spotify introduziu no vocabulário missões (missions), tribes (tribos), squads, guildas, e os Chapter Leads para descrever sua maneira de trabalhar.

Isso deu a ilusão de que o Spotify havia criado algo digno de precisar aprender através da escolha de palavras incomuns. No entanto, se removermos os sinônimos desnecessários das ideias, o modelo do Spotify se revela como uma coleção de equipes multifuncionais com muita autonomia e uma estrutura de gestão ruim.

Não caia nessa.

Se o Spotify tivesse se referido a essas ideias usando os seus nomes originais, talvez pudesse ter avaliado a falha do seu modelo de forma mais justa, ao invés simplesmente ter que enfrentar a mudança de sua identidade cultural para encontrar processos internos que funcionassem bem.

Aprenda com os erros do Spotify:

A maioria das empresas só pode sustentar algumas áreas de inovação. Processos internos raramente são uma área primária de inovação que diferencia uma empresa no mercado. Estudar o passado permite que as empresas escolham melhores áreas para a inovação.
Otimize para entender. Cada coisa nova que alguém deve aprender para ser produtivo deve sofre uma avaliação sobre o seu valor.
Nomenclaturas como unidades de negócios, departamentos, times e gerentes comunicam de forma mais eficaz as funções e responsabilidades dentro de uma estrutura organizacional do que os sinônimos do Spotify, sinônimos estes que falharam com seu criador.

Ao invés de seguir este modelo, faça isso

(Brincadeira. Não existem correções rápidas.)

Você pode ter descoberto o modelo do Spotify porque estava tentando descobrir como estruturar suas equipes. Não pare por aqui. Continue pesquisando. Líderes de empresas que resistiram a testes mais longos de tempo escreveram muito mais do que o Spotify blogou.

Os humanos têm tentado descobrir como trabalhar juntos desde que existe a humanidade. A era industrial e a era da informação mudaram algumas das restrições para isto, mas acadêmicos que estudam teorias de organizações encontraram verdades atemporais sobre o que os humanos precisam para serem bem-sucedidos dentro de uma coletividade.

Acontece que o Spotify em 2012 não tinha descoberto como manter a velocidade e agilidade de uma pequena equipe em uma grande organização. A empresa evoluiu além de seu modelo homônimo e olhou para fora de si para encontrar melhores respostas. E você deveria fazer o mesmo.

Algumas das minhas recomendações relacionadas aos tópicos abordados pela maneira de trabalho do modelo do Spotify:

Mais de 200 pessoas em seu produto — engenharia — organização de design? O Scaled Agile Framework funcionou bem para a Fitbit quando trabalhei lá.
Menos de 200 pessoas? Shape Up by Basecamp é como pretendo estruturar minha próxima startup.
Essential Scrum por Kenneth S. Rubin
Team topologies por Matthew Skelton e Manuel Pais

Notas e Citações

1: Scaling Agile @ Spotify whitepaper, Spotify Engineering Culture

2: Anders Ivarsson e Henrik Kniberg foram os autores do whitepaper Scaling Agile @ Spotify. Henrik esclareceu seu status de criador em 2015: “as pessoas às vezes parecem fazer a suposição de que eu inventei o modelo do Spotify. Bem, eu certamente não! Sou apenas o mensageiro. … O modelo do Spotify é o resultado de muitas pessoas colaborando e experimentando ao longo do tempo, e muitos aspectos do modelo foram inventados sem o meu envolvimento. Eu certamente não gostaria de levar o crédito das pessoas envolvidas”.

3: Episódio 112: Dentro do Spotify com Anders Ivarsson, The Agile Revolution, 2016

4: Você pode fazer melhor do que o modelo spotify por Joakim Sundén, vídeo 2017 video, slides

5: Como as coisas ainda não funcionam no Spotify e como estamos tentando resolvê-lo por Jason Yip, vídeo de 2017 video, slides

6: Equilibrando autonomia com responsabilidade por Edwin Dando

Recursos adicionais

Se mais de 2.200 palavras relatando a minha experiência em primeira mão e as palavras de 4 funcionários do Spotify não foram suficientes, leia como o modelo do Spotify não funcionou para essas pessoas fora do Spotify.

Ilustração de capa inspirada em Bad Blood por Taylor Swift, que sabe algo sobre metas de squads, mas não de direitos autorais. Se você esqueceu 2015, aqui está um exame do termo metas do squad.

Obrigado a Roland Siebelink e Jason Harmon por revisar os rascunhos deste artigo.

Notas de Tradução

[NT1] - Os termos em inglês de algumas posições foram mantidos intencionalmente dado que o texto é orientado para pessoas que conhecem essas profissões.

[NT2] - Devido às diferenças de linguagem e de estilo, eu adaptei algumas partes para termos mais comuns em português.

[NT3] - Por uma questão de estilo, alguns parágrafos foram “quebrados” para dar uma melhor experiência de leitura; em especial em dispositivos móveis