Spotify: dos princípios às práticas
Compilado de tópicos extraídos da palestra do Marcin Floryan — Diretor de Engenharia da Spotify — de 2018.
Published in
7 min readJun 26, 2020
A intenção do texto é mostrar que não existe “um modelo Spotify” e nem independente da própria cultura Spotify.
É comum vermos as empresas copiarem o que acreditam ser o “modelo Spotify” sem entender o contexto e nem a cultura da empresa.
E, curiosamente, o que algumas dessas empresas chamam de “modelo Spotify” muitas vezes significa apenas os nomes “squads”, “tribe” e “chapter” e uma tentativa de times multidisciplinares.
Algumas empresas talvez imaginem que seja pop para contratar pessoas e outras talvez acreditem que só de chamar algum time de “squad” a mágica acontece e tudo se torna ágil.
Várias empresas não tentam entender seus próprios desafios e necessidades. Não se questionam. Não experimentam. Não adaptam. Não evoluem.
Espero que os trechos abaixo possam dar uma ideia do que foi falado nesse vídeo do Marcin Floryan de 2018.
Lembrete: apesar de em alguns momentos eu escrever no presente sobre as práticas comentadas no vídeo, lembre-se que isso é referente à época do vídeo (2018).
Vídeo
Sobre “Modelo Spotify”
- 2m10 a 2m48: fala sobre o paper do Spotify de 2012: “Spotify Model”. Ele comenta que mesmo na época isso não descrevia muito bem/não era inteiramente verdade e certamente já era diferente em 2018 (época do vídeo).
- 3m18s (nomes: tribos, capítulos) — a única razão para terem esses nomes (tribes, chapters, etc) era por ninguém na indústria usar esses nomes. Ele comenta que se você usa eles, é por não ter entendido a proposta. Eles queriam apenas se diferenciar com os nomes.
Princípios e práticas que permitem a evolução do modelo
- Valores: colaborativo, apaixonado, inovador, sincero, divertido.
- Princípios: transparência, colaboração, loops de feedback, autonomia alinhada, segurança psicológica.
Exemplos com o princípio de transparência:
O que fazem na organização deve estar disponíveis para todos da organização:
- balanço patrimonial;
- resultados financeiros;
- chamadas com investidores disponíveis para todos da empresa;
- todo documento que qualquer diretor escreve pode ser lido por qualquer engenheiro.
Processo que ele usava para criar e encorajar transparência:
- escrever um checkin (o que fez; o que irá fazer) e compartilhar com liderados e líderes por email toda segunda-feira de manhã.
Exemplos com o princípio de colaboração
- Tribe Standup (teve outros nomes ao longo do tempo): representantes de cada squad. Isso permite: Foco, Comprometimento, Pertencimento e Aprendizado.
- Uma tribo tinha por volta de 50 pessoas.
- Big Room Planning: a cada trimestre todos os squads apresentam suas ideias, líderes apresentam prioridades, juntos concordam com o trabalho — time decidia junto o que fazer — e criam OKRs.
- Ele comenta que os OKRs deles não são bem como o que documentos da Intel ou Google falam. Tem apenas o mesmo nome. Eles têm Objectives e Key Results mas não usam outros aspectos. Comentam sobre tentativas e erros com isso lá pelo minuto 16 do vídeo.
- Ele comenta sobre falhas que tiveram com Key Results não entregues; dependências; etc.
- Deu exemplo de que não eram bom em Capacity planning (“didn’t have a very clear view of every single team’s capacity” — feriados, hackdays, etc).
Exemplos com o princípio de feedback loop
- Taps with squads: os leads se encontram com todos os squads, geralmente 1–2 vezes por trimestes. Quatro tópicos: impacto, entregas, saúde (técnica e da equipe) e ajuda que o time precisa dos líderes. Eles são checkpoints um pouco mais estruturados entre a equipe de liderança e os squads (19m). Não é a única maneira de interagirem.
- Almoço com os líderes: oportunidade informal de conversar. Inscrição fácil. Aproximar conexão. Eles criaram um formulário onde as pessoas poderiam se inscrever e informar se era urgente, se gostariam de conversar sozinha ou não se importavam em ser em grupo.
- Pararam de fazer isso pois não precisam mais. As pessoas agora compartilham o que precisam diretamente.
Exemplos com o princípio de autonomia
- Trechos: Equipes autônomas (squads) têm muita autonomia. Eles realmente escolhem suas próprias práticas. Eles escolhem qual ferramenta usar para ter seu board (quadro). Eles escolhem o design do quadro. Eles escolhem o processo […] mas acontece que, naturalmente, a autonomia por si só não é muito boa, porque você acaba com 50 equipes, cada uma fazendo suas próprias coisas em sua própria direção. é caos. […] É super importante adicionar alinhamento a essa autonomia.
- Todos times têm a liberdade de escolher “o quê” e “como”, mas precisam entender o “porquê” e esse “porquê” deve ser compartilhado por toda a empresa.
- Uma das práticas que ajudam eles a definir o “porquê” é estabelecer expectativas evidentes:
- As pessoas precisam de expectativas. E definir limites claros permite autonomia. Não o contrário.
- “Não é suficiente deixar a pessoa ir e dizer ‘crie essa experiência de pesquisa incrível ou crie este melhor sistema de playlist se você não entender para quem esse sistema é construído’”.
- A prática de alinhar expectativas permite as pessoas tomar responsabilidade pois agora entendem que elas possuem algo pra serem responsáveis.
- Torne explícito.
- Autonomia vem com responsabilidade.
- Citação compartilhada por ele: “autonomia não é um benefício, é uma expectativa de responsabilidade”. Quado se dá autonomia às pessoas, esperam que elas assumam a responsabilidade.
Estrutura que usam para pensar em princípios
- Decidiram expressar os princípios como aspirações.
- Em vez de dizer “há algum princípio de transparência. Nós aspiramos trabalhar com alguma coisa relacionada a transparência”.
- Discussão entre todas pessoas da tribo.
- Aspirações votadas colaborativamente e que terão validade por 1 ano.
- Uma das aspirações se destacou: criar um ambiente de segurança psicológica.
Outras práticas
Feedback Jar
Mistakes Column
- uma coluna no board com os menores erros que as pessoas lembram que aconteceu e eles falam sobre isso toda sexta-feira, e limpam a coluna
- não é pra comemoração, mas pra uma lembrança e como uma prática para as pessoas expressarem e conversarem sobre seus erros
Effectiveness Review
- Inspirado na Sociocracia 3.0 (Você desejar saber mais sobre Sociocracia e Sociocracia 3.0? Entre em contato comigo)
Workshop “what’s not to like about this code” por volta de 37m40s
- Eles tinham uma aspiração 1 ano antes da data do vídeo dos engenheiros poderem participar de outros times pra compartilhar conhecimento, aumentar senso de pertencimento, ser inspirado, se desenvolver.
- Tiveram um OKR explícito pra isso e nada aconteceu. Em 2018, sem nenhum OKR as pessoas começaram a pedir pra fazer isso.
- Ele comenta que algumas práticas demoram um bom tempo até ganhar espaço e se estabelecer.
Alergia a “melhores práticas”:
Inspirações para osprincípios que ele apresentou (veja aqui mais livros que podem te ajudar)
