Chegou um dia importante para a Red Hat, a comunidade russa de código aberto e todos os envolvidos - no russo,
o livro de Jim Whitehurst, Organização aberta: paixão traz frutas, foi publicado . Ela conta em detalhes e de maneira vívida como nós da Red Hat damos as melhores idéias e as pessoas mais talentosas, e como não nos perder no caos e reunir milhões de pessoas em todo o mundo.
E este livro é sobre vida e prática. Tem muitas dicas para todos que desejam aprender como construir uma empresa de acordo com o modelo de uma organização aberta e gerenciá-la efetivamente. Abaixo estão alguns dos princípios mais importantes dados no livro, dos quais você pode tomar nota agora.
(Vídeo disponível com legendas em russo)
O histórico de empregos de Jim é notável. Isso mostra que no mundo do código aberto não há alarde, mas há uma nova abordagem para a liderança:
“Depois de conversar com o recrutador, manifestei interesse na entrevista e ele perguntou se eu não me importaria de ir à sede da Red Hat em Raleigh, Carolina do Norte, no domingo. Eu pensei que domingo era um dia estranho para conhecer. Mas desde que eu ia voar para Nova York na segunda-feira de qualquer maneira, estava a caminho e concordei. Peguei um avião de Atlanta e aterrissei no aeroporto de Raleigh Durham. De lá, peguei um táxi que me deixou na frente da empresa Red Hat, no campus da Universidade da Carolina do Norte. Era domingo, às 9h30, e ninguém estava por perto. A luz estava apagada e, depois de verificar, descobri que as portas estavam trancadas. No começo, decidi que estava sendo enganado. Virando-me para retornar ao táxi, vi que ele já havia saído. Começou a chover muito em breve, eu não tinha guarda-chuva.
Assim que eu estava indo para um lugar para pegar um táxi, Matthew Schulick, mais tarde presidente do conselho de administração e CEO da Red Hat, parou em seu carro. "Oi", ele disse. "Você gostaria de um café?" Pareceu-me um começo incomum da entrevista, mas percebi que definitivamente precisava tomar café. Por fim, pensei, será mais fácil pegar um táxi para o aeroporto.
Domingo na Carolina do Norte é bastante calmo pela manhã. Levamos um tempo para encontrar uma cafeteria que se abrisse antes do meio dia. A cafeteria não era a melhor da cidade e nem a mais limpa, mas funcionava e ali você podia beber café fresco. Sentamos à mesa e começamos uma conversa.
Cerca de trinta minutos depois, percebi que gosto de como tudo vai; a entrevista não era tradicional, mas a conversa em si foi muito interessante. Em vez de discutir os meandros da estratégia corporativa da Red Hat ou sua imagem em Wall Street - ou seja, fazendo o que me preparei -, Matthew Shulick perguntou mais sobre minhas esperanças, sonhos e objetivos. Agora entendo que Shulik estava avaliando se eu estaria de acordo com o estilo de subcultura e gerenciamento da empresa.
Depois que terminamos, Shulik anunciou que queria me apresentar ao advogado geral da empresa, Michael Cunningham, e se ofereceu para se encontrar com ele agora, em um almoço cedo. Eu concordei e estávamos prestes a sair. Então meu interlocutor descobriu que não tinha carteira com ele. "Opa", ele disse. "Eu não tenho dinheiro." E você? Peguei-me de surpresa, mas respondi que tenho dinheiro e não me importo de pagar pelo café.
Alguns minutos depois, Shulik me deixou em uma pequena lanchonete mexicana onde me encontrei com Michael Cunningham. Mas, novamente, nenhuma entrevista tradicional ou reunião de negócios se seguiu, mas outra conversa interessante ocorreu. Quando íamos pagar a conta, verificou-se que a máquina para pagamento com cartão de crédito havia quebrado no restaurante, e somente dinheiro podia ser aceito por nós. Cunningham virou-se para mim e perguntou se eu estava disposto a pagar porque ele não tinha dinheiro com ele. Desde que eu estava indo para Nova York, eu tinha muito dinheiro, então paguei o almoço.
Cunningham se ofereceu para me dar uma carona até o aeroporto e nós dirigimos em seu carro. Alguns minutos depois, ele perguntou: “Você se importa se eu parar e reabastecer? Vamos correr a toda velocidade. "Não tem problema", respondi. Assim que ouvi a batida rítmica da bomba, houve uma batida na janela. Era Cunningham. "Ei, eles não aceitam cartões de crédito aqui", disse ele. "Posso emprestar algum dinheiro?" Comecei a me perguntar se isso é realmente uma entrevista ou algum tipo de golpe.
No dia seguinte, enquanto estava em Nova York, discuti com minha esposa esta entrevista com a Red Hat. Eu disse a ela que a conversa era muito interessante, mas não tenho certeza se essas pessoas realmente pretendem me contratar: talvez elas precisassem apenas de comida e gasolina gratuitas? Lembrando-me da reunião de hoje, entendo que Shulik e Cunningham eram apenas pessoas abertas e me trataram como qualquer outra pessoa com quem pudessem tomar café, almoçar ou reabastecer com gasolina. Sim, é engraçado e até engraçado que ambos acabaram sem dinheiro. Mas para eles não se tratava de dinheiro. Eles, como o mundo em torno do código aberto, não acreditavam no tapete vermelho ou na tentativa de convencer a outra pessoa de que tudo estava perfeito. Eles simplesmente procuraram me conhecer melhor, em vez de tentar 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 é diferente. Essa empresa não observou uma hierarquia tradicional e um regime especial para gerentes, pelo menos na forma que é aceita 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 traduzir as melhores idéias, seja da alta gerência ou de um estagiário contratado para um emprego de verão. Em outras palavras, minha primeira impressão da Red Hat me apresentou a aparência do futuro da liderança. ”
Dicas de cultivo de meritocracia
A meritocracia é um valor central da comunidade de código aberto. Não nos importamos com o nível da pirâmide que você ocupa, o principal é o quão boas são suas idéias. Aqui está o que Jim oferece:
- Nunca diga: "É isso que o chefe deseja" e não confie na hierarquia. Isso pode ajudá-lo a curto prazo, mas a meritocracia não pode ser construída assim.
- Reconheça publicamente sucessos e contribuições importantes para a causa comum. Pode ser um simples e-mail de agradecimento, em uma cópia da qual é toda a equipe.
- Pense: sua autoridade depende de sua posição na hierarquia (ou do acesso a informações privilegiadas) ou é o resultado do respeito que você conquistou? Se o primeiro - comece a trabalhar no segundo.
- Peça feedback e colete idéias sobre um tópico específico. Deve responder a tudo, teste - apenas o melhor. Mas não apenas pegue as melhores idéias e siga em frente - use todas as oportunidades para fortalecer o espírito da meritocracia, prestando homenagem a todos que a merecem.
- Marque o membro exemplar de sua equipe, oferecendo uma tarefa interessante, mesmo que não pertença ao seu campo de atividade habitual.
Deixe suas estrelas do rock seguirem sua paixão
Entusiasmo e engajamento são duas palavras muito importantes em uma organização aberta. No livro, eles são repetidos constantemente. Mas você não pode atrair pessoas criativas e entusiasmadas para trabalhar sem parar, certo? Caso contrário, apenas não obtenha tudo o que seu talento pode oferecer. No Red Hat, os obstáculos para seus próprios projetos são nivelados o máximo possível:
“As empresas estão tentando muito impulsionar a inovação. A abordagem do Google é interessante. Desde que o Google começou a ser conhecido em todos os lares desde 2004, executivos e ideólogos do setor de Internet tentaram desvendar o principal segredo da empresa para repetir seu sucesso impressionante. Um dos programas mais conhecidos, mas atualmente fechados, era que todos os funcionários do Google eram convidados a gastar 20% do tempo de trabalho em quase tudo o que desejavam. A idéia era a seguinte: se os funcionários começarem a implementar seus próprios projetos e idéias pelas quais são apaixonados, além do trabalho, começarão a criar inovações. Foi assim que surgiram os projetos de terceiros de sucesso: GoogleSuggest, AdSense for Content e Orkut; todos eles vieram desse experimento com 20% - uma lista impressionante! [...]
Nós da Red Hat adotamos uma abordagem menos formal. Não temos uma política estabelecida sobre quanto tempo cada um de nossos funcionários deve gastar em “inovação”. Em vez de dar às pessoas tempo separado para a autoeducação, garantimos que os funcionários obtenham o direito de gastar seu tempo em coisas novas. Francamente, muitos têm um pouco desse tempo, mas há quem possa gastar quase todo o dia útil em inovação.
O caso mais típico se parece com isso: alguém está trabalhando em um projeto de terceiros (se ele explicou aos gerentes a importância disso no local de trabalho; ou depois de horas por sua própria iniciativa), e mais tarde esse trabalho pode levar todo o seu horário de expediente ”.
Mais do que um brainstorm
“Digressão lírica. Alex Fakney Osbourne é o inventor do método de brainstorming, cuja continuação é hoje o método sinético. É curioso que essa idéia tenha surgido durante a Segunda Guerra Mundial, quando Osborne comandou um dos navios da caravana de carga americana, que estava em perigo de um ataque de torpedo por um submarino alemão. Então o capitão lembrou-se do truque que os piratas da Idade Média usavam: se a equipe estivesse com problemas, todos os marinheiros se reuniam no convés para propor alternadamente uma maneira de resolver o problema. Havia muitas idéias, inclusive absurdas à primeira vista: por exemplo, a idéia de explodir um torpedo como um time inteiro. Mas com um jato da bomba de um navio, disponível em todos os navios, é bem possível desacelerar o torpedo ou até mudar de rumo. Como resultado, Osborne até patenteou a invenção: um parafuso adicional é montado a bordo do navio, o que leva uma corrente de água ao longo do lado, e o torpedo desliza nas proximidades ".
Nosso Jim repete constantemente que em uma organização aberta não é tão fácil trabalhar. Até a gerência entende, porque ninguém é poupado da necessidade de defender sua opinião. Mas apenas essa abordagem é necessária para obter um excelente resultado:
“Fóruns on-line [de desenvolvedores de código aberto] e bate-papos geralmente são preenchidos com discussões animadas e às vezes mordazes sobre tudo - desde a melhor forma de corrigir um bug no software e terminar com quais novos recursos devem ser considerados na próxima atualização. Como regra, esta é a primeira fase das discussões, durante a qual novas idéias são apresentadas e acumuladas, mas a próxima rodada sempre ocorre - uma análise crítica. Embora todos possam participar dessas disputas, uma pessoa precisa estar preparada para defender sua posição com todas as suas forças. Idéias impopulares são rejeitadas na melhor das hipóteses, e na pior das hipóteses - ridicularizadas.
Até Linus Torvalds, criador do sistema operacional Linux, discorda das 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 benefícios das alterações de código solicitadas pela Red Hat, o que ajudaria a garantir a segurança de nossos clientes. Em resposta ao pedido de Howells, Torvalds escreveu: “Francamente, essa [palavra imprimível] é idiotice. Tudo parece girar em torno dessas interfaces estúpidas e por razões completamente idiotas. Por que devemos fazer isso? Não gosto mais do analisador X.509 existente. As interfaces complexas idiotas estão sendo criadas, e agora haverá 11. - Linus 9 ”.
Deixando de lado os detalhes técnicos, Torvalds, no próximo post, continuou escrevendo da mesma maneira - e de modo que não me arriscaria a citar. Esse debate trovejou tão alto que chegou às páginas do The Wall Street Journal. [...]
Esse debate mostra que, na maioria das empresas que produzem software proprietário, não há um debate aberto sobre quais novos recursos ou alterações eles podem 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 exatamente quais mudanças são necessárias e, o mais importante, por que são necessárias, não cessam. Isso, é claro, torna todo o processo muito mais confuso e demorado ".
Solte cedo, solte frequentemente
Como não podemos prever o futuro, precisamos apenas tentar:
"Atuamos 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. Obviamente, quanto mais alterações e atualizações forem coletadas em uma versão (versão) do software, maior a probabilidade de que haja erros nessa versão. Os desenvolvedores de software de código aberto perceberam: com o lançamento rápido e frequente de versões de software, o risco de problemas sérios em qualquer programa é reduzido - porque não trazemos todas as atualizações imediatamente para o mercado, mas em partes para cada versão. Com o tempo, percebemos que essa abordagem não apenas reduz o número de erros, mas também leva a soluções mais interessantes. Acontece que fazer pequenas melhorias continuamente cria mais inovação. Talvez não haja nada de surpreendente aqui. Um dos princípios fundamentais dos processos de fabricação modernos, como o kaizen a ou lean b, é o foco em pequenas e graduais mudanças e atualizações.
[...] Muito do que estamos trabalhando pode não ter sucesso. Mas, em vez de perder muito tempo tentando entender o que funciona e o que não funciona, preferimos fazer pequenas experiências. As idéias mais populares levarão ao sucesso, e as que não funcionam desaparecerão por si mesmas. Assim, podemos tentar muito, e não apenas uma coisa, e sem muito risco para a empresa.
Essa é uma maneira racional de alocar recursos. Por exemplo, as pessoas costumam me perguntar como escolhemos quais projetos de código aberto devem ser comercializados. Embora às vezes iniciemos projetos, na maioria das vezes nos conectamos aos já existentes. Um pequeno grupo de engenheiros - e às vezes até uma pessoa - começa a contribuir para um dos projetos comunitários 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 estão mudando para um novo projeto. Quando decidirmos comercializar a proposta, o projeto poderá crescer a tal ponto que a solução seja óbvia. Uma grande variedade de projetos, incluindo aqueles não relacionados ao software, surge naturalmente em toda a Red Hat, até ficar claro para todos que agora alguém terá que trabalhar com ele o tempo todo. ”
Aqui está outra citação do livro:
“Percebi que, para cumprir esse papel, os líderes de amanhã devem ter características que simplesmente não são prestadas atenção nas organizações comuns. Para gerenciar efetivamente uma organização aberta, o líder deve possuir as seguintes qualidades.
- Força e confiança pessoais. Os líderes comuns usam o poder posicional - sua posição - para ter sucesso. Mas com a meritocracia, os líderes devem ganhar respeito. E isso só é possível se eles não tiverem medo de admitir que não têm respostas para todas as perguntas. Eles devem estar preparados para discutir problemas e tomar decisões rápidas, a fim de encontrar as melhores soluções em conjunto com sua equipe.
- Paciência. A mídia raramente conta histórias sobre o quão "paciente" o líder é. Mas ele realmente tem que ser paciente. Quando você trabalha para obter o máximo de esforço e resultados da sua equipe, passe horas conversando e repetindo algo repetidamente até que tudo seja feito corretamente - você precisa ser paciente.
- Alto QE (inteligência emocional). Com muita frequência, anunciamos as habilidades intelectuais dos executivos, concentrando-nos em seu QI, quando, na realidade, sua razão de inteligência emocional, ou EQ, precisa ser levada em consideração. Ser a pessoa mais inteligente entre outras pessoas não é suficiente se você não conseguir trabalhar com essas pessoas. Quando você trabalha com comunidades de funcionários envolvidos, como a Red Hat, e não tem a capacidade de solicitar alguém, sua capacidade de ouvir, processar analiticamente e não levar tudo para sua conta se torna incrivelmente valiosa.
- Outra mentalidade. Os líderes que vieram de organizações tradicionais foram criados no espírito do quid pro quo (lat. “Serviço por serviço”), segundo o qual cada ação deveria receber um retorno adequado. Mas quando você vai investir na criação de uma determinada comunidade, pense a longo prazo. É como uma tentativa de construir um ecossistema finamente equilibrado, onde qualquer movimento errado pode criar um desequilíbrio e levar a perdas a longo prazo que você pode não perceber imediatamente. Os gerentes devem se livrar do tipo de pensamento que exige que eles alcancem resultados hoje e a qualquer custo, e começar a fazer negócios de modo a obter grandes benefícios por meio de investimentos no futuro. ”
E por que isso é importante
A Red Hat vive e trabalha com 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 espalhar os princípios de organização aberta entre empresas russas, entre pessoas que desejam e podem viver de maneira diferente.
Leia , experimente!