Il lavoratore remoto: la flessibilità, diritto e un dovere


Se lavorate da remoto e state facendo 9/18 con 1 ora di pausa pranzo state sbagliando tutto. Il lavoratore remoto è diverso, deve essere diverso e deve giovare dell’essere diverso.

Forse qualcuno avrà notato che ho cambiato la cadenza dei post, non ce ne sono più il venerdì. Perché? Semplice sono in ferie tutti i venerdì fino a fine agosto. Anche quest’anno per ora niente ferie lunghe e consecutive, ma lo stress e la fatica si accumulano comunque, la flessibilità che ho mi permette con tranquillità di prendermi 14 venerdì di ferie.

Allo stresso tempo visto che fa caldo, troppo caldo perché le mie sinapsi producano qualcosa di intelligente, la flessibilità di cui sopra mi permette di cambiare la mia giornata e spaccarla in due in maniera completamente diversa. La mattina inizia presto, 6.30, finisce verso le 11, piscina, piscina, piscina. Il pomeriggio inizia tardi, verso le 15.30 e finisce tardi.

Nel nostro caso specifico ottengo il vantaggio che ho più sovrapposizione con i colleghi australiani e americani, ma è un dettaglio. Il tutto è permesso dal fatto che la struttura organizzativa e i processi sono pensati con la flessibilità come uno dei punti cardine, nel nostro caso perché è un requisito ovviamente, ma nel vostro?

Se siete un lavoratore 100% remoto e siete obbligati al 9/18 con 1 ora di pausa pranzo, fatevi delle domande, probabilmente c’è qualcosa di profondo che non va e quella è la punta dell’iceberg, o l’effetto collaterale. Uno scenario potrebbe essere che l’organizzazione non è strutturata per il lavoro remoto, ma le percepisce solamente come un benefit (se volete leggere contentino fate pure ;-) ) e come tale lo tratta.

author: Mauro Servienti | posted @ Wednesday, July 19, 2017 11:24 AM | Feedback (0)

Le persone vanno unite, non divise.


Nota per il lettore:

Questa (mini) serie di post non è una ricetta per trasformare un’organizzazione in un ambiente in cui fallire non sia un problema, mi spiace dirvelo: non esistono ricette o il manuale delle istruzioni. Quello di cui parlo in questi 6 post sono le cose principali che sono emerse nel lungo processo di trasformazione, iniziato ormai 3 anni fa, che hanno portato Particular Software ad essere quello che è oggi.

La vostra ricetta la potete trovare solo voi facendo quello che forse è il primo, e più difficile, passo: chiedendo a voi stessi, ai colleghi e ai dipendenti che cosa non va bene e come lo cambierebbero. Ovviamente dovete ascoltare le risposte, criticarle e poi infine dovete voler cambiare.

Eroi solitari

Ho spesso la sensazione che si tenda a promuovere una cultura in cui l’eroe solitario, che arriva e risolve tutto, sia la cosa da favorire. Certo dal punto di vista dell’eroe è bello pensare di essere la figura indispensabile, senza la quale non funziona nulla. Quello con il numero 11 sulla maglia. Allo stesso tempo l’eroe è il perfetto capro espiatorio, se ha successo verrà osannato, ma se fallisce abbiamo la figura su cui puntare il dito, quello da punire e castigare.

Cui prodest?

La mia esperienza dice che tutto ciò è figlio di una cultura che premia, o punisce, il risultato. Una cultura focalizzata sul cosa si ottiene e non sul come. In tutto ciò ovviamente il manager, quello nell’accezione negativa, ci sguazza con gioia perché in questo modo detiene potere.

Se al contrario facessimo lavorare, sempre, le persone in team (diciamo in tre)? cosa otterremmo?

  • Diversità di pensiero
  • Lo stimolo a trovare un modo per raggiungere il consenso
  • La nascita, spesso inaspettata, di nuovi leader
  • La scoperta che alcune persone sono dei perfetti avvocati del diavoli
  • Lo stimolo a crescere e alla sfida costante

Forse la cosa più importante è la spersonalizzazione della colpa, se sei solo e fallisci è per forza colpa tua, se sei un team e fallisci è colpa di tutto il team. Ebbene si, magari la colpa è di uno solo del team, ma gli altri lo hanno lasciato fallire portandosi a casa la loro fetta di responsabilità. Un team sano e coeso fa di tutto per auto-correggersi.

Ovvio che siamo in oligarchia, tutto ciò spaventa molto.

Post in questa (mini) serie:

author: Mauro Servienti | posted @ Monday, July 17, 2017 9:23 AM | Feedback (0)

Le metriche sono il male fatto a misura.


Nota per il lettore:

Questa (mini) serie di post non è una ricetta per trasformare un’organizzazione in un ambiente in cui fallire non sia un problema, mi spiace dirvelo: non esistono ricette o il manuale delle istruzioni. Quello di cui parlo in questi 6 post sono le cose principali che sono emerse nel lungo processo di trasformazione, iniziato ormai 3 anni fa, che hanno portato Particular Software ad essere quello che è oggi.

La vostra ricetta la potete trovare solo voi facendo quello che forse è il primo, e più difficile, passo: chiedendo a voi stessi, ai colleghi e ai dipendenti che cosa non va bene e come lo cambierebbero. Ovviamente dovete ascoltare le risposte, criticarle e poi infine dovete voler cambiare.

L’importanza delle metriche

Misurare è importante, misurare le cose sbagliate è deleterio. Imporre le misurazioni, giuste o sbagliate che siano, è altrettanto problematico. Basare il raggiungimento degli obiettivi sulla base delle metriche, magari sbagliate e imposte, è infine la ricetta per il disastro.

In scenari in cui le metriche scelte sono quelle sbagliate e/o sono imposte dall’alto e non condivise le persone tendono a lavorare principalmente per soddisfare la metrica. Se la metrica premia quanti support case chiudo in una settimana, il mio modello di relazione con il cliente sarà orientato a sbolognarlo nel più breve tempo possibile e non in primis a risolvere con qualità il suo problema.

Non misuravamo nulla

Quando abbiamo deciso di fare tabula rasa della struttura tradizionale dell’organizzazione abbiamo anche eliminato tutte le metriche, non misuravamo nulla. Il passaggio drastico è servito a resettare l’ambiente, a cambiare i parametri del successo e dell’insuccesso. Negli ultimi 6 mesi circa un paio di metriche sono state re-introdotte. Sarebbe meglio dire che sono state inventate dal basso al fine di soddisfare esigenze che le persone coinvolte nelle attività quotidiane hanno.

Quando la metrica emerge dal basso, è condivisa da tutti, è elaborata e costruita da tutti, è naturale vederne il valore intrinseco e non percepirla come un mero strumento di controllo finalizzato alla punizione quando questa non viene soddisfatta.

Concludendo

Come per tutti i processi aziendali, anche le metriche infine devono essere controllate, oliate e aggiustate continuamente, altrimenti diventano il nuovo Gantt scolpito nella pietra, che può solo generare problemi e frustrazioni. Possiamo quindi riassumere dicendo che le metriche:

  • in se non sono il male, ma è come vengono usate;
  • usate per elargire benefit o celebrare successi e punire insuccessi travieranno per forza le persone;
  • devono essere condivise e comprese a fondo da tutti, meglio se vengono dal basso;
  • devono essere costantemente monitorare e aggiustate in base al contesto;

Post in questa (mini) serie:

  • Il manager non serve, trovate: leader, mentor e coach.
  • Le metriche sono il male fatto a misura.
  • Le persone vanno unite, non divise.
  • Fiducia, fiducia e ancora fiducia.
  • Processi (tanti), non risultati.
  • Basta! basta! basta! pensare alla soluzione non serve se non si è compreso il problema.

author: Mauro Servienti | posted @ Wednesday, July 12, 2017 11:10 AM | Feedback (0)

Il manager non serve, trovate: leader, mentor e coach.


Nota per il lettore:

Questa (mini) serie di post non è una ricetta per trasformare un’organizzazione in un ambiente in cui fallire non sia un problema, mi spiace dirvelo: non esistono ricette o il manuale delle istruzioni. Quello di cui parlo in questi 6 post sono le cose principali che sono emerse nel lungo processo di trasformazione, iniziato ormai 3 anni fa, che hanno portato Particular Software ad essere quello che è oggi.

La vostra ricetta la potete trovare solo voi facendo quello che forse è il primo, e più difficile, passo: chiedendo a voi stessi, a colleghi e dipendenti che cosa non va bene e come lo cambierebbero. Ovviamente dovete ascoltare le risposte, criticarle e agire. Infine dovete voler cambiare.

Da Wikipedia:

A manager is a person who manages or is in charge of something. Managers can control departments in companies, or guide the people who work for them. Managers must often make decisions about things.

Abbiamo completamente eliminato i manager, le persone operative sono direttamente responsabili delle loro azioni, le persone sul campo sono quelle che prendono decisioni, tutte le persone coinvolte in un processo si assicurano che il processo sia ben oliato e funzionante, controllando che tutto funzioni come si deve.

Non ci serve un manager con il frustino che stia su un piedistallo a controllare che le risorse (perché così lui le chiamerebbe) stiano incollate davanti al computer almeno 8 ore, ne tantomeno ci serve qualcuno che ti faccia notare che insomma per oggi hai fatto solo mezza giornata, mentre i tuoi colleghi faranno anche 11 ore.

Quello che ci serve sono leader, che spronino le persone a fare scelte audaci e a mettersi in gioco, leader che allo stesso tempo sappiano insegnare alle persone trasferendo conoscenze ed esperienza. Infine siamo costantemente alla ricerca di punti di riferimento, di persone con cui confrontarci in merito alla quotidianità e perché no anche ai problemi lavorativi e non che ci attanagliano.

Come siamo soliti dire:

Non esistono persone sbagliate, ma solo persone giuste al posto sbagliato.

Un manager farebbe di tutto per liberarsene; leader, coach a mentor fanno di tutto per esplorarne il potenziale e trovare il posto giusto per massimizzarlo.

Post in questa (mini) serie:

  • Il manager non serve, trovate: leader, mentor e coach.
  • Le metriche sono il male fatto a misura.
  • Le persone vanno unite, non divise.
  • Fiducia, fiducia e ancora fiducia.
  • Processi (tanti), non risultati.
  • Basta! basta! basta! pensare alla soluzione non serve se non si è compreso il problema.

author: Mauro Servienti | posted @ Monday, July 10, 2017 10:28 AM | Feedback (3)

La coesione cambia, l’accoppiamento resta. Take 2


Quando abbiamo detto che la coesione cambia e l’accoppiamento resta abbiamo usato un esempio:

Se pensiamo ad un processo come ad una macchina a stati, in ogni stato del processo ci possono essere coinvolti uno o più servizi, coesi tra loro da quello specifico stato, ma non necessariamente nello stato successivo. Se non stiamo attenti e scivoliamo da coesione verso accoppiamento a questo punto ci ritroviamo che i servizi coinvolti in un processo sono per forza anche inutilmente coesi, proprio perché accoppiati, a prescindere dallo stato del processo stesso.

La macchina a stati

Un esempio minimalista potrebbe essere il seguente:

  1. Scelgo dal catalogo
  2. Aggiungo al carrello
  3. Inizio il checkout
  4. Imputo l’indirizzo di spedizione
  5. Scelgo il tipo di spedizione
  6. Imputo l’indirizzo di fatturazione
  7. Pago
  8. La merce viene reperita
  9. Il corriere espresso viene contattato
  10. La merce viene spedita
  11. L’ordine è evaso

Diciamo che dal punto 3 in poi è una tipica gestione ordini. Abbiamo vari servizi (logici) coinvolti, come Shipping, Finance, e Warehouse.

Un tentativo accoppiato

Un modo per modellare il processo di cui sopra potrebbe essere:

Il carrello manda un comando al gestore ordini per iniziare il checkout. Il checkout manda un comando a Shipping per far si che i dettagli della spedizione vengano definiti, Shipping quindi manda un comando a Finance per gestire il pagamento, Finance una volta gestito il pagamento manda un comando a Warehouse per iniziare la comporre l’ordine e infine Warehouse manda un comando nuovamente a Shipping per iniziare la spedizione, al termine della quale Shipping dice al gestore dell’ordine che l’ordine è completato e quindi evaso.

Se rileggete quello che abbiamo appena scritto e sostituite tutti i “manda un comando” con “invoca” avete un bel flusso procedurale, accoppiatissimo e monolitico. Flusso in cui magari i service boundary sono chiari e definiti ma monolitico resta, se ci mettete una coda e dei messaggi ottenete due cose:

  • più complessità
  • il solo vantaggio che la coda vi fa off-loading del carico quindi se il passaggio X è particolarmente lento gli altri non ne risentono

L’orchestratore

A questo punto tipicamente il passaggio che si fa è: ma se l’ordine è a tutti gli effetti una macchina a stati, allora un orchestrator, o un process manager, o una saga sono il modello ideale. Del resto prima in un paio di punti sono stato obbligato ad usare il termine “gestore ordini”.

La trasformazione che quindi si applica potrebbe essere ad esempio:

Il carrello manda un comando al gestore ordini per iniziare il checkout. Il gestore ordini manda un comando a Shipping per far si che i dettagli della spedizione vengano definiti, Shipping quindi manda un messaggio al gestore ordini per informare che i dettagli della spedizione sono definiti, il gestore ordini quindi dice a Finance che può gestire il pagamento, Finance una volta gestito il pagamento manda un messaggio al gestore ordini per aggiornarlo sulla situazione. A questo punto il gestore ordini può mandare un comando a Warehouse per iniziare la comporre l’ordine e, dopo aver ricevuto conferma da Warehouse, infine mandare un comando nuovamente a Shipping per iniziare la spedizione, al termine della quale Shipping dice al gestore dell’ordine che l’ordine è completato e quindi evaso.

È cambiato qualcosa?

Secondo me è peggiorato, lo si evince anche solo leggendo:

  • Abbiamo sempre una sorta di comportamento procedurale, questa volta nelle mani di qualcuno di specifico: il gestore ordini
  • è ancora più complesso perché adesso abbiamo un nuovo attore: il gestore ordini
  • è molto verboso, o “chatty” come direbbero i miei colleghi

Perché quindi?

Spesso si finisce comunque per disegnare una soluzione come la seconda con la convinzione che risolva due problemi:

  • non è monolitica, ma è distribuita, scala ed è disaccoppiata (solo perché c’è una coda nel mezzo)
  • abbiamo un posto solo dove la UI può andare a leggere per riportare al lettore lo stato dell’ordine

Tada: “Riportare al lettore lo stato dell’ordine”

Questo è quello che ci sta fregando, questa necessità ci sta dicendo che una porzione del sistema, quella in cui facciamo reportistica all’utente, ha bisogno di informazioni aggregate sull’ordine. Il processo che gestisce l’ordine assolutamente no. I singoli servizi hanno bisogno delle loro informazioni interne per poter fare il loro lavoro. Shipping non ha bisogno di sapere quanto ho pagato o come ho pagato, ha solo bisogno di sapere che ho pagato.

Quindi abbiamo due informazioni importanti adesso:

  • La UI sta generano coesione, alcuni servizi devono in alcuni momenti essere in grado di riportare al lettore informazioni
  • Gli stati dei singoli servizi coinvolti nella gestione dell’ordine sono coesi al fine di risolvere il problema della gestione dell’ordine, ergo tutti prima o poi devono partecipare in qualche modo facendo la loro parte

Perché la coesione può cambiare?

Nel processo di cui sopra il carrello è coeso con la gestione dell’ordine? Solo al primo passaggio, quando iniziamo il processo di checkout, se lo iniziamo dal carrello, se lo iniziassimo da un ordine telefonico no non sarebbe coeso.

Allo stesso modo la coesione evolve o cambia con l’evolvere o l’avanzamento del processo di gestione dell’ordine, c’è un momento, ma solo quello, in cui Shipping probabilmente ha bisogno di Warehouse per capire dimensione e valore dei beni da spedire per organizzare la spedizione e capire se deve assicurarli.

Infine nuovi requisiti potrebbero cambiare gli attuali rapporti di coesione ma sarebbero un terremoto se ci fosse accoppiamento, uno su tutti: arriva uno stakeholder e vi informa che il business vuole vendere anche musica in formato digitale. Tutta la parte di spedizione scompare in un batter d’occhio. Se c’è accoppiamento sono dolori. Se c’è solo coesione c’è solo da introdurre il nuovo processo.

Ricordiamoci che:

Siccome l’accoppiamento è per sempre è bene lavorare per ridurlo al minimo indispensabile, ricordandoci che accoppiamento zero è impossibile. La strategia per ridurre all’osso l’accoppiamento tra le parti è identificare i service boundary seguendo la coesione che è una buona linea guida.

author: Mauro Servienti | posted @ Saturday, July 8, 2017 11:21 AM | Feedback (0)

“Embrace failure”: come crei un ambiente in cui fallire non sia un problema?


Alessio fa quella che probabilmente è la Domanda, con la D maiuscola: Come crei un ambiente che consenta di alzare la mano e dire: “non sono produttivo”?

image

Diciamo che probabilmente possiamo generalizzare la domanda in: come crei un ambiente in cui fallire non sia un problema?

42, è la risposta

Un ambiente in cui fallire non è un problema non è il punto di partenza, piuttosto è la destinazione a cui dovremmo tendere. Se il fallimento non è più visto come un problema si sbloccano tutta una serie di comportamenti che non possono far altro che migliorare drasticamente l’ambiente in cui viviamo e lavoriamo.

Fallimento = male

Il problema di fondo è che la cultura in cui viviamo ci ha insegnato che fallire, o anche semplicemente sbagliare è male, il male peggiore. Si viene marchiati a vita, con la lettera scarlatta, come dei falliti. La cosa molto curiosa è che questo processo mentale si instaura in tarda età. Il bambino appena nato fallisce costantemente e ad ogni piè sospinto, per il semplice fatto che sta facendo esperienza ed ogni cosa è nuova, e l’unico modo per imparare è sperimentando e apprendendo dagli errori, quindi fallendo. Questa cosa è accettata fino ad una certa età dalla nostra società dopodiché ci si aspetta che l’esperienza accumulata sia sufficiente per non sbagliare più.

Mai cazzata fu più colossale

Questo ovviamente, alza il velo del disonore e con il disonore i freni. Quindi? come ristabiliamo l’equilibrio nella forza? Nel nostro piccolo ci abbiamo messo quasi tre anni, minchia tre anni (cit.), ma ci siamo riusciti. Non abbiate fretta.

Le cose che abbiamo fatto e che continuiamo a fare sono tantissime, ma quelle che ritengo essere le più importanti sono:

  1. Il manager non serve, trovate: leader, mentor e coach.
  2. Le metriche sono il male fatto a misura.
  3. Le persone vanno unite, non divise.
  4. Fiducia, fiducia e ancora fiducia.
  5. Processi (tanti), non risultati.
  6. Basta! basta! basta! pensare alla soluzione non serve se non si è compreso il problema.

Alcuni degli argomenti li abbiamo già trattati in maniera sparsa qua e la in questi ultimi due anni. Abbiamo 6 post da scrivere, alla prossima. Post che sono la base del talk “from cogs to nirvana” che ogni tanto mi capita di portare in giro per conferenze e user group, se siete interessati fate un fischio.

author: Mauro Servienti | posted @ Wednesday, July 5, 2017 8:44 AM | Feedback (3)

Il lavoratore remoto: il confronto con i colleghi


L’organizzazione della propria giornata lavorativa, in particolare se si è da soli nel proprio ufficio, è particolarmente complessa e rischia di essere il nostro tallone d’Achille. Una giornata mal organizzata può solo portare a:

  • Sensazione o effettiva poca produttività.
  • Poca soddisfazione.
  • Frustrazione

Giorno dopo giorno, mano a mano che si accumulano le settimane la cosa può solo finire male.

Prevenire è meglio che curare

Non ci sono ricette magiche, una delle cose che ho compreso essere molto importante è il costante confronto con i colleghi, ove confronto significa:

  • farsi spiegare come organizzano loro la loro giornata
  • ascoltare quali problemi hanno
  • esporre come organizziamo noi la nostra giornata
  • dire molto apertamente quali problemi abbiamo
  • condividere quindi successi e insuccessi anche nelle piccole cose di tutti i giorni

Quello che in apparenza sembra ovvio implica che lavoriate in un ambiente in cui potete alzare la mano e dire: “non sono produttivo”.

author: Mauro Servienti | posted @ Monday, July 3, 2017 10:19 AM | Feedback (1)

Services Composition: ViewModel Composition - Take 3


Ci siamo lasciati a questo punto, con una overview ancora architetturale di come funzionano le cose:

image

Il commento di Raffaele mi da lo spunto per entrare un minimo nel tecnico:

image

Back-end

Facciamo un esempio con il mero scopo di capire come potrebbero funzionare nella realtà le cose.

Marketing è un nostro sistema interno scritto in .NET che espone un’API tramite WebAPI. Sales è un’istanza di SalesForce che paghiamo profumatamente. Shipping sono i servizi del/i corriere/i espresso/i che ci forniscono servizi e li possiamo interrogare sempre tramite un’API basata su HTTP. Warehouse è sempre un nostro sistema interno scritto in Node.js. Infine Publishing, che abbiamo detto essere, dal punto di vista logico, un processo di Marketing è un mero Key/Value store in cui dato un ID di prodotto possiamo sapere se è disponibile on-line o meno: quindi Key = ID prodotto, Value = true/false.

IT/Ops Composition Engine

Il Composition Engine altro non è che un reverse proxy che ha lo scopo di implementare un API Gateway, implementato nell’esempio disponibile online con ASP.NET Core. Data la tecnologia del gateway, ogni team dei servizi di cui sopra produrrà un assembly con delle classi che implementano interfacce definite dal Gateway stesso. Questi assembly saranno deployati insieme al Gateway il quale li caricherà via IoC.

/products/123

Abbiamo bisogno di visualizzare un prodotto, la cui chiave è “123”. Per il client il web server a cui rivolgersi è il reverse proxy, quindi la richiesta HTTP “/products/123” viene gestita dal nostro fidato API Gateway. Il quale Gateway ovviamente non sa che fare, se non:

  • Iterare su tutte le classi che implementano IRouteInterceptor (uso la terminologia dell’esempio) e chiedere se sono interessate a gestire la rotta “/products/123” (istanze che potrebbero essere ovviamente cachate per URL).
  • Creare in memoria un ViewModel vuoto, ad esempio un dictionary o un oggetto dymanic.
  • Invocare tutti i route interceptor interessati a gestire la richiesta corrente passando ad ognuno il ViewModel di cui sopra.
    • Ogni route interceptor, data la rotta corrente, è pensato per interagire con il suo backend e quindi recuperare le informazioni necessarie a soddisfare la porzione di richiesta che spetta a lui
  • Aspettare che tutti abbiano finito :-).
  • Ritornare il ViewModel come risposta HTTP.

Concludendo

A questo punto ci aspettiamo che il ViewModel sia riempito con dati pertinenti, ma non è così semplice come sembra. Se osserviamo i servizi/processi da cui siamo partiti c’è una cosa che probabilmente ci salta all’occhio ed è che Publishing comanda, se nel Key/Value Store il valore per “123” è false significa che il prodotto non deve essere visualizzato e che quindi tutti gli altri non devono fare nulla. L’ordine di esecuzione è una rogna, perché implica accoppiamento per certi versi, è una rogna che quindi vorremmo evitare.

Al prossimo giro, però :-)

author: Mauro Servienti | posted @ Friday, June 30, 2017 6:13 PM | Feedback (0)

Agenda: perché cartacea e non digitale


La domanda di Roberto e la risposta di Michael sono interessanti:

image

Diciamo che sono allineato al 100% con quello che dice Michael, oltre al fatto che la carta:

  • Mi piace
  • Le batterie non si scaricano
  • Non crasha, sbomba, corrompe lo storage, etc..

Battute a parte le motivazioni sono le seguenti:

  • Il fatto di dover riportare costantemente, tutte le sere, al giorno successivo mi aiuta a ragionare sul perché non ho fatto
  • La frizione derivante dal “riportare” a mano mi aiuta a pianificare meglio, perché riportare è noioso

La giornata di oggi si è rivelata un disastro, e guardando l’agenda è evidente perché: ieri si sono accumulate una quantità notevole di cose da fare. Di solito ho un massimo di 8 task, mentre in questo momento siamo così:

2017-06-28 12.52.40 HDR

e dopo la foto è pure peggiorata…sarà una lunga settimana :-)

author: Mauro Servienti | posted @ Wednesday, June 28, 2017 3:37 PM | Feedback (0)

Il lavoratore remoto è da solo e senza feedback


Nel viaggio attraverso alcune delle caratteristiche del lavoratore remoto abbiamo già toccato il problema solitudine. Il tener traccia delle attività quotidiane è un interessante escamotage al fine di dare valore alla giornata, principalmente se la giornata tende ad essere guidata da mille cose da fare.

L’agendina sul lungo periodo non funziona

In ambienti sani (e non credo di averne incontrati) ci si aspetta che ci sia un processo di feedback consolidato, in cui il manager è colui che veicola il feedback verso il team, con un flusso costante di informazioni. Feedback sia positivo che negativo, sono entrambi fondamentali. In ambienti meno sani in cui non c’è un processo consolidato c’è comunque tutto il mondo non-verbale che emerge in maniera naturale dalla condivisione degli spazi, è ovviamente soggetto a interpretazione ma c’è e non è detto che sia cosa buona e giusta se non accompagnato da un vero processo di feedback.

Il lavoratore quindi è immerso in un ambiente che volente o nolente comunica con lui e porta feedback verso di lui.

Il lavoratore remoto non ha neanche quello

Il lavoratore remoto data la sua innata condizione di solitudine non ha neanche accesso al feedback non-verbale, insinuando nella quotidianità domande che non dovrebbero esistere:

  • sto facendo bene?
  • è quello che si aspettano da me?
  • dovrei fare di più?
  • gli altri fanno cose che io non e da cui sono escluso per qualche motivo?

E via dicendo.

Al fine di evitare la degenerazione inevitabile che domande come quelle di cui sopra portano con se, da quasi un anno, in Particular, stiamo ragionando su definire un processo di feedback consolidato e diffuso al fine di prevenire completamente il formarsi anche del solo dubbio.

Il successo va celebrato

Siamo lontani dall’avere qualcosa di pronto, un secondo pilot sta per partire. Secondo perché il primo è stato un mezzo flop (magari ne parleremo). Quello che abbiamo compreso essere fondamentale è comunque una cosa che per molti magari è scontata ma tanti altri proprio non lo è: celebrare il successo.

L’essere umano è molto bravo ad evidenziare, ma ancor di più a notare e ricordare, i problemi. Ed è comprensibile, i problemi per loro natura impattano molto sulla nostra quotidianità quindi emergono e persistono. Ci sono inoltre persone che partono da presupposto che far funzionare le cose faccia parte del loro lavoro quotidiano, risolvere problemi o essere bravi speaker sia dovuto per il semplice fatto che è il loro ruolo all’interno dell’azienda. Ci si aspetta da un responsabile contabilità che ne sappia di contabilità e che si sappia districare nei meandri della stessa, si tende quindi a dare per scontato che possa anche essere un buon responsabile contabilità.

Non basta

Quando le cose vanno bene è importante dirlo, condividerlo. Quando qualcuno fa qualcosa che ha un impatto su qualcosa o su qualcun altro è importante dirlo. Ma cosa ancora più importante è importante dirlo pubblicamente. La condivisione dei successi e la celebrazione degli stessi è un primo passo verso un processo di feedback sano ed efficace.

author: Mauro Servienti | posted @ Monday, June 26, 2017 7:43 AM | Feedback (0)