[Parte 2.2 — Coaching] Empowered— Resumo em Português

O primeiro livro de Marty Cagan é um pré-requisito para qualquer pessoa ingressando na área de produtos. E, quando Inspired ainda não tinha tradução em português, na expectativa de democratizar o conteúdo no Brasil, fiz um resumo que você pode ler aqui.

Em 2020 os autores de Inspired lançaram Empowered. O novo livro foca no papel e competências da liderança de produto e é tão bom quanto o primeiro.

Já temos a Parte 1, Parte 2.1 e a Parte 3 do resumo de Empowered e agora começamos a Parte 2.2, seguindo ainda no tema de coaching.

—

Na última parte começamos a falar sobre dicas para a criação do plano de coaching, que é um plano de desenvolvimento criado por coach e coachee para trabalhar os pontos de desenvolvimento levantados no assessment. Falamos sobre como desenvolver as habilidades relacionadas com “Conhecimento sobre o Produto” e a seguir vamos abordar técnicas em processos e habilidades pessoais. 

Técnicas e habilidade em processos

Existem muitas técnicas de produto no mercado e inúmeras surgindo constantemente, sendo impossível conhecer todas. O importante aqui é garantir que o Product Manager conheça as técnicas que se encaixam com o que ele precisa de acordo com o desafio que tem na empresa.

Product Discovery 

É preciso entender os quatro diferentes tipos de riscos (valor, usabilidade, viabilidade técnica e viabilidade de negócio) e conhecer técnicas para mitigar cada um deles. Além disso, é preciso saber como medi-los quantitativamente e qualitativamente.

Uma forma de treinar os Product Managers no assunto é pedir para que eles leiam o livro Inspired (Inspirado) e, depois, discutir diversos cenários e quais técnicas eles aplicariam para mitigar os riscos em cada um deles. 

Otimização de Produto

Para produtos que estão em produção existe uma série de formas de aplicar a otimização, como, por exemplo, testes A/B voltados para otimização do funil de produto. 

Product Delivery

Em geral o delivery é focado no time de engenharia, mas é importante que o Product Manager entenda o que está sendo aplicado e, em alguns casos, tenha um papel mais ativo, como, por exemplo, quando grandes mudanças estão sendo colocadas em produção e decisões que envolvem custo precisam ser tomadas.

Processo de desenvolvimento de produto

A decisão de qual processo de desenvolvimento usar é do time de engenharia e sua liderança, mas é importante que o PM saiba e conheça o processo para entender também suas responsabilidades dentro dele. 

A maioria dos times usam Scrum, Kanban, XP (Extreme Programming) ou alguma mistura desses. Uma forma de desenvolver essa habilidade é fazer um curso/certificação de Product Owner (CSPO), no qual serão apresentadas as responsabilidades desse papel, mas veja bem, o que será apresentado é apenas uma pequena parte do que engloba o papel do Product Manager. Outro importante ponto de aprendizado é saber utilizar bem a ferramenta de gerenciamento de Backlog utilizada pela empresa. 

Habilidades Pessoais e Responsabilidade

Colaboração com o time 

A base dos times modernos de produto é a colaboração entre produto, design e engenharia, sendo assim, é importante que o PM consiga reconhecer a real contribuição desses perfis e que elas são tão relevantes quanto a do próprio Product Manager. Além disso, a PM precisa conseguir estabelecer relações de confiança e respeito com essas pessoas, para que seja possível colaborar de maneira efetiva. 

Uma maneira de ajudar na evolução desse aspecto é fazer reuniões para discutir problemas e soluções com os três perfis simultaneamente, e, posteriormente, dar feedbacks sobre as interações e como a PM contribuiu ou prejudicou a colaboração. 

Pontos a serem observados são, por exemplo: O quão engajados com o debate estava o time? Eles agiram como times com autonomia ou recebedores de pedidos? O designer e tech lead trouxeram soluções relevantes para discussão ou eles só criticaram o que foi proposto pelo PM? Gastaram muito tempo discutindo ou partiram para a prototipação? Como eles resolveram os atritos quando as opiniões eram divergentes?

Colaboração com Stakeholders

A maioria das dicas sobre colaboração com o time se aplicam também para colaboração com os Stakeholders, com a diferença que é mais simples construir relações com pessoas do time que você fala todos os dias. 

Stakeholders, em sua maioria, são executivos, conhecem muito da sua parte do negócio e estão acostumados a dar ordens, sendo assim é preciso dedicar esforços para construir relações de confiança com essas pessoas. 

É importante que o PM dedique um tempo para entender as preocupações e dores desses stakeholders. Uma vez que isso tenha sido feito, será preciso convencer cada um deles que o PM conhece e está buscando soluções para esses problemas. Construir essa confiança leva tempo. 

Evangelização

Especialmente em médias e grandes empresas, a persuasão é uma parte importante do trabalho. Isso envolve convencer seu time e os stakeholders que você entende o que precisa ser feito e tem um plano sólido de entrega. 

Uma boa técnica para evoluir nesse ponto é escrever as narrativas (será explicado melhor em um capítulo futuro). Outra dica é se inscrever em aulas de oratória, nas quais você recebe feedbacks profissionais. 

Liderança

Essa habilidade é muito relevante para Product Managers, pois apesar de não gerenciarem ninguém, tudo depende da sua capacidade de influenciar. Para desenvolver essa habilidade, foque em desenvolver a comunicação e a evangelização, além de estudar sobre liderança e aprender quais características distinguem líderes bons de líderes ruins.

Reuniões de One-on-One (1:1's)

Essas reuniões são a base do coach e existem alguns pontos cruciais para que elas sejam verdadeiramente efetivas. São eles:

• Propósito - o principal objetivo das 1:1's é ajudar as pessoas a melhorarem e a se desenvolverem para alcançarem seu potencial. Se você perder isso de vista, você perderá o real valor dessa sessão.
• Relacionamento - A pessoa deve confiar e acreditar que seu objetivo como gerente é genuinamente ajudá-la a atingir seu potencial. Vocês devem confiar um no outro para que consigam falar com honestidade e franqueza.
• Onboarding - Esse é um período importante no qual a pessoa de produto está adquirindo os conhecimentos necessários sobre o produto para que possa performar e é seu trabalho estar próximo nesse processo para evitar que a pessoa prejudique ao time e a ela mesma. 
• Frequência - Existem opiniões divergentes sobre a frequência ideal, mas os autores acreditam que elas devem acontecer pelo menos uma vez por semana, por pelo menos 30 minutos. Você pode, eventualmente, precisar reagendar alguma 1:1, mas nunca cancele ou pule esse ponto semanal. Para pessoas que estão no período de onboarding, é preciso de dois a três pontos por semana.
• Contexto - Para dar autonomia e empoderar as pessoas de produto para resolverem problemas, o gerente precisa dar o contexto estratégico, garantindo que os objetivos da empresa e do time estão claros.
• Tarefa de casa - Como gerente é possível direcionar, fornecer os recursos, tirar impedimentos, responder dúvidas, mas depende da pessoa realmente colocar a mão na massa e fazer o que precisa ser feito.
• Pensar e agir como uma pessoa de produto - Parte do coaching é ajudar o outro a pensar como uma boa pessoa de produtos, com foco em resultados, considerando os riscos, vendo o negócio e o produto de maneira holística, resolvendo problemas de maneira criativa, persistindo aos obstáculos, conseguindo colaborar com engenharia e design de maneira efetiva.
• Visão holística - Um dos grandes benefícios das 1:1's é ter visibilidade das atividades e problemas acontecendo em diversos times, possibilitando que você, como gerente, veja alguma dependência ou duplicidade acontecendo. Ao identificar esse cenário, você deve mencionar e encorajar a colaboração entre times.
• Feedback - Esse é o maior valor que você pode oferecer como gerente. Os feedbacks devem ser frequentes e imediatos (lembre-se de elogiar publicamente e criticar privadamente). Também é importante que você busque feedbacks sobre a pessoa com outros membros do time. Depois de um tempo, dar feedbacks construtivos deixa de ser incômodo e passa a ser instintivo, mas até lá, se esforce para conseguir que eles aconteçam toda semana.
• Desenvolvimento contínuo - O trabalho de produto não é fácil e podemos dizer que é uma jornada, não o destino. Sendo assim, é preciso estar constantemente aprendendo e explorando, visto que novas tecnologias aparecem, o comportamento dos usuários muda, as empresas crescem, as expectativas sobem. 

Erros mais cometidos

Muitos gerentes dizem conhecer e praticar o que foi falado acima, mas mesmo assim não conseguem desenvolver seus liderados. Aqui estão alguns motivos mais comuns destacado por Cagan e Jones:

• Não se importar - Isso acontece quando o gerente não gosta de desenvolver pessoas ou não vê esse ponto como sua principal responsabilidade, então ele acaba deixando de lado e passando a mensagem para o liderado de que ele "está sozinho". 
• Microgerenciamento - É mais fácil passar instruções específicas e microgerenciar, do que dar autonomia e confiar. Entretanto, essa não é uma solução escalável, visto que você não vai desenvolver as pessoas que precisar e tudo resultará em decepção.
• Falar mais do que escutar - Não existe nada de errado em levantar pontos para discussão, mas não se deve perder o foco de que o 1:1 é primariamente para o liderado e não para o gerente. 
• Não dar feedbacks difíceis - Sem feedbacks construtivos as pessoas não evoluem da forma como poderiam. 
• Insegurança e/ou incompetência - Essas tecnicas assumem que o gerente não é inseguro ou incompetente, que ele entende que o sucesso das pessoas do seu time é o seu sucesso. 
• Não mitigar as perdas - É importante conseguir identificar quando alguém não quer ou não vai se desenvolver para atender as expectativas para o papel. Sendo capaz de resolver o problema do time e criar a oportunidade para que a pessoa seja bem sucedida em algo que faz sentido pra ela.

A narrativa escrita 

Essa técnica é descrita como uma das preferidas dos autores, mas também a que gera maior resistência. Ela consiste em realmente escrever a narrativa explicando as recomendações e argumentos para cada uma das propostas de produto.

Geralmente ela gera um documento de, mais ou menos, 6 páginas, que narra o problema, como ele importa para o cliente e para o negócio, e sua estratégia para resolvê-lo. Em seguida, trabalhar em uma FAQ (Frequently Asked Questions), buscando antecipar as preocupações e perguntas que os executivos e stakeholders fariam. Se a narrativa estiver bem feita, o leitor será convencido e inspirado.

O benefício de usar essa ferramenta é que a pessoa de produto conseguirá ver as falhas de raciocínio antes de de fato se comprometer com ela, levando seus argumentos de maneira mais assertiva para o time e stakeholders.

Contexto Estratégico

Entender o contexto de negócio em que o produto está inserido é o que irá possibilitar que o time tenha autonomia para tomar as melhores decisões. Sendo assim, é responsabilidade do gerente garantir que o time saiba e entenda esse contexto durante todo o processo.  

Geralmente existem 6 tipos de contexto estratégico:

• Missão da empresa: Esse é o propósito da empresa e deve explicar o motivo de tudo que está sendo feito. A missão é durável, olhando o horizonte de uma década ou mais. Se algum funcionário não souber a missão da empresa, existe algo bem errado acontecendo com a cultura e liderança, entretanto é comum que as pessoas não saibam como contribuir para essa missão.
• Scorecard (Dashboard de negócio) - Toda empresa possui algum KPI (Key Performance Indicator) que é acompanhado para entender a visão geral e a saúde do negócio. Esse Dashboard não olha para todas as métricas disponíveis, apenas para as mais importantes e é como os líderes entendem como está a performance da empresa.
• Objetivos da empresa - São determinados pela liderança sênior, geralmente em conjunto com o board, e consiste em áreas de foco que a empresa quer trabalhar em um determinado período para atingir resultados chave (key results). Reforçando, estamos falando aqui de resultados e não de entregas. Os resultados chaves a serem alcançados geralmente já estão no Scorecard, mas se não estiverem devem ser adicionados, para que seja possível medir o progresso dos objetivos e garantir que nenhum resultado negativo está impactando a saúde da empresa.
• Visão de produto e princípios - A visão descreve o futuro que estamos querendo criar em 3 a 10 anos e como ele irá mudar a vida dos nossos clientes. Os princípios complementam a visão ao definir os valores e crenças que devem nortear as decisões de produto. 
• Topologia de time - É importante que os times saibam como eles se integram na estrutura e como eles se relacionam com outros times.
• Estratégia de produto - A estratégia é o que conecta todas as outras coisas acima e é o que determina os objetivos dos times. Ela será abordada com mais profundidade mais pra frente no livro.

Sentimento de dono

Ser um bom profissional de produto também consiste em ter o mindset de dono, demonstrando ser bom para tomar decisões. Mas o que significa ter sentimento de dono? Em resumo, é verdadeiramente se sentir responsável pelo resultado da empresa. 

Algumas empresas buscam reforçar esse sentimento distribuindo equity da empresa para que as pessoas realmente possam ser donas. Essa estratégia nem sempre é simples, dado o sistema jurídico de cada país, mas tem sido cada vez mais adotada por empresas de diversos tamanhos. Além disso, é importante que essa estratégia seja constante (evergreen), ou seja, que os melhores funcionários estejam sempre recebendo mais equity, para que sintam que se saírem da empresa estarão perdendo uma oportunidade de ganhar mais dinheiro. 

Gerenciando o tempo

É comum a história da Product Manager que nunca tem tempo para se dedicar ao processo de discovery, pois passa todo seu tempo pulando de reunião em reunião e só consegue parar para realmente trabalhar a noite, depois do horário de trabalho. 

A verdade é que a maioria dessas pessoas gasta boa parte do seu tempo gerenciando projeto e não fazendo produto. Isso acontece por vários motivos, mas especialmente por ser mais tangível trabalhar em cima de tarefas.

Para quebrar esse padrão os autores encorajam que as pessoas de produto reservem pelo menos 4 horas por dia e bloqueiem esse horário na agenda. Sem isso, ou o PM irá acabar trabalhando fora do horário ou irá falhar em entregar os resultados necessários de negócio.

Pensar

Pensar e ser inteligente são coisas diferentes, assim como adquirir conhecimento e aplicar esse conhecimento na prática são coisas distintas. Para ser um bom Product Manager não basta ser inteligente, é preciso estar disposto a pensar e resolver problemas. É preciso se questionar sobre o problema, sobre a necessidade do que está sendo proposto, sobre possíveis alternativas, sobre potencial de mercado, sobre os custos, sobre como sustentar a operação, sobre potenciais riscos jurídicos. 

Para desenvolver essa habilidade os autores recomendam utilizar a técnica da narrativa escrita e trabalhar esse tipo de questionamento acima dentro do processo de coach. 

Colaboração com o time

Colaboração não é sobre consenso. Apesar de ser bom quando ele acontece naturalmente, não é algo que é buscado ou incentivado. As decisões devem ser de responsabilidade de cada especialidade e quando acontecem conflitos podemos utilizar de testes para resolvê-los. 

Colaboração não é sobre artefatos e critérios, apesar de eles serem aplicáveis e importantes em algumas situações (especialmente em times remotos). Por que disso? Pois quando o Product Manager define algo como critério é basicamente o fim da conversa e a discussão move para como implementar aquele critério.

Colaboração não é sobre se comprometer. Vocês precisam encontrar uma solução que funciona, ou seja, que tem valor, que tem uma boa usabilidade, que é tecnicamente viável e é também viável para o negócio. Isso requer verdadeira colaboração. 

Uma forma de atingir verdadeira colaboração é criar e discutir em cima de protótipos e mapeamento de storys (story maps). O Product Designer poderá considerar diferentes abordagens para a experiência, o Tech Lead poderá considerar implicações de diferentes abordagens e potenciais novas tecnologias, e o Product Manager poderá considerar os impactos de negócio das diferentes direções. Reforçando que não estamos buscando que as pessoas só falem sobre sua própria especialidade, mas sim que todos possam trazer insights para a solução proposta como um todo.

Ao final do processo o produto dessa discussão pode se tornar um artefato para o time, mas veja bem, o objetivo aqui é promover e facilitar a verdadeira colaboração.

Colaboração com Stakeholders

Em times de produto empoderados, o trabalho consiste em "servir os clientes de maneiras que eles amam e que funciona para o negócio" e não servir aos times de negócio entregando aquilo que eles querem e demandam. 

Em boas empresas de produto existe uma relação muito diferente com stakeholders, na qual a colaboração é essencial. O Product Manager não está lá para pegar solicitações e entender requerimentos, mas sim para criar uma parceria que pode resultar em melhores soluções para o negócio. A chave dessa colaboração é entender com profundidade as preocupações de cada um desses stakeholders, buscando entender o que de fato precisa acontecer para que as soluções propostas funcionem para o negócio e para os clientes. 

Síndrome do Impostor

Ansiedade e doenças mentais realmente existem e são coisas sérias. Dito isso, Marty acredita que mesmo as pessoas mentalmente saudáveis duvidam de si mesmas e se sentem inseguras sobre dar sua opinião para os outros, sendo esse um medo normal e saudável de se ter. Ele acredita que esse é um aviso da sua mente sobre as consequências que irão acontecer se ele não estiver realmente preparado e é esse receio que o move para estudar, pensar, compartilhar, buscar feedback e validar/invalidar suas ideias. 

Foco no cliente

O primeiro ponto é entender que o cliente é de fato aquele que opta por usar ou comprar seu produto ou serviço, e reforçar que os stakeholders não são clientes do time de produto. 

É necessário que os Product Managers entendam isso para que consigam colocar foco naquilo que importa, como, por exemplo, falar com pelo menos 3 clientes por semana, aprender com eles e conseguir compartilhar essas histórias com o time e a empresa.  

Ainda sim, é importante que o PM entenda que seu trabalho não é perguntar ao cliente o que ele precisa, mas sim entender e inovar para o cliente. 

Integridade

O trabalho de uma Product Manager é baseado em confiança, e competência e caráter são pilares para construção dessa confiança. Por sua vez, integridade é uma forte característica que compõe o caráter. 

A verdade é que a integridade de um Product Manager será testada em diversos cenários e é preciso que o coach consiga ajudar essa pessoa a identificar e evitar essas situações, entender as prioridades e o contexto em que está inserida, e lidar com diferentes personalidades. 

Além disso, é recomendado focar em desenvolver os três comportamentos a seguir: 

• Confiabilidade - É importante que a pessoa de produto entenda que caso se comprometa com algo, esse compromisso deve ser levado muito a sério ou isso prejudicará sua reputação com stakeholders, clientes, parceiros e time. A PM precisa entender que compromissos devem ser feitos apenas com base em informações fundamentadas e que, uma vez feitos, será preciso fazer tudo que é possível para entregar o que foi prometido. 
• Interesse da empresa - O PM deve estar sempre buscando o que é melhor para a empresa, não apenas para ele mesmo ou seu time. Mas como? Ajudando outros times a atingirem seus objetivos, indo além das expectativas para ajudar clientes e stakeholders, dar os créditos para outras pessoas publicamente, tomar decisões que não necessariamente são as melhores para o seu time, mas são melhores para a empresa e os clientes.
• Assumir a responsabilidade - Isso significa estar disposto a assumir erros e a buscar entender como poderia ter agido diferente para mitigar os problemas que impedem o sucesso do produto.

Decisões

Para tomar boas decisões é preciso manter em mente o resultado que se quer atingir e criar um racional que os líderes e stakeholders devem ser capazes de entender e respeitar, mesmo se eles próprios não tivessem tomado a mesma decisão. 

São 5 os principais pontos para serem desenvolvidos nesse aspecto:

• Tamanho/importância da decisão - É crítico conseguir reconhecer que as decisões não são igualmente importantes, assim como suas consequências. É preciso ponderar o nível de risco e associar um nível de consequência a elas. Dependendo dessa avaliação você avaliará se precisa coletar mais informações ou se já é possível tomar uma decisão com o que você tem hoje. 
• Decisões colaborativas - Boas decisões não são sobre todos concordarem com ela (consenso), sobre a satisfação da maioria (votação) e muito menos sobre ter uma pessoa responsável por todas as decisões. As decisões específicas de cada especialidade competem às pessoas que trabalham em cada área e o Product Manager deve confiar em seus pares para tomá-las.
• Resolvendo discordâncias - Em empresas com times de produto empoderados, discordâncias são normais e saudáveis, como, por exemplo, quando o Tech lead e o Product Designer discordam sobre a complexidade de implementação e relevância da experiência. Nessas situações é importante saber quando aplicar testes e cabe ao Product Manager conseguir liderar o time para chegar na técnica de discovery mais apropriada. 
• Transparência - Para que todos entendam e respeitem a decisão é preciso que o racional por trás dela esteja transparente. Para pequenas decisões uma explicação é o suficiente, já para grandes decisões é sugerido a utilização da narrativa escrita, explicada anteriormente. 
• Discordar e se comprometer - Em algumas situações, mesmo após testes, as pessoas irão discordar, o que não é uma coisa ruim. Porém, é preciso que o time entenda que no final é preciso tomar uma decisão e que os membros do time estejam dispostos a se comprometer com ela, mesmo que discordem. 

Reuniões efetivas

O problema das reuniões é que elas são síncronas, todos precisam parar o que estão fazendo e se dedicar a ela, o que não é fácil. Portanto, se existe uma forma assíncrona de resolver um problema, ela geralmente é um caminho melhor. Em empresas de produto existem, em regra, três tipos de motivos para fazer reunião, são elas:

• Comunicação - Existe uma informação importante que o organizador acredita ser muito complexa ou importante para ser passada de maneira assíncrona, por exemplo, por e-mail. 
• Decisões - Acontecem quando existem decisões que precisam ser tomadas que vão além do que o time de produto pode decidir sozinho, geralmente em razão do impacto delas atingir outras partes da empresa ou por terem um risco substancial. Nesse caso é sugerido que se comece a reunião lendo a narrativa escrita.
• Resolver problemas - Acontecem quando não sabemos qual a melhor solução para o problema, mas acreditamos que se as pessoas certas estiverem envolvidas conseguiremos resolvê-lo. 

Ética

Teoricamente a ética deveria ser considerada um ponto de preocupação dentro do risco de viabilidade de negócio, dado que uma solução não ética pode colocar a empresa em sérios problemas.  Porém, pela seriedade e pelo fato de que geralmente não existe um stakeholder responsável exclusivamente por esse ponto, tem sido discutido sobre a ética se tornar o quinto risco a ser mitigado pelo time de produto.

Devemos construir isso? (Risco de Ética)

Bons times de produto devem ponderar sobre como o que eles estão criando afetam a comunidade como um todo. A solução é boa para o cliente? Ela afeta o ambiente ou o restante da sociedade de alguma maneira? Ficaríamos envergonhados se nossas discussões sobre o assunto fossem divulgadas? É preciso se fazer perguntas como essa para conseguir proteger a empresa e a sociedade.

Felicidade

O clichê que diz que as pessoas entram para a empresa, mas abandonam o gerente é verdadeiro. É importante que o gerente se pergunte e avalie se as pessoas do seu time estão felizes observando como cada um se sente em relação aos pontos abaixo.

• Trabalho significativo - A maioria das pessoas de produto quer que seu trabalho seja significativo e importante. Esse é um dos pontos que mais contribui para a felicidade na empresa, até mais que o reconhecimento financeiro, entretanto esse ponto nem sempre é claro para as pessoas e é importante que isso seja falado de maneira clara, explícita e reforçada constantemente pela liderança.
• Relacionamentos pessoais - As relações profissionais são construídas em cima de relações pessoais. É importante conhecer as pessoas do time para que seja possível fazer um melhor trabalho como gerente ao saber quais são seus desejos e motivações.
• Reconhecimento - Promoções, aumentos e equity são formas claras de reconhecimento, mas existem maneiras mais pessoais e frequentes que também podem e devem ser utilizadas pelos gerentes, como, por exemplo, presentear com um vinho, um livro, um ingresso, um jantar, uma viagem. 
• Hábitos de trabalho - Não é novidade que em times de produto trabalham muito, mas existe uma diferença importante em trabalhar muito porque quer e por precisar ou ser forçado. No caso em que a pessoa trabalha muito por querer, é preciso que o gerente fale sobre isso nas 1:1's e se esforce para garantir que o time entenda que o descanso é essencial, inclusive para uma melhor performance.
• Exemplo de bom comportamento - Se o gerente realmente se importa com a felicidade do seu time, deve ser o bom exemplo e garantir que suas ações sejam condizentes ao que deseja que o time também faça.
• Planejamento de carreira - Também é importante reconhecer que existem casos em que para que a pessoa realmente seja feliz ela precisa encontrar seu caminho para outro trabalho ou carreira. 

—

Aqui fechamos a parte 2 do livro, com muito conteúdo e várias dicas para promover uma liderança focada em desenvolvimento contínuo. Se você ainda não leu a Parte 1, Parte 2.1 e a Parte 3, aproveite para se inteirar antes do próximo capítulo, ein?!

Na próxima parte vamos falar sobre contratação e o dia a dia de tocar um time. O foco será na parte “organizacional” da liderança e falaremos sobre recrutamento, entrevistas, onboarding, demissão e promoções.

Espero que tenha te ajudado e te espero para o próximo texto!

Obrigada e até breve.