Chegou um dia importante para a Red Hat, a comunidade russa de código aberto e todos os envolvidos - foi publicado em russo . Ela conta em detalhes e vividamente como nós da Red Hat damos o caminho às melhores ideias e às pessoas mais talentosas, e também sobre como não se perder no caos e unir milhões de pessoas ao redor do mundo.
Este livro também é sobre vida e prática. Ele contém muitos conselhos para quem deseja aprender como construir uma empresa usando o modelo de organização aberta e gerenciá-la com eficácia. Abaixo estão alguns dos princípios mais importantes fornecidos no livro que você pode observar agora.
O histórico profissional de Jim na empresa é notável. Isso mostra que não há alarde no mundo do código aberto, mas há uma nova abordagem de liderança:
“Depois de falar com o recrutador, manifestei interesse em uma entrevista e ele perguntou se eu me importaria de voar para a sede da Red Hat em Raleigh, Carolina do Norte, no domingo. Achei que domingo era um dia estranho para nos encontrarmos. Mas como eu ainda iria voar para Nova York na segunda-feira, em geral estava a caminho e concordei. Embarquei em um avião em Atlanta e pousei no aeroporto Raleigh Durham. De lá, peguei um táxi que me deixou em frente ao prédio da Red Hat, no campus da Universidade da Carolina do Norte. Era domingo, 9h30, e não havia ninguém por perto. As luzes estavam apagadas e ao verificar descobri que as portas estavam trancadas. No começo pensei que estava sendo enganado. Quando me virei para voltar para o táxi, vi que ele já havia partido. Logo começou a chover, eu não tinha guarda-chuva.
Quando eu estava prestes a pegar um táxi em algum lugar, Matthew Shulick, mais tarde presidente do conselho de administração e CEO da Red Hat, parou em seu carro. “Oi,” ele cumprimentou. “Você gostaria de tomar um café?” Parecia uma maneira incomum de começar uma entrevista, mas eu sabia que definitivamente precisava tomar um café. No final das contas, pensei, seria mais fácil pegar um táxi para o aeroporto.
As manhãs de domingo são bastante tranquilas na Carolina do Norte. Demorou um pouco para encontrar uma cafeteria que abrisse antes do meio-dia. A cafeteria não era a melhor da cidade e nem a mais limpa, mas funcionava e você podia tomar café acabado de fazer ali. Sentamos em uma mesa e começamos a conversar.
Depois de cerca de trinta minutos, percebi que gostava do modo como as coisas estavam indo; A entrevista não foi tradicional, mas a conversa em si acabou sendo muito interessante. Em vez de discutir as complexidades da estratégia corporativa da Red Hat ou sua imagem em Wall Street — algo para o qual eu havia me preparado — Matthew Shulick perguntou mais sobre minhas esperanças, sonhos e objetivos. Agora está claro para mim que Shulik estava avaliando se eu me encaixaria na subcultura e no estilo de gestão da empresa.
Depois que terminamos, Shulick disse que queria me apresentar ao conselheiro geral da empresa, Michael Cunningham, e sugeriu que eu me encontrasse com ele agora para almoçarmos mais cedo. Eu concordei e nos preparamos para sair. Então meu interlocutor descobriu que não estava com a carteira. “Opa”, disse ele. - Não tenho dinheiro. E você?" Isso me pegou de surpresa, mas respondi que tinha dinheiro e não me importava de pagar o café.
Poucos minutos depois, Shulik me deixou em um pequeno restaurante mexicano, onde conheci Michael Cunningham. Mas, novamente, não se seguiu nenhuma entrevista tradicional ou reunião de negócios, mas ocorreu outra conversa interessante. Quando estávamos prestes a pagar a conta, descobrimos que a máquina de cartão de crédito do restaurante estava quebrada e só podíamos aceitar dinheiro. Cunningham virou-se para mim e perguntou se eu estava disposto a pagar, porque ele não tinha dinheiro consigo. Como eu estava indo para Nova York, eu tinha muito dinheiro, então paguei o almoço.
Cunningham se ofereceu para me levar ao aeroporto e fomos no carro dele. Depois de alguns minutos, ele perguntou: “Você se importa se eu parar e abastecer? Seguiremos a todo vapor." “Sem problemas”, respondi. Assim que ouvi o som rítmico da bomba, ouvi uma batida na janela. Foi Cunningham. “Ei, eles não aceitam cartões de crédito aqui”, disse ele. “Posso pegar algum dinheiro emprestado?” Comecei a me perguntar se isso era realmente uma entrevista ou algum tipo de fraude.
No dia seguinte, enquanto estava em Nova York, discuti esta entrevista com minha esposa na Red Hat. Eu disse a ela que a conversa era muito interessante, mas não tinha certeza se essas pessoas estavam falando sério sobre me contratar: talvez elas só quisessem comida e gasolina de graça? Lembrando daquele encontro de hoje, entendo que Shulick e Cunningham eram simplesmente pessoas abertas e me trataram como qualquer outra pessoa com quem pudessem tomar café, almoçar ou abastecer. Sim, é engraçado e até engraçado que os dois tenham ficado sem dinheiro. Mas para eles não se tratava de dinheiro. Eles, assim como o mundo do código aberto, não acreditavam em estender tapetes vermelhos ou em tentar convencer os outros de que tudo estava perfeito. Eles estavam apenas tentando me conhecer melhor, não tentando impressionar ou apontar nossas diferenças. Eles queriam saber quem eu era.
Minha primeira entrevista na Red Hat me mostrou claramente que o trabalho aqui era diferente. Esta empresa não possuía uma hierarquia tradicional e um tratamento especial para os gestores, pelo menos na forma que é habitual na maioria das outras empresas. Com o tempo, aprendi também que a Red Hat acredita no princípio da meritocracia: vale sempre a pena tentar implementar a melhor ideia, independentemente de ela vir da alta administração ou de um estagiário de verão. Em outras palavras, minha primeira experiência na Red Hat me apresentou como será o futuro da liderança.”
Dicas para cultivar a meritocracia
A meritocracia é o valor central da comunidade de código aberto. Não importa para nós qual nível da pirâmide você ocupa, o principal é quão boas são suas ideias. Aqui está o que Jim sugere:
- Nunca diga: “É isso que o chefe quer” e não confie na hierarquia. Isso pode ajudá-lo no curto prazo, mas não é assim que se constrói uma meritocracia.
- Reconhecer publicamente sucessos e contribuições importantes. Este poderia ser um simples e-mail de agradecimento com toda a equipe em cópia.
- Considere: a sua autoridade é uma função da sua posição na hierarquia (ou do acesso a informações privilegiadas) ou é resultado do respeito que você conquistou? Se for o primeiro, comece a trabalhar no segundo.
- 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 se limite a pegar nas melhores ideias e seguir em frente com elas – aproveite todas as oportunidades para fortalecer o espírito de meritocracia, dando crédito a todos que o merecem.
- Reconheça um membro exemplar da sua equipe, oferecendo uma tarefa interessante, mesmo que não seja na sua área habitual de trabalho.
Deixe suas estrelas do rock seguirem sua paixão
Entusiasmo e envolvimento são duas palavras muito importantes em uma organização aberta. Eles são repetidos constantemente no livro. Mas você não pode fazer com que pessoas criativas e apaixonadas trabalhem duro, certo? Caso contrário, você simplesmente não obterá tudo o que o talento deles tem a oferecer. Na Red Hat, os obstáculos para seus próprios projetos são nivelados tanto quanto possível:
“Para impulsionar a inovação, as empresas tentam muitas coisas. A abordagem do Google é interessante. Desde que o Google se tornou conhecido em todos os lares em 2004, executivos e ideólogos do ramo da Internet têm tentado desvendar o principal segredo da empresa para repetir seu sucesso impressionante. Um dos programas mais famosos, mas atualmente encerrado, era que todos os funcionários do Google fossem convidados a gastar 20% de seu tempo fazendo quase tudo o que quisessem. A ideia era que, se os funcionários seguissem seus próprios projetos e ideias pelos quais eram apaixonados fora do trabalho, eles começariam a inovar. Foi assim que surgiram projetos de terceiros de sucesso: GoogleSuggest, AdSense for Content e Orkut; todos eles vieram desse experimento de 20% – uma lista impressionante! […]
Na Red Hat, adotamos uma abordagem menos formal. Não temos uma política definida sobre quanto tempo cada um dos nossos funcionários deve dedicar à “inovação”. Em vez de dar às pessoas tempo dedicado para se educarem, garantimos que os funcionários ganhem o direito de gastar seu tempo aprendendo coisas novas. Para ser sincero, muitas pessoas têm muito pouco tempo, mas também há quem consiga dedicar quase todo o dia de trabalho à inovação.
O caso mais típico é mais ou menos assim: alguém trabalha em um projeto paralelo (se explicou sua importância aos gestores - diretamente no local de trabalho; ou fora do horário de trabalho - por iniciativa própria), e posteriormente esse trabalho pode ocupar todo o seu horário atual.
Mais do que brainstorming
“Digressão lírica. Alex Fakeney Osborne é o inventor do método de brainstorming, cuja continuação hoje é o método sinético. É curioso que essa ideia tenha surgido durante a Segunda Guerra Mundial, quando Osborne comandava um dos navios de um comboio de carga americano que corria o risco de ser atacado por um torpedo de um submarino alemão. Então o capitão lembrou-se da técnica a que recorriam os piratas da Idade Média: se a tripulação se metesse em apuros, todos os marinheiros se reuniam no convés para se revezarem sugerindo uma forma de resolver o problema. Foram muitas ideias, inclusive absurdas à primeira vista: por exemplo, a ideia de explodir um torpedo com toda a equipe. Mas com o jato da bomba de navio, que está disponível em todos os navios, é bem possível desacelerar um torpedo ou até mesmo mudar seu curso. Como resultado, Osborne até patenteou uma invenção: uma hélice adicional é montada na lateral do navio, que impulsiona um fluxo de água ao longo da lateral, e o torpedo desliza ao lado.”
Nosso Jim repete constantemente que não é tão fácil trabalhar em uma organização aberta. Até a gestão entende, pois ninguém é poupado da necessidade de defender a sua opinião. Mas esta é exatamente a abordagem necessária para alcançar excelentes resultados:
“Fóruns e salas de bate-papo on-line [de código aberto] costumam estar repletos de discussões animadas e às vezes amargas sobre tudo, desde a melhor forma de corrigir um bug de software até quais novos recursos devem ser considerados na próxima atualização. Via de regra, esta é a primeira fase das discussões, durante a qual novas ideias são apresentadas e acumuladas, mas há sempre uma próxima rodada - a análise crítica. Embora qualquer pessoa possa participar nestes debates, a pessoa deve estar preparada para defender a sua posição com todas as suas forças. Idéias impopulares serão rejeitadas, na melhor das hipóteses, e ridicularizadas, na pior.
Até Linus Torvalds, criador do sistema operacional Linux, expressa seu desacordo com as alterações propostas no código. Um dia, Linus e David Howells, um dos principais desenvolvedores da Red Hat, entraram em um debate acalorado sobre os méritos de uma mudança de código solicitada pela Red Hat que ajudaria a fornecer segurança aos nossos clientes. Em resposta ao pedido de Howells, Torvalds escreveu: “Francamente, isto é [palavra não imprimível] idiota. Tudo parece girar em torno dessas interfaces estúpidas, e por razões completamente estúpidas. Por que devemos fazer isso? Não gosto mais do analisador X.509 existente. Interfaces estupidamente complexas estão sendo criadas e agora serão 11. – Linus 9.”
Deixando de lado os detalhes técnicos, Torvalds continuou a escrever com o mesmo espírito na mensagem seguinte - e de uma forma que não me atrevo a citar. Essa disputa foi tão barulhenta que chegou até às páginas do The Wall Street Journal. […]
Este debate mostra que a maioria das empresas que produzem software proprietário e não-livre não têm um debate aberto sobre quais as novas funcionalidades ou mudanças em que poderão estar a trabalhar. 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 - o mais importante - por que são necessárias, não diminuem. Isso, é claro, torna todo o processo muito mais confuso e demorado.”
Libere mais cedo, libere com frequência
Não podemos prever o futuro, então só temos que tentar:
“Operamos com base no 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. Obviamente, quanto mais alterações e atualizações forem coletadas em um lançamento (versão) de software, maior será a probabilidade de haver bugs nesta versão. Os desenvolvedores de software de código aberto perceberam que, ao lançar versões de software de forma rápida e frequente, o risco de problemas sérios com qualquer programa é reduzido – afinal, não trazemos todas as atualizações ao mercado de uma vez, mas uma de cada vez para cada versão. Com o tempo, percebemos que esta abordagem não só reduz erros, mas também leva a soluções mais interessantes. Acontece que fazer pequenas melhorias continuamente cria mais inovação no longo prazo. Talvez não haja nada de surpreendente aqui. Um dos princípios-chave dos processos de fabricação modernos, como kaizen a ou lean b, é o foco em mudanças e atualizações pequenas e incrementais.
[…] Muito daquilo em que trabalhamos pode não ter sucesso. Mas em vez de gastar muito tempo imaginando o que funcionará e o que não funcionará, preferimos realizar pequenos experimentos. As ideias mais populares levarão ao sucesso, e aquelas que não funcionarem desaparecerão por si mesmas. Dessa forma podemos tentar muitas coisas em vez de apenas uma, sem muitos riscos para a empresa.
Esta é uma forma racional de alocar recursos. Por exemplo, muitas vezes as pessoas me perguntam como escolhemos quais projetos de código aberto comercializar. Embora às vezes iniciemos projetos, na maioria das vezes simplesmente saltamos para os já existentes. Um pequeno grupo de engenheiros – às vezes apenas uma pessoa – começa a contribuir para um dos projetos da comunidade de código aberto. Se o projeto for bem-sucedido e procurado por nossos clientes, começaremos a dedicar mais tempo e esforço nele. Caso contrário, os desenvolvedores passam para um novo projeto. No momento em que decidimos comercializar a proposta, o projeto pode ter crescido a tal ponto que a solução é óbvia. Vários projetos, incluindo aqueles que não são de software, surgem naturalmente em toda a Red Hat até que fique claro para todos que agora alguém terá que trabalhar nisso em tempo integral.”
Aqui está outra citação do livro:
“Percebi que, para cumprir esta função, os líderes de amanhã deverão ter características que são simplesmente ignoradas nas organizações convencionais. Para liderar eficazmente uma organização aberta, um líder deve ter as seguintes qualidades.
- Força e confiança pessoal. Os líderes comuns usam o poder posicional – a sua posição – para alcançar o sucesso. Mas numa meritocracia, os líderes devem merecer respeito. E isso só é possível se não tiverem medo de admitir que não têm todas as respostas. Eles devem estar dispostos a discutir problemas e tomar decisões rapidamente para encontrar as melhores soluções com sua equipe.
- Paciência. A mídia raramente conta histórias sobre o quão “paciente” um líder é. Mas ele realmente deve ser paciente. Quando você está trabalhando para obter o melhor esforço e resultados de sua equipe, conversando por horas e repetindo coisas indefinidamente até que tudo seja feito corretamente, você precisa ser paciente.
- Alto EQ (inteligência emocional). Muitas vezes promovemos a inteligência dos líderes concentrando-nos no seu QI, quando o que realmente precisa de ser levado em conta é o seu quociente de inteligência emocional, ou pontuação de QE. Ser a pessoa mais inteligente entre outras não é suficiente se você não for capaz de trabalhar com essas pessoas. Quando você trabalha com comunidades de funcionários engajados, como a Red Hat, e não tem a capacidade de dar ordens a ninguém, sua capacidade de ouvir, processar analiticamente e não levar as coisas para o lado pessoal se torna extremamente valiosa.
- Mentalidade diferente. Os líderes provenientes de organizações tradicionais foram criados com o espírito de quid pro quo (latim para “quid pro quo”), segundo o qual cada ação deve receber um retorno adequado. Mas quando se pretende investir na construção de uma comunidade específica, é preciso pensar a longo prazo. É como tentar construir um ecossistema delicadamente equilibrado, onde qualquer passo errado pode criar um desequilíbrio e levar a perdas a longo prazo que você pode não perceber imediatamente. Os líderes devem livrar-se da mentalidade que os obriga a alcançar resultados hoje a qualquer custo e começar a fazer negócios de uma forma que lhes permita colher maiores benefícios do investimento no futuro.”
E por que isto é importante
A Red Hat vive e opera com base em princípios muito diferentes de uma organização hierárquica tradicional. E funciona, nos torna comercialmente bem-sucedidos e humanamente felizes. Traduzimos este livro na esperança de difundir os princípios da organização aberta entre as empresas russas, entre as pessoas que querem e podem viver de forma diferente.
, tente!
Fonte: habr.com