Depois de ter ajudado a fundar o PayPal, fundou em 2002 o LinkedIn, que o transformou em multimilionário. Foi um dos investidores iniciais do Facebook e é atualmente sócio da Greylock, uma empresa de capital de risco. Escreveu dois livros, “The Start-Up of You” (com Ben Casnocha) e “The Alliance: Managing Talent in the Networked Age” (com Casnocha e Chris Yeh).
No outono de 2015, Reid Hoffman começou a lecionar uma cadeira de informática, designada “Technology-Enabled Blitzscaling”, na Universidade de Stanford, onde estudou, com John Lilly (seu sócio na Greylock e anterior CEO da Mozilla), Allen Blue (cofundador do LinkedIn) e Yeh (cofundador da Allied Talent). Nesta entrevista que deu a Tim Sullivan da “Harvard Business Review Press”, Hoffman fala sobre os desafios, riscos e recompensas da “blitzscaling”.
Comecemos pelo princípio. O que é “blitzscaling”?
“Blitzscaling” é o que se faz quando é necessário crescer mesmo muito depressa. É a ciência e a arte de, rapidamente, construir uma empresa para servir um mercado vasto e geralmente global, com o objetivo de se tornar o primeiro em escala.
Trata-se de empreendedorismo de alto impacto. Este género de empresas cria sempre muitos dos empregos e indústrias do futuro. Consideremos a Amazon que, essencialmente, inventou o comércio eletrónico. Hoje em dia, tem mais de 150 mil empregados e criou uma infinidade de empregos entre os seus vendedores e parceiros. O Google revolucionou a forma como encontramos a informação — tem mais de 60 mil empregados e criou muitos mais empregos nos seus parceiros AdWords e AdSense.
Porquê essa atenção ao crescimento rápido?
Vivemos numa era em que tudo funciona em rede. E não falo apenas da Internet. A globalização é uma forma de trabalho em rede. Há redes de transporte, comércio, pagamento e fluxos de informação por todo o mundo. Num ambiente assim, temos de nos mover mais rapidamente, porque a concorrência em qualquer parte do globo pode ultrapassar-nos.
O software tem uma afinidade natural com a “blitzscaling”, porque os custos marginais de servir qualquer dimensão de mercado são praticamente zero. Quando mais osoftware se torna parte integrante de todos os sectores, mais depressa as coisas avançam. Juntemos-lhe a aprendizagem automática dentro da Inteligência Artificial, e tudo se torna mais rápido ainda. É por isso que veremos cada vez mais “blitzscaling”. Não um pouco mais, mas muito mais.
Como é que se decidiram pelo termo “blitzscaling”? Pode sugerir algumas associações interessantes.
Tenho algumas hesitações óbvias em relação à associação com o termo “blitzkrieg” da Segunda Guerra. Contudo, os paralelismos intelectuais são tão próximos que o termo é bastante informativo. Antes de a “blitzkrieg” ter emergido como uma tática militar, os exércitos não avançavam para além das suas linhas de abastecimento, o que lhes limitava a velocidade. A teoria da “blitzkrieg” era que, transportando apenas o estritamente necessário, o avanço podia ser muito rápido, vencendo assim o inimigo pela surpresa. Ao chegar a meio caminho do destino, era preciso decidir se se devia voltar para trás ou prosseguir, abandonando as linhas. Uma vez tomada a decisão de avançar, ou se ganhava em grande, ou se perdia em grande.
A “blitzscaling” adota uma perspetiva similar. Se uma startup determina que precisa de se mover muito rapidamente, correrá muito mais riscos que uma empresa que percorra o processo normal e racional de crescimento.
O processo de “blitzscaling” começa normalmente entre a escala “tribo” e a “aldeia”.
Este género de velocidade é necessária por razões ofensivas e defensivas. Ofensivamente, a empresa pode exigir uma certa escala para ter valor. O LinkedIn não se tornou valioso enquanto não se lhe juntaram milhões de pessoas. Plataformas de vendas como o eBay têm de possuir em escala, tanto vendedores, como compradores. Os negócios de pagamentos, como o PayPal, e os de comércio eletrónico, como a Amazon, têm margens pequenas, pelo que exigem grandes volumes. Ao nível defensivo, é preferível escalar mais depressa do que a concorrência, porque o primeiro a chegar junto dos consumidores terá mais probabilidade de ficar com eles, e as vantagens da escala podem conduzi-lo a uma posição “winner-takes-most”. E, num ambiente global, nem sempre temos consciência de quem é, na verdade, o nosso concorrente.
A ideia de escala tem várias dimensões?
Existem três tipos de escala. As pessoas, naturalmente, concentram-se em dois deles: aumento dos rendimentos e aumento da base de clientes. E, claro, se isso não for bem feito, o resto não importa. Mas poucas empresas podem ser bem-sucedidas nessas duas frentes se não ajustarem igualmente a dimensão da organização. O tamanho de uma organização e a sua capacidade para executar, determinam se esta conseguirá captar clientes e receitas.
Vemos o crescimento como uma série de etapas, baseadas em ordens de magnitude: uma empresa à escala familiar pode contar os seus empregados pelos dedos das mãos; uma “tribo” conta-os em dezenas, uma “aldeia” em centenas, uma “cidade” em milhares. Uma “nação” tem mais de 10 mil empregados. Trata-se de estimativas, não de orientações exatas; uma empresa permanece como “família” até cerca de 15 empregados, como “tribo” até perto dos 150, e assim sucessivamente.
O que é blitzcaling?
“Blitzscaling” é o que se faz quando é necessário crescer mesmo muito depressa. É a ciência e a arte de, rapidamente, construir uma empresa para servir um mercado vasto e geralmente global, com o objetivo de se tornar o primeiro em escala.
A cada um dos níveis, a forma como se gerem as diferentes funções — financiamento da empresa, contratação de pessoal, marketing do produto, etc., — muda significativamente. Quando se aplica a “blitzscaling” não há regras para isto; usa-se, antes, a heurística — ou seja, orientações gerais que ajudam a tomar decisões e a aprender durante o processo.
A escala organizacional tem mais a ver com o caráter da empresa do que com uma contagem exata de empregados — as coisas não mudam drasticamente ao atingir os 150 empregados certos. E não temos, necessariamente, de ampliar cada elemento da empresa ao mesmo tempo ou ritmo. É mais provável que nos concentremos primeiro no serviço de clientes e vendas que noutras funções. Mesmo assim, teremos de aplicar a “blitzscaling” a outras partes da organização. Então, durante todo o processo, temos mesmo de pensar a empresa como um todo: como vamos distribuir os talentos e fazê-los crescer? Como vamos manter-nos fiéis à nossa cultura? Como vamos comunicar? Como vai mudar o nosso panorama competitivo?
Quando é que uma startup começa a aplicar a “blitzscaling”?
Na etapa “família”, a empresa está normalmente a angariar dinheiro e a tentar perceber exatamente qual é o seu produto ou serviço. Muito provavelmente, ainda não foi lançado um produto.
À escala “tribo”, começa-se a ter uma verdadeira empresa. É muito raro — não inédito, mas raro — que a “blitzscaling” comece nesta fase, a não ser que se tenha um produto de sucesso imediato, como o PayPal ou o Instagram. O mais típico é que se tenha lançado uma versão do produto ou serviço, e se tenha identificado o mercado alvo. Mas ainda não há certezas de que a startup possa, de facto, crescer massivamente. Há sempre algum grau de risco. Poderemos decidir não crescer nesta etapa, por não termos a certeza de possuir um produto que satisfaça uma forte procura de mercado. Ou podemos decidir avançar apesar disso, por sabermos que é absolutamente necessário, pelas razões ofensivas e defensivas de que falámos.
Assim, o processo de “blitzscaling” começa normalmente entre a escala “tribo” e a “aldeia”. Nessa altura, já teremos limado a capacidade de o produto satisfazer um bom mercado, temos alguns dados e sabemos como é o panorama competitivo.
É neste momento que a lógica da “blitzscaling” se torna muito clara. Uma vez que comecemos a provar — a nós próprios e aos outros — que existe uma categoria interessante e uma grande oportunidade de mercado, atraímos todo o género de concorrência. Por um lado, outras startups podem estar a lançar a sua própria versão do seu produto ou serviço e a tentar conquistar dimensão de mercado antes de nós. Por outro, as marcas estabelecidas estarão a tentar perceber como tirar partido dos seus próprios recursos para se apropriarem de parte ou mesmo da totalidade do nosso espaço.
Uma startup tem duas vantagens em tomar a iniciativa aplicando a “blitzscaling”: concentração e velocidade. As marcas estabelecidas tendem a não ser tão rápidas ou concentradas. E as startups concorrentes, provavelmente, ainda não dispõem do mesmo impulso (embora possam ser igualmente rápidas e concentradas).
O exemplo canónico é a Groupon, que conseguiu chegar a este estádio intermédio e foi abalada pela competição intensa, tanto de outras startups, como das empresas estabelecidas. Não conseguiu crescer depressa e, ao mesmo tempo, construir um produto durável, falhando assim em concretizar uma oportunidade potencialmente transformadora de todo um setor.
Quais são os problemas organizacionais com que se depara ao aplicar a “blitzscaling”?
A “blitzscaling” é sempre ineficiente do ponto de vista da gestão — e esbanja rapidamente uma grande quantidade de capital. Mas, para crescer, tem de se estar disposto a aceitar essas ineficiências. É exatamente o contrário da otimização realizada pelas grandes organizações.
Por exemplo, ao contratar, poderemos precisar do máximo de pessoas o mais depressa possível — e, ao mesmo tempo, de contratar empregados de qualidade e de manter a cultura da empresa. Como é que isso se faz? Diferentes empresas usam diferentes táticas. Como parte da “blitzscaling” da Uber, os gestores perguntavam a um engenheiro recém-contratado, “Quem foram os três melhores engenheiros com que trabalhou no seu emprego anterior?” E depois mandavam cartas a esses três engenheiros, com propostas de emprego. Não faziam entrevistas. Não confirmavam referências. Precisavam de fazer crescer rapidamente a sua engenharia, e essa foi uma técnica fundamental.
Enfrentámos essa questão no PayPal. No princípio de 2000, o volume das transações de pagamentos crescia a uma taxa composta de 2% a 5% ao dia. Esse género de crescimento colocou a empresa em grandes dificuldades relativamente ao serviço de clientes. Apesar de só ser possível encontrar as nossas informações de contacto na lista telefónica de Palo Alto, clientes zangados conseguiam obter o nosso número central e marcavam extensões ao acaso. Era possível, vinte e quatro horas por dia, atender qualquer telefone e falar sempre com um cliente zangado. Então, desligámos todos os telefones e usámos os telemóveis. Mas isso não era solução. Sabíamos que precisávamos de construir um serviço ao cliente capaz, e depressa.
Mas é muito difícil fazer isso em Silicon Valley, pelo que o fizemos em Omaha. Isto foi durante o primeiro boom das dot-com, e convencemos o governador do Nebraska de que ele queria fazer parte da revolução da Internet. Ele e o presidente da Câmara realizaram conferências de imprensa para informar que o PayPal ia abrir um serviço de apoio ao cliente, o que desencadeou uma série de candidaturas. Durante quatro fins de semana seguidos, 20% do pessoal da empresa viajava de avião para ir fazer entrevistas. As pessoas apareciam com os seus currículos e nós metíamo-las em salas e fazíamos entrevistas de grupo. Seis semanas depois, tínhamos 100 empregados no serviço ao cliente a responder a e-mails.
Hoje em dia, é normal as empresas de Internet oferecerem apoio ao consumidor apenas via Web e e-mail, mas nós tivemos de resolver o problema muito rapidamente. Não havia nenhum manual para nos dizer o que fazer. Ainda não há.
Se não existem regras, como é que definiram a vossa abordagem?
Por vezes, a liberdade em relação às regras normais é o que nos dá vantagem competitiva. Por exemplo, se tivéssemos percebido quanto podiam ser perniciosos os estornos e as fraudes com cartão de crédito logo nos primeiros tempos do PayPal, talvez não tivéssemos acreditado que um serviço destes poderia ter sucesso. Não percebemos o impacto que os prejuízos podiam ter.
Todo o pessoal dos bancos conhecia as regras — a primeira coisa a fazer era proteger-se contra as fraudes. Isso impediu que tentassem qualquer coisa de remotamente parecida com o PayPal. A nossa ignorância permitiu-nos construir algo rapidamente mas, depois, claro que tivemos de ir fazendo correções, quando já estávamos em terreno minado.
A maioria dos críticos pensou que estávamos a perder tanto dinheiro em 2000 por causa dos bónus de aquisição de clientes, mas não foi isso. O custo médio de aquisição de consumidores neste sector através da publicidade era de cerca de 40 dólares. Assim, quando dávamos 10 dólares aos clientes que recomendassem um amigo e mais 10 dólares ao novo cliente, estávamos a cortar os custos pela metade.
Porquê depender da heurística e não das regras? Porque estamos em busca de uma vantagem que nos distinga dos nossos concorrentes, que seguem a sabedoria convencional. Não quer dizer que não existam regras. Por exemplo, “Não deixes ninguém malbaratar o teu dinheiro” é uma regra. Mas não dá vantagem competitiva a ninguém.
Parece que a opção pela heurística pode conduzir a resultados organizacionais radicalmente diferentes.
Sim. Um dos diferenciadores entre o Google e a Microsoft, duas companhias que aplicam a “blitzscaling”, é que o Google queria permanecer “flat”, enquanto a Microsoft construiu muita hierarquia.
Para ser gestor no Google era preciso ter oito pessoas que lhe reportassem, mas não havia limite superior. O gestor tinha 10, 15, 20 ou mesmo 100 pessoas que lhe reportavam diretamente, para minimizar a gestão intermédia. Provavelmente, a nível de gestão, teria sido mais eficiente que não fossem mais de oito pessoas. Contudo, o Google escolheu uma organização pouco hierarquizada, que sacrificou esse género de eficiência para obter uma concentração extrema no desenvolvimento tecnológico. A Microsoft, por seu lado, seguiu uma abordagem mais clássica e hierárquica.
Isso recorda-me a decisão do Google de contratar apenas pessoas com médias muito altas de universidades de elite. Como heurístico, existem obviamente danos colaterais — há muitas pessoas inteligentes que não tem permissão para contratar —, mas faz sentido se o seu objetivo for contratar rapidamente um grande número de generalistas.
Isso criou muita frustração. “Não posso contratar o meu amigo que não tem essa qualificação, mas sei que ele é mesmo bom.” E a companhia diz, “Pois, desculpa lá. É assim que operamos enquanto aplicamos a “blitzscaling”. Precisamos de uma heurística simples, para nos podermos concentrar no que realmente importa”. Outro benefício da decisão do Google de contratar apenas nas universidades de elite foi isso ajudar a criar e a manter uma cultura coerente à medida que a empresa crescia.
Porque é a cultura tão importante para a “blitzscaling”?
Porque temos uma organização a crescer muito depressa, precisamos que as pessoas se responsabilizem umas pelas outras numa base horizontal, colega a colega, e não apenas verticalmente e de cima para baixo.
Que outros procedimentos são importantes quando se passa, digamos, de “aldeia” a “cidade”?
A especialização a todos os níveis torna-se mais importante. Temos de compreender como gerir um departamento de engenharia em grande escala, por exemplo, e como aplicar uma quantidade significativa de capital ao marketing. Precisamos dedashboards, análises e métricas para essas funções, tanto quanto para nos ajudar a compreender os clientes e o mercado.
Também é preciso ter uma muito maior fiabilidade; por vezes, a ineficiência que aceitámos enquanto estávamos sob a “blitzscaling”, ao longo do estágio de “aldeia”, não é sustentável a uma escala maior. Temos de contratar pessoas que saibam como garantir que o nosso site nunca está em baixo. E temos de ser mais cuidadosos ao lançar o nosso produto de engenharia. Em resultado, temos menos adaptabilidade. Por exemplo, é bem conhecido que o Facebook passou de um mantra de “Avança depressa e parte tudo” para “Avança depressa com uma infraestrutura estável”.
A maioria das empresas de Silicon Valley torna-se globais quando passam de “aldeia” para “cidade”, mas algumas são globais desde o primeiro dia.
Também passamos de uma organização una para uma ramificada, permitindo que a empresa se concentre em mais de uma coisa ao mesmo tempo. Quando estamos numa “tribo”, toda a gente está sintonizada com uma prioridade. Numa “aldeia”, é provável que comecemos a focar-nos naquilo que vamos ampliar. Também começamos a pensar em experiências laterais — por exemplo, construir ferramentas de programação ou fazer experiências ao nível do marketing ou de outra aquisição paga. E começaremos, provavelmente, a adicionar novas funções, como desenvolvimento corporativo para considerar aquisições.
Tudo isto é urdido com mente no objetivo macro de ter sucesso enquanto empresa mas, quando passamos de “aldeia” para “cidade”, as funções começam verdadeiramente a diferenciar-se.
As empresas à escala da “cidade” têm normalmente mais do que um produto principal. Poderão ter uma fonte de receitas central, como o AdWords ou o Microsoft Office do Google, mas alguns produtos diferentes. Construíram uma arquitetura que determina como os produtos se relacionam uns com os outros. E cada um dos produtos pode também ter várias ramificações.
A maioria das empresas de Silicon Valley torna-se globais quando passam de “aldeia” para “cidade”, mas algumas são globais desde o primeiro dia. No LinkedIn, abrimos com 15 países na nossa lista de opções. No segundo dia, estávamos a receber e-mails de pessoas de países que não constavam da lista. Para mim, foi uma lição de geografia interessante, porque eu não sabia que as Ilhas Faroé eram um país até receber uma queixa. Então, fui ler um pouco da sua história e disse, “OK, acrescenta-se à lista”. Isto é verdade.
Diferentes partes da empresa usam diferentes manuais de estratégia?
Sim. Por exemplo, o Google desenvolveu dois sistemas operativos móveis ao mesmo tempo: o Android e o Chrome. Quando o Google adquiriu Andy Rubin e a sua startup, Android Inc., Andy ficou como empreendedor dentro da empresa, concentrado nessa experiência e reportando a Larry Page. Da perspetiva dos recursos corporativos do Google, foi uma questão de perguntar a Andy de que precisava para fazer o projeto funcionar.
Andy pretendia que a Android se mantivesse coesa e focada. Então, por exemplo, apenas os crachás de empregado da Android davam acesso às suas instalações; os outros empregados do Google não podiam entrar. A equipa Android não corre o seusoftware através do processo padrão de revisão de código do Google. Andy também queria ter a possibilidade de fazer diferentes contratos com as operadoras móveis — o que quer que fosse necessário para arrancar com o projeto — sem aprovações adicionais.
Quando se está em processo de “blitzscaling”, há uma série de coisas que inevitavelmente correm mal, e não é possível trabalhar em todas ao mesmo tempo.
Numa iniciativa completamente diferente, o Chrome foi desenvolvido em C++ (o Android foi em Java) e focado em laptops e browsers, mais que em telefones. O Google podia ter lidado com as coisas de outra maneira, misturando Android e Chrome num mesmo projeto, atacando coerentemente a oportunidade de sistema operativo móvel. Mas escolheu a ramificação, contratando a melhor pessoa para o projeto, dando-lhe as ferramentas para realizar a tarefa e deixando-o gerir um projeto completamente separado, de acordo com o seu manual próprio.
Uma das perguntas que o ouvi fazer, foi, “O que posso ignorar?” Talvez o reverso seja, “Em cada um dos estádios, que problemas prioritários tenho de resolver”?
Uma das metáforas que uso para as startups é: você atira-se de um penhasco e tem de montar o seu avião enquanto cai. Se não resolver o problema certo no momento certo, é o fim. A mortalidade faz-nos ver muito claramente quais são as prioridades.
Quando se está em processo de “blitzscaling”, há uma série de coisas que inevitavelmente correm mal, e não é possível trabalhar em todas ao mesmo tempo. É preciso triar. Resolvem-se as coisas que levam os investidores a dar-nos mais dinheiro. A sustentação que o capital nos concede significa que dispomos de mais tempo no ar para fazer as coisas bem. Não é provável que o avião levante voo com o primeiro impulso de capital, nem mesmo com o segundo.
Um princípio geral de gestão é que, se tivermos problemas de dinâmica de equipa, temos de os resolver imediatamente. Mas, durante a “blitzscaling”, esses desafios são constantes. E o avanço é tão rápido que os problemas de hoje não serão os de amanhã. O funcionamento é remendado, feio, colado com fita-cola. Então, talvez ignoremos a disfunção da equipa por algum tempo.
Por exemplo, os seus engenheiros podem estar insatisfeitos. Nós pensamos, “Deveremos construir ferramentas de programação para os ajudar a serem mais produtivos? Devemos atribuir essa tarefa a um grupo de engenheiros?” Mas sabemos que a dimensão da equipa continuará a mudar radicalmente; quaisquer ferramentas que criarmos hoje, ficarão obsoletas. Então, não tentamos resolver o problema imediatamente, apesar de sabermos que ignorá-lo vai criar insatisfação organizacional e que as pessoas ficarão frustradas. Em circunstâncias em que não exista a “blitzscaling” esse género de questões podem ser prioritárias, mas agora, por vezes, tem de se deixar arder.
Lembre-se que, mesmo que resolva um problema, este provavelmente só ficará resolvido por um curto período de tempo.
Poderá aliviar a insatisfação explicando às pessoas porque está a tomar determinadas decisões?
Sim, mas apenas até certo ponto. O que mantém as coisas controladas é a perceção de que avança a alta velocidade porque está a criar algo de verdadeiramente grande, e que fará parte de algo de sucesso.
Quase todas as organizações sujeitas a “blitzscaling” que analisei de perto têm muita insatisfação interna. Falta de clareza quanto a papéis, responsabilidades e áreas de atuação. “Oh, caramba, esta empresa é um caos.” O que mantém estas empresas unidas — seja o PayPal, o Google, o eBay, o Facebook, o LinkedIn ou o Twitter — é a sensação de entusiasmo acerca do que está a acontecer e a visão de um futuro grandioso. Como faço parte de uma equipa que está a produzir algo de grande, eu trabalho, apesar da minha insatisfação individual. Claro que gostava que as áreas estivessem mais bem definidas, gostava de ser mais eficiente, gostava que a organização avançasse mais suavemente. Mas estou disposto a deixar passar, porque o sacrifício vale a pena.
Slideshare do seu curso em Stanford:
[slideshare id=53092937&doc=183copy-150923041642-lva1-app6891]
__
Fonte: https://www.dinheirovivo.pt/entrevistas/reid-hoffman-comecemos-pelo-principio-o-que-e-blitzscaling/