A Squad dos sonhos: Lições de um Time que Deu Certo
Uma história verídica para dizer que o perfeito não existe, mas o saudável, respeitoso e performático é possível.
Vou começar dizendo que me considero muito sortuda. Assim que fiz minha transição de carreira para Product Manager, tive a oportunidade de trabalhar com um produto do qual eu dominava a parte de negócios e com um time internacional formado por pessoas incríveis. Além de tudo, tínhamos uma liderança que confiava, nos dava um objetivo, um prazo e nos deixava trabalhar como entendêssemos ser o melhor jeito.
Então sim, nós éramos privilegiados naquele momento, e isso nos deu a oportunidade de testar dinâmicas de trabalho diferentes.
Minha intenção com esse artigo não é te dar uma receita para o sucesso do seu time, até porque, não existe uma. Durante os dois anos que estive nesse time, mudamos várias vezes o formato de trabalho, porque as necessidades e as pessoas eram diferentes ao longo do tempo e íamos nos adaptando.
Tem uma coisa muito importante que guia o sucesso de qualquer método de trabalho, mas vou falar dela no final dessa conversa.
O que quero compartilhar aqui são ideias que considero bem sucedidas e que você pode testar.
Quero muito que mais times possam alcançar resultados como os nossos com a saúde mental em dia e construindo amizades também, por que não? O perfeito não existe, como eu já disse, mas existem muitas possibilidades de tornar o ambiente de trabalho, onde estamos 8h por dia, em algo prazeroso e motivador.
Chega de bla bla bla e vamos ao que interessa. Separei em tópicos para a leitura ser mais fluida e te ajudar a ir direto ao ponto caso não queira ler tudo.
O ambiente importa
Primeiro de tudo é preciso que o time tenha uma liderança alinhada que dê espaço para testes. Talvez esse artigo possa ser o recadinho que precisa ser passado para seu líder centralizador. Mas também vale lembrar que por trás da centralização e do famoso “top down” está a insegurança, e isso pode ser trabalhado pelos líderes da squad.
Nós só conseguimos chegar em um modelo legal de trabalho porque tínhamos espaço para testar e errar, ou seja, um espaço seguro. Nossa liderança nos dava objetivos e prazos e o resto era com a gente. A autonomia é de extrema importância para que times se desenvolvam, e nosso papel como líderes (ainda que indiretos) é lutar pela autonomia do nosso time.
Outra coisa que é importante dizer é que tínhamos pessoas bastante maduras no time, não necessariamente em tempo de experiência, mas maduras no sentido de saber que discordar é importante, saber ouvir, saber aceitar quando “perde” uma discussão e por aí vai.
Eu trouxe esses pontos aqui porque eles são a base. Se vocês não têm essas características com as pessoas com quem trabalha, talvez seja necessário trabalhar nessas coisas também, para garantir sucesso. Seja na construção desse ambiente ou na construção da sinergia e ambiente para que a squad se desenvolva.
Objetivo compartilhado
Isso aqui é bem básico, mas ainda vemos acontecer umas coisas estranhas por aí.
Para ser objetiva, nunca em hipótese nenhuma os objetivos de engenharia e design podem ser diferentes dos objetivos de produto. Essas 3 áreas precisam estar alinhadas.
Lembra: a squad é formada por 3 competências, então 1 squad = 1 objetivo. Podem ser áreas de atuação diferentes, mas fazem parte do mesmo time, e portanto precisam buscar os mesmos resultados.
“Ah, mas engenharia precisa ter objetivos técnicos relacionados às melhorias da arquitetura…” tudo bem, no final do dia, melhorar a arquitetura serve para que? Para ter um produto mais estável ou garantir escala, talvez? Então, esse também é um objetivo de produto e design. Ainda que eles não estejam tão envolvidos na execução precisam estar comprometidos para garantir espaço no roadmap e negociar essa necessidade com stakeholders, por exemplo.
E não só, para garantir sucesso de verdade, os objetivos de negócios também precisam ser alinhados. Aqui, a alta liderança tem um papel muito importante. Mas se você perceber que não existe esse alinhamento, é o momento de cobrar que ele exista. Imagina se as áreas de CS e vendas tem um objetivo que é impossível de ser alcançado devido a uma deficiência no produto? Pode apostar que se esse cenário existir, nosso planejamento não será seguido e precisaremos mudar todo o programa ao longo do trimestre.
Na ocasião, a empresa trabalhava com a metodologia OKRs e os objetivos eram da unidade de negócios toda. Isso ajudava muito a garantir todos remando pro mesmo lado — um viva para nossos time de PPMA que garantia essa comunicação a nível empresa.
Ideação conjunta
Se tem uma coisa que eu vejo dar meleca por aí, é design ou produto pensar na solução sem envolver tech. Quantas vezes o designer apresentou uma experiência incrível, linda, maravilhosa e inviável de ser desenvolvida?
Bom, para resolver esse tipo de problema a gente tinha uma abordagem que pode ser muito polêmica, mas no nosso caso funcionava muito bem.
Desde a definição dos KRs do quarter, passando pela escolha das iniciativas e depois a construção da solução e da experiência, nós envolvíamos todo time de engenharia, não de forma obrigatória, mas todos eram convidados a idear juntos. Além disso, também convidávamos stakeholders para que pudessem co-criar.
As rotinas que vou descrever aqui aconteciam durante uma semana a cada trimestre, e ao longo do quarter, entrávamos mais no detalhe e replanejávamos caso necessário. Isso é importante de ser dito, pois um dos argumentos que sempre ouço de não envolver o time, é que eles “perdem tempo” em reuniões. O ideal é que a gente não pare o time toda semana, e mesmo na semana de planejamento, que isso seja organizado para ter tempo de reunião e tempo de desenvolvimento. Então, 1 vez por quarter fazíamos uma imersão, e depois, garantíamos a manutenção do planejamento.
Vou entrar um pouco mais a fundo nas nossas cerimônias de planejamento, apesar de que cada um desses itens daria um artigo, então precisarei resumir de qualquer forma.
Definição OKR
Começando pelo começo: a empresa nos dava objetivos, nossa liderança de produto e tecnologia, o direcionamento da nossa área, e nós como time definíamos nossos Key Results. Sem que esse primeiro ponto esteja muito claro para todos os envolvidos, nada mais faz sentido.
Nós costumávamos fazer um workshop do time e com as pessoas de negócios (CS, Vendas, Business Development). Como dito anteriormente, todas as pessoas desenvolvedoras eram convidadas, mas a participação não era obrigatória — ainda assim, sempre tivemos participação de todos, pois ao contrário do que todo mundo pensa, boa parte das pessoas técnicas gostam de ser envolvidas.
A seguir o passo a passo do nosso workshop:
1. Apresentação dos objetivos — um tempo dedicado a explicar os objetivos da empresa, da nossa unidade de negócios e o porque ele é importante nesse momento.
2. Revisão dos dados atuais que têm relação com o objetivo — é o momento para olhar para nossos resultados agora, entender juntos nosso ponto de partida, e aqui eu como PM mostrava os dados de todos os aspectos de produto e negócios que tinham relação com os direcionamentos que recebemos.
3. Resultados chave — Dedicamos um tempo para colocar em post its todas as métricas que nós como produto podemos movimentar para alcançar esses objetivos. Esse é um exercício muito legal, onde surgem discussões do que são key results e do que são apenas métricas que devemos acompanhar como time. Após a discussão, fizemos a votação de quais são os KRs que fazem mais sentido e que nós, como time, conseguimos mover com mais independência.
Após o workshop, o trio de liderança ficava com a tarefa de encontrar as metas dentro das metas que decidimos movimentar, e o cálculo era feito considerando tempo de entrega e expectativa de resultado ao longo do tempo.
Fazer esse exercício com o time é relativamente simples, mas ajuda que todos exercitem o senso crítico e conheçam as métricas que acompanhamos, além de quais são mais relevantes para o objetivo da empresa. Após isso, sempre que uma demanda aparecer de última hora, todos têm capacidade de questionar se ela realmente faz sentido, e se vale a pena priorizá-la nesse momento, seja ela uma iniciativa técnica ou não.
Definição de iniciativas
Era só depois de definir quais ponteiros mover que falávamos de iniciativas. Nesse momento todo o time participa com ideias.
A dinâmica começa com todo mundo colocando em post its o que podemos desenvolver para alavancar o resultado chave, sem discutir ainda sobre complexidade de desenvolvimento.
Depois vamos afunilando, dedicamos tempo para estressar as ideias que o time acha mais interessante e discutir viabilidade, por fim, fazemos uma pré-priorização utilizando framework simples de complexidade x impacto.
Importante ressaltar que nós não decidíamos nada de forma definitiva, e era importante deixar claro para todos os envolvidos que essa é uma pré-priorização e a proposta não é ter uma super acuracidade técnica.
A partir do resultado desse encontro, aí sim, o trio de liderança faz um cálculo de custo técnico de desenvolvimento x o cálculo do ganho, apresentamos a proposta para stakeholders e só no final de tudo isso é que conseguimos fechar o que será nosso roadmap do quarter.
Nesse segundo momento pode ser que as decisões mudem um pouco, mas depois de todo o processo é fácil explicar pro time o que está sendo alterado e o porquê se estivermos mantendo a coerência do discurso.
Processos de Design
Outra dinâmica interessante, proposta pelo nosso designer, foi rodar uma versão adaptada de design sprint com o time sempre que precisávamos criar ou mudar algo importante da nossa experiência.
Essa dinâmica reduzia o trabalho dele, garantindo que ele não criaria uma experiência linda, mas que seria impossível de desenvolver e trazia para o time técnico a importância da alteração proposta.
Na dinâmica todas as pessoas do time desenhavam um rascunho da experiência, juntos voltávamos nas que faziam mais sentido, considerando o resultado esperado e o tempo de desenvolvimento.
Depois, com todos os nossos rascunhos e discussões, ele criava o design muito mais rápido e o time também conseguia desenvolver mais rápido, visto que já sabiam o que era necessário.
Antes de finalizar sobre nossas dinâmicas, quero argumentar mais uma vez o porque acho importante a participação do time.
Ao contrário do que todos pensam, o time técnico ganha tempo.
Ao participar da construção do planejamento, o time tem visão do futuro, conseguem antecipar problemas e trazer o ponto de vista técnico para discussões de negócio antes que seja tarde demais.
Essas dinâmicas colocam todos na mesma página em um nível que qualquer pessoa do time pode se ausentar que o restante consegue seguir sem problemas.
Contando que a gente consiga balancear a participação deles, sem atrapalhar as entregas, todo mundo sai ganhando. E para garantir isso, o tempo investido nos exercícios, precisa ser considerado na hora de prometer o que vamos entregar, é tão simples quanto isso.
Manutenção da Dinâmica ao Longo do Trimestre
Como eu disse anteriormente, as dinâmicas são feitas a cada trimestre. Mas se você é um PM hoje, você sabe que tudo muda o tempo todo. Seja por uma nova norma, uma movimentação do mercado, algum achado novo do time de negócios ou o humor da diretoria. Além disso, nem sempre as nossas ações estão movimentando os números como esperado e recalcular a rota é preciso.
Então, nós tínhamos algumas formas de garantir que toda a mensagem passada no planejamento fosse reforçada e mantida ao longo das semanas, mas que também fosse rápido mudar a direção caso necessário.
A primeira coisa é o acompanhamento semanal dos KRs, e principalmente um radar que nos mostra quão distante estamos do nosso objetivo.
Além disso, tínhamos um canal só da nossa squad para uma newsletter. Nele, eu fazia postagens com todo tipo de novidades discutidas nas reuniões, notícias importantes do mercado e ações de outros times que poderiam ter impacto em nosso planejamento.
Como nosso time trabalhava remoto e com fuso horário diferente, a news era um formato que funcionava muito bem. Cada um podia ler a hora que fazia sentido dentro da sua rotina e quando nos encontrávamos nas cerimônias semanais, caso tenha ficado alguma dúvida, curiosidade ou alguém tenha tido alguma ideia, discutiamos aquele assunto juntos.
Time de Tech, Áreas de Negócios e os Clientes
Colocar todo o time na mesma página e manter essa sinergia demanda dedicação e constância.
Qualquer um do nosso time podia participar das nossas entrevistas com os clientes, mas com os desafios do idioma e do fuso horário era muito desafiador para que isso acontecesse de forma síncrona.
Para resolver esse problema, nós tínhamos uma página com os vídeos das entrevistas, assim todos poderiam assistir. Além disso, trechos importantes eram incluídos na news, e os depoimentos positivos iam para uma página que chamava “coração quentinho”. Quando a gente precisava lembrar porque fazemos o que fazemos, era só dar uma olhadinha ali, onde colocávamos trechos, prints e áudios dos clientes.
Testamos fazer algumas vezes uma dinâmica de juntar ideias e encontrar quickwins a partir do vídeo das entrevistas, mas essa abordagem foi um pouco mais difícil de manter e gerar resultado, não é tão fácil priorizar só com argumentos qualitativos.
O nosso time também sabia quais eram os times de negócios, o que elas faziam, e como nosso trabalho impactava o trabalho dessas pessoas. Dessa forma, caso precisassem poderiam, pedir ajuda para essas pessoas diretamente. E decisões que não mudassem o rumo do que tinha sido definido podiam ser tomadas de forma autônoma.
Celebração de Conquistas
Para fechar o ciclo todo, criar formas de celebrar as nossas conquistas dava o gostinho especial de pertencimento para todos.
Criamos uma página no confluence chamada “coração quentinho”, onde colocávamos prints, áudios, trechos de entrevistas, com elogios tanto dos clientes externos como dos nossos stakeholders. No dia que batia aquela bad, e dúvida do porque fazemos o que fazemos, dar uma olhadinha nessa página ajudava demais.
Fazíamos encontros para ouvir juntos os depoimentos da página coração quentinho e reuniões para ouvir dos nossos stakeholders o impacto das entregas, mas o mais legal, era quando a gente apresentava as métricas juntos para alta liderança, seja diretoria, VPs ou Heads.
Nós fizemos tudo juntos, e tínhamos que encerrar juntos. É preciso garantir o pertencimento do começo ao fim, e para o time de desenvolvimento ouvir a parabenização da alta liderança e saber que eles sabem quem fez parte daquilo encerra o processo com chave de ouro.
Papel do PM na Construção desse Cenário
O Product Manager não é CEO de nada, nem líder de ninguém, mas tem responsabilidade sobre o produto e o poder de influenciar pessoas. E depois de ler sobre todas essas ações que foram realizadas pelo nosso trio de líderes da época. Deve estar se perguntando qual especificamente é o papel do PM nessa jornada toda?
Primeiro de tudo e mais importante, eu diria que o PM tem o papel de construir confiança com time, liderança e stakeholders.
A confiança é, na minha opinião, a chave para que tudo isso possa acontecer, seja para que os líderes e os stakeholders confiem que o time vai tomar boas decisões, seja para que as pessoas do time sintam que têm espaço seguro para dar suas ideias, discordar, discutir e errar.
Condorda comigo que se existe segurança, a necessidade de topdown e centralização diminuem e a autonomia aumenta? Pois é, mas conquistar esse lugar demanda tempo, dedicação, visibilidade e comunicação. Tudo isso é papel do PM.
É a soma de pequenas ações que te levam para esse lugar. Veja alguns exemplos:
Liderar indiretamente. O PM não lidera o time técnico diretamente, mas nada impede que ele faça 1:1 com as pessoas, entenda seus desejos e habilidades. Dê feedback quando necessário e aprenda a aprender com essas pessoas. Construir liderança por influência é papel do PM e ajuda a garantir boas entregas.
Ser o louco das métricas. Pode ser que você não seja a pessoa responsável por construir dashboards de métricas, mas é sua função usar de forma inteligente as informações que os dados nos trazem. É preciso ser curioso sobre os números e sempre levar as conversas importantes para o que as métricas estão dizendo.
Vender as entregas. Todo dia é importante mostrar para toda a empresa o que o time conquistou, por menor que seja, mostrar e reforçar o impacto ajuda a construir na cabeça das pessoas que esse time é capaz de gerar valor.
Negociar. Priorizar um roadmap é ter no seu colo 10000 demandas e ter capacidade de entregar 4. É nesse momento que você pode sugerir alternativas que não dependem de tecnologia. Argumenta com números e se apoia nos objetivos da empresa o que não será entregue e muitas vezes tenta um puxadinho em alguma squad parceira para conseguir fazer tudo o que precisa.
Comunicar. Nada que é dito apenas uma vez e de uma forma pega na cabeça das pessoas. Muitas vezes é preciso ser repetitivo, gravar vídeos, fazer threads e documentar para que a informação seja fixada. E sim, garantir que a informação seja entendida e enraizada é também papel do PM.
Organizar e mediar. Todos esses encontros citados aqui exigem uma organização prévia, alguém que vai lá e agenda as datas, prepara as dinâmicas e mediar as discussões, isso pode ser dividido no trio, mas é nosso papel também.
Ser honesto e vulnerável. Muitas vezes vamos precisar chegar na liderança ou em algum time de negócios e dizer “deu ruim” vamos precisar de ajuda. E quando a gente faz isso de forma pró ativa já trazendo ideias de solução, você coloca mais um tijolinho na parede da confiança.
Tem muitas outras coisas que podem ser feitas, mas em resumo o nosso papel é assumir a responsabilidade pela entrega e extrair de todos os envolvidos o melhor possível garantindo que a informação esteja sempre igual nos quatro cantos e a entrega de valor aconteça no tempo certo.
Daria para ficar mais algumas horas falando sobre isso, mas espero que esse artigo tenha te inspirado e gerado boas ideias para que você possa testar com sua squad.
Eu particularmente, ainda não consegui chegar ao mesmo nível de performance e sinergia que tinha com esse time nas squads que atuo hoje. Mas o fato de ter vivido isso me coloca em uma posição de não me conformar com o que não está bom e sempre buscar melhorar.
De pouquinho em pouquinho a gente chega lá.
