Da quanto si posta nel thread dello status lavorativo, parrebbe che vi sia un certo insieme di tipo team leader, business unit manager, project manager...insomma di profili che perseguono responsabilmente obbiettivi tramite il coordinamento di colleghi subordinati nell’organigramma.
In seguito a specifico avvenimento, l’altro giorno riflettevo a riguardo di quali sono o sarebbero le migliori metodologie per prendere decisioni in tutti quei casi in cui due o più colleghi, magari di distinte funzioni (es produzione e acquisti), opinano in maniera divergente rispetto ad uno specifico tema del quale noi, per forza di cose, non conosciamo i dettagli operativi.
Vi capita o è mai capitato?
Difficile che troveremo un common ground per un confronto su un tema così ampio.
Dipende tantissimo dal ruolo, dall’industria, dai valori aziendali e dal proprio stile di leadership.
La mia esperienza è su team relativamente piccoli che si occupano di soluzioni di ML e Analytics in ambiente AWS. Nel mio caso ho trovato funzionale creare delle forti specializzazioni con relativamente poche aree di overlap tra risorse del team e le soluzioni di design vengono condivise con me e da me validate.
In questo modo do ownership e un percorso di carriera molto più definito ai ragazzi e minimizzo i conflitti intra-team.
Per quanto riguarda invece il coordinamento Inter-team, dipende dai flussi e processi aziendali.
Nel nostro caso molte volte siamo in uncharted territory (non esiste un processo predefinito perché il progetto è nuovo e gli stakeholder si siedono al tavolo assieme per la prima volta) e in genere vince un mix tra carisma e forza politica interna dei team leader / responsabili di funzione.
In pratica li bastono e faccio prevalere il mio disegno o la mia visione su quella degli altri team coinvolti
Inefficiente e stressante, in quanto mancano i processi di lavoro disegnati a monte dal nostro Director...
Sent from my iPhone using Tapatalk
Dipende tantissimo dal ruolo, dall’industria, dai valori aziendali e dal proprio stile di leadership.
La mia esperienza è su team relativamente piccoli che si occupano di soluzioni di ML e Analytics in ambiente AWS. Nel mio caso ho trovato funzionale creare delle forti specializzazioni con relativamente poche aree di overlap tra risorse del team e le soluzioni di design vengono condivise con me e da me validate.
In questo modo do ownership e un percorso di carriera molto più definito ai ragazzi e minimizzo i conflitti intra-team.
Per quanto riguarda invece il coordinamento Inter-team, dipende dai flussi e processi aziendali.
Nel nostro caso molte volte siamo in uncharted territory (non esiste un processo predefinito perché il progetto è nuovo e gli stakeholder si siedono al tavolo assieme per la prima volta) e in genere vince un mix tra carisma e forza politica interna dei team leader / responsabili di funzione.
In pratica li bastono e faccio prevalere il mio disegno o la mia visione su quella degli altri team coinvolti
Inefficiente e stressante, in quanto mancano i processi di lavoro disegnati a monte dal nostro Director...Sent from my iPhone using Tapatalk
C'è una cosa importantissima da tenere in considerazione: tendenzialmente i KPI assoluti delle funzioni di solito sono in contrasto tra loro. Massimizzarne uno, nell'organizzazione, porta a farne soffrire un altro da qualche altra parte dell'organizzazione, solitamente (pe. avere tanto stock per facilitare il fulfillment rispetto all'immobilizzazione di capitale).
Questo per dire che: l'organizzazione ha delle eccellenze e delle priorità, solitamente le persone vanno riportare al concetto di ingranaggi dell'orologio, per far capire che ci sono dei trade off indispensabili, che si tirano dietro del necessario change management, sia processuale, che organizzativo (eg. staff augmentation) che potenzialmente sistemico.
Poi ci sono dei momenti in cui, se si ha la leadership o l'empowerment necessario, si possa andare a dire "si fa così, perchè sì"
Questo per dire che: l'organizzazione ha delle eccellenze e delle priorità, solitamente le persone vanno riportare al concetto di ingranaggi dell'orologio, per far capire che ci sono dei trade off indispensabili, che si tirano dietro del necessario change management, sia processuale, che organizzativo (eg. staff augmentation) che potenzialmente sistemico.
Poi ci sono dei momenti in cui, se si ha la leadership o l'empowerment necessario, si possa andare a dire "si fa così, perchè sì"
Io non ho esperienza diretta da team lead in quanto non ho supporti diretti e sono "single contributor" pero' nella mia esperienza di sviluppo prodotto digitale non esiste che qualcuno prenda le decisioni per me, tanto meno il mio TL
il TL per me e' quello che fa la mia valutazione semestrale, raccoglie i miei feedbakc, mi approva le ferie, segue il mio percorso di crescita, ma sa poco o niente del mio lavoro ne' tantomeno prende decisioni a riguardo.
Il product manager prende decisioni di sviluppo del prodotto in sieme a tutto il team, e una volta prese le decisioni si occupa di portarle avanti e quindi che ogni membro del team delivery nella sua parte, io faccio il modello, il designer fa la UX i dev sviluppano fanno roll out ecc. poi la decisione finale se andare avanti ad iterare o meno viene presa collettivamente dal team.
componenti superiori tipo group product menager e directors tantomeno mettono bocca su quello che facciamo, se non per dare linee strategiche di massima.
per quanto riguarda i conflitti se insorgono e' compito dei componenti del team che si trovano in conflitto affrontarlo, a quel punto magari si tirare in mezzo un TL o manager per risolverlo, o semplicemente ritornando al team e prendendo una decisione collettiva. detto cosi' e' tutto molto bello ma ovviamente e' chiaro che se ci sono caratteri prevaricanti vs passivi puo' anche essere che la soluzione sia diversa
il TL per me e' quello che fa la mia valutazione semestrale, raccoglie i miei feedbakc, mi approva le ferie, segue il mio percorso di crescita, ma sa poco o niente del mio lavoro ne' tantomeno prende decisioni a riguardo.
Il product manager prende decisioni di sviluppo del prodotto in sieme a tutto il team, e una volta prese le decisioni si occupa di portarle avanti e quindi che ogni membro del team delivery nella sua parte, io faccio il modello, il designer fa la UX i dev sviluppano fanno roll out ecc. poi la decisione finale se andare avanti ad iterare o meno viene presa collettivamente dal team.
componenti superiori tipo group product menager e directors tantomeno mettono bocca su quello che facciamo, se non per dare linee strategiche di massima.
per quanto riguarda i conflitti se insorgono e' compito dei componenti del team che si trovano in conflitto affrontarlo, a quel punto magari si tirare in mezzo un TL o manager per risolverlo, o semplicemente ritornando al team e prendendo una decisione collettiva. detto cosi' e' tutto molto bello ma ovviamente e' chiaro che se ci sono caratteri prevaricanti vs passivi puo' anche essere che la soluzione sia diversa
Darth siete organizzati tipo in squad/tribes/groups a la Spotify?
simile ma un po' piu' tradizionale. di simile c'e' la componente molto indipendente in cui ogni team ha responsabilita' diretta su un prodotto e autonomia forte dal decidere gli obbiettivi al come eseguirli. poi il team e' inserito in una track di 5/6 team che ha uno scopo omogeneo.
altra similitudine e' il fatto che la parte di management sia divisa tra people management e product management: quindi ogni team ha un TL e un PM, che si occupano o delle persone o del prodotto, questo fa si che come dicevo prima il mio TL, che si occupa della mia valutazione, non puo' dirmi cosa fare. a sua volta il PM che puo' tendenzialmente spingermi di piu' sul cosa fare, non si occpua della mia valutazione. e' un sistema che funziona e trovo molto sano.
non abbiamo quella struttura strana di spotify con la matrice incrociata di craft e product in cui ogni individuo e' praticamente inserito in due team contemporaneamente, che infatti leggevo recentemente hanno abbandonato anche loro: https://www.jeremiahlee.com/posts/failed-squad-goals/
altra similitudine e' il fatto che la parte di management sia divisa tra people management e product management: quindi ogni team ha un TL e un PM, che si occupano o delle persone o del prodotto, questo fa si che come dicevo prima il mio TL, che si occupa della mia valutazione, non puo' dirmi cosa fare. a sua volta il PM che puo' tendenzialmente spingermi di piu' sul cosa fare, non si occpua della mia valutazione. e' un sistema che funziona e trovo molto sano.
non abbiamo quella struttura strana di spotify con la matrice incrociata di craft e product in cui ogni individuo e' praticamente inserito in due team contemporaneamente, che infatti leggevo recentemente hanno abbandonato anche loro: https://www.jeremiahlee.com/posts/failed-squad-goals/
Eh, azienda straniera e si vede
Qui da noi è una giungla organizzativa e vince ancora chi lo sbatte più forte sul tavolo e convince l’hippo di turno
Sent from my iPhone using Tapatalk
Qui da noi è una giungla organizzativa e vince ancora chi lo sbatte più forte sul tavolo e convince l’hippo di turno
Sent from my iPhone using Tapatalk
Per me non esiste non sapere cosa facciano i membri del team, altrimenti la figura diventa inutile.
C'è tantissima letteratura e ci sono anche corsi di svariati livelli di preparazione e costi, niente però ti può preparare a prendere una decisione su qualcosa di cui non sai nulla.
Inviato dal mio SM-G935F utilizzando Tapatalk
C'è tantissima letteratura e ci sono anche corsi di svariati livelli di preparazione e costi, niente però ti può preparare a prendere una decisione su qualcosa di cui non sai nulla.
Inviato dal mio SM-G935F utilizzando Tapatalk
Io - ma è una best practice nella mia compagnia- faccio daily check-in e check-out col team per allinearci con le priorità e gli obiettivi della giornata
Potresti dettagliare un po’ di più, magari, se possibile, con qualche esempio può?
Mi sembra molto limitativo.
Solo per fare un esempio di mille, secondo te un CEO o un managing director già anche di una middle company ha un’idea anche solo minimamente dettagliata di tutta la struttura informatica della stessa?
Non è che tutti i manager devono sapere tutto di qualsiasi aspetto, devono sapere in cosa consiste il lavoro dei propri riporti.
Il CEO come tutti gli altri manager ha dei riporti, anche in numero limitato rispetto ad altre funzioni, ma sa di cosa si occupano. Nel tuo esempio dipende dal settore, nelle aziende in cui l'informatica non è il core business il CEO non ne sa nulla, se non magari il nome di qualche gestionale se è particolarmente innovativo o ha avuto un costo rilevante. Al CEO probabilmente risponde un COO, a cui risponde un CIO a cui risponderanno dei team leader a cui risponderanno i vari dipendenti che si occupano della parte informatica. Neanche il CIO sa nel dettaglio cosa fanno gli informatici essendo una figura manageriale, sa cosa fanno i team leader il cui lavoro non è fare gli informatici ma gestire un gruppo di persone e valutarle con delle metriche predeterminate.
Ognuno degli step sa probabilmente abbastanza per valutare e decidere riguardo il livello appena sotto di lui e magari qualcosa del livello successivo.
Inviato dal mio SM-G935F utilizzando Tapatalk
A me la giornata sembra eccessivo, però probabilmente dipende dal tipo di industry.
Nell'ultimo programma di formazione executive che ho fatto con l'HBS c'erano delle statistiche sull'efficacia dell'azione dei leader e si consigliava per una unit di dimensioni moderne (4-6, più raramente 8 risorse) almeno un meeting a settimana di 1 ora.
Era poi suggerito in caso di alta professionalizzazione un ulteriore meeting che non avesse però tematiche strettamente lavorative: quindi immagina un meeting di lunedì a parlare di tematiche lavorative ed uno il venerdì a fine giornata a parlare del più e del meno ed ad entrare in ambito lavorativo solo come review dell'attività del lunedì.
Nei meeting il leader deve parlare poco e far parlare tutti e adattare con ogni persona e con il gruppo uno stile comunicativo appropriato.
Inviato dal mio SM-G935F utilizzando Tapatalk
Nell'ultimo programma di formazione executive che ho fatto con l'HBS c'erano delle statistiche sull'efficacia dell'azione dei leader e si consigliava per una unit di dimensioni moderne (4-6, più raramente 8 risorse) almeno un meeting a settimana di 1 ora.
Era poi suggerito in caso di alta professionalizzazione un ulteriore meeting che non avesse però tematiche strettamente lavorative: quindi immagina un meeting di lunedì a parlare di tematiche lavorative ed uno il venerdì a fine giornata a parlare del più e del meno ed ad entrare in ambito lavorativo solo come review dell'attività del lunedì.
Nei meeting il leader deve parlare poco e far parlare tutti e adattare con ogni persona e con il gruppo uno stile comunicativo appropriato.
Inviato dal mio SM-G935F utilizzando Tapatalk
Io lavoro in consulenza, dove abbiamo deliverables con scadenze brevissime (spesso 1 giorno o meno) e sempre piu' lavoro di quello che e' davvero possibile fare. Di conseguenza abbiamo iterazioni continue per essere sicuri che tutto quello che facciamo aggiunga valore. E che sia fatto bene gia' la prima volta.
Inoltre da manager io gestico multipli workstreams e sono responsabile dello storyline di ognuno e di quello complessivo, quindi devo avere una visione molto puntuale di quello che stiamo facendo.
Da ultimo, noi facciamo un sacco di apprendistato sul lavoro, il che significa che spesso abbiamo colleghi che non hanno mai visto quell'industria quando entrano nel team, e il daily check-in/out mi e gli permette di chiarire quali possono essere i problemi e chiedere aiuto.
Inoltre da manager io gestico multipli workstreams e sono responsabile dello storyline di ognuno e di quello complessivo, quindi devo avere una visione molto puntuale di quello che stiamo facendo.
Da ultimo, noi facciamo un sacco di apprendistato sul lavoro, il che significa che spesso abbiamo colleghi che non hanno mai visto quell'industria quando entrano nel team, e il daily check-in/out mi e gli permette di chiarire quali possono essere i problemi e chiedere aiuto.
Deliverables giornalieri 
Una tragedia, lascia stare
Come gestisci questa cosa? Lavoro approssimativo o lasci indietro le richieste sperando che cadano nel dimenticatoio?
Entrambe le cose credo
Lavora in consulenza e le loro azioni non ricadono su di loro.
Fino a che non vengono arrestati per roba tipo OxyContin
Ovviamente ice ha una morale, ma certe agenzie di consulenza sono parecchio shady.
Il primo step e' sempre negoziare con la leadership e il client, cercando di deprioritizzare quello che non e' essenziale.
Il secondo step e' lavorare fino alle 23/24/1/2, dipende dai giorni, tutti i giorni
