Operando com eficiência em escala

Por Brian Armstrong, CEO e cofundador

À medida que as empresas crescem, normalmente desaceleram e tornam-se menos eficientes. É preciso mais dinheiro, mais pessoas e mais tempo para fazer qualquer coisa. Os ventos contrários à coordenação aumentam, surgem vetocracias, a tolerância ao risco diminui e as equipas concentram-se internamente em vez de permanecerem focadas nos seus clientes.

Embora esta trajetória seja natural, não é inevitável. Todas as grandes empresas, da Amazon à Meta e à Tesla, encontraram formas de manter a sua energia fundadora em conjunto com controlos apropriados, mesmo que tenham crescido para serem muito maiores do que a Coinbase é hoje. As grandes empresas mantêm a sua mentalidade insurgente, por medo de se tornarem complacentes e irrelevantes com o tempo.

É por isso que estamos nos concentrando em gerar mais eficiência na Coinbase. Após 18 meses de crescimento anual de aproximadamente 200% dos funcionários, muitas de nossas ferramentas internas e princípios de organização começaram a se desgastar ou quebrar. Por isso, temos nos aprofundado para identificar o conjunto de mudanças que precisamos fazer para nos ajudar a ter sucesso nesta nova escala.

O primeiro passo foi desacelerar significativamente o nosso crescimento e tomar a difícil decisão de reduzir o tamanho da nossa equipe atual, que anunciou no mês passado. No futuro, continuaremos procurando maneiras de tornar a Coinbase mais eficiente e de voltar à mentalidade e abordagem que nos tornaram bem-sucedidos. Acredito que estes passos nos levarão adiante.

Usamos DRIs (indivíduos diretamente responsáveis) para nos ajudar a executar com mais rapidez. Os DRIs equilibram as informações da equipe e tomam decisões claras em tempo hábil.

Mas agora que somos uma empresa maior, com muitos produtos em vez de um, precisamos ajustar a forma como tomamos decisões – empurrando a maior parte da tomada de decisões para baixo na organização, removendo gargalos e capacitando nossos líderes de produtos.

Os DRIs muitas vezes têm a tentação de empurrar a tomada de decisões para o topo da cadeia quando não têm certeza ou não querem correr riscos. Às vezes, eles têm medo de serem demitidos se a decisão não der certo. É por isso que, sempre que possível, estamos cada vez mais focados na identificação de DRIs “single-threaded”. Single-threaded é um jargão tecnológico que significa simplesmente focado exclusivamente em uma única área. O DRI de thread único é a pessoa mais experiente cujo só trabalho é administrar um determinado produto ou iniciativa, normalmente será um líder de gerenciamento de produto ou engenharia. Eles não podem ser DRI de thread único se forem DRI de múltiplas áreas.

Isso pode significar que nem todas as decisões são perfeitas. Mas não há problema se conseguirmos dimensionar o nosso impacto e capacitar especialistas no assunto que estão mais próximos dos produtos e dos nossos clientes.

Cada um dos nossos produtos tem concorrentes bem financiados que são empresas dedicadas. Acreditamos que a maneira certa de competir é incentivar nossos líderes de produto a também administrarem seus produtos de forma mais autônoma. As empresas devem alcançar um crescimento rentável num horizonte de tempo razoável. Com o tempo, seremos capazes de dar aos líderes de produtos visibilidade direta dos seus lucros e perdas, para que possam mover os seus produtos em direção a margens positivas e tomar melhores decisões sobre onde investir, enquanto a nível executivo continuaremos a olhar para o desempenho consolidado.

Embora os líderes de produto possam operar de forma independente, muitas vezes existem elementos comuns entre os produtos. Compartilhamos serviços sobre como os clientes integram, gerenciam suas contas, armazenam criptografia, adicionam métodos de pagamento, negociam criptografia e muito mais. Feitos de maneira errada, os serviços compartilhados podem desacelerar e frustrar as equipes de produto. Mas quando funcionam bem, podem criar sinergias incríveis entre produtos e uma integração mais profunda dos produtos.

As equipes de produto não devem ser obrigadas a usar um serviço compartilhado incompleto. Mas quando um serviço partilhado estiver maduro, todos os produtos poderão ser obrigados a utilizá-lo. Descobrimos que muitas vezes ajuda iniciar um serviço compartilhado com um produto âncora em mente. Quando fica claro que estamos duplicando esforços ou criando uma experiência de usuário inconsistente em nossos produtos, os serviços precisam se transformar em serviços claramente dissociados que qualquer produto pode aproveitar.

Equipes pequenas são mais eficientes. É por isso que é importante definir um tamanho máximo para as equipes, para que elas não cresçam muito e fiquem lentas.

Estamos começando a implantar um novo conceito que chamamos de “pods” para criar mais estrutura em torno do tamanho apropriado de uma equipe. Dentro de cada produto, definiremos grupos de <10 pessoas trabalhando em um recurso ou área específica. Se um grupo crescer para mais de 10 pessoas, será hora de dividi-lo em dois e atribuir a cada um um objetivo ou foco mais específico. Os pods também precisam ter um foco e uma métrica norte que se relacione com as métricas gerais da empresa.

Dentro das empresas em crescimento, existe o perigo de que as equipes de produto e engenharia comecem a enviar excelentes apresentações de slides em vez de excelentes produtos. Pode ser tentador “administrar” e sentir que uma reunião correu bem com um belo deck mostrado aos superiores. Mas nossos clientes nunca veem as apresentações de slides que criamos. Eles só veem o produto.

Portanto, estamos experimentando proibir apresentações de slides em análises de produtos e engenharia. Em vez de uma apresentação de slides, você pode mostrar:

• Um painel com suas métricas – espero que sua equipe esteja analisando isso pelo menos uma vez por semana
• Maquetes Figma
• Mas o mais importante… mostre o produto em si e use-o ao vivo!

Não há problema em incluir uma agenda de uma página para capturar itens de ação ou vincular a qualquer pré-leitura, como documentos de design técnico. Mas o melhor uso do tempo em análises de produtos e engenharia é compartilhar sua tela e percorrer o produto real no celular ou na web. Pode ser a versão de produção ou uma versão de teste. O importante é colocar o produto em prática, ver o que o cliente está vendo (ou prestes a ver) e torná-lo melhor.

Ao fazermos isso, devemos evitar gastar muito tempo falando sobre o que está indo bem nas reuniões. Podemos compartilhar o que está indo bem na pré-leitura e reservar um momento para comemorar, mas a maior parte do tempo nas reuniões deve ser focado no que não está indo bem, para que possamos melhorar o produto.

É difícil exagerar neste ponto. Dentro das empresas, há muitas coisas que parecem funcionar, mas que, em última análise, não melhoram a experiência do cliente – desde ciclos de mercado e imprensa negativa até esforços políticos, política/drama interno, títulos e remuneração. Temos equipes focadas nessas áreas, para que a grande maioria da empresa (80%+) possa permanecer focada em conversar com os clientes e construir produtos melhores.

As empresas maiores também são prejudicadas por reuniões intermináveis ​​sobre priorização e solicitações de recursos. Precisamos mudar para um modelo onde todas as equipes de produtos e engenharia (não apenas serviços compartilhados) publiquem APIs para que outras equipes possam se beneficiar do que estão construindo sem nunca precisar agendar uma reunião. Em outras palavras, eles precisam produzir seus serviços e permitir que outras equipes os utilizem de forma self-service.

Isso exige que adotemos um catálogo interno de API onde qualquer engenheiro da Coinbase possa navegar para encontrar um serviço apropriado. Sem isso, é difícil para qualquer engenheiro saber se existe uma API, levando à duplicação de trabalho. Todos os serviços precisam ser arquitetados usando “estradas pavimentadas”, o que significa bibliotecas e linguagens consistentes para autenticação, registro, instrumentação, etc. Muitas dessas APIs também serão apresentadas na Coinbase Cloud para clientes externos, tornando-as ainda mais robustas.

Em última análise, muito disso se resume a manter a mentalidade do fundador dentro da empresa e agir como proprietários. A maioria das empresas começa por ser anti-establishment, procurando corrigir alguns erros no mundo. Mas à medida que crescem e têm mais sucesso, começam a se tornar o novo estabelecimento. Eles ficam complacentes, sentindo que eles ganharame a burocracia se instala.

Na Coinbase, um dos nossos valores é a inovação repetível, o que significa que queremos sempre ultrapassar as fronteiras. Utilizamos um modelo de alocação de recursos 70/20/10, onde investimos 70% dos nossos recursos no nosso negócio principal e 20% em esforços estratégicos. Também garantimos que 10% dos nossos recursos vão sempre para novas apostas ambiciosas. E sempre tentamos fazer produtos que sejam mais confiáveis ​​e fáceis de usar, para que possamos trazer um bilhão de pessoas para a criptografia. Esta é a melhor forma de cumprir a nossa missão de aumentar a liberdade económica no mundo.

O sucesso da Coinbase sempre esteve enraizado na capacidade de operar de forma eficiente com uma mentalidade de startup. Agora, à medida que nos adaptamos à nossa nova escala, precisamos de voltar às coisas que nos tornaram bem sucedidos – para impulsionar mais eficiência e livrar-nos da complacência que pode infiltrar-se numa empresa maior. Precisamos capacitar nossos líderes para tomar decisões e nossas equipes para entregar excelentes produtos aos clientes. Não será fácil e precisaremos continuar nos ajustando. Mas chegámos até aqui e estou confiante de que, se tomarmos decisões inteligentes agora, será apenas o começo.

As empresas abordam este problema do declínio da eficiência de diferentes maneiras, para melhor se adequarem à sua situação. Alinhamos a implementação dessas mudanças e ferramentas depois de fazer pesquisas significativas sobre como outras empresas navegaram nisso. Aqui estão alguns ótimos livros e recursos que ajudaram a me educar sobre esse assunto:

• Amplie: Frank Slootman tem um ótimo no blog sobre isso que virou livro. A mensagem principal é que quando alguém disser que entrarei em contato com você na próxima semana, diga que tal amanhã. Quando alguém disser que levará seis meses, pergunte como faríamos isso em seis semanas ou seis dias, se fosse necessário.
• Vire o navio: A mensagem central deste livro é que, em vez de perguntar ao seu gerente o que você deve fazer, diga a ele o que você pretender fazer, e eles editarão seu pensamento, se necessário. Você ainda precisa informar, mas é sua responsabilidade decidir o melhor caminho.
• Mentalidade dos Fundadores: A mensagem central é manter uma mentalidade insurgente, com tendência para a ação, missão ousada, defesa do cliente e muito mais. Tente o interrogar para mais detalhes.
• Ventos contrários de coordenação: Organizações em escala precisam ser fracamente acopladas e estreitamente alinhadas. Em outras palavras, alinhe-se com uma missão, valores e métricas de alto nível e, em seguida, capacite os líderes a trilharem seu próprio caminho com tomadas de decisão mais localizadas.