Come posso incoraggiare una cultura della puntualità in una società di software?

**Il miglior fattore motivante è la fiducia. Le culture delle regole sono alimentate dalla sfiducia, e bastoni e bastoni per far rispettare le regole non faranno altro che erodere ulteriormente la fiducia della vostra squadra.

Piuttosto che preoccuparsi dei tempi esatti e delle culture informali, provate a capire quali sono i valori intrinseci.

• Le 9:30 (o qualsiasi altro orario arbitrario) hanno davvero importanza? Oppure è necessario che il vostro team si assicuri di non ostacolare il lavoro degli altri team con la loro assenza?

• 5 minuti fanno la differenza? **O è più importante che tutti i membri si uniscano allo standup quotidiano?

• L'informalità è un problema? O la flessibilità è un vantaggio? 002 & 002 - Io scaverei al centro del problema, cioè che il vostro team non ha creduto all'idea. Vedere dove si trova la disconnessione, ma **evitare di creare una cultura delle regole. Mandarli a casa per il ritardo (una tattica disciplinare che si trova in una scuola elementare) porterà il vostro team a credere che li vedete come bambini di cui non ci si può fidare.

Creare una cultura della puntualità può richiedere tempo e può essere qualcosa su cui si deve scendere a compromessi. Dato che avete a che fare con lavoratori della conoscenza intelligenti, avrete più successo se riuscirete a farli entrare nel piano. Invece di concentrarvi sul tempo, concentratevi sul problema creato dai problemi di programmazione.

Presentate il problema come una sfida per il team e vedete cosa ne viene fuori. La risposta può essere la programmazione impostata o può essere qualcosa di diverso che risolve il problema. Potrebbe essere lunedì, mercoledì, venerdì sono le 9 del mattino, mentre martedì e giovedì sono i giorni flessibili. Anche se il piano potrebbe non essere perfetto e non sarà esattamente quello che avevi previsto, trovare una via di mezzo da qualche parte che renda felice sia il team di sviluppo, sia risolvere il problema reale impedirà al tuo staff di diventare amareggiato e di vederti come il nemico.

Tenete presente che non avete a che fare con un processo di produzione in cui tutti devono presentarsi esattamente alle 9:30 del mattino, quando fischia il fischio, in modo da poter iniziare l'impegnativo compito di assemblare gli stessi piccoli widget di plastica ripetutamente, fino a quando il fischio non fischia di nuovo, e il personale con la mente intontita si dirige verso il bar locale per l'happy hour.

Il mio team non si presenta in tempo. Ho cercato di costringerli e non funziona.

Forzare le persone intelligenti non funziona mai. Dovete ricordare che avete a che fare con persone altamente istruite, intelligenti e creative, che sono brave a risolvere problemi complessi, astratti e unici. Queste persone, almeno quelle veramente brave, non seguiranno mai ciecamente gli ordini. Questo significa rimettere il problema nelle loro mani, almeno all'inizio. Se non fanno nulla, allora vorrai intervenire con la tua soluzione.

Hai detto che sei un nuovo capo squadra. Entrare in una nuova posizione come questa è impegnativo e stressante, perché non si sa come ottenere il rispetto della squadra e anche essere un buon leader. Questo viene con l'esperienza, ed è comune per i nuovi leader inesperti che cercano di “costringere” o forzare le persone a fare le cose a modo loro. Non si tratta di leadership.

Gli sviluppatori e gli altri lavoratori della conoscenza non hanno bisogno di un manager, ma di un leader. I grandi leader ispirano gli altri a fare grandi cose, e questa è la vostra opportunità di condurre il vostro team alla grandezza piuttosto che dettarla alla disperazione.

La ricerca mostra che le persone sono più propense a impegnarsi quando hanno partecipato a determinare quale sarà la soluzione, piuttosto che avere quella soluzione detto a loro, e questo è soprattutto vero con i lavoratori della conoscenza.

Per l'ispirazione, si veda l'Intervista di Seth Godin sulla Differenza tra Leadership e Management . Raccomando vivamente a tutti, e a tutti coloro che hanno una capacità di leadership, di assistere a questa breve intervista.

La mia esperienza mi ha insegnato che ai lavoratori della conoscenza non piace essere costretti a sottostare a politiche per le quali non hanno alcuno scopo. Lei afferma uno scopo, ma i dipendenti che gestisce sembrano pensare che non sia buono. Inoltre, probabilmente ci sono alternative che non avete considerato e, dato quello che sembra un problema “dettato dall'alto”, i vostri dipendenti potrebbero non averci pensato, non si sentono a loro agio a proporle o pensano che sarebbero semplicemente abbattuti.

Se l'unico motivo per cui state attuando la politica è la tensione con le persone di altri reparti, è vostro compito gestire tale tensione in modo che i vostri dipendenti possano lavorare nel modo più efficace. Non credo che questa sia l'unica ragione, però. Ad esempio, cosa succede se è necessario uno sviluppatore per risolvere un problema di produzione urgente che si verifica alle 8:00 o alle 9:00 o qualsiasi altro orario? Tuttavia, è improbabile che sia necessario tutti gli sviluppatori presenti per risolvere quel problema. Che cosa succederebbe se aveste un programma a rotazione (a meno che qualcuno non si offra volontario) “in anticipo”, in modo che ogni sviluppatore prenda il turno di essere presente alle 8:00 (o alle 9:00, ecc.)? Questa soluzione sembra più adatta a soddisfare sia le esigenze aziendali che i desideri dei vostri dipendenti. Tutti “condividono il dolore” (o lo infliggono a chi non se ne preoccupa). Le persone possono entrare e lavorare il più delle volte quando ritengono di essere più produttivi. Questa è solo una possibilità, ma può generare discussioni con i vostri dipendenti su come risolvere i problemi reali e soddisfare gli interessi di tutti.

Se scegliete di seguire la via più disciplinare, e la questione dell’“orario di inizio” è davvero importante per i vostri sviluppatori, perderete i vostri buoni dipendenti a favore di altri impieghi. È probabile che i vostri dipendenti si sentano insicuri nel loro lavoro (e se un giorno dovesse accadere una vera emergenza per far arrivare qualcuno in ritardo?) Inoltre, questo può essere visto come un cambiamento di gestione nella direzione sbagliata (dal punto di vista dei vostri dipendenti), dal momento che in precedenza hanno avuto esperienza di lavoro sotto qualcun altro.

Dipende da voi, naturalmente, ma vi esorto a fare un passo indietro e a cercare di vedere la situazione dal punto di vista dei vostri dipendenti. Avete un lavoro da fare, naturalmente, ma penso che ci siano soluzioni che soddisfano meglio gli interessi di tutti rispetto a quella da voi proposta.

La risposta precisa alla tua domanda è licenziare e sostituire qualcuno che non recepisce il messaggio e poi licenziare qualcun altro che non recepisce il messaggio.

Non mi aspetto che questo aiuti la tua carriera o gli obiettivi di sviluppo della tua azienda, ma hai deciso che questo è il problema e sembra che non ci sia modo di convincerti del contrario. Ecco come fare.

Più costruttivamente, vi suggerirei di considerare quanto segue:

• I vostri sviluppatori hanno avuto tempo flessibile. Ora volete toglierli

Non importa se si tratta di un beneficio ufficiale in qualche politica scritta o meno. È una politica di fatto e fa parte della cultura consolidata. La vita e gli orari delle persone sono stati stabiliti intorno a queste ore. E per i devs come me, che preferiscono evitare l'ora di punta e che si beccano un terribile caso di SAD in inverno, ma non riesco a pensare a nessun posto più vicino all'equatore in cui preferirei vivere, è una cosa tanto importante quanto ottenere benefici per la salute.

• Qual è la natura di questa “angoscia” di cui parla? È a) principalmente gelosia o b) legittime questioni di comunicazione interdipartimentale come la difficoltà di programmare incontri/comunicazione generale.

a) I Devs non hanno bisogno di interagire con i clienti o con altre aziende. Secondo la mia esperienza, più la struttura aziendale è rigida, più i Devs sono mediocri. Mentre la maggior parte dello sviluppo è un processo creativo di risoluzione dei problemi, è anche un processo di risoluzione dei problemi che richiede che le persone siano al massimo livello. È anche un processo imprevedibile, basato su scadenze imprevedibili, che a volte si traduce in ore molto, molto tardive. Un effetto collaterale di questo è che spesso i progettisti ricevono il trattamento “creativo”. In un'azienda di 30 persone non dovrebbe essere difficile insistere sul fatto che le persone siano adulte riguardo ai dipendenti che hanno bisogno di essere al massimo dell'acutezza quando sono presenti e che, in ultima analisi, probabilmente impiegheranno molte più ore nell'arco di un anno di un 9-5er che di solito fa le valigie alle 16:55 ogni giorno.

b) In un'azienda di 30 persone, non si dovrebbero fare così tante riunioni che questo diventa un problema. Non contare cose come le riunioni di sprint o altre sessioni di pianificazione bimestrale, legare i vostri devs per più di 30 minuti ogni giorno in riunioni è un assurdo, grossolanamente incompetente spreco di denaro. Lo stesso vale per la comunicazione generale. 30 persone significa andare a parlare con l'altro e parlare con lui. In scenari di tempo flessibile è ragionevole stabilire un arco di tempo in cui tutti sono in ufficio alla stessa ora. Non riesco a pensare a una buona ragione per cui quel lasso di tempo sia superiore a 3-4 ore della giornata lavorativa e perché non dovrebbe essere il più vicino possibile a metà giornata.

• Perché uno standup mattutino?

Perché la prima idea di gestione degli scarti di mischia, agile, ecc… è sempre il consiglio di non avere lo standup come prima cosa? Nella programmazione ci vuole un po’ di tempo per tornare alla piena consapevolezza di tutti i dettagli e di tutti i problemi che si stanno affrontando su un determinato problema. Quando si fanno gli standups come prima cosa, i vostri sviluppatori non avranno la testa completamente avvitata. Gli standup sono fondamentali per la comunicazione e il miglioramento dell'efficienza, non qualcosa che si fa per “togliersi di mezzo”.

• I vostri sviluppatori non riescono a portare a termine il lavoro?

In caso contrario, perché incasinare una cosa buona? Non è loro compito comunicare con le altre preoccupazioni dell'azienda. È compito vostro. In una struttura manageriale sana di mente, la vostra responsabilità è nei confronti del vostro diretto superiore e delle persone che gestite, non dell'uva acida di altri reparti che devono essere presenti ad orari più tipici per motivi pratici.

La prima cosa da fare è andare a leggere “Peopleware”

È un errore cercare di cambiare questa situazione adesso. Ero un manager in una società in cui avevamo un orario di lavoro piuttosto flessibile. Uno dei nostri sviluppatori più produttivi è arrivato alle 11 del mattino. Mi ha fatto rapporto per un po’. Mi è stato detto di fargli cambiare gli orari. Mi sono opposto a questa richiesta. Duramente. Sono stato respinto.

Il risultato:

Uno sviluppatore meno produttivo, meno interessato, che ha contribuito molto al team. È diventato molto meno produttivo e utile per il team.

Il tutto a causa di una stupida nozione di “puntualità”.

Concentratevi di più sulla produttività.

Il vostro lavoro come manager è quello di rimuovere le barriere alla produttività - non fate sembrare, sentire e agire tutti allo stesso modo.

Gli orari flessibili sono un vantaggio - e un datore di lavoro che permette orari flessibili può attrarre più persone di qualità.

Come “nuova guida tecnica” non c'è modo di cambiare presto la cultura. Soprattutto nella direzione che sembrate volere. Avete fatto qualcosa per migliorare i ruoli e i lavori del vostro team?

Lavorate prima di tutto per costruire la fiducia con loro. Molti manager/leader alla prima volta commettono errori del genere.

Trova ciò di cui gli altri gruppi hanno veramente bisogno. Non “devono essere qui alle 9:30”. Scoprite davvero qual è il problema. Poi trova una soluzione a questo.

** Invece di dire al tuo team cosa fare - spiega il problema e poi CHIEDI LORO PER SUGGERIMENTI/FEEDBACK.**

Fai un vago riferimento a “provoca molta angoscia tra il mio dipartimento e gli altri dipartimenti” - ma non è chiaro cosa sia questa angoscia - sono sconvolti dal fatto che i devs siano trattati in modo preferenziale? Qual è il vero problema di fondo?

Ho cercato di costringerli e non funziona.

C'è una ragione per questo. E non sembra che tu mi stia ascoltando. Raggiungere misure più drastiche e martelli più grandi non miglioreranno la situazione. Provate l'approccio della “carota” invece di quello del “bastone”.

Ancora una volta, leggete “Peopleware”.

Non andrete lontano con idee come le riunioni quotidiane o l'idea di mandare le persone a casa o con l'idea che sono i vostri tirapiedi che devono fare come dite voi, “altrimenti”.

Chi vi sta dicendo che devono essere al lavoro alle 9:30? Altri gruppi? I vostri capi? Voi? Scoprite il VERO problema e affrontatelo. Quando si presentano NON dovrebbe essere il problema.

Indipendentemente dal motivo per cui lo fai, per i membri del tuo team è come se ti portassi via un vantaggio. Per alcuni di loro potrebbe anche essere uno dei motivi principali per cui lavorano per la vostra azienda piuttosto che per un'altra.

In sostanza, chiedete loro di prendere una riduzione del loro pacchetto retributivo totale.

È possibile convincerli ad accettare, ma avrete bisogno di buoni argomenti e quasi certamente ci sarà un risentimento persistente al riguardo. Potreste o non potreste perdere delle brave persone per questo.

Dalla vostra descrizione la ragione principale sembra essere la gelosia degli altri dipartimenti. Avete pensato di dare agli altri reparti lo stesso vantaggio?

In breve: non fatelo, a meno che non pensiate che valga la pena di perderne qualcuno per questo.

Per cambiare la tua cultura devi capire perché stai vivendo una resistenza e poi gestirne la causa.

Nella mia esperienza, il “coordinamento con altri dipartimenti” tende ad essere la provincia di quelli con titoli di posizione più alti e a capo di un percorso di gestione di progetti/persone. I dipartimenti che si interessano solo di codice tendono ad essere schermati da questo. Nei negozi più strutturati, potrebbero non farlo affatto e nei negozi più piccoli, potrebbero farlo in modo più informale.

Che ti piaccia o no, hai ereditato una cultura del flex hours, che è un enorme vantaggio per la maggior parte degli sviluppatori. Togliergliela in uno dei tuoi primi atti come leader non solo gli sembrerà tirannico (quando spiegherai loro che le 9:30 non è quello presto, stai imponendo loro il tuo programma, arbitrariamente secondo loro), ma è realisticamente la sottrazione di un vantaggio sostanziale. Potrebbe piacerti lavorare su un programma particolare e non considerarlo un vantaggio significativo, ma loro probabilmente lo considerano inestimabile. Consideratelo alla pari con il dire loro che gli state togliendo una settimana di ferie o che gli state tagliando la paga di qualche punto percentuale.

Per cambiare questo, potete usare la carota o il bastone. Stai parlando di usare un bastone e, forse, un bastone più grande. Se si segue questa strada, ho intenzione di assumere qualche nuovo sviluppatore, perché immagino che alcuni del vostro team cominceranno a fare colloqui di lavoro presso altre aziende. Personalmente farei la strada della carota per ottenere l'acquisto per la rimozione di questo vantaggio, chiarendo che le promozioni e gli avanzamenti futuri saranno decisi da coloro che “si coordinano con gli altri dipartimenti”. Cioè, i leader/le persone importanti sono in anticipo, lavorano con altri team, si assumono responsabilità, ecc. I “neofiti” ottengono il flex perk, ma le persone seriamente intenzionate ad avanzare arrivano in tempo.

Se create questa cultura, ho il sospetto che alcuni dei vostri sviluppatori cominceranno ad arrivare in tempo di propria iniziativa. Sia per l'interesse ad avanzare, sia per la percezione che “le persone importanti arrivano in anticipo”.

Non ti invidio per questo - come collega manager, sarebbe difficile per me. E, onestamente, credo che perderai delle persone per questo. Penso che lei abbia un singolo sintomo che deriva dal cambiamento di cultura della Start Up -> Medium Sized culture shift, e non tutti gli sviluppatori riusciranno a fare questo cambiamento con successo. Penso che tu debba essere preparato con le descrizioni dei lavori e la conoscenza di come apri le richieste di lavoro e penso che tu debba mettere l'accento sulla capacità di assumere nuove persone e migliorare la documentazione…

Scusami se è così triste. Ma non credo che abbiate una situazione di problemi di fiducia, o un caso in cui possiate spiegare facilmente le persone in accordo. E non c'è davvero nessun compenso che bilanci perfettamente l'enorme flessibilità sul lavoro.

Sono d'accordo che vi state togliendo un vantaggio. La flessibilità nell'orario di inizio è un grosso problema per alcune persone, e parla di una cultura informale che può essere una forte preferenza per alcune persone. Presumibilmente con la crescita dell'azienda, il carico di lavoro è diventato più affidabile, la sicurezza del lavoro è migliorata, il rispetto per il prodotto è aumentato, e potreste essere stati in grado di offrire alcuni piani di stock nifty, aumenti di stipendio o altri miglioramenti. Se nulla di tutto ciò è vero, allora dovete chiedervi se avete un'azienda in crescita e fiorente o un'azienda che sta sprofondando nella disperazione.

Il trucco è che spesso le persone non riescono a collegare i punti tra questi nuovi valori aggiunti e la rimozione del vantaggio preferito. Si può provare a spiegarlo, ma per alcune persone questo non è un buon compromesso, e non è un caso in cui si possa offrire la scelta. È un “mio modo o autostrada” perché ha un impatto organizzativo che non è necessariamente percepibile all'interno del team, ma che è sperimentato e supportato ai livelli superiori dell'azienda.

Sembra che tu abbia fatto le cose giuste:

• l'hai spiegato chiaramente

• hai parlato del motivo e della necessità di un cambiamento

• hai impegnato uno contro uno (e continui a farlo, presumo) per risolvere i singoli casi man mano che si presentano

• hai dato un feedback

Credo che tu sia giunto al “lo pensa davvero? ”, dove per lo più si tratta di dimostrare alla gente che fai sul serio e che questo deve davvero cambiare. La mia opinione personale è che essere in ritardo di 5 minuti in un ufficio della mia regione non è un grosso problema e che le riunioni che hanno un breve lasso di tempo (come alzarsi in piedi in un agile sprint) non dovrebbero essere così dure contro l'inizio della giornata lavorativa che un collegamento di autobus perso o un cattivo traffico sarà un problema regolare. Ma questo è un po’ regionale - le diverse località hanno ampie variazioni nella situazione del traffico. Quindi è tanto conoscere la propria regione quanto sapere da singoli reclami ciò che è ragionevole.

Il resto è solo un meccanismo abbastanza debilitante da dimostrare che si fa sul serio. Un giorno di paga arretrata è un'opzione e rientra nei vostri diritti legali - anche se qualsiasi meccanismo mi venisse in mente, lo farei attraverso gli avvocati. Così come un sistema di avvertimento formale che porta ad un'azione discplinare. Suppongo che il vostro dipartimento delle Risorse Umane potrebbe avere dei suggerimenti…

Molto dipende da ciò che il lavoro può tollerare - quando mandate qualcuno a casa, perdete anche il lavoro di quella giornata, il che ha un impatto sui vostri costi e sul vostro programma. Quando si dispone di un sistema di allarme che porta ad azioni disciplinari - compreso il licenziamento - si risparmia il resto della giornata di lavoro, ma si rischia di dover licenziare il dipendente.

Penso che il fatto è che, quando si tratta di punizioni, bisogna essere preparati con una punizione abbastanza dannosa da essere presa sul serio e da portare a casa il punto che “non si fa il proprio lavoro se non lo si fa”.

La risposta breve è che NON dovreste farlo. I membri del vostro team tecnico sono (o almeno, dovrebbero essere) abbastanza intelligenti da sapere che non c'è un beneficio tangibile nell'avere tutti presenti in ufficio entro un certo tempo arbitrario; la sola metrica importante è se il loro lavoro viene svolto o meno.

Se il vostro team non sta svolgendo il suo lavoro, allora questo è un problema a parte. Ma se stanno portando a termine il loro lavoro, allora perché li molestate solo perché altri reparti vi hanno molestato?

Parte del vostro ruolo di leader è quello di isolare il vostro team da banali distrazioni e critiche causate da fonti esterne. Se la vostra reazione alle altre persone che si lamentano dei membri del vostro team è quella di trasmettere le lamentele ai membri del vostro team e/o dettare modifiche basate esclusivamente su tali lamentele, allora state fallendo nel vostro lavoro. Suggerirei che, supponendo che il vostro team stia effettivamente svolgendo il suo o i suoi compiti (cosa che sembra essere, visto che non vi lamentate della loro produttività), un modo migliore per rispondere a tali critiche è quello di dire al denunciante “sì, beh, i miei ragazzi lavorano sodo e forniscono costantemente risultati solidi, e questa è l'unica cosa che conta; quindi perché non smettete di preoccuparvi di come il mio team gestisce i loro compiti e tornate ai vostri? ”.

E naturalmente, se si segue una politica obbligatoria “devi essere in ufficio entro il tempo X”, è giusto integrarla con una politica “devi lasciare l'ufficio entro il tempo Y”, e una politica “non devi lavorare da casa al di fuori del normale orario di lavoro”. Questo è giusto solo come un modo per proteggere l'equilibrio tra lavoro e vita privata del vostro dipendente, poiché scommetto che molti dei membri del vostro team che non si presentano fino alle 11:00 probabilmente rimangono a casa fino a tardi o fanno del tempo extra a casa.

Sembra che ci sia uno scollamento tra il modo in cui i vostri sviluppatori vedono il problema e il modo in cui gli altri dipartimenti (o i vostri superiori, o chiunque sia a richiedere questo cambiamento) vedono il problema. Suggerirei di cercare di colmare questa lacuna, in più fasi, se necessario.

Innanzitutto, gli sviluppatori sono d'accordo che ci sono buone ragioni per questo cambiamento? Se non sono d'accordo, hanno qualche buona contro-argomentazione o suggerimenti alternativi? In caso affermativo, dovreste portarli alla direzione e vedere se possono allentare i tempi richiesti - o se possono spiegare perché le alternative non funzionano e le contro-argomentazioni non risolvono il problema, in modo che possiate tornare dai vostri sviluppatori e dare loro una spiegazione più completa. Continuate a fare avanti e indietro per tutto il tempo necessario/produttivo.

Se arrivate al punto in cui gli sviluppatori sono d'accordo che ci sono buone ragioni ma non sono disposti ad adattarsi, o non pensano che le ragioni siano buone e si risentono dell'intera idea, comunicatelo al management. Spiegate che potreste costringere gli sviluppatori a fare ciò che si vuole, ma ciò causerà risentimento, minore motivazione, molto probabilmente minore produttività o anche dipendenti che se ne andranno. Assicuratevi che la direzione lo capisca e che sia comunque d'accordo che è importante far rispettare l'orario di inizio (e ancora una volta, comunicatelo ai vostri sviluppatori), altrimenti potreste finire per essere responsabili di un cambiamento che ha perso l'azienda più di quanto abbia guadagnato.

(Una nota personale: mi è stato detto di venire ad un'ora prestabilita per, per quanto riguarda i dipendenti, nessuna buona ragione, ed è davvero estremamente demotivante. È davvero importante assicurarsi che la gente capisca le ragioni e non si senta come se si cambiasse la politica per un capriccio o perché non ci si fida di loro)(Una nota personale: mi è stato detto di venire ad un'ora prestabilita per quanto riguarda i dipendenti, senza una buona ragione, ed è davvero estremamente poco motivante.

Lavoravo in un'organizzazione no profit che aveva questo problema. Le riunioni iniziavano sempre in ritardo, 10 minuti di ritardo diventavano uno “standard”.

Poi abbiamo avuto un nuovo project manager per un grande progetto chiave (e uno su una linea temporale fissa). Ha convocato la prima riunione. La gente entrava come al solito, con minuti di ritardo e chiacchierando con disinvoltura. Si è seduta sulla sua sedia e non ha detto niente - niente di niente - per diversi minuti. Alla fine le chiacchiere si sono “spente” fino al silenzio. Aspettavamo tutti che ci sentissero parlare. Lei ha permesso che il silenzio continuasse ancora per un po’. Si guardò intorno e disse: “Devo mettere le cose in chiaro. Gli incontri cominciano in orario. Se arrivi 5 minuti in ritardo, non disturbarti a venire, vieni a trovarmi dopo. OK, ora per il progetto che faremo questa settimana [qualunque sia]…”. Questo ha fatto una GRANDE impressione e le persone hanno fatto un vero sforzo per essere puntuali per le sue riunioni.

Nota: Aggiunta risposta aggiuntiva qui sotto.

Considera il lavoro svolto in remoto.

Spesso i produttori più alti fanno gran parte del loro lavoro in ogni caso in remoto, quindi a volte ci mettono tanto tempo in remoto quanto in ufficio. Questo è un punto importante sia da considerare che da comunicare con gli altri reparti. Questa comunicazione dovrebbe essere sottile - non convocare una riunione, ma iniziare a cercare il modo di mostrare “sì, Joe è stato sveglio fino a tardi ieri sera a lavorare su x” e “sì, Mary ha stabilito che domenica è rimasta sveglia fino a mezzanotte”.

Parlare apertamente del pendolarismo. Se qualcuno arriva alle 10.30, il suo tragitto può durare 15 minuti. Se deve arrivare alle 9 o alle 9.30, il tragitto può durare un'ora. In più, sarebbe lo stesso andare a casa se lavorasse 8 o 9 ore. Molte persone pensano che questo sia un grande spreco della loro vita. Preferiscono lavorare a distanza per un po’ e poi entrare dopo. Cercate di integrare questo fatto con le vostre esigenze quando impostate gli orari e assicuratevi che anche gli altri reparti lo sappiano, sempre menzionandolo spesso.

Assicuratevi di usare tecnologia per aiutare. Per esempio, io lavoro virtualmente - il 100% del tempo. Quindi anche avere Skype acceso, mostrare il mio stato online, una video-cam, ecc. può essere d'aiuto.

Essendo stato in situazioni simili, anche se certo in meno tempo rispetto all'OP, ho solo questo da dire sullo stato della sua situazione:

La soluzione più pratica e più semplice…

…sarebbe invece quella di provare ad iniziare le riunioni alle 11 in punto. Non preoccuparti, non ti stai “arrendendo”. Invece stai reindirizzando il flusso molto simile ai principi che stanno dietro Aikido . L'idea è invece di concentrarsi su come consentire al vostro team di ottenere cose importanti fatto come è il punto fondamentale, perché c'è davvero un problema serio che deve essere affrontato:

La squadra non ha davvero idea di ciò che è su con gli altri reparti e che cosa hanno davvero bisogno di fare.

Avere il tuo team a presentarsi alle 9:30 che posso ammettere non è presto è tuttavia non è una soluzione a questo problema. Avete tentato e fallito, quindi smettete di insistere per farlo . Smettila di sbattere la testa su un muro di mattoni. Il mio unico consiglio è quello di dare sempre più valore alla comunicazione che alle riunioni fissate arbitrariamente.

Dal momento che gli altri reparti iniziano alle 8 puoi utilizzare questa riunione tardiva del team a tuo vantaggio. Tra le 8 e le 11 hai 3 ore per aiutare il tuo team nelle attività di project management come (in nessun ordine particolare o priorità):

• Andare alle riunioni e raccogliere obiettivi e requisiti dagli altri reparti
• Capire cosa è stato finito da ieri
• Gestire le aspettative e gli impegni con gli altri reparti su ciò che deve e può essere fatto durante la giornata lavorativa
• Fornire notizie buone e cattive agli altri reparti
• Aggiornare eventuali piani rilevanti per il team se ci sono
• Capire quali sono i problemi di codice e di architettura del software che devono avere attenzione oggi
• Dire “NO” alle richieste che non forniscono alcun valore commerciale
• Accettare le critiche degli altri appartamenti e scusarsi con la garanzia che i problemi saranno risolti
• ecc. (c'è sempre qualcosa che deve essere affrontato)

E infine, prima dell'incontro summerizzare un brief per il team su ciò che sta accadendo, in modo da dare loro una certa consapevolezza della situazione. Quando la riunione inizia alle 11 e tutti sono freschi di lavoro, si hanno a disposizione informazioni e un protocollo di riunione preparato per loro. Potete far scrivere il brief e i verbali dell'incontro come una newsletter e inviarlo come una e-mail qualche tempo dopo l'incontro come un dolce promemoria.

Durante l'incontro con il team avete bisogno di due cose da loro:

• Chiedete stime per i compiti che devono essere svolti, specialmente quelli che sono ad alta priorità. Non è necessario che sia preciso, come in pochi minuti. Con questo potete decidere impegni e scadenze molto più chiaramente con gli altri reparti. Se non sono in grado di dare una stima per un compito, chiedete loro di capirlo durante il giorno o il giorno successivo.
• Chiedete impedimenti o se hanno bisogno di aiuto per qualsiasi cosa, annotatelo e verificate se questi problemi sono risolvibili e che vengano risolti.

Dopo un po’ di tempo potete probabilmente spostarvi gradualmente per avere le riunioni prima. Ma inizialmente andare controcorrente non è la strada da percorrere e porta solo a una cultura ancora più contagiosa (in cui l'unico modo per riparare è sostituire l'intera squadra). Se sono, come dici tu, “primadonne”, allora il tuo vero lavoro è quello di ristrutturarle in fantastiche primadonne che offrono un'alta qualità. È chiaro che il tuo team ha avuto e vuole autonomia , quindi inizia a sfruttare quella cultura a vantaggio degli obiettivi della tua azienda.

Quando sei riuscito a creare una squadra affidabile, attraverso la comunicazione piuttosto che la coercizione, puoi andartene tre ore prima di tutti gli altri membri del team sapendo che stanno facendo il loro lavoro (ma che sono ancora in servizio se la merda colpisce il ventilatore). **Ora, questa è la fiducia su cui si può contare.

Gli altri sollevano molti punti positivi su come gestire la situazione; tuttavia, alla fine della giornata, se il programma del vostro gruppo sta disturbando gli altri in azienda, allora dovete correggere il problema e assicurarvi che le cose vadano bene. Con questo in mente, dovete scoprire quando gli altri gruppi hanno bisogno di un accesso affidabile agli sviluppatori e se c'è spazio per la flessibilità in quel programma. Se altri gruppi hanno bisogno di accedere agli sviluppatori quando sono in ufficio su una base imprevedibile, allora un segmento centrale di sviluppatori deve assicurarsi che tale necessità sia soddisfatta. Se questo significa che alcuni sviluppatori devono essere in ufficio a periodi di tempo fissi, allora è quello che è.

Per quanto riguarda lo spostamento degli sviluppatori verso una sorta di programma di disponibilità fissa, la cosa migliore da fare è assicurarsi che le “ore difficili” siano ammorbidite il più possibile. Ad esempio, se le “ore centrali” sono dalle 11:00 alle 15:00, allora potete anche fare in modo che le ore centrali del venerdì non siano presenti e che il venerdì sia un vero giorno di tempo flessibile. Poiché martedì, mercoledì e giovedì sono tradizionalmente considerati i giorni più produttivi della settimana, si può fare in modo che le ore fondamentali si applichino a quei giorni e che il lunedì e il venerdì siano anche giorni di flex completo.

In termini di garantire che le ore siano rispettate, se la direzione scende dall'alto e viene approvata dalla direzione superiore, allora alla fine gli sviluppatori devono attenersi ad essa come parte del loro lavoro. Dovreste fare il possibile per assicurarvi che sia introdotto gradualmente e se alcuni sviluppatori hanno un orario flessibile scritto nel loro contratto di lavoro, questo dovrebbe essere affrontato (ad es. cambiando il loro compenso e i loro benefici, nonno, ecc.); tuttavia, ad un certo punto dovrete assicurarvi che la politica debba essere rispettata, il che potrebbe anche richiedere una disciplina ufficiale dei dipendenti. Allo stesso modo, se alcuni scelgono di andarsene, potrebbe valere la pena di provare a vedere se sono disposti a rimanere con i cambiamenti di compensi e benefici; tuttavia, potreste anche dover accettare di perdere alcuni degli sviluppatori.

In definitiva, se il vostro lavoro richiede di imporre un cambiamento culturale al gruppo per soddisfare le esigenze dell'azienda, allora le vostre opzioni saranno limitate in una certa misura. Potete e dovete fare tutto il possibile per ammorbidire il cambiamento e suscitare eventuali compromessi con altri gruppi, ma alla fine dovrete far rispettare il cambiamento e accettare qualsiasi cambiamento di personale che ne derivi.

Sto leggendo commenti e risposte e devo confessare che sono un po’ sbalordito. Da quando avere gente che si presenta in orario è una “perdita di un vantaggio”? Da quando il flex-time non deve preoccuparsi dell'impatto delle sue azioni sul resto del team e dell'azienda?

Da quanto ho letto nella domanda e nei commenti, il comportamento dei suoi membri del team si dimostra dannoso e costoso per l'azienda. E dopo aver cercato di ragionare e di scendere a compromessi, la situazione non è migliorata (e btw, 9.30 è non precocemente o in alcun modo irragionevole).

Spieghi al suo team che non ha problemi con il tempo di flessione, ma che implica una certa dose di responsabilità personale per assicurarsi che la sua flessione non abbia un impatto sul lavoro degli altri (sul suo team o su altri team). Poiché il vostro team sta chiaramente fallendo nella parte di responsabilità, direi che, con effetto immediato e fino a nuovo avviso, tutti i tempi di flessione devono essere approvati da voi in anticipo. Non presentarsi in orario al mattino senza approvazione o senza una scusa ragionevole (no, la sveglia non ha suonato la sveglia non è accettabile) **porterà a un'azione disciplinare come il docking pay o il tempo di ferie.

Sia molto chiaro il motivo di ciò che sta accadendo e cosa l'ha costretta a prendere queste misure. Sottolineate che non è qualcosa che volete fare, ma qualcosa che siete stati forzati a fare. Sia anche chiaro che queste politiche restrittive possono essere revocate una volta che la situazione migliora.

Ci sono ancora diverse possibilità per gestire questo problema, una di queste sarebbe quella di cambiare il ruolo che il reparto svolge, come ad esempio: Se lavorate con gli sviluppatori di software, potreste cambiare il ruolo di un certo o più persone durante la settimana per far sì che facciano da supporto agli altri dipartimenti, il che richiede che ne arrivino 1 o più alle 9 o prima e se questo non funziona potreste sempre invocare una clausola di insubordinazione che normalmente è presente in qualsiasi manuale di lavoro negli Stati Uniti. Personalmente sono sempre stato contrario all'uso di questa clausola, che dà a un manager la possibilità di rimproverare e persino di licenziare qualcuno per causa, ma nel tuo caso questo potrebbe essere appropriato. Quindi, esaminate il manuale per i dipendenti** e discutetene con il vostro superiore se ne avete uno.

L'idea di base è la seguente:

1. 1. Stabilite la regola che almeno 1-2 o tutte le persone devono essere al lavoro entro l'ora X.
2. Se i membri del vostro team non hanno una scusa valida per non presentarsi o persistere in questa pratica, voi come manager dovreste rimproverarli ed eventualmente licenziarli.

Come manager che fa quello che ho descritto sarebbe l'ultimo ricorso**, ma in base a quello che descrivete potreste essere arrivati a quel punto. Ci sono molti articoli che potrebbero costituire un'insubordinazione dei dipendenti che potete trovare online e questi sono solo alcuni esempi:

• BlogSpot
• Duhaime

Naturalmente la sfortunata conseguenza potrebbe essere un alto tasso di turnover nel vostro gruppo che si rifletterebbe male su di voi come manager ma che farebbe rispettare la disciplina e probabilmente ucciderebbe il morale nel processo.

Ora, detto tutto questo, ho una domanda: Hai davvero bisogno che il tuo team sia presente prima di loro quando arrivano?

In sostanza, devi decidere cos'è più importante, portare a termine il lavoro in modo corretto o stare seduto alla tua scrivania per 8 ore ad orari prestabiliti?