Raccontare episodi della propria vita lavorativa
Si possono identificare alcuni 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 valore lunga, 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 un "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.
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 possono 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?"
- "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 prodotto.
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.
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, chi 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.
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.
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.
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. La cultura aziendale di un'organizzazione va rispettata; il contesto, come sempre, resta fondamentale.