Chegou um dia importante para a Red Hat, a comunidade russa de código aberto e todos os envolvidos – em russo foi lançada . Ele descreve de forma detalhada e vívida como, na Red Hat, damos espaço às melhores ideias e às pessoas mais talentosas, além de como não se perder no caos e unir milhões de pessoas ao redor do mundo.
Além disso, este livro é sobre a vida e a prática. Contém muitos conselhos para aqueles que querem aprender a construir uma empresa baseada no modelo de organização aberta e liderá-la de forma eficaz. Abaixo estão alguns dos princípios mais importantes apresentados no livro que você pode começar a considerar agora mesmo.
A história da contratação de Jim na empresa é notável. Ela demonstra que no mundo do código aberto não há fanfarras, mas sim uma nova abordagem à liderança:
"Depois de conversar com o recrutador, manifestei interesse em uma entrevista, e ele perguntou se eu me importaria de voar no domingo para a sede da Red Hat na cidade de Raleigh, Carolina do Norte. Pensei que domingo era um dia estranho para uma reunião. Mas como eu já estava planejando voar para Nova York na segunda-feira, na verdade estava a caminho, e aceitei. Peguei um avião de Atlanta e aterricei no aeroporto de Raleigh-Durham. De lá, peguei um táxi que me deixou em frente ao edifício da Red Hat no campus da Universidade da Carolina do Norte. Era domingo, eram 9:30 da manhã, e não havia ninguém por perto. As luzes estavam apagadas e, ao checar, descobri que as portas estavam trancadas. A princípio, pensei que estavam me brincando. Ao me virar para retornar ao táxi, notei que ele já tinha ido embora. Logo começou a chover, e eu não tinha guarda-chuva.
Assim que eu estava prestes a ir a algum lugar para pegar um táxi, Matthew Szulik, depois presidente do conselho e CEO da Red Hat, apareceu com seu carro. "Olá," ele disse. "Quer tomar um café?" Achei um início incomum para uma entrevista, mas eu sabia que definitivamente precisava de um café. No final das contas, pensei que seria mais fácil pegar um táxi para o aeroporto depois.
No domingo de manhã, na Carolina do Norte, é bastante tranquilo. Levou-nos algum tempo apenas para encontrar um café que abria antes do meio-dia. O café não era o melhor da cidade e não estava exatamente limpo, mas funcionava e podíamos tomar um café fresco. Sentamos à mesa e começamos a conversar.
Cerca de trinta minutos depois, percebi que estava gostando de como tudo estava indo; a entrevista não era tradicional, mas a conversa em si acabou sendo bastante interessante. Em vez de discutir as nuances da estratégia corporativa da Red Hat ou sua imagem na Wall Street – ou seja, aquilo para o que me preparei – Matthew Shulik perguntava mais sobre minhas esperanças, sonhos e objetivos. Agora, fica claro que Shulik estava avaliando se eu me encaixaria na subcultura e no estilo de liderança da empresa.
Depois que terminamos, Shulik disse que queria me apresentar ao conselheiro-geral da empresa, Michael Cunningham, e sugeriu que nos encontrássemos agora, para um almoço antecipado. Concordei, e começamos a nos levantar. Então, meu entrevistador percebeu que não tinha sua carteira com ele. "Ops", ele disse. "Não tenho dinheiro. E você?" Isso me pegou de surpresa, mas respondi que eu tinha dinheiro e que não me importava em pagar pelo café.
Alguns minutos depois, Shulik me deixou em uma pequena lanchonete mexicana, onde conheci Michael Cunningham. Mas novamente não houve uma entrevista tradicional ou uma reunião de negócios, mas sim mais uma conversa interessante. Quando estávamos prestes a pagar a conta, descobrimos que a máquina de cartões no restaurante estava quebrada, e só aceitavam dinheiro. Cunningham se virou para mim e perguntou se eu poderia pagar, já que ele não tinha dinheiro consigo. Como eu estava indo para Nova York, tinha bastante dinheiro em espécie, então paguei pelo almoço.
Canningham se ofereceu para me levar ao aeroporto, e fomos de carro. Alguns minutos depois, ele perguntou: “Você se importaria se eu parasse para abastecer? Vamos acelerar.” – “Sem problemas”, respondi. Assim que ouvi o rítmico som da bomba, houve uma batida na janela. Era Canningham. “Ei, aqui não aceitam cartões de crédito”, ele informou. “Posso emprestar um pouco de dinheiro?” Comecei a me perguntar se realmente era uma entrevista ou algum tipo de golpe.
No dia seguinte, enquanto estava em Nova Iorque, discuti com minha esposa sobre a entrevista na Red Hat. Eu mencionei que a conversa foi muito interessante, mas não tinha certeza se aquelas pessoas realmente pretendiam me contratar: talvez só quisessem comida e gasolina de graça? Refletindo sobre aquele encontro hoje, percebo que Shulik e Canningham eram apenas pessoas abertas e me tratavam como qualquer outra pessoa com quem poderiam tomar um café, almoçar ou abastecer o carro. Sim, é engraçado e até cômico que ambos estivessem sem dinheiro. Mas para eles, a questão não era o dinheiro. Assim como o mundo ao redor do código aberto, eles não acreditavam em tapetes vermelhos ou em tentar convencer o entrevistado de que tudo estava perfeito. Eles simplesmente queriam me conhecer melhor, em vez de tentar impressionar ou destacar nossas diferenças. Eles queriam saber quem eu era.
Minha primeira entrevista na Red Hat me mostrou claramente que o trabalho aqui é diferente. Nesta empresa, não há uma hierarquia tradicional e um regime especial para líderes, pelo menos não da forma como é comum na maioria das outras empresas. Com o tempo, também aprendi que a Red Hat acredita no princípio da meritocracia: sempre vale a pena tentar implementar a melhor ideia, não importa se ela vem da alta administração ou de um estagiário de verão. Em outras palavras, minha primeira impressão da Red Hat me apresentou o futuro da liderança.
Dicas para cultivar a meritocracia
Meritocracia é o valor principal da comunidade de código aberto. Não importa qual nível da pirâmide você ocupa, o que importa é quão boas são suas ideias. Aqui está o que Jim sugere:
- Nunca diga: "É assim que o chefe quer" – e não confie na hierarquia. Isso pode ajudá-lo no curto prazo, mas não se constrói uma meritocracia dessa maneira.
- Reconheça publicamente os sucessos e as contribuições importantes para o bem comum. Pode ser um simples e-mail de agradecimento, copiado para toda a equipe.
- Pense: sua autoridade depende de sua posição hierárquica (ou do acesso a informações privilegiadas) ou é o resultado do respeito que você conquistou? Se for a primeira, comece a trabalhar na segunda.
- Peça feedback e reúna ideias sobre um tópico específico. Você deve reagir a tudo, testar apenas o melhor. Mas não basta pegar as melhores ideias e seguir em frente – use qualquer oportunidade para fortalecer o espírito meritocrático, dando crédito a todos que merecem.
- Destaque um membro exemplar de sua equipe, oferecendo uma tarefa interessante, mesmo que não esteja relacionada à sua área habitual.
Deixe suas "rock stars" seguirem sua paixão.
Entusiasmo e engajamento são duas palavras muito importantes em uma organização aberta. No livro, elas são mencionadas com frequência. Mas você não pode forçar pessoas criativas e apaixonadas a trabalhar "do começo ao fim", certo? Caso contrário, você não aproveitará tudo o que seu talento pode oferecer. Na Red Hat, os obstáculos para projetos pessoais são minimizados ao máximo:
«Para gerenciar inovações, as empresas tentam muito. O conceito da Google é interessante. Desde que a Google se tornou conhecida em cada casa, a partir de 2004, líderes e pensadores do setor de internet tentaram descobrir o grande segredo da empresa para replicar seu impressionante sucesso. Um dos programas mais conhecidos, mas atualmente descontinuados, era que todos os funcionários da Google eram incentivados a usar 20% de seu tempo de trabalho em qualquer projeto que desejassem. A ideia era a seguinte: se os funcionários começassem a desenvolver seus próprios projetos e ideias que os apaixonam fora do trabalho, começariam a criar inovações. Assim surgiram projetos externos de sucesso: GoogleSuggest, AdSense for Content e Orkut; todos eles nasceram desse experimento dos 20% – uma lista impressionante! [...]
Na Red Hat, adotamos uma abordagem menos formal. Não temos uma política estabelecida sobre quanto tempo cada um de nossos funcionários deve dedicar à "inovação". Em vez de designar horários específicos para autoaprendizado, fazemos com que os colaboradores ganhem o direito de usar seu tempo para novas ideias. Para ser honesto, muitos têm pouco tempo disponível, mas há aqueles que conseguem dedicar quase todo o dia de trabalho à inovação.
O caso mais típico se apresenta da seguinte forma: alguém trabalha em um projeto paralelo (se tiver explicado a relevância para os gerentes - diretamente no horário de trabalho; ou em seu tempo livre - por iniciativa própria), e mais tarde esse trabalho pode ocupar todas as suas horas de presença.
Mais do que um brainstorming
"Um desvio lírico. Alex Faikney Osborn - inventor do método de 'brainstorming', que é a base do método de sinéctica atualmente. Curiosamente, essa ideia surgiu durante a Segunda Guerra Mundial, quando Osborn comandava um dos navios de um comboio mercante americano sob ataque de um submarino alemão. Naquela época, o capitão se lembrou de uma técnica utilizada por piratas medievais: se a tripulação se encontrasse em apuros, todos os marinheiros se reuniriam no convés para propor soluções, uma a uma. Havia muitas ideias, incluindo algumas que, à primeira vista, pareciam absurdas: por exemplo, a proposta de soprar na torpedo com toda a equipe. Mas com o jato da bomba de navio, que está disponível em cada embarcação, é possível desacelerar ou mesmo mudar a direção da torpedo. Como resultado, Osborn até patenteou a invenção: um parafuso adicional é instalado na lateral do navio para jorrar um fluxo de água, enquanto a torpedo desliza ao lado."
Nosso Jim costuma repetir que em uma organização aberta não é tão fácil trabalhar. Até a liderança sente a pressão, pois ninguém está isento de ter que defender suas opiniões. Mas essa é a abordagem necessária para alcançar excelentes resultados:
«Fóruns online [de desenvolvedores de código aberto] e chats frequentemente estão cheios de discussões animadas, e às vezes até mordazes, sobre tudo – desde a melhor forma de corrigir um erro de software até quais novas funcionalidades devem ser consideradas na próxima atualização. Normalmente, essa é a primeira fase das discussões, em que novas ideias são apresentadas e acumuladas, mas sempre há uma próxima rodada – a análise crítica. Embora todos possam participar dessas disputas, é necessário estar preparado para defender sua posição com todas as forças. Ideias impopulares, na melhor das hipóteses, são rejeitadas e, na pior, ridicularizadas.
Até Linus Torvalds, o criador do sistema operacional Linux, expressa sua discordância em relação às mudanças propostas no código. Certa vez, Linus e David Howells, um dos principais desenvolvedores da Red Hat, entraram em uma acalorada polêmica sobre os benefícios de uma mudança de código solicitada pela Red Hat, que ajudaria a garantir a segurança para nossos clientes. Em resposta ao pedido de Howells, Torvalds escreveu: «Francamente, isso é [palavra imprópria] idiotice. Tudo parece girar em torno dessas interfaces estúpidas, e por razões completamente idiotas. Por que temos que fazer isso? Eu já não gosto do parser X.509 existente. Estão sendo criadas interfaces idiotas e complexas, e agora haverá 11 delas. – Linus 9».
Deixando de lado os detalhes técnicos, Torvalds continuou escrevendo na mesma linha em sua próxima mensagem – algo que eu não ouso citar. Essa disputa teve um impacto tão grande que até chegou às páginas do The Wall Street Journal. […]
Esta disputa mostra que, na maioria das empresas que lançam programas proprietários, não há debates abertos sobre quais novas características ou mudanças estão sendo consideradas. Quando o produto está pronto, a empresa simplesmente o envia aos clientes e segue em frente. Ao mesmo tempo, no caso do Linux, as discussões sobre quais mudanças são necessárias e – mais importante – por que elas são necessárias, não cessam. Isso, claro, torna todo o processo muito mais desordenado e trabalhoso».
Lançar cedo, lançar com frequência
Não podemos prever o futuro, por isso devemos apenas tentar:
«Nós operamos com o princípio de 'lançamento antecipado, atualizações frequentes'. O principal problema de qualquer projeto de software é o risco de erros ou bugs no código-fonte. É evidente que quanto mais alterações e atualizações se acumulam em uma única versão do software, maior a probabilidade de que essa versão contenha bugs. Os desenvolvedores de software de código aberto perceberam que com lançamentos rápidos e frequentes de versões, o risco de problemas sérios em qualquer programa diminui – pois não trazemos todas as atualizações de uma só vez, mas em porções a cada versão. Com o tempo, notamos que essa abordagem não só reduz o número de erros, mas também leva a soluções mais interessantes. Afinal, a introdução constante de pequenas melhorias acaba gerando mais inovações. Pode não haver nada de surpreendente nisso. Um dos princípios-chave dos processos de produção modernos, como kaizen ou lean, é o foco em pequenas e graduais mudanças e atualizações.
[…] Muito do que trabalhamos pode não ter sucesso. Mas, em vez de perdermos muito tempo pensando no que funcionará e no que não funcionará, preferimos realizar pequenos experimentos. As ideias mais demandadas levarão ao sucesso, enquanto aquelas que não funcionarem se extinguirão por si mesmas. Assim, podemos testar muitas coisas, e não apenas uma, sem riscos significativos para a empresa.
Esta é uma maneira racional de alocar recursos. Por exemplo, as pessoas costumam me perguntar como escolhemos quais projetos de código aberto devemos comercializar. Embora às vezes iniciemos projetos, na maioria das vezes apenas nos juntamos a projetos existentes. Um pequeno grupo de engenheiros — às vezes uma única pessoa — começa a contribuir para um dos projetos da comunidade de código aberto. Se o projeto for bem-sucedido e demandado por nossos clientes, começamos a dedicar mais tempo e esforço a ele. Caso contrário, os desenvolvedores mudam para um novo projeto. Quando decidimos comercializar a oferta, o projeto pode ter crescido a tal ponto que a decisão se torna óbvia. Uma variedade de projetos, incluindo aqueles não relacionados a software, surgem naturalmente em toda a empresa Red Hat, até que todos percebam que agora alguém terá que trabalhar com isso continuamente.
Aqui está outra citação do livro:
«Percebi que, para atender a tal papel, os líderes de amanhã devem se diferenciar por características que as organizações comuns simplesmente ignoram. Para liderar eficazmente uma organização aberta, o líder deve possuir as seguintes qualidades.
- Força pessoal e confiança. Líderes comuns utilizam o poder posicional — seu cargo — para ter sucesso. Mas na meritocracia, os líderes precisam ganhar respeito. E isso só é possível se eles não tiverem medo de reconhecer que não têm respostas para todas as perguntas. Eles devem estar dispostos a discutir problemas e tomar decisões rapidamente, para encontrar as melhores soluções em colaboração com sua equipe.
- Paciência. A mídia raramente conta histórias sobre quão "paciente" um líder é. Mas ele realmente precisa ser paciente. Quando você está trabalhando para obter o máximo de esforço e resultados de sua equipe, passando horas dialogando e repetindo algo várias vezes até que tudo esteja feito corretamente, você precisa ter paciência.
- Alta EQ (inteligência emocional). Com frequência, destacamos as capacidades intelectuais dos líderes, focando no seu QI, quando, na verdade, é necessário considerar o seu coeficiente de inteligência emocional, ou avaliação de EQ. Ser a pessoa mais inteligente entre os outros não é suficiente se você não consegue trabalhar com essas pessoas. Quando você está lidando com comunidades de funcionários engajados, como na Red Hat, e não tem a capacidade de ordens, sua habilidade de ouvir, processar de forma analítica e não levar as coisas para o lado pessoal torna-se extremamente valiosa.
- Outra mentalidade. Líderes que vêm de organizações tradicionais foram educados sob o espírito do quid pro quo, onde cada ação deve receber uma compensação adequada. Mas quando você se propõe a investir na construção de uma determinada comunidade, deve pensar a longo prazo. É como tentar construir um ecossistema delicadamente equilibrado, onde qualquer passo em falso pode criar um desequilíbrio e resultar em perdas de longo prazo que podem não ser percebidas imediatamente. Os líderes devem se livrar do tipo de pensamento que exige resultados imediatos a qualquer custo e começar uma maneira de fazer negócios que permita obter maiores benefícios através do investimento no futuro.
E por que isso é importante
A Red Hat vive e opera com princípios que diferem significativamente da organização tradicional com hierarquia rígida. E isso funciona, nos tornando comercialmente bem-sucedidos e felizes como seres humanos. Traduzimos este livro na esperança de disseminar os princípios da organização aberta entre as empresas russas, entre pessoas que querem e podem viver de forma diferente.
, experimente!
Fonte: habr.com
