Copertina: Foto di Pramod Tiwari su Unsplash

Avvertenza

Questa storia non è proprio vera. Ma non è affatto finta.

È il resoconto verosimile di un processo di trasformazione aziendale e organizzativa basato su fatti ed eventi reali che però sono stati opportunamente modificati, adattati e combinati per far loro assumere un significato più generale e per dare al racconto anche un valore “didattico”: la narrazione di una trasformazione organizzativa ispirata ai principi e alle pratiche Lean/Agile e alle conoscenze e alle tecniche dell’Organisational Design.

Pertanto i nomi, l’azienda, i luoghi non fanno riferimento a elementi precisamente identificabili e i personaggi sono da intendersi come di fantasia. Anche se poi magari qualche persona potrà riconoscersi in essi.

La storia comincia nei primissimi mesi del 2021 ed è tuttora in svolgimento…

Barn raising e conoscenza collaborativa

Tanti anni fa, rimasi colpito nello scoprire una pratica diffusa nell’America rurale tra XVIII e prima metà del XX secolo, quella del barn raising, letteralmente “innalzamento del fienile”. Si trattava di un evento durante il quale una comunità di persone, il villaggio o il gruppo di case sparse di un certo territorio, si riuniva per lavorare insieme alla realizzazione di un edificio rurale (un “fienile”, appunto, o genericamente un magazzino) per una famiglia del gruppo o per tutta la comunità.

L’idea mi piacque perché da essa derivavano tante considerazioni sulla conoscenza collaborativa, ossia sul fatto che lavorare insieme a qualche progetto fa crescere il bagaglio di competenze di tutti coloro che si mettono insieme per svolgere quel compito.

Quando mi sono congedato da Alessio, dicendogli che avrei voluto coinvolgere qualche amico, l’ho fatto per vari motivi. Anzitutto perché io, come consulente e coach per aziende, non vado dai client con soluzioni già pronte per essere adottate, ma faccio il percorso insieme a quell’azienda scoprendo a mia volta possibili soluzioni che emergono dal contesto peculiare in cui stiamo lavorando. E per fare chiarezza, anzitutto a noi stessi, su quali siano i passi giusti da fare in certe situazioni, vale senza dubbio la preparazione teorica, conta molto l’esperienza di anni su certe tipologie di progetti, ma ha un immenso valore anche il confronto con esperti di determinati temi con i quali è importante parlare per avere una visione più ampia.

Ma c’è anche un altro motivo: mi entusiasmo molto nel proporre idee e pratiche che ho avuto modo di comprendere e sperimentare. E cerco di coinvolgere anche gli altri in questo mio entusiasmo. Questa volta, però, ho notato in Alessio qualcosa in più oltre al suo consueto, sano e positivo spirito critico che tanto ci ha aiutato a mettere a punto le iniziative fin qui realizzate, consentendone un miglior adattamento al contesto aziendale in cui lui si muove da tanti anni. Questa volta mi è sembrato che la sua preoccupazione non fosse tanto per l’edificio concettuale che stiamo costruendo, né per le pur notevoli questioni tecniche, quanto piuttosto per tutta quella serie di vincoli normativi, finanziari, procedurali che un’organizzazione grande si trova necessariamente ad avere.

Un esperto di team e di organizzazioni digital

Per questo sono a dialogare con Alessandro Giardina [1] di Intré, un professionista che è partito da un ruolo tecnico e che da quel mondo non si è comunque distaccato, ma che ha svolto un percorso per cui è diventato cruciale lavorare con le persone e far loro scoprire il modo di apprendere, collaborare, realizzare gli obiettivi nella maniera meno conflittuale possibile e più positiva per i singoli, i team, l’intera organizzazione.

Alessandro ascolta con attenzione quanto ho da raccontargli. Non ha problemi a comprendere come stiamo procedendo con il tema degli ecosistemi digitali, visto che lo conosce, né si intimidisce a pensare agli aspetti tecnici impegnativi che il nostro percorso potrebbe riservarci. Quando arrivo a spiegare ciò che ho percepito nella conversazione con Alessio, e un po’ nell’ambito delle aziende coinvolte, capisce che è arrivato il suo momento per parlare.

Come funzionano le organizzazioni (grandi)

Con il suo tipco tono pacato, Alessandro comincia: “Quello che noi vediamo è che le aziende, quando crescono sopra una certa dimensione, si burocratizzano, creano dei silos, quindi diventa una vera sfida la creazione di gruppi di lavoro che restlno allineati al flusso di valoreche producono per l’utente, per l’azienda e così via”.

“Be’, sì, è qualcosa che sperimentiamo tutti” aggiungo, più per confermare ad Alessandro che proprio questo è il punto di partenza del nostro discorso che per dire qualcosa di particolarmente brillante…

“Pensa a questo.”, riprende Alessandro. “Le startup funzionano molto bene proprio perché il team è tutto lì, focalizzato a creare valore: è di per sé stream-aligned. Ma poi, quando cresciamo, riusciamo a mantenere un team tutto focalizzato sullo stream di valore? E la risposta, almeno nella maggior parte dei casi è ‘purtroppo no’, perché le aziende che crescono sono ancorate a vecchi modelli di organizzazione, vuoi di tipo piramidale, vuoi basati su team specializzati e separati. E alla fine degenerano nel proverbiale ‘carrozzone burocratico’. Chi più e chi meno, ma insomma…”.

Alessandro ha perfettamente ragione e, proprio mentre sta per dirlo, capisco che vuole ulteriormente riforzare questa considerazione.

“Vedi Giovanni, il discorso dei gruppi separati vale già all’interno delle singole organizzazioni e a maggior ragione finisce per impattare quando si vogliono far lavorare insieme organizzazioni diverse”.

“Sì,” lo assecondo“ è quello che rende più difficili le interazioni di tipo Cross Organisations, o X-O come siamo soliti dire noi”.

“È una sfida importante”, riprende Alessandro, “e non la scopriamo noi adesso: si tenta di affrontarla con approcci un po’ diversi, ma i tentativi ci sono. È una sfida organizzativa, ma soprattutto culturale”.

Tra Team Topologies e unFIX

“Quello che ha fatto Team Topologies [2] è di razionalizzare e spiegare perché i team che sono stream-aligned hanno valore e quindi trovare un modo per organizzarsi con questi stream team e una serie di altri attori che sono a supporto. Jurgen Appelo, dal canto suo, con unFIX [3], fa un passo ulteriore: pur ispirandosi a Team Topologies e a diversi altri modelli organizzativi, include nel suo framework organizzativo una serie di altri attori, di altre strutture ‘di supporto’ — come il management, gli aspetti legal, le funzioni HR — che in effetti esistono nell’organizzazione e che non vanno eliminate concettualmente. Se la tendenza degli ultimi venti anni è stata quella di ridurre le dipendenze, e concentrare all’interno del singolo team tutte le competenze necessarie a fare qualcosa — l’ormai canonico cross-functional team —, invece Appelo ci dice che le dipendenze ci sono, non è possibile eliminarle e anzi possono anche essere una cosa buona, a patto che ve ne sia consapevolezza e si sappia come governarle”.

Per un attimo rifletto su quante idee, quanti modelli organizzativi, quanti approcci diversi ho visto proporre in questi ultimi venti anni nell’ambito organizzativo delle aziende digitali, e non solo. Vorrei fare una serie di considerazioni: quanti di essi hanno goduto di un periodo di assoluto splendore per poi cadere nell’oblio? Quante enunciazioni di cui eravamo tutti entusiasti hanno retto la prova del campo? E, in positivo, quante “scoperte” abbiamo fatto nel continuo confronto con le realtà aziendali che poi abbiamo ritrovato nell’opera di qualche bravo imprenditore / manager / gruppo di studio che le ha proposte nelle maggiori conferenze internazionali? È stato, questo primo quarto di secolo del secondo millennio, un periodo di trasformazioni incredibili, non tutte positive, non tutte negative. Dobbiamo imparare a navigare in questo mare agitato della digital revolution.

Ma mentre formulo rapidamente questi pensieri tra me e me, Alessandro ha già ripreso il filo del discorso: “E queste proposte che ad esempio fa Jurgen Appelo sono tutte belle e tutte valide. Ma poi… vai a implementarle in un’organizzazione… E qui arriva il difficile, perché ci sono tanti casi diversi e tanti contesti differenti”.

“Sì, ti seguo” faccio io.

Qualche caso reale

Alessandro continua: “Anzitutto sgombriamo il campo dall’idea che tutte le organizzazioni anche grandi siano sempre disfunzionali: a me è capitato di operare in situazioni di massimo ‘splendore’, con aziende che rilasciavano un flusso di valore costante. Ma anche questi casi poi possono ‘degenerare’ per tante ragioni: un caso tipico è che l’azienda viene acquisita da una più grande o, viceversa, incorpora altre realtà con i loro prodotti. Oppure pensa all’azienda che si quota in Borsa e allora deve seguire tutta una serie di norme legali particolari, ma anche proprio delle pratiche tipiche che non sono neanche leggi, ma che devono comunque in qualche modo essere seguite. E qui iniziano a emergere delle differenze ‘culturali’, nel senso di cultura aziendale, che a volte sono solo diversità, in altri casi diventano fonte di conflitto… Poi va detto anche che, nonostante certe difficoltà, tutto sommato è possibile far lavorare abbastanza bene insieme le persone a livello di team, anche di team di aziende diverse. Le persone coinvolte spesso trovano dei working agreements e seguono delle pratiche agili come la review o le retrospettive che tutte quante facilitano sicuramente l’interazione. Ma poi, a un certo punto, arrivano dall’alto alcune ‘imposizioni’ che dipendono dalla cultura dell’azienda a cui si afferisce, e questo complica la vita dei team Cross-Organisation”.

“Sì, è vero”, gli faccio eco. “Quando entri in un’azienda in cui non sei mai stato, dopo un po’ di tempo riesci a renderti conto se certi problemi ci sono. Forse noi ‘consulenti’ esterni ce ne rendiamo conto ancor ci più”.

“Guarda,” riprende Alessandro, “ti faccio un po’ di esempi di situazioni tipiche, che tu avrai sicuramente sperimentato e che magari non ti suoneranno nuove. Ma, di fatto, sono casi tipici che ben spiegano quali sono i problemi reali. Cominciamo con una questione quasi banale, ma che invece diventa cruciale, quella delle ferie”.

“Sì,” lo assecondo ridendo, “noi questa ormai in certi casi la consideriamo un benchmark”.

“Eh, appunto”, continua Alessandro. “Che cosa succede di solito? Che i team che devono lavorare su un prodotto, se sono formati e hanno una certa maturità, sanno autoorganizzarsi. E quindi sanno anche quando è il momento di andare in ferie compatibilmente con l’andamento del progetto. Ora però succede che, per policy proprie dell’azienda A, il loro ramo HR decida che le persone debbano andare in ferie, che so, tra fine aprile e inizio maggio, quando ci sono i ponti. E però le persone dell’Azienda B dovrebbero continuare a lavorare senza che i loro colleghi siano a disposizione. Immaginiamo che nel team dell’Azienda A ci sia, per esempio, il responsabile Quality Assurance del gruppo. Che fanno gli altri? Possono continuare a lavorare? Arriviamo a paradossi per cui il QA del team dell’Azienda A, che è ben consapevole di cosa vuol dire la sua assenza, va dal suo HR e lo prega di non mandarlo in ferie!”

Ridiamo entrambi. In effetti la situazione è divertente, ma molto comune.

Alessandro riprende: “Oppure, un altro caso tipico del come sia possibile intralciare dall’alto il lavoro dei team di aziende diverse che si svolge più ‘in basso’ è quello dei permessi, nel senso di chi è autorizzato a fare determinate cose. Il dipartimento IT dell’Azienda A non vuol autorizzare dipendenti dell’azienda B a operare su sistemi della propria azienda: soltanto le persone dell’Azienda A hanno il diritto di modificare le pipeline perché per fare quello ci vogliono dei permessi particolari. Eh, ma poi succede che l’esperto di pipeline dei team X-O appartenga proprio all’Azienda B e non possa quindi ricevere tali permessi particolari dall’IT dell’Azienda A. Poi i team si autoorganizzano e quindi si arriva a situazioni tipo videochiamate con il Team A che condivide lo schermo del proprio tool di pipeline con il Team B e l’esperto dell’Azienda B, privo dei permessi, che dice ai colleghi del Team A di premere quel pulsante, far vedere quella pagina, scrivere quel codice, eseguire quel comando e così via”.

Mi viene ancora da ridere, ma la situazione reale è proprio quella che sta descrivendo Alessandro nel raccontare questi casi vissuti.

“La cosa che faccio io” riprende, “è proprio questa, vale a dire cercare di persuadere le organizzazioni a rilasciare un po’ certi vincoli, spiegandone i motivi. Ma più l’azienda con cui lavori è grossa, più queste cose sono difficili”.

Disaccoppiamento, composizione, piattaforme

Quanto mi dice Alessandro è molto chiaro e condivisibile. Cerco a mia volta di proporre una possibile soluzione: “Ma, a questo punto, non sarebbe meglio evitare di ‘costringere’ le due organizzazioni a lavorare insieme con dei team X-O e seguire un’altra strategia? Cioè si potrebbe ipotizzare che l’Azienda A e l’Azienda B producano dei servizi disaccoppiati, esposti su una piattaforma secondo certe regole e poi sarà l’Azienda C o il Team C che li utilizza, creando delle composable application e superando così quelle dipendenze e quei vincoli di cui stavamo parlando”.

Sempre la Legge di Conway

Alessandro mi risponde: “Sì, certo, come architettura è giusta, come sono spesso buone le soluzioni che vengono proposte dai tecnici. Ma il fatto è che qui noi parliamo di organizzazioni e dobbiamo confrontarci con la cosiddetta Legge di Conway [4] la quale afferma che le organizzazioni che devono progettare un’architettura finiscono per produrre architetture le quali sono copie della propria struttura organizzativa interna. In realtà dovresti fare l’esatto contrario, ossia creare organizzazioni a partire da un’architettura funzionale… ma poi c’è HR, c’è il Top Management e così via”.

Insisto: “Tutto questo è chiaro, ma la mia idea era proprio di svincolarsi da questo creando appunto delle composable applications a partire da quello che l’azienda espone sulla sua piattaforma…”

“Sì, certo” riprende Alessandro, “ma già convincere l’Azienda A e B a creare una piattaforma i cui servizi poi saranno sfruttati da un’Azienda C potrebbe risultare molto difficile. Ti potrebbero chiedere perché mai realizzare questa piattaforma se è qualcosa che non vendo e non posso fatturarla”.

“Eh” rispondo, “è proprio questo il discorso: devi venderlo, devi fatturarlo”.
Alessandro continua: “Certo, ma questa idea che sia qualcosa di profittevole la devi far passare, verso il top management, e devi trovare il modo di parlare e convincere, il che potrebbe essere anche complicato”.

“Sì” continuo io, “ma pensa a questo esempio: se io propongo non tanto un database o qualcosa del genere, ma un vero e proprio servizio ‘calcola prezzo’, questo potrà essere acquistato da qualcuno che da me compra questo, da un altro compra il servizio ‘carrello’ o quel che è, per comporre un’applicazione. Forse ho una visione troppo da Product Owner, o da imprenditore, ma non pensi che possa funzionare?”.

“Sì” risponde Alessandro, “ma va fatto capire, tenendo ben presenti anche certe problematiche culturali e organizzative di cui abbiamo parlato. Ti racconto un altro caso reale”.

Piattaforme ed eccezioni

“C’è un’azienda che, per anni, ha dato grande libertà ai propri team non solo di creare prodotti, ma anche di definire il modello di business con cui vendere questo prodotto e di rilasciarlo ai loro clienti, occupandosi anche della messa in produzione. È chiaro che questi prodotti hanno un modello di business diverso tra loro, un sistema di pricing diverso tra loro, una base clienti diversa. Ci sono prodotti venduti a licenza, altri a consumo con dei token, altri con sistemi diversi. E poi ci sono prodotti che, per esempio, hanno un abbonamento base e uno avanzato, altri che hanno tre livelli di prezzo, altri che magari hanno gli stessi livelli ma li chiamano in modo diverso, che so ‘Pro’ ed ‘Expert’. Di certo, non siamo in presenza di un carrozzone centralizzato. Poi cosa è successo? Questa azienda è cresciuta facendo delle acquisizioni di concorrenti, in certi casi perché il loro prodotto era migliore e puntavano ad averlo; in altri casi, semplicemente per togliere di mezzo un competitor perché poi il prodotto dopo un po’ veniva chiuso. Ma, di fatto, tutto questo ha portato a un caos con decine e decine di prodotti, alcuni dei quali tendono anche a sovrapporsi. Allora hanno chiamato noi affinché realizzassimo una piattaforma in grado di gestire tutta questa complessità: un punto centralizzato in cui trovare la documentazione del cliente, la tipologia di contratto, se a consumo o ad abbonamento per esempio, la situazione di consumo / rinnovo di ciascun cliente e così via. Oltre a questo, si desiderava una uniformazione, ad esempio, del tipo di licenze vendute, sia nei livelli che anche nel nome”.

Stavolta non ho capito dove vuole arrivare Alessandro, ma il suo racconto mi sta interessando e mi riporta alla mente vari casi simili a cui ho assistito.

Alessandro continua: “A questo punto, dicevo, arriva il nostro intervento con la piattaforma che, in fin dei conti non è tecnicamente difficile. C’è un database normalizzato dei clienti, bisogna capire chi ha cosa e con quale formula (abbonamento? consumo?), organizzare le scadenze e i rinnovi oppure contare il consumo e provvedere alla vendita di pacchetti di token. Oltre a uniformare, come ti dicevo, i livelli delle varie formule di acquisto. Bene… Sai che succede? Succede che ci sono delle resistenze incredibili da parte dei singoli team che curavano i vari prodotti”.

Mi inserisco: “Eh, ma in questi casi contano tanti elementi: dietro ognuno di questi prodotti c’è una responsabilità, c’è un valore, c’è anche una gelosia…”

“Dici bene” mi fa eco Alessandro. “C’è una gelosia, ma c’è anche il fatto che in effetti è il team quello che conosce meglio il prodotto e sa qual è la base di clienti e il modello di business migliore per venderlo. E su questa cosa hanno probabilmente anche ragione a fare qualche resistenza. Ma, dall’altra parte il top management dice che la piattaforma va fatta con i criteri di armonizzazione dei vari prodotti, per porre fine a quel caos che il continuo accumulo di soluzioni diversificate ha prodotto. Bene, vuoi sapere come va a finire?”

“E certo”, faccio io.

“Va a finire che vincono i team di prodotto sul top management: le regole della piattaforma armonizzante restano un po’ dei sogni e il backlog del gruppo di lavoro che la sta realizzando è composto tutto da item del tipo ‘realizza l’eccezione per il sistema di licensing’, ‘realizza l’eccezione per le tipologie di livello di contratto’ e così via”.

Ridiamo entrambi. Ma devo chiedere per forza qualcosa.

Soluzioni organizzative e tecniche

“Scusa Alessandro, ma per queste situazioni ci saranno anche delle soluzioni, no?”.
“Certo” mi risponde. “Anche tu ne avrai provate”.

“Sì”, faccio io. “Ma mi piacerebbe sentire prima le tue, per vedere se corrispondono”.

Alessandro si ferma un attimo e poi, con tono quasi solenne afferma: “Alle sprint review e sprint planning del team che realizza la piattaforma, invitiamo anche i responsabili dei vari team di singolo prodotto, affinché si rendano conto del delirio che stanno causando”.

Scoppio a ridere: “Non è esattamente quello a cui stavo pensando, ma mi pare comunque efficace…”

“Sì”, riprende Alessandro. “Chiaramente non c’è solo questo. Per esempio, andiamo a cena tutti insieme? Invitiamo il manager dell’HR insieme al CTO e li mettiamo in condizione di avere una conversazione e uno scambio di pareri in un contesto rilassato e informale. Cosa che in azienda non farebbero mai perché la gerarchia dell’organizzazione e il modo in cui essa è strutturata non li fanno mai dialogare. In questo modo anche loro potranno sperimentare i problemi — feel the pain — e tentare di trovare dei compromessi, cosa che nella rigida struttura dell’organizzazione sarebbe ben più difficile”.

Torno a riproporre la mia idea sulle composable application mettendo in luce che, nel momento in cui il modello di business rende vantaggioso anche in termini economici la “vendita” di determinati servizi su piattaforma, poi tutti avrebbero interesse a sviluppare un tale modello, sia chi offre i servizi, perché guadagna, sia chi li utilizza per costruire applicazioni.

Alessandro è d’accordo, ma ha qualcosa da aggiungere: “È vero… pensa che la piattaforma di cui ti parlavo utilizza dei servizi combinandoli insieme. Per esempio usa Kong [5] come gateway, o Chargebee [6] come sistema per la gestione del licencing, e anche molti altri elementi. Ecco questi prodotti, queste tecnologie ti forniscono dei pezzetti di piattaforma realizzati con estrema cura, molto affidabili e performanti, a un prezzo equo, che sia in abbonamento o in pay per use. Poi è anche vero che ognuno si potrebbe scrivere la propria ogica per il gateway o per il controllo degli accessi o per la gestione delle licenze, ma magari otterrebbe un risultato peggiore con sforzi maggiori. Invece ha già pronti questi componenti di alta qualità che gli servono e non deve far altro che assemblarli. Quindi, se già nell’azienda gli sviluppatori, a un livello tecnico, fanno questa cosa che funziona, perché non dovrebbe essere possibile farlo anche a livelli più elevati per i prodotti di punta?”.

“La sfida diventa trovare un marketplace in cui vendere i propri servizi che altri potranno usare per fare qualcosa, no?” chiedo io.

“La sfida è smettere di realizzare soluzioni in cerca di un problema e capire invece qual è il reale problema che vogliamo risolvere.” sentenzia Alessandro. “E questo vale in generale, ma ancor più in Italia. Tornando a quanto dicevo prima, ai vari Kong e Chargebee usati nella piattaforma, quello è un bel modo per creare componenti che possano vivere in un ecosistema digitale. Occorre che le aziende, in particolar modo le startup, si liberino di quella dimensione troppo sognatrice che poteva andar bene venti anni fa. È abbastanza insensato continuare a pensare di creare il prodotto Business-to-Consumer che rovescia tutto quanto: l’iPhone è arrivato quasi venti anni fa e non siamo tutti degli Steve Jobs. Invece, creare dei componenti Business-to-Business, tipo quelli che citavamo, capaci di risolvere un problema specifico, molto curati e ben performanti… be’, non sarà di sicuro esaltante come cercare qualcosa di analogo all’iPhone, ma di certo è un lavoro che porta valore a tante persone risolvendo dei problemi e che si colloca bene su un mercato. Certo dire di aver fatto una buona piattaforma di licencing grazie alla quale le aziende possono vendere le loro licenze non è esaltante o affascinante come inventare lo smartphone, ma è estremamente importante: un ecosistema fatto di composizione, di piccoli pezzi molto specializzati che funzionano benissimo richiede un cambiamento di mentalità in senso pragmatico e di cultura della product ownership”.

Una questione di product ownership

Quel che Alessandro ha appena detto mi risuona molto. In definitiva torniamo sempre al tema del prodotto e del valore. La sfida è fare bene il lavoro del product owner, identificando i bisogni e risolvendo i problemi. La differenza qui è la scala: non stiamo più sviluppando la singola app, ma un servizio che viene utilizzato in un contesto più ampio. Tenendo a mente anche che qui stiamo lavorando in un’ottica di collaborazione tra le aziende, dove vanno tenute presenti componenti anche molto variate e diversificate.

So che potrà aggiungere ulteriori riflessioni, e mi congedo da lui solo temporaneamente. “Non credere di essertela cavata con queste ‘storielle’ e basta”, gli dico scherzando.

“Ho capito che ti piacciono le storie di vita vissuta e ne ho diverse altre da raccontarti, alcune delle quali proprio relative al mondo automotive in cui stai operando attualmente”.

“Grazie Alessandro. Ci sarà sicuramente l’occasione. E credo anche presto, visto come si stanno muovendo le cose”.

Riferimenti

[1] La scheda personale di Alessandro Giardina sul sito Intré
https://www.intre.it/author/ale_giardina/

[2] Matthew Skelton – Manuel Pais, Team Topologies: Organizing Business and Technology Teams for Fast Flow. IT Revolution, 2019
https://teamtopologies.com/book

[3] unFIX. Organization design for continuous innovation & better human experience
https://unfix.com/

[4] Melvin Conway, How do committees invent?. Datamation, April 1968
https://www.melconway.com/Home/pdf/committees.pdf

[5] Kong API Gateway
https://konghq.com/products/kong-gateway

[6] Chargebee, sistema di gestione del licencing
https://bit.ly/3PiwAwp