Times pequenos ajudam a inovar. Mas o tipo de projeto define quanto o time precisa de dedicação, autoridade e distância do negócio principal.

Em 2002, executivos da Amazon defendiam que a empresa precisava de maior comunicação entre as áreas. Jeff Bezos reagiu na direção contrária. Para ele, o excesso de comunicação era sinal de uma organização que dependia demais de coordenação. Pouco depois, a Amazon passou a se organizar em torno dos famosos “times de duas pizzas”: grupos autônomos pequenos o suficiente para serem alimentados com duas pizzas durante uma noite de trabalho.¹

A ideia entrou para o folclore da gestão e há boas razões para isso.

J. Richard Hackman, psicólogo de Harvard que dedicou a carreira ao estudo de equipes, defendia times com menos de dez integrantes. O argumento é quase aritmético. Um grupo de cinco pessoas precisa administrar dez relações entre seus membros. Um grupo de dez, 45. Um grupo de quinze, 105.²

Décadas depois, uma análise de mais de 65 milhões de artigos científicos, patentes e projetos de software encontrou outro efeito: times menores tendem a produzir trabalhos que rompem com o conhecimento estabelecido, enquanto times maiores são particularmente eficientes para desenvolver e consolidar ideias existentes.³

Mas a história da Amazon tem um segundo capítulo.

Em 2004, quando decidiu entrar no mercado de leitores digitais, a empresa não entregou o desafio simplesmente a mais um time pequeno dentro da estrutura existente. Criou a Lab126, uma subsidiária na Califórnia, a mais de mil quilômetros da sede em Seattle. Três anos depois, o Kindle chegou ao mercado.⁴

Os dois episódios não se contradizem. Eles revelam que o tamanho do time é apenas uma das escolhas envolvidas no desenho de uma equipe de inovação.

Para alguns projetos, um pequeno grupo dentro da estrutura existente é suficiente. Para outros, as pessoas precisam trabalhar em tempo integral, o líder precisa de autoridade real e o projeto precisa ser protegido das prioridades, métricas e processos do negócio principal.

A questão, portanto, não se resume a quantas pessoas colocar no time. É preciso decidir também quão próximo esse time deve permanecer do core business.

O dilema da proteção

Boa parte dos erros na organização de projetos de inovação segue dois padrões opostos.

O primeiro é proteger de menos. O projeto é entregue a um squad formado por pessoas das áreas, cada integrante dedica algumas horas por semana e o coordenador acompanha o cronograma sem controlar recursos ou prioridades. Enquanto a iniciativa compete apenas com outros projetos de inovação, o arranjo pode funcionar. O problema surge quando passa a disputar atenção e orçamento com o negócio atual. Nesse momento, a operação tende a vencer.

Foi o que ocorreu com a Digital Equipment Corporation, a DEC. Entre 1983 e 1995, a empresa tentou quatro vezes entrar no mercado de computadores pessoais. Em todas, conduziu os projetos dentro da organização principal, utilizando processos e estruturas de custos desenvolvidos para o negócio de minicomputadores. Nenhuma das tentativas prosperou.⁵

O erro oposto é proteger demais.

A empresa cria uma estrutura independente e corta suas ligações com o negócio principal. Ganha liberdade, mas pode perder justamente as vantagens que uma grande empresa possui sobre uma startup: marca, canais, clientes, capacidade produtiva, poder de compra e conhecimento regulatório.

O desafio da liderança é encontrar a distância adequada.

Antes de montar o time, diagnostique o projeto

Quatro perguntas ajudam a definir essa distância:

Quanto o projeto ainda precisa aprender?
Quanto mais hipóteses relevantes sobre cliente, tecnologia ou modelo de negócio ainda precisarem ser testadas, maior a necessidade de espaço para experimentar.

O projeto cabe nos processos atuais?
Algumas inovações podem utilizar as rotinas existentes de desenvolvimento, compras, fabricação e vendas. Outras exigem formas diferentes de trabalhar e tomar decisões.

O modelo de negócios do projeto é compatível com o do core?
Margens menores, clientes menos prioritários, ameaça a produtos existentes ou investimentos aparentemente pouco atraentes podem fazer com que o conflito deixe de ser operacional e se torne uma disputa de prioridade.

De quais ativos do core o projeto depende para ganhar escala?
Quanto maior a dependência de marca, canais, clientes, capacidade produtiva ou poder de compra, maior o custo de isolar completamente a iniciativa.

Cinco desenhos possíveis de times de inovação

As respostas determinam o desenho do time. Não existe uma estrutura universal para inovar. Existem configurações mais ou menos adequadas à natureza do projeto.

MATRIZ DE PERFIS DE TIMES DE INOVAÇÃO

1. Time funcional

No extremo mais próximo da operação, formalmente quase não existe um time de projeto. Cada área executa sua parte, as pessoas dedicam uma pequena parcela do tempo à iniciativa e os gestores funcionais continuam definindo prioridades, metas e avaliação. É um desenho eficiente para melhorias incrementais, adaptações e produtos que utilizam os processos existentes.

2. Time peso-leve

É o formato comum a muitos squads corporativos. Cada área indica um representante e um gerente de projeto coordena as atividades. Os integrantes continuam subordinados às suas áreas e dedicam apenas parte do tempo ao projeto. O gerente facilita a comunicação e acompanha prazos, mas normalmente não tem autoridade para realocar recursos ou redefinir prioridades. Esse arranjo funciona bem para novas versões, extensões e iniciativas próximas do negócio existente. O problema está em esperar um resultado radical de um time que continua operando part-time segundo a lógica do core. Em um estudo com 35 iniciativas de inovação radical, nenhuma das nove conduzidas por times multifuncionais dentro da hierarquia atingiu seus objetivos.⁶

3. Time peso-pesado

Quando o projeto exige novas formas de trabalhar, o desenho precisa mudar. No time peso-pesado, um pequeno núcleo multifuncional trabalha em tempo integral durante um período definido. À frente dele está um gestor sênior com autoridade para alocar recursos, definir prioridades e avaliar os integrantes. As áreas funcionais continuam contribuindo, mas o projeto deixa de depender exclusivamente delas. O time permanece dentro da empresa, porém ganha condições para desenvolver processos próprios.

4. Unidade ambidestra

Projetos mais radicais exigem maior separação da estrutura existente. Numa unidade ambidestra, a iniciativa ganha equipe dedicada, estrutura, métricas e processos próprios. Seu líder deixa de atuar apenas como gerente de projeto e passa a se comportar como o gestor geral de um novo negócio. A separação, porém, não é completa. A integração acontece na alta gestão. O líder da nova unidade responde a um executivo capaz de arbitrar as tensões entre o negócio novo e o existente e garantir acesso aos ativos do core. A unidade fica separada na operação, mas integrada no topo.

5. Organização autônoma

Há situações em que nem isso basta. Quando o novo negócio conflita diretamente com clientes, margens, canais ou modelo econômico da empresa e não há recursos do core a serem alavancados, pode ser necessário criar uma organização autônoma. As pessoas trabalham em tempo integral, o gestor controla recursos, processos e prioridades, e novos profissionais podem ser contratados de fora. Foi o caminho seguido pela própria Amazon com a Lab126. O contraste histórico mais claro, porém, aparece entre IBM e DEC. Em 1981, para entrar no mercado de computadores pessoais, a IBM criou uma unidade independente em Boca Raton, distante da sede e livre para desenvolver uma estrutura de custos diferente daquela do negócio de mainframes. A IBM conseguiu entrar com sucesso num mercado em que a DEC fracassaria repetidamente.⁹

Mas autonomia não significa abandono. Estruturas independentes também fracassam quando não recebem patrocínio efetivo da alta gestão.¹⁰ O projeto pode estar distante do core. Não pode estar distante da liderança.

O desenho também precisa mudar

Esses cinco desenhos não representam uma sequência de maturidade. Um time peso-pesado não é necessariamente superior a um time funcional, assim como uma organização autônoma não é uma forma mais avançada de inovação.

Cada estrutura responde a um problema diferente. Há ainda uma complicação adicional: o desenho adequado no início pode não ser o desenho adequado mais adiante.

Na fase de descoberta, uma iniciativa pode precisar de proteção, velocidade e liberdade para experimentar. Quando encontra um modelo viável e começa a escalar, passa a depender mais intensamente dos clientes, canais, fábricas, sistemas e capacidades do negócio principal. Nesse momento, a autonomia que protegeu o projeto pode se tornar uma barreira.

O movimento inverso também acontece. Um projeto criado dentro da operação pode descobrir ao longo do caminho que suas métricas, seus clientes ou sua lógica econômica são muito diferentes das do core. Mantê-lo dentro da estrutura pode então comprometer seu desenvolvimento. Por isso, o desenho do time não deveria ser decidido uma única vez. Ele precisa ser revisto nos principais marcos do projeto, assim como se revisam orçamento, metas e investimentos.

Quem está próximo do projeto costuma subestimar a força do negócio existente. Quem está próximo da operação tende a subestimar o que o projeto tem de realmente novo. É papel da liderança arbitrar essa tensão.

Bezos popularizou uma ótima regra para o tamanho dos times. Mas duas pizzas não bastam.

O erro mais comum é dar ao projeto certo a configuração de time errado.