Silo e feudi

Il successo di qualsiasi modifica importante alle procedure, alla cultura o alle operazioni tecnologiche di un'azienda richiede una mentalità volta allo sviluppo. Al centro della mentalità della crescita è la capacità di accettare il cambiamento e fornire la leadership nonostante l'ambiguità.

Alcuni antipattern bloccano la mentalità della crescita nelle organizzazioni che vogliono crescere e trasformare. Questi antipattern includono micromanagement, pensiero pregiudiziato e procedure di esclusione. Molti di questi blocchi rappresentano sfide personali che creano opportunità di crescita personale per tutti. Ma due antipattern comuni in IT, silos e fiefdoms, richiedono più di una crescita individuale o maturità per affrontare.

Questi antipattern sono il risultato di modifiche organiche all'interno di vari team, che comportano comportamenti organizzativi non integri. Per affrontare la resistenza causata da ogni antipattern, è importante comprendere la causa radice della formazione.

Team IT organici e integri

È naturale creare una divisione del lavoro nell'IT. È corretto stabilire team con competenze simili, processi condivisi, un obiettivo comune e una visione allineata. È anche naturale che i team abbiano una propria microcultura, norme condivise e prospettive.

I team IT integri si concentrano sul partner con altri team per promuovere correttamente il completamento dei compiti. I team IT integri cercano di comprendere gli obiettivi aziendali supportati dal contributo tecnologico. I dettagli e gli effetti fiscali potrebbero essere fuzzy, ma il contributo del valore del team viene in genere compreso all'interno del team.

Anche se i team IT sani hanno una passione per la tecnologia supportata, sono aperti a cambiare e disposti a provare nuove cose. Questi team sono in genere i più antichi e più forti collaboratori al centro dell'eccellenza (CCoE). Si vuole incoraggiare pesantemente il loro contributo.

Resistenza naturale al cambiamento

Talvolta, le microculture all'interno di team IT integri possono reagire in modo non integro alle decisioni della direzione o dall'alto volte a favorire il cambiamento. Questa reazione è naturale, come collettive umane con norme condivise spesso collaborano per superare minacce esterne.

Persone talvolta visualizzare le modifiche che influiscono sui lavori giornalieri del team, sul senso di sicurezza o sull'autonomia come rischio per il collettivo. I segni di resistenza sono in genere un indicatore iniziale che i membri del team non si sentono come fanno parte del processo decisionale.

Quando gli architetti del cloud e altri leader investono nell'abolire i pregiudizi personali e guidare per i team IT inclusivi, la resistenza al cambiamento è probabile ridurre rapidamente e dissolversi nel tempo. Un CCoE è uno strumento che aiuta gli architetti e i leader del cloud a creare decisioni inclusive.

Attrito sano

È facile confondere la resistenza con l'attrito. I team IT esistenti sono comunemente informati sugli errori precedenti, sui rischi tangibili, sulle conoscenze tribali sulle soluzioni e sul debito tecnico non documentato. Sfortunatamente, anche i team IT più sani possono cadere nella trappola di descrivere questi importanti punti dati come parte di una soluzione tecnica specifica che non dovrebbe essere modificata. Questo approccio alla comunicazione maschera la conoscenza dei team e crea una percezione di resistenza.

Fornendo a questi team un meccanismo di comunicazione nella terminologia di ricerca futura aggiunge punti dati, identifica le lacune e crea un attrito sano intorno alle soluzioni proposte. Questo attrito aggiuntivo scende verso i bordi ruvidi della soluzione e determina valori a lungo termine. La semplice modifica della conversazione può creare chiarezza intorno a soggetti complessi e generare energia per offrire soluzioni più riuscite.

Le indicazioni sulla definizione dei criteri aziendali facilitano le conversazioni basate sui rischi con gli stakeholder aziendali. Ma è possibile usare questo stesso modello per facilitare le conversazioni con i team che vengono percepiti come resistenti al cloud. Quando la percezione della resistenza è diffusa, può essere opportuno includere procedure di risoluzione delle resistenze nella dichiarazione di intenti per un team di cloud governance.

Antipattern

La crescita organica e reattiva all'interno dell'IT che crea team IT integri può anche comportare antipattern che bloccano la trasformazione e l'adozione del cloud. Solo e feudi IT sono diversi dalle microculture naturali che si creano all'interno di team IT integri. In entrambi i modelli, l'attenzione del team tende a essere indirizzata alla protezione del "feudo". Quando i membri del team si confrontano con un'opportunità di modifica e miglioramento delle operazioni, investono più tempo e energia per bloccare il cambiamento rispetto alla ricerca di una soluzione positiva.

Come accennato in precedenza, i team IT integri possono creare una resistenza naturale e attriti positivi. Silo e feudi rappresentano una sfida diversa. Non esiste alcun indicatore iniziale documentato per l'antipattern. Questi antipattern tendono a essere identificati dopo mesi di attività del Cloud Center of Excellence e del team di cloud governance. Vengono individuati come risultato di una resistenza in corso.

Anche nelle culture tossiche, gli sforzi del CCoE e del team di cloud governance dovrebbero contribuire a guidare la crescita culturale e il progresso tecnico. Dopo mesi di attività, alcuni team potrebbero ancora non mostrare segni di comportamenti inclusivi e restare solidi nella loro resistenza al cambiamento. Questi team probabilmente operano in uno dei modelli antipattern seguenti: silo e feudi. Anche se questi modelli si presentano in modo simile, la causa radice e gli approcci per affrontare la resistenza sono radicalmente diversi tra loro.

Silos IT

I membri del team in un silo IT sono probabilmente definiti attraverso l'allineamento a alcuni fornitori IT o a un'area di specializzazione tecnica. Tuttavia, non si devono confondere i silo con i feudi IT. I silos tendono a essere guidati da comfort e passione, e i silos sono talvolta più facili da superare rispetto alle motivazioni guidate dalla paura dietro i fiefdomi.

Questo antipattern spesso emerge da una passione comune per una soluzione specifica. I silo IT vengono quindi rinforzati dalle competenze avanzate del team in seguito all'investimento in tale soluzione specifica. Questa competenza superiore è un acceleratore degli sforzi di adozione del cloud se è possibile superare la resistenza al cambiamento. Può anche diventare un blocco importante se i silo sono frammentati o se i membri del team non riescono a valutare con precisione le opzioni. Fortunatamente, è in genere possibile superare i silos IT senza apportare modifiche significative al grafico dell'organizzazione.

Superare la resistenza rappresentata dai silo IT

È possibile risolvere i silos IT tramite gli approcci seguenti. L'approccio migliore dipende dalla causa radice della resistenza.

Creare team virtuali: la sezione Idoneità organizzativa del Cloud Adoption Framework descrive una struttura a più livelli per l'integrazione e la definizione di quattro team virtuali. Un vantaggio di questa struttura è rappresentato dalla visibilità e dall'inclusione tra organizzazioni. L'introduzione di un centro cloud di eccellenza crea un team aspirazione ad alto profilo che i principali tecnici vogliono partecipare. Questa modifica consente di creare nuovi allineamenti tra soluzioni che non sono associati ai vincoli del grafico dell'organizzazione. Esso guida anche l'inclusione di top engineer che sono stati riparati da silos IT.

L'introduzione di un team di strategia cloud crea visibilità immediata sui contributi IT relativi alle attività di adozione del cloud. Quando i silo IT tendono a favorire la separazione, questa visibilità può aiutare a motivare i responsabili IT e aziendali a supportare correttamente i membri del team più resistenti. Questo processo rappresenta un rapido percorso per l'engagement e il supporto degli stakeholder.

Prendere in considerazione la sperimentazione e l'esposizione: è probabile che i membri del team in un silo IT siano stati vincolati a pensare in un determinato modo per un certo periodo di tempo. L'interruzione di questa mentalità unidirezionale rappresenta un primo passo per affrontare la resistenza.

La sperimentazione e l'esposizione sono strumenti potenti per sfondare le barriere nei silo. I membri del team potrebbero essere resistenti alle soluzioni concorrenti, quindi non è consigliabile metterli a capo di un esperimento che compete con la soluzione esistente. Tuttavia, come parte di un primo test del carico di lavoro del cloud, l'organizzazione deve implementare soluzioni concorrenti. Il team in silo deve essere invitato a partecipare come fonte di input e revisione, ma non come decision maker. Comunicare chiaramente questo approccio al team con un impegno per coinvolgere più profondamente i decision maker prima di passare a soluzioni di produzione.

Durante la revisione della soluzione concorrente, usare le procedure descritte in Definire i criteri aziendali per documentare i rischi tangibili dell'esperimento e stabilire criteri che aiutano il team siloato a diventare più comodo con lo stato futuro. Questo approccio espone il team a nuove soluzioni e rafforza la soluzione futura.

Essere "senza limiti": i team che guidano l'adozione del cloud trovano facile spingere i limiti esplorando nuove e interessanti soluzioni native del cloud. È una metà dell'approccio per rimuovere i limiti. Tuttavia, questo modo di pensare può rafforzare ulteriormente i silo IT. La spinta a un cambiamento troppo repentino e senza rispetto per la cultura esistente può creare attriti sfavorevoli e causare una resistenza naturale.

Quando i silo IT iniziano a opporre resistenza, è importante dimostrare di essere "senza limiti" nelle proprie soluzioni. Tenere presente una semplice verità: le soluzioni native del cloud non sono sempre le migliori. Si considerino soluzioni ibride che potrebbero offrire l'opportunità di estendere gli investimenti esistenti del silo IT in futuro.

Si considerino anche le versioni basate sul cloud della soluzione che il team del silo IT usa attualmente. Sperimentare le soluzioni e ottenere l'esposizione al punto di vista dei membri del team che lavorano nel silo IT. Almeno, si otterrà una nuova prospettiva. In molte situazioni, si potrà ottenere il rispetto del silo IT per ridurre la resistenza.

Investire nell'istruzione: molte persone che convivono in un silo IT si sono appassionate alla soluzione corrente in seguito all'espansione della propria formazione. Investire nella formazione di questi team raramente è inopportuno. Concedere a queste persone il tempo di partecipare a forme di apprendimento automatico, a corsi o persino conferenze per interrompere l'attenzione quotidiana sulla soluzione corrente.

Per l'istruzione essere un investimento, è necessario vedere un ritorno dalla spesa. In cambio dell'investimento, il team può illustrare la soluzione proposta agli altri team coinvolti nell'adozione del cloud o fornire la documentazione dei rischi tangibili, degli approcci di gestione dei rischi e dei criteri desiderati per l'adozione della soluzione proposta. Ogni vantaggio coinvolge i team nella soluzione e usa le proprie conoscenze tribali.

Trasformare i blocchi in trampolini: i silo IT possono rallentare o arrestare qualsiasi trasformazione. La sperimentazione e l'iterazione trovano un modo, ma solo se il progetto continua a muoversi. Concentrarsi sull'attivazione di ostacoli alla velocità. Definire i criteri in base a cui tutti possono trovarsi temporaneamente a proprio agio in cambio di una progressione continua.

Ad esempio, se la sicurezza IT è il ostacolo perché la soluzione di sicurezza non può monitorare i dati protetti compromessi nel cloud, stabilire i criteri di classificazione dei dati. Impedire la distribuzione dei dati classificati nel cloud fino a quando non si trova una soluzione accettabile. Invitare la sicurezza IT a sperimentare soluzioni ibride o native del cloud per monitorare i dati protetti.

Se il team di rete opera come silo, identificare i carichi di lavoro autonomi e senza dipendenze di rete. In parallelo, è possibile sperimentare, esporre ed educare il team di rete mentre si lavora su soluzioni ibride o alternative.

Dimostrarsi pazienti e inclusivi: procedere senza il supporto di un silo IT appare allettante. Ma questa decisione causa interruzioni e ostacoli lungo la strada. Cambiare idea del silo IT può richiedere tempo. Siate pazienti con la loro resistenza naturale. Convertirlo in valore. Essere inclusivi e invitare un attrito salutare per migliorare la soluzione futura.

Non competere mai: il silo IT esiste per un motivo. Persiste per un motivo. C'è un investimento nella gestione della soluzione a cui i membri del team sono appassionati. Competere direttamente con la soluzione o il silo IT distrae dall'obiettivo reale di raggiungere i risultati aziendali. Questa trappola ha bloccato molti progetti di trasformazione.

Rimanere concentrati sull'obiettivo, anziché su un singolo componente dello stesso. Contribuire ad accentuare gli aspetti positivi della soluzione del silo IT e aiutare i membri del team a prendere decisioni oculate sulle soluzioni migliori per il futuro. Non insultare o degradare la soluzione corrente, perché sarebbe controproducente.

Collaborare con l'azienda: se il silo IT non blocca i risultati aziendali, perché preoccuparsene? Non c'è una soluzione perfetta o un fornitore IT perfetto. La concorrenza esiste per un motivo: ognuno ha i propri vantaggi.

Accettare la diversità e includere l'azienda supportando e allineandosi a un team di strategia cloud solido. Quando un silo IT supporta una soluzione che blocca i risultati aziendali, è più facile comunicare tale ostacolo senza il rumore delle squabb tecniche. Il supporto di silo IT non bloccanti mostra come collaborare per i risultati aziendali desiderati. Questi sforzi guadagnano maggiore rispetto e maggiore sostegno all'azienda quando un silo IT presenta un blocco legittimo.

Feudi IT

È probabile che i membri del team in un feudo IT si definiscano in base all'allineamento a un processo o a un'area di responsabilità specifica. Il team opera presupponendo che l'influenza esterna sul suo settore di responsabilità porti a problemi. I fiefdomi tendono ad essere un antipattern guidato dalla paura, che richiede un significativo sostegno della leadership per superare.

I fiefdom sono particolarmente comuni nelle organizzazioni che hanno avuto un ridimensionamento it, una turbolenza frequente nel personale IT o una scarsa leadership IT. Quando l'azienda vede l'IT esclusivamente come un centro di costo, è molto più probabile che si presentino dei feudi.

In genere, i feudi sono il risultato di un line manager che teme la perdita del team e della power base associata. Questi leader spesso hanno un senso di dovere per i loro team e sentono la necessità di proteggere i loro subordinati da conseguenze negative. Frasi come "proteggere il team dal cambiamento" e "proteggere il team dall'interruzione del processo" sono indicatori di un manager sorvegliato eccessivamente che potrebbe aver bisogno di più supporto dalla leadership.

Risolvere la resistenza dei feudi IT

I fiefdom it possono dimostrare la crescita seguendo gli approcci per affrontare la resistenza al silo IT. Prima di provare a risolvere la resistenza rappresentata da un feudo IT, è consigliabile trattare prima il team come un silo IT. Se questi tipi di approcci non riescono a produrre modifiche significative, il team resistente potrebbe essere soggetto a un antipattern sotto forma di feudo IT. La causa principale dei fiefdomi IT è un po' più complessa da affrontare, perché tale resistenza tende a provenire dal responsabile della linea diretta (o leader in alto nell'organizzazione). Le sfide che sono basate su silo IT sono in genere più facili da superare.

Quando la continua resistenza di un feudo IT blocca le attività di adozione del cloud, può essere opportuno un impegno combinato per valutare la situazione con i leader IT esistenti. I responsabili IT devono prendere attentamente in considerazione le informazioni dettagliate del team di strategia del cloud, del centro di eccellenza del cloud e del team di governance del cloud prima di prendere decisioni.

Nota

I responsabili IT non devono mai prendere alla leggera eventuali modifiche all'organigramma. Devono anche convalidare e analizzare i commenti e suggerimenti di ognuno dei team di supporto. Tuttavia, gli sforzi di trasformazione come l'adozione del cloud tendono a ingigantire i problemi sottostanti che sono passati inosservati o non sono stati risolti molto tempo prima. Quando i feudi impediscono il successo dell'azienda, è probabile che sia necessario apportare modifiche alla leadership.

Fortunatamente, la rimozione del leader di un fiefdom non termina sempre. Questi leader forti e appassionati spesso passano a un ruolo di gestione dopo un breve periodo di riflessione. Con il giusto supporto, questo cambiamento è sano per il leader del fiefdom e il team corrente.

Attenzione

Per i responsabili dei feudi IT, proteggere il team dai rischi è un chiaro valore di leadership. Tuttavia, c'è una linea sottile tra protezione e isolamento. Quando il team è bloccato a partecipare ai cambiamenti di guida, può avere conseguenze psicologiche e professionali per il team. La voglia di opporsi al cambiamento potrebbe essere forte, soprattutto nei periodi di cambiamento visibile.

Il responsabile di qualsiasi team isolato può dimostrare al meglio una mentalità di crescita sperimentando le linee guida associate ai team IT sani nelle sezioni precedenti. La partecipazione attiva e ottimistica alle attività di governance e CCoE può portare a una crescita personale. I responsabili dei feudi IT sono nella posizione migliore per cambiare le idee che si sono imposte e aiutare il team a svilupparne di nuove.

I fiefdomi IT sono talvolta un segno di problemi di leadership sistemica. Per superare un fiefdom IT, i responsabili IT hanno bisogno della libertà di apportare modifiche alle operazioni, alle responsabilità e occasionalmente anche alle persone che forniscono la gestione line per team specifici. Quando queste modifiche sono necessarie, è consigliabile affrontare le modifiche con punti dati chiari e defensibili.

L'allineamento con gli stakeholder, le motivazioni e i risultati aziendali potrebbe essere necessario per favorire le modifiche necessarie. La collaborazione con il team di strategia del cloud, il Cloud Center of Excellence e il team di cloud governance può fornire i punti dati necessari per una posizione difendibile. Laddove necessario, questi team devono essere coinvolti in un'escalation di gruppo per risolvere i problemi che non possono essere affrontati solo con la leadership IT.

Passaggi successivi

L'interruzione degli antipattern organizzativi è un lavoro di gruppo. Per agire in base a queste linee guida, esaminare l'introduzione all'idoneità dell'organizzazione per identificare le strutture e i partecipanti del team più idonei:

Individuare le strutture e i partecipanti del team giusti