Ep. 06 - Squads e Agilidade Organizacional

Que problemas a agilidade organizacional resolve? Nesse talk que eu fiz, a ideia foi muito mostrar histórias que eu tinha vivido no passado. Como qualquer outra pessoa que começou com ágil, em 2004, bem no início, a agilidade era muito focada em entrega, nível time mesmo, como é que a gente consegue entregar as coisas de uma forma mais simples, mais rápida, validar as coisas antes. Mas à medida que fui passando por outras empresas, comecei a ver como se fosse um antipadrão: o ágil fica só na tecnologia. Mas quando eu começava a olhar para um fluxo de valor, eu falava, a gente está fazendo uma grande otimização local aqui. Eu estava fazendo alguma coisa errada.

Não estava legal. E principalmente quando comecei a aprofundar mais na parte do Lean, eu falei: tem alguma coisa errada aí. Eu não sabia o que exatamente. Depois de um tempo, comecei a ver a gente falar de agilidade em outras esferas, olhando esse fluxo como um todo. Se quiser dar uma definição para agilidade organizacional, tem várias espalhadas pela internet, mas no geral, como se fosse uma capacidade da organização de se renovar, se adaptar, mudar rapidamente, ter sucesso, nesse ambiente que a gente vive, todo mutável.

Certo, turbulento. Não é uma capacidade focada só na tecnologia, mas pensando no fluxo de valor e no cliente no final, isso atinge várias áreas da empresa como um todo. Não dá para focar só em tecnologia.

O Humberto já passou por Yahoo, Spotify, agora Magalu. Dentro dessa trajetória, em que momento você começou a observar não só o seu movimento, mas o movimento de mercado, perseguindo essa agilidade organizacional e não só uma agilidade de time, de tecnologia? Foi antes de ir para a Suécia, no Spotify? Ou no tempo de Yahoo já tinha essa pegada? Tiveram algumas fases.

O Yahoo eu fiquei lá de 2010 até 2012, mais ou menos. Lá não se falava, pelo menos eu não tinha sido exposto, nada de agilidade organizacional. Eu lembro que a gente estava muito na onda de conseguir fazer o produto correto. Foi lá que a gente começou a estudar sobre Lean Startup, e o método Kanban a gente tinha trazido bem antes, em 2009.

Mas nessa época do Yahoo, nada disso. Eu fiquei tão apaixonado por essa coisa do Lean Startup que tive um insight: estou entregando várias coisas erradas, na verdade. Como eu poderia estar lidando com isso antes? Eu acabei indo para uma startup: dois americanos vieram para o Brasil e criaram uma startup de e-commerce focada em mães, e uma outra focada em flash sales, vendas rápidas com tempo limitado. Foi nessa startup que eu tive dois estalos, na verdade.

Que eu vivenciei aquela coisa de ter que contratar um time do zero. Quando cheguei, eram três devs e um designer. A gente teve que fazer o time crescer, foi indo para 25, 30 pessoas. Ali comecei a me inspirar, foi bem na época em que o Spotify tinha lançado o paper em 2012, aquele famoso Scaling Agile at Spotify. Eu fui uma das pessoas que ficaram muito inspiradas com aquilo, não no sentido de copiar, mas de falar, estou com um problema parecido aqui. Esse momento da escala foi muito interessante, comecei a separar os times em fluxo de valor.

Mas ali, para mim, foi um momento de perceber o seguinte: a startup estava crescendo rápido; a empresa devia ter 50 pessoas, e daqui a pouco tinham 200. E eu fui ver e falei, eu criei uma ilha de agilidade, fantástica, com liderança servidora, pessoas felizes. Aquele time da startup foi um time de alta performance, o melhor que eu já trabalhei na vida; nenhum outro do Spotify ou de outro lugar conseguiu bater. A gente fez um negócio muito especial, pessoas que, não sei explicar, foi um momento no universo que conectou. Mas o ponto negativo foi que isso rolava dentro do produto e tecnologia.

Quando eu olhei para o lado e comecei a ver a empresa, comecei a não reconhecer aquela empresa. Quando começava a conversar com o pessoal do financeiro, do RH, do marketing, eu falava, essa empresa está completamente diferente do que a gente fez aqui, com relação à cultura, valores, princípios. Ali, para mim, foi o primeiro momento que bateu: eu tinha que estar pensando na agilidade como um todo, tinha que estar alinhando esses times desde o início. E acho que eu cheguei já tarde, depois de quase dois anos, porque, numa startup, você gasta muita energia, faz de tudo um pouco.

Eu não tinha essa de, eu sou um Scrum Master, eu sou um Agile Coach. Você faz de tudo um pouco e está fazendo o produto acontecer. Na hora que você olha para o lado, a empresa está crescendo rápido. Foi naquele momento que eu falei, tinha que estar pensando na agilidade como um todo. Mas acho que eu nem tinha essa noção desse nome, agilidade organizacional. Eu fiquei lá até 2014, quando fui para a Suécia, e me deparei com o Spotify, mas aí já é um outro contexto, que já nasceu digital com aquela cultura das pessoas suecas, muito colaborativas, trabalham muito em time, muito inovadoras.

E lá, realmente, eu via a agilidade rolar até no RH, com o pessoal do marketing, de uma forma natural, não necessariamente falando agilidade, mas exposta nos princípios, nos valores, na maneira de pensar, errar rápido, aprender. Ali comecei a ver o mercado falar de agilidade organizacional, então diria que foi de 2014 para frente.

O movimento do método Kanban, o Carl Scotland, um dos precursores da época, trabalhava no Yahoo, tinha o Errol Sanders também. Quando eu entrei no Yahoo em 2010, já vim com toda aquela bagagem do método Kanban por causa do Alisson, que eu já vinha estudando. Quando cheguei lá, achei um grupo pelo e-mail interno da empresa de pessoas entusiastas do Kanban, e depois batizamos o nome do grupo de Kanbanners. Eu praticava Kanban em 2010. A gente fazia meetups, fazia open space, tinha muita gente boa.

Devido a vários momentos da empresa, as pessoas foram saindo. É um movimento bem de vanguarda, o Kanban é de 2007, a gente está falando de 2010, um grupo organicamente surgindo dentro da empresa. O Yahoo tinha um capital intelectual gigante que foi se espalhando. Aí, para fechar os aprendizados: tem um aprendizado de que no Spotify essa agilidade organizacional já começa a ficar mais explícita, mais clara.

Assim como o sucesso do Spotify também é explícito e claro, pelo menos para quem usa. A gente sabe que nas empresas, você vai nas empresas, a gente já é ágil, já está trabalhando com ágil, mas o fluxo de valor ainda não é ágil, está só focado no time de desenvolvimento. Como é que é nas empresas que vocês passaram, como é que as empresas estão vendo agilidade organizacional na prática, no dia a dia? A gente na K21 tem a vantagem de passar por vários cenários.

E o que eu vejo é que tem uma galera muito afogada para conseguir tirar a cabeça e enxergar o rio, tirando proveito de uma analogia que a gente usa muito na K21, a imagem do rio. Se você estiver mergulhado no rio, não vai conseguir enxergar a extensão dele. Se a gente está falando de uma startup, você consegue ver o rio porque ele é mais enxuto, mais curtinho, as coisas fluem mais rápido. Agora, se você está falando de uma empresa gigante, pensa em qualquer banco nacional hoje, o rio é muito extenso.

O rio é muito largo, muito grande, quase um rio Amazonas, e você não vai conseguir enxergar estando mergulhado nele. Você vai ter que se afastar o suficiente para enxergar. O que eu vejo no dia a dia é que as pessoas acabam tendo só a visão local. E o mais engraçado é que, mesmo falando com a gerência desse time, com a média gestão, com a gerência sênior, a visão ainda é local, porque o rio é muito extenso, e a conexão entre as partes não fica clara. A gente tem partes sendo otimizadas, mas sem olhar para as conexões entre elas.

Tem uma frase do Ackoff muito boa: em sistemas complexos, a soma das partes não vai ser igual ao produto; o produto está muito mais relacionado com a interação entre as partes, e não só com a soma de cada uma delas. O que eu vejo hoje na realidade é a galera afogada, olhando só para o contexto local, sem conseguir olhar ponta a ponta.

Isso me lembra o seguinte: você, como cliente, se você clicou o play no Netflix, você quer ver o filme. Você não quer saber quantas áreas tem, se o time usa squad, se tem tribo. Você sentou no sofá, deu o play, quer ver o filme. A gente tem que ter muito esse pensamento de quem é o seu cliente e o que ele quer. A Luiza Helena, que foi CEO do Magalu, tem uma frase emblemática: todo mundo que trabalha aqui é vendedor. Em última instância, o que ela está falando é o quê?

Se você está ali é porque tem um propósito de estar ali, você está vendendo alguma coisa para atingir um cliente no fim das contas. Mesmo que você esteja numa área de apoio, no RH, no financeiro, marketing ou tecnologia, você tem que pensar: estou possibilitando que a venda aconteça? E o cliente não quer saber quantas áreas tem, ele quer um produto bom, no preço legal, com frete grátis, entregando no mesmo dia, se possível. Esses são os problemas que a gente tem que estar resolvendo no dia a dia, e isso conecta muito bem com a agilidade organizacional.

Se você não tiver essa agilidade, não vai conseguir fazer essa química rolar. Esse foco no cliente pregado pela liderança é suficiente para fazer as partes se conectarem, interagirem até chegar nesse fim maior, ou a gente ainda tem que penar bastante para fazer essa conexão funcionar bem? É preciso, sim, ter a parte dos líderes explicitando isso, que é a questão do foco no cliente. Tem a questão disso ser um valor da empresa, que entra até em avaliação comportamental das pessoas.

Mas entra também em outras partes. Quando eu cheguei em 2017, a forma que o Magalu fazia o desdobramento das estratégias era muito projetizada ainda, eram projetos acontecendo, e tinha aquela coisa de entregar até tal data, com bônus atrelado. Você entregou na data, recebe um bônus; entregou depois, não recebe. Uma das primeiras coisas que fui ajudando a mudar foi: ao invés de ter projetos, a gente ter indicadores, muito parecido com OKRs.

Qual é o nosso número de usuários mensais ativos, qual é o nosso contact rate, o pessoal compra alguma coisa e tem que ficar ligando para cá, ou a venda já é boa de primeira? Qual é o nosso NPS? Essas são métricas legais de ter, e com base nisso a gente cria hipóteses, que seriam, no caso, os projetos, uma hipótese que você está testando para tentar mexer no indicador. Ter esses indicadores voltados para o cliente faz com que a empresa comece a pensar como um todo.

Porque, mais uma vez, você tenta gerenciar o sistema e não as pessoas. E, como consequência, você vê o comportamento das pessoas pensando cada vez mais no cliente. Tem um livro muito bom, Empresa Conectada, do Dave Gray, que fala exatamente isso: ao longo dos anos, as empresas foram sendo tratadas como máquinas, em que as engrenagens internas, cada uma faz sua parte. Só que no mundo de hoje, onde o ambiente muda muito rapidamente, e é um pouco do que já se falou aqui sobre sistemas complexos, o que vale é a interação entre as partes. Se você não tratar a sua empresa como um organismo vivo, que aprende, que se adapta, que muda, você está fadado ao fracasso.

Se tratar a sua empresa de uma maneira rígida, uma máquina engessada que só faz aquilo, você está ferrado. Isso vai muito de encontro com o que a gente já discutiu no episódio sobre o castelo de mentiras, gestão de portfólio versus gestão de projetos: gestão por projetos não tem visão mais interna do que fazer gestão por indicadores do projeto, porque o seu cliente, no final, não está olhando para o projeto.

Ele está olhando para o que vai consumir no fim da cadeia. E métricas mudam comportamentos, diga-me como me medes, e te digo como me comportarei. Se você está me medindo por projeto entregue, eu te entrego mais projetos, está entregando valor? Não sei, não me importo, mas estou entregando projetos. Agora, se você está me medindo pela quantidade de reclamações que o cliente está fazendo, eu vou tentar reduzir isso.

A gente falou um pouco também sobre Spotify, legal ter você aqui, porque você vivenciou na pele como a coisa funciona. Vamos falar a realidade: isso aqui virou um boom no Brasil, esse negócio de squad, squadificação, virou um negócio absurdo. Na sua opinião, o que é a squadificação que tomou conta das empresas brasileiras?

A squadificação do mal. É interessante voltar um pouco atrás, de onde surgiu essa palavra, surgiu no Spotify mesmo. Foi em 2011, mais ou menos, quando meu amigo Joaquim Sunder entrou como agile coach lá, se eu não me engano, foi o segundo agile coach. Ele pegou bem aquela parte da escala. Eu cheguei depois, em 2014, mas por volta de 2011, 2012, o Spotify estava crescendo muito. O que aconteceu? Antes era fácil das pessoas saberem o nome umas das outras, o que cada um estava fazendo. Daqui a pouco foi ficando um monte de time, time, time. Quando alguém te perguntava, você faz parte de qual time?

Você não tinha uma resposta, porque fazia parte de vários times. Ficava uma confusão. Esses nomes, o pessoal se juntou numa sala e começou a fazer uma taxonomia, dar nome às coisas. E falaram, o time de entrega, que é o Product Development Team, ou até um Scrum Team. Eles pararam de usar esse nome Scrum, que foi muito utilizado lá no início. O próprio Henrik Kniberg fala que o Scrum é como uma bicicleta de rodinhas, que ajuda você a entender várias coisas.

Só que chegou um momento que eles falaram, vamos tirar essa rodinha e criar algumas coisas aqui. Até o nome Scrum Team não estava mais fazendo sentido, por isso também que lá começaram a ter Agile Coaches, que não eram Scrum Masters necessariamente, pensavam em vários métodos para resolver o problema de várias formas. Fazendo esse brainstorm, como é que a gente chama esse time multidisciplinar, relativamente pequeno, que pega um fluxo de valor e entrega o mais ponta a ponta possível? O Joaquim tinha dado a ideia de chamar de crew, como se fosse a tripulação.

Aí a ideia dele foi voto vencido, alguém falou a palavra squad. O pessoal gostou e pegou. Então, vamos chamar isso de squad. E dentro do seu time, você tinha uma competência, outras pessoas de back-end juntas com você formavam um chapter. E tinha outros de front-end, chapter de front-end, e por aí foi indo. Começaram a surgir vários squads com missões específicas para resolver problemas de negócio, e começou a separar também, não é bom ficar tão grande. O Joaquim, na época, estava estudando muito o esquema daquele antropólogo, o Dunbar.

Que fala sobre tribos. O pessoal achou o nome legal, tribo, bacana, vamos botar. Uma coleção de squads juntos, com uma missão, dentro de uma tribo, tenta não passar muito de 120, 150 pessoas. E aí, comunidade de prática, que era o nome de fora, o pessoal botou de guild, uma guilda. Isso virou uma febre no mundo, mas foi sem querer. O Henrik Kniberg entrou um pouco depois, como consultor, com engajamentos de uns quatro meses. E ele gosta muito de fazer visual recording, sketch note.

E o Spotify sempre foi muito aberto, sempre gostou de palestrar em eventos. Acho que juntou essa combinação explosiva de ser uma empresa muito transparente, compartilhar as coisas, com aqueles desenhos legais do Henrik, isso foi meio que explodindo. Mas foi sem querer. É engraçado que lá dentro ninguém fala Spotify Model, isso não existe, ninguém sabe o que é isso. Mas as pessoas de fora têm a necessidade de botar um nome nas coisas. Quando o pessoal fala que está usando o modelo de vocês, que modelo?

Quando a gente vai ver, no fim das contas, é meio que isso, a pessoa tenta enxergar aquilo que foi falado. Agora, o que eu vejo como antipadrão, e isso acontece até dentro do Magalu, é se deixar o pessoal falar que isso aqui é uma squad, sem entender o que é isso. Isso aqui é um time. Chama de outra coisa: é uma célula, pode ser um capítulo, não precisa que tudo seja squad. Esse nome acabou pegando no mercado, hoje um time de desenvolvimento de produtos ficou comum chamar de squad.

É ruim quando você quer que tudo vire squad. A gente ajudou a fazer uma reorg no RH, no marketing, e o pessoal queria muito usar o nome squad, e a gente lutou para que eles não usassem, justamente para não cair nessa armadilha. Palavras têm poder. Hoje eu vejo em muito cliente gente falando squad só para não usar a palavra time, pô, eu tinha um time, agora a gente é ágil, então agora tem um squad.

Somos ágeis, está resolvido, porque agora a gente se chama de squad. Além de squad, tem outra moda que está pegando, falar agora temos um time de produto, não são mais um time de desenvolvimento, somos um time de produto. Time de produto, squad, ou a gente poderia chamar isso de time de alta performance? Se eu tenho um time de produto, eu tenho um time de alta performance?

Tudo é time, no seguinte sentido: eu tenho um time que faz entregas, que está entregando valor. Eu tenho um time de pessoas que têm a mesma competência que eu. Esses times de produto eu enxergo muito como sendo um chapter, um capítulo, pessoas com a mesma competência, melhorando essa competência, mas não necessariamente um squad, porque para mim a essência do squad é ele ser multidisciplinar e atuar nesse fluxo de valor o mais ponta a ponta possível. Se você tiver se juntando com outras pessoas de produto, vocês podem até ser um time, mas não multidisciplinar o suficiente para entregar valor de ponta a ponta.

Mas tem a galera também que fala time de produto como, a gente está focado em um produto único, somos multifuncionais, e isso é suficiente para se dizer um time de alta performance. Semana passada eu ouvi uma frase muito boa, que encaixa bem em todos esses termos, time de alta performance, squad, chapter, guild: a batina não faz o padre. A gente adaptou um pouco, a capa não faz o super-herói. Tem muito termo sendo utilizado, principalmente o modelo Spotify, achando que o uso do termo já vai resolver.

Uma coisa que acho bacana é a gente conseguir tangibilizar isso, porque é difícil dizer, você é um time de alta performance ou não, você ganhou um certificado? É difícil ter esse momento. Você consegue ter vários indicadores de que está numa jornada em direção a se tornar um time muito funcional, de alta performance. O que eu tenho que fazer, exatamente? A gente criou uma espécie de assessment interno no Magalu. A gente fez benchmark com várias áreas, coisas que eu tinha visto no Spotify, tipo o squad health check, coisas que vi em outros lugares, em livros, e adequando a problemas que a gente via lá no Magalu. A gente começou a tangibilizar isso, porque os próprios times ficavam, eu quero ser esse time de alta performance, o que eu faço?

A gente começou a separar algumas afirmações, 16 afirmações. Se você estiver indo bem na maioria delas, você pode até se considerar um time de alta performance. O que tem nesse assessment? A gente discute coisas muito relacionadas ao cliente, ao negócio, para a pessoa entender como está a satisfação do cliente, se você conhece ele, se tem interações regulares, se ele está satisfeito ou não. Como está o seu ritmo de entrega? Você entrega valor frequentemente ou não? Para mim isso é meio que a raiz do ágil: você pode falar um monte de coisa, mas se ficar só no PowerPoint, não foi.

E a parte do produto: você consegue validar a hipótese com o menor esforço possível, você pensa em MVPs, faz o desenvolvimento de forma iterativa, evolui o produto de forma constante, ou só entregou a primeira versão e nunca mais voltou lá? A parte do alinhamento estratégico, você está contribuindo com a estratégia da empresa, essa é a razão de existir do seu time. Às vezes, rodando esse assessment, a gente pegou um time que não tinha alinhamento com nada. A gente falou, então por que vocês existem?

Só de rodar o assessment, a gente desmantelou o time, não fazia sentido existir. Às vezes são perguntas simples, porque time é uma coisa que gasta muita energia, você tem que pensar três vezes antes de querer montar um time. O time só existe porque tem um objetivo compartilhado que depende de outras pessoas: é uma questão de interdependência, já que você depende de outros skills que não conseguiria ter sozinho, e todo mundo depende daquele mesmo objetivo. Agora, se não tem isso, nem precisa criar time, você pode ter um fluxo de valor ali, cada um tomando um pedaço e fazendo acontecer, às vezes é até mais simples.

Outras características que eu vejo em times de alta performance: toda a parte técnica, como está a arquitetura, que também pode ser um grande impedimento para a agilidade. O próprio Spotify passou por isso, quando cheguei lá, tinham acabado de fazer uma mudança grande, tudo era escrito num grande monolito, e depois ficou difícil de modificar. Hoje em dia fica aquele movimento de pêndulo, o pessoal achou que o monolito era o mal, foi todo mundo para...

Microserviços. Agora o pessoal fala, na verdade, nenhum é bom ou ruim por si só, são padrões, tem que saber quando usar. A gente pega muito também questões do Extreme Programming, se tem um método ágil para você usar em tecnologia, eu diria que é o XP, ele é o principal. A gente pega questões de automação, se você está conseguindo automatizar as coisas, fazer testes. E toda a parte de pessoas: um time de alta performance é aquele em que as pessoas dão e recebem feedback a todo momento, não aquela coisa que depende só do seu superior, ou só do ciclo anual do RH.

A questão da auto-organização, se o time tem isso. A questão da interdisciplinaridade, tem silos de conhecimento, isso a gente pega muito, um pega só esse pedaço, outro só esse outro, e o cara sai de férias e o time para. Como o time faz para poder fazer a coisa rolar a todo momento, navegar por todas as colunas do fluxo de valor e não ficar parado só numa? A questão do engajamento, você está feliz de ir para esse time, se sente motivado? Todos os nossos squads têm uma missão que tenta ser muito inspiradora e focada no negócio, porque qual é a sua razão de acordar de manhã e trabalhar nesse time?

Se for uma missão muito meia boca, você fica naquela de não estar legal. A gente coloca isso muito na mão dos times, nas retrospectivas a cada duas, três semanas, revisem a missão de vocês, porque às vezes ela pode estar muito ampla, com muita coisa dentro, e vocês ficam meio perdidos, ou pode estar muito restrita, e aí fica sem graça. Vamos dar um jeito de ampliar essa missão, deixar ela mais desafiadora. E tem toda a questão do processo em si, como é a sua maneira de trabalhar, você está conseguindo ter um processo otimizado?

Você está pensando em melhoria contínua, todo dia consegue estar um pouquinho melhor do que ontem, a questão do pensamento Kaizen. As políticas explícitas. Lá no Spotify o pessoal falava muito de ser orientado a dados, mas não necessariamente dirigido por dados, porque você tem que usar outros pontos para tomar a sua decisão, inclusive a sua inspiração. E a parte do ritmo sustentável, um sistema sem folga não tem melhoria, você acaba tendo aquele time que dá um tiro de três meses e o time acaba. Como você faz para ter um time que fica um ano, dois, três juntos e continua evoluindo? Essas são algumas características que a gente olha, e com base nisso a gente consegue enxergar padrões na organização, fazer tipo um mapa de calor, nossa organização está falhando muito na questão de dados, ou na parte da arquitetura.

Aí a gente começa a criar ações para remover esses impedimentos e fazer com que a organização continue evoluindo e tendo mais agilidade. Enquanto você ia falando, encaixou muito bem nos quatro domínios da agilidade: você começa em negócios, parte para o técnico, vai para o cultural e depois entra no organizacional de uma forma muito boa. O que eu gostei muito é que você não ficou preso ao método. A gente já falou sobre Lean, Kanban, você trouxe XP, mas o método não é o que vai resolver.

Inclusive a frase que eu ouvi, a capa não faz o super-herói, foi numa semana em que a gente estava falando e praticando XP, que é um negócio tão esquecido. Se você tem um squad, se faz parte de um time que tem como foco um produto digital e não está olhando para nada de XP, talvez você não esteja perseguindo alta performance ainda, talvez falte esse pezinho nas boas práticas técnicas. Ou se você é um time que tem muito skill técnico, mas não está olhando para eficácia, para a orientação que vai seguir quanto ao consumidor, você também não é um bom squad, por mais legal que o seu código seja.

Ou se você é um time de RH muito preocupado com a cultura da organização, mas não está olhando para os seus processos, para o seu fluxo de valor, talvez não esteja sendo um time de RH de sucesso, e por aí vai. É bem isso mesmo, a gente vai nas organizações, vê os caras porem as pessoas junto e falarem, agora temos um squad, um time. Tem uma autora que eu gosto muito, a Christina Wodtke, que fala justamente isso: quando você tem várias pessoas multidisciplinares e coloca todas para trabalhar junto, logo de cara elas não vão ser um time, vão ser um grupo de trabalho.

E para transformar elas em time, ainda mais em time de alta performance, tem que ter todo esse trabalho de ter uma missão, ter estratégia, ter maestria, ter autonomia, ter feedback. Como que a gente escala isso? Como que vocês fizeram para escalar isso no Magalu, uma referência que escalou de uma maneira absurda, tem o Luiz Labs.

É uma luta constante. Eu acho que essa que é a magia da coisa, mas também é o lado difícil, a gente não tem uma receita exata, faça exatamente isso. É você sentar, ouvir os problemas, entender e tentar criar um experimento. O experimento não deu, deixa eu tentar outro. Se deixar, o sistema tende a uma desordem maluca. Quando cheguei lá no Luiz Labs, foi começo de 2017. Eles estavam com 180 pessoas e eu fui ajudá-los a se tornar uma TI única, todas as pessoas que não eram parte do Labs, mas eram da tecnologia do Magalu, iam virar uma coisa só.

Eles se tornaram 380 pessoas, mais ou menos. Foi um momento de aculturamento grande. A empresa foi adquirindo mais empresas em 2017, 2018, 2019. Hoje a gente está com 1.200 pessoas, em 3 anos. Minha missão é mais ampla, a gente fala dos 30 mil colaboradores. A gente oferece treinamentos para os 30 mil, tem mentoria para os 30 mil, faz projetos de imersão atuando naqueles KPIs que falei, NPS, contact rate, um fluxo de valor que tem pessoas de tudo que há lá dentro.

Como é que faz para escalar? Eu tenho ido muito na linha de tentar identificar quem é o cliente final e qual é o fluxo de valor. Com base nesse fluxo, a gente tenta criar os times em volta para fazer aquele fluxo evoluir. Por exemplo, quando cheguei em 2017, a parte de pós-venda do Magalu tinha várias deficiências: você não conseguia acompanhar como estava sendo feita a sua compra, em que passo, como estava o tracking. A gente falou, o fluxo de valor tem toda uma parte depois que ninguém está tomando conta. A gente criou um time ali.

O squad, multidisciplinar, com pessoas olhando para aquele fluxo e para aqueles indicadores o tempo inteiro. Foi indo, o time foi crescendo, virou uma tribo. Hoje a gente tem uma tribo gigantesca que só pensa nessa questão da jornada do cliente nessa parte final. A gente está olhando o fluxo, começa de uma forma embrionária, um squadzinho vai indo, vira dois, três, vira uma tribo. Hoje a gente tem o que no Spotify chamávamos de aliança, aqui chamamos de vertical, como se fosse uma unidade de negócio, tem um diretor em cima, mas várias tribos dentro dessa vertical.

A gente tem uma vertical inteira olhando para a nossa questão do seller, que a gente está muito forte no marketplace. Tem outra olhando muito para a nossa plataforma digital. Mas para escalar, a ideia é essa: olha o seu cliente, olha o fluxo de valor e vai tentando criar experimentos em cima.

A gente tem agora time de alta performance. Já tem agilidade organizacional? Se perguntar isso ao Klaus Leopold, que esteve com a gente lá no Magalu, ele nem gosta desse nome, time de alta performance. Eu não sou tão radical assim, mas acho que uma das coisas que o time de alta performance tem que olhar é justamente se ele está num fluxo de valor o mais ponta a ponta possível, pensando no cliente. Porque, se ele for um time isolado, pode estar fazendo uma grande otimização local. A resposta para mim é não: um time de alta performance não vai garantir agilidade organizacional nenhuma, e multiplicar vários deles também não necessariamente, porque tem um trabalho grande a ser feito em outros níveis da empresa.

Por exemplo, desde que cheguei lá em 2017, a empresa era baseada em projetos anuais. A gente conseguiu pegar e olhar para indicadores. Mais recentemente, a gente conseguiu quebrar esse ciclo: hoje no Magalu a gente tem ciclos quadrimestrais, a cada quatro meses a gente para, planeja quais são os próximos indicadores, cria hipóteses em cima. Isso habilitou a agilidade acontecer de uma forma melhor. Isso está completamente fora do escopo de um time, são coisas que você tem que fazer em outros níveis, com diretores, com C-level, muita conversa para mexer na estruturação da empresa.

Dá para fazer algumas analogias muito boas com skills que cada um precisa ter dentro de uma bateria de escola de samba, que tem que ser diversa, se todo mundo tocar o mesmo instrumento, não vai ser uma bateria de fato. E tem que estar na mesma direção, todo mundo tocando a mesma música, no momento certo. Se você tiver a melhor bateria do mundo, uma bateria de alta performance, não necessariamente você vai ter a melhor escola de samba, porque o desfile não está limitado ao time da bateria.

É como um conjunto de pessoas que organicamente vai fazendo a coisa acontecer, mas não em áreas isoladas. Se a gente conseguisse traduzir de forma sonora o que a empresa está tocando, ia sair umas aberrações muito doidas, uma pessoa dançando funk, outra rock, enquanto tentam tocar samba usando uma gaita de fole.

As métricas ajudam muito nisso: a gente está caminhando para a mesma direção, num ritmo bom, cada um conseguindo contribuir para um bom desfile. A principal diferença é que o desfile das organizações nunca acaba, essa é a grande diferença. Por onde as pessoas que estão ouvindo, no trabalho ou em casa, por onde começar?

Eu acho que tem muitas ações individuais que conseguem ter um efeito muito bom no resto do sistema. Se você for voltar para o seu dia a dia de trabalho, a primeira coisa que eu tentaria fazer é tirar a cabeça de dentro d'água um pouco, tentar não estar afogado. A minha dica é: para um pouquinho, algumas horinhas, para de fazer o trabalho que você está fazendo, e pensa sobre o trabalho que você está fazendo.

Começa a pensar quem é o seu cliente, por onde a informação flui até chegar na sua mão, depois que sai da sua mão vai para onde. Depois que você conseguir fazer essas conexões, será que isso está visível o suficiente? Como que a minha parte se conecta com o resto da empresa? Entra muito um trabalho primeiro de percepção, de observação. Segundo, de deixar tão explícito quanto possível, desde os indicadores que norteiam o trabalho até o fluxo, porque o trabalho do conhecimento é invisível por natureza. E depois que você estiver enxergando, entra o ponto de pensar, dado isso, onde estão os problemas?

Dados os problemas que eu tenho, tem algum ponto que se eu fizer uma pequena mexida, talvez eu consiga ter um bom resultado? Vou lá, faço algum experimento em cima disso, e começo a tentar fazer disso um hábito, para não viver afogado. Hoje tem muita gente afogada, se afogando cada vez mais, começando a ter crise de burnout, começando a sofrer de ansiedade, muito porque não está conseguindo tirar a cabeça d'água para respirar e tentar olhar o rio e o cenário. Fazer esse exercício mais frequentemente, se possível pareando com alguém, trazendo alguém para o lado, trocando ideia.

Processo colaborativo. Eu acho que posso complementar, a primeira coisa a ser feita é você pensar bastante qual é o problema que você quer resolver.

E por quê. As pessoas do Lean vão muito nessa linha, um problema muito bem definido já está praticamente metade solucionado ali. Já é um caminho. E aí entra muito daquela questão do protagonismo, no método Kanban a gente fala em atos de liderança em todos os níveis. Vai ter problemas que você consegue resolver sozinho com o seu time, dentro da sua esfera. Mas vai ter a segunda esfera, que é a da influência, em alguns momentos vai ter que conversar com outros times, outros líderes, outras áreas.

Você vai ter que montar uma coalizão, ter aquela visão junto, para fazer com que aquele problema seja solucionado. Uma coisa que eu tenho aprendido muito na questão de transformação digital é que uma das principais virtudes que você tem que desenvolver é a paciência: alguns problemas você resolve em dois meses, mas vai ter problemas que você vai conviver com eles por um ano, um ano e meio. E às vezes eu vejo pessoas que ficam seis meses na empresa e trocam, seis meses e trocam, qual é o case que você está construindo? Eu diria, resista um pouco pelo menos.

Consiga fazer esses cases, lute para que aquele problema vá para um outro nível. Uma dica legal também é da Donella Meadows, que tem um artigo bem legal sobre alavancas sistêmicas: questione os objetivos, talvez eles sejam o melhor lugar para começar a atacar uma mudança. Isso é muito forte, qual é o objetivo daquele sistema? Às vezes você consegue entender o objetivo e trocá-lo, e isso já muda completamente. Eu tenho alguns exemplos assim: um time tomando conta de uma aplicação, você chega, cria uma missão para aquele time, mudou o objetivo, mudou os comportamentos, mudou a forma de acontecer.

O outro exemplo que dei: a empresa estava com projetos, o objetivo era entregar projetos. Você troca, agora é uma métrica tal, você muda completamente. Se as coisas estão funcionando hoje de tal jeito, o comportamento que está acontecendo é porque tem algum objetivo lá que pode estar até escondido, e você não sabe. Tenta fazer esses objetivos ficarem explícitos, porque uma vez explícito, fica mais fácil interagir com eles.

Se você quer praticar agilidade organizacional, pensa nisso de uma forma ágil. Não ache que traçando um plano gigante e depois botando esse plano em execução as coisas vão se resolver. Se você quer ser ágil, pratique agilidade para ser ágil. Faz experimento, vê o que aconteceu depois do experimento, adapta, faz mais experimento, vai observando o caminho e adaptando.

Não adianta fazer um plano para ser ágil. Não adianta olhar a agilidade organizacional e falar, é só a gente ver como o Spotify resolveu, ou colocar o framework X que vai resolver. Não é bem assim.

Uma consideração final é tente enxergar o todo. A todo momento a gente tem aquela recaída de, tem esse time aqui, vou ajudar esse time. Por isso que agilidade organizacional não é post-it: muitas vezes fica aquela conotação de que agilidade é só tecnologia, é só post-it, agora é só colocar post-it no marketing que lá está ágil também. Não é por aí. Você tem que conseguir dar um passo para trás e ver as coisas como sistemas mesmo: lá em cima, a empresa toma decisões, como ela decide alocar o dinheiro, por que está tomando essas decisões, e de quanto em quanto tempo ela revisa essas decisões?

Ela tem algum ciclo para aprender sobre a decisão que foi tomada? Quando você olha o todo, você fala, estou vendo que está tendo problemas nos times ou nos squads, mas vou resolver aquele problema lá primeiro. Um problema que eu enfrentei muito foi questão de WIP gigantesco no nível portfólio: eu poderia tentar criar qualquer time de alta performance, qualquer squad de alta performance, não seria suficiente. Não ia resolver o problema. Eu falo que é agilidade para resolver efeito colateral, e isso não motiva ninguém. Eu tento fazer agilidade para resolver as causas raízes, e é nessa que entra a paciência, às vezes demora, para conseguir mudar a coisa lá em cima vai todo um processo de gestão.

Mas não desista, que as coisas vão acontecer sim. É um processo mais evolucionário do que revolucionário.