Modelos de inovação: Google nos anos 2000

Uma das empresas de tecnologia de maior impacto nas primeiras décadas do século 21 nasceu sem muita preocupação com mecanismos de gestão ou de ditar de maneira prescritiva como seus profissionais trabalhariam. O Google começou em 1998 com o intuito inicial de fazer uma máquina de buscas. Conforme foi crescendo, decidiu simplesmente sair contratando as melhores pessoas do mercado. 

Essas contratações foram feitas com tal velocidade que, a certa altura, os gestores de tecnologia tinham times tão numerosos sob seu comando que nem conseguiam apontar quem eram seus subordinados.

Como não poderia ser diferente, com tanta gente boa ali, uma infinidade de ideias brotavam o tempo todo, especialmente porque existia uma política oficial da empresa de permitir que as pessoas dedicassem 20 por cento do seu tempo pago, no horário regular de trabalho, a qualquer projeto em que quisessem se envolver. Surgiram desse momento mais solto sementes de projetos interessantes, como o Google News. 

Porém, chegou uma hora em que havia uma média de apenas três ou quatro pessoas nesses pequenos projetos “autorais”, que não necessariamente contribuíam para o modelo de negócios, e eles passaram a ser consolidados ou eliminados.

O Google entrou então em uma fase de implementação de uma  hierarquia um pouco mais top-down de gestão, com mais gestores intermediários definindo projetos e passando diretrizes e prioridades do topo do comando para baixo. Manteve-se, contudo, o espírito Google de oferecer autonomia para que as ideias circulassem entre equipes, com a ajuda de ferramentas de engenharia comuns a todas.

Uma infinidade de ideias brotavam o tempo todo, especialmente porque existia uma política oficial da empresa de permitir que as pessoas dedicassem 20 por cento do seu tempo pago, no horário regular de trabalho, a qualquer projeto em que quisessem se envolver.

Independência baseada em ferramentas básicas

Obviamente que, quando se trabalha em ideias de cenários não previstos no planejamento de uma empresa já mais estruturada, essas ideias têm que entrar em produção alguma hora e, para isso, precisam ser aprovadas por pessoas mais acima da hierarquia da empresa. Ou seja, mesmo que alguma coisa bacana surja com alguém mais júnior da equipe, de um jeito ou de outro essa ideia terá que ser submetida ao julgamento técnico de um ou mais gestores acima para vir ou não a ser integrada a algum produto, sistema ou serviço.

Naquele período mais inicial do Google, nos primeiros anos do século, porém, os engenheiros tinham bastante autonomia para validar uma ideia e botá-la em produção sem precisar de aprovação formal por níveis superiores.

Isso somente era possível pois já vigoravam processos e ferramentas de engenharia que proviam a segurança de que as mudanças não impactariam negativamente os clientes. Por exemplo, se alguém tivesse uma ideia de como deixar o sistema mais barato, com um custo menor para o Google e sem mudar a qualidade de resposta do motor de busca, isso podia ser executado de forma independente. Agora, se a ideia diminuísse o custo relativamente, mas impactasse a qualidade para o usuário, era preciso discutir os tradeoffs com as lideranças responsáveis. 

A maneira como esses profissionais de engenharia operavam em casos de alguma mudança que impactasse diretamente os clientes, como por exemplo uma mudança de API, geralmente envolvia criar um MVP (minimum viable product ou produto viável mínimo) para colocar em produção apenas para uma pequena porcentagem dos usuários, e, com isso, validar a ideia. 

Havia também bastante experimentação validando com testes A/B  — em que uma funcionalidade nova era testada com uma parcela dos usuários, enquanto a outra parcela continuava recebendo a funcionalidade antiga. Conseguia-se assim descobrir se as pessoas tinham gostado ou não daquilo.

Essas situações de uma companhia tão fora da curva como o Google, especialmente naquele final de século 20 e início de 21, não necessariamente devem ser vistas como a fórmula ideal para outras empresas, mas sim como uma fotografia do tipo de estrutura organizacional que permitiu à companhia dar a luz a serviços tão inovadores. Um dos pilares para isso ocorrer baseava-se no fato de que o Google soube atrair desde a sua fundação uma equipe de engenheiros experientes e profissionalmente maduros. Havia então confiança no topo da empresa de que ninguém perderia tempo fazendo experimentos com projetos banais ou inúteis.

Existiam poucos processos de gestão também porque havia muito controle de como os times eram organizados e como as ferramentas de engenharia eram construídas e compartilhadas. Cada time tinha responsabilidade por uma parte do código e não havia como mexer nele sem obter aprovação do criador original. O processo de aprovação estava integrado à plataforma, o que impedia que alguém fizesse mudanças e as colocasse no ar sem que elas tivessem sido testadas e aprovadas.

Outra diferença é que boa parte dos projetos do Google naquela época eram produtos para o consumidor final. Quando se trata de um produto business-to-business (B2B), o processo para colocar qualquer nova feature em produção precisa ser muito mais rigoroso, pois envolve necessariamente mudanças em APIs que requerem desenvolvimento por parte dos clientes para que sejam adotadas.

O exemplo do Google é uma das modalidades possíveis para dar espaço à experimentação e à pesquisa, que podem ser integrados, como na gigante de buscas, ou separado, como em muitas outras empresas.