Perché le piccole squadre vincono

Vincono perché risolvono la complessità della comunicazione.

La legge di Metcalfe dice che ogni volta che aggiungi un nuovo utente a una rete, il numero di connessioni aumenta proporzionalmente al quadrato del numero di utenti. Questa è tecnologia, M cosa significa questo per la tua organizzazione e i tuoi team?

La struttura della nostra mente è che non può davvero gestire un gran numero di relazioni. Scienziati come Robin Dunbar ci hanno detto per decenni che il nostro mondo sociale è molto piccolo.

Dicono che ci sono circa 5 persone con cui possiamo avere relazioni strette e altre 15 persone con cui possiamo avere relazioni leggermente meno intense. Pensa alle squadre sportive, per esempio. Raramente sono più grandi di 15 persone.

Per questo motivo, le organizzazioni progressiste si sono allontanate dalle tradizionali gerarchie manageriali. Al contrario, si strutturano come reti decentralizzate di team.

Queste reti non hanno (o pochi) quadri intermedi. Sono dotati di team altamente autonomi in cui i membri si occupano della comunicazione, del coordinamento e della contrattazione.

Ma come mostra la legge di Metcalfe, quando non ci sono manager, i team devono essere abbastanza piccoli da non sovraccaricare i membri di comunicazioni e informazioni

Quale pensi sia il futuro delle organizzazioni?

Do you suffer from Imposter Syndrome? Always believing that you must be completely knowledgeable before acting? Adjust your viewpoint.

Tip: Critical thinking skills can be really valuable for Software engineers, Product and many other walks of life. It’s about approaching new information with a mix of humble curiosity and doubt.

Think independently and ask good questions that help make thoughtful decisions.

In broad strokes, some of the questions I like to ask based on critical thinking are:

➡️ How do we know we’re solving the right problem?
➡️ How do we know we’re solving the problem in the right way? (i.e. balancing rigor and efficiency, given our understanding of the problem and constraints)
➡️ If we don’t know the sources of our problem, how can we determine the root cause?
➡️ How can we break the key question down into smaller questions that we can analyze further?
➡️ Once we have one or more hypotheses, how do we structure work to evaluate them?
➡️ What shortcuts might we take if we’re under constraints (time pressure) without unduly compromising our analytics rigor around the question?
➡️ Does the evidence sufficiently support the conclusions?
How do we know when we are done? When is the solution “good enough”?
➡️ How do I communicate the solution clearly and logically to all stakeholders?

I’ve found these questions often help. Sometimes we’ll address the symptom of a problem, only to discover there are other symptoms that pop up. At other times, we might quickly ship a solution that creates more problems later down the road.

With a lens on critical thinking, we might challenge assumptions, look closer at the risk/benefit, seek out contradictory evidence, evaluate credibility and look for more data to build confidence we are doing the right thing.

Being in engineering or product, we can sometimes rush to solve a problem right away so it feels like we’re making progress or looks like we’re being responsive to stakeholders. This can introduce risks if we aren’t asking the right questions before doing so, fully considering causes and consequences. Put another way, critical thinking is thinking on purpose and forming your own conclusions. This goal-directed thinking can help you focus on root-cause issues that avoid future problems that arise from not keeping in mind causes and consequences.

Critical thinkers:
➡️ Raise mindful questions, formulating them clearly and precisely
➡️ Collect and assess relevant information, validating how they might answer the question
➡️ Arrive at well-reasoned conclusions and solutions, testing them against relevant criteria and standards
➡️ Think open mindedly within alternative systems of thought, recognizing and assessing, as need be, their assumptions, implications, and practical consequences
➡️ Communicate effectively with others in figuring out solutions to complex problems

Se nei giorni in cui lavoro da remoto entra qualcuno in ufficio chiedendo di me, ecco non dite mai “No, oggi Luigi non c’è, è in smartworking” ma rispondete “Sì, sì, oggi Luigi c’è, lavora in smartworking”.

Si potrebbe sintetizzare così lo smartworking, in italiano il lavoro agile. Perché si lavora anche così, non necessariamente seduti alla scrivania nel proprio ufficio. L’abbiamo imparato, chi già non lo faceva prima, in questi due anni di pandemia. Ci si può organizzare meglio, si risparmia tempo e tanto la produttività quanto la vita personale ne traggono vantaggio. Win-win, per stare sull’inglese. Che poi, per rispondere agli scettici, guardate che chi non lavora da casa, di regola non lavora neppure dall’ufficio.

Dal 1 settembre, ormai ci siamo, torna obbligatorio l’accordo individuale, sospeso negli ultimi due anni. Cos’è? È il fulcro dello smartworking (che ricordiamo non è un contratto di lavoro ma una sua modalità di esecuzione).

Datore di lavoro e lavoratore si devono mettere d’accordo su come organizzare il lavoro, in parte all’interno dei locali aziendali e in parte all’esterno, senza precisi vincoli di orario e di luogo di lavoro. È un accordo, il che significa che se una delle parti non è – appunto – d’accordo non se ne fa nulla. Ed è individuale, non collettivo (anche se spesso regolamenti o contratti collettivi possono dare indicazioni).

L’accordo deve essere stipulato in forma scritta, dicono le norme, “ai fini della regolarità amministrativa e della prova” e deve essere conservato dal datore di lavoro per cinque anni dalla sua sottoscrizione. Nessuna sanzione esplicita se manca l’accordo, ma conseguenze in base ai fini che è chiamato a raggiugere. Come provare i contenuti dell’accordo? Quali le conseguenze in caso di infortunio?

Novità degli ultimi giorni: l’accordo individuale, a differenza del periodo pre-pandemico, non deve più essere trasmesso al Ministero del Lavoro al quale basterà sapere (oltre all’elenco dei lavoratori interessati) la data di sottoscrizione dell’accordo e la sua durata. La comunicazione di questi dati (che poi il Ministero trasmetterà all’Inail) dovrà essere effettuata entro cinque giorni dalla sottoscrizione dell’accordo, pena una sanzione pecuniaria da 100 a 500 euro. Per la prima fase transitoria il termine è fissato al 1 novembre.

Bene, inizia la fase due dello smartworking ordinario e non più emergenziale!

E ricordatevi che risposta dare quando, non trovandomi in ufficio, vi chiederanno “Oggi Luigi è al lavoro?”.

Prima di entrare nei dettagli di Enterprise Design Thinking, analizziamo i suoi principi fondamentali, scopriamo i modelli iterativi e diamo un’occhiata alle chiavi.

I principi guidano te ed il tuo gruppo

Guarda ai problemi e alle soluzioni come a una conversazione continua

Un focus sui risultati per gli utenti

Dai la priorità ai bisogni delle persone che useranno la tua soluzione. Il successo non è misurato da caratteristiche o funzioni ma è calcolato dal modo in cui sono soddisfatte le esigenze degli utenti.

Reinventarsi di continuo

Tutto è un prototipo! Tutto, anche i prodotti e le soluzioni già esistenti. Quando consideri qualsiasi cosa come un’ulteriore iterazione, puoi portare nuove idee anche ai problemi più vecchi.

Gruppi diversi responsabilizzati

Gruppi diversi generano più idee di quelli in cui tutti la pensano allo stesso modo, perché prospettive diverse generano idee differenti e aumentano le possibilità di fare un passo in avanti. Membri diversi di un team aiutano un gruppo ad accrescere le conoscenze e a trasformare le idee in risultati.

Il modello iterativo guida te e il tuo gruppo 

Capire le esigenze degli utenti e ottenere risultati continui 

Il Modello Iterativo spinge il team a comprendere il presente e immaginare il futuro in un ciclo continuo di osservazione, riflessione e realizzazione.

Quando i gruppi iniziano, si riuniscono per capire il presente e per immaginare il futuro. È compito di ciascuno imparare di più sul mondo degli utenti con l’osservazione, oppure iniziando subito a lavorare mettendo in pratica le idee.

Il Design Thinking considera tutto come un prototipo. Tutto è un prodotto non completato su cui si continuerà a lavorare e che verrà sempre reinventato. I gruppi possono osservare, riflettere e fare ripetutamente mentre cercano di risolvere un problema.

Le Chiavi allineano te e il tuo gruppo

Le Chiavi aiutano a mantenere i gruppi focalizzati e allineati sui risultati che interessano agli utenti

Enterprise Design Thinking introduce tre pratiche fondamentali delle chiavi che aiutano a risolvere problemi ben noti che IBM spesso registra in progetti complessi. Queste possono essere brevemente descritte come:

• Hills (colline), che ci allineano come gruppi. 
• Playbacks (riproduzioni), che ci allineano nel tempo. 
• Utenti Sponsor, che ci allineano con la loro realtà. 

Le Chiavi aiutano a mantenere i gruppi concentrati sui risultati che contano per gli utenti e con le necessità del mondo reale.

Fai clic su ciascun titolo per saperne di più su queste pratiche.Le hill aiutano i gruppi a sincronizzarsi

Le Hill sono gli elementi di un piano di sviluppo che permettono al tuo progetto di focalizzarsi sui grandi problemi e sui risultati per gli utenti, e non solo su un elenco di richieste di funzionalità. Una hill indica dove andare, non come arrivarci, fornendo lo spazio necessario per generare idee innovative. 

Lo scopo di una hill è garantire l’allineamento di tutto il gruppo su un obiettivo importante, dal punto di vista dell’utente finale. Dal momento che le hill definiscono l’ambito di un progetto, è importante che la specifica della hill sia fattibile nel tempo previsto. La specifica di ogni hill dovrebbe contenere le tre componenti: Chi? Cosa? e Wow.

Chi è l’utente principale?

– vale a dire, l’utente da servire

Cos’è che verrà consegnato?

– vale a dire, il risultato che si consente agli utenti di raggiungere 

Wow è la differenza che renderà valida la tua soluzione.

–  vale a dire, una descrizione di come questo risultato piacerà al cliente

Ecco alcuni esempi che mostrano come inserire le tre componenti in un’unica espressione:

Uno studente delle superiori [Chi] può produrre un progetto di storia di otto pagine [Cosa] in meno di 24 ore senza l’aiuto dei genitori [Wow!]. 

Credo che questa nazione [Chi] dovrebbe impegnarsi a raggiungere l’obiettivo [Cosa] […] di far sbarcare un uomo sulla Luna e riportarlo in salvo sulla Terra [Wow!]. – John F. Kennedy, presidente americano, 1961I playback aiutano i gruppi a restare sincronizzati

I Playback allineano il nostro gruppo, le parti interessate e i clienti attorno al valore che forniremo per l’utente piuttosto che sui singoli elementi del progetto. I playback sono presentati ai clienti e ai gruppi sotto forma di storie utente, garantendo che l’attenzione sia focalizzata sul valore erogato all’utente piuttosto che sui dettagli tecnici. Utilizzando i playback durante tutto il ciclo di rilascio, tutte le persone coinvolte rimangono informate e allineate. I playback avvengono in molti punti lungo il percorso.

Ecco alcune best practice da tenere a mente:

• Man mano che un gruppo sviluppa delle hill, un Hill Playback aiuta a garantire che tutti siano d’accordo sul risultato previsto del progetto.
• Una volta che il team ritiene di aver raggiunto una proposta di soluzione per ciascuna hill, pianifica il prossimo traguardo: il Playback Zero. Questa sessione è un momento in cui il team e le parti interessate concordano su ciò che il team si impegnerà effettivamente a fornire.
• Mentre si sviluppa la soluzione il team prepara vari Client Playback, dove presentare il piano, le tre hill e la esperienza utente che si intende offrire all’utente. In cambio, i clienti forniscono riscontri al gruppo per continuare a migliorare il piano.

Gli utenti sponsor aiutano a capire i “veri” utenti

Gli Utenti Sponsor non sono necessariamente i manager o i responsabili. Più comunemente sono gli utenti o i potenziali utenti che aiutano con la loro esperienza tutto il gruppo. Partecipano insieme al gruppo nel raggiungere un risultato che soddisfi le esigenze degli utenti finali.

Gli utenti sponsor non sostituiscono la ricerca, ma il loro punto di vista fornirà una conoscenza diretta delle esigenze specifiche degli utenti. Le loro esperienze aiutano a colmare il divario tra i presupposti del team e la realtà quotidiana dell’utente.