A sala de reunião tinha um designer, um desenvolvedor, um analista de marketing e Carlos — o único de operações. O projeto era novo e exigia que todo mundo contribuísse.
O designer falava em fluxo de experiência. O desenvolvedor falava em arquitetura de sistema. O analista de marketing falava em conversão. Carlos ouvia e sentia que estava num país estrangeiro.
— Carlos, o que você acha? — o designer perguntou no meio da reunião.
— To tentando traduzir ainda — ele respondeu, honesto. — O que você falou sobre fluxo, pra mim, faz sentido se a gente pensar em como a operação vai executar. Mas eu preciso entender melhor o que você quer dizer com "ponto de atrito".
O designer explicou. Dessa vez com exemplo concreto.
Carlos anotou. No fim da reunião, ele tinha aprendido três jargões novos e ensinado dois termos de operação que ninguém sabia.
Na segunda reunião, já estava mais solto. Começou a perceber que cada um via o mesmo problema de um ângulo diferente — e que o ângulo dele, de operações, era essencial para o projeto não quebrar na execução.
— Se a gente fizer desse jeito — Carlos disse, apontando para o quadro — a operação consegue rodar. Mas precisa de dois dias a mais de setup.
— Dois dias a mais vale o ganho de experiência? — o desenvolvedor perguntou.
— Vale — o designer respondeu.
Fecharam o planejamento.
Trabalhar em time multidisciplinar não era sobre saber tudo. Era sobre aceitar que cada um sabia algo que o outro não sabia — e que o resultado final era melhor quando todo mundo ensinava e aprendia ao mesmo tempo.
*Continua em: 139 — Como comunicar uma demissão para a equipe?*