Raccontare episodi della propria vita lavorativa

Si possono identificare alcunii episodi lavorativi dentro la vita di una persona, di un ruolo, dentro un’azienda, che possono essere messi in una matrice e hanno delle caratteristiche. Li possiamo descrivere in maniera narrativa. Cosa successe quando ti diedero l’opportunità di gestire un team? Chi ha preso quella decisione? Qual è stato il trigger? Come ti sei sentito? Perché è nella parte alta della matrice? Cosa è successo quando ti è stato aggiunto un altro team su cui fare lo scrum master, oltre ai due? Chi l’ha deciso? Come ti sei sentito? Che conseguenze hai avuto? Questo serve sia per cominciare a crearsi un piccolo catalogo di episodi che, se stanno in alto, possono essere ripetuti e, se stanno in basso, verranno in qualche modo ridotti di frequenza: questo è un patrimonio inestimabile, ma ci permette anche di comprendere la cultura aziendale.

Esempi di cultura aziendale

Perché, partendo da lì, elenchiamo quello che è successo. E cosa significa la cultura aziendale? Significa comprendere che in un’azienda tecnologica piccola, in cui si sviluppa software, la parte di rilevanza rispetto a “Ero soddisfatto perché mi hanno dato un aumento o ho ricevuto il premio”, è piccola rispetto a “Ho partecipato a un percorso di innovazione”. In aziende grandi e solide, con una catena del valorelunga, non è facile far apparire chiaro al cliente quello che stai facendo tu. La capitalizzazione del prodotto assicurativo che abbiamo creato la potremo validare fra tre anni. Io cosa aspetto? Tre anni prima di essere soddisfatto dello stipendio che prendo?

Ma ci possono essere anche casi diversi, ad esempio legati alla frenesia. Abbiamo mappato in alcune aziende una cultura che prevedeva la sfida e la tensione dei capi aggressivi, percepito come elemento positivo. “Io ho bisogno di essere sfidato. E per me è stato positivo essere messo in una situazione in cui ero sotto stress, perché ho tirato fuori il meglio”.

Le culture aziendali sono tutte diverse; però dobbiamo partire da questa, perché non possiamo aspettarci di spazzarla via se introduciamo un framework — culturale o metodologico — diverso. Se ci sono sempre stati i premi di produzione, non funziona dire: “Guardate, che adesso non vi diamo più i premi, perché lavoriamo in Agile”… Ma se abbiamo vent’anni di storia in cui questo è un elemento culturale di successo, le persone si sono basate su quello anche per organizzare la loro vita…

Cambiare il punto di vista

Ormai da anni abbiamo imparato a fare gli user journeys o le service blueprint per i nostri prodotti, per i nostri clienti. Ma i nostri primi “clienti” sono le persone che lavorano con noi. Allora prendiamo una user journey, mappiamo la user journey di un dipendente, di un collega. Cosa succede? Quali sono i trigger, i momenti in cui succede qualcosa che può essere positivo o negativo? Quanto è difficile per una persona cambiare ruolo dentro un’azienda? Quanto è difficile trovare riconoscimento spalmato in una serie di passaggi in cui chiunque può interferire?

Quindi è arrivato il momento di cambiare il punto di vista, di andare oltre il nostro lato consueto: ora abbiamo uni “catalogo” con un po’ di materiali; e cosa ce ne facciamo? Lo teniamo da parte? Torniamo a employability come criterio, quindi un set di skill, conoscenze e comprensioni che ci permettono di fare tutto il resto.

Ruoli vs. incarichi

Ora, forse stiamo arrivando in un periodo storico in cui le aziende smettono di costruire delle posizioni organizzative gerarchiche sui ruoli. Son stati fatti danni in passato, ma finalmente cominciamo a capire che abbiamo a che fare con incarichi, cioè funzioni di un meccanismo. Non sono posizioni organizzative gerarchiche, caselline dentro un organigramma, perché non scalano, ma soprattutto perché, nel caso di developer e product owner, l’azienda non è Scrum, ma l’azienda usa Scrum.

Se io ricostruisco la mia architettura aziendale — che magari ha venti, trenta o quarant’anni di storia — su Scrum, e dico: “Adesso siete tutti quanti product developer”… be’ nell’azienda questo approccio drastico non può funzionare. Perché la professionalità delle varie persone è legata al fatto che si sentono uno user experience designer, oppure un developer, oppure una persona di business, o invece uno che è bravo a fare analisi…  e spazzare via questa cosa è controproducente.

Possiamo usare un framework che permette di lavorare in modo diverso, ma tenendo conto di queste professionalità, perché il modo in cui ci descriviamo condiziona anche il modo in cui collaboriamo.

Poi, in aziende più o meno liquide, queste professionalità rispondono anche a figure diverse, che magari non sono esattamente quelle più vicine al “luogo” in cui lavoriamo. Per sempio, io sono Scrum Master in un team, ma rispondo ad HR; sono sempre Scrum Master ma, se facciamo sviluppo software, rispondo a una figura, mentre, se facciamo prodotti finanziari, rispondo al CTO, il PO risponde a un’azienda diversa, il developer risponde al fornitore. Però siamo partner, ma come ci identifichiamo all’interno di questo sistema? Noi abbiamo un approccio abbastanza agnostico a questi ruoli, non prendiamo alla lettera la guida Scrum limitando strettamente ad essa cosa dovrebbe fare uno Scrum Master. E il motivo è che ogni azienda ha le sue dinamiche che spesso sono molto diverse, perché le persone interagiscono con colleghi diversi.

Chiedere e imparare

Quindi che cosa facciamo anche qui? Lo chiediamo alle persone. “Cosa fai dentro la tua azienda?”. Glielo chiediamo: il “ruolo”, quello che svolgono, le loro attività. Attraverso le domande giuste, che posono anche essere tante, creiamo una scheda:

• “Che cosa fai?”
• “Cosa ti viene chiesto di fare che non vorresti fare?”
• “Qual è il tuo grado di autonomia all’interno dell’azienda?”
• “Di cosa puoi disporre?”, “Che cosa devi saper fare?”
• “Che cosa impari facendolo e rimane difficile anche dopo?” (non è che dopo un anno sai fare bene il lavoro e sei una macchina, perché in certi contesti è sempre difficile fare alcune attività)
• “Chi ti può insegnare qualcosa?”
• “A chi tu puoi insegnare qualcosa dopo?”
• “Che strumenti usi?”
• “Da cosa è evidente che lo stai facendo bene?”

La logica di costruzione di questa scheda, con alcune di queste domande guida, è la concretezza, perché oramai ci siamo stufati di job description in cui il Product Owner è responsabile della qualità del prodott.

Lo chiedo a chi fa il PO? Siete responsabili davvero della qualità del prodotto? Diciamo che siete responsabili di mettere in fila i pezzi che aumentano la probabilità che il prodotto sia di qualità, ma non potete garantirla. Quindi che cosa puoi garantire? Che qualche meeting venga fatto? Va bene, è sufficiente probabilmente, però è chiaro.

Gl aspetti di operation

E poi la parte di operation: a chi chiedi le ferie? Questa è una cosa che in tutti i team Scrum certamente viene fuori, perché non è il Product Owner che può approvare le ferie. Se io fossi un Product Owner, non farei mai fare le ferie alle persone; ma è giusto? Se io fossi un Product Owner, oltretutto, proprio non vorrei gestire questo aspetto operativo delle ferie. Ci sono modalità operative differenti, e allora intanto mappiamo la differenza.

Il radar dei doveri

A volte usiamo anche un diagramma “a radar”. Prima di costruire la scheda, facciamo un radar. Che cos’è che è al centro? Che tu fai, pensi di dover fare e fai volentieri e secondo te ha un contributo.

Che cos’è che non riesci a fare ma vorresti? E che cos’è che sta fuori, che ti tocca fare, ma non ha proprio senso per te? E c’è senz’altro qualcosa che sta all’interno e fuori.

Ovviamente, anche con uno strumento così interessante, ci sono dei rischi: il principale è che ci finisca dentro di tutto, in maniera un po’ indistinta. E allora le diverse risposte vanno “clusterizzate” in maniera da avere dei gruppi omogenei di attività. Così possiamo capire qual è l’impatto sull’azienda — in termini di tempi, qualità, budget, costi, ricavi — delle attività che si vorrebbero fare di più o di quelle che si fanno già o di quelle che non si vorrebbero più fare. Queste sono etichette che fanno riflettere su quello che è importante per l’azienda.

Ma in definitiva, dal radar poi cosa esce? Esce un patrimonio di informazioni per cui scopriamo che il Product Owner non ha nessuna leva sul time-to-market. Esce un patrimonio di informazioni rispetto a quante cose non sapevano gli altri che venivano fatte da queste figure come lo scrum master o il developer o il technical analyst o il business analyst che hanno un impatto positivo all’interno della gestione dei costi.

Attività concrete

Ed esce tutta una serie di attività che vengono svolte quotidianamente, si tratti semplicemente anche di “Devo mandare una mail al fornitore”, “Devo approvare l’offerta”, “Devo aspettare che mi venga approvato qualcosa”. Molto concrete, pratiche, quotidiane.

Un altro aspetto interessante che emerge da questo radar è che ci sono attività che non riuscite a fare ma che dovreste fare. Analizziamole nel dettagio e mappiamo un processo del come lavoriamo noi con le altre persone per questa attività. Basta una semplice Service Blueprint da cui facciamo emergere gli step del processo di cui vi occupate… e, guarda un po’, salta fuori che quel processo, di cui in teoria siete responsabili, va a coinvolgere tante persone in un determinato momento chiave, per cui non riuscite a fare quello che vi è stato chiesto senza che mezza azienda sia coinvolta… Quindi il grado di responsabilità che potete assumere non è quello di garantire quello step ma di garantire che tutte le persone arrivino puntuali a quello step.

Le interazioni con i ruoli

Nel nostro viaggio nell’agilità organizzativa, abbiamo messo in luce l’importanza delle interazioni. Una delle domande tipiche che facciamo come consulenti nella nostra scheda è “Qual è il tuo network?”. Vale a dire, hi vedi spesso, con chi hai bisogno di collaborare sempre per poter essere efficace, chi invece puoi vedere meno di frequente.

Ha senso che tu riceva le email dall’amministratore delegato o dal CEO? Ha senso che tu venga interrotto da qualcuno che ti chiede di fare qualcosa di diverso da quello che stai già facendo? Ecco, noi dobbiamo tener presenti tutte queste interazioni perché, usando gli strumenti giusti, anche qui ricaviamo un patrimonio di informazioni sui dei ruoli effettivi e sulle interazioni reali. E con questo schema di ruoli e interazioni ben disegnato su una lavagna, possiamo fare un confronto con l’organigramma ufficiale che spesso riporta ruoli e interazioni diverse.

Personalmente, io mi diverto tantissimo con queste attività, perché le persone finalmente si sentono riconosciute al di là di quello che era stato il loro job title di assunzione che poi, dopo qualche settimana di lavoro reale in azienda, si è rivelato come sempre inadeguato.

Feedback per una visione d’insieme

Che cosa facciamo dopo, quando abbiamo questo materiale? Visualizziamo insieme le schede e facciamo in modo che le persone leggano le schede degli altri e facciano richieste dicendo: “Ma secondo me potresti/dovresti fare anche questo”, oppure “Eh, ma non lo sapevo che facevi questa cosa”. Quindi si tratta di un piccolo tour in cui ognuno inserisce delle richieste agli altri ruoli per dire che, se nel tuo ruolo facessi questo, poi anche io nel mio ruolo sarei più efficace, perché li vediamo insieme. Ecco, l’insieme di tutte queste schede permette di realizzare in un team con dei ruoli diversi coinvolti più o meno a tempo parziale.

Avere queste informazioni, raccolte con gli strumenti adeguati e visualizzati in maniera chiara, consente proprio questa discussione collaborativa sul prodotto, e sul valore, nel suo insieme. Non si dice più che questa è roba da tester, quella è roba da venditori, quell’altra è roba da analisti e così via. Ma si interagisce, pur nella diversità dei ruoli, focalizzati su istanze concrete e con un quadro d’insieme su cui interagire.

E si rischia meno che poi determinate attività vadano in escalation fuori dal radar, in carico a qualcuno che magari è pure capace di svolgerle bene, ma che poi non interagisce laddove invece ce ne è più bisogno.

Un esempio in tal senso è quanto ho potuto vdere in una azienda di software. Si tratta di un’azienda relativamente piccola, che però deve garantire comunque dei livelli di sicurezza per il delivery, il trasporto, la logistica e che ha conseguentemente bisogno di certificazioni. Il problema restava sospeso e alla fine chi se ne è occupato? Non il team ma invece il CTO, che ha un ruolo più distaccato e che non è presente ai lavori del team. Uno degli aspetti principali di questo approccio che chiaiamo agilità organizzativa è che si chiariscono un sacco di punti che magari per mesi, o addirittura per anni a volte, sono rimasti in sospeso e sono stati considerati come inefficienza del team.

E che questo approccio abbia un senso lo capiamo quando i vari ruoli ci dicono: “Finalmente ci hanno ascoltato”, “Finalmente ho capito cosa fanno gli altri, come posso interagire io, come posso modificare il mio lavoro”, “Scopro che i miei colleghi conoscono più di quello che mi viene insegnato nella formazione aziendale” e “Finalmente so cosa dire a mia mamma quando mi chiede che lavoro faccio”…

Ruolo, identità, riconoscimento sociale

Facciamo attenzione che questa cosa del job title, del far capire agli altri che lavoro si fa, va da un lato analizzata e “ripulita” di tante rigidità. Ma, dall’altro questa identità lavorativa è qualcosa che ogni lavoratore possiede: è una costruzione sociale che viene modificata dalle interazioni dell’azienda. IL modo in cui ci identifichiamo è molto importante; il nome che diamo, o che viene dato, al nostro ruolo può condizionare in modo significativo il modo in cui noi collaboriamo con gli altri e gli altri collaborano con noi: quindi non prendiamo sottogamba la maniera in cui un ruolo descrive se stesso all’interno di un’azienda.

Quando parliamo di carriera, ogni ruolo all’interno di un’azienda si costruisce con le domande che scaturiscono dai nostri episodi lavorativi: sono dei trigger di carriera.

Gli episodi all’interno della vita aziendale possono essere, ad esempio, la creazione di un nuovo team, la riorganizzazione agile, la partecipazione a un progetto innovativo e così via.

Ne scaturiscono domande, del tipo “Volevo risolvere questa cosa l’anno scorso ma non l’ho ancora fatto”, “Ma queste cose si possono fare anche in quest’altro modo”; oppure può trattarsi di un dialogo con qualche collega che lavora in un’azienda simile alla nostra e che ci racconta cosa fanno loro.

La carriera come sviluppo

Ma questa dinamica non vale solo per il lavoratore, ma anche per l’azienda. Anche l’azienda si fa delle domande, dove ovviamente per “azienda” intendiamo le persone che hanno il compito e la possibilità di dare un indirizzo alle scelte dell’organizzazione. Le decisioni sono sempre eventi comunicativi che hanno dei poli e questa conversazione di crescita si può avere con la persona che rappresenta l’azienda; se è alimentata dal materiale che abbiamo visto è potentissima. Significa che io come persona porto l’evidenza del mio contributo, il feedback che ho raccolto, porto le mie aspirazioni. L’azienda mi dice come sta andando, mi deve rassicurare, quantomeno darmi contesto, e poi capire che tipo di opportunità ci sono che tipo di sviluppi ci sono o non ci sono.

All’interno di un’azienda io parlo con un referente, se l’azienda è molto strutturata. Posso parlare con più referenti che determinano la mia carriera, se l’azienda è più liquida, più moderna. Se l’azienda è piccola, poi, ne parliamo tra di noi che siamo una trentina di persone e vediamo cosa può succedere.

Allenarsi a queste conversazioni non è facile ed è un’altra sorta di framework che può essere però imparato, allenato e adattato azienda per azienda. Attenzione, non stiamo parlando di valutazione delle prestazioni, ma di un discorso più ampio. Se proprio dobbiamo usare i termini in voga, direi che a Performace Management dovremmo sostituire Performance Development, perché è interesse dell’azienda e di chi ci lavora dentro quello di migliorare: mettere in condizione la persona di crescere.

Miglioramento continuo

Il modo in cui può crescere una persona in genere verte su questi aspetti:

• competenze core
• miglioramento del ruolo
• crescita nell’expertise

E in quale track mi devo collocare? Parliamo di incremento se io mi sento nel posto giusto probabilmente sento un piccolo incremento ogni tanto. Certo, può essere anche solo la retribuzione, perché non tutti vogliono crescere indefinitamente in competenze.

Ma la strada giusta è sempre fare chiarezza tramite una buona individuazione delle informazioni iniziali realizzata con gli strumenti e i framework che ci consentono di fare le domande giuste e raccogliere risposte significative. Senza mai dimenticare che in ogni azienda si cresce in versioni diverse. Ad esempio, non in tutte le aziende — pensiamo a quelle piccole — si può divenare facilmente CTO, ma diventare CTO non rappresenta certo l’unico modo per crescere. La cultura aziendale di un’organizzazione va rispettata; il contesto, come sempre, resta fondamentale.

Marco Calzolari

Di formazione umanistica e filosofo, lavora e si diverte con il digitale dal 1999. Nel corso degli anni, ha rivestito ruoli di web designer, motion designer, software developer e project manager. Ha contribuito a diffondere in Italia la cultura dell’Information Architecture e della User Experience. Dopo un’esperienza di General Management e in alcune startup come investitore e advisor, ora è CEO e co-fondatore di Agile Reloaded e di Nobilita. Svolge attività di consulenza e coaching in organizzazioni che hanno bisogno di migliorare qualità, performance e sostenibilità del ritmo lavorativo, con un’attenzione specifica alla valorizzazione delle persone e delle performance.