Hoe kan ik een cultuur van stiptheid in een softwarebedrijf stimuleren?

De beste motiverende factor is vertrouwen. De eenheid van het team is van ultiem belang voor het bereiken van je doelen. Regelculturen worden gekweekt door wantrouwen, en stokken en prikkers om regels af te dwingen zullen het vertrouwen van je team alleen maar verder ondermijnen.

In plaats van bezorgd te zijn over exacte tijden en informele culturen, probeer uit te zoeken wat de intrinsieke waarden zijn.

• Doet 9:30 (of een willekeurige tijd) er echt toe? Of moet uw team ervoor zorgen dat ze het werk van andere teams niet hinderen door hun afwezigheid?

• Maakt 5 minuten een verschil? Of is het belangrijk dat alle leden deelnemen aan de dagelijkse gang van zaken?

• Is informaliteit een probleem? Of is flexibiliteit een voordeel?

zou ik in het middelpunt van de belangstelling plaatsen, namelijk dat uw team zich niet in het idee heeft ingespannen. Kijk waar de ontkoppeling is, maar vermijd het creëren van een regelcultuur. Door ze naar huis te sturen omdat ze te laat zijn (een disciplinaire tactiek die je op een basisschool zou aantreffen) zal je team geloven dat je ze ziet als kinderen die niet te vertrouwen zijn.

Het creëren van een stiptheidscultuur kan tijd kosten en kan iets zijn waar je wat aan moet doen. Aangezien je te maken hebt met intelligente kenniswerkers, zul je meer succes hebben als je ze in het plan kunt krijgen. In plaats van je te concentreren op de tijd, richt je je op het probleem dat ontstaat door de planningsproblemen.

Presenteer het probleem als een uitdaging voor het team en zie wat ze bedenken. Het antwoord kan zijn dat de planning is ingesteld of dat het iets anders is dat het probleem oplost. Het kan maandag, woensdag, vrijdag zijn, terwijl dinsdag en donderdag de flexdagen zijn. Hoewel het plan misschien niet perfect is en het ook niet precies zal zijn wat u voor ogen had, zal het vinden van een middenweg ergens die zowel het ontwikkelingsteam gelukkig maakt, als het oplossen van het eigenlijke probleem voorkomen dat uw personeel verbitterd wordt en u als de vijand ziet.

Houd er rekening mee dat je niet te maken hebt met een fabricageproces waarbij iedereen om precies 9:30 uur ‘s ochtends, als het fluitje gaat, moet opdagen, zodat ze kunnen beginnen met de geestdodende taak om dezelfde kleine plastic widgets herhaaldelijk in elkaar te zetten, totdat het fluitje weer gaat fluiten, en het geestdodende personeel zich naar de plaatselijke bar voor happy hour begeeft.

Mijn team komt niet op tijd opdagen. Ik heb geprobeerd ze te dwingen en het werkt niet.

Dwingen van slimme mensen werkt nooit. […] Deze mensen, althans de echt goede, zullen nooit zomaar blindelings bevelen opvolgen. Dit gaat terug naar het in handen geven van het probleem, in ieder geval in het begin. Als ze niets doen, dan wil je in de praktijk komen met je eigen oplossing.

Je hebt gezegd dat je een nieuwe teamleider bent. Het is uitdagend en stressvol om in zo'n nieuwe functie te stappen, omdat je niet zeker weet hoe je respect voor het team kunt krijgen en ook nog eens een goede leider kunt zijn. […] Dit is geen leiderschap.

Ontwikkelaars, en andere kenniswerkers, hebben geen behoefte aan een manager; in plaats daarvan hebben ze een leider nodig. […] Ik raad iedereen die een leidinggevende functie heeft ten zeerste aan om dit korte interview te bekijken.

Het is mijn ervaring dat kenniswerkers het niet leuk vinden om gedicteerd te worden over beleid waarvoor ze zien geen doel hebben. U geeft wel een doel aan, maar de medewerkers die u aanstuurt lijken te denken dat het geen goed doel is. Verder zijn er waarschijnlijk alternatieven die u niet in overweging hebt genomen, en gezien wat klinkt als een kwestie die “van bovenaf wordt gedicteerd”, hebben uw werknemers er misschien niet aan gedacht, voelen ze zich niet op hun gemak om ze voor te stellen, of hebben ze het gevoel dat ze gewoon worden neergeschoten.

Als de enige reden waarom u het beleid uitvoert, is het uw taak om die spanning te managen, zodat uw mensen het meest effectief kunnen werken. Ik denk echter niet dat dat de enige reden is. Wat als er bijvoorbeeld een ontwikkelaar nodig is om een dringend productieprobleem op te lossen dat om 8.00 uur of 9.00 uur of wat dan ook gebeurt? Het is echter onwaarschijnlijk dat u allemaal uw ontwikkelaars nodig hebt om dat probleem op te lossen. Wat als u een roulerend (tenzij er iemand vrijwilligerswerk doet) “vroeg” schema had, zodat elke ontwikkelaar om 8:00 uur (of 9:00 uur, etc.) aan de beurt moet zijn? Die oplossing lijkt eerder te voldoen aan zowel de zakelijke behoeften als de wensen van uw medewerkers. Iedereen “deelt de pijn” (of legt het op aan iemand die het niet erg vindt). Mensen kunnen het grootste deel van de tijd binnenkomen en werken wanneer ze het gevoel hebben dat ze het meest productief zijn. Dit is slechts één mogelijkheid, maar het kan een discussie op gang brengen met uw medewerkers over hoe de echte problemen op te lossen en ieders belangen hier te bevredigen.

Als u ervoor kiest om de meer disciplinaire weg in te slaan, en de “starttijd” kwestie is echt belangrijk voor uw ontwikkelaars, verliest u uw goede aan een andere baan. Uw medewerkers zullen zich waarschijnlijk onzeker voelen in hun baan (wat als er een echt noodgeval gebeurt op een dag om iemand te laat te maken?). Verder kan dit gezien worden als een verschuiving in het management in de verkeerde richting (vanuit het perspectief van uw medewerkers), aangezien zij eerder ervaring hadden met het werken onder iemand anders.

Het is natuurlijk aan u, maar ik wil u aansporen om een stapje terug te doen en harder te proberen om de situatie te zien vanuit het perspectief van uw medewerkers. Je hebt natuurlijk een taak te vervullen, maar ik denk dat er oplossingen zijn die beter voldoen aan ieders belangen dan degene die je voorstelt.

Het precieze antwoord op je vraag is om iemand te ontslaan en te vervangen die het bericht niet begrijpt en dan iemand anders te ontslaan die het bericht niet begrijpt.

Ik verwacht niet dat dit je carrière of de ontwikkelingsdoelen van je bedrijf zou helpen, maar je hebt besloten dat dit het probleem is en het lijkt erop dat je er niet van overtuigd bent dat dit anders het geval is. Dus dat is hoe je het moet doen.

Meer constructief, ik stel voor dat je het volgende overweegt:

• Je devs had flexibele tijd. Nu wil je het wegnemen

Het maakt niet uit of het een officieel voordeel is in een of ander geschreven beleid of niet. Het is een de facto beleid en een onderdeel van de gevestigde cultuur. Mensenlevens en -schema’s zijn rond deze uren vastgelegd. En voor devs zoals ikzelf, die veel liever het spitsuur ontwijken en die in de winter een afschuwelijk vervelend geval van SAD krijgen, maar geen dev-vriendelijke plaatsen kunnen bedenken dichter bij de evenaar waar ik liever woon, is het net zo groot als het trekken van gezondheidsvoordelen.

• Wat is de aard van deze “angst” waar je het over hebt? Is het a) vooral jaloezie of b) legitieme interdepartementale communicatieproblemen zoals problemen met het plannen van vergaderingen/algemene communicatie.

a) Devs hebben geen behoefte aan interactie met klanten of andere bedrijven. Mijn ervaring is dat hoe stijver de bedrijfsstructuur, des te middelmatiger de devs. Hoewel veel van de ontwikkeling is moeren en bouten, is het ook een creatief probleemoplossingsproces dat vereist dat mensen op hun scherpst zijn. Het is ook een onvoorspelbaar deadlinegedreven proces dat soms tot zeer, zeer late uren leidt. Een neveneffect hiervan is dat devs vaak de “creatieve” behandeling krijgt. In een bedrijf van 30 personen zou het niet moeilijk moeten zijn om aan te dringen dat mensen volwassen zijn over werknemers die op hun scherpst moeten zijn wanneer ze aanwezig zijn en die uiteindelijk waarschijnlijk veel meer uren in de loop van een jaar zullen steken dan een 9-5er die gewoonlijk elke dag om 16:55 uur zijn spullen inpakt.

b) In een bedrijf van 30 moet je niet zoveel vergaderingen hebben dat dit een probleem wordt. Als je dingen zoals sprintvergaderingen of andere tweemaandelijkse planningssessies niet meetelt, is het elke dag vastbinden van je devs voor meer dan 30 minuten in vergaderingen een absurde, grove incompetente verspilling van geld. Hetzelfde geldt voor de algemene communicatie. 30 mensen betekent dat je naar de andere man toe loopt en met hem praat. In flexibele tijdscenario’s is het redelijk om een tijdspanne in te stellen waarin iedereen op hetzelfde moment op kantoor is. Ik kan geen goede reden bedenken waarom die tijdspanne meer dan 3-4 uur van de werkdag zou moeten bedragen en waarom het niet zo dicht mogelijk bij het midden van de dag zou moeten zijn.

• Waarom een ochtend standup?

Hoe komt het dat het eerste idee management uitvalt van scrum, agile, etc… is altijd het advies dat je de standup niet als eerste hebt? Bij het programmeren duurt het een tijdje om terug te keren naar de volledige bewustwording van alle details en problemen waar je mee te maken hebt bij een bepaald probleem. Wanneer je standups als eerste doet, zullen je devs hun hoofden niet volledig vastgeschroefd hebben. Standups zijn cruciaal voor de communicatie en het verbeteren van de efficiëntie, niet iets wat je als eerste doet om “uit de weg te gaan”.

• Zijn je devs er niet in geslaagd om de klus te klaren?

Zo niet, waarom zou je dan rotzooien met een goede zaak? Het is niet hun taak om te communiceren met de andere bedrijven in het bedrijf. Het is de jouwe. In een gezonde managementstructuur is je verantwoordelijkheid aan je directe manager en de mensen die je leidt, niet aan de zure druiven van andere afdelingen die er om praktische redenen op meer typische tijdstippen moeten zijn.

Het eerste wat je moet doen is ga “Peopleware” lezen

Het is een vergissing om dit nu te proberen te veranderen. Ik was een manager bij een bedrijf waar we een vrij flexibel werkschema hadden. Een van onze meest productieve ontwikkelaars kwam om 11 uur ‘s ochtends binnen. Hij meldde zich een tijdje bij mij. Ik kreeg te horen dat hij zijn uren moest veranderen. Ik vocht tegen dit verzoek. Hard. Ik werd overruled.

Het resultaat:

Een minder productieve, minder geïnteresseerde ontwikkelaar die een enorme teambijdrage leverde. Hij werd veel minder productief en nuttig voor het team.

Alles vanwege een domme notie van “op tijd”.

Focus meer op productiviteit.

Jouw taak als manager is het wegnemen van barrières voor productiviteit - niet iedereen er hetzelfde uit laten zien, voelen en handelen.

Flexibele uren zijn een voordeel - en een werkgever die flexibele uren toestaat kan meer kwaliteitsmensen aantrekken.

Als “nieuwe technische voorsprong” is er geen manier om de cultuur snel te veranderen. Zeker niet in de richting die je lijkt te willen. Heeft u iets gedaan om de rollen/functies van uw team te verbeteren?

Werk eerst samen met hen aan het opbouwen van vertrouwen. Zoveel eerste keer managers maken fouten als deze.

Vindt uit wat de andere groepen ECHT nodig hebben. Niet “ze moeten hier om 9:30 uur zijn”. Zoek echt uit wat er aan de hand is. Zoek dan een oplossing voor dat probleem.

In plaats van je team te vertellen wat ze moeten doen - leg het probleem uit en ASK THEM FOR SUGGESTIONS/FEEDBACK.

Je maakt een vage verwijzing naar “veroorzaakt veel angst tussen mijn afdeling en andere afdelingen” - maar het is onduidelijk wat die angst is - zijn ze boos dat devs bij voorkeur worden behandeld? Wat is het echte onderliggende probleem?

Ik heb geprobeerd ze te dwingen en het werkt niet.

Er is een reden voor. En je lijkt niet te luisteren. Het bereiken van meer drastische maatregelen en grotere hamers zal de situatie niet echt verbeteren. Probeer de “wortel” aanpak in plaats van de “stok” aanpak.

Nogmaals, lees “Peopleware”.

Je gaat niet ver met ideeën zoals dagelijkse ontmoetingen of het naar huis sturen van mensen of met het idee dat ze je volgelingen zijn die moeten doen wat je zegt, “of anders.”

Wie vertelt je dat ze om 9:30 uur op het werk moeten zijn? Andere groepen? Je bazen? Jij? Zoek het echte probleem uit en pak dat aan. Als ze komen opdagen, moet dat NIET het probleem zijn.

Het maakt niet uit waarom je het doet, voor je teamleden voelt het alsof je een voordeel wegneemt. Voor sommige van hen kan het zelfs een van de belangrijkste redenen zijn waarom ze voor jouw bedrijf werken in plaats van voor een ander.

In wezen vraag je ze om een verlaging van hun totale vergoedingspakket.

Het is mogelijk om ze te overtuigen om het te nemen, maar je zult goede argumenten nodig hebben en er zal vrijwel zeker een blijvende wrok over zijn. Je kunt wel of niet goede mensen verliezen door dit.

Uit je beschrijving blijkt dat de belangrijkste reden jaloezie van andere afdelingen is. Heb je overwogen om de andere afdelingen hetzelfde perk te geven?

Kortom: Doe het niet tenzij je denkt dat het de moeite waard is om er een aantal van hen over te verliezen.

Om je cultuur te veranderen moet je je realiseren waarom je weerstand ondervindt en vervolgens de oorzaak van de weerstand managen.

In mijn ervaring is de “coördinatie met andere afdelingen” meestal de provincie van degenen met een hogere positie titels en leidt het een project/mensen-managementtraject. Werk-een-dag devs die alleen geïnteresseerd zijn in code worden hier meestal van afgeschermd. In meer gestructureerde winkels doen ze het misschien helemaal niet en in kleinere winkels doen ze het misschien meer informeel.

Like it or not, you’ve inherited a flex hours culture, which is a huge perk for most developers. Dat van hen wegnemen in een van je eerste handelingen als leider zal hen niet alleen tiranniek lijken (als je hen uitlegt dat 9:30 niet dat vroeg is, leg je hen je eigen agenda op, willekeurig in hun ogen), maar is realistisch gezien de aftrekking van een substantieel perk. U vindt het misschien leuk om aan een bepaald schema te werken en beschouwt dit niet als een betekenisvol perk, maar ze vinden het waarschijnlijk van onschatbare waarde. Beschouw dit als hetzelfde als hen te vertellen dat je een week van hun vakantie wegneemt of hun loon met een paar procent verlaagt.

Om dat te veranderen kun je de wortel of de stok gebruiken. Je hebt het over het gebruik van een stok en, misschien, een grotere stok. Als je die weg inslaat, ben ik van plan om een paar nieuwe ontwikkelaars in te huren, omdat ik denk dat een deel van je team gaat beginnen met interviews bij andere bedrijven. Ik zou persoonlijk gaan de wortel route om buyin te krijgen voor het verwijderen van deze perk door het duidelijk te maken dat toekomstige promoties en vorderingen zullen worden beslist door degenen die “coördineren met andere afdelingen”. Dat wil zeggen, leiders / belangrijke mensen zijn in het begin, het werken met andere teams, het nemen van verantwoordelijkheden, enz. “Newbies” krijgen het flex perk, maar mensen die het serieus menen met vooruitgang komen op tijd binnen.

Als je die cultuur creëert, dan vermoed ik dat sommige van je devs op tijd zullen beginnen te komen uit eigen beweging. Zowel door de interesse in vooruitgang als door de perceptie dat “de belangrijke mensen er vroeg bij zijn”.

Ik benijd je niet. Als collega-manager zou het moeilijk voor me zijn. En eerlijk gezegd, ik geloof dat je er mensen over gaat verliezen. Ik denk dat je een enkel symptoom hebt dat voortkomt uit de Start Up - Ik denk dat je voorbereid moet zijn met functiebeschrijvingen en kennis van hoe je vacatures opent en ik denk dat je de nadruk moet leggen op het vermogen om nieuwe mensen aan te nemen en de documentatie te verbeteren…

Sorry dat is zo grimmig. Maar ik denk niet dat je een situatie van vertrouwensproblemen hebt, of een geval waarin je mensen gemakkelijk kunt uitleggen waar ze het mee eens zijn. En er is echt geen compensatie die perfect in evenwicht is met een enorme flexibiliteit op het werk.

Ik ben het ermee eens dat je een voordeel wegneemt. Flexibiliteit in de starttijd is voor sommige mensen een groot goed, en het spreekt tot een informele cultuur die voor sommige mensen een sterke voorkeur kan hebben. Vermoedelijk is het bedrijf gegroeid, de werkdruk is betrouwbaarder geworden, de werkzekerheid is verbeterd, het respect voor het product is toegenomen, en je hebt misschien een aantal handige voorraadplannen, loonsverhogingen of andere verbeteringen kunnen bieden. Als niets van dat alles waar is, dan heb je de vraag of je een groeiend & bloeiend bedrijf hebt of een bedrijf dat zich in wanhoop stort.

Trick is, mensen kunnen vaak niet de puntjes op de i zetten tussen deze nieuwe waardetoevoegingen en het verwijderen van het favoriete perk. Je kunt het proberen uit te leggen, maar voor sommige mensen is dit geen goede afweging, en dit is niet een geval waarin je de keuze kunt bieden. Het is een “mijn weg of de snelweg” omdat het een organisatorische impact heeft die niet noodzakelijkerwijs binnen het team te voelen is, maar die wel wordt ervaren en ondersteund op de hogere niveaus van het bedrijf.

Het klinkt alsof je de juiste dingen hebt gedaan:

• je hebt het duidelijk uiteengezet

• je hebt gesproken over de reden en de noodzaak van verandering

• je hebt één op één ingeschakeld (en blijft dat doen, neem ik aan) om individuele gevallen op te lossen als ze zich voordoen

• je hebt feedback gegeven

Ik denk dat je het hebt over de “meent hij het echt? "punt waar het vooral aan mensen bewijst dat je serieus bent, en dat dit echt moet veranderen. Het zou mijn persoonlijke mening zijn dat 5 minuten te laat zijn in een kantoor in mijn regio geen groot probleem is en dat vergaderingen die een korte spanwijdte hebben (zoals stand ups in een wendbare sprint) niet zo tegen het begin van de werkdag aan moeten gaan dat een gemiste busverbinding of slecht verkeer een regelmatig terugkerend probleem wordt. Maar dit is enigszins regionaal - verschillende locaties hebben grote verschillen in de verkeerssituatie. Dat is dus net zo goed je regio kennen en van individuele klachten weten wat redelijk is.

De rest komt gewoon met een mechanisme dat slopend genoeg is om te bewijzen dat je serieus bent. Een dagje gedokt loon is een optie en het valt binnen je wettelijke rechten - alhoewel elk mechanisme dat ik zou verzinnen, ik zou de advocaten doornemen. Zo is een formeel waarschuwingssysteem dat leidt tot discplinaire actie. Ik zou aannemen dat uw HR-afdeling misschien suggesties heeft…

Veel hangt af van wat het werk kan verdragen - als je iemand naar huis stuurt, verlies je ook op het werk van die dag, wat invloed heeft op je kosten & planning. Wanneer je een waarschuwingssysteem hebt dat leidt tot disciplinaire maatregelen - inclusief ontslag - bespaar je de rest van de dag werk, maar riskeer je de werknemer te moeten ontslaan.

Ik denk dat het ding is, wanneer je te maken hebt met straffen, moet je voorbereid zijn met een straf die schadelijk genoeg is om serieus genomen te worden en om naar huis te rijden met het punt dat "je je werk niet doet als je dit niet doet”.

Het korte antwoord is dat je dit NIET moet doen. Uw technische teamleden zijn (of tenminste, zou moeten zijn) slim genoeg om te weten dat er geen tastbaar voordeel is om iedereen op kantoor aanwezig te hebben tegen een willekeurige tijd; de _alleen belangrijke metriek is of hun werk al dan niet gedaan wordt.

Als uw team zijn werk niet gedaan krijgt, dan is dat een aparte kwestie. Maar als ze hun werk wel gedaan krijgen, waarom valt u ze dan lastig, alleen maar omdat andere afdelingen u lastig vallen?

Een deel van uw rol als leider is het isoleren van uw team van triviale afleidingen en kritiek die door externe bronnen worden veroorzaakt. Als uw reactie op andere mensen die over uw teamleden klagen, is het doorgeven van de klachten aan uw teamleden en/of het dicteren van veranderingen uitsluitend op basis van die klachten, dan faalt u op uw werk. Ik stel voor dat, in de veronderstelling dat je team in feite zijn werk doet (wat het klinkt alsof ze dat doen, aangezien je geen klachten maakt over hun productiviteit), een betere manier om te reageren op dergelijke kritiek is om de klagende partij te vertellen “ja, nou mijn jongens werken hard en leveren consequent goede resultaten, en dat is het enige dat telt; dus waarom stop je niet met je zorgen te maken over hoe mijn team met hun taken omgaat en ga terug naar je eigen team? ”.

En natuurlijk, als je doorgaat met een verplicht “je moet op kantoor zijn tegen tijd X” beleid, is het alleen maar eerlijk om het aan te vullen met een “je moet het kantoor verlaten tegen tijd Y” beleid, en een “je moet niet van thuis uit werken buiten de normale kantooruren” beleid. Dat is alleen maar eerlijk als een manier om de balans tussen werk en privéleven van uw werknemer te beschermen, want ik durf te wedden dat veel van de teamleden die u heeft en die niet komen opdagen tot 11:00 uur, waarschijnlijk ofwel te laat terug zijn ofwel extra tijd thuis doorbrengen.

Het lijkt erop dat er een kloof bestaat tussen hoe uw ontwikkelaars het probleem zien, en hoe de andere afdelingen (of uw superieuren, of wie het ook is die deze verandering daadwerkelijk eist) het probleem zien. Ik stel voor om te proberen die kloof te overbruggen, indien nodig in meerdere fasen.

Ten eerste, zijn de ontwikkelaars het erover eens dat er goede redenen zijn voor deze verandering? Als ze het er niet mee eens zijn, hebben ze dan goede tegenargumenten, of alternatieve suggesties? Als ze dat wel hebben, moet je die naar het management brengen en kijken of ze de tijdsvereisten kunnen versoepelen - of dat ze kunnen uitleggen waarom de alternatieven niet zullen werken en de tegenargumenten het probleem niet oplossen, zodat je terug kunt gaan naar je ontwikkelaars en ze een meer volledige uitleg kunt geven. Ga zo lang als nodig/productief door met het heen en weer gaan.

Als je op het punt komt dat de ontwikkelaars het erover eens zijn dat er goede redenen zijn, maar gewoon niet bereid zijn om zich aan te passen, of ze denken dat de redenen niet goed zijn en hebben een hekel aan het hele idee, communiceer dat dan aan het management. Leg uit dat je kan de ontwikkelaars kan dwingen om te doen wat ze willen, maar het zal wrok, een lagere motivatie, mogelijk een lagere productiviteit of zelfs het vertrek van medewerkers met zich meebrengen. Zorg ervoor dat het management dit begrijpt en dat je het er nog steeds mee eens bent dat het belangrijk is om de starttijd af te dwingen (en nogmaals, communiceer dit aan je ontwikkelaars), anders kun je uiteindelijk verantwoordelijk worden voor een verandering die het bedrijf meer heeft verloren dan het heeft gewonnen.

_(Een persoonlijke noot: Ik ben in de positie dat ik op een vast uurtje moet komen voor, wat de medewerkers betreft, geen goede reden, en het is echt heel erg ongemotiveerd. Het is echt belangrijk om ervoor te zorgen dat mensen de redenen begrijpen en niet het gevoel hebben dat je het beleid in een opwelling verandert of omdat je ze niet vertrouwt.

Ik werkte vroeger bij een non-profit organisatie die dit probleem had. Vergaderingen begonnen altijd laat, 10 minuten te laat werd een “standaard”.

Toen kregen we een nieuwe projectmanager voor een groot sleutelproject (en een op een vaste tijdlijn). Ze belde de eerste vergadering. Mensen liepen zoals gewoonlijk naar binnen, minuten te laat en nonchalant babbelend. Ze zat in haar stoel en zei enkele minuten lang niets - helemaal niets. Uiteindelijk ging het geklets “dood” tot er stilte was. We zaten allemaal te wachten om te horen spreken. Ze liet de stilte nog even voortduren. Ze keek om zich heen en zei: “Ik moet het duidelijk maken. De vergaderingen beginnen op tijd. Als je 5 minuten te laat gaat zijn, doe dan geen moeite om te komen, zie me daarna gewoon. OK, nu voor het project dat we deze week doen [wat dan ook]…” Dit maakte een GROTE indruk en de mensen deden echt hun best om op tijd te zijn voor haar vergaderingen.

Note: Extra antwoord toegevoegd hieronder.

Rekening voor werk dat op afstand wordt gedaan.

Vaak doen de hoogste producenten toch al een groot deel van hun werk ** op afstand**, dus ze zetten soms net zoveel tijd op afstand in als op kantoor. Dit is een belangrijk punt om te overwegen en te communiceren met de andere afdelingen. Die communicatie moet subtiel zijn - bel geen vergadering, ga gewoon op zoek naar manieren om te laten zien “yeah, joe was gisteravond laat aan het werk op x” en “yeah, Mary repareerde dat op zondag, ze was op ‘till like midnight’.

Praat openlijk over het woon-werkverkeer. Als iemand om 10.30 uur binnenkomt, kan hun woon-werkverkeer 15 minuten duren. Als ze om 9.30 uur of 9.30 uur binnen moeten zijn, kan hun woon-werkverkeer een uur duren. Plus het zou hetzelfde zijn om naar huis te gaan als ze 8 of 9 uur werken. Veel mensen vinden dit een grote verspilling van hun leven. Ze werken liever een tijdje op afstand en komen dan daarna binnen. Zorg ervoor dat u dit feit integreert met uw behoeften bij het instellen van de tijden en zorg ervoor dat andere afdelingen dat ook weten, door het opnieuw vaak te vermelden.

Zorg ervoor dat u technologie gebruikt om te helpen. Ik werk bijvoorbeeld bijna - 100% van de tijd. Dus als ik Skype aan heb, mijn status online laat zien, een video-cam laat zien, etc. kan dat ook helpen.

Nu ik me in vergelijkbare situaties bevind, zij het in minder tijd dan de OP, heb ik alleen dit te zeggen over de toestand van zijn situatie:

De meest praktische en eenvoudigste oplossing…

…zou zijn om in plaats daarvan te proberen de vergaderingen om 11 uur te beginnen. Maak je geen zorgen, je geeft niet “toe”. In plaats daarvan stuur je de stroom om, net als de principes achter Aikido . Het idee is om je in plaats daarvan te richten op het in staat stellen van je team om belangrijke dingen gedaan te krijgen, want er is echt een serieus probleem dat moet worden aangepakt:

Het team heeft echt geen idee wat er met de andere afdelingen is en wat ze ECHT moeten doen.

Je team laten opdagen om 9:30 uur, wat ik kan toegeven, is echter geen oplossing voor dit probleem. Je hebt geprobeerd en gefaald, dus stop met erop aan te dringen om dit te doen . Stop met het slaan van je hoofd op een stenen muur. Mijn enige tip hier is om de communicatie altijd te waarderen boven willekeurig ingestelde vergaderingen.

Aangezien de andere afdelingen om 8 uur beginnen, kun je ** deze late teamvergadering in je eigen voordeel gebruiken. Tussen 8 en 11 uur heeft u **3 uur om uw team te helpen met projectmanagementactiviteiten zoals (in geen bepaalde volgorde of prioriteit):

• Ga naar vergaderingen en verzamel doelstellingen en eisen van de andere afdelingen
• Zoek uit wat er sinds gisteren klaar is - Manage verwachtingen en afspraken met de andere afdelingen over wat er tijdens de werkdag gedaan moet en kan worden - Lever goed nieuws en slecht nieuws aan de andere afdelingen
• Update alle plannen die relevant zijn voor het team als er
• Zoek uit welke code en software architectuur problemen moeten aandacht hebben vandaag
• Zeg “NEE” tegen verzoeken die geen zakelijke waarde
• Accepteer kritiek van de andere appartementen en verontschuldig je met de zekerheid dat de problemen zullen worden opgelost
• etc. (er is altijd iets dat aangepakt moet worden)

En tenslotte voor de vergadering summarizeert het team een briefing over wat er aan de hand is, om hen wat situationeel bewustzijn te geven. Als de vergadering om 11 uur begint en iedereen is fris om aan het werk te gaan, heb je informatie en een vergaderingsprotocol voor hen klaarliggen. Je kunt de brief en de notulen van de vergadering als een nieuwsbrief laten schrijven en als een zachte herinnering een keer na de vergadering als e-mail versturen.

Tijdens de vergadering met het team heb je twee dingen van hen nodig:

• Vraag naar schattingen voor taken die gedaan moeten worden, met name die welke een hoge prioriteit hebben. Het hoeft niet precies te zijn, zoals in minuten. Hiermee kun je veel duidelijker afspraken en deadlines maken met de andere afdelingen. Als ze geen schatting kunnen geven voor een taak, vraag hen dan om dit in de loop van de dag of de volgende uit te zoeken.
• Vraag om impedimenten of als ze ergens hulp bij nodig hebben, schrijf dat op en zorg ervoor dat die problemen op te lossen zijn en dat ze opgelost worden.

Na een tijdje kunt u waarschijnlijk geleidelijk aan de vergaderingen eerder houden. Maar in eerste instantie tegen de stroom in gaan is niet de manier om te gaan en leidt alleen maar tot een nog besmettelijker cultuur (waarbij de enige manier om te repareren is om het hele team te vervangen). Als ze, zoals u zegt, “primadonna’s” zijn, dan is het uw echte taak om ze op te knappen tot geweldige primadonna’s die met hoge kwaliteit leveren. Het is duidelijk dat uw team autonomie had en wil, dus begin met het benutten van die cultuur in het voordeel van de doelstellingen van uw bedrijf.

Als het je gelukt is om een betrouwbaar team te maken, door middel van communicatie in plaats van dwang, kun je drie uur eerder vertrekken dan alle anderen in het team, wetende dat ze hun werk doen (maar nog steeds oproepbaar zijn als de rotzooi de fan raakt). Nu is dat vertrouwen waar je op kunt rekenen.

De anderen brengen veel goede punten naar voren over hoe om te gaan met de situatie; maar als het schema van uw groep uiteindelijk anderen in het bedrijf verstoort, dan moet u het probleem corrigeren en ervoor zorgen dat de zaken soepel verlopen. Met dit in gedachten moet u uitzoeken wanneer andere groepen betrouwbare toegang tot de ontwikkelaars nodig hebben en of er ruimte is voor flexibiliteit in die planning. Als andere groepen toegang tot de ontwikkelaars nodig hebben wanneer ze op een onvoorspelbare basis op kantoor zijn, dan moet een kernsegment van ontwikkelaars ervoor zorgen dat die behoefte wordt opgevangen. Als dit betekent dat sommige ontwikkelaars op vaste tijden op kantoor moeten zijn, dan is dat wat het is.

Met betrekking tot het verplaatsen van de ontwikkelaars naar een soort van een vast beschikbaarheidsschema, is het het beste om ervoor te zorgen dat eventuele “harde uren” zoveel mogelijk worden verzacht. Als de “kernuren” bijvoorbeeld van 11:00 tot 15:00 uur zijn, dan kunt u er ook voor zorgen dat de kernuren op vrijdag niet aanwezig zijn en dat de vrijdag een echte flex-tijddag is. Aangezien dinsdag, woensdag en donderdag traditioneel als de meest productieve dagen van de week worden beschouwd, kun je de kernuren op die dagen laten gelden en maandag en vrijdag ook als volledige flexdagen laten gelden.

Wat betreft de naleving van de uren, als de richting van de top komt en wordt goedgekeurd door het hoger management, dan moeten de ontwikkelaars zich er uiteindelijk aan houden als onderdeel van hun dienstverband. U moet doen wat u kunt om ervoor te zorgen dat het gefaseerd wordt ingevoerd en als sommige ontwikkelaars flextijd in hun arbeidsovereenkomst hebben opgenomen, moet dit worden aangepakt (bijvoorbeeld door hun vergoeding en voordelen te wijzigen, ze in te schrijven, enz. Evenzo, als sommigen ervoor kiezen om te vertrekken kan het de moeite waard zijn om te proberen te zien of ze bereid zijn om te blijven met veranderingen in vergoedingen en voordelen; het kan echter ook zijn dat u moet accepteren dat u sommige van de ontwikkelaars verliest.

Uiteindelijk, als uw baan vereist dat u een culturele verandering aan de groep afdwingt om te voldoen aan de behoeften van het bedrijf, dan zullen uw opties tot op zekere hoogte beperkt zijn. Je kunt en moet alles doen om de verandering te verzachten en eventuele compromissen met andere groepen uit te lokken als je kunt, maar uiteindelijk zul je de verandering moeten afdwingen en elke personeelsverandering die ermee gepaard gaat moeten accepteren.

Ik lees opmerkingen en antwoorden en ik moet toegeven, ik ben een beetje verbijsterd. Sinds wanneer is het hebben van mensen opdagen op tijd “verlies van een perk”? Sinds wanneer hoeft flex-time zich geen zorgen te maken over de impact van je acties op de rest van het team en het bedrijf?

Van wat ik lees in de vraag en opmerkingen, is het gedrag van zijn teamleden aantoonbaar schadelijk en kostbaar voor het bedrijf. En na een poging om te redeneren en compromissen te sluiten, is de situatie niet verbeterd (en btw, 9.30 is niet vroeg of op enigerlei wijze onredelijk).

Leg aan je team uit dat je geen probleem hebt met flex-tijd, maar dat het een zekere persoonlijke verantwoordelijkheid impliceert om ervoor te zorgen dat je flexing geen invloed heeft op het werk van anderen (op je team of andere teams). Aangezien uw team duidelijk tekortschiet op het gebied van verantwoordelijkheid, zou ik zeggen dat met onmiddellijke ingang en tot nader order alle flex-tijd door u vooraf moet worden goedgekeurd. Als u ‘s morgens niet op tijd komt opdagen zonder goedkeuring of een redelijk excuus (nee, de wekker ging niet af is niet acceptabel) ** zal dit leiden tot disciplinaire maatregelen zoals dokloon of vakantietijd.

Wees heel duidelijk waarom dit gebeurt en wat u gedwongen heeft om deze maatregelen te nemen. Wijs erop dat dit niet iets is wat je wil doen, maar iets wat je gedwongen bent te doen. Wees ook duidelijk dat dit restrictieve beleid kan worden opgeheven zodra de situatie verbetert.

Er zijn nog steeds meerdere mogelijkheden om dit probleem aan te pakken, waaronder het veranderen van de rol die de afdeling speelt, zoals bijvoorbeeld: Als u met softwareontwikkelaars werkt, kunt u de rol voor een bepaalde of mensen gedurende de week wijzigen om ze ondersteuning te laten doen voor de andere afdelingen, waarbij 1 of meer mensen om 9 uur of eerder moeten komen en als dat niet werkt, kunt u altijd een beroep doen op een insubordinatieclausule die normaal gesproken in elk arbeidshandboek ** in de VS** aanwezig is. Persoonlijk ben ik altijd tegen het gebruik van deze clausule geweest, die een manager de mogelijkheid geeft om iemand te berispen en zelfs te ontslaan ** voor de zaak, maar in uw geval kan dit gepast zijn. Lees dus het **werknemershandboek door en bespreek het met uw leidinggevende als u een van hen heeft dat u dit gaat doen.

Het basisidee is als volgt:

1. Je stelt de regel in dat minstens 1-2 of alle mensen op uur X. 2 aan het werk moeten zijn. Als je teamleden geen geldig excuus hebben om niet te komen opdagen of te volharden in deze praktijk moet je ze als manager berispen en eventueel ontslaan.

Als manager die doet wat ik heb beschreven zou het laatste redmiddel zijn, maar op basis van wat je beschrijft zou je dat punt kunnen hebben bereikt. Er zijn veel artikelen over zou kunnen vormen werknemer insubordinatie die u online kunt vinden en dit zijn slechts een paar voorbeelden:

• BlogSpot
• Duhaime

Natuurlijk kan de ongelukkige consequentie zijn dat er in uw groep een hoge omloopsnelheid is die slecht zou reflecteren op u als manager, maar het zal de discipline afdwingen en waarschijnlijk het moreel doden in het proces.

Nu ik dat allemaal heb gezegd, heb ik wel een vraag: Heb je je team echt nodig om eerder binnen te zijn dan wanneer ze binnenkomen?

In principe moet u beslissen wat belangrijker is, de klus goed klaren of 8 uur achter uw bureau zitten op de voorgeschreven tijdstippen?