È arrivato un giorno importante per Red Hat, la comunità open source russa e tutti coloro che vi sono coinvolti: è stata pubblicata in russo . Racconta in dettaglio e in modo vivido come noi in Red Hat diamo strada alle idee migliori e alle persone più talentuose, e anche come non perdere la rotta nel caos e unire milioni di persone in tutto il mondo.
Inoltre, questo libro parla di vita e di pratica. Contiene molti consigli per chiunque voglia imparare a costruire un'azienda secondo il modello dell'organizzazione aperta e guidarla in modo efficace. Di seguito, alcuni dei principi più importanti presentati nel libro, che puoi prendere in considerazione già da ora.
La storia dell'assunzione di Jim nella società è notevole. Mostra che nel mondo del codice aperto non ci sono fanfare, ma un nuovo approccio alla leadership:
«Dopo aver parlato con il reclutatore, ho espresso interesse per un colloquio, e lui mi ha chiesto se avrei avuto qualcosa in contrario a volare domenica alla sede centrale di Red Hat a Raleigh, Carolina del Nord. Ho pensato che la domenica fosse un giorno strano per un incontro. Ma poiché comunque dovevo volare a New York lunedì, alla fine era sulla mia strada, quindi ho acconsentito. Sono salito su un aereo ad Atlanta e sono atterrato all'aeroporto di Raleigh-Durham. Da lì ho preso un taxi che mi ha lasciato davanti all'edificio di Red Hat nel campus dell'Università della Carolina del Nord. Era domenica, le 9:30 del mattino, e non c'era nessuno nei dintorni. La luce era spenta e, controllando, ho scoperto che le porte erano bloccate. All'inizio ho pensato che mi stessero prendendo in giro. Voltandomi per tornare al taxi, ho visto che era già andato via. Molto presto è iniziato a piovere, e non avevo l'ombrello.
Proprio quando stavo per andare da qualche parte a cercare un taxi, Matthew Shulik, poi presidente del consiglio di amministrazione e CEO di Red Hat, è arrivato con la sua macchina. «Ciao, – ha detto. – Vuoi prendere un caffè?» Mi è sembrato un inizio strano per un colloquio, ma sapevo che avevo decisamente bisogno di un caffè. Alla fine, pensai, sarà più facile prendere un taxi per l'aeroporto dopo.
La domenica in Carolina del Nord è piuttosto tranquilla al mattino. Ci è voluto un po' di tempo per trovare una caffetteria che aprisse prima di mezzogiorno. La caffetteria non era la migliore in città e non era la più pulita, ma era aperta e si poteva bere caffè fresco. Ci siamo seduti a un tavolo e abbiamo iniziato a chiacchierare.
Dopo circa trenta minuti, ho capito che mi piaceva come procedeva tutto; il colloquio non era tradizionale, ma la conversazione era stata molto interessante. Invece di discutere i dettagli della strategia aziendale di Red Hat o la sua immagine su Wall Street – ovvero di ciò per cui mi ero preparato – Matthew Shulik mi ha chiesto di più riguardo alle mie speranze, sogni e obiettivi. Ora è chiaro che Shulik stava valutando se sarei stato in grado di integrarmi nella sottocultura e nello stile di gestione dell'azienda.
Dopo aver terminato, Shulik ha detto che voleva presentarmi al chief legal officer dell'azienda, Michael Cunningham, e ha proposto di incontrarlo subito, per un pranzo anticipato. Ho accettato e ci siamo preparati a partire. Poi il mio interlocutore ha scoperto di non avere il portafoglio con sé. "Ups," ha detto. "Non ho soldi. E tu?" Questo mi ha colto di sorpresa, ma ho risposto che avevo dei soldi e non mi dispiaceva pagare per il caffè.
Pochi minuti dopo, Shulik mi ha lasciato in una piccola taqueria messicana, dove ho incontrato Michael Cunningham. Ma non ci sono stati colloqui tradizionali o incontri di lavoro, solo un'altra conversazione interessante. Quando ci siamo apprestati a pagare il conto, è emerso che il terminale per il pagamento con carta di credito del ristorante era rotto e potevamo pagare solo in contante. Cunningham si è rivolto a me e ha chiesto se ero disposto a pagare, perché non aveva contante con sé. Poiché stavo per andare a New York, avevo molti contanti, quindi ho pagato il pranzo.
Cunningham mi ha offerto di accompagnarmi all'aeroporto, e siamo partiti con la sua auto. Dopo qualche minuto ha chiesto: «Ti dispiace se mi fermo a fare rifornimento? Andremo a tutta velocità». – «Nessun problema», ho risposto. Non appena ho sentito il ritmo regolare della pompa, ho sentito un colpo al finestrino. Era Cunningham. «Ehi, qui non accettano carte di credito», mi ha detto. – «Posso prendere in prestito un po' di soldi?» Ho iniziato a chiedermi se fosse davvero un colloquio o qualche truffa.
Il giorno successivo, mentre mi trovavo a New York, ho discusso con mia moglie di questo colloquio presso la Red Hat. Le ho detto che la conversazione è stata molto interessante, ma non sono sicuro che queste persone intendano davvero assumermi: forse avevano solo bisogno di cibo e benzina gratis? Ripensando oggi a quell'incontro, capisco che Shulik e Cunningham erano semplicemente persone aperte e mi trattavano come qualsiasi altra persona con cui potessero bere un caffè, pranzare o fare rifornimento. Sì, è divertente e persino buffo che entrambi fossero senza soldi. Ma per loro non si trattava di soldi. Come il mondo intorno all'open source, non credevano nell'estendere tappeti rossi o nel cercare di convincere l'interlocutore che tutto fosse perfetto. Volevano semplicemente conoscermi meglio, senza tentare di impressionarmi o di mettere in evidenza le nostre differenze. Volevano sapere chi fossi.
Il mio primo colloquio presso Red Hat mi ha mostrato chiaramente che lavorare qui è diverso. In questa azienda non c'era la tradizionale gerarchia e un particolare regime per i dirigenti, almeno nella misura in cui è consueto nella maggior parte delle altre aziende. Col passare del tempo ho anche scoperto che Red Hat crede nel principio della meritocrazia: vale sempre la pena cercare di realizzare la migliore delle idee, indipendentemente da chi provenga, sia essa da un alto dirigente o da uno stagista assunto per un lavoro estivo. In altre parole, la mia prima impressione di Red Hat mi ha presentato come sarà il futuro della leadership.
Consigli per coltivare la meritocrazia
La meritocrazia è il valore fondamentale della comunità open source. Non ci interessa quale livello della piramide occupi, ciò che conta sono le tue idee. Ecco cosa propone Jim:
- Non dire mai: «Lo vuole il capo» e non fare affidamento sulla gerarchia. Questo può aiutarti a breve termine, ma non costruirai una meritocrazia in questo modo.
- Riconosci pubblicamente i successi e i contributi importanti al lavoro comune. Può essere una semplice email di ringraziamento, con tutta la squadra in copia.
- Pensa: la tua autorità dipende dalla posizione nella gerarchia (o dall'accesso a informazioni privilegiate) o è il risultato del rispetto che hai guadagnato? Se è la prima, inizia a lavorare sulla seconda.
- Chiedi feedback e raccogli idee su un tema specifico. Rispondi a tutto, sperimenta solo le migliori. Ma non prendere semplicemente le migliori idee e andare avanti con esse: usa ogni opportunità per rafforzare lo spirito della meritocrazia, riconoscendo tutti coloro che lo meritano.
- Segnala un membro esemplare della tua squadra offrendo un compito interessante, anche se non è pertinente al suo campo abituale.
Fai seguire le tue «rock star» dalla loro passione.
Entusiasmo e coinvolgimento sono due parole molto importanti in un'organizzazione aperta. Nel libro vengono ripetute costantemente. Ma non puoi costringere persone creative e appassionate a lavorare «dall'inizio alla fine», giusto? Altrimenti, non otterrai tutto ciò che il loro talento può offrire. In Red Hat, gli ostacoli ai progetti personali vengono ridotti al minimo:
«Per gestire le innovazioni, le aziende provano molte cose. Interessante è l'approccio dell'azienda Google. Da quando Google, a partire dal 2004, è diventata nota in ogni casa, leader e ideologi nel settore internet hanno cercato di decifrare il segreto principale dell'azienda per replicarne il successo straordinario. Uno dei programmi più noti, ma attualmente chiusi, consisteva nel permettere a tutti i dipendenti di Google di dedicare il 20% del loro tempo lavorativo praticamente a qualsiasi cosa ritenessero opportuno. L'idea era: se i dipendenti iniziano a realizzare i propri progetti e idee di cui sono appassionati oltre al lavoro, inizieranno a creare innovazioni. Così sono nati progetti esterni di successo: GoogleSuggest, AdSense for Content e Orkut; tutti sono emersi da questo esperimento del 20% – un elenco impressionante! [...]
In Red Hat adottiamo un approccio meno formale. Non abbiamo una politica stabilita su quanto tempo ogni dipendente debba dedicare all'«innovazione». Invece di riservare del tempo separato per l'autoformazione, facciamo in modo che i dipendenti guadagnino il diritto di dedicare il proprio tempo a nuove idee. A dire il vero, molti hanno poco tempo a disposizione, ma ci sono anche coloro che possono dedicare quasi tutta la giornata lavorativa all'innovazione.
Il caso più comune appare così: qualcuno lavora a un progetto esterno (se ha spiegato ai manager la sua importanza – direttamente sul posto di lavoro; oppure nel tempo libero – per iniziativa personale), e successivamente questo lavoro può occupare tutte le sue ore lavorative.
Più di un brainstorming
«Una digressione lirica. Alex Făykni Osborn è l'inventore del metodo del
Il nostro Jim ripete continuamente che lavorare in un'organizzazione aperta non è affatto semplice. Anche i dirigenti ne risentono, poiché nessuno è esente dall'obbligo di difendere la propria opinione. Ma proprio questo approccio è necessario per ottenere risultati eccellenti:
«Forum online [di sviluppatori open source] e chat sono spesso pieni di discussioni vivaci, a volte anche pungenti, su tutto – da come correggere al meglio un errore nel software, a quali nuove funzionalità dovrebbero essere considerate nel prossimo aggiornamento. Di solito, questa è la prima fase delle discussioni, in cui nuove idee vengono avanzate e accumulate, ma c'è sempre un giro successivo – l'analisi critica. Anche se chiunque può partecipare a queste controversie, una persona deve essere pronta a difendere la propria posizione con tutte le forze. Le idee impopolari verranno scartate nel migliore dei casi, nel peggiore – derise.
Anche Linus Torvalds, il creatore del sistema operativo Linux, esprime il proprio disaccordo con le modifiche proposte al codice. Una volta, Linus e David Howells, uno dei principali sviluppatori della Red Hat, sono entrati in una animata polemica riguardo ai vantaggi di una modifica al codice richiesta dalla Red Hat, che avrebbe aiutato a garantire la sicurezza ai nostri clienti. In risposta alla richiesta di Howells, Torvalds scrisse: «Francamente, è un [parola inappropriata] idiozia. Tutto sembra ruotare attorno a queste interfacce stupide, e per motivi completamente idioti. Perché dovremmo farlo? Non mi piace l'attuale parser X.509. Si stanno creando interfacce complessamente stupide, e ora saranno 11. – Linus 9».
Lasciando da parte i dettagli tecnici, Torvalds continuò a scrivere nel suo messaggio successivo sullo stesso tema – in modo tale che non oso citare. Questo dibattito ha fatto rumore a tal punto che è finito anche sulle pagine del The Wall Street Journal. […]
Questo dibattito mostra che nella maggior parte delle aziende che producono software proprietario e non libero non ci sono dibattiti aperti su quali nuove caratteristiche o modifiche potrebbero essere lavorate. Quando il prodotto è pronto, l'azienda lo invia semplicemente ai clienti e va avanti. Allo stesso tempo, nel caso di Linux, le discussioni su quali modifiche siano necessarie e – soprattutto – perché siano necessarie non si placano. Questo, ovviamente, rende il processo molto più disordinato e laborioso».
Rilascia presto, rilascia spesso
Non possiamo prevedere il futuro, quindi dobbiamo semplicemente provare:
«Agiamo secondo il principio di "lancio anticipato, aggiornamenti frequenti". Il problema principale di qualsiasi progetto software è il rischio di errori o bug nel codice sorgente. È evidente che quanto più cambiamenti e aggiornamenti vengono accumulati in una singola versione del software, maggiore è la probabilità che in quella versione ci siano bug. Gli sviluppatori di software open source hanno capito che con rilasci rapidi e frequenti di versioni, si riduce il rischio di gravi problemi con qualsiasi programma: non portiamo sul mercato tutti gli aggiornamenti contemporaneamente, ma in porzioni per ciascuna versione. Nel tempo, abbiamo notato che questo approccio non solo riduce il numero di errori, ma porta anche a soluzioni più interessanti. Si scopre che l'introduzione costante di piccoli miglioramenti alla fine genera più innovazione. Forse non c'è nulla di sorprendente in questo. Uno dei principi chiave dei moderni processi produttivi, come kaizen o lean, è la concentrazione su piccole e graduali modifiche e aggiornamenti.
[…] Molto di ciò su cui stiamo lavorando potrebbe non avere successo. Ma invece di perdere tempo cercando di capire cosa funzionerà e cosa no, preferiamo condurre piccoli esperimenti. Le idee più richieste porteranno al successo, mentre quelle che non funzioneranno svaniranno da sole. In questo modo possiamo provare molte cose, e non una sola, senza un rischio significativo per l'azienda.
Questo è un modo razionale per distribuire le risorse. Ad esempio, la gente mi chiede spesso come scegliamo quali progetti open source commercializzare. Sebbene talvolta iniziamo progetti, più spesso ci uniamo a quelli già esistenti. Un piccolo gruppo di ingegneri – a volte anche una sola persona – inizia a contribuire a uno dei progetti della comunità open source. Se il progetto ha successo e riscontra interesse da parte dei nostri clienti, iniziamo a investire più tempo e risorse. In caso contrario, gli sviluppatori passano a un nuovo progetto. Quando decidiamo di commercializzare un'offerta, il progetto potrebbe già essersi evoluto a tal punto da rendere la decisione ovvia. I più svariati progetti, anche quelli non legati al software, sorgono naturalmented all'interno dell'azienda Red Hat, fino a quando diventa chiaro a tutti che qualcuno dovrà lavorarci continuamente.
Ecco un'altra citazione dal libro:
«Ho realizzato che per ricoprire questo tipo di ruolo, i leader del domani devono possedere caratteristiche che nelle organizzazioni tradizionali spesso non vengono notate. Per guidare efficacemente un'organizzazione aperta, un leader deve possedere le seguenti qualità.
- Forza personale e fiducia. I leader tradizionali usano il potere posizionale – la loro posizione – per avere successo. Ma in un sistema meritocratico, i leader devono guadagnarsi il rispetto. E questo è possibile solo se non hanno paura di ammettere che non hanno risposte a tutte le domande. Devono essere pronti a discutere i problemi e a prendere decisioni rapide per trovare le migliori soluzioni insieme al loro team.
- Pazienza. I media raramente raccontano storie su quanto un leader sia «paziente». Ma deve davvero esserlo. Quando lavori per ottenere il massimo impegno e risultati dal tuo team, conversando per ore e ripetendo le cose più e più volte finché tutto non è fatto per bene, devi avere pazienza.
- Elevato EQ (intelligenza emotiva). Troppo spesso promuoviamo le capacità intellettuali dei leader, concentrandoci sul loro QI, quando in realtà è necessario considerare il loro coefficiente di intelligenza emotiva, o valutazione EQ. Essere la persona più intelligente tra gli altri non è sufficiente se non si è in grado di lavorare con queste persone. Quando si lavora con comunità di dipendenti coinvolti, come in Red Hat, e non si ha la possibilità di comandare nessuno, la capacità di ascoltare, elaborare analiticamente e non prendere tutto sul personale diventa incredibilmente preziosa.
- Un'altra mentalità. I leader provenienti da organizzazioni tradizionali sono stati educati nello spirito del quid pro quo, secondo cui ogni azione deve ricevere un adeguato ritorno. Ma quando si decide di investire nella creazione di una determinata comunità, bisogna pensare a lungo termine. È come cercare di costruire un'ecosistema finemente equilibrato, dove ogni passo falso può creare un disguido e portare a perdite a lungo termine che potrebbero non essere immediatamente visibili. I leader devono liberarsi di quel tipo di pensiero che richiede loro di ottenere risultati oggi e a tutti i costi, e iniziare a gestire in un modo che consenta di trarre maggiori benefici investendo nel futuro.
E perché è importante
Red Hat vive e lavora secondo principi che differiscono notevolmente da quelli di un'organizzazione tradizionale con gerarchie rigide. E questo funziona, ci rende commercialmente di successo e umanamente felici. Abbiamo tradotto questo libro con la speranza di diffondere i principi dell'organizzazione aperta tra le aziende russe, tra le persone che vogliono e possono vivere in modo diverso.
, prova!
Fonte: habr.com
