Domanda:
Come posso incoraggiare una cultura della puntualità in un'azienda di software?
Jacob G
2012-04-12 22:34:49 UTC
view on stackexchange narkive permalink

In qualità di nuovo responsabile tecnico in una nuova azienda, quali sono alcune strategie aggiuntive da impiegare per cambiare la cultura del team di sviluppo in modo che le persone si presentino nel momento in cui ho richiesto?

TLDR : il mio team non si presenta in tempo. Ho provato a costringerli e non funziona.

Dati di background:

  1. Piccola azienda, 30 dipendenti, 5 membri del mio team.
  2. Il precedente lead è ancora nello staff come sviluppatore regolare.
  3. La cultura prima del mio arrivo era quella dell'informalità senza limiti fissi o orari di base. Questa cultura non è stata contestata dai leader aziendali. La maggior parte delle persone del team si presentava tra le 10:30 e le 11:00 per questo motivo.
  4. Altri reparti, a causa della natura del loro lavoro, hanno fissato orari di inizio di 8 o 9.

Questa discrepanza e imprevedibilità causa molta angoscia tra i miei dipartimento e altri dipartimenti. In quanto tale, ho fatto sedere la squadra e ho specificato un orario "non più tardi" delle 9:30. Ho spiegato il mio ragionamento e ho spiegato i vantaggi di un tale schema e gli aspetti negativi dello schema attuale. È stata una conversazione lunga e controversa e 3 delle 5 persone del team erano piuttosto scontente.

Inutile dire che le persone non si fanno vedere in tempo (e le 9:35 non sono puntuali).

Ho programmato il nostro incontro quotidiano in piedi alle 9:30 come ulteriore motivazione. Sapendo che ci vuole un po 'di tempo per gli orari di inizio della transizione (con pendolarismo, ecc ...) inizialmente avrei aspettato di iniziare la riunione finché non si fossero presentati tutti, ma ora inizio la riunione (e spesso finisco la riunione) con chiunque sia presente. Anche questo sembra non fare la differenza e rende il team meno coeso.

Le conversazioni su base individuale e di gruppo producono gli stessi risultati della conversazione originale (cioè non vedono il valore, pensa Mi sto togliendo un vantaggio dal lavoro, ecc ...)

Ho il pieno supporto e il sostegno del senior management team e ho il potere di utilizzare tutti i dispositivi che ritengo appropriati per far sì che se ne occupi.

Il mio prossimo passo attuale è mandare qualcuno a casa e fare si prendono il giorno libero. È troppo drastico? Esistono strategie alternative che sto trascurando che potrebbero aiutarmi a risolvere questo problema?

Modifica in base alle domande nella risposta di Jarrod

Che ne dici di un lead tecnico? 6 mesi, in questa azienda, al momento della domanda.

Perché imponi politiche gestionali puramente non tecniche? È nell'ambito della mia posizione definita dalla direzione esecutiva.

Quali sono le tue credenziali di gestione? 10 anni di esperienza come responsabile tecnico. Nessuna istruzione formale o certificazione in nulla di manageriale.

Che esperienza precedente nella gestione del personale hai? Sono stato un responsabile tecnico per 10 anni. Sono stato responsabile per l'assunzione / il licenziamento / il colloquio / la revisione / la guida / la creazione di diversi team tecnici.

Ti sei guadagnato il rispetto del team in modo tecnico?

Ti sei guadagnato il rispetto del team in modo manageriale? Sono stato intervistato per capacità tecniche e gestionali dal team. Sono stato chiaro e diretto su come mi piace gestire i team tecnici e su come mi piace gestire i progetti (con l'ovvia avvertenza che questo è solo un punto di partenza e la cultura e il personale alla fine influenzano dove atterro.) Ci sono molte cose, da un prospettiva manageriale, di cui il team è abbastanza soddisfatto.

Il precedente responsabile tecnico si è dimesso? Sì.

Il precedente responsabile tecnico è stato retrocesso? No. Era una sua richiesta.

Il precedente comando tecnico era efficace? Per un po 'di tempo. Ma la crescita dell'azienda e il codice base hanno reso il suo stile inefficace.

La maggior parte del team esistente ha un rapporto più personale con il precedente responsabile tecnico? Sì.

Il precedente responsabile tecnico è effettivamente ancora in carica? No.

Allora [la precedente cultura dell'informalità senza limiti fissi] deve avere ha funzionato? Ha funzionato per un periodo, quando l'azienda era ancora una startup. È cresciuto e si è evoluto ben oltre la fase di avvio e, a causa di tale crescita, non è così efficace come una volta. Tanto più che altri reparti hanno introdotto un po 'più di formalità e prevedibilità.

Il team è riuscito a fornire prodotti utili quando promesso? All'inizio. Tuttavia, con la crescita dell'azienda e del prodotto, la qualità e i tempi di consegna sono notevolmente diminuiti.

Non sembra che tu abbia nemmeno considerato o esplorato un qualche tipo di compromesso con il tuo team o con i team esterni sulla base del loro feedback negativo. Davvero? Certo che l'ho fatto, non sono un novellino. Il nocciolo della questione è che rispetto il fatto che il resto dell'azienda lavori in una scatola rigida a causa della natura delle loro responsabilità. Il team non era disposto a scendere a compromessi sul tempo di flessibilità e, in molti casi, gli altri reparti non sono in grado di scendere a compromessi. Ho anche affrontato il feedback negativo in modo specifico con gli altri dipartimenti e ho implementato una serie di cose per migliorare le cose. Uno dei grandi vantaggi di questo cambiamento è stato quello di migliorare la prevedibilità e cambiare le percezioni.

Aggiornamento finale

Dall'equipaggio originale di 5 persone, 2 sono stati sostituiti. Il primo era il precedente team leader. Non potevamo vedere negli occhi come eseguire i progetti di sviluppo e non poteva accettare modifiche a ciò che aveva stabilito in precedenza, quindi abbiamo concordato reciprocamente di separarci. Il secondo ha perso interesse per il lavoro, ha commesso un paio di grossi errori e abbiamo anche concordato reciprocamente di separarci.

Il team, nel suo insieme, ora si presenta abbastanza presto per garantire un'ampia copertura per il resto dell'azienda. Ciò che alla fine ha funzionato è stato il mandato e la pressione dei pari. Inoltre, altri cambiamenti che sono stati introdotti hanno portato a risolvere quasi tutte le angosce interdipartimentali. Tutti possono ancora lavorare su progetti fantastici, per lo più a loro scelta, al proprio ritmo in un'azienda entusiasmante e sono tutti abbastanza contenti nonostante il mercato del lavoro sia ridicolo nella zona.

Sono stato promosso a una posizione esecutiva e il nuovo "team problematico" è stato spostato sotto di me (oltre a mantenere il controllo del team di sviluppo e ancora in via di sviluppo). Ora sto lavorando per aiutarli a ottenere risultati migliori ed essere migliori compagni di squadra per i loro colleghi. Non ho problemi di puntualità con questo nuovo team ... I loro problemi sono la precisione e la comunicazione.

Forse un diverso tipo di motivazione, come una ciambella * solo * per coloro che si presentano in orario o presto. Potrebbe essere costoso farlo ogni giorno, quindi forse fallo solo una volta alla settimana, ma non dirgli * quale * giorno ...;) Non l'ho mai provato, quindi è per questo che sto piuttosto postando come commento di una risposta.
Una cosa importante manca a questa domanda: *** PERCHÉ *** stai apportando questo cambiamento? Il lavoro non viene svolto in modo tempestivo? C'è un problema reale che deve essere risolto (ed è questo il modo giusto per risolverlo? Potrebbe essere un argomento per un'altra domanda ...) Come ha sottolineato Andrew nella sua risposta, dettando un arbitrario "non dopo" tempo di inizio della conoscenza i dipendenti che hanno già una cultura del tempo flessibile saranno impopolari ed è difficile suggerire motivatori / metodologie senza più contesto ...
@voretaq7: Penso che "Questa discrepanza e imprevedibilità causi molta angoscia tra il mio dipartimento e gli altri dipartimenti" significa che gli altri dipartimenti devono essere in contatto con il dipartimento di OP. e quando un gruppo arriva alle 9 del mattino e dipende da altri che non si presenteranno fino alle 11 o giù di lì, causa problemi.
@FrustratedWithFormsDesigner Molto probabilmente ma poi se lo sviluppatore mette il lavoro sulla scrivania del designer alle 8 di sera per essere testato tra le 9 e le 11 di domani mattina non vedo alcun problema. Preferisco il coordinamento a regole arbitrarie. Sto anche cercando di non fare supposizioni, ma l '"angoscia" potrebbe essere altrettanto facilmente "Le vendite piangono perché anche loro vogliono arrivare tardi e se non possono nessuno può!"
Sei disposto a far rispettare il rovescio della medaglia della regola della "campanella scolastica"? Ognuno interrompe quello che sta facendo e se ne va in un momento certo, non importa quanto lavoro potrebbe ancora essere annullato?
@JimInTexas è più una regola "Core Hours". Devi essere in ufficio dalle 9:30 alle 4:00 ... puoi oscillare prima o dopo come preferisci.
@voretaq7, nel mondo aziendale, un manager deve agire quando altri reparti si lamentano. I dipendenti di quei reparti non vedono perché devono essere presenti a orari prestabiliti e gli sviluppatori no. Sono sicuro che sia stato indirizzato a risolvere il problema.
@HLGEM Tuttavia, questo dipende dalla natura del reclamo: a volte l'azione giusta come manager è dire agli altri reparti "Questo è il modo in cui lavora il mio team e funziona per l'azienda. Tough Rocks". - Nel caso di Jacob, anche se i suoi sviluppatori sembrano essere delle primedonne viziate con problemi di atteggiamento [vedi questa discussione in chat] (http://chat.stackexchange.com/transcript/message/4208458#4208458) e alcuni dei commenti sotto. ..
@JacobG: Quindi le persone in altri reparti * hanno bisogno * di avere incontri faccia a faccia con gli sviluppatori del tuo team su base regolare, tanto che avere gli sviluppatori al lavoro alle 11 del mattino interferisce seriamente con questo? Perché è necessaria così tanta interazione faccia a faccia tra i reparti? *È necessario? Partecipare a queste riunioni è davvero un buon uso del tempo dei tuoi sviluppatori o il coordinamento può avvenire a un livello superiore (ad esempio, tra * te * e altri reparti)? Non metto in dubbio la tua descrizione della situazione, ma mi sembra strano.
@KeithThompson: L'interazione tra i reparti è frequente e spesso dovuta a necessità di collaborazione. Siamo una piccola azienda e un piccolo team di sviluppo e dobbiamo indossare più cappelli nell'SDLC, supportare i nostri ambienti di produzione e aiutare anche gli altri reparti a soddisfare i loro risultati. Molti di noi in azienda hanno cose sensibili al tempo da consegnare e di solito non c'è abbastanza tempo per dedicare giorni al coordinamento. Corro sulle interferenze il meglio che posso, ma non posso sopportare tutto da solo e ho bisogno che il resto della squadra sia disponibile.
* Inutile dire che le persone non si fanno vedere in tempo (e le 9:35 non sono puntuali.) * Questo suona dittatoriale, micro-gestionale e tirannico. Sembra che tu abbia bisogno di servitori; cerca quei tipi di personalità quando l'attuale equipaggio lascia.
Nel momento in cui dici: (e le 9:35 non sono puntuali.) Mi dai subito l'impressione che tu sia un capo duro e avrei meno probabilità di ascoltare quello che dici. I programmatori praticamente ovunque hanno sempre la flessibilità dell'orario di lavoro e la maggior parte delle volte le persone cadono in una routine, è improbabile che siano imprevedibili quando arriveranno. Le persone lo fanno principalmente per ciò che funziona meglio per loro e, a sua volta, ciò le rende più produttive.
@JarrodRoberson e tsoverflow - Ovviamente siete i benvenuti alle vostre opinioni, ma penso che siate un po 'fuori limite con la vostra iperbole. Non sono né "tirannico" né "idiota", ma mi aspetto che le persone si presentino alle riunioni in tempo e siano pronte a partecipare.
Sembra ancora che il problema sia con * tu * non con il resto della squadra. Hai un tono dittatoriale qui, posso solo immaginare come ti imbatti nelle persone che dovresti * guidare *. La sensazione che provo è che questa sia la prima o la seconda volta in questa posizione e pensi che dovrebbero fare come dici tu perché sei tu a comandare. Esiste una cultura nel bene o nel male; devi adattarti e cambiarlo con l'esempio dall'interno. Sei venuto qui chiedendo aiuto, ma non vuoi ascoltare le opinioni di nessuno. Questo dovrebbe davvero essere * Come posso piegare i miei dipendenti alla mia volontà? *
colazione a base di bagel, ciambelle, caffè, ecc. imballare tutto alle 9:30
Non so cosa pensate tutti, ma discutere per più di cinque minuti non è un modo efficace né produttivo per trascorrere il tempo con la squadra.
@Spoike - Potrebbero essere necessari solo 5 minuti ma sono ancora in ritardo. Se non possono nemmeno presentarsi su TIME 9/10 volte, come può l'autore fidarsi di loro?
@Ramhound: Ogni volta che ho persone che arrivano tardi per le riunioni, sinceramente ** non mi interessa **. Finisco per parlare con persone che sono in tempo (discutendo della giornata, della vita, qualunque cosa ... sai ... conoscendole meglio) e poi vado avanti con i veri affari quando tutti sono arrivati. La fiducia è qualcosa che guadagni attraverso le tue interazioni con altre persone. La punizione (anche se sembra buona nei film di successo di Hollywood) non è il modo in cui crei la tua fiducia con loro.
@Spoike Direi che essere abitualmente in ritardo * alle riunioni * tradisce una mancanza di rispetto per il tempo degli altri che dovrebbe essere affrontato. L'azienda non dovrebbe pagare cinque persone per sedersi intorno a girarsi i pollici a chiacchierare aspettando che tutti arrivino C'è valore in * alcuni * chiacchiere, ecc., Ma una cultura in cui l'attività di una riunione non inizia fino a diversi minuti dopo l'ora di inizio pianificata indica che l'ora non è valutata e rispettata.
@tsOverflow: Se la riunione in piedi è alle 9h30 in punto, allora devi solo programmare il tuo arrivo per le 9h25 e puoi permetterti di arrivare 5 minuti in ritardo in caso di problemi.
@MatthieuM .: OP ha deciso di far venire tutti prima alle 9:30, poi ha programmato di proposito l'incontro alle 9:30 per costringere tutti a venire presto. C'è la differenza tra programmare la riunione in anticipo di proposito in questo modo e avere effettivamente una riunione in quel momento senza l'intenzione di fondo di far venire le persone in un determinato momento.
@JohnMcG: Entrare come nuovo manager per interrompere le cose senza lasciare che nessuno abbia un mandato in merito è un grosso problema, un segno che non ascolti e un segno di mancanza di rispetto. Cambiamenti come questo richiedono tempo, anche anni. Cerca di iniziare a rispettare gli altri prima di * esigere * rispetto. Dalla modifica: il suo team non è disposto a compromettere il tempo flessibile, il che immagino perché hanno un interesse acquisito e probabilmente si sono iscritti per quel tipo di lavoro. Qualunque sia la ragione, è il tuo lavoro di manager occupartene e gestire le aspettative ... o licenziare il team ... ma questa è una cattiva soluzione.
@JacobG: Dalla discussione in chat collegata da voretaq7, sembra che la tua situazione possa essere riassunta come "Devo guidare un dipartimento di primedonne viziate che non fanno il lavoro correttamente, hanno cattivi rapporti con altri dipartimenti e arrivano in ritardo" - in una situazione del genere, "vieni in ritardo" è * l'ultimo dei tuoi problemi *. Tuttavia, potresti essere in grado di utilizzarlo a tuo vantaggio: se puoi concordare con il senior management che la puntualità può essere ridotta in cambio di miglioramenti in altre aree, * e * presentalo come un quid pro quo al tuo team, * puoi * Ottieni miglioramenti ovunque.
@Spoike - Sembra che sarebbe molto difficile lavorare con te. Non sembri pensare che "essere in ritardo" agli occhi del supervisore sia un problema. Non importa quale fosse la politica con il vecchio supervisore ad essere onesti. Se non gradiscono i suddetti cambiamenti, possono andarsene e il nuovo supervisore può sostituirli con persone che SARANNO puntuali.
@Ramhound: Ora stai facendo supposizioni che non ci sono e che non sono richieste. Di solito sono puntuale per le riunioni, e preferisco anche esserci qualche minuto prima e di solito è facile lavorare, almeno questo è quello che mi dicono i miei colleghi sul mio profilo LinkedIn. :-) Tutto quello che sto dicendo è che anche se qualcuno arriva in ritardo per una riunione non voglio spendere tutte le mie energie cognitive per litigare, ci sono cose molto più urgenti a cui occuparmi.
Sono ancora perplesso sul perché perdere una o due ore di finestra al mattino sia così disastroso per il coordinamento con altri reparti. Se i tuoi sviluppatori trascorrono più di un'ora al giorno a fare questo genere di cose, questo è un indicatore per me di una gestione seria (non necessariamente OP) o di un problema culturale. Se gli sviluppatori sono delle prime donas, è possibile che siano tutti dei cretini. È anche possibile che qualcuno li abbia in ore di riunioni al giorno per aggiornamenti costanti sui progressi su tutto il lavoro a cui non possono nemmeno arrivare fino a dopo le 5 quando tutti gli altri se ne vanno. Sono stato lì / ho visto quel colossale spreco di stipendi degli sviluppatori.
* Ho il pieno supporto e il sostegno del senior management team e ho il potere di utilizzare tutti i dispositivi che ritengo appropriati per far sì che se ne occupi. * - E pensi che questo ti aiuterà a imporre una cultura della puntualità? Buona fortuna, amico.
@JimG. Si trattava semplicemente di informazioni potenzialmente rilevanti che qualcuno avrebbe potuto utilizzare per formulare una soluzione produttiva per "incoraggiare" e non "imporre" una cultura della puntualità. Sentiti libero di partecipare alla community e di offrire la tua soluzione produttiva.
La domanda è un ossimoro ....
L'intensità della giornata lavorativa di un programmatore è incomparabile a quella dei lavoratori dell'altro reparto, quindi non possono essere trattati allo stesso modo. Ad esempio, se il tuo lavoro consiste nel rivedere un paio di CV o nel fare una telefonata, ovviamente devi essere presente dalle 9:00 alle 17:00. Voglio dire, ci sono lavori in cui non hai compiti impegnativi, ma la tua presenza è necessaria tutto il giorno, e ce ne sono altri in cui hai una scadenza e una quantità di lavoro da fare prima, indipendentemente da quando arrivi mattina.
* "Ho programmato il nostro incontro quotidiano in piedi alle 9:30 come ulteriore motivazione ..." * - la chiami * "motivazione" *? OH MIO DIO..
C'è qualche motivo per cui devi sottolineare che sei tu a decidere le cose nella tua squadra?
OP suona come un dittatore. "Perché state imponendo politiche gestionali puramente non tecniche? Rientra nell'ambito della mia posizione definita dalla direzione esecutiva." Power-trip molto?
"Abbiamo assunto molte persone a buon mercato in cambio di orari di lavoro super flessibili. Ora che hanno abboccato vorremmo cambiare." Se vuoi "puntualità" metti nel contratto l'orario di lavoro (core).
Sono nuovo del sito e vorrei lasciare qui questa nota: come sviluppatore, vorrei sapere per quale azienda lavorava l'OP al momento in cui ha posto questa domanda, quindi non gli mando mai il mio curriculum.
Leggendo la domanda, i commenti e la chat non è chiaro per me esattamente dove la motivazione per questa 'rimozione dei vantaggi' si trovi tra "dobbiamo coordinarci tra i reparti" e "gli altri reparti sono gelosi del nostro vantaggio". Probabilmente affermando l'ovvio, ma se i tuoi sviluppatori ritengono che il primo motivo sia solo una facciata per il secondo, la reazione che stai ricevendo è completamente prevedibile: già che ci sei, perché non abbassare i loro stipendi per allinearsi con gli altri dipartimenti? Se è davvero il problema della "coordinazione", è un problema ogni singolo giorno? In caso contrario, deve esserci un'altra possibile soluzione
Mi chiedevo perché ci fosse "angoscia" negli altri dipartimenti. Potresti approfondire questo?
@ThorbjørnRavnAndersen Probabilmente stavano interpretando Bright Eyes nel loro reparto.
Se * loro […] pensano che sto portando via un vantaggio del lavoro * è perché lo sei. Potrebbe anche essere giustificato, necessario, irragionevole, dittatoriale ma è quello che è a prescindere.
Quindi il motivo per l'inizio anticipato è che gli altri dipartimenti sono gelosi? Forse hai bisogno di vedere perché 9-5 è diventato uno standard in primo luogo e le molte ragioni per cui non si applica più alla maggior parte degli sviluppatori di software nell'era del telelavoro ...
Diciassette risposte:
#1
+155
Nicole
2012-04-13 00:42:13 UTC
view on stackexchange narkive permalink

Il miglior fattore motivante è la fiducia. L'unità di squadra è di fondamentale importanza per raggiungere i tuoi obiettivi. Le culture delle regole sono allevate dalla sfiducia, e bastoni e stimoli per far rispettare le regole non faranno che erodere ulteriormente la fiducia del tuo team.

Invece di preoccuparti dei tempi esatti e delle culture informali, prova a capire quali sono i valori intrinseci.

  • Le 9:30 (o qualsiasi ora arbitraria) sono davvero importanti? Oppure il tuo team deve assicurarsi di non ostacolare il lavoro di altri team con la loro assenza?

  • 5 minuti fanno la differenza ? Oppure è più importante che tutti i membri si uniscano alla lotta quotidiana?

  • L'informalità è un problema? O la flessibilità è un vantaggio?

Vorrei scavare al centro del problema, ovvero che il tuo team non ha accettato l'idea . Scopri dove si trova la disconnessione, ma evita di creare una cultura delle regole . Mandarli a casa per il ritardo (una tattica disciplinare che potresti trovare in una scuola elementare) porterà la tua squadra a credere che li vedi come bambini di cui non ci si può fidare.

+1 - Penso che questo sia il modo più conciso per formulare il problema * e * le soluzioni. Qualunque sia la regola che imposti per facilitare le cose da fare, è così che dovrebbe essere affrontata con i dipendenti.
Mi piace questa risposta e sono d'accordo con essa. Credo di aver tentato di convincerli a comprendere i problemi di fondo e come sarebbero stati aiutati con una politica Core Hours. Uno sviluppatore ha risposto con superiorità (cioè fanculo gli altri reparti b / c sono speciale) e gli altri si sono concentrati esclusivamente sulla perdita di un vantaggio. Non credo che si vedano come una parte della squadra più grande, piuttosto come la superstar della squadra più grande. Non voglio "rimandarli a casa", ecco perché ho chiesto delle tattiche alternative perché non so cos'altro fare.
@JacobG Sai, il secondo sviluppatore _does_ ha un punto - essere in grado di entrare tra le 10:30 e le 11:00 ** è ** un vantaggio, anche se è uno che non approvi che usi (come, ad es. , fumo si rompe). Non dovresti rimuoverlo senza offrire una qualche forma di risarcimento.
+1 assolutamente d'accordo. Aggiungerei che forse il problema può essere mitigato considerando di avere "copertura" durante le ore centrali piuttosto che avere _tutti_ in loco nelle ore centrali. Alcuni sviluppatori possono offrirsi volontari per presentarsi prima mentre altri rimangono più tardi?
Sono d'accordo con il fattore motivazione, ma non sono d'accordo sul fatto che una cultura delle regole sia una cosa negativa.
quando le persone hanno cattive abitudini, premiarle / compensarle per averle abbandonate non è eccezionale. Preferisco premiare e compensare i risultati.
Alcuni punti positivi, ma non sono d'accordo con la tua premessa. La fiducia, non la sfiducia, abilita le culture delle regole. Il problema dell'OP è che i suoi rapporti non si fidano abbastanza di lui per fare quello che chiede loro. Possono avere ragione a non farlo. Quindi, piuttosto ** Il miglior fattore motivante è l'interesse personale. **
Questo non è un problema di * fiducia * è un problema di * rispetto * e qualcuno dirige il manager che sostiene la sua opinione rispettandola e assicurandosi che la sua voce venga ascoltata. Leggi i commenti sulla mia risposta, non c'è convinzione che il team di sviluppo debba avere voce in capitolo, è un approccio dittatoriale non un approccio insulare alla gestione.
In qualità di team lead o line manager che lavora con persone intelligenti e creative, l'abilità più importante è ascoltare. Finché il team è produttivo ed efficiente, non intralciarli. In questo caso la pressione proviene dall'esterno della squadra - vedo il mio ruolo di * proteggere * la squadra da questo tipo di "pioggia organizzativa" e quindi tendo a combattere per loro con la direzione, non il contrario. Se il team è efficiente e produttivo, non scherzare. Se il cronometraggio interrompe la coesione della squadra, assicurati che venga sollevato nelle tue retrospettive come un problema da risolvere per il team.
+1 per concentrarsi sul problema centrale ed evitare di creare una cultura delle regole. Anche il punto sulla flessibilità come vantaggio è positivo.
#2
+124
jmort253
2012-04-13 11:26:15 UTC
view on stackexchange narkive permalink

Creare una cultura della puntualità potrebbe richiedere tempo e potrebbe essere qualcosa su cui devi scendere a compromessi. Poiché hai a che fare con lavoratori della conoscenza intelligenti, avrai più successo se riesci a convincerli a partecipare al piano. Invece di concentrarti sul tempo, concentrati sul problema creato dai problemi di pianificazione.

Presenta il problema come una sfida al team e guarda cosa ne pensa. La risposta potrebbe essere programmata o potrebbe essere qualcosa di diverso che risolve il problema. Può essere lunedì, mercoledì, venerdì sono i giorni precisi alle 9:00 mentre martedì e giovedì sono i giorni flessibili. Anche se il piano potrebbe non essere perfetto né sarà esattamente quello che avevi immaginato, trovare una via di mezzo da qualche parte che renda felice sia il team di sviluppo, sia che risolva il problema reale impedirà al tuo staff di diventare amareggiato e di vederti come il nemico .

Tieni presente che non hai 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 che possano iniziare il compito sconvolgente di assemblare lo stesso piccoli oggetti di plastica ripetutamente, fino a quando il fischio non suona di nuovo e il personale insensibile si fa strada al bar locale per l'happy hour.

La mia squadra non si presenta in tempo. Ho provato a costringerli e non funziona.

Forzare le persone intelligenti non funziona mai. Devi ricordare che hai 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 torna a mettere il problema nelle loro mani, almeno all'inizio. Se non fanno nulla, ti consigliamo di intervenire con la tua soluzione.

Hai detto che sei un nuovo capogruppo. Entrare in una nuova posizione come questa è impegnativo e stressante perché non sei sicuro di come ottenere il rispetto della squadra ed essere anche un buon leader. Questo viene fornito con l'esperienza, ed è comune che i nuovi team inesperti tentino di "costringere" o costringere le persone a fare le cose a modo loro. Questa non è leadership.

Gli sviluppatori e altri lavoratori della conoscenza non hanno bisogno di un manager; invece, hanno bisogno di un leader. I grandi leader ispirano gli altri a fare grandi cose, e questa è la tua opportunità per guidare il tuo team verso la grandezza piuttosto che dettarlo alla disperazione.

La ricerca mostra che le persone hanno maggiori probabilità di impegnarsi quando hanno partecipato alla determinazione di cosa la soluzione sarà piuttosto che avere quella soluzione raccontata a loro, e questo è specialmente vero con i lavoratori della conoscenza.

Per l'ispirazione, vedi Seth Godin Intervista sulla differenza tra leadership e gestione. Consiglio vivamente a chiunque e tutti con capacità di leadership di guardare questa breve intervista.

"Lascia che escano con un piano" è stata anche la mia prima reazione. Tuttavia, a giudicare dai commenti e dalla chat, non sembra probabile che funzioni in questo caso particolare ...
@Benjol - Il tono della domanda mi fa pensare che ci sia di più in questo di quanto sembri. Sembra anche la gestione in stile Theory X, che non è efficace nella gestione degli sviluppatori. Stiamo ascoltando solo un lato della storia e la verità è sempre da qualche parte nel mezzo.
Vedi la mia risposta :)
Il punto più importante è questo: _Forzare persone intelligenti non funziona mai_. Non puoi trattare i membri del tuo team altamente intelligenti come bambini e aspettarti che non si lamentino, reagiscano e non ti risentano per questo (caso in questione; non sono direttamente influenzato da nulla di tutto questo, ma trovo ancora difficile offendersi personalmente per come l'OP sta cercando di gestire la sua squadra). I dipendenti tecnici sono generalmente intelligenti quanto i loro manager (se non di più), quindi l'unico modo efficace per avvicinarli è come colleghi, non come subalterni insensati che dovrebbero fare quello che dici perché l'hai detto.
Sono scarsamente istruito e continuo a obiettare che le persone prendano il mio tempo flessibile.
#3
+64
Andrew
2012-04-12 23:19:20 UTC
view on stackexchange narkive permalink

In base alla mia esperienza, ai knowledge worker non piace essere dettati da politiche per le quali non vedono alcuno scopo. Dichiari uno scopo, ma i dipendenti che gestisci sembrano pensare che non sia buono. Inoltre, ci sono probabilmente alternative che non hai considerato e, dato quello che suona come un problema "dettato dall'alto", i tuoi dipendenti potrebbero non averci pensato, non sentirsi a proprio agio nel proporle o pensare che lo sarebbero semplicemente abbattuto.

Se l'unico motivo per cui stai implementando la politica è a causa della tensione con persone di altri dipartimenti, è tuo compito gestire quella tensione in modo che i tuoi dipendenti possano lavorare in modo più efficiente. Non credo che sia l'unica ragione, però. Ad esempio, cosa succede se uno sviluppatore è necessario per risolvere un problema di produzione urgente che si verifica alle 8:00 o alle 9:00 o in qualsiasi altro momento? Tuttavia, è improbabile che tu abbia bisogno di tutti i tuoi sviluppatori presenti per risolvere il problema. E se avessi un programma "anticipato" a rotazione (a meno che qualcuno non si offra volontario), in modo che ogni sviluppatore a turno richieda di essere lì alle 8:00 (o alle 9:00, ecc.)? Questa soluzione sembra più probabile che soddisfi sia le esigenze aziendali che i desideri dei tuoi dipendenti. Tutti "condividono il dolore" (o lo infliggono a qualcuno a cui non importa). Le persone possono entrare e lavorare la maggior parte delle volte quando ritengono che sarebbero più produttive. Questa è solo una possibilità, ma può generare discussioni con i tuoi dipendenti su come risolvere i problemi reali e soddisfare gli interessi di tutti qui.

Se scegli di seguire la strada più disciplinare e la questione dell '"ora di inizio" è veramente importante per i tuoi sviluppatori, perderai i tuoi buoni a causa di altri lavori. È probabile che i tuoi dipendenti si sentano insicuri nel loro lavoro (e se un giorno si verificasse davvero un'emergenza reale per far ritardare qualcuno?). Inoltre, questo può essere visto come un cambiamento nella direzione nella direzione sbagliata (dal punto di vista dei dipendenti), poiché in precedenza avevano esperienza di lavoro sotto qualcun altro.

Dipende da te, ovviamente, ma Ti esorto a fare un passo indietro e sforzarti di vedere la situazione dal punto di vista dei tuoi dipendenti. Hai un lavoro da fare, ovviamente, ma penso che ci siano soluzioni che soddisfano meglio gli interessi di tutti rispetto a quella che stai proponendo.

Non penalizzerò qualcuno se ha un motivo legittimo per arrivare in ritardo. Dormire troppo tre volte a settimana perché giocano a WoW tutta la notte non è legittimo. Abbiamo una persona in anticipo che preferisce presentarsi alle 7:30. Il grosso problema è che se Dev X sta lavorando a un progetto con il Designer Y e il Designer Y è alle 8, aspetta fino alle 13:00 o più tardi per ottenere qualcosa di cui potrebbe aver bisogno. Quando viene chiamato, gli sviluppatori non vedono alcun problema con esso. Siamo una piccola azienda e dovremmo essere tutti nella stessa squadra. Seriamente, le 9:30 non sono molto presto. Sono davvero irragionevole?
@JacobG Non posso dire se sei irragionevole senza ulteriori informazioni, tuttavia la chiave per flettere il tempo è che il lavoro *** deve essere fatto. Se quello che stai dicendo è che il lavoro ** non ** viene svolto, privare il tempo di flessibilità dei dipendenti improduttivi (o ridurre i periodi di paga / ferie) potrebbe essere la strada da percorrere. Nel tuo esempio. Dev X e Designer Y dovrebbero coordinarsi, quindi nessuno dei due è seduto a girarsi i pollici in attesa dell'altro. Se ciò non accade, è un problema di processo tanto quanto un problema di pianificazione ...
"perderai i tuoi buoni a causa di altri lavori": questo è il cuore dell'intera questione, @Jacob. Se il lavoro non viene svolto, hai problemi più profondi; i tuoi sviluppatori e designer devono coordinarsi meglio. Se il lavoro * viene * svolto, non sprecare il tempo degli sviluppatori con sciocchezze come impostare un'ora di inizio specifica.
+1 per aver perso contro altri datori di lavoro. Se dovessi passare da un ambiente in cui mi è stato affidato per mantenere il mio programma e portare a termine il mio lavoro a un ambiente in cui ho i demeriti del ritardo, rispolvererei il mio curriculum.
@ErikDietrich: Quindi, se non stavi portando a termine il tuo lavoro in modo soddisfacente e il tuo capo ha detto "Sai, il tuo lavoro non viene svolto in modo tempestivo e così e così si lamenta che non sei abbastanza disponibile durante il loro programma stabilito e prescritto, quindi iniziamo a presentare un programma coerente entro le 9:30 al più tardi ". rispolvereresti ancora il tuo curriculum?
@JacobG Se provenissi da un ambiente con orari flessibili e ora parte di "soddisfacente" è "essere puntuali", allora lo farei assolutamente (e, credo, lo sarà anche la tua squadra). L'orario flessibile non è una questione di giocatori per giocare ai videogiochi tutta la notte: si tratta di una cultura della fiducia. Se è il mio team, confido che conoscano la propria personalità e preferiscano l'orario di lavoro abbastanza bene da poter fare le cose. Ritirare gli orari flessibili significa revocare quella fiducia e inviare il messaggio che devono essere (micro) gestiti perché sono pigri e incompetenti. Anche se è vero, non gli piacerà.
D'accordo con @AdamRackis se "Il grosso problema è che se Dev X sta lavorando a un progetto con il Designer Y e il Designer Y è alle 8, sta aspettando [...]" Vorrei che il Designer Y dovrebbe pianificare in anticipo e dire a la fine della giornata "Ehi, ci lavorerò domani mattina, potresti assicurarti di arrivare domani presto e aiutarmi, o farlo prima di partire" Anche farli lavorare insieme richiede meno tempo .
"Dormire troppo tre volte a settimana perché giocano a WoW tutta la notte non è legittimo." Cosa significa "dormire troppo"? Siamo ancora alle elementari qui? Otto ore sono otto ore, sia che inizi alle 6:00 o alle 10:00.Se hai bisogno che le persone siano presenti alle riunioni e cose del genere, lascia che scelgano determinate ore fondamentali in cui saranno disponibili, diciamo dalle 10:00 alle 15:00. o qualsiasi altra cosa. Ma se il lavoro viene svolto è ortogonale al fatto che arrivino entro un certo tempo o meno. ** Hai provato a parlare con gli sviluppatori del problema e a chiedere * loro * di trovare una soluzione? **
@Kyralessa - Se il tuo capo dice di essere al lavoro alle 9:30, allora è meglio che tu sia in ufficio alle 9:30, altrimenti SEI IN RITARDO. Non riesco a credere a quante persone abbiano un problema con la domanda di questo autore, per non parlare di dirgli che non è un leader ragionevole, mi è stato insegnato a presentarmi in orario ogni singolo giorno.
@Ramhound Il problema è che la cultura precedente era quella in cui le 9:35 NON erano in ritardo e l'OP vuole passare a una cultura che è, presumibilmente per le persone con talenti che non sono facilmente sostituibili e che hanno un certo livello di libertà su dove possono lavorare. Può gridare "SEI IN RITARDO", suppongo, ma ciò potrebbe portare alcune persone ad andarsene e abbassare il morale, cosa che sembra stia cercando di evitare.
@Renan Non è l'ideale per tutte le situazioni, certamente. Il punto è essere sicuri che le esigenze aziendali siano soddisfatte. Se c'è un problema di produzione urgente in un momento critico, qualcuno deve essere in grado di risolverlo. Nel mio ruolo attuale, spesso sono io, ma quello che succede è che ricevo un'e-mail sul mio telefono, lo riconosco e salgo sulla mia macchina * a casa * e risolvo il problema. Se si verifica un'emergenza dopo un'emergenza, ci sono problemi ben oltre chi è in ufficio e quando.
@Ramhound Impostare un orario di inizio arbitrario quando non ce n'era uno prima e aspettarsi che tutti aggiustassero semplicemente il loro programma di vita intorno ad esso _è_ irragionevole. Del resto, anche impostare un orario di inizio difficile quando non è realmente necessario è irragionevole. Ovviamente, gli sviluppatori non lo considerano necessario, quindi sembra loro irragionevole. Inoltre, considerando che sono stati con l'azienda molto più a lungo del manager e sembrano tutti d'accordo, potrebbero avere ragione.
#4
+50
Erik Reppen
2012-05-06 00:55:38 UTC
view on stackexchange narkive permalink

La risposta precisa alla tua domanda è licenziare e sostituire qualcuno che non riceve il messaggio e quindi licenziare chiunque altro che non riceve il messaggio.

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

In modo più costruttivo, ti suggerirei di considerare quanto segue:

  • I tuoi sviluppatori hanno avuto tempo flessibile. Ora vuoi portarlo via

Non importa se si tratta di un vantaggio ufficiale in qualche politica scritta o meno. È una politica de facto e una parte della cultura consolidata. La vita e gli orari delle persone sono stati stabiliti in queste ore. E per gli sviluppatori come me, che preferiscono di gran lunga schivare l'ora di punta e che hanno un orrendamente brutto caso di SAD in inverno, ma non riescono a pensare a nessun luogo adatto agli sviluppatori più vicino all'equatore che preferirei vivere, è grande come un patto come trarre benefici per la salute.

  • Qual è la natura di questa "angoscia" di cui parli? È a) principalmente gelosia o b) problemi di comunicazione tra i dipartimenti legittimi come difficoltà nella pianificazione di riunioni / comunicazioni generali.

a) Gli sviluppatori non hanno bisogno di interagire con i clienti o altre aziende. Nella mia esperienza, più rigida è la struttura aziendale, più mediocri sono gli sviluppatori. Mentre gran parte dello sviluppo è semplice, è anche un processo creativo di risoluzione dei problemi che richiede che le persone siano al massimo. È anche un processo imprevedibile basato su scadenze che a volte si traduce in ore molto, molto tardive. Un effetto collaterale di ciò è che gli sviluppatori spesso ricevono un trattamento "creativo". In un'azienda di 30 persone non dovrebbe essere difficile insistere che le persone siano adulte riguardo ai dipendenti che devono essere al massimo quando sono presenti e che alla fine impiegheranno molte più ore nel corso di un anno di un 9-5er di solito fanno le valigie alle 16:55 ogni giorno.

b) In un'azienda di 30, non dovresti avere così tante riunioni che questo diventi un problema. Senza contare cose come le riunioni di sprint o altre sessioni di pianificazione bimestrale, legare i tuoi sviluppatori per più di 30 minuti ogni giorno alle riunioni è uno spreco di denaro assurdo e grossolanamente incompetente. Allo stesso modo con la comunicazione generale. 30 persone significa che ti avvicini all'altro ragazzo e gli parli. Negli scenari di tempo flessibile è ragionevole impostare un periodo di tempo in cui tutti sono in ufficio allo stesso tempo. Non riesco a pensare a una buona ragione per cui quell'arco di tempo sia più di 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 scarta da mischia, agile, ecc ... è sempre il consiglio di non avere lo standup per prima cosa? Nella programmazione ci vuole un po 'di tempo per risalire alla piena consapevolezza di tutti i dettagli e le questioni che devi affrontare su un dato problema. Quando fai gli stand-up per prima cosa, i tuoi sviluppatori non avranno la testa completamente avvitata. Gli stand-up sono fondamentali per la comunicazione e il miglioramento dell'efficienza, non qualcosa che fai semplicemente per "toglierti di mezzo".

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

In caso contrario, perché scherzare con una cosa buona? Non è compito loro comunicare con le altre preoccupazioni dell'azienda. È tuo. In una struttura di gestione sana, la tua responsabilità è nei confronti del tuo diretto superiore e delle persone che gestisci, non delle uve acide di altri reparti che devono essere presenti all'ora più tipica per motivi pratici.

Ho dato una risposta alla domanda. E poi un seguito / addendum davvero lungo.
#5
+46
user718
2012-07-12 12:30:04 UTC
view on stackexchange narkive permalink

Revisione della domanda: ci sono molte informazioni e contesto mancanti

In qualità di nuovo responsabile tecnico in una nuova azienda, quali sono alcune strategie aggiuntive da impiegare per cambiare la cultura dello sviluppo squadra in modo che le persone si presentino al momento in cui ho richiesto?

  1. Quanto sei nuovo di un lead tecnico?
  2. Perché imponete politiche gestionali puramente non tecniche?
  3. Quali sono le vostre credenziali di gestione?
  4. Quali sono le vostre precedenti esperienze di gestione del personale?
  5. Ti sei guadagnato il rispetto della squadra in modo tecnico?
  6. Ti sei guadagnato il rispetto della squadra in modo manageriale?

TLDR: il mio team non si presenta in tempo. Ho provato a costringerli e non funziona.

Non possiamo fornire una soluzione a meno che non sappiamo specificatamente perché devi cambiare la cultura drasticamente. Inoltre, non sappiamo con cosa hai cercato di costringerli per essere in grado di dirti perché è inefficace. Possiamo indovinare, ma questa è una speculazione.

Perché hai il compito di risolvere quello che è probabilmente un mandato di gestione del personale non tecnico? Consegnalo a un superiore che è un manager e lascia che se ne occupi. Poliziotto buono contro poliziotto cattivo.

Dati di base:

Piccola azienda, 30 dipendenti, 5 membri del mio team. Il precedente lead è ancora nello staff come sviluppatore regolare.

  1. Il precedente lead tecnico si è dimesso?
  2. Il precedente lead tecnico è stato degradato?
  3. Il precedente lead tecnico era efficace?
  4. La maggior parte del team esistente ha un rapporto più personale con il precedente responsabile tecnico?
  5. Il precedente responsabile tecnico effettivamente è ancora in carica ?

La cultura prima del mio arrivo era quella dell'informalità senza limiti fissi o orari fondamentali. Questa cultura non è stata contestata dai leader aziendali.

  1. Allora deve aver funzionato?
  2. Il team è riuscito a fornire prodotti utili quando promesso?

La maggior parte delle persone del team si presentava tra le 10:30 e le 11:00 a causa di Questo. Altri reparti, a causa della natura del loro lavoro, hanno fissato orari di inizio di 8 o 9. Questa discrepanza e imprevedibilità provoca molta angoscia tra il mio dipartimento e gli altri reparti.

In particolare, non ci sono abbastanza dettagli qui per iniziare a formulare una risposta a questa domanda. Qualsiasi tipo di risposta sarebbe una speculazione completa.

Come tale, ho fatto sedere la squadra e ho specificato un orario "non oltre" alle 9:30. Ho spiegato il mio ragionamento e ho spiegato i vantaggi di un tale schema e gli aspetti negativi dello schema attuale. È stata una conversazione lunga e controversa e 3 delle 5 persone del team erano piuttosto scontente.

Che ne dici di darci i tuoi vantaggi e aspetti negativi senza di loro, non possiamo giudicare quanto ragionevole né quanto efficace sarebbe stata la tua comunicazione. Non sembra che tu abbia nemmeno considerato o esplorato una sorta di compromesso con il tuo team o con i team esterni sulla base del loro feedback negativo. Davvero?

Inutile dire che le persone non si fanno vedere in tempo (e le 9:35 non sono puntuali.)

Questo non " Non sembra un atteggiamento molto positivo o efficace.

Ho programmato la nostra riunione quotidiana in piedi alle 9:30 come ulteriore motivazione. Sapendo che ci vuole un po 'di tempo per gli orari di inizio della transizione (con pendolarismo, ecc ...) inizialmente avrei aspettato di iniziare la riunione finché non si fossero presentati tutti, ma ora Inizio solo la riunione (e spesso finisco incontro) con chiunque sia presente. Anche questo sembra non fare la differenza e sta rendendo la squadra meno coesa.

Quindi le azioni unilaterali che stai intraprendendo stanno rendendo il team meno coeso. Pensa a it.

Le conversazioni su base individuale e di gruppo producono gli stessi risultati della conversazione originale (cioè non vedono il valore, penso che io togliendo un vantaggio al lavoro, ecc ...)

Sentiamo e possiamo estrapolare ciò che non accettano, li sentite ?

Ho il pieno supporto e il sostegno del senior management team e ho il potere di utilizzare qualsiasi dispositivo ritenga appropriato per occuparmi di questo.

The Catholic La Chiesa aveva lo stesso potere durante l'Inquisizione, guarda come è andata a finire!

Il mio prossimo passo attuale è mandare qualcuno a casa e fargli prendere il giorno libero. È troppo drastico? Esistono strategie alternative che sto trascurando che potrebbero aiutarmi a risolvere questo problema?

Anche l'escalation non sembra un'alternativa praticabile. Rimandarli a casa senza paga è un insulto e danneggerà l'azienda più che il dipendente. Ti farà sembrare ancora più dittatoriale e tirannico. Trattarli come bambini li farà semplicemente comportare ancora di più come bambini.


Risultato previsto del tuo approccio attuale

  1. Perderai tutto il rispetto dell'intero team, saranno sempre più inefficaci, sarai percepito sempre più inefficace man mano che la produttività si ferma.
  2. Il tuo fallimento con il cambiamento di politica e le capacità di gestione del personale ti faranno percepire inefficace dai tuoi superiori.
  3. Perderai il rispetto delle persone non nel tuo team a causa della comunicazione tra uffici. Saboterà anche qualsiasi futura opportunità di leadership tecnica con loro.
  4. Danneggerai sicuramente la tua reputazione in azienda, su e giù per la catena.
  5. I dipendenti migliori lasceranno chiaramente prima.
  6. I dipendenti ancora migliori se ne andranno silenziosamente dopo di loro.
  7. Quelli marginalmente qualificati potrebbero smettere o meno a seconda del dolore che imponi.
  8. Quelli non qualificati continueranno come ticchetta e sopporta tutto ciò che imponi.
  9. L'azienda finisce per perdere e ottenere una cattiva reputazione esternamente dai dipendenti che se ne sono andati.
  10. La percezione è tutto! Non dimenticarlo mai!

Alcuni approcci suggeriti

  1. In qualità di loro manager dovresti lottare per isolarli dalle decisioni dei vertici aziendali. Dovresti lottare per far sentire la loro voce. Dovresti aiutarli a formare collettivamente una risposta, respingerli e supportarli con la loro risposta.
  2. Questa è una decisione non tecnica e puramente gestionale aziendale. Perché ti occupi di esso e della sua implementazione? Avere un accordo migliore con questo, questo è il loro lavoro.
  3. Non agire come un dittatore o un tiranno. Potrebbe non essere giusto.
  4. Considera alcune abilità personali, formazione di competenze trasversali.
  5. Muoviti più lentamente. Cose come questa non cambiano dall'oggi al domani.
  6. Se ha un rapporto con il team, devi avere il precedente responsabile tecnico dalla tua parte.
  7. Avere un compromesso alternativo, come delle persone a cui non importa di arrivare presto, le altre persone non devono farlo?
  8. Lo spostamento del tempo di alzarsi è arbitrario, tutti lo vedono e non è visto come pratico o ragionevole ma altrettanto dittatoriale.
  9. Invita i team esterni con cui devi occuparti a partecipare alla discussione e ti aiutano a vendere le modifiche alle politiche.
  10. Fai marcia indietro, concorda con loro, essere il buon poliziotto. Chiedi al tuo superiore di stabilire la legge. Questo è un problema di gestione, non un problema tecnico. Sei un responsabile tecnico, non un manager, giusto?
  11. Chiedi ai membri del team esterno e ai membri del tuo team di stabilire gli orari per incontrarsi quando hanno bisogno di incontrarsi. Giorni e orari di disponibilità predeterminati sarebbero un buon compromesso. Gli sviluppatori non vogliono essere costantemente interrotti dal team esterno e sembrano essere presenti solo per passare alle riunioni su loro richiesta.

Considerazione finale:

Il mio Lo stile di gestione sia tecnico che non tecnico si basa sul Wu Wei Principal del Tao te Ching.

Il principio Wu Wei può essere compreso colpendo un pezzo di sughero che galleggia in acqua. Più forte lo colpisci, più cede: più cede, più forte rimbalza. Senza spendere energia, il tappo può facilmente logorarti.

Più fai più velocemente è probabile che fallirai. Meno fai, più è probabile che la cosa che vuoi che accada venga fatta.

Leadership indiretta trasparente

All'inizio, nella migliore delle ipotesi, le persone difficilmente notano un leader. Poi lo adorano e lo acclamano, poi arrivano a temerlo, alla fine lo disprezzano. Così la fede persa genera la fede perduta.

Sii non direttivo, rendi preziose le tue poche parole. Quando il lavoro è finito, finale guadagnato, tutti diranno: l'abbiamo fatto da soli, naturalmente.

Porta le persone del dipartimento esterno che hanno i reclami insieme alle tue persone in una stanza e lascia hanno elaborato una soluzione accettabile tra di loro internamente, senza di te nella stanza . Sii disposto ad accettare qualunque sia il risultato. Allora la soluzione è loro, loro la possiedono e tu guadagnerai un po 'di rispetto di cui avrai bisogno per aver lasciato che risolvessero il problema. Questo è l'approccio non direttivo .

+1, Questi sono tutti approcci davvero fantastici. Personalmente, mi piace l'approccio di responsabilizzare il team a risolvere il problema. È incredibile ciò di cui sono capaci gli adulti quando vengono trattati come ... beh ... adulti. Martha ha bisogno di incontrarsi con John, quindi pianificano e si coordinano insieme, senza che il capo cattivo e cattivo venga a fare il dittatore.
Ho modificato la mia domanda per rispondere ad alcune delle tue domande specifiche.
@JacobG Anche dopo la tua modifica, una cosa che non è ancora chiara è che sei un * Responsabile tecnico * o sei queste persone * Responsabile / responsabile di linea non tecnico *? Questa è una distinzione importante, in quanto responsabile tecnico, guida nel processo decisionale tecnico. Quale ** tecnologia ** usare, ** non ** quando gli sviluppatori entrano in gioco! 10 anni di decisioni tecniche non sono qualifiche per affrontare problemi sociali / di personalità manageriali non tecnici come questo, specialmente senza formazione formale.
@JacobG Hai iniziato con l'approccio * stick *, nessuna quantità di * carote * si riprenderà da quello. Un segno di un grande leader è sapere quando non è qualificato e non sarà efficace e chiedere aiuto, personalmente penso che questo sia uno di quei momenti in cui puoi salvare la faccia e lanciare questa battaglia a qualcun altro . Hai perso la guerra psicologicamente, anche se * vinci * la battaglia che tu e la tua squadra avrete perso a vicenda. L '** unico ** modo per risolvere questo problema è riunire i leader dei reparti esterni con il tuo team e fargli trovare una soluzione * senza * di te nella stanza.
@JarrodRoberson - Non sono sicuro di aver capito la tua distinzione. Sono responsabile del controllo della direzione tecnica e sono anche responsabile delle loro revisioni. Approvo la PTO e fornisco le funzionalità. Faccio entrambe queste cose da 10 anni. Inoltre, tecnicamente non c'è stato un approccio "stick". Questa politica è stata messa in atto tramite una discussione di più di 2 ore con l'intero team. Non è stato presentato in modo dittatoriale e non ci sono state conseguenze. Da allora i dirigenti hanno rafforzato il messaggio con il team e sostanzialmente hanno avuto la stessa discussione di oltre 2 ore.
@JacobG * "è stato messo in atto tramite una discussione di oltre 2 ore" * è un ossimoro. * "è stato messo in atto" * implica una ** decisione unilaterale ** dettata da qualcuno e applicata. La maggior parte dei luoghi in cui ho lavorato negli ultimi 22 anni si è resa conto che dovrebbe esserci una separazione tra leadership tecnica e gestione. Questa è una struttura organizzativa molto ben consolidata nella maggior parte delle grandi aziende (intendo multimiliardari all'anno) per cui ho lavorato come leadership tecnica. Unire le due responsabilità è una ricetta per il conflitto. Avere 2X 2+ ore * discussioni * dovrebbe dirti che la politica è cattiva e l'approccio è peggiore.
@JarrodRoberson Penso che stiamo parlando l'uno dell'altro. 1) Questa azienda è troppo piccola per garantire un responsabile dello sviluppo non tecnico. 2) Questa domanda si riduce davvero a "come influenzare un cambiamento culturale" indipendentemente dalle specificità del cambiamento. Il fatto è che i responsabili riconoscono la necessità di un cambiamento culturale e sono giunti a una conclusione su quale sia il cambiamento. Tutte le persone coinvolte concordano sul fatto che il cambiamento sia corretto. La speranza era che discuterne con il team di sviluppo avrebbe portato loro a trarre le stesse conclusioni. Non è successo e questo fiasco è il risultato.
+1 questa è una buona risposta ... anche se preferisco un ambiente più strutturato, questa è una risposta effettiva con suggerimenti pratici.
@JacobG: "Tutte le persone coinvolte concordano sul fatto che il cambiamento è corretto." Eppure hai detto che 3 sviluppatori su 5 si sono fortemente opposti al cambiamento. Questo significa che gli sviluppatori non sono "coinvolti" nel cambiamento? O vuoi dire che dopo le discussioni, tutti gli sviluppatori hanno convenuto che questo cambiamento era necessario?
@MarkBannister - Ci scusiamo per la confusione. Volevo dire che tutti i responsabili che hanno determinato la necessità di un cambiamento culturale hanno convenuto che questa era una mossa appropriata.
@JacobG continui a dire * ne hai discusso con loro *, non gli hai detto come sarebbe stato ora e apparentemente c'è stata una discussione per 2+ ore. Questa non è una * discussione * su un cambiamento di politica. ** Una vera discussione ** sarebbe stata * abbiamo i seguenti reclami da altri reparti, un'idea di quei team è un orario di inizio anticipato, quali altre idee avete voi ragazzi che possiamo riportare alle altre squadre per risolvere i problemi reali che hanno? *. Dal momento che non sembra che avere tutti il ​​100% del team lì presto sia effettivamente il problema.
@JarrodRoberson: Mi sento come se non fossi ancora chiaro. La leadership ha riconosciuto un problema culturale e sistemico, una soluzione ideata attraverso un'ampia discussione. La componente puntualità era un elemento di quella soluzione. La discussione con il team di sviluppo è stata quella di guidarli attraverso la stessa logica che ha portato la leadership alle loro conclusioni con l'aspettativa che il team trasse le stesse conclusioni. Ciò non è avvenuto perché la squadra non era d'accordo sul fatto che ci fosse un problema da risolvere. Hanno scelto di concentrarsi su questo particolare problema sopra tutti gli altri.
@JacobG una discussione implica la comunicazione bilaterale, per tua stessa ammissione anche qui, questa era una comunicazione unilaterale di * come andranno le cose ora *. * "Ho programmato la nostra riunione quotidiana in piedi alle 9:30 come ulteriore motivazione." * È un ** bastone ** arbitrario che cerca di forzare un comportamento conforme. Tutti coloro che leggono questo lo percepiscono, il tuo "team" lo ha percepito di sicuro! È una regola messa in atto che vedono come una punizione per azioni non ancora intraprese e si stanno ribellando. Se non accetti questa percezione, niente di ciò che fai sarà efficace. Sei chiaro, non li stai ascoltando.
@JarrodRoberson Non so davvero perché non ci stiamo connettendo qui. Se 5 dipartimenti si lamentano di 1 (reale / valido) e l'1 pensa che i 5 siano solo gelosi / inferiori / dovrebbero superarlo, allora cercare di convincerli perché questo cambiamento sarebbe meglio per tutti sembra giusto. Come ho detto, il senior mgmt mi ha chiesto di mettere in atto il cambiamento, ho tentato di guidare la squadra attraverso la logica che ha seguito il senior mgmt e la risposta è stata che non c'era davvero alcun problema. Dovrei tornare a mgmt e dire "scusate ragazzi, il team di sviluppo pensa che il servizio clienti sia un mucchio di bambini e dovrebbe superarlo?"
@JacobG il punto è che ** il tuo approccio ** al team di sviluppo è stato scarso. Se insisti su questo approccio, che suona come te, ** continuerai a fallire ** e i tuoi supervisori ti vedranno fallire. Penso che dovresti respingere a nome del tuo team, * gran parte del lavoro di un manager * è isolare il loro team da cose come questa. Dovresti almeno dare al team di sviluppo la possibilità di elaborare una soluzione alternativa con cui respingere. Ho fornito molti ** approcci di successo ** per trovare un compromesso reciproco. Non credo che l '** intero ** team debba essere a loro completa disposizione.
@JacobG smetti di dedicare così tanto tempo a difendere il tuo approccio fallito e giustificare le opinioni degli altri dipartimenti e inizia ad accettare tutti i buoni suggerimenti su ** come puoi supportare il tuo team e far sentire la loro voce! ** Se non pensi che dovrebbero averlo una voce, beh, non vorrei essere in quella squadra. Vedi le mie previsioni su cosa succederà nella mia risposta.
Leggendo questa discussione, mi viene in mente che il vero problema qui è che i superiori stanno prendendo decisioni su dettagli che non dovrebbero riguardarli. Ogni livello dovrebbe occuparsi di risultati inadeguati dal livello sottostante. Il come dovrebbe essere nella tua corte. Il fatto che gli sviluppatori stiano praticamente sconvolgendo tutti a questo punto mi suggerisce che sono entrambi stufi e per nulla preoccupati di trovare nuovi lavori se si arriva a questo. Se vogliono giocare in questo modo, è meglio valutare la difficoltà di sostituire la maggior parte di un team di sviluppo.
#6
+28
Tim
2012-04-27 00:55:45 UTC
view on stackexchange narkive permalink

La prima cosa che devi fare è vai a leggere "Peopleware"

È un errore provare a cambiarlo adesso. Ero un manager in un'azienda in cui avevamo un orario di lavoro piuttosto flessibile. Uno dei nostri sviluppatori più produttivi è arrivato alle 11:00. Mi ha riferito per un po '. Mi è stato detto di convincerlo a cambiare i suoi orari. Ho combattuto questa richiesta. Difficile. Sono stato respinto.

Il risultato:

Uno sviluppatore meno produttivo e meno interessato che è stato un enorme collaboratore del team. È diventato molto meno produttivo e utile per la squadra.

Tutto a causa di una sciocca nozione di "puntuale".

Concentrati maggiormente sulla produttività.

Il tuo lavoro come manager è rimuovere gli ostacoli alla produttività, non far sembrare, sentire e agire tutti allo stesso modo.

Gli orari flessibili sono un vantaggio e un datore di lavoro che consente orari flessibili può attirare più persone di qualità.

In quanto "nuovo lead tecnico" non è possibile cambiare presto cultura. Soprattutto nella direzione che sembri desiderare. Hai fatto qualcosa per migliorare i ruoli / lavori del tuo team?

Lavora prima di tutto per creare fiducia con loro. Così tanti manager / lead per la prima volta commettono errori come questo.

Scopri di cosa hanno VERAMENTE bisogno gli altri gruppi. Non "devono essere qui alle 9:30". Scopri davvero qual è il problema. Quindi trova una soluzione.

Invece di dire al tuo team cosa fare, spiega il problema e poi CHIEDI SUGGERIMENTI / FEEDBACK.

Fai un riferimento vago a "causa molta angoscia tra il mio dipartimento e gli altri dipartimenti" - ma non è chiaro quale sia questa angoscia - sono turbati dal fatto che gli sviluppatori siano trattati in modo preferenziale? Qual è il vero problema di fondo?

Ho provato a costringerli e non funziona.

C'è una ragione per questo. E sembra che tu non stia ascoltando. Raggiungere misure più drastiche e martelli più grandi non migliorerà davvero la situazione. Prova l'approccio "carota" invece di quello "bastone".

Ancora una volta, leggi "Peopleware".

Non andrai lontano con idee come riunioni quotidiane o mandare persone a casa o con l'idea che siano i tuoi tirapiedi che devono fare come dici tu, "o altro."

Chi ti dice che deve essere al lavoro alle 9:30? Altri gruppi? I tuoi capi? Tu? Individua il problema REALE e affrontalo. Quando si presentano NON dovrebbe essere il problema.

* Nota del moderatore: la discussione estesa nei commenti è stata cancellata. Per qualsiasi discussione continua, ti invitiamo a portarla a [chat] (http://chat.stackexchange.com/rooms/3060/the-water-cooler). *
Una volta ho avuto un collega che si è presentato alle 12 e se n'è andato quando ne aveva voglia.Indossare sandali o niente scarpe.In qualità di sviluppatore di software, è stato straordinario.Era una delle pochissime persone che abbia mai incontrato che fosse chiaramente più bravo di me in questo lavoro.Cercare di costringere questo ragazzo a iniziare presto (a) non avrebbe successo e (b) sarebbe la cosa più ridicolmente stupida che potresti mai fare.
#7
+20
Kristof Provost
2012-04-13 15:03:29 UTC
view on stackexchange narkive permalink

Indipendentemente dal motivo per cui lo stai facendo, ai membri del tuo team sembra che tu stia portando via un vantaggio. Per alcuni di loro potrebbe anche essere uno dei motivi principali per cui lavorano per la tua azienda piuttosto che per un'altra.

In sostanza, stai chiedendo loro di prendere una riduzione del loro pacchetto di retribuzione totale.

È possibile convincerli a prenderlo, ma avrai bisogno di buoni argomenti e quasi sicuramente ci sarà un risentimento persistente al riguardo. Potresti o meno perdere brave persone per questo.

Dalla tua descrizione il motivo principale sembra essere la gelosia degli altri dipartimenti. Hai pensato di dare agli altri dipartimenti lo stesso vantaggio?

In breve: non farlo a meno che non pensi che valga la pena di perderne alcuni per questo.

Non è esclusivamente la gelosia e il mio errore se l'ho definita tale. Altri reparti hanno orari di lavoro rivolti al pubblico, quindi flessibilità senza aggiungere risorse non è davvero una possibilità per loro.
@Chad - La risposta è implicita nel secondo paragrafo: pagali di più
@CurtainDog - A meno che l'aumento di paga non sia subordinato alla presentazione in tempo, dubito che questa sarà una soluzione duratura. Se è contingente, siamo d'accordo.
Sarebbe possibile modificare questo post ed espandere su come dare all'altra squadra lo stesso vantaggio? Sebbene questo post offra un'alternativa, non approfondisce né affronta il fatto che alcuni dei dipendenti potrebbero essere lavoratori a turni che devono avere un programma.
#8
+18
Erik Dietrich
2012-04-23 20:37:03 UTC
view on stackexchange narkive permalink

Per cambiare la tua cultura devi capire perché stai sperimentando resistenza e quindi gestire la causa della resistenza.

Nella mia esperienza, il "coordinamento con altri dipartimenti" tende ad essere l'ambito di quelli con titoli di posizione più alti e si è diretto verso un percorso di gestione del progetto / delle persone. Gli sviluppatori che lavorano quotidianamente interessati solo al codice tendono a essere protetti da questo. Nei negozi più strutturati, potrebbero non farlo affatto e nei negozi più piccoli, potrebbero farlo in modo più informale.

Ti piaccia o no, hai ereditato una cultura dell'orario flessibile, che è un enorme vantaggio per la maggior parte degli sviluppatori. Portarglielo via in uno dei tuoi primi atti come leader non solo sembrerà loro tirannico (quando spieghi loro che le 9:30 non sono così presto, stai imponendo il tuo programma su di loro, arbitrariamente a loro avviso), ma è realisticamente la sottrazione di un vantaggio sostanziale. Potrebbe piacerti lavorare un programma particolare e non considerarlo un vantaggio significativo, ma probabilmente lo considerano inestimabile. Considera questo come dire loro che stai portando via una settimana di ferie o tagliando la loro paga di qualche percentuale.

Per cambiarlo, puoi usare la carota o il bastone. Stai parlando di usare un bastone e, forse, un bastone più grande. Se segui questa strada, ho intenzione di assumere alcuni nuovi sviluppatori, poiché immagino che alcuni membri del tuo team inizieranno a fare colloqui presso altre società. Vorrei personalmente seguire la via della carota per ottenere il buy-in per la rimozione di questo vantaggio, chiarendo che le promozioni e gli avanzamenti futuri saranno decisi da coloro che "si coordinano con altri reparti". Cioè, i leader / persone importanti sono all'inizio, lavorano con altri team, assumendosi responsabilità, ecc. I "neofiti" ottengono il vantaggio flessibile, ma le persone seriamente intenzionate ad avanzare entrano in tempo.

Se crei quella cultura, sospetto che alcuni dei tuoi sviluppatori inizieranno ad arrivare in tempo di propria iniziativa. Sia per l'interesse per il progresso sia per la percezione che "le persone importanti entrano presto".

#9
+13
aroth
2012-07-12 11:03:25 UTC
view on stackexchange narkive permalink

La risposta breve è che NON dovresti farlo. I membri del tuo team tecnico sono (o almeno dovrebbero essere ) abbastanza intelligenti da sapere che non c'è alcun vantaggio tangibile nell'avere tutti presenti in ufficio entro un periodo di tempo arbitrario; l ' unica metrica importante è se il loro lavoro viene svolto o meno.

Se il tuo team non sta portando a termine il proprio lavoro, questo è un problema separato. Ma se stanno facendo le cose, allora perché li molesti solo perché altri dipartimenti ti hanno molestato?

Parte del tuo ruolo di leader è isolare il tuo team da banali distrazioni e critiche causate da fonti esterne. Se la tua reazione ad altre persone che si lamentano dei membri del tuo team è trasmettere i reclami ai membri del tuo team e / o imporre modifiche basate esclusivamente su tali reclami, allora stai fallendo nel tuo lavoro. Suggerirei che, supponendo che il tuo team stia effettivamente svolgendo il suo lavoro (il che sembra che lo siano, dal momento che non ti lamenti della loro produttività), un modo migliore per rispondere a tali critiche è dire al lamentoso "sì, beh, i miei ragazzi lavorano duro e forniscono costantemente risultati concreti, e questa è l'unica cosa che conta; quindi perché non smetti di preoccuparti di come il mio team gestisce i loro compiti e torna ai tuoi?".

E, naturalmente, se segui una norma obbligatoria "devi essere in ufficio entro l'ora X", è giusto integrarla con una norma "devi lasciare l'ufficio entro l'ora Y" e una politica "non devi lavorare da casa al di fuori del normale orario di lavoro". È giusto come un modo per proteggere l'equilibrio tra lavoro e vita privata dei tuoi dipendenti, poiché scommetto che molti dei membri del tuo team che non si presentano fino alle 11:00 probabilmente rimarranno a casa fino a tardi o impiegheranno dei tempi supplementari a casa.

Tranne che l'autore afferma che il lavoro non viene svolto.
@Ramhound - No, non lo fa, almeno non nel post originale. Nella lunga lista delle modifiche menziona che la performance è stata recentemente in declino. Tuttavia, poiché il team ha sempre avuto orari di lavoro flessibili in passato, non c'è ancora nulla che dimostri che il calo delle prestazioni sia correlato all'orario di lavoro o che l'impostazione di un orario di inizio fisso provocherà alcun miglioramento. A giudicare dal post originale, sembra che l'autore sia più preoccupato per il feedback negativo che riceve dagli altri reparti.
Sembra che "le percosse continueranno fino a quando il morale non migliorerà".
#10
+13
bethlakshmi
2012-07-12 21:36:53 UTC
view on stackexchange narkive permalink

Non ti invidio questo: come collega manager, sarebbe difficile per me. E onestamente, credo che perderai le persone per questo. Penso che tu abbia un singolo sintomo che deriva dal cambio di cultura Start Up -> Medium Sized, e non tutti gli sviluppatori realizzeranno questo cambiamento con successo. Penso che tu debba essere preparato con le descrizioni del lavoro e la conoscenza di come apri le richieste di lavoro e penso che tu debba porre l'accento sulla capacità di assumere nuove persone e migliorare la documentazione ...

Scusa, è così triste . Ma non credo che tu abbia una situazione di problemi di fiducia o un caso in cui puoi facilmente spiegare le persone in modo che siano d'accordo. E non c'è davvero alcun compenso che bilancia perfettamente l'enorme flessibilità sul lavoro.

Sono d'accordo che stai 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 potresti essere stato in grado di offrire alcuni piani di scorta, aumenti di stipendio o altri miglioramenti. Se nulla di tutto ciò è vero, allora ti sei chiesto se hai un'azienda fiorente di & in crescita o un'azienda che precipita nella disperazione.

Il trucco è che le persone spesso non riescono a collegare i punti tra questi nuovi valori- aggiunge e la rimozione del vantaggio preferito. Puoi provare a spiegarlo, ma per alcune persone questo non è un buon compromesso e questo non è il caso in cui puoi offrire la scelta. È "a modo mio o in autostrada" poiché ha un impatto organizzativo che non può essere necessariamente sentito all'interno del team, ma che è sperimentato e supportato ai livelli più alti dell'azienda.

hai fatto le cose giuste:

  • l'hai esposto chiaramente

  • hai parlato del motivo e necessità di cambiamento

  • ti sei assunto uno contro uno (e presumo che continui a farlo) per risolvere i casi individuali man mano che si presentano

  • hai fornito un feedback

Penso che tu sia giù per il "lo intende davvero?" punto in cui sta principalmente dimostrando alle persone che sei serio e che questo ha davvero bisogno di cambiare. Sarebbe mia opinione personale che essere in ritardo di 5 minuti in un ufficio nella mia regione non sia un grosso problema e che le riunioni che hanno un breve periodo (come gli stand up in uno sprint agile) non dovrebbero essere così contro l'inizio della giornata lavorativa in cui una mancata coincidenza con l'autobus o il traffico intenso sarà un problema regolare. Ma questo è un po 'regionale: le diverse località hanno ampie variazioni nella situazione del traffico. Quindi è tanto conoscere la tua regione e sapere cosa è ragionevole in base ai reclami individuali.

Il resto è solo inventare un meccanismo che è abbastanza debilitante da dimostrare che sei serio. Un giorno di paga ridotta è un'opzione ed è nei tuoi diritti legali, anche se qualsiasi meccanismo che avrei escogitato lo avrei fatto passare attraverso gli avvocati. Quindi è un sistema di allerta formale che porta ad un'azione discrezionale. Presumo che il tuo reparto risorse umane possa avere suggerimenti ...

Molto dipende da ciò che il lavoro può tollerare: quando mandi qualcuno a casa, perdi anche il lavoro di quella giornata, il che influisce sui tuoi costi Programma &. Quando disponi di un sistema di allerta che porta ad azioni disciplinari, compreso il licenziamento, risparmi il resto della giornata di lavoro, ma rischi di dover licenziare il dipendente.

Penso che il problema sia quando ti occupi di punizioni , devi essere preparato con una punizione abbastanza dannosa da essere preso sul serio e da portare a casa il punto che "non stai facendo il tuo lavoro se non lo fai".

#11
+10
weronika
2012-04-14 08:21:56 UTC
view on stackexchange narkive permalink

Sembra che qui ci sia una disconnessione tra il modo in cui i tuoi sviluppatori vedono il problema e il modo in cui gli altri reparti (o i tuoi superiori, o chiunque stia effettivamente chiedendo questo cambiamento) vedono il problema. Suggerirei di provare a colmare questa lacuna, in più fasi, se necessario.

Innanzitutto, gli sviluppatori concordano sul fatto che ci sono buone ragioni per questo cambiamento? Se non sono d'accordo, hanno buone controargomentazioni o suggerimenti alternativi? Se lo fanno, dovresti portarli alla direzione e vedere se allenteranno i requisiti di tempistica o se possono spiegare perché le alternative non funzionano e le controargomentazioni non risolvono il problema, in modo che tu possa torna dai tuoi sviluppatori e dai loro una spiegazione più completa. Continua avanti e indietro per tutto il tempo necessario / produttivo.

Se arrivi al punto in cui gli sviluppatori concordano sul fatto che ci sono buone ragioni ma semplicemente non sono disposti ad adattarsi, o non lo fanno pensa che le ragioni siano buone e offendi l'idea, comunicalo alla direzione . Spiega che potresti costringere gli sviluppatori a fare ciò che è voluto, ma ciò causerà risentimento, minore motivazione, molto probabilmente minore produttività o persino l'abbandono dei dipendenti. Assicurati che la direzione lo capisca e che sia ancora d'accordo che è importante applicare l'ora di inizio (e di nuovo, comunicarlo ai tuoi sviluppatori), altrimenti potresti finire per essere responsabile di un cambiamento che ha perso l'azienda più di quanto ne abbia guadagnato.

(Una nota personale: sono stato nella posizione di sentirmi dire di entrare a un'ora prestabilita perché, per quanto riguardava i dipendenti, nessuna buona ragione, ed è davvero estremamente demotivante . È molto importante assicurarsi che le persone comprendano i motivi e non si sentano come se stessi cambiando la politica per capriccio o perché non ti fidi di loro.)

#12
+9
Michael Durrant
2012-05-06 19:27:24 UTC
view on stackexchange narkive permalink

Lavoravo in un'organizzazione no profit che aveva questo problema. Le riunioni iniziavano sempre in ritardo, 10 minuti in ritardo sono diventati uno "standard".

Poi abbiamo avuto un nuovo project manager per un grande progetto chiave (e uno con una tempistica fissa). Ha convocato il primo incontro. La gente entrava come al solito, con qualche minuto di ritardo e chiacchierando casualmente. Si sedette sulla sedia e non disse niente, proprio niente, per diversi minuti. Alla fine le chiacchiere "si spensero" finché non ci fu silenzio. Stavamo tutti aspettando di sentire parlare. Lasciò che il silenzio continuasse ancora per un po '. Si guardarono intorno e dissero: "Devo chiarire. Le riunioni iniziano in orario. Se arriverai in ritardo di 5 minuti, non preoccuparti di venire, vedimi dopo. OK, ora per il progetto siamo facendo questa settimana [qualunque] ... ". Ciò ha fatto una GRANDE impressione e le persone hanno fatto un vero sforzo per essere puntuali alle sue riunioni.

Nota: aggiunta di una risposta aggiuntiva di seguito.

Tieni conto del lavoro svolto in remoto.

Spesso i produttori più esperti svolgono gran parte del loro lavoro in remoto comunque, quindi a volte sono impiegando tanto tempo da remoto quanto in ufficio. Questo è un punto importante da considerare e da comunicare con gli altri reparti. Quella comunicazione dovrebbe essere sottile - non chiamare una riunione, inizia solo a cercare modi per mostrare "sì, Joe era sveglio fino a tardi la scorsa notte a lavorare su x" e "sì, Mary ha risolto il problema domenica, era sveglia fino a mezzanotte ".

Parla apertamente del tragitto giornaliero. Se qualcuno arriva alle 10.30, il suo tragitto giornaliero potrebbe essere di 15 minuti. Se deve arrivare alle 9 o alle 9.30, il suo tragitto giornaliero potrebbe essere di un'ora. Inoltre sarebbe lo stesso andare a casa se hanno lavorato 8 o 9 ore. Molte persone ritengono che questo sia un grande spreco della loro vita. Preferiscono lavorare a distanza per un po 'e poi rientrare. Cerca di integrare questo fatto con le tue esigenze durante l'impostazione volte e assicurati che anche gli altri reparti lo sappiano, menzionandolo spesso.

Assicurati di utilizzare la tecnologia per aiutare. Ad esempio, lavoro virtualmente - il 100% delle volte. Quindi avere Skype su, mostrare il mio stato come online, una videocamera, ecc. Può anche aiutare.

Il motivo per cui ho votato positivamente è perché l'idea del manager è fantastica: praticamente ha dato a tutti un "biglietto gratuito per uscire dalle riunioni".
#13
+8
Spoike
2012-07-17 14:04:35 UTC
view on stackexchange narkive permalink

Essendo stato in situazioni simili, anche se 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 provare ad avviare le riunioni alle 11. Non preoccuparti, non stai "cedendo". Invece stai reindirizzando il flusso in modo molto simile ai principi alla base dell ' Aikido. L'idea è invece di concentrarsi sul consentire al tuo team di fare cose importanti in quanto è il punto fondamentale perché c'è davvero un problema serio che deve essere affrontato:

Il team non ha davvero idea cosa succede agli altri reparti e cosa devono DAVVERO fare.

Avere il tuo team che si presenta alle 9:30, il che posso ammettere che non è presto, non è tuttavia una soluzione a questo problema. Hai provato e fallito, quindi smetti di insistere per farlo. Smettila di sbattere la testa contro un muro di mattoni. Il mio unico suggerimento qui è quello di valutare sempre la comunicazione rispetto alle riunioni impostate arbitrariamente.

Poiché gli altri dipartimenti iniziano alle 8, puoi utilizzare questa riunione del team in ritardo a tuo vantaggio . Tra 8 e 11 hai 3 ore per aiutare il tuo team con attività di gestione del progetto come (in nessun ordine o priorità particolare):

  • Vai alle riunioni e raccogli gli obiettivi e requisiti degli altri reparti
  • Scopri cosa è stato fatto da ieri
  • Gestisci le aspettative e gli impegni con gli altri reparti su ciò che deve e può essere fatto durante la giornata lavorativa
  • Fornisci buone notizie e cattive notizie agli altri reparti
  • Aggiorna eventuali piani rilevanti per il team se ce ne sono
  • Scopri quali problemi di architettura software e codice devono avere attenzione oggi
  • Dire "NO" alle richieste che non forniscono alcun valore commerciale
  • Accetta le critiche dagli altri appartamenti e chiedi scusa con certezza che i problemi verranno risolti
  • ecc. (c'è sempre qualcosa che deve essere risolto)

E infine, prima dell'incontro, riassume un breve 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 per mettersi al lavoro, hai preparato le informazioni e un protocollo della riunione. Puoi avere il brief e il verbale della riunione scritti come una newsletter e inviarli come e-mail qualche tempo dopo la riunione come promemoria.

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

  • Richiedi stime per le attività che devono essere eseguite, in particolare quelle ad alta priorità. Non deve essere preciso, come in pochi minuti. Con questo puoi decidere impegni e scadenze molto più chiaramente con gli altri reparti. Se non sono in grado di fornire alcuna stima per un'attività, chiedi loro di capirlo durante il giorno o il giorno successivo.
  • Chiedi impedimenti o se hanno bisogno di aiuto per qualsiasi cosa, scrivilo e verifica se questi problemi sono risolvibili e vengono risolti.

Dopo un po 'probabilmente puoi passare gradualmente alle riunioni prima. Ma inizialmente andare contro corrente 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", il tuo vero lavoro è rimetterle a nuovo in fantastiche primadonne che forniscano con alta qualità. È chiaro che il tuo team aveva e desidera autonomia, quindi inizia a sfruttare quella cultura a vantaggio degli obiettivi della tua azienda.

Quando sei riuscito a creare un team affidabile, attraverso la comunicazione anziché la coercizione, puoi partire tre ore prima di chiunque altro in la squadra sa che stanno facendo il loro lavoro (ma saranno comunque a disposizione se la merda colpisce il fan). Questa è la fiducia su cui puoi contare.

Penso che questo sia un consiglio più valido e solido e un buon approccio alternativo che porterebbe al successo. Il ruolo di un ** manager / team leader ** è quello di isolare il team dal rumore e dalla confusione e rimuovere gli ostacoli che riducono la loro efficienza. Questa risposta propone un approccio per fare tutte queste cose!
#14
+6
pap
2012-04-26 17:26:40 UTC
view on stackexchange narkive permalink

Sto leggendo commenti e risposte e devo confessare di essere un po 'sbalordito. Da quando le persone si presentano in tempo "perdita di un vantaggio"? Da quando è il momento flessibile a non doversi preoccupare dell'impatto delle tue azioni sul resto del team e dell'azienda?

Da quello che ho letto nella domanda e nei commenti, il comportamento dei suoi membri del team è dimostrabilmente dannoso e costoso per l'azienda. E dopo aver cercato di ragionare e scendere a compromessi, la situazione non è migliorata (e tra l'altro, le 9.30 sono non in anticipo o in alcun modo irragionevoli).

Spiega al tuo team che non hai problema con il tempo flessibile, ma che implica una certa responsabilità personale per assicurarsi che la tua flessione non influisca sul lavoro degli altri (nella tua squadra o in altre squadre). Poiché il tuo team sta chiaramente fallendo nella parte di responsabilità, direi che con effetto immediato e fino a nuovo avviso, tutto il tempo flessibile deve essere approvato da te in anticipo. La mancata presentazione in orario la mattina senza approvazione o una scusa ragionevole (no, la sveglia non è suonata non è accettabile) comporterà un'azione disciplinare come lo stipendio o le ferie.

Sii molto chiaro perché questo sta accadendo e cosa ti ha costretto a prendere queste misure. Fai notare che questo non è qualcosa che vuoi fare, ma qualcosa che sei stato costretto a fare. Sia anche chiaro che queste politiche restrittive possono essere revocate una volta che la situazione migliora.

** Commenti rimossi. ** Utilizzare i commenti per migliorare la risposta o richiedere chiarimenti, non per discussioni generali. Per una discussione approfondita, utilizzare [chat].
#15
+6
anonymous
2012-04-24 00:35:26 UTC
view on stackexchange narkive permalink

Gli altri sollevano molti punti positivi su come gestire la situazione; tuttavia, alla fine della giornata, se il programma del tuo gruppo sta disturbando gli altri in azienda, devi correggere il problema e assicurarti che le cose procedano senza intoppi. Con questo in mente, è necessario scoprire quando altri gruppi necessitano di un accesso affidabile agli sviluppatori e se c'è spazio per la flessibilità in quella pianificazione. Se altri gruppi necessitano di accesso agli sviluppatori quando sono in ufficio in modo imprevedibile, un segmento centrale di sviluppatori deve assicurarsi che tale esigenza sia soddisfatta. Se questo significa che alcuni sviluppatori devono essere in ufficio a periodi di tempo fissi, allora è quello che è.

Per quanto riguarda il trasferimento degli sviluppatori a una sorta di programma di disponibilità fisso, la soluzione migliore è garantire che le "ore difficili" siano ammorbidite il più possibile. Ad esempio, se le "ore di base" sono dalle 11:00 alle 15:00, puoi anche assicurarti che le ore di base del venerdì non siano presenti e che il venerdì sia un vero giorno flessibile. Poiché martedì, mercoledì e giovedì sono tradizionalmente considerati i giorni più produttivi della settimana, potresti essere in grado di applicare le ore di base a quei giorni e consentire anche a lunedì e venerdì di essere giorni flessibili.

In termini di garantire il rispetto delle ore, se la direzione scende dall'alto ed è approvata dai vertici aziendali, alla fine gli sviluppatori devono aderirvi come parte del loro impiego. Dovresti fare quello che puoi per assicurarti che sia introdotto gradualmente e se alcuni sviluppatori hanno tempo flessibile scritto nel loro contratto di lavoro dovrebbe essere affrontato (ad es. Modificando i loro compensi e benefici, acquisendoli, ecc.); tuttavia, a un certo punto dovrai assicurarti che la politica debba essere rispettata, il che potrebbe anche richiedere una disciplina ufficiale da parte dei dipendenti. Allo stesso modo, se alcuni scelgono di andarsene, può valere la pena provare a vedere se sono disposti a rimanere con compensi e modifiche ai benefici; tuttavia potresti anche dover accettare di perdere alcuni sviluppatori.

In definitiva, se il tuo lavoro richiede che imponi un cambiamento culturale al gruppo per soddisfare le esigenze dell'azienda, le tue opzioni saranno limitate in una certa misura. Puoi e dovresti fare di tutto per ammorbidire il cambiamento e sollecitare eventuali compromessi con altri gruppi il più possibile, ma alla fine dovrai applicare il cambiamento e accettare qualsiasi cambiamento di personale che potrebbe derivarne.

#16
+2
Karlson
2012-04-12 23:14:29 UTC
view on stackexchange narkive permalink

Ci sono ancora molte strade a tua disposizione per gestire questo problema, una delle quali sarebbe cambiare il ruolo che il dipartimento svolge, ad esempio: se lavori con sviluppatori di software potresti cambiare il ruolo per una o più persone durante la settimana per fargli fare supporto per gli altri reparti, che richiede uno o più per entrare alle 9 o prima e se non funziona puoi sempre invocare una clausola di insubordinazione che normalmente è presente in qualsiasi manuale del lavoro negli Stati Uniti . Personalmente sono sempre stato contrario all'uso di questa clausola, che offre a un manager la possibilità di rimproverare e persino licenziare qualcuno per giusta causa , ma nel tuo caso potrebbe essere appropriato. Quindi rivedi il manuale del dipendente e discuti con il tuo superiore se ne hai qualcuno che lo farai.

L'idea di base è la seguente:

  1. Tu imposti la regola che almeno 1-2 o tutte le persone dovrebbero essere al lavoro entro l'ora X.
  2. Se i membri del tuo team non hanno una scusa valida per non presentarsi o persistere in questa pratica, come manager dovresti rimproverarli e possibilmente licenziarli.

Come manager che fa ciò che io descritto sarebbe l ' ultima risorsa ma in base a ciò che stai descrivendo potresti essere arrivato a quel punto. Ci sono molti articoli su come costituire insubordinazione dei dipendenti che puoi trovare online e questi sono solo alcuni esempi:

Ovviamente la sfortunata conseguenza potrebbe essere un alto tasso di turn over nel tuo gruppo che rifletterebbe male su di te come manager ma rafforzerà la disciplina e probabilmente ucciderà il morale nel processo.

Ora, detto tutto ciò, ho una domanda: hai davvero bisogno che la tua squadra partecipi prima di quando entrano?

In risposta alla tua domanda - Sì. Abbiamo più reparti con i quali lavoriamo regolarmente. Questi reparti sono tra 8-9 e lasciano tra 4: 30-5: 30. Un orario di inizio tardivo e un pranzo significa, come minimo - 1) Nessun incontro prima delle 13:00 e 2) Sprecare mezza giornata o più se qualcuno sta aspettando qualcosa dal nostro dipartimento. Incredibilmente inefficiente.
@JacobG la classica conseguenza è "Rimani fino a tardi per finire il lavoro, o attracchiamo in vacanza". Rispetto a "tutti" che trovano alle 9:30 un orario di inizio ragionevole: io no. Poi di nuovo, lavoro fino alle 8-9 di sera, a volte più tardi e spesso dopo essere tornato a casa. Quelle sono le mie ore più produttive, e non le inserirò se dovessi entrare dalla porta alle 9.30 in punto "oppure" - diventerei un 9 a 5er. Ogni squadra è unica e spero che tu lo consideri nella tua valutazione ...
@Jacob - che tipo di team di sviluppo è questo? Ragazzi, siete solo un'altra azienda che gestisce l'app X interna o questi sviluppatori di alta qualità stanno scrivendo un codice solido che è la spina dorsale della vostra azienda? In quest'ultimo caso, alcuni di loro si aspettano di poter lavorare fino a tardi da casa e di arrivare tardi non sembra sorprendente. Ti suggerirei di provare ad adattarlo. Gli sviluppatori di qualità sono * incredibilmente * difficili da trovare. E hanno sempre altre opzioni se il lavoro attuale non funziona.
@voretaq7 non la prende nel modo sbagliato, ma trovo che sia in gran parte una questione di abitudine. Se prendi l'abitudine di andare a letto alle 23:00 invece delle 3:00 e di alzarti alle 7:00 invece che alle 9:30 scoprirai che dopo un po 'il tuo momento più produttivo sarà prima di pranzo e che alle 21:00, inizia ad avere un po 'di sonno. Gli esseri umani si adattano.
@JacobG Perché "sprecare mezza giornata"? Queste altre squadre arrivano alle 8 del mattino e si rendono conto improvvisamente di aver bisogno di qualcosa da uno sviluppatore?
@robertc Ci sono certamente occasioni in cui gli altri team arrivano a 8 e vedono che c'è qualcosa che richiede l'attenzione dello sviluppatore. Ma non era questo il punto. Il punto era che se un altro dipartimento sta bloccando qualcosa del team di sviluppo, il blocco non verrà mai rilasciato fino almeno a metà giornata del richiedente. A volte va bene e molte volte è semplicemente scomodo.
@JacobG Ma ti manca il mio punto, perché stanno aspettando fino alle 8 del mattino il giorno in cui hanno bisogno di qualcosa per decidere di dire allo sviluppatore che hanno bisogno di qualcosa?
@robertc Perché non sanno di aver bisogno di qualcosa fino alle 8 del mattino. "Un cliente ha chiamato e stava riscontrando questo problema ..." "Sembra che questi dati siano danneggiati ..."
@JacobG Nessuno degli esempi che hai elencato sono attività di sviluppo. Anche se stai facendo in modo che i tuoi sviluppatori forniscano supporto client (come stai sottintendendo), perché tutti i tuoi sviluppatori devono essere in ufficio a un certo orario per fornire supporto? Perché hai promesso tempi di consegna specifici ai clienti e ad altri reparti su questioni di supporto quando non disponi di personale di supporto dedicato?
Ho lavorato in una manciata di squadre che sono state infrante a causa di regole come quella suggerita qui. Un consiglio: le persone potrebbero iniziare ad arrivare presto per alcune settimane. Ma dopo li vedrai lavorare per la competizione.
#17
+2
A quiet hum
2018-06-24 21:22:16 UTC
view on stackexchange narkive permalink

Fondamentalmente, devi decidere cosa è più importante, portare a termine il lavoro correttamente o stare seduto alla scrivania per 8 ore a orari prestabiliti?



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...