Por que você deve tratar sua empresa como um produto
Por que você deve tratar sua empresa como um produto
Líderes outcome-driven enxergam as organizações como algo que eles podem alterar, testar e evoluir. Como um produto.
Bem-vindo ao terceiro artigo da série sobre a construção de organizações outcome-driven e a obtenção de resultados com OKR. Se você ainda não leu os artigos anteriores, eu recomendo começar por eles:
No final deste artigo, você encontrará uma lista de perguntas para discussão para ajudá-lo a colocar o artigo em prática.
Este post também está disponível em Inglês.
Líderes outcome-driven definem o sucesso com base em outcomes, mas não param por aí. Eles também tratam as organizações como produtos—algo que eles podem alterar, testar e evoluir.
Steve Jobs é o maior exemplo de um líder que geria a empresa como um produto. Quando perguntado sobre de qual produto ele tinha mais orgulho, ele respondeu:
Fazer um produto é difícil, mas criar um time que possa fazer produtos continuamente é ainda mais difícil. O produto do qual tenho mais orgulho é a Apple e o time que construí na Apple.
Líderes outcome-driven tratam cada elemento da organização como uma "funcionalidade do produto" que existe para ajudar a organização a ter sucesso.
Essas "funcionalidades organizacionais" incluem coisas como processos, métricas, rituais, relatórios, estrutura, dados, ferramentas, habilidades e comportamentos.
Parafraseando Dharmesh Shah, co-fundador e CTO da HubSpot:
Toda empresa desenvolve dois produtos: um é o produto que elas desenvolvem para seus clientes e o outro é um produto que elas desenvolvem para seu time.
A cultura e o modelo operacional da sua empresa formam juntos o produto que você desenvolve para o seu time. Eles existem para ajudar as ótimas pessoas que você tem a fazer coisas incríveis para seus clientes e sua empresa.
Neste artigo, discutiremos o que significa tratar sua organização como um produto e os mindsets e comportamentos que impedem as pessoas de fazer isso.
Líderes outcome-driven desenham intencionalmente como a organização opera
Todas as empresas têm uma cultura e um modelo operacional, sejam intencionalmente pensados ou não.
A diferença é que os líderes outcome-driven desenham intencionalmente cada elemento de suas empresas. Eles evoluem deliberadamente sua cultura e formas de trabalhar para facilitar a obtenção de outcomes.
Como explica o blogueiro de tecnologia John Gruber, Steve Jobs foi muito intencional sobre como a Apple deveria funcionar:
O mesmo pensamento, cuidado e atenção meticulosa aos detalhes que Steve Jobs trouxe para questões como "Como um computador deve funcionar?", "Como um telefone deve funcionar?", "Como devemos comprar música e aplicativos na era digital?" ele também trouxe para a questão mais importante: "Como deve funcionar uma empresa que cria tais coisas?"
Líderes outcome-driven regularmente fazem perguntas como:
Quais comportamentos queremos reforçar e encorajar nas pessoas? Quais queremos inibir?
Quais fatores estão dificultando nosso desempenho? Quais estão ajudando?
Como podemos criar um ambiente onde os times possam ter o melhor desempenho?
Vamos nos aprofundar em uma pergunta ainda mais poderosa.
Isso vai ajudar a alcançar nossos outcomes?
Ben Hunt-Davis é um coach de liderança que ganhou uma medalha de ouro como parte do time britânico de remo nas Olimpíadas de 2000. Seu princípio principal é: "Isso vai fazer o barco ir mais rápido?" Ou seja, isso ajudará a organização a ter sucesso?
Líderes outcome-driven fazem algo semelhante. Eles questionam tudo o que suas organizações fazem—ou não fazem— com a pergunta: "Isso vai ajudar a alcançar nossos outcomes?"
Se algo ajuda a alcançar os outcomes desejados, eles continuam fazendo. Se não, eles tentam algo diferente.
Essa filosofia se aplica no que eles trabalham (funcionalidades de produtos ou projetos) e também em como eles trabalham (seu modelo operacional ou maneira de trabalhar).
Cada elemento do modelo operacional ou da cultura da sua empresa existe por uma razão: ajudar a organização a alcançar sua missão e os outcomes desejados.
Por exemplo, muitas empresas perceberam que precisavam mudar suas abordagens para incentivos e metas se quisessem adotar times empoderados.
O coach de engenharia de software Doc Norton fez uma brincadeira para descrever como as empresas soam quando não fazem isso:
Só pedimos que você seja inovador sem cometer erros, enquanto trabalha em equipe para atingir metas individuais de desempenho.
Líderes outcome-driven estão dispostos a mudar ou abandonar qualquer coisa que não esteja ajudando suas organizações a fazer a diferença. Eles também estão prontos para desaprender antigos mindsets e comportamentos.
Essa forma de pensar não é nova. Há cem anos, Henry Ford pregava algo semelhante:
Esteja pronto para rever qualquer sistema, descartar qualquer método, abandonar qualquer teoria, se o sucesso do trabalho exigir.
Essa flexibilidade permitiu que Ford alcançasse um milagre de produtividade com sua linha de montagem de movimento contínuo, diminuindo em quase 90% as horas de trabalho necessárias para produzir um carro Modelo T.
Líderes outcome-driven trabalham em duas frentes ao mesmo tempo
Há uma outra forma de entender o que está acontecendo: líderes outcome-driven trabalham em duas frentes ao mesmo tempo. Eles trabalham para alcançar os outcomes desejados, mas também para otimizar a organização para alcançar outcomes (meu obrigado a Marty Cagan pela expressão).
Um velho ditado nos ajuda a entender o que isso significa: "Se eu tivesse cinco minutos para cortar madeira, eu gastaria os primeiros dois minutos e meio afiando meu machado”.
Seguindo essa analogia, líderes outcome-driven equilibram o trabalho em duas frentes:
Alcançar outcomes ("Cortar madeira"): Trabalhar para atingir seus outcomes pretendidos usando práticas e fluxos de trabalho atuais.
Otimizar a organização para alcançar outcomes ("Afiar o machado"): Trabalhar para melhorar como a organização opera, evoluindo sua cultura e maneiras de trabalhar para facilitar o atingimento dos outcomes.
Steve Jobs se referia a essas duas frentes quando falou sobre "fazer um produto" (cortar madeira) versus "criar um time que possa continuamente fazer produtos" (afiar o machado).
Empresas de sucesso usam OKR para afiar o machado
Você pode estar se perguntando como OKR se encaixa nessa discussão.
Tenho ajudado empresas ao redor do mundo a adotar OKR e outcomes desde 2014. Depois de treinar e mentorar milhares de pessoas, notei um padrão claro que separa as empresas que têm sucesso com OKR das demais:
Empresas de sucesso usam OKR para afiar o machado, evoluindo sua cultura e formas de trabalhar.
Mas a grande maioria das pessoas adapta OKR à sua maneira antiga de trabalhar. Como aquela famosa definição de insanidade, eles continuam fazendo a mesma coisa repetidamente enquanto esperam resultados diferentes.
OKR pode ser uma ferramenta poderosa para ajudar a construir uma cultura outcome-driven e otimizar sua organização. Mas também pode ajudar a manter as coisas exatamente como estão. Tudo depende de como você o usa.
Algumas pessoas se referem às duas frentes acima como operar o negócio vs. mudar o negócio. Mas a maioria das empresas faz mudanças limitadas na forma como trabalham, e o resultado é que 70% das transformações falham, de acordo com pesquisas.
Tenho encontrado repetidamente um exemplo irônico dessa falta de afiar o machado enquanto trabalho com clientes.
Muitas empresas investiram em "transformação” e é claro que todas diziam usar OKR. Mas em vez de usar esses investimentos como uma forma de se tornarem mais outcome-driven, a maioria das organizações foca em datas em vez de outcomes.
Frequentemente, a meta é simplesmente "migrar para a nuvem até o final do ano". Não importa se essa migração fez a diferença ou não.
Muitas iniciativas de transformação assumem implicitamente que todos os projetos terão sucesso. Em vez de fazer discovery e testar ideias rapidamente, elas se baseiam em projetos que não entregam valor por 12-18 meses e raramente medem os outcomes desses projetos.
Olhe mais de perto e você verá que essas empresas estão usando técnicas “Ágeis” para entregar projetos waterfall—não há nada que se assemelhe a entrega contínua de valor.
Toda essa situação é um caso clássico do mindset sabe-tudo, onde acreditamos que temos todas as respostas. A premissa oculta é: “Não precisamos medir ou experimentar, sabemos o que estamos fazendo”. Não há muita transformação aí.
Esse problema não se limita a corporações tradicionais. Muitas empresas mais novas fazem coisas semelhantes, mesmo as que são “powered by tecnologia”.
Temos que lembrar que a maioria das organizações não está pronta para outcomes. Se você quer se beneficiar de ser outcome-driven, você deve mudar radicalmente sua organização—ajustes superficiais não serão suficientes.
Você pode evoluir passo a passo, mas tem que dar esses passos.
Por que as pessoas deixam de afiar o machado?
Transformação é difícil. Às vezes, os líderes resistem à mudança ou não sabem o que fazer.
Mas também existem outras razões pelas quais as pessoas deixam de afiar o machado:
Operando no piloto automático: As pessoas costumam trabalhar mecanicamente em vez de serem intencionais sobre o que querem alcançar e como trabalham.
Mindset fixo: Muitas pessoas veem sua organização como algo fixo que não pode ser mudado, em vez de um produto que pode ser alterado e melhorado.
Fobia de retrabalho: Às vezes, as pessoas resistem em afiar o machado porque odeiam retrabalho, mesmo quando sabem que vai ser bom para elas.
Percepção de falta de autonomia: Algumas pessoas se sentem como se fossem apenas uma engrenagem na máquina e acreditam que não há nada que possam fazer.
Vamos discutir cada um desses pontos com mais detalhes.
As pessoas costumam operar no piloto automático
A maioria das pessoas não é intencional sobre como trabalha. Todos nós temos uma tendência a operar no piloto automático, fazendo o que sempre fizemos.
Quando fazemos isso, trabalhamos mecanicamente e sem questionar o que queremos alcançar ou como trabalhamos.
As pessoas costumam ignorar uma pergunta básica: Qual problema estamos tentando resolver?
Essa pergunta é tão clichê que está listada em livros sobre como parecer inteligente no trabalho. E ainda assim, quando operamos no piloto automático deixamos de fazer essa pergunta fundamental.
Uma consequência da falta dessa pergunta é que as pessoas muitas vezes não sabem por que um processo ou métrica existe.
Como o fundador da Amazon, Jeff Bezos, explica:
É muito comum, especialmente em grandes empresas, que elas estejam gerenciando métricas que não entendem realmente. Elas realmente não sabem por que existem, e o mundo pode ter mudado um pouco e as métricas não são mais tão relevantes quanto eram quando alguém as inventou 10 anos atrás.
Bezos novamente:
Você tem que estar alerta para isso. Você tem que saber: “Ok, eu realmente não me importo com essa métrica. Eu me preocupo com a felicidade do cliente e só vale a pena investir energia, acompanhar e melhorar essa métrica se realmente afetar a felicidade do cliente”.
É extremamente fácil perder de vista a diferença que queremos fazer. Trabalhamos mecanicamente sem questionar por que uma métrica ou processo existe.
A solução é sempre começar definindo claramente o outcome que queremos alcançar, por que ele é importante e as restrições para alcançá-lo.
As métricas são “funcionalidades organizacionais” críticas, mas as pessoas não as discutem o suficiente na hora de definir OKRs. Eles podem discutir os números, mas não discutem as métricas.
Há muita discussão do tipo “no mês passado esta métrica era 10, agora é 12”, mas falta perguntar “esta é a métrica certa?”.
Muitas vezes há pouca discussão sobre processos ou práticas atuais, mesmo quando claramente há um problema. Vamos ver um exemplo que pode parecer muito tático, mas tem um impacto enorme: reuniões.
E se você gerir as reuniões como um produto?
Pesquisas mostram que os executivos passam em média quase 23 horas por semana em reuniões, e mesmo assim todo mundo as odeia.
Como o expert em produtos John Cutler explica, se as reuniões fossem um produto, ninguém compraria ou renovaria. Elas não têm product-market fit—as pessoas aparecem, não recebem valor e reclamam. Duvido que você possa encontrar um produto com notas de satisfação do cliente piores.
E se você intencionalmente repensar suas reuniões, fazendo experimentos?
Empresas como Dropbox e Asana descobriram que cada colaborador poderia economizar de 3 a 11 horas por mês cancelando ou repensando reuniões de baixo valor.
Empresas como Amazon e Stripe são conhecidas por terem reinventado suas reuniões. Todas as reuniões começam com os participantes lendo um documento, o que é mais rápido e permite um debate mais profundo do que assistir alguém apresentar slides.
E se você levar essa ideia além das reuniões e repensar intencionalmente outras "funcionalidades" da sua organização?
A maioria das pessoas vê organizações e times como algo fixo
Líderes outcome-driven enxergam as organizações como produtos que podem modificar, testar e melhorar, mas isso é radicalmente diferente da forma como a maioria das pessoas pensa.
A psicóloga Carol Dweck popularizou a ideia de que algumas pessoas têm um mindset fixo e enxergam suas habilidades como traços fixos que não podem mudar. A pesquisa de Dweck é sobre indivíduos, mas notei que as pessoas costumam aplicar um mindset semelhante quando pensam sobre o trabalho.
Pessoas com um "mindset fixo para trabalho" enxergam a maneira como sua organização opera como algo que está essencialmente escrito em pedra e não pode ser mudado. Muitos colaboradores individuais enxergam seus times de forma semelhante.
Por exemplo, quando converso com líderes de empresas grandes ou médias, muitos reclamam que não podem usar OKR ou focar em outcomes porque têm muitas dependências entre os times.
A solução tradicional é "gerir” essas dependências—gastar muito tempo coordenando o trabalho entre várias equipes.
Essa abordagem não apenas deixa tudo muito mais lento, mas também faz com que seja muito difícil que os times possam se apropriar de um outcome, já que tudo depende de todos os outros.
E, no entanto, executivos com um mindset fixo para trabalho acreditam que não há nada que possam fazer.
As pessoas da Amazon tinham um mindset diferente. Diante do mesmo problema, eles perceberam que não havia nenhuma lei dizendo que todo projeto tinha que envolver tantos times diferentes.
Por volta de 2002, Jeff Bezos e os outros executivos se cansaram de gerir dependências e decidiram remover dependências.
A Amazon investiu para reduzir drasticamente as dependências, fazendo mudanças profundas na forma como desenvolvia software e adotando uma nova arquitetura de software, adotando APIs1.
A empresa também reduziu dependências mudando a topologia do time—a forma como as organizações dividem o trabalho entre diferentes equipes, incluindo sua estrutura e escopo.
O objetivo era criar o que a Amazon chama de times separáveis, times que precisam de pouquíssima coordenação com os demais e que têm um alto grau de autonomia e senso de propriedade sobre seu trabalho.
O mindset fixo para trabalho afeta executivos e colaboradores individuais igualmente
O mindset fixo para trabalho não discrimina. Ele afeta executivos e colaboradores individuais igualmente.
Claro, há um limite sobre o que os times e os colaboradores individuais podem mudar em uma organização. Mas as pessoas com um mindset fixo enxergam a maneira como seus times operam como algo escrito em pedra, mesmo coisas que poderiam mudar.
A tabela abaixo traz alguns exemplos comuns de coisas que as pessoas falam quando enxergam a organização como uma coisa fixa.
Pare um minuto e se pergunte: você já disse ou pensou coisas parecidas?
Algumas pessoas odeiam retrabalho, mesmo quando é bom para elas
Às vezes, as pessoas resistem em afiar seus machados porque odeiam fazer mudanças em algo em que já trabalharam—mesmo quando sabem que será bom para elas.
Pessoas que trabalharam em projetos por muito tempo tendem a desenvolver retrabalhofobia.
Retrabalhofobia (substantivo):
Medo ou ódio irracional de fazer mudanças em algo em que você já trabalhou.
A crença equivocada de que todo retrabalho é ruim e deve ser evitado a todo custo.
Pessoas com retrabalhofobia costumam dizer coisas como: "Não podemos mudar nossos OKRs agora, já gastamos tanto tempo neles!”
Elas também dizem: "Trabalhamos duro para definir nossa estratégia, é frustrante aprender que está errada. Se mudarmos agora, as pessoas vão pensar que fizemos um trabalho ruim”.
Outra fala comum é: "Não podemos definir OKRs trimestrais porque não vamos entregar nada nos próximos nove meses. Mas não podemos mudar nossos projetos agora porque gastamos muito tempo planejando-os”. (Esse problema é tão comum que decidi mencioná-lo duas vezes neste artigo.)
No mundo dos projetos, o retrabalho é sempre ruim porque significa que alguém cometeu um erro e você tem que fazer o trabalho novamente. Podem até te responsabilizar por algo que não foi sua culpa.
O mesmo acontece na manufatura, onde o retrabalho é o processo de correção de itens defeituosos. A expectativa é que projetos e itens manufaturados sejam resolvidos em uma tacada só: você faz as coisas uma vez e pronto.
Mas produtos nunca estão "prontos", eles continuam evoluindo. Trabalhar em uma nova versão é natural no mundo dos produtos.
As pessoas na Netflix não dizem: "Gastamos tanto tempo na funcionalidade de recomendação, não podemos mudá-la agora!" Eles continuam evoluindo a funcionalidade.
O mindset outcome-driven envolve entender que é impossível saber tudo com antecedência, mas você pode aprender. O retrabalho nem sempre implica em um erro, talvez você tenha aprendido algo novo.
Como o guru do desenvolvimento de software Kent Beck diz:
A única maneira de tudo acontecer de acordo com o plano é se você não aprender nada.
Existe retrabalho bom e retrabalho ruim
Líderes outcome-driven entendem a diferença entre retrabalho bom e retrabalho ruim.
O retrabalho bom é intencional e envolve aprendizado e melhoria contínuos. Por exemplo, o retrabalho bom acontece quando aprendemos coisas novas, aprimoramos nossos produtos, nos adaptamos às mudanças ou usamos o desenvolvimento iterativo para melhorar e refinar nosso produto a cada ciclo.
O retrabalho ruim é não intencional e vem de práticas inadequadas. Por exemplo, o retrabalho ruim acontece quando não nos alinhamos em torno de um outcome claro, mudamos as prioridades com frequência, temos que corrigir os mesmos problemas repetidamente ou não fazemos discovery e acabamos construindo algo que ninguém quer.
Não estou dizendo que você deve passar todo o seu tempo reescrevendo seus OKRs ou redefinindo sua estratégia. Você precisa equilibrar a otimização de sua organização com o atingimento dos outcomes.
Se você passa todo o tempo "afiando seu machado" sem "cortar nenhuma lenha", está fazendo errado.
Você tem mais autonomia do que imagina
Às vezes, as pessoas sentem que são apenas uma engrenagem na máquina e não há nada que possam fazer. Eu também já me senti assim.
Mas quero encerrar este artigo lembrando que você tem mais autonomia do que imagina, mesmo como um colaborador individual em uma empresa enorme.
Me lembro de uma excelente história contada por Teresa Torres. É mais ou menos assim:
A única maneira de tudo acontecer de acordo com o plano é se você não aprender nada.
Um time reclamou para Teresa que não poderia fazer discovery de produto de maneira adequada porque a empresa não permitia que os times falassem diretamente com os clientes. Eles estavam proibidos de entrevistar os clientes finais e acreditavam que não havia nada que pudessem fazer.
Teresa perguntou ao time: existe alguma regra proibindo entrevistar os clientes de seus concorrentes?
Você pode aprender muito conversando com pessoas que não são seus clientes. Você pode aprender sobre suas necessidades, desejos e pontos problemáticos com o produto que estão usando atualmente.
Idealmente, você também deve entrevistar seus próprios clientes, mas não deixe que isso o impeça de aprender.
Você tem mais autonomia do que imagina.
Perguntas para discussão em grupo
Em breve, voltaremos com outro post. Enquanto isso, a melhor maneira de colocar este artigo em prática é discutir as ideias principais com seus colegas ou amigos.
Aqui estão algumas perguntas para ajudar:
Como seria seu trabalho se você tratasse sua organização ou time como um produto?
Questione algumas coisas que você faz - ou não faz - perguntando: "Isso ajudará a alcançar nossos outcomes desejados?" Depois de fazer a pergunta, o que você mudaria?
Você está gastando tempo suficiente afiando seu machado?
Você está usando OKR para evoluir como trabalha ou para manter as coisas como estão?
Quais produtos organizacionais estão com data de validade vencida?
De que maneiras você pode estar operando involuntariamente com um mindset fixo para trabalho?
Onde você está resistindo ao bom retrabalho? Você está sendo vítima de retrabalhofobia?
Fique à vontade para comentar abaixo ou me enviar um e-mail.
Para os mais dedicados, segue abaixo uma lista de leitura com os links mencionados neste artigo (em inglês).
Abraço,
Felipe
Lista de leitura e links (em inglês):
Big Think: Walter Isaacson on Steve Jobs’ Favorite Product: The Apple Team.
Lenny’s Podcast: Zigging vs. zagging: How HubSpot built a $30B company | Dharmesh Shah (co-founder/CTO).
Dharmesh Shah: Culture is a product you build for your people.
John Gruber: Resigned.
Ben Hunt-Davis: Will it make the boat go faster?
Benedict Evans: Office, messaging and verbs.
Mckinsey: 70% of transformations fail.
Lex Fridman Podcast: Jeff Bezos: Amazon and Blue Origin
Harvard Business Review: Meeting Overload Is a Fixable Problem.
Se você gostou deste artigo, compartilhe com amigos. Se alguém te encaminhou este post, assine minha newsletter para receber mais conteúdo direto no seu email.
Uma API é um conjunto de rotinas, protocolos e ferramentas para construir aplicações de software e definir como os componentes de software devem interagir.