Guardare a un mondo che è già cambiato

Nelle aziende moderne, una gran parte delle persone fa due lavori. Uno è quello per cui è pagata — è stata assunta, quantomeno — e l’altro è il difendersi dalla confusione generata dal primo lavoro. Soprattutto nelle aziende in cui è in corso una trasformazione agile, in cui si spostano i team, in cui si ridistribuisce la leadership, si riduce la gerarchia, in cui si creano team con porzioni di persone part-time, a giornate.

Non è un tema nuovissimo e ne ho parlato a più riprese, in presentazioni a svariate conferenze. Con questa situazione, “tutti diventano HR” ed è un fenomeno su cui ci stiamo interrogando da molto tempo. Non riusciamo — almeno le aziende non riescono — a rispondere alle domande che ogni persona si fa in un’azienda.

Le domande degli individui

• Come sto andando?
• Come sto andando rispetto agli altri?
• Il mio ruolo funziona?
• Potrò accedere a una promozione, a un aumento?
• Se l’azienda cresce, cosa mi succederà?
• Se l’azienda invece ha una contrazione, cosa mi succederà?

A queste domande è difficilissimo trovare una risposta. Cosa c’è sotto? C’è una domanda che riguarda il presente, quindi “Sto facendo il lavoro giusto?”, e ci sono delle domande che riguardano il futuro, che noi riassumiamo con “Quali sono le mie opzioni di carriera?”, perché in base a queste io so se mi sto muovendo bene o male.

Ora, io parlo della maggior parte delle aziende, perché in realtà di aziende virtuose, o di contesti virtuosi in cui a queste domande si risponde, ce ne sono tante.

La questione del ruolo

Però in dieci anni di lavoro nella mia azienda di consulenza mi sono reso conto di un fatto: tra le tante aziende con cui abbiamo lavorato, quelle che si interessano all’agilità, anche come cultura, si contano veramente sulle dita di una mano e mezza, e significa che c’è ancora tanto spazio per lavorare. In dieci anni abbiamo visto di tutto e mi interessavo di questi temi già prima di contribuire a fondare l’azienda in cui lavoro attualmente.

Quindici anni fa venni inserito come Chief Operating Officer in un’azienda di marketing, e-commerce e servizi web digitali, dal forte cuore “american-oriented”, quindi COO, CTO, CFO… C’era tutta quella pantomima di ruoli all’americana, anche perché si investiva nelle start-up, avevamo una sede a San Francisco…

Io fui assunto come direttore operativo. Il ruolo era abbastanza chiaro, perché cosa fa un COO è chiaro: mi hanno chiesto di fare alcune attività, di occuparmi di qualcosa, in un quadro abbastanza chiaro.

Ho fatto il mio lavoro per tre mesi, quattro, e poi ho cominciato a vedere che qualcuno non veniva alle riunioni, qualcuno non seguiva esattamente le procedure che volevamo implementare; quindi abbiamo tentato di inserire pratiche Agile, Scrum, Kanban, team cross-funzionali. Ma mi rendevo conto che c’era molta maretta.

Dopo sei mesi ulteriori di lavoro, mi sono accorto che qualcosa ero riuscito a fare, ma sentivo degli smell, sentivo dei fastidi…  Ma, soprattutto, mi rendevo conto che non ero riuscito a cambiare le metriche che mi erano state indicate come quelle da influenzare: più reddittività, più velocità.

Però avevamo l’Agile, avevamo il team cross-funzionale, avevamo il Product Owner, lo Scrum Master, eccetera.

Un ruolo definito dalle interazioni

Allora cosa feci? Mandai una survey a tutti, una sessantina di persone, facendo poi il giro uno a uno, chiedendo loro di essere brutalmente onesti: “Ti chiederò delle cose sul mio lavoro, su quello che sto facendo, per sapere se ti sto aiutando e se ti è chiaro il mio ruolo”.

Ho mandato questa survey: hanno risposto tutti, perché ero il COO, e mi hanno risposto le peggior cose… Qualcuno non sapeva cosa facessi, ma l’intenzione del survey era proprio quella. Ho chiesto se avessi avuto un impatto positivo sul lavoro delle persone e le risposte erano le più svariate: “Dipende…”, “E cosa dovrei fare di più?” e c’era veramente la qualunque tra quanto scritto in quei moduli.

Una delle domande era: ”Come descriveresti il mio ruolo a tua nonna, o a chi non lavora da noi?”. E anche qui sono risultato un soggetto, un capo, un Socrate aziendale, con una diversificazione della percezione del mio ruolo. Il modo in cui ero percepito io, in base alle persone, in base anche al tipo di interazione che avevo, era radicalmente diverso. Lì ho cominciato un percorso di ascolto, di avvicinamento, ho rinunciato a quell’ufficio, mi sono messo una scrivania nel corridoio e ho cominciato a lavorare insieme alle persone.

Una nuova percezione

Mi spostavo con la scrivania insieme alle persone che lavoravano, dando anche un po’ di fastidio perché la gente diceva: “Sei il COO… che cosa ci fai qua?”. Però così ho cominciato veramente a comprendere la natura del lavoro che facevano le persone, cosa che dal mio ufficio non riuscivo a vedere pienamente.

Ho cambiato il modo in cui interagivo con le persone, ho cambiato il modo in cui le persone hanno iniziato a interagire con me e, comprendendo la cultura aziendale, dopo un anno e mezzo, abbiamo rinunciato alle cariche CEO, CTO, COO etc. e così sono diventato un semplice “direttore generale”, ruolo che risultava più facile da spiegare all’interno e anche fuori.

Verso l’agilità organizzativa

È cambiato il mio ruolo, e questa cosa mi ha fatto capire tante dinamiche in quell’azienda.

A questo punto, si comincia a vedere chiaramente il rapporto tra individui e interazioni nella definizione del ruolo. E se vogliamo parlare di individui e interazioni, probabilmente il modo migliore per farlo è di prendere in esame alcuni casi, che verranno illustrati in questi due articoli, derivati da situazioni reali vissute in aziende reali nelle quali abbiamo lavorato. Naturalmente faremo delle astrazioni e delle generalizzazioni, ma il vissuto che c’è dietro è reale. È daila analisi della realtà che partono le nostre considerazioni.

“Archetipi” aziendali

Quelli che seguono  potranno sembrare a qualcuno degli stereotipi, ma io li definirei invece tre “archetipi” di azienda.

Partiamo con quella che definirei “azienda piccola”, tipo quella di cui parlavo prima a proposito dei ruoli “americani” e della scrivania “itinerante” e in cui ho lavorato parecchi anni fa. In quei contesti, le persone si conoscono, interagiscono spesso, sanno chi sono, la catena della collaborazione è abbastanza corta.

Poi, sul mercato, ci sono delle aziende di dimensione nettamente maggiore che definirei “aziende grandi liquide” o “aziende grandi moderne”: sono quelle aziende con tante persone in però cui si è già iniziato a togliere un po’ di livelli gerarchici, ci sono già delle aree relativamente autonome per lavorare insieme, sono state modernizzate alcune pratiche.

Ma c’è anche un terzo “archetipo” di organizzazione: chiamiamole “aziende grandi solide”, dove l’aggettivo “solide” non è un giudizio di valore. Sono le aziende che hanno delle logiche gerarchiche ancora molto strutturate, però hanno inserito qualche pratica di lavoro un po’ più trasversale, quindi banalmente team cross–funzionali, oppure delle scelte di team. Però, in queste aziende grandi “solide” rmane la gerarchia funzionale, il funzionogramma, l’organigramma: tutti questi elementi rimangono anche come livelli di delega.

L’oggetto del nostro lavoro

Ma qual è il campo su cui operiamo in quanto consulenti/coach che si occupano di progettazione organizzativa? Si tratta anzitutto di lavorare su individui e interazioni, anche a prescindere dall’agilità. Questo è necessario e riguarda quasi la necessità di rispondere a quelle domande di prima, per creare i prerequisiti per cui possono funzionare le pratiche agili di collaborazione, ma può funzionare anche qualsiasi altra pratica moderna.

Quindi prendiamo in esame tre casi in cui si possono applicare le attività che racconterò di seguito. Cosa cambia? Non tanto il modo in cui svolgiamo le attività in questione, perché le abbiamo svolte esattamente nello stesso modo sia in aziende piccole che in aziende grandi, moderne o meno.

Però cambia il modo in cui queste attività possono essere prese in carico e cambia il modo in cui possono essere percepite dalle persone.

Employability come riferimento

Come driver del nostro ragionamento, useremo adesso il concetto di employability. Non lo traduciamo in italiano come “occupabilità”, perché questa parola, pur corretta in senso letterale, assume tutt’altro significato.

Nel caso dell’employability, dobbiamo considerare qual è il valore di una persona all’interno di un’organizzazione, qual è il suo contributo: questa definizione ci aiuta come bussola. E allora, in tal senso, l’employability è l’insieme di competenze, conoscenze, attitudini di una persona che le permette di scegliere un’occupazione che le dia soddisfazione e successo.

A questa definizione tutti i manager e tutti gli HR si esaltano e dicono: “Sì, la voglio!”. Però… attenzione: non stiamo parlando di un prodotto pronto all’uso e in vendita su qualche piattaforma. Dentro l’employability ci sono tanti elementi e lavorare per essa implica un percorso lungo. Partiamo banalmente da scegliere un’occupazione, capire quante possibilità di scelta ho dentro un’azienda e poi quanto queste possibilità possano portare alla soddisfazione e al successo.

Capire soddisfazione e successo

Quando parliamo di soddisfazione e successo, si tratta di qualcosa che accomuna sia le persone che l’azienda, però con caratteristiche diverse ovviamente. Ma nessuno, persone o azienda, vuol fare un’attività, un’impresa per non avere successo e soddisfazione.

Quali sono, se usiamo questo come bussola, i modi per cui un dipendente, un collaboratore, un developer, un product owner, qualsiasi persona all’interno dell’organizzazione possa provare soddisfazione e successo? Cosa ci serve per provare soddisfazione e successo dentro l’azienda? Essere liberi? Avere una sfera di autonomia? Avere un impatto? Avere un senso di scopo? Fare anche le cose che piacciono? Sentirsi al sicuro? Qual è la risposta giusta dentro un’azienda specifica? Chiediamocelo ma, soprattutto, chiediamolo direttamente alle persone interessate.

Prendiamo le persone, mettiamole in una stanza — lasciamo stare le survey — e facciamole interagire; chiediamo direttamente a loro quali sono state le caratteristiche della loro esperienza lavorativa in cui hanno provato soddisfazione e successo.

E una volta che si siano individuati i momenti lavorativi significativi, mettiamoli in una scala: qui tanta soddisfazione, qui poca, quindi successo, fallimento, soddisfazione, frustrazione, paura… Elenchiamo qualsiasi cosa che sia legata al negativo o al positivo. Una volta che abbiamo raccolto questo materiale — e può essere fatto con un campione oppure con le persone dell’azienda che hanno uno stesso ruolo in particolare perché lo user journey di un ruolo è diverso da quello di un altro —clusterizziamolo in episodi lavorativi.

Si possono identificare una manciata di episodi lavorativi dentro la vita di una persona, di un ruolo, dentro un’azienda, che possono essere messi in questa matrice e hanno delle caratteristiche. Li possiamo descrivere in maniera narrativa.

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.