È un giorno importante per Red Hat, per la comunità open source russa e per tutti i coinvolti – è uscita in russo . Questo libro racconta in dettaglio e in modo vivace come in Red Hat diamo spazio alle migliori idee e ai talenti più brillanti, e offre anche spunti su come non perdersi nel caos e unire milioni di persone in tutto il mondo.
Inoltre, questo libro parla di vita e pratica. Contiene molti consigli per chi desidera imparare a costruire un'azienda secondo il modello dell'organizzazione aperta e a gestirla in modo efficace. Di seguito sono riportati alcuni principi fondamentali presentati nel libro che puoi prendere in considerazione subito.
La storia di assunzione di Jim in azienda è notevole. Dimostra che nel mondo del codice aperto non ci sono fanfare, ma esiste un nuovo approccio alla leadership:
«Dopo una conversazione con il reclutatore ho espresso interesse per un colloquio, e lui mi ha chiesto se avrei avuto problemi a volare domenica presso la sede di Red Hat a Raleigh, Carolina del Nord. Ho pensato che domenica fosse una giornata strana per un incontro. Ma visto che avrei comunque volato lunedì a New York, in un certo senso il viaggio non era un problema, e ho accettato. Sono salito su un aereo da Atlanta e sono atterrato all'aeroporto di Raleigh-Durham. Da lì ho preso un taxi che mi ha portato davanti all'edificio di Red Hat all'interno del campus dell'Università della Carolina del Nord. Era domenica, erano le 9:30 del mattino e non c'era nessuno nei dintorni. La luce era spenta e, controllando, ho scoperto che le porte erano chiuse. All'inizio ho pensato che stessero scherzando. Rivolgendomi per tornare al taxi, ho notato che era già andato via. Poco dopo ha iniziato a piovere e non avevo un ombrello.
Proprio quando stavo per andare da qualche parte a cercare un taxi, Matthew Szulik, poi presidente del consiglio di amministrazione e CEO di Red Hat, è arrivato con la sua auto. «Ciao», ha detto. «Vuoi prendere un caffè?» Mi è sembrato un inizio insolito per un colloquio, ma capivo che avevo bisogno di un caffè. Alla fine, ho pensato che sarebbe stato più facile prendere un taxi per l'aeroporto dopo.
Domenica mattina in Carolina del Nord è piuttosto tranquilla. Ci siamo voluti un po' di tempo solo per trovare una caffetteria aperta prima di mezzogiorno. La caffetteria non era la migliore in città e non era la più pulita, ma era aperta e si poteva bere un caffè fresco. Ci siamo seduti a un tavolo e abbiamo iniziato a chiacchierare.
Dopo circa trenta minuti, ho capito che mi piaceva come stavano andando le cose; il colloquio non era tradizionale, ma la conversazione si era rivelata molto interessante. Invece di discutere le sfumature della strategia aziendale di Red Hat o della sua immagine a Wall Street – ovvero di occuparmi di ciò per cui mi ero preparato – Matthew Szulik ha chiesto di più sulle mie speranze, sogni e obiettivi. Ora capisco che Szulik stava valutando se sarei stato adatto alla sottocultura e allo stile di gestione dell'azienda.
Dopo che abbiamo finito, Szulik ha detto che voleva presentarmi al consulente legale di Red Hat, Michael Cunningham, e ha proposto di incontrarlo subito per un pranzo anticipato. Ho accettato e ci siamo preparati a partire. Poi il mio interlocutore si è accorto di non avere il portafoglio con sé. «Ops», ha detto. «Non ho soldi. E tu?» Questa mi ha colto di sorpresa, ma ho risposto che avevo dei soldi e che non mi dispiaceva pagare per il caffè.
Dopo pochi minuti Szulik mi ha lasciato in un piccolo ristorante messicano, dove ho incontrato Michael Cunningham. Ma non ci sono stati colloqui tradizionali o incontri d'affari, ma è avvenuta un'altra interessante conversazione. Quando stavamo per pagare il conto, abbiamo scoperto che nel ristorante la macchina per il pagamento con carta di credito era rotta e potevamo pagare solo in contanti. Cunningham si è rivolto a me e ha chiesto se ero disposto a pagare, perché non aveva contante. Poiché stavo andando a New York, avevo molti contanti, quindi ho pagato il pranzo.
Cunningham ha offerto di accompagnarmi all'aeroporto e siamo partiti con la sua auto. Dopo qualche minuto ha chiesto: «Ti dispiace se ci fermiamo a fare rifornimento? Ci metteremo in cammino a tutta velocità». – «Nessun problema», ho risposto. Appena ho sentito il ritmo della pompa, qualcuno ha bussato al finestrino. Era Cunningham. «Ehi, qui non accettano carte di credito», ha detto. «Posso prendere in prestito un po' di soldi?» Ho iniziato a chiedermi se questo fosse davvero un colloquio o una truffa.
Il giorno successivo, mentre mi trovavo a New York, ho discusso con mia moglie questo colloquio in Red Hat. Le ho raccontato 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 chiunque altro con cui potessero prendere un caffè, pranzare o fare rifornimento. Sì, è divertente e persino buffo che entrambi si siano ritrovati senza soldi. Ma per loro non si trattava di denaro. Credevano, così come il mondo del software open source, che non fosse necessario srotolare tappeti rossi o cercare di convincere l'interlocutore che tutto fosse perfetto. Volevano solo conoscerci meglio, senza cercare di impressionarci o sottolineare le nostre differenze. Volevano sapere chi fossi.
Il mio primo colloquio in Red Hat mi ha mostrato in modo chiaro che lavorare qui è diverso. In questa azienda non esiste la tradizionale gerarchia e nemmeno un comportamento speciale per i dirigenti, almeno non come avviene nella maggior parte delle altre aziende. Col tempo ho anche scoperto che Red Hat crede nel principio della meritocrazia: vale sempre la pena tentare di realizzare la migliore delle idee, indipendentemente da chi la proponga, che sia un dirigente o uno stagista assunto per un lavoro estivo. In altre parole, la mia prima impressione di Red Hat mi ha introdotto a come sarà il futuro della leadership.
Suggerimenti per coltivare la meritocrazia
La meritocrazia è il valore fondamentale della comunità open source. Non ci interessa quale grado occupi nella piramide, ma quanto siano valide le tue idee. Ecco cosa propone Jim:
- Non dire mai: «Così vuole il capo» – e non fare affidamento sulla gerarchia. Questo può aiutarti a breve termine, ma non costruirai mai una meritocrazia in questo modo.
- Riconosci pubblicamente i successi e i contributi significativi al progetto comune. Può essere una semplice e-mail di ringraziamento, in copia a tutto il team.
- Riflettete: la vostra autorità dipende dalla vostra posizione gerarchica (o dall'accesso a informazioni privilegiate) oppure è il risultato del rispetto guadagnato? Se è la prima, inizia a lavorare sulla seconda.
- Chiedi feedback e raccogli idee su un tema specifico. È importante rispondere a tutti, sperimentando solo le migliori. Ma non limitarti a prendere le migliori idee e procedere con esse: sfrutta ogni opportunità per rafforzare lo spirito di meritocrazia, rendendo omaggio a chi lo merita.
- Riconosci un membro esemplare del tuo team offrendo un incarico interessante, anche se non rientra nel suo ambito di competenza abituale.
Lascia che le tue «rock star» seguano la propria passione.
Entusiasmo e coinvolgimento sono due parole molto importanti all'interno di un'organizzazione aperta. Nel libro, queste parole vengono ripetute costantemente. Ma non puoi costringere persone creative e appassionate a lavorare «dall'inizio alla fine», giusto? Altrimenti, non otterrai mai tutto ciò che il loro talento può offrire. In Red Hat gli ostacoli per i progetti personali sono minimizzati al massimo:
«Per gestire l'innovazione, le aziende provano molte cose. Interessante è l'approccio di Google. Dal 2004, da quando Google è diventata conosciuta in ogni casa, leader e ideologi nel business online hanno cercato di decifrare il segreto principale dell'azienda per replicarne il successo straordinario. Uno dei programmi più noti, ma attualmente chiuso, consisteva nell'offrire a tutti i dipendenti di Google di dedicare il 20% del loro tempo lavorativo a praticamente qualsiasi cosa volessero. L'idea era che se i dipendenti avessero l'opportunità di perseguire progetti e idee che li appassionano al di fuori del lavoro, avrebbero iniziato a generare innovazione. Così sono nati progetti di successo: GoogleSuggest, AdSense for Content e Orkut; tutti sono emersi da questo esperimento del 20% – un elenco impressionante! […]
In Red Hat non adottiamo un approccio così formale. Non abbiamo una politica stabilita su quanto tempo ogni nostro dipendente debba dedicare all'«innovazione». Invece di destinare tempo specifico all'autoformazione, facciamo in modo che i dipendenti guadagnino il diritto di dedicare il loro tempo a nuove idee. A dire il vero, molti di loro hanno poco tempo, mentre altri potrebbero dedicare quasi tutta la loro giornata lavorativa all'innovazione.
Il caso più tipico appare così: qualcuno lavora a un progetto esterno (se ha spiegato ai manager la sua importanza – proprio sul posto di lavoro; oppure nel tempo libero – per iniziativa personale), e in seguito questo lavoro può occupare tutte le sue ore di lavoro.
Più di un brainstorming
«Una digressione. Alex Faickney Osborn è l'inventore del metodo del "brainstorming", oggi evoluto nel metodo della sinettica. È curioso che quest'idea sia nata durante la Seconda guerra mondiale, quando Osborn comandava una delle navi di un convoglio americano sottoposto a un attacco di una sottomarina tedesca. In quel momento, il capitano ricordò una tecnica usata dai pirati medievali: se l'equipaggio si trovava in pericolo, tutti i marinai si riunivano sul ponte per proporre, a turno, una soluzione al problema. Le idee erano molto numerose, anche quelle che a prima vista sembravano assurde: per esempio, l'idea di soffiare sulla torpedine da tutta l'equipaggio. Ma la corrente d'acqua della pompa della nave, presente su ogni imbarcazione, può effettivamente rallentare o addirittura deviare una torpedine. Di conseguenza, Osborn brevettò anche l'invenzione: nel fianco della nave viene installada una vite aggiuntiva che spinge lungo il fianco un getto d'acqua, mentre la torpedine scivola al suo fianco.»
Il nostro Jim ripete costantemente che in un'organizzazione aperta non è affatto facile lavorare. Anche i dirigenti ne sono coinvolti, poiché nessuno è esente dall'obbligo di difendere la propria opinione. Ma è proprio questo approccio che è necessario per raggiungere risultati eccellenti:
«I forum online [degli sviluppatori di codice aperto] e le chat sono spesso pieni di dibattiti vivaci, e talvolta pungenti, su tutto: da come risolvere un errore nel software a quali nuove funzionalità considerare nel prossimo aggiornamento. Generalmente, questa è la prima fase dei dibattiti, durante la quale vengono avanzate e accumulate nuove idee, ma c'è sempre un successivo turno – l'analisi critica. Sebbene chiunque possa partecipare a queste discussioni, una persona deve essere pronta a difendere la propria posizione con tutte le proprie forze. Le idee impopolari vengono respinte nel migliore dei casi, nel peggiore vengono derise.
Anche Linus Torvalds, creatore del sistema operativo Linux, esprime il suo disaccordo con le modifiche proposte al codice. Una volta, Linus e David Howells, uno dei principali sviluppatori di Red Hat, hanno avuto un acceso dibattito sui benefici della modifica del codice richiesta da Red Hat, che avrebbe contribuito a garantire la sicurezza ai nostri clienti. In risposta alla richiesta di Howells, Torvalds scrisse: "Francamente, questo [parola inappropriata] è un’idiozia. Tutto sembra ruotare attorno a queste stupide interfacce, e per motivi completamente idioti. Perché dobbiamo farlo? Non mi piace già il parser X.509 esistente. Si creano interfacce ridicolmente complesse, e ora ne avranno 11. – Linus 9."
Lasciando da parte i dettagli tecnici, Torvalds proseguiva nel suo successivo messaggio con lo stesso spirito – e cose che non oserei citare. Questo dibattito è stato così forte da finire persino sulle pagine del Wall Street Journal. […]
Questo dibattito dimostra che nella maggior parte delle aziende che producono software proprietario, non ci sono dibattiti aperti su quali nuove caratteristiche o modifiche possano essere lavorate. Quando il prodotto è pronto, l'azienda lo invia semplicemente ai clienti e prosegue. Al contrario, nel caso di Linux, le discussioni su quali modifiche siano necessarie e – cosa più importante – perché siano necessarie, non si interrompono mai. Questo, ovviamente, rende l'intero processo molto più disordinato e laborioso.
Rilasciare in anticipo, rilasciare spesso
Non possiamo prevedere il futuro, quindi dobbiamo semplicemente provare:
«Ci muoviamo secondo il principio 'lancio anticipato, aggiornamenti frequenti'. Il problema principale di qualsiasi progetto software è il rischio di errori o bug nel codice sorgente. È evidente che maggiore è il numero di modifiche e aggiornamenti inclusi in una singola release (versione) del software, maggiore è la probabilità che in quella versione ci siano bug. Gli sviluppatori di software open source hanno capito che con il rilascio rapido e frequente delle versioni si riduce il rischio di gravi problemi con qualsiasi programma, poiché portiamo sul mercato non tutti gli aggiornamenti contemporaneamente, ma a piccoli gruppi per ogni 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 apportare continuamente piccoli miglioramenti conduce, in definitiva, a una maggiore innovazione. Non c'è nulla di strano in questo. Uno dei principi fondamentali dei moderni processi produttivi, come il kaizen o il lean, è la focalizzazione su cambiamenti e aggiornamenti piccoli e graduali.
[…] Molte delle cose su cui lavoriamo potrebbero non avere successo. Ma invece di perdere molto tempo a chiederci 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, non solo una, senza un rischio significativo per l'azienda.
Questo è un modo razionale di allocare risorse. Ad esempio, la gente spesso mi chiede come scegliamo quali progetti open source commercializzare. Sebbene a volte iniziamo progetti, più spesso ci uniamo a quelli esistenti. Un piccolo gruppo di ingegneri, e a volte anche una sola persona, inizia a contribuire a uno dei progetti della comunità open source. Se il progetto ha successo e è richiesto dai nostri clienti, iniziamo a dedicargli più tempo e sforzi. Se no, gli sviluppatori passano a un nuovo progetto. Quando decidiamo di commercializzare un'offerta, il progetto potrebbe essere cresciuto a tal punto che la decisione diventa ovvia. Progetti di vario tipo, compresi quelli che non riguardano il software, sorgono naturalmente in tutta l'azienda Red Hat, finché non diventa chiaro che ora qualcuno dovrà lavorarci costantemente.
Ecco un'altra citazione dal libro:
«Ho realizzato che, per svolgere questo ruolo, i leader di domani devono possedere caratteristiche che nelle organizzazioni normali non vengono generalmente considerate. Per dirigere efficacemente un'organizzazione aperta, il leader deve possedere le seguenti qualità.
- Forza personale e fiducia. I leader ordinari utilizzano il potere di posizione - il loro ruolo - per avere successo. Ma in una meritocrazia, i leader devono guadagnarsi il rispetto. E questo è possibile solo se non temono di ammettere che non hanno risposte a tutte le domande. Devono essere pronti a discutere i problemi e prendere decisioni rapidamente, in modo da trovare le migliori soluzioni insieme al loro team.
- Pazienza. I media raramente raccontano storie su quanto un leader sia 'paziente'. Ma deve essere davvero paziente. Quando lavori per ottenere il massimo impegno e risultati dal tuo team, e conduci dialoghi per ore ripetendo qualcosa finché tutto non viene fatto correttamente, devi avere pazienza.
- Alto EQ (quoziente emotivo). Troppo spesso pubblicizziamo le capacità intellettuali dei leader, concentrandoci sul loro IQ, quando in realtà è fondamentale considerare il loro quoziente emotivo, o EQ. Essere la persona più intelligente tra gli altri non è sufficiente se non sei in grado di lavorare con queste persone. Quando lavori con comunità di dipendenti coinvolti, come in Red Hat, e non hai la possibilità di comandare nessuno, la tua capacità di ascoltare, elaborare analiticamente e non prendere tutto sul personale diventa incredibilmente preziosa.
- Una mentalità diversa. I leader provenienti da organizzazioni tradizionali sono stati educati secondo il principio del quid pro quo (lat. «un servizio in cambio di un servizio»), secondo cui ogni azione deve ricevere un adeguato ritorno. Ma quando si tratta di investire nella creazione di una comunità specifica, è necessario pensare a lungo termine. È come cercare di costruire un ecosistema delicatamente bilanciato, dove ogni passo falso può creare uno sbilanciamento e portare a perdite a lungo termine che potrebbero non essere immediatamente evidenti. I leader devono liberarsi di quel tipo di mentalità che richiede risultati immediati a tutti i costi e iniziare a gestire le attività in un modo che permetta di ottenere maggiori benefici grazie agli investimenti nel futuro.
E perché è importante
Red Hat vive e opera secondo principi che differiscono notevolmente da quelli delle organizzazioni tradizionali con una gerarchia rigida. E questo funziona, ci rende commercialmente di successo e felici a livello umano. Abbiamo tradotto questo libro nel tentativo di divulgare i principi dell'organizzazione aperta tra le aziende russe, tra le persone che desiderano e possono vivere in modo diverso.
, prova!
Fonte: habr.com
