Chegou un día importante para Red Hat, a comunidade rusa de código aberto e todos os implicados: publicouse en ruso . Ela conta con detalle e vívidamente como en Red Hat damos o camiño ás mellores ideas e ás persoas máis talentosas, e tamén como non perderse no caos e unir a millóns de persoas en todo o mundo.
Este libro tamén trata sobre a vida e a práctica. Contén moitos consellos para quen queira aprender a construír unha empresa utilizando o modelo de organización aberta e xestionala de forma eficaz. A continuación móstranse algúns dos principios máis importantes que se dan no libro que podes tomar en conta agora mesmo.
O historial de emprego de Jim coa empresa é notable. Mostra que non hai fanfarria no mundo de código aberto, pero hai un novo enfoque para o liderado:
"Despois de falar co reclutador, expresei o meu interese nunha entrevista, e preguntou se me importaría voar á sede de Red Hat en Raleigh, Carolina do Norte, o domingo. Pensei que o domingo era un día raro para coñecer. Pero como o luns aínda ía voar a Nova York, en xeral estaba de camiño, e aceptei. Subín a un avión desde Atlanta e aterrei no aeroporto de Raleigh Durham. Desde alí, collín un taxi que me deixou diante do edificio Red Hat no campus da Universidade de Carolina do Norte. Era domingo, ás 9:30 horas, e non había ninguén. As luces estaban apagadas e ao comprobar que as portas estaban pechadas. Ao principio pensei que me estaban a enganar. Cando xirei para volver subir ao taxi, vin que xa saíra. Moi pronto comezou a chover, eu non tiña paraugas.
Xusto cando estaba a piques de ir a algún lugar para coller un taxi, Matthew Shulick, máis tarde presidente do consello de administración e CEO de Red Hat, parou no seu coche. "Ola", saudou. "Queres tomar un café?" Esta parecía unha forma inusual de comezar unha entrevista, pero sabía que definitivamente necesitaba tomar un café. En definitiva, pensei, sería máis fácil para min coller un taxi ata o aeroporto.
As mañás dos domingos son bastante tranquilas en Carolina do Norte. Levamos un tempo atopar unha cafetería que abriu antes do mediodía. A cafetería non era a mellor da cidade nin a máis limpa, pero funcionaba e alí podías tomar café recén feito. Sentámonos nunha mesa e comezamos a falar.
Despois duns trinta minutos máis ou menos decateime de que me gustaba como estaban as cousas; A entrevista non era tradicional, pero a conversa en si resultou moi interesante. En lugar de discutir os puntos máis finos da estratexia corporativa de Red Hat ou da súa imaxe en Wall Street, algo para o que tiña preparado, Matthew Shulick preguntou máis sobre as miñas esperanzas, soños e obxectivos. Agora está claro para min que Shulik estaba a avaliar se me axustaría á subcultura e ao estilo de xestión da empresa.
Despois de que rematamos, Shulick dixo que quería presentarme ao conselleiro xeral da compañía, Michael Cunningham, e suxeriu que me reunise con el agora para xantar cedo. Aceptei e preparámonos para marchar. Entón o meu interlocutor descubriu que non levaba a carteira con el. "Vaia", dixo. - Non teño cartos. E ti?" Isto colleume por sorpresa, pero respondín que tiña cartos e que non me importaba pagar o café.
Uns minutos despois, Shulik deixoume nun pequeno restaurante mexicano, onde coñecín a Michael Cunningham. Pero de novo, non seguiu ningunha entrevista ou reunión de negocios tradicional, senón que tivo lugar outra conversación interesante. Cando estabamos a piques de pagar a factura, resultou que a máquina da tarxeta de crédito do restaurante estaba rota e só podíamos aceptar diñeiro en efectivo. Cunningham volveuse cara min e preguntou se estaba preparado para pagar, porque non tiña cartos con el. Xa que ía a Nova York, tiña moitos cartos, así que paguei o xantar.
Cunningham ofreceuse a levarme ata o aeroporto e fomos no seu coche. Despois duns minutos, preguntou: "¿Importache que me paro e me gaste? Seguiremos a todo vapor". "Non hai problema", respondín. En canto escoitei o son rítmico da bomba, bateu na fiestra. Foi Cunningham. "Oe, aquí non levan tarxetas de crédito", dixo. "Podo pedir un diñeiro prestado?" Comecei a preguntarme se isto era realmente unha entrevista ou algún tipo de estafa.
Ao día seguinte, mentres estaba en Nova York, comentei esta entrevista coa miña muller en Red Hat. Díxenlle que a conversación era moi interesante, pero non estaba seguro de se esta xente se tomaba en serio contratarme: quizais só querían comida e gasolina gratis? Recordando aquela reunión de hoxe, entendo que Shulick e Cunningham eran simplemente persoas abertas e tratáronme como a calquera outra persoa coa que puidesen tomar un café, xantar ou encher gasolina. Si, é gracioso e mesmo curioso que ambos acabaron sen cartos. Pero para eles non se trataba do diñeiro. Eles, como o mundo de código aberto, non crían en tirar alfombras vermellas nin tentar convencer aos demais de que todo era perfecto. Só intentaban coñecerme mellor, non intentando impresionar nin sinalar as nosas diferenzas. Querían saber quen era eu.
A miña primeira entrevista en Red Hat mostroume claramente que o traballo aquí era diferente. Esta empresa non tiña unha xerarquía tradicional e un trato especial para os directivos, polo menos na forma habitual na maioría das outras empresas. Co paso do tempo, tamén souben que Red Hat cre no principio da meritocracia: sempre paga a pena intentar poñer en práctica a mellor idea, independentemente de que proceda da alta dirección ou dun pasante de verán. Noutras palabras, a miña primeira experiencia en Red Hat presentoume como é o futuro do liderado".
Consellos para cultivar a meritocracia
A meritocracia é o valor fundamental da comunidade de código aberto. Non nos importa o nivel da pirámide que ocupas, o principal é o boas que son as túas ideas. Isto é o que suxire Jim:
- Nunca digas: "Iso é o que quere o xefe" e non te basees na xerarquía. Isto pode axudarche a curto prazo, pero non é así como constrúes unha meritocracia.
- Recoñecer publicamente os éxitos e as contribucións importantes. Este pode ser un simple correo electrónico de agradecemento con todo o equipo copiado.
- Considere: a súa autoridade é unha función da súa posición na xerarquía (ou o acceso a información privilexiada), ou é o resultado do respecto que gañou? Se é o primeiro, comeza a traballar no segundo.
- Solicita comentarios e recolle ideas sobre un tema específico. Deberías reaccionar a todo, probar só o mellor. Pero non te limites a tomar as mellores ideas e seguir adiante con elas: aproveita todas as oportunidades para fortalecer o espírito de meritocracia, dándolle crédito a todos os que o merecen.
- Recoñece a un membro exemplar do teu equipo ofrecéndolle unha tarefa interesante, aínda que non estea no seu ámbito de traballo habitual.
Deixa que as túas estrelas de rock sigan a súa paixón
Entusiasmo e implicación son dúas palabras moi importantes nunha organización aberta. Repítense constantemente no libro. Pero non podes conseguir que persoas creativas apaixonadas traballen duro, non? Se non, simplemente non obterás todo o que o seu talento ten para ofrecer. En Red Hat, os obstáculos para os seus propios proxectos líxanse o máximo posible:
“Para impulsar a innovación, as empresas intentan moitas cousas. O enfoque de Google é interesante. Desde que Google se coñeceu en todos os fogares en 2004, directivos e ideólogos do negocio de Internet intentaron desvelar o segredo principal da compañía para repetir o seu impresionante éxito. Un dos programas máis famosos, pero actualmente pechado, foi que se pedía a todos os empregados de Google que dedicasen o 20 por cento do seu tempo a case todo o que quixesen. A idea era que se os empregados perseguían os seus propios proxectos e ideas que lles apaixonasen fóra do traballo, comezarían a innovar. Así xurdiron os proxectos de terceiros exitosos: GoogleSuggest, AdSense for Content e Orkut; todos proviñan deste experimento do 20 por cento: unha lista impresionante! […]
En Red Hat adoptamos un enfoque menos formal. Non temos unha política establecida sobre canto tempo debe dedicar cada un dos nosos empregados á "innovación". En lugar de darlle tempo dedicado á xente a educarse, asegurámonos de que os empregados gañen o dereito a dedicar o seu tempo a aprender cousas novas. Sinceramente, moitas persoas teñen moi pouco tempo, pero tamén hai quen pode dedicar case toda a súa xornada laboral á innovación.
O caso máis típico é algo así: alguén traballa nun proxecto paralelo (se lles explica a súa importancia aos xestores -directamente no lugar de traballo; ou en horas non laborables - por iniciativa propia), e despois este traballo pode ocupar todo o as súas horas actuais”.
Máis que brainstorming
“Digresión lírica. Alex Fakeney Osborne é o inventor do método brainstorming, unha continuación do cal hoxe é o método sinéctico. É curioso que esta idea xurdiu durante a Segunda Guerra Mundial, cando Osborne comandaba un dos barcos dun convoi de carga americano que corría perigo dun ataque de torpedos por parte dun submarino alemán. Entón o capitán lembrou unha técnica á que recorreban os piratas da Idade Media: se a tripulación se meteba en problemas, todos os mariñeiros reuníanse na cuberta para suxerir por quendas unha forma de solucionar o problema. Houbo moitas ideas, incluídas as absurdas a primeira vista: por exemplo, a idea de soprar un torpedo con todo o equipo. Pero co chorro da bomba dun barco, que está dispoñible en todos os barcos, é moi posible frear un torpedo ou incluso cambiar o seu rumbo. Como resultado, Osborne mesmo patentou un invento: unha hélice adicional está montada no costado do barco, que impulsa unha corrente de auga ao longo do lado, e o torpedo deslízase ao lado.
O noso Jim repite constantemente que non é tan fácil traballar nunha organización aberta. Incluso a dirección o consegue, xa que a ninguén se lle escatima a necesidade de defender a súa opinión. Pero este é exactamente o enfoque necesario para lograr excelentes resultados:
"Os foros e salas de chat en liña [de código aberto] adoitan estar cheos de discusións animadas e ás veces agrias sobre todo, desde a mellor forma de corrixir un erro de software ata cales son as novas funcións que se deben considerar na próxima actualización. Como regra xeral, esta é a primeira fase de discusións, durante a cal se presentan e acumulan novas ideas, pero sempre hai unha seguinte rolda: análise crítica. Aínda que calquera pode participar nestes debates, unha persoa debe estar preparada para defender a súa posición con todas as súas forzas. As ideas impopulares serán rexeitadas no mellor dos casos, ridiculizadas no peor.
Incluso Linus Torvalds, o creador do sistema operativo Linux, expresa o seu desacordo coas modificacións propostas no código. Un día, Linus e David Howells, un dos principais desenvolvedores de Red Hat, entraron nun acalorado debate sobre os méritos dun cambio de código que Red Hat solicitara para axudar a proporcionar seguridade aos nosos clientes. En resposta á petición de Howells, Torvalds escribiu: "Francamente, isto é [palabra non imprimible] idiota. Todo parece xirar arredor destas estúpidas interfaces, e por razóns completamente estúpidas. Por que debemos facer isto? Xa non me gusta o analizador X.509 existente. Estase creando interfaces complexas estúpidas e agora haberá 11 delas. - Linus 9".
Deixando os detalles técnicos a un lado, Torvalds continuou escribindo co mesmo espírito na seguinte mensaxe -e de tal xeito que non me atrevo a citar-. Esta disputa foi tan forte que incluso chegou ás páxinas de The Wall Street Journal. […]
Este debate mostra que a maioría das empresas que producen software privativo e non libre non teñen un debate aberto sobre cales son as novas funcións ou cambios nas que poderían estar traballando. Cando o produto está listo, a empresa simplemente envíallo aos clientes e segue adiante. Ao mesmo tempo, no caso de Linux, as discusións sobre que cambios son necesarios e, o máis importante, por que son necesarios, non ceden. Isto, por suposto, fai que todo o proceso sexa moito máis desordenado e lento".
Soltar cedo, soltar a miúdo
Non podemos predecir o futuro, así que só temos que probar:
"Operamos co principio de "lanzamento anticipado, actualizacións frecuentes". O problema clave de calquera proxecto de software é o risco de erros ou erros no código fonte. Obviamente, cantos máis cambios e actualizacións se recollan nunha versión (versión) de software, maior é a probabilidade de que haxa erros nesta versión. Os desenvolvedores de software de código aberto decatáronse de que ao lanzar versións de software de forma rápida e frecuente, redúcese o risco de problemas graves con calquera programa; despois de todo, non levamos ao mercado todas as actualizacións á vez, senón unha por vez para cada versión. Co paso do tempo, observamos que este enfoque non só reduce os erros, senón que tamén leva a solucións máis interesantes. Resulta que facer continuamente pequenas melloras crea máis innovación a longo prazo. Quizais non haxa nada sorprendente aquí. Un dos principios fundamentais dos procesos de fabricación modernos como kaizen a ou lean b é centrarse nos cambios e actualizacións pequenos e incrementais.
[…] É posible que gran parte do que traballamos non teña éxito. Pero en lugar de pasar moito tempo preguntándonos que funcionará e que non, preferimos realizar pequenos experimentos. As ideas máis populares levarán ao éxito, e as que non funcionan desaparecerán por si mesmas. Deste xeito podemos probar moitas cousas e non só unha, sen moito risco para a empresa.
Esta é unha forma racional de asignar recursos. Por exemplo, moitas veces a xente pregúntame como eliximos que proxectos de código aberto queremos comercializar. Aínda que ás veces iniciamos proxectos, a maioría das veces simplemente saltamos aos existentes. Un pequeno grupo de enxeñeiros, ás veces só unha persoa, comeza a contribuír a un dos proxectos da comunidade de código aberto. Se o proxecto é exitoso e demandado entre os nosos clientes, comezamos a dedicarlle máis tempo e esforzo. Se non, os desenvolvedores pasan a un novo proxecto. No momento en que decidimos comercializar a proposta, o proxecto pode ter medrado ata tal punto que a solución é obvia. Varios proxectos, incluídos os que non son de software, xorden naturalmente en Red Hat ata que todos quede claro que agora alguén terá que traballar nisto a tempo completo".
Aquí tes outra cita do libro:
“Decateime de que para cumprir este papel, os líderes de mañá deben ter características que simplemente se pasan por alto nas organizacións convencionais. Para liderar eficazmente unha organización aberta, un líder debe ter as seguintes calidades.
- Forza e confianza persoal. Os líderes comúns usan o poder posicional -a súa posición- para acadar o éxito. Pero nunha meritocracia, os líderes deben gañarse respecto. E isto só é posible se non teñen medo de admitir que non teñen todas as respostas. Deben estar dispostos a discutir problemas e tomar decisións rapidamente para atopar as mellores solucións co seu equipo.
- Paciencia. Os medios raramente contan historias sobre o "paciente" que é un líder. Pero realmente debe ser paciente. Cando estás a traballar para obter o mellor esforzo e os mellores resultados do teu equipo, tendo conversas durante horas e repetindo as cousas unha e outra vez ata que se faga ben, debes ter paciencia.
- Alta EQ (intelixencia emocional). Con demasiada frecuencia promovemos a intelixencia dos líderes centrándonos no seu coeficiente intelectual, cando o que realmente hai que ter en conta é o seu cociente de intelixencia emocional, ou puntuación de EQ. Ser a persoa máis intelixente entre outras non é suficiente se non es capaz de traballar con esas persoas. Cando traballas con comunidades de empregados comprometidos como Red Hat, e non tes a capacidade de encargar a ninguén, a túa capacidade de escoitar, procesar analíticamente e non tomar as cousas persoalmente tórnase moi valiosa.
- Mentalidade diferente. Os líderes que proviñan de organizacións tradicionais foron educados co espírito de quid pro quo (en latín "quid pro quo"), segundo o cal cada acción debería recibir un retorno adecuado. Pero cando buscas investir na construción dunha comunidade en particular, debes pensar a longo prazo. É como tentar construír un ecosistema delicadamente equilibrado, onde calquera paso equivocado pode crear un desequilibrio e levar a perdas a longo prazo que quizais non notes de inmediato. Os líderes deben desfacerse da mentalidade que lles obriga a acadar resultados hoxe, a calquera prezo, e comezar a facer negocios de forma que lles permita obter maiores beneficios investindo no futuro”.
E por que é importante
Red Hat vive e opera con principios moi diferentes dunha organización xerárquica tradicional. E funciona, fainos exitosos comercialmente e humanamente felices. Traducimos este libro coa esperanza de difundir os principios da organización aberta entre as empresas rusas, entre as persoas que queren e poden vivir doutro xeito.
, próbao!
Fonte: www.habr.com