Sistema de Duplo Reporte

Sistema de Duplo Reporte

Quando a empresa está crescendo estruturalmente e sente a necessidade de começa a separar as equipes por unidades de negócio ou objetivos, passa por algumas dificuldades sobre o entendimento do modelo ideal de separação dessas equipes, afinal, temos pouca clareza sobre a melhor forma de balancear liberdade para se atingir os objetivos e garantia de que os padrões da empresa sejam seguidos.

Em busca de compartilhar uma possível solução, Henrik Kniberg e Anders Ivarsson lançaram em 2012 o documento Scaling Agile @ Spotify, no qual é relatado o modelo de gestão do Spotify, baseado em Squads, Tribos e Capítulos, Scaling Agile @ Spotify. Esse modelo que ficou super famoso, tem muita conexão com o assunto que quero tratar aqui, o sistema de duplo reporte.

A separação da equipe em squads se faz necessária quando a empresa percebe que existe mais de um produto ou feature, no qual, o cumprimento dos seus objetivos individuais impactam diretamente o resultado geral e crescimento da empresa. Por isso, na tentativa de dar liberdade para que cada equipe trabalhe focada no atingimento de um objetivo específico, nasce a necessidade da divisão de recursos entre esses objetivos. Com isso, nascem as squads, cada uma focada em um objetivo.


É importante entender que os objetivos aqui são resultados que esperamos alcançar para que a empresa siga crescendo como esperado. Um bom exemplo aqui poderia ser aumentar em X% a taxa de ativação dos usuários, o que resultaria em um possível aumento de receita para a empresa, mesmo mantendo o número de aquisições. O mais importante é entender que uma squad deve receber um resultado a ser atingido e não tarefas a serem executadas.


Depois da definição dos objetivos e separação das squads, é necessário identificar as skills necessárias para cada uma delas. Em geral, teremos um PM, desenvolvedores back-end e front-end e um Product Designer. Entretanto, vai depender muito do objetivo a ser alcançado, já que no caso de uma das squads precisar de uma estratégia de Go-To-Market, ela necessitará de uma pessoa de marketing na equipe, também.

Skills definidas e equipes prontas, vamos começar a trabalhar, com cada equipe focada no seu objetivo e com liberdade para testar formas de atingir aquele resultado esperado. Para esse momento, há quem prefira o modelo de sprint, há quem prefira a avaliação trimestral das ORKs e há quem prefira o modelo shape-up, de qualquer forma, o importante é seguir algum processo que passe pelas etapas de construção do plano de ação(discovery), execução, análise dos resultados e sistematização do que funcionou ou análise do motivo de não funcionar.

Pronto, agora que temos nossas equipes rodando com objetivos claros, está tudo lindo. Basta sentarmos e esperarmos os resultados chegarem, certo? ERRADO!

Quando damos uma liberdade integral para cada equipe buscar seus objetivos, corremos um grande risco de faltar integração entre elas. Afinal, em tecnologia, quem garante que todos na empresa utilizarão a mesma linguagem de programação? Quem garante que serão seguidos os mesmos padrões de API e nomeação de variável?. E no marketing, quem garante que todos irão querer utilizar o mesmo disparador de emails? Será que seria interessante cada squad ter seu disparador ou sairia mais barato o compartilhamento dessa ferramenta?

É para garantir essa padronização e definir uma identidade das áreas que existe o sistema de duplo reporte, bastante parecido com o sistema de Chapters do Shopify.

No modelo de duplo reporte, as squads têm um objetivo a ser alcançado, nesse caso, portanto, a liderança da squad precisa cuidar para que o objetivo seja alcançado. No entanto, é necessário que alguém cuide da identidade da empresa e dos padrões de cada área da empresa e esse alguém são os Chapters, podendo ter uma liderança ou não.

Nesse modelo, as áreas se reunem com uma determinada frequência, sugiro que seja semanalmente, para discutir as melhores práticas da área, os padrões que serão seguidos e principais dificuldades que estão sendo encontradas, garantindo uma integração entre todas as squads.


Chamamos de área da empresa as pessoas separadas por skill, por exemplo, as pessoas de marketing formam a área de marketing, as pessoas de tecnologia formam a área de tecnologia e assim sucessivamente. No caso de tecnologia, ainda podemos separar em back-end e front-end se for mais harmonioso para a empresa.


Podemos concluir, portanto, que a separação da equipe por squads, cada uma focada em um resultado específico da empresa, tende a melhorar os resultados gerais da organização, já que cada squad terá maior liberdade para buscar seu objetivo. No entanto, corre-se o risco de cada uma criar sua própria identidade e padrões e, consequentemente, acabar com a identidade e os padrões da empresa. É para garantir que esse efeito colateral não aconteça que o sistema de duplo reporte foi criado e utilizado pela Nasa, para colocar um homem na Lua.

Frederico Silva

Tech Manager | Developer | Entrepreneur

1 a

O modelo é ótimo, porém é exatamente nesta etapa que 90% falha: "O mais importante é entender que uma squad deve receber um resultado a ser atingido e não tarefas a serem executadas."

Gabriel Francisco dos Santos

Inteligência Artificial - ChatGPT - Chatbot - Javascript

1 a

Boa Netinho! Parabens pelo artigo, mandou muito. Acho importante citar também o artigo Failed Squad Goals do spotify, que fala bastante sobre essa departamentalização matricial.

Ana Clara Zuchi

Hubspot | Operations | Automations | Notion

1 a

Excelente artigo, Antônio! Clareou bastante minhas percepções sobre o assunto.

Hiram Damin

Coordenador de Customer Success | 3x Top100 CS Estrategista Mundial - Success Coaching (USA) | Escritor best seller Amazon | Palestrante | Liderança | Mentoria | Jurado Top 25 Success Coaching (EUA)

1 a

Boa Antônio! Atingimos tantas pessoas com nossa experiência que nem sabemos o quanto, continue nessa jornada!

Entre para ver ou adicionar um comentário

Outras pessoas também visualizaram

Conferir tópicos