È arrivato un giorno importante per Red Hat, per la comunità open source russa e per tutti i soggetti coinvolti: è stato pubblicato in russo . Racconta in dettaglio e in modo vivido come noi di Red Hat diamo il percorso alle idee migliori e alle persone più talentuose, e anche come non perdersi nel caos e unire milioni di persone in tutto il mondo.
Questo libro parla anche della vita e della pratica. Contiene molti consigli per chiunque voglia imparare a costruire un'azienda utilizzando il modello organizzativo aperto e gestirla in modo efficace. Di seguito sono riportati alcuni dei principi più importanti contenuti nel libro di cui puoi prendere nota in questo momento.
La storia lavorativa di Jim con l'azienda è notevole. Dimostra che non c’è fanfara nel mondo open source, ma c’è un nuovo approccio alla leadership:
"Dopo aver parlato con il reclutatore, ho espresso interesse per un colloquio e lui mi ha chiesto se mi dispiaceva volare domenica al quartier generale di Red Hat a Raleigh, nella Carolina del Nord. Pensavo che domenica fosse un giorno strano per incontrarci. Ma dato che lunedì dovevo ancora volare a New York, in generale era in arrivo 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 lasciato davanti all'edificio Red Hat nel campus dell'Università della Carolina del Nord. Era domenica, alle 9:30, e non c'era nessuno in giro. Le luci erano spente e dopo aver controllato ho scoperto che le porte erano chiuse. All'inizio pensavo di essere stato ingannato. Mentre mi voltavo per risalire sul taxi, vidi che era già partito. Ben presto cominciò a piovere, non avevo l’ombrello.
Proprio mentre stavo per andare da qualche parte a prendere un taxi, Matthew Shulick, in seguito presidente del consiglio di amministrazione e CEO di Red Hat, si fermò con la sua macchina. "Ciao", salutò. "Vuoi prendere un caffè?" Sembrava un modo insolito di iniziare un'intervista, ma sapevo che avevo assolutamente bisogno di prendere un caffè. Alla fine, ho pensato, sarebbe stato più facile per me prendere un taxi per l'aeroporto.
Le domeniche mattina sono piuttosto tranquille nella Carolina del Nord. Ci è voluto un po' solo per trovare una caffetteria che aprisse prima di mezzogiorno. La caffetteria non era la migliore della città e nemmeno la più pulita, ma funzionava e lì si poteva bere il caffè appena preparato. Ci siamo seduti a un tavolo e abbiamo iniziato a parlare.
Dopo una trentina di minuti circa ho capito che mi piaceva come stavano andando le cose; L'intervista non è stata tradizionale, ma la conversazione in sé si è rivelata molto interessante. Invece di discutere i dettagli più delicati della strategia aziendale di Red Hat o della sua immagine a Wall Street, qualcosa per cui mi ero preparato, Matthew Shulick mi ha chiesto di più sulle mie speranze, sogni e obiettivi. Ora mi è chiaro che Shulik stava valutando se mi sarei adattato alla sottocultura e allo stile di gestione dell’azienda.
Dopo che abbiamo finito, Shulick ha detto che voleva presentarmi al consigliere generale della società, Michael Cunningham, e mi ha suggerito di incontrarlo adesso per un pranzo anticipato. Ho accettato e ci siamo preparati a partire. Poi il mio interlocutore ha scoperto di non avere con sé il portafoglio. "Ops", ha detto. - Non ho soldi. E tu?" La cosa mi ha colto di sorpresa, ma ho risposto che avevo i soldi e non mi dispiaceva pagare il caffè.
Pochi minuti dopo, Shulik mi lasciò in un piccolo ristorante messicano, dove incontrai Michael Cunningham. Ma ancora una volta non è seguita alcuna intervista tradizionale o incontro di lavoro, ma ha avuto luogo un'altra conversazione interessante. Quando stavamo per pagare il conto, si è scoperto che la macchina per carte di credito del ristorante era rotta e potevamo accettare solo contanti. Cunningham si è rivolto a me e mi ha chiesto se ero pronto a pagare, perché non aveva contanti con sé. Dato che andavo a New York, avevo molti soldi, quindi ho pagato il pranzo.
Cunningham si offrì di accompagnarmi all'aeroporto e andammo con la sua macchina. Dopo qualche minuto, chiese: “Ti dispiace se mi fermo e faccio benzina? Andremo avanti a tutto vapore." “Nessun problema”, risposi. Non appena ho sentito il suono ritmico della pompa, ho bussato alla finestra. Era Cunningham. "Ehi, qui non accettano carte di credito", ha detto. "Posso prendere in prestito un po 'di soldi?" Ho iniziato a chiedermi se si trattasse davvero di un'intervista o di una specie di truffa.
Il giorno successivo, mentre ero a New York, ho discusso di questa intervista con mia moglie alla Red Hat. Le ho detto che la conversazione era molto interessante, ma non ero sicuro che queste persone fossero seriamente intenzionate ad assumermi: forse volevano solo cibo e gas gratis? Ricordando quell'incontro di oggi, capisco che Shulick e Cunningham erano semplicemente persone aperte e mi trattavano come qualsiasi altra persona con cui potevano prendere un caffè, pranzare o fare il pieno di benzina. Sì, è divertente e persino divertente che entrambi siano rimasti senza soldi. Ma per loro non era una questione di soldi. Loro, come il mondo open source, non credevano nello stendere tappeti rossi o nel cercare di convincere gli altri che tutto era perfetto. Stavano solo cercando di conoscermi meglio, non di impressionare o sottolineare le nostre differenze. Volevano sapere chi ero.
La mia prima intervista a Red Hat mi ha mostrato chiaramente che il lavoro qui era diverso. Questa azienda non aveva una gerarchia tradizionale e un trattamento speciale per i manager, almeno nella forma consueta nella maggior parte delle altre aziende. Con il tempo ho anche imparato che Red Hat crede nel principio della meritocrazia: vale sempre la pena provare a realizzare l'idea migliore, indipendentemente dal fatto che provenga dal senior management o da uno stagista estivo. In altre parole, la mia prima esperienza in Red Hat mi ha fatto conoscere il futuro della leadership”.
Suggerimenti per coltivare la meritocrazia
La meritocrazia è il valore fondamentale della comunità open source. Per noi non importa quale livello della piramide occupi, la cosa principale è quanto sono buone le tue idee. Ecco cosa suggerisce Jim:
- Non dire mai: “Questo è ciò che vuole il capo” e non fare affidamento sulla gerarchia. Questo può aiutarti a breve termine, ma non è così che si costruisce una meritocrazia.
- Riconoscere pubblicamente i successi e i contributi importanti. Potrebbe trattarsi di una semplice e-mail di ringraziamento con l'intero team in copia.
- Considera: la tua autorità è una funzione della tua posizione nella gerarchia (o dell'accesso a informazioni privilegiate) o è il risultato del rispetto che ti sei guadagnato? Se il primo, inizia a lavorare sul secondo.
- Chiedi feedback e raccogli idee su un argomento specifico. Dovresti reagire a tutto, testare solo il meglio. Ma non limitarti a prendere le idee migliori e andare avanti con esse: cogli ogni opportunità per rafforzare lo spirito di meritocrazia, dando credito a tutti coloro che se lo meritano.
- Riconosci un membro esemplare del tuo team offrendogli un incarico interessante, anche se non rientra nel suo ambito di lavoro abituale.
Lascia che le tue rock star seguano la loro passione
Entusiasmo e coinvolgimento sono due parole molto importanti in un'organizzazione aperta. Si ripetono costantemente nel libro. Ma non è possibile convincere le persone creative e appassionate a lavorare sodo, giusto? Altrimenti, semplicemente non otterrai tutto ciò che il loro talento ha da offrire. In Red Hat gli ostacoli per i propri progetti vengono livellati il più possibile:
“Per promuovere l’innovazione, le aziende provano molte cose. Interessante l'approccio di Google. Da quando Google è diventato noto in ogni casa nel 2004, dirigenti e ideologi del settore Internet hanno cercato di svelare il segreto principale dell'azienda per ripetere il suo impressionante successo. Uno dei programmi più famosi, ma attualmente chiusi, prevedeva che a tutti i dipendenti di Google fosse chiesto di trascorrere il 20% del proprio tempo facendo quasi tutto ciò che desideravano. L’idea era che se i dipendenti avessero perseguito i propri progetti e le idee che li appassionavano al di fuori del lavoro, avrebbero iniziato a innovare. È così che sono nati progetti di successo di terze parti: GoogleSuggest, AdSense per i contenuti e orkut; provenivano tutti da questo esperimento del 20%: un elenco impressionante! […]
Noi di Red Hat adottiamo un approccio meno formale. Non abbiamo una politica fissa riguardo a quanto tempo ciascuno dei nostri dipendenti dovrebbe dedicare all’”innovazione”. Invece di concedere alle persone tempo dedicato all’istruzione, ci assicuriamo che i dipendenti si guadagnino il diritto di trascorrere il proprio tempo imparando cose nuove. A dire il vero, molte persone hanno pochissimo tempo a disposizione, ma c'è anche chi può dedicare quasi l'intera giornata lavorativa all'innovazione.
Il caso più tipico è più o meno questo: qualcuno lavora a un progetto parallelo (se ne ha spiegato l'importanza ai manager - direttamente sul posto di lavoro; o durante l'orario non lavorativo - di propria iniziativa), e in seguito questo lavoro può occupare tutto le sue ore presenti."
Altro che brainstorming
“Digressione lirica. Alex Fakeney Osborne è l'inventore del metodo del brainstorming, la cui continuazione oggi è il metodo sinettico. È curioso che questa idea sia apparsa durante la seconda guerra mondiale, quando Osborne comandava una delle navi di un convoglio mercantile americano che correva il pericolo di un attacco con siluri da parte di un sottomarino tedesco. Poi il capitano si ricordò della tecnica a cui ricorrevano i pirati del Medioevo: se l'equipaggio si metteva nei guai, tutti i marinai si riunivano sul ponte per suggerire a turno un modo per risolvere il problema. Le idee erano tante, anche assurde a prima vista: ad esempio l'idea di soffiare su un siluro con tutta la squadra. Ma con il getto della pompa di bordo, disponibile su ogni nave, è del tutto possibile rallentare un siluro o addirittura cambiarne la rotta. Di conseguenza, Osborne brevettò persino un’invenzione: sulla fiancata della nave viene montata un’elica aggiuntiva, che spinge un flusso d’acqua lungo la fiancata, e il siluro scivola accanto”.
Il nostro Jim ripete costantemente che non è così facile lavorare in un'organizzazione aperta. Anche il management lo capisce, poiché a nessuno viene risparmiata la necessità di difendere la propria opinione. Ma è proprio questo l’approccio necessario per ottenere ottimi risultati:
“I forum e le chat room online [open source] sono spesso pieni di discussioni vivaci e talvolta aspre su tutto, da come correggere al meglio un bug del software a quali nuove funzionalità dovrebbero essere prese in considerazione nel prossimo aggiornamento. Di norma, questa è la prima fase delle discussioni, durante la quale vengono proposte e accumulate nuove idee, ma c'è sempre un ciclo successivo: l'analisi critica. Sebbene chiunque possa partecipare a questi dibattiti, una persona deve essere pronta a difendere la propria posizione con tutte le sue forze. Le idee impopolari verranno respinte nella migliore delle ipotesi, ridicolizzate nella peggiore.
Anche Linus Torvalds, il creatore del sistema operativo Linux, esprime il suo disaccordo con le modifiche proposte al codice. Un giorno, Linus e David Howells, uno dei principali sviluppatori di Red Hat, iniziarono un acceso dibattito sui vantaggi di una modifica al codice richiesta da Red Hat per contribuire a fornire sicurezza ai nostri clienti. In risposta alla richiesta di Howells, Torvalds scrisse: “Francamente, questa [parola non stampabile] è idiota. Tutto sembra ruotare attorno a queste stupide interfacce, e per ragioni del tutto stupide. Perché dovremmo farlo? Non mi piace più il parser X.509 esistente. Si stanno creando interfacce stupide e complesse, e ora ce ne saranno 11. – Linus 9.”
Lasciando da parte i dettagli tecnici, Torvalds ha continuato a scrivere con lo stesso spirito nel messaggio successivo - e in modo tale che non oso citare. Questa controversia fu così clamorosa che arrivò persino sulle pagine del Wall Street Journal. […]
Questo dibattito mostra che la maggior parte delle aziende che producono software proprietario e non libero non hanno un dibattito aperto su quali nuove funzionalità o cambiamenti potrebbero lavorare. Quando il prodotto è pronto, l'azienda lo spedisce semplicemente ai clienti e se ne va. 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 l’intero processo molto più disordinato e dispendioso in termini di tempo”.
Rilascia presto, rilascia spesso
Non possiamo prevedere il futuro, quindi dobbiamo solo provare:
“Operiamo secondo il principio del “lancio anticipato, aggiornamenti frequenti”. Il problema chiave di qualsiasi progetto software è il rischio di errori o bug nel codice sorgente. Ovviamente, più modifiche e aggiornamenti vengono raccolti in una versione (versione) del software, maggiore è la probabilità che vi siano bug in questa versione. Gli sviluppatori di software open source si sono resi conto che rilasciando le versioni del software in modo rapido e frequente, il rischio di problemi seri con qualsiasi programma si riduce: dopo tutto, non immettiamo sul mercato tutti gli aggiornamenti contemporaneamente, ma uno alla volta per ciascuna versione. Nel tempo abbiamo notato che questo approccio non solo riduce gli errori, ma porta anche a soluzioni più interessanti. Si scopre che apportare continuamente piccoli miglioramenti crea più innovazione nel lungo termine. Forse non c'è nulla di sorprendente qui. Uno dei principi chiave dei moderni processi di produzione come kaizen a o lean b è l’attenzione a modifiche e aggiornamenti piccoli e incrementali.
[…] Gran parte di ciò su cui lavoriamo potrebbe non avere successo. Ma invece di spendere molto tempo a chiederci cosa funzionerà e cosa no, preferiamo condurre piccoli esperimenti. Le idee più popolari porteranno al successo e quelle che non funzionano svaniranno da sole. In questo modo possiamo provare molte cose anziché una sola, senza troppi rischi per l'azienda.
Questo è un modo razionale di allocare le risorse. Ad esempio, le persone spesso mi chiedono come scegliamo quali progetti open source commercializzare. Anche se a volte avviiamo progetti, il più delle volte ci limitiamo semplicemente a lanciarci in quelli esistenti. Un piccolo gruppo di ingegneri, a volte una sola persona, inizia a contribuire a uno dei progetti della comunità open source. Se il progetto ha successo ed è richiesto dai nostri clienti, iniziamo a dedicarvi più tempo e impegno. In caso contrario, gli sviluppatori passano a un nuovo progetto. Nel momento in cui decidiamo di commercializzare la proposta, il progetto potrebbe essere cresciuto a tal punto che la soluzione è ovvia. Vari progetti, compresi quelli non software, nascono naturalmente in Red Hat finché non diventa chiaro a tutti che ora qualcuno dovrà lavorarci a tempo pieno.
Ecco un'altra citazione dal libro:
“Mi sono reso conto che per ricoprire questo ruolo, i leader di domani devono avere caratteristiche che vengono semplicemente trascurate nelle organizzazioni convenzionali. Per guidare efficacemente un'organizzazione aperta, un leader deve possedere le seguenti qualità.
- Forza personale e fiducia. I leader ordinari usano il potere posizionale – la loro posizione – per raggiungere il successo. Ma in una meritocrazia, i leader devono guadagnarsi il rispetto. E questo è possibile solo se non hanno paura di ammettere che non hanno tutte le risposte. Devono essere disposti a discutere i problemi e prendere decisioni rapidamente per trovare le migliori soluzioni con il proprio team.
- Pazienza. I media raramente raccontano storie su quanto sia “paziente” un leader. Ma deve davvero essere paziente. Quando lavori per ottenere il massimo sforzo e risultati dal tuo team, conversando per ore e ripetendo le cose ancora e ancora finché non viene fatto bene, devi essere paziente.
- EQ elevato (intelligenza emotiva). Troppo spesso promuoviamo l’intelligenza dei leader concentrandoci sul loro QI, quando ciò che realmente deve essere preso in considerazione è il loro quoziente di intelligenza emotiva, o punteggio EQ. Essere la persona più intelligente tra gli altri non è sufficiente se non sei in grado di lavorare con quelle persone. Quando lavori con comunità di dipendenti impegnati come Red Hat e non hai la possibilità di dare ordini a nessuno, la tua capacità di ascoltare, elaborare in modo analitico e non prendere le cose sul personale diventa incredibilmente preziosa.
- Mentalità diversa. I leader provenienti da organizzazioni tradizionali sono stati educati con lo spirito del quid pro quo (dal latino “quid pro quo”), secondo il quale ogni azione dovrebbe ricevere un adeguato ritorno. Ma quando intendi investire nella costruzione di una particolare comunità, devi pensare a lungo termine. È come cercare di costruire un ecosistema delicatamente equilibrato, in cui qualsiasi passo sbagliato può creare uno squilibrio e portare a perdite a lungo termine che potresti non notare subito. I leader devono liberarsi della mentalità che impone loro di ottenere risultati oggi, ad ogni costo, e iniziare a fare affari in un modo che consenta loro di ottenere maggiori benefici investendo nel futuro”.
E perché è importante
Red Hat vive e opera secondo principi molto diversi da quelli di un'organizzazione gerarchica tradizionale. E funziona, ci rende commercialmente vincenti e umanamente felici. Abbiamo tradotto questo libro nella speranza di diffondere i principi dell'organizzazione aperta tra le aziende russe, tra le persone che vogliono e possono vivere diversamente.
, Provalo!
Fonte: habr.com