Hoje é o Dia de Goof Off no Trabalho

Quando o senhor é contratado no Google, só precisa fazer o trabalho para o qual foi contratado 80% do tempo. Nos outros 20% do tempo, o senhor pode trabalhar em no que o senhor quiser – desde que o senhor faça o Google avançar de alguma forma. Pelo menos, essa é a teoria.

A política de 20% de tempo do Google já é bem conhecida nos círculos de engenharia de software. O que é não tão bem conhecido é que esse conceito remonta a 1948 na 3M.

Em 1974, o cientista Art Fry, da 3M, teve uma invenção inteligente. Ele achava que se pudesse aplicar um adesivo (inventado pelo colega Spencer Silver vários anos antes) no verso de um pedaço de papel, poderia criar o marcador de página perfeito, que ficaria guardado no hinário de sua igreja. Ele o chamou de Post-It Note. Fry criou o produto que hoje é icônico (ele fala ao Smithsonian sobre isso aqui) durante seu “tempo de 15%”, um programa da 3M que permite que os funcionários usem uma parte de seu tempo remunerado para correr atrás do arco-íris e ter suas próprias ideias. Isso pode parecer um benefício para os funcionários. Mas, na verdade, chegou a hora produziu muitos dos produtos mais vendidos da empresa e estabeleceu um precedente para algumas das principais empresas de tecnologia da atualidade, como a Google e a Hewlett-Packard.

Não há muita documentação sobre essa versão da HP; quando encontro menções a ela, é sempre mencionada como uma “convenção”, não como uma política explícita. Robert X. Cringely fornece mais detalhes:

O Google não inventou isso: Foi a HP. E a maneira como o processo foi instituído na HP era bastante formal, pois o tempo de 10% era depois do almoço, às sextas-feiras. Imagine o que deve ter sido as tardes de sexta-feira em Palo Alto, com todos os engenheiros trabalhando em alguma ideia maluca. E a outra parte do sistema era que esses engenheiros tinham acesso ao que eles chamavam de “lojas de laboratório” – tudo o que fosse necessário para fazer o trabalho, fosse um microscópio, um magnetron ou um barril de acetona, poderia ser retirado sem questionamentos nas tardes de sexta-feira dos depósitos da HP. Isso possibilitou uma enxurrada de inovações que produziu alguns dos melhores produtos da HP, incluindo essas impressoras.

Talvez a HP tenha inventado isso, já que ela existe desde 1939. Dave Raggett, por exemplo, aparentemente teve um papel importante na invenção do HTML em seus 10% de tempo na HP.

Embora o conceito seja anterior ao Google, eles fizeram mais do que qualquer outra pessoa para validá-lo como uma estratégia real e popularizá-lo nos círculos de tecnologia. Curiosamente, não consigo encontrar qualquer menção ao benefício de 20% do tempo listado no página atual de empregos do Googlemas é parte integrante da cultura do Google. E por um bom motivo: projetos notáveis de 20% incluem GMail, Google News, Google Talk e AdSense. De acordo com a ex-funcionária Marissa Meyer, cerca de metade dos dos produtos do Google se originaram desses 20%.

Na Hewlett-Packard, na 3M e no Google, “muitos” de seus melhores e mais populares produtos vêm do da pequena porção de tempo que eles concedem aos funcionários para trabalhar no no que quisessem. O que isso significa? Será que todos nós deveríamos nos divertir mais no trabalho e experimentar nossas próprias ideias? É isso que o livro A Doutrina dos 20% explora.

Intimamente relacionada aos 20% de tempo está a Dia do Hack. Os Hack Days reservam um período específico de 24 horas da programação, incentivando grandes grupos a se reunirem para trabalhar de forma colaborativa (ou em uma competição amigável) durante esse período. Chad Dickerson instituiu um dos primeiros no Yahoo em 2005.

Na sexta-feira anterior, eu havia organizado o primeiro Hack Day interno do Yahoo! com a ajuda de um grupo de pessoas da empresa. A designação “hack” para o dia foi uma homenagem à cultura hacker, mas também um aceno ao fato de que estávamos tentando consertar um sistema que não funcionava muito bem. A ideia era muito simples: todos os engenheiros de nossa divisão tiveram um dia de folga para construir o que quisessem. As únicas regras eram construir algo em 24 horas e mostrá-lo no final do período. A estrutura básica do evento em si foi inspirada no que tínhamos visto em pequenas startups, mas ninguém havia tentado realizar um evento desse tipo em grande escala em uma empresa estabelecida.

O primeiro Yahoo! Hack Day foi claramente um sucesso. Em uma empresa que estava lutando para inovar, cerca de setenta protótipos surgiram do nada em um único período de 24 horas e foram apresentados em um ambiente alegremente entusiasmado, onde as pessoas gritavam e aplaudiam. Os desenvolvedores, que não dormiam e usavam camisetas, ficavam até tarde no trabalho em uma sexta-feira à noite para mostrar os protótipos que haviam criado, sem nenhum outro motivo além de quererem criar algo. Em seu livro seminal sobre software de código aberto, The Cathedral and the Bazaar, Eric Raymond escreveu: “Todo bom trabalho de software começa coçando a coceira pessoal de um desenvolvedor.” É evidente que havia muita coceira nos desenvolvedores do Yahoo! mas foi necessário o Hack Day para que eles pudessem fazer uma coceira catártica coletiva.

A versão da Atlassian, um trimestralmente ShipIt Daytambém data de 2005. É interessante notar que eles também tentaram emular a política de 20% de tempo do Google com o resultados mistos.

De longe, o maior problema foi agendar tempo para 20% do trabalho. Como disse uma pessoa, “conseguir 20% de tempo é incrivelmente difícil em meio a toda a pressão para entregar novos recursos e correções de bugs”. A Atlassian tem lançamentos frequentes de produtos, então é muito difícil para as equipes programarem “tempo de inatividade”. As equipes pequenas, em particular, achavam difícil ter tempo longe do desenvolvimento do produto principal. Isso não se devia ao fato de os líderes de equipe serem severos. Muitas vezes, isso se devia ao fato de os desenvolvedores não quererem aumentar a carga de trabalho de seus colegas enquanto faziam 20% do trabalho. Eles gostam dos produtos que estão desenvolvendo e têm orgulho de seus esforços. No entanto, não querem ser vistos como se estivessem desfrutando de um privilégio enquanto outros carregam a carga de trabalho.

Acho que há um histórico suficiente de sucesso documentado que vale a pena fazer lobby por algo como Hack Days ou 20% de tempo onde quer que o senhor trabalhe. Mas antes de fazer isso, considere se o senhor e sua empresa estão prontos:

1. Há folga suficiente no cronograma?

   De forma realista, o senhor não conseguirá atingir 20% de tempo, ou mesmo um mísero hack day, se não houver absolutamente nenhuma folga no cronograma. Se todos ao seu redor estiverem trabalhando a todo vapor, o máximo que puderem, o tempo todo, isso… provavelmente não é saudável. É claro que todo mundo tem momentos de crise de vez em quando, mas se o seu ambiente de trabalho parece constante o senhor precisará lidar com isso primeiro. Para munição, tente O livro Slack, de Tom Demarco.

2. O tempo de sonhar acordado é importante?

   Se alguém for criticado por não “parecer ocupado”, a cultura de trabalho de sua empresa pode não ser capaz de apoiar uma iniciativa como essa. É preciso que haja uma adesão no nível dos chefes que o tempo gasto pensando e sonhando acordado é uma parte válida do trabalho. Sonhar acordado não é a antítese do trabalho; pelo contrário, a solução criativa de problemas requer ele.

3. O fracasso é aceito?

   Quando é dada a liberdade de “trabalhar no que o senhor quiser”, os poderes constituídos têm de realmente falar sério para que o trabalho seja importante. Na maioria das vezes, isso significa dar aos funcionários a liberdade irrestrita de fracassar miseravelmente em seus projetos de skunkworks, sem repercussão ou julgamento. Sem fracasso, e lotes do material, não pode haver inovação ou experimentação verdadeira. O valor de aprender (rapidamente!) com os fracassos e seguir em frente é enorme.

4. A experimentação individual é respeitada?

   Se não houver um respeito saudável pela experimentação individual em comparação com a busca incessante pela Próxima Coisa na lista de tarefas do projeto coletivo, essas iniciativas estão fadadas ao fracasso. Os senhores precisam realmente acreditar, como empresa e como colegas, que inovações e aprimoramentos cruciais podem vir do todos na empresa a qualquer momento, de baixo para cima – eles não são entregues de cima para baixo em intervalos de lançamento programados no todo-poderoso Plano Diretor.

Ter algum reconhecimento oficial de que o tempo gasto trabalhando em qualquer o senhor que o senhor acha que vai melhorar as coisas por aqui não é apenas tolerado, mas incentivado, e pode ajudar muito a fazer com que o trabalho pareça muito menos com trabalho.