Quanto funziona bene in pratica il modello DRI (Directly Responsible Individual) di Apple?

Il concetto DRI funziona fenomenalmente bene.

Nota che è solo questo -- un concetto. Un semplice strumento per rendere chiara la proprietà e indirizzare le persone con domande al posto giusto. Non è un processo o una struttura per la gestione del progetto.

Con i DRI su tutto, dalle grandi iniziative alle segnalazioni di bug, molte questioni di proprietà vengono chiarite. Nella minoranza dei casi, si tratta di responsabilità dopo che qualcosa è andato storto. Il casino di MobileMe è uno di quei pochi esempi in cui qualcosa va male e poi qualcuno viene licenziato. Più frequentemente, avere un DRI vi aiuta nelle seguenti situazioni:

• Quando si risolve un problema ingegneristico complesso e interfunzionale, volete un DRI che sia responsabile di guidare il team fino a quando il problema non è risolto. Spesso si tratta di un capo ingegnere o di un responsabile del programma di ingegneria. Diciamo che è soprattutto un problema di ingegneria meccanica con un po' di HW coinvolto. Allora di solito un ingegnere PD (product design) sarà il DRI, e lavorerà con gli ingegneri HW per risolvere il problema. Se qualcosa continua a fallire sulle linee di collaudo dei prototipi, allora si potrebbe avere un TPM (test program manager) come DRI, che lavora in collaborazione con i team di ingegneri Apple, il fornitore di apparecchiature di collaudo e i team dei produttori a contratto.
• Quando non è chiaro chi abbia la palla e cosa dovrebbe succedere, tutti si fidano che sia il DRI a guidare. Quando ti fidi del tuo DRI, non devi preoccuparti quando non vedi nessuna attività recente su quel problema. Si presume che abbiano trovato una dipendenza e stiano aspettando che accada prima, o che stiano lavorando a qualcosa dietro le quinte che si rivelerà utile. Questo non è solo rassicurante per le altre persone che lavorano sullo stesso problema, ma aiuta anche la gestione interfunzionale a fare chiarezza su chi *esattamente* sta guidando cosa. Non è solo "il team marcomm", è una persona specifica.
• Quando tutti sanno che qualcosa è importante, ma nessuno si sente come se fosse sua responsabilità vederlo fino in fondo. In un'azienda in rapida crescita con tonnellate di attività, le cose importanti vengono lasciate sul tavolo non perché le persone sono irresponsabili ma solo perché sono molto occupate. Il beneficio qui è più proprietà che responsabilità. Quando sentite che qualcosa è il vostro bambino, allora vi preoccupate davvero, davvero di come sta andando. Sarai ossessionato dalle metriche e rintraccerai i problemi e radunerai le persone e vorrai fare cose carine per loro quando raggiungerai qualcosa di grande.
  

Avere un DRI è anche efficiente per il team perché non si hanno 15 persone che si preoccupano delle stesse cose. Invece, un ingegnere può sentirsi a suo agio sapendo che a volte si presenta semplicemente e altre persone gli diranno cosa fare, liberandolo per concentrarsi sulla sfida in questione. Altre volte, agiranno come DRI ed eserciteranno di più i loro muscoli di leadership.

Ovviamente, sono un grande fan del modello DRI. È una delle cose più preziose e pratiche che ho imparato alla Apple, ed è uno strumento che usiamo a Flipboard quando sembra utile.

Flipboard'è una startup, e non abbiamo tanti processi formali quanti ne ha Apple. Ecco come abbiamo i DRI: Abbiamo un team interfunzionale che lavora su Android (frontend, backend, QA, product manager, marketing, design, BD, account management) con il leader eng come DRI generale di Android. Allo stesso modo, abbiamo un team interfunzionale che lavora su internazionale, con un capo BD come DRI informale. Nessuna di queste persone potrebbe fare il proprio lavoro senza l'aiuto di molti altri team funzionali. Ma aiuta ad avere un singolo DRI per chiamare fuori un pezzo importante del grande quadro che ci manca, per guidare qualcosa al completamento, e per essere responsabile delle decisioni strategiche insieme al nostro CEO.