A Realidade por Tr\u00e1s do Modelo Spotify<\/em>: Desafios e Li\u00e7\u00f5es Aprendidas<\/h3>\n\n\n\n<\/p>\n\n\n\n
H\u00e1 alguns anos, o pessoal da equipe por tr\u00e1s do servi\u00e7o de streaming de m\u00fasica Spotify<\/em> escreveu sobre a estrutura organizacional Agile<\/em> que eles implementaram internamente. O chamado \u2018Modelo Spotify<\/strong>\u2019, amplamente resumido no gr\u00e1fico abaixo e na cl\u00e1ssica apresenta\u00e7\u00e3o de Henrick Kniberg<\/em><\/strong><\/a>, serviu como uma inspira\u00e7\u00e3o para v\u00e1rias outras organiza\u00e7\u00f5es que, ao longo dos anos, tentaram adotar a mesma estrutura e terminologia (Squads<\/em>, Tribes<\/em>, Chapters<\/em>, Guilds<\/em>) em seus pr\u00f3prios contextos.<\/p>\n\n\n\n![\"\"](\"https:\/\/www.semeru.com.br\/blog\/wp-content\/uploads\/2024\/09\/spotifymodel.png\")
<\/a><\/figure>\n\n\n\nMesmo hoje, muitas empresas ainda tentam replicar esse modelo. No entanto, h\u00e1 um problema central com isso: o Spotify<\/em> n\u00e3o utiliza o \u2018Modelo Spotify<\/strong>\u2019. E, na verdade, nunca utilizou plenamente. Segundo Jeremiah Lee<\/a><\/em>, um insider da empresa, a estrutura que muitas vezes \u00e9 referida como o Modelo Spotify<\/strong> nunca foi completamente implementada no pr\u00f3prio Spotify<\/em>. Isso significa que o pr\u00f3prio Spotify<\/em> n\u00e3o o adota mais \u2014 e, muito provavelmente, voc\u00ea tamb\u00e9m n\u00e3o deveria seguir esse modelo sem uma reflex\u00e3o mais profunda sobre o que ele realmente significa e seus potenciais problemas.<\/p>\n\n\n\nAntes de mais nada, \u00e9 importante destacar que copiar e colar cegamente a estrutura organizacional de outra empresa em sua pr\u00f3pria opera\u00e7\u00e3o \u00e9 um erro significativo. Muitas empresas veem o Modelo Spotify<\/strong> como uma solu\u00e7\u00e3o pronta, mas cada organiza\u00e7\u00e3o tem suas pr\u00f3prias particularidades. Mais do que isso, o modelo n\u00e3o funcionou no pr\u00f3prio Spotify<\/em> por uma s\u00e9rie de raz\u00f5es bastante espec\u00edficas que merecem aten\u00e7\u00e3o.<\/p>\n\n\n\n\n ![](\"https:\/\/raw.githubusercontent.com\/leandrocgsi\/blog-images\/main\/06-spotify.png\" "\\"Spotify")
\n<\/a>\n\n\n\nO \u2018Modelo Spotify\u2019 que nunca se concretizou\u2026<\/h3>\n\n\n\n
<\/p>\n\n\n\n
O que muitas empresas e profissionais enxergam como o Modelo Spotify<\/strong> era, na verdade, mais uma aspira\u00e7\u00e3o do que uma pr\u00e1tica completamente realizada dentro do Spotify<\/em>. A ideia por tr\u00e1s do modelo era modernizar e otimizar o trabalho em equipe, com base em princ\u00edpios Agile<\/em>, para criar uma cultura de alta performance e flexibilidade organizacional. No entanto, o modelo enfrentou obst\u00e1culos significativos dentro da empresa, que impediram sua ado\u00e7\u00e3o plena e, em \u00faltima an\u00e1lise, sua continuidade. Aqui est\u00e3o os principais fatores, segundo Jeremiah Lee<\/a><\/em>, que contribu\u00edram para isso.<\/p>\n\n\n\n\n- Renomear equipes e departamentos como \u2018squads\u2019 e \u2018tribes\u2019 criou confus\u00e3o e fomentou uma mitologia falha<\/strong><\/li>\n\n\n\n
- A gest\u00e3o matricial foi ineficaz em muitos casos<\/strong><\/li>\n\n\n\n
- Como uma empresa em crescimento acelerado, o Spotify<\/em> descobriu que equipes otimizadas para m\u00e1xima autonomia eram sub\u00f3timas no contexto de crescimento e escalabilidade<\/strong><\/li>\n\n\n\n
- As equipes careciam de uma compreens\u00e3o b\u00e1sica e competente dos princ\u00edpios e pr\u00e1ticas Agile<\/em><\/strong><\/li>\n<\/ul>\n\n\n\n
Agora, vamos explorar cada um desses pontos com mais detalhes.<\/p>\n\n\n\n
Renomea\u00e7\u00e3o de Estruturas<\/h3>\n\n\n\n
<\/p>\n\n\n\n
No cerne do que se chamava de Modelo Spotify<\/strong>, estava o que essencialmente era uma renomea\u00e7\u00e3o de uma estrutura j\u00e1 conhecida como estrutura matricial<\/strong>. Cada \u2018chapter<\/strong>\u2019 era, na realidade, apenas uma \u00e1rea funcional, como Testes, Programa\u00e7\u00e3o ou Design, com seu pr\u00f3prio gerente de pessoas. Um \u2018squad<\/strong>\u2019, por sua vez, nada mais era do que uma equipe multifuncional composta por membros de diferentes chapters<\/em>. Em ess\u00eancia, era simplesmente uma equipe. Se era apenas uma equipe, por que n\u00e3o cham\u00e1-la de equipe? Renomear isso como \u2018squad\u2019 n\u00e3o agregou valor significativo. Cada \u2018tribe<\/strong>\u2019 era, na pr\u00e1tica, simplesmente um antigo departamento rebatizado. Portanto, nada nas estruturas subjacentes realmente mudou. O uso de novos nomes acabou criando confus\u00e3o entre os colaboradores e levou \u00e0 cria\u00e7\u00e3o de uma mitologia em torno da ideia de que algo substancial havia mudado, quando, na verdade, n\u00e3o havia.<\/p>\n\n\n\nEssa confus\u00e3o sobre os nomes mascarava a verdadeira quest\u00e3o de que a estrutura da empresa n\u00e3o estava se tornando mais \u00e1gil ou adaptativa, mas apenas adotando uma nova terminologia. Isso ilustrou que apenas a mudan\u00e7a de palavras ou r\u00f3tulos n\u00e3o transforma necessariamente as din\u00e2micas internas de uma empresa, e muito menos suas pr\u00e1ticas operacionais.<\/p>\n\n\n\n
Gest\u00e3o Matricial<\/h3>\n\n\n\n
Outro grande problema estava na implementa\u00e7\u00e3o da gest\u00e3o matricial<\/strong>. Cada \u2018squad<\/strong>\u2019 (que, como j\u00e1 mencionado, deveria ser chamada apenas de equipe) era liderada por m\u00faltiplos gerentes funcionais, um para cada \u2018chapter<\/strong>\u2019, que, na pr\u00e1tica, eram apenas \u00e1reas funcionais como Testes, Programa\u00e7\u00e3o back-end, mobile, etc. Isso gerava uma sobrecarga de supervis\u00e3o e, consequentemente, de coordena\u00e7\u00e3o, levando a conflitos. Quando surgia um desacordo dentro de uma equipe, por exemplo, sobre a dire\u00e7\u00e3o t\u00e9cnica a seguir, esse problema muitas vezes tinha que ser resolvido entre v\u00e1rios gerentes funcionais, o que adicionava camadas de burocracia e complexidade. Na aus\u00eancia de consenso entre os gerentes, as disputas precisavam ser escaladas para o Diretor da \u2018tribe<\/strong>\u2019 (ou seja, o chefe do departamento), o que criava ainda mais fric\u00e7\u00e3o e inefici\u00eancias no processo de tomada de decis\u00f5es.<\/p>\n\n\n\nAutonomia das Equipes<\/h3>\n\n\n\n
Al\u00e9m disso, as squads<\/em> foram otimizadas para operar com um n\u00edvel m\u00e1ximo de autonomia. Essa abordagem foi, sem d\u00favida, muito vantajosa para o Spotify<\/em> quando ainda era uma start-up em crescimento acelerado, onde a agilidade e a rapidez de adapta\u00e7\u00e3o eram vitais para sobreviver em um mercado competitivo. No entanto, \u00e0 medida que o Spotify<\/em> cresceu e se tornou uma empresa de maior escala, essa autonomia extrema come\u00e7ou a gerar problemas. A falta de consist\u00eancia entre as diferentes equipes dificultou a gest\u00e3o eficaz do r\u00e1pido crescimento da empresa. Com pouca coordena\u00e7\u00e3o central, diferentes equipes acabavam duplicando esfor\u00e7os em tarefas similares ou criando solu\u00e7\u00f5es que levavam \u00e0 complexidade t\u00e9cnica e \u00e0 entropia t\u00e9cnica<\/strong> ao longo do tempo.<\/p>\n\n\n\nPor exemplo, enquanto uma equipe poderia estar desenvolvendo uma solu\u00e7\u00e3o espec\u00edfica para um problema, outra poderia estar resolvendo o mesmo problema de uma maneira completamente diferente. Isso n\u00e3o apenas desperdi\u00e7ava recursos, mas tamb\u00e9m criava desafios na manuten\u00e7\u00e3o de padr\u00f5es de qualidade e na integra\u00e7\u00e3o de sistemas em escala.<\/p>\n\n\n\n
Compet\u00eancia em Agile<\/h3>\n\n\n\n
Por fim, embora a autonomia das equipes fosse um dos principais pilares do modelo, muitas delas n\u00e3o tinham a compet\u00eancia necess\u00e1ria para operar com efic\u00e1cia dentro de um ambiente Agile<\/em>. O Spotify<\/em> ofereceu \u00e0s equipes controle completo sobre seus pr\u00f3prios processos e pr\u00e1ticas, permitindo que cada uma seguisse o caminho que considerasse mais apropriado. No entanto, n\u00e3o havia l\u00edderes t\u00e9cnicos suficientes treinar e para garantir que todas as equipes seguissem os princ\u00edpios fundamentais de Agile<\/strong> corretamente, e muitas equipes simplesmente n\u00e3o tinham o conhecimento ou a experi\u00eancia necess\u00e1rios para implementar esses princ\u00edpios de forma eficaz. Segundo Jeremiah Lee<\/a><\/em>, \u201cN\u00e3o era realmente Agile<\/em>. Era apenas \u2018n\u00e3o-waterfall\u2019\u201d, ou seja, eles n\u00e3o estavam seguindo metodologias \u00e1geis, mas tamb\u00e9m n\u00e3o estavam utilizando um modelo de gest\u00e3o tradicional e estruturado como o Waterfall<\/strong>.<\/p>\n\n\n\n\n ![](\"https:\/\/raw.githubusercontent.com\/leandrocgsi\/blog-images\/main\/05-agile.png\" "\\"Agile")
\n<\/a>\n\n\n\nConclus\u00e3o<\/h3>\n\n\n\n
Embora o Modelo Spotify<\/strong> tenha se tornado um s\u00edmbolo de inova\u00e7\u00e3o e uma tentativa de modernizar as pr\u00e1ticas organizacionais no mundo Agile<\/em>, ele n\u00e3o trouxe os resultados esperados para o pr\u00f3prio Spotify<\/em>. A renomea\u00e7\u00e3o de estruturas tradicionais, como equipes e departamentos, sem mudan\u00e7as substanciais no funcionamento, gerou confus\u00e3o e falhou em promover a transforma\u00e7\u00e3o desejada. A gest\u00e3o matricial e a autonomia extrema das equipes tamb\u00e9m trouxeram desafios significativos, como falta de coordena\u00e7\u00e3o e entropia t\u00e9cnica. Al\u00e9m disso, a aus\u00eancia de compet\u00eancia em pr\u00e1ticas Agile<\/em> impediu que o modelo se consolidasse de maneira eficiente. Esses problemas evidenciam que a simples ado\u00e7\u00e3o de novos r\u00f3tulos e conceitos n\u00e3o \u00e9 suficiente para transformar a realidade de uma organiza\u00e7\u00e3o. Antes de seguir esse caminho, as empresas devem avaliar suas pr\u00f3prias necessidades e contextos, reconhecendo que o que funciona para uma start-up em crescimento pode n\u00e3o ser adequado para uma empresa em processo de escalabilidade.<\/p>\n\n\n\n
<\/a><\/figure>\n\n\n\nMesmo hoje, muitas empresas ainda tentam replicar esse modelo. No entanto, h\u00e1 um problema central com isso: o Spotify<\/em> n\u00e3o utiliza o \u2018Modelo Spotify<\/strong>\u2019. E, na verdade, nunca utilizou plenamente. Segundo Jeremiah Lee<\/a><\/em>, um insider da empresa, a estrutura que muitas vezes \u00e9 referida como o Modelo Spotify<\/strong> nunca foi completamente implementada no pr\u00f3prio Spotify<\/em>. Isso significa que o pr\u00f3prio Spotify<\/em> n\u00e3o o adota mais \u2014 e, muito provavelmente, voc\u00ea tamb\u00e9m n\u00e3o deveria seguir esse modelo sem uma reflex\u00e3o mais profunda sobre o que ele realmente significa e seus potenciais problemas.<\/p>\n\n\n\n Antes de mais nada, \u00e9 importante destacar que copiar e colar cegamente a estrutura organizacional de outra empresa em sua pr\u00f3pria opera\u00e7\u00e3o \u00e9 um erro significativo. Muitas empresas veem o Modelo Spotify<\/strong> como uma solu\u00e7\u00e3o pronta, mas cada organiza\u00e7\u00e3o tem suas pr\u00f3prias particularidades. Mais do que isso, o modelo n\u00e3o funcionou no pr\u00f3prio Spotify<\/em> por uma s\u00e9rie de raz\u00f5es bastante espec\u00edficas que merecem aten\u00e7\u00e3o.<\/p>\n\n\n\n\n <\/p>\n\n\n\n O que muitas empresas e profissionais enxergam como o Modelo Spotify<\/strong> era, na verdade, mais uma aspira\u00e7\u00e3o do que uma pr\u00e1tica completamente realizada dentro do Spotify<\/em>. A ideia por tr\u00e1s do modelo era modernizar e otimizar o trabalho em equipe, com base em princ\u00edpios Agile<\/em>, para criar uma cultura de alta performance e flexibilidade organizacional. No entanto, o modelo enfrentou obst\u00e1culos significativos dentro da empresa, que impediram sua ado\u00e7\u00e3o plena e, em \u00faltima an\u00e1lise, sua continuidade. Aqui est\u00e3o os principais fatores, segundo Jeremiah Lee<\/a><\/em>, que contribu\u00edram para isso.<\/p>\n\n\n\n Agora, vamos explorar cada um desses pontos com mais detalhes.<\/p>\n\n\n\n <\/p>\n\n\n\n No cerne do que se chamava de Modelo Spotify<\/strong>, estava o que essencialmente era uma renomea\u00e7\u00e3o de uma estrutura j\u00e1 conhecida como estrutura matricial<\/strong>. Cada \u2018chapter<\/strong>\u2019 era, na realidade, apenas uma \u00e1rea funcional, como Testes, Programa\u00e7\u00e3o ou Design, com seu pr\u00f3prio gerente de pessoas. Um \u2018squad<\/strong>\u2019, por sua vez, nada mais era do que uma equipe multifuncional composta por membros de diferentes chapters<\/em>. Em ess\u00eancia, era simplesmente uma equipe. Se era apenas uma equipe, por que n\u00e3o cham\u00e1-la de equipe? Renomear isso como \u2018squad\u2019 n\u00e3o agregou valor significativo. Cada \u2018tribe<\/strong>\u2019 era, na pr\u00e1tica, simplesmente um antigo departamento rebatizado. Portanto, nada nas estruturas subjacentes realmente mudou. O uso de novos nomes acabou criando confus\u00e3o entre os colaboradores e levou \u00e0 cria\u00e7\u00e3o de uma mitologia em torno da ideia de que algo substancial havia mudado, quando, na verdade, n\u00e3o havia.<\/p>\n\n\n\n Essa confus\u00e3o sobre os nomes mascarava a verdadeira quest\u00e3o de que a estrutura da empresa n\u00e3o estava se tornando mais \u00e1gil ou adaptativa, mas apenas adotando uma nova terminologia. Isso ilustrou que apenas a mudan\u00e7a de palavras ou r\u00f3tulos n\u00e3o transforma necessariamente as din\u00e2micas internas de uma empresa, e muito menos suas pr\u00e1ticas operacionais.<\/p>\n\n\n\n Outro grande problema estava na implementa\u00e7\u00e3o da gest\u00e3o matricial<\/strong>. Cada \u2018squad<\/strong>\u2019 (que, como j\u00e1 mencionado, deveria ser chamada apenas de equipe) era liderada por m\u00faltiplos gerentes funcionais, um para cada \u2018chapter<\/strong>\u2019, que, na pr\u00e1tica, eram apenas \u00e1reas funcionais como Testes, Programa\u00e7\u00e3o back-end, mobile, etc. Isso gerava uma sobrecarga de supervis\u00e3o e, consequentemente, de coordena\u00e7\u00e3o, levando a conflitos. Quando surgia um desacordo dentro de uma equipe, por exemplo, sobre a dire\u00e7\u00e3o t\u00e9cnica a seguir, esse problema muitas vezes tinha que ser resolvido entre v\u00e1rios gerentes funcionais, o que adicionava camadas de burocracia e complexidade. Na aus\u00eancia de consenso entre os gerentes, as disputas precisavam ser escaladas para o Diretor da \u2018tribe<\/strong>\u2019 (ou seja, o chefe do departamento), o que criava ainda mais fric\u00e7\u00e3o e inefici\u00eancias no processo de tomada de decis\u00f5es.<\/p>\n\n\n\n Al\u00e9m disso, as squads<\/em> foram otimizadas para operar com um n\u00edvel m\u00e1ximo de autonomia. Essa abordagem foi, sem d\u00favida, muito vantajosa para o Spotify<\/em> quando ainda era uma start-up em crescimento acelerado, onde a agilidade e a rapidez de adapta\u00e7\u00e3o eram vitais para sobreviver em um mercado competitivo. No entanto, \u00e0 medida que o Spotify<\/em> cresceu e se tornou uma empresa de maior escala, essa autonomia extrema come\u00e7ou a gerar problemas. A falta de consist\u00eancia entre as diferentes equipes dificultou a gest\u00e3o eficaz do r\u00e1pido crescimento da empresa. Com pouca coordena\u00e7\u00e3o central, diferentes equipes acabavam duplicando esfor\u00e7os em tarefas similares ou criando solu\u00e7\u00f5es que levavam \u00e0 complexidade t\u00e9cnica e \u00e0 entropia t\u00e9cnica<\/strong> ao longo do tempo.<\/p>\n\n\n\n Por exemplo, enquanto uma equipe poderia estar desenvolvendo uma solu\u00e7\u00e3o espec\u00edfica para um problema, outra poderia estar resolvendo o mesmo problema de uma maneira completamente diferente. Isso n\u00e3o apenas desperdi\u00e7ava recursos, mas tamb\u00e9m criava desafios na manuten\u00e7\u00e3o de padr\u00f5es de qualidade e na integra\u00e7\u00e3o de sistemas em escala.<\/p>\n\n\n\n Por fim, embora a autonomia das equipes fosse um dos principais pilares do modelo, muitas delas n\u00e3o tinham a compet\u00eancia necess\u00e1ria para operar com efic\u00e1cia dentro de um ambiente Agile<\/em>. O Spotify<\/em> ofereceu \u00e0s equipes controle completo sobre seus pr\u00f3prios processos e pr\u00e1ticas, permitindo que cada uma seguisse o caminho que considerasse mais apropriado. No entanto, n\u00e3o havia l\u00edderes t\u00e9cnicos suficientes treinar e para garantir que todas as equipes seguissem os princ\u00edpios fundamentais de Agile<\/strong> corretamente, e muitas equipes simplesmente n\u00e3o tinham o conhecimento ou a experi\u00eancia necess\u00e1rios para implementar esses princ\u00edpios de forma eficaz. Segundo Jeremiah Lee<\/a><\/em>, \u201cN\u00e3o era realmente Agile<\/em>. Era apenas \u2018n\u00e3o-waterfall\u2019\u201d, ou seja, eles n\u00e3o estavam seguindo metodologias \u00e1geis, mas tamb\u00e9m n\u00e3o estavam utilizando um modelo de gest\u00e3o tradicional e estruturado como o Waterfall<\/strong>.<\/p>\n\n\n\n\n Embora o Modelo Spotify<\/strong> tenha se tornado um s\u00edmbolo de inova\u00e7\u00e3o e uma tentativa de modernizar as pr\u00e1ticas organizacionais no mundo Agile<\/em>, ele n\u00e3o trouxe os resultados esperados para o pr\u00f3prio Spotify<\/em>. A renomea\u00e7\u00e3o de estruturas tradicionais, como equipes e departamentos, sem mudan\u00e7as substanciais no funcionamento, gerou confus\u00e3o e falhou em promover a transforma\u00e7\u00e3o desejada. A gest\u00e3o matricial e a autonomia extrema das equipes tamb\u00e9m trouxeram desafios significativos, como falta de coordena\u00e7\u00e3o e entropia t\u00e9cnica. Al\u00e9m disso, a aus\u00eancia de compet\u00eancia em pr\u00e1ticas Agile<\/em> impediu que o modelo se consolidasse de maneira eficiente. Esses problemas evidenciam que a simples ado\u00e7\u00e3o de novos r\u00f3tulos e conceitos n\u00e3o \u00e9 suficiente para transformar a realidade de uma organiza\u00e7\u00e3o. Antes de seguir esse caminho, as empresas devem avaliar suas pr\u00f3prias necessidades e contextos, reconhecendo que o que funciona para uma start-up em crescimento pode n\u00e3o ser adequado para uma empresa em processo de escalabilidade.<\/p>\n\n\n\n\n<\/a>\n\n\n\nO \u2018Modelo Spotify\u2019 que nunca se concretizou\u2026<\/h3>\n\n\n\n
\n
Renomea\u00e7\u00e3o de Estruturas<\/h3>\n\n\n\n
Gest\u00e3o Matricial<\/h3>\n\n\n\n
Autonomia das Equipes<\/h3>\n\n\n\n
Compet\u00eancia em Agile<\/h3>\n\n\n\n
\n<\/a>\n\n\n\nConclus\u00e3o<\/h3>\n\n\n\n