Falhou #ObjetivoDeSquad

Jeremiah Lee - 19/04/2020 Traduzido por Erika Assis

O Spotify não usa “ o modelo Spotify” e você também não deveria.

De todos os atrativos da cultura de startups, poucos são mais desejáveis do que a velocidade e agilidade de uma pequena equipe. Manter esse sentimento à medida que a empresa cresce é um desafio. Em 2012, o Spotify compartilhou sua maneira de trabalhar e sugeriu que já tinha tudo resolvido.

Fiquei animado para ver o modelo Spotify em ação quando fiz uma entrevista para uma função de gerenciamento de produto em sua sede em Estocolmo em 2017. No entanto, a recrutadora me surpreendeu antes da primeira entrevista. Ela me alertou para não esperar que o Spotify fosse uma utopia ágil.

Entrei na empresa depois que ela triplicou de tamanho para 3.000 pessoas em 18 meses. Aprendi que o famoso modelo de Squads sempre foi uma aspiração e nunca havia sido totalmente implementado. Testemunhei o caos organizacional à medida que os líderes da empresa faziam a transição gradativa para estruturas de gestão mais tradicionais.

Quando perguntei aos meus colegas de trabalho por que o conteúdo não foi removido ou atualizado para refletir a realidade, nunca obtive uma boa resposta. Muitas pessoas ironicamente pensaram que as postagens eram ótimas 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 Spotify e também vai falhar na sua empresa.

Mas você não precisa acreditar apenas na minha palavra.

O co-autor do Modelo Spotify e vários treinadores ágeis que trabalharam no Spotify vêm dizendo às pessoas para não copiá-lo por anos. Infelizmente, a verdade não se espalha tão rápido ou amplamente quanto uma ideia em que as pessoas querem acreditar.


“Mesmo na época em que escrevemos isso, não estávamos fazendo isso. Era em parte ambição, em parte aproximação. As pessoas realmente lutaram para copiar algo que realmente não existia.” - Joakim Sundén, agile coach no Spotify 2011–2017


“Fico preocupada quando as pessoas olham para o que fazemos e pensam que é uma estrutura que podem simplesmente copiar e implementar. (…) Estamos realmente nos esforçando para enfatizar que também temos problemas. Nem tudo é ‘brilhante e tudo funciona bem e todos os nossos squads são super incríveis’." - Anders Ivarsson, co-autor do Spotify Whitepaper


Recap

Você pode ler e assistir ao conteúdo original em menos de 30 minutos ou pular para a próxima seção se estiver familiarizado. Aqui está um breve resumo.

O Spotify tinha times que se chamavam squads porque parecia mais legal (sem brincadeira). Um grupo de equipes foi organizado em um departamento denominado tribo. Cada equipe deveria ser uma mini-startup autônoma, com um gerente de produto atuando como mini-CEO para a área de uma feature. As equipes tinham designers e engenheiros de software com uma série de especializações. A intenção era que uma equipe tivesse todas as habilidades necessárias sem a necessidade de contar com outra equipe para atingir os objetivos.

Os gerentes de produto tinham uma estrutura de gerenciamento tradicional. Um gerente de produto de uma equipe se reportava ao diretor de produto de seu departamento ("líder da tribo"). O mesmo vale para designers. Os engenheiros de software, no entanto, eram gerenciados fora da estrutura da equipe.


“Chapter leads” gerenciavam engenheiros de software especializados em um tipo específico de desenvolvimento de software em todo o departamento. Por exemplo, todos os engenheiros de software trabalhando em APIs de back-end em todas as equipes do departamento teriam um gerente e todos os engenheiros de Android no departamento teriam um gerente diferente. A intenção era permitir que os engenheiros fossem movidos entre as equipes dentro do departamento para melhor atender aos requisitos de negócios sem que eles precisassem mudar de gerente.


O Spotify tentou uma estrutura de equipe matricial de longa duração com escolhas de palavras incomuns. Não funcionou bem.


Por que não funcionou

  1. O gerenciamento matricial resolveu o problema errado

  2. Fixou-se na autonomia da equipe

  3. A colaboração era uma competência assumida

  4. A “mitologia” tornou-se difícil de mudar


O gerenciamento matricial resolveu o problema errado

A equipe ágil “full stack” trabalhou bem, mas o gerenciamento matricial dos engenheiros de software introduziu mais problemas do que resolveu.

  • As equipes do Spotify tiveram uma vida bastante longa. O benefício de não ter que mudar de gerente ao mudar para outra equipe era limitado.

  • Os gerentes de engenharia nesse modelo tinham pouca responsabilidade além do desenvolvimento da carreira das pessoas que administravam. Mesmo assim, sua capacidade de ajudar no desenvolvimento de habilidades interpessoais de pessoas era limitada. Um gerente de engenharia não administraria o suficiente das outras pessoas da equipe ou se envolveria o suficiente no contexto diário para avaliar de forma independente o conflito dentro da equipe.

  • Sem um único gerente de engenharia responsável pelos engenheiros em uma equipe, o gerente de produto carecia de um colega equivalente - doo mini-CTO até o 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 surgiram divergências dentro da equipe de engenharia, o gerente de produto precisava negociar com todos os engenheiros da equipe. Se os engenheiros não chegassem a um consenso, o gerente de produto precisava escalar para tantos gerentes de engenharia quantas especializações de engenharia havia na equipe. Uma equipe com engenheiros de back-end, aplicativos da Web e aplicativos móveis teria pelo menos três gerentes de engenharia que precisariam ser envolvidos. Se esses gerentes de engenharia não pudessem chegar a um consenso, o problema de uma única equipe teria que ser escalado para o diretor de engenharia do departamento.


“Chapter leads/ Líderes de Capítulo são líderes-servidores que o ajudam a crescer como indivíduo. Eles realmente não trabalham com nenhuma equipe. Eles têm subordinados diretos em todas as equipes. Eles não têm realmente 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 Spotify


Aprenda com os erros do Spotify:

  • Uma equipe de engenharia - design - de produto, tipicamente contém mais engenheiros que designers ou gerentes de produto. Ter um único gerente de engenharia para os engenheiros no time, cria um sério caminho de escalada para o conflito dentro da equipe.

  • Os gerentes de produto devem ter um par equivalente para engenharia. Os gerentes de produto 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 a capacidade de negociar balanceamentos de velocidade e qualidade com o gerente de produto.


Spotify se fixou na autonomia da equipe


Quando uma empresa é pequena, as equipes têm que fazer uma ampla gama de trabalhos para entregar e precisam mudar as iniciativas com frequência. À medida que uma empresa cresce desde a inicialização até a ampliação, as funções duplicadas entre as equipes são transferidas para novas equipes dedicadas a aumentar a eficiência da organização, reduzindo a duplicação. Com mais equipes, a necessidade de uma equipe mudar a iniciativa diminui frequentemente. Ambas as mudanças permitem que as equipes pensem mais profundamente e a longo prazo sobre os problemas que pretendem resolver. A iteração mais rápida, entretanto, não é garantida. Cada responsabilidade que uma equipe cede para aumentar seu foco torna-se uma nova dependência entre as equipes.

O Spotify não definiu um processo comum para colaboração entre equipes. Permitir que cada equipe tivesse uma forma única forma de trabalhar significava que cada equipe precisava de uma forma única de engajamento ao colaborar. A produtividade geral da organização foi prejudicada.

O modelo 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 fez o primeiro corte, mas as partes sobre alinhamento e responsabilidade 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 para colaboração entre equipes devem ser definidos. Autonomia não significa deixar equipes se auto organizarem frente a todos os problemas.

  • A forma como o sucesso é medido deve ser definida pela liderança para que as pessoas possam negociar com eficácia a priorização das dependências entre equipes.

  • Autonomia requer responsabilidade. A gestão do produto é responsável pelo valor. A equipe é responsável por entregar incrementos "prontos". Equipes maduras podem justificar sua independência com sua capacidade de articular valor de negócios, risco, aprendizado e o próximo passo.

A colaboração era uma competência assumida


Embora o Spotify desse às equipes controle sobre sua forma de trabalhar, muitas pessoas não tinham um conhecimento básico de práticas ágeis. Isso resultou em equipes iterando por meio de ajustes de processo na esperança cega de encontrar a combinação que os ajudaria a melhorar sua entrega. As pessoas careciam de uma linguagem comum para discutir com eficácia os problemas do processo, a educação para resolvê-los e a experiência para avaliar o desempenho. Isso não era realmente ágil. Apenas não era um modelo waterfall.


“Agile coaches” eram consultores internos que Spotify fornecia às equipes para ensinar e sugerir melhorias de processo. Embora bem intencionados, não havia coaches suficientes para ajudar todas as equipes. O envolvimento de um coach com uma equipe raramente era longo o suficiente para abranger a conclusão de um projeto para ajudar uma equipe a avaliar o desempenho. Além disso, eles também 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:

  • A colaboração é uma habilidade que requer conhecimento e prática. Os gerentes não devem presumir que as pessoas já tenham uma compreensão de práticas Ágeis.

  • Quando uma empresa se torna grande o suficiente, as equipes precisam de suporte dedicado para orientar o planejamento dentro da equipe e estruturar a colaboração entre as equipes. O gerenciamento do programa pode ser responsável pelo processo de planejamento. Gerentes de programa dedicados capacitam as equipes de maneira semelhante a como os gerentes de produto e gerentes de engenharia dedicados fazem com suas respectivas competências.

A mitologia é difícil de mudar


Quando o Agile Scrum introduziu novos significados para um monte de palavras como burn-down e sprint, ele o fez porque introduziu novos conceitos que precisavam de nomes. Spotify introduziu o vocabulário de missões, tribos, squads, guildas e líderes de capítulo para descrever sua maneira de trabalhar. Deu a ilusão de que havia criado algo digno de precisar aprender escolhas incomuns de palavras. No entanto, se removermos os sinônimos desnecessários das ideias, o modelo Spotify é revelado como uma coleção de equipes multifuncionais com muita autonomia e uma estrutura de gestão pobre. Não caia nessa. Se o Spotify tivesse se referido a essas ideias por seus nomes originais, talvez pudesse tê-las avaliado de forma mais justa quando falharam, em vez de ter que enfrentar a mudança de sua identidade cultural simplesmente para encontrar processos internos que funcionassem bem.


Aprenda com os erros do Spotify:

  • A maioria das empresas pode sustentar apenas algumas áreas de inovação. Processos internos raramente é uma área primária de inovação que diferencia uma empresa no mercado. Estudar o passado permite que as empresas escolham áreas melhores para inovação.

  • Otimize para compreender. Cada coisa nova que alguém precisa aprender para ser produtivo em sua organização deve ser avaliada por seu valor.

  • Unidades de negócios, departamentos, equipes e gerentes comunicam com mais eficácia as funções e responsabilidades da estrutura organizacional do que os sinônimos do Spotify e não estão vinculados a uma forma de trabalho que falhou com seu criador.

Artigo original: http://bit.ly/3rOhOiZ

© 2021 por Product Guru's.