Vraag:
Hoe kan ik een cultuur van punctualiteit in een softwarebedrijf stimuleren?
Jacob G
2012-04-12 22:34:49 UTC
view on stackexchange narkive permalink

Wat zijn enkele aanvullende strategieën die je als nieuwe technische leider in een nieuw bedrijf kunt toepassen om de cultuur van het ontwikkelingsteam te veranderen, zodat mensen opdagen op het moment dat ik heb gevraagd?

TLDR : Mijn team komt niet op tijd. Ik heb geprobeerd ze te dwingen, maar het werkt niet.

Achtergrondgegevens:

  1. Klein bedrijf, 30 werknemers, 5 leden van mijn team.
  2. De vorige lead zit nog steeds in het personeel als een reguliere ontwikkelaar.
  3. De cultuur voorafgaand aan mijn komst was er een van informaliteit zonder vaste grenzen of kernuren. Deze cultuur werd niet uitgedaagd door de bedrijfsleiders. De meeste mensen van het team kwamen hierdoor tussen 10.30 en 11.00 uur opdagen.
  4. Andere afdelingen hebben, vanwege de aard van hun werk, starttijden van 8 of 9.

Deze discrepantie en onvoorspelbaarheid veroorzaakt veel angst tussen mijn afdeling en andere afdelingen. Als zodanig heb ik het team neergezet en een 'niet later dan'-tijd van 9:30 gespecificeerd. Ik legde mijn redenering uit en ik legde de voordelen van een dergelijke regeling en de nadelen van de huidige regeling uit. Het was een lang en omstreden gesprek en 3 van de 5 mensen in het team waren behoorlijk ontevreden.

Onnodig te zeggen dat mensen niet op tijd komen opdagen (en 9:35 is niet op tijd.)

Ik heb onze dagelijkse stand-up meeting om 9.30 uur ingepland als extra motivator. Wetende dat het een beetje tijd kost om de starttijden over te zetten (met woon-werkverkeer, enz ...), zou ik in eerste instantie wachten om de vergadering te beginnen tot iedereen kwam opdagen, maar nu begin ik de vergadering (en beëindig ik de vergadering vaak) met wie er ook is. Dat lijkt ook geen verschil te maken en het maakt het team minder hecht.

Gesprekken op individuele en groepsbasis leveren dezelfde resultaten op als het oorspronkelijke gesprek (dwz ze zien de waarde niet, denk Ik neem een ​​extraatje van de baan weg, enz ...)

Ik heb de volledige steun en steun van het senior managementteam en ben bevoegd om alle apparaten te gebruiken die ik geschikt acht om hier voor te zorgen.

Mijn huidige volgende stap is om iemand naar huis te sturen en ze nemen een dag vrij. Is dat te ingrijpend? Zijn er alternatieve strategieën die ik over het hoofd zie en die me kunnen helpen dit probleem op te lossen?

Bewerk op basis van vragen in Jarrod's antwoord

Hoe nieuw van een technische lead? sterk> 6 maanden, bij dit bedrijf, op het moment van deze vraag.

Waarom legt u een puur niet-technisch managementbeleid op? Het valt binnen de reikwijdte van mijn functie zoals gedefinieerd door het uitvoerend management.

Wat zijn uw managementreferenties? 10 jaar ervaring als technisch hoofd. Geen formele opleiding of certificering op het gebied van management.

Welke eerdere ervaring op het gebied van personeelsmanagement heb je? Ik ben 10 jaar een technische leider geweest. Ik ben verantwoordelijk geweest voor het aannemen / ontslaan / interviewen / beoordelen / leiden / opbouwen van een paar verschillende technische teams.

Heb je het respect van het team op een technische manier verdiend? Ja

Heb je het respect van het team op leidinggevende wijze verdiend? Ik werd door het team geïnterviewd vanwege technische en leidinggevende vaardigheden. Ik was duidelijk en duidelijk over hoe ik het leuk vind om technische teams te leiden en hoe ik het leuk vind om projecten te runnen (met het voor de hand liggende voorbehoud dat dat slechts een startpunt is en dat cultuur en personeel uiteindelijk invloed hebben op waar ik land.) Er zijn veel dingen, van een managementperspectief, waar het team best tevreden mee is.

Is de vorige technische leider afgetreden? Ja.

Is de vorige technische lead gedegradeerd? Nee. Het was zijn verzoek.

Was de vorige technische lead effectief? Voor een tijdje. Maar de groei van het bedrijf en de codebase maakten zijn stijl ondoelmatig.

Heeft de meerderheid van het bestaande team een ​​meer persoonlijke relatie met de vorige technische leider? Ja.

Heeft de vorige technische leider nog steeds de leiding? Nee.

Dan moet [de vorige cultuur van informaliteit zonder vaste grenzen] werkte het? Het werkte een tijdje, toen het bedrijf nog een startup was. Het is gegroeid en geëvolueerd tot ver na de opstartfase en is door die groei lang niet meer zo effectief als het ooit was. Vooral omdat andere afdelingen een beetje meer formaliteit en voorspelbaarheid hebben geïntroduceerd.

Was het team succesvol in het leveren van nuttige producten op de belofte? In het begin. Maar naarmate het bedrijf en het product groeiden, gingen de kwaliteit en levertijden aanzienlijk achteruit.

Het klinkt niet alsof je zelfs maar een soort compromis met je team of de externe teams hebt overwogen of onderzocht op basis van hun negatieve feedback. Heb je dat? Natuurlijk wel, ik ben geen groentje. Het feit is dat ik het feit respecteer dat de rest van het bedrijf in een onbuigzaam kader werkt vanwege de aard van hun verantwoordelijkheden. Het team was niet bereid compromissen te sluiten over hun flextijd en in veel gevallen konden de andere afdelingen geen compromissen sluiten. Ik heb de negatieve feedback ook specifiek met de andere afdelingen aangepakt en een aantal dingen geïmplementeerd om het beter te maken. Een van de grote voordelen van deze wijziging was de voorspelbaarheid en veranderingspercepties te verbeteren.

Laatste update

Van de oorspronkelijke ploeg van 5 zijn er 2 vervangen. De eerste was de vorige teamleider. We wisten niet hoe we ontwikkelingsprojecten moesten uitvoeren en hij kon geen veranderingen accepteren ten opzichte van wat hij eerder had vastgelegd, dus kwamen we onderling overeen om uit elkaar te gaan. De tweede verloor interesse in het werk, maakte een paar grote fouten en we spraken ook onderling af om uit elkaar te gaan.

Het team als geheel komt nu vroeg genoeg opdagen om voldoende dekking voor de rest van het bedrijf te garanderen. Wat uiteindelijk werkte, was mandaat en groepsdruk. Bovendien hebben andere doorgevoerde veranderingen ertoe geleid dat bijna alle interdepartementale angst moet worden opgelost. Iedereen werkt nog steeds aan geweldige projecten, meestal naar keuze, in zijn eigen tempo bij een opwindend bedrijf en ze zijn allemaal behoorlijk tevreden, ondanks dat de arbeidsmarkt in het gebied belachelijk is.

Ik ben gepromoveerd tot een leidinggevende functie en het nieuwe 'probleemteam' is onder mij verplaatst (naast het behouden van de controle over het ontwikkelteam en nog steeds in ontwikkeling). Ik werk nu om hen te helpen beter te presteren en betere teamgenoten te zijn voor hun collega's. Ik heb niet het punctualiteitsprobleem met dit nieuwe team ... Hun problemen zijn nauwkeurigheid en communicatie.

Misschien een ander soort motivator, zoals een donut * alleen * voor degenen die op tijd of vroeg komen opdagen. Het kan duur worden om dagelijks te doen, dus doe het misschien maar één keer per week, maar vertel ze niet * welke * dag ...;) Ik heb dit nog nooit geprobeerd, dus daarom plaats ik liever een reactie dan een antwoord.
Een belangrijk ding ontbreekt in deze vraag: *** WAAROM *** breng je deze wijziging aan? Wordt het werk niet op tijd gedaan? Is er een werkelijk probleem dat moet worden opgelost (en is dit de juiste manier om het op te lossen? Zou een onderwerp kunnen zijn voor een andere vraag ...) Zoals Andrew in zijn antwoord opmerkte, dicteerde hij een willekeurige 'niet-na'-starttijd voor kennis werknemers die al een flex-tijdcultuur hebben, zullen impopulair zijn, en het is moeilijk om motivatoren / methodologie voor te stellen zonder meer context ...
@voretaq7: Ik denk dat "Deze discrepantie en onvoorspelbaarheid veel angst veroorzaakt tussen mijn afdeling en andere afdelingen" betekent dat andere afdelingen contact moeten hebben met de afdeling van OP. en als een groep om 9 uur 's ochtends binnenkomt en afhankelijk is van anderen die pas om 11 uur komen opdagen, veroorzaakt dat problemen.
@FrustratedWithFormsDesigner Het is heel goed mogelijk, maar als de ontwikkelaar dan om 20.00 uur het werk op het bureau van de ontwerper legt om te worden getest tussen 9 en 11 morgenochtend, zie ik geen probleem. Ik geef de voorkeur aan coördinatie boven willekeurige regels. Ik probeer ook geen aannames te doen, maar de "angst" zou net zo goed kunnen zijn "De verkoop huilt omdat ze ook laat willen komen en als ze dat niet kunnen, kan niemand het!"
Ben je bereid om de keerzijde van je 'schoolbel'-regel te handhaven? Iedereen stopt met wat hij doet en vertrekt op een zeker moment, ongeacht hoeveel werk er nog ongedaan gemaakt kan worden?
@JimInTexas het is meer een "Core Hours" -regel. Je moet op kantoor zijn tussen 9.30 - 16.00 uur ... je kunt naar keuze eerder of later swingen.
@voretaq7, in de zakenwereld, een manager moet optreden als andere afdelingen klagen. De medewerkers op die afdelingen zien niet in waarom ze daar op vaste uren moeten zijn en de ontwikkelaars niet. Ik weet zeker dat hij de opdracht heeft gekregen om het probleem op te lossen.
@HLGEM Dat hangt echter af van de aard van de klacht: soms is de juiste actie als manager om de andere afdelingen te vertellen "Dit is hoe mijn team werkt, en het werkt voor het bedrijf. Tough Rocks." - In het geval van Jacob lijken zijn ontwikkelaars prima donna's te zijn verwend met attitudeproblemen [zie deze discussie in de chat] (http://chat.stackexchange.com/transcript/message/4208458#4208458) en enkele van de opmerkingen hieronder. ..
@JacobG: Dus mensen op andere afdelingen * moeten * regelmatig face-to-face ontmoetingen hebben met de ontwikkelaars in uw team, zo erg zelfs dat het feit dat de ontwikkelaars om 11 uur 's ochtends aan het werk komen daar ernstig mee te maken hebben? Waarom is zo veel face-to-face interactie tussen afdelingen nodig? *Is het noodzakelijk? Is het bijwonen van deze bijeenkomsten echt een goed gebruik van de tijd van uw ontwikkelaars, of kan de coördinatie plaatsvinden op een hoger niveau (bijvoorbeeld tussen * u * en andere afdelingen)? Ik twijfel niet aan uw beschrijving van de situatie, maar het lijkt vreemd.
@KeithThompson: De interactie tussen afdelingen is frequent en vaak vanwege de behoefte aan samenwerking. We zijn een klein bedrijf en een klein ontwikkelteam en we moeten meerdere hoeden dragen in de SDLC, onze productieomgevingen ondersteunen en ook de andere afdelingen helpen om hun resultaten te halen. Velen van ons in het bedrijf hebben tijdgevoelige dingen om te leveren en er is meestal niet genoeg doorlooptijd om dagenlang te coördineren. Ik voer zo goed mogelijk interferentie uit, maar ik kan het niet allemaal op mij nemen en heb de rest van het team nodig om beschikbaar te zijn.
* Onnodig te zeggen dat mensen niet op tijd komen opdagen (en 9:35 is niet op tijd.) * Dit klinkt dictatoriaal, micro-management en tiranniek. Het klinkt alsof je minions nodig hebt; zoek naar die persoonlijkheidstypen wanneer de huidige bemanning stopt.
Op het moment dat je zegt: (en 9:35 is niet op tijd.) Geef me meteen de indruk dat je een harde baas bent en dat ik minder snel zou luisteren naar wat je zegt. Programmeurs hebben vrijwel overal altijd flexibele werkuren, en meestal vervallen mensen in een routine, het is onwaarschijnlijk dat ze onvoorspelbaar zijn wanneer ze komen. Mensen doen dit vooral vanwege wat het beste voor hen werkt, en dat maakt hen op hun beurt productiever.
@JarrodRoberson en tsoverflow - Jullie zijn natuurlijk welkom bij jullie mening, maar ik denk dat jullie een beetje buiten de perken vallen met jullie overdrijving. Ik ben niet 'tiranniek' of 'sukkel', maar ik verwacht dat mensen op tijd naar vergaderingen komen en bereid zijn om deel te nemen.
Het klinkt nog steeds alsof het probleem bij * jij * zit en niet bij de rest van het team. Je hebt hier een dictatoriale toon, ik kan me alleen maar voorstellen hoe je overkomt op de mensen waarvan je verondersteld wordt dat ze * leiden *. Het gevoel dat ik krijg is dat dit je eerste of tweede keer is in deze functie en je denkt dat ze gewoon moeten doen wat je zegt, want jij hebt de leiding. Er is een cultuur voor goed of slecht; je moet je eraan aanpassen en het bijvoorbeeld van binnenuit veranderen. Je kwam hier om hulp vragen, maar wil niet naar de mening van iemand luisteren. Dit moet echt * Hoe kan ik mijn medewerkers naar mijn hand zetten? *
ontbijt met bagels, donuts, koffie, etc. pak alles om 9.30 uur in
Ik weet niet wat jullie allemaal denken, maar vijf minuten ruzie maken is niet echt een effectieve of productieve manier om je tijd met het team door te brengen.
@Spoike - Het kan maar 5 minuten duren, maar ze zijn nog steeds te laat. Als ze niet eens 9/10 keer op TIJD kunnen verschijnen, hoe kan de auteur ze dan vertrouwen?
@Ramhound: Als er mensen te laat komen voor vergaderingen, kan het me eerlijk gezegd ** niet schelen **. Uiteindelijk praat ik met mensen die op tijd zijn (over de dag, het leven, wat dan ook ... je weet wel ... ze beter leren kennen) en ga dan verder met de echte zaken als iedereen is gearriveerd. Vertrouwen is iets dat u verdient door uw interacties met andere mensen. Straffen (hoewel het er goed uitziet in Hollywood-blockbuster-films) is niet hoe je je vertrouwen met hen opbouwt.
@Spoike Ik zou zeggen dat het vaak te laat zijn * voor vergaderingen * een gebrek aan respect verraadt voor de tijd van anderen die moet worden aangepakt. Het bedrijf zou geen vijf mensen moeten betalen om rond de duimen te zitten en koetjes en kalfjes te maken terwijl ze wachten tot iedereen arriveert. * Wat * koetjes en kalfjes enz. minuten na de geplande starttijd geeft aan dat de tijd niet wordt gewaardeerd en gerespecteerd.
@tsOverflow: Als de stand-up meeting stipt om 9.30 uur is, dan hoeft u alleen maar uw aankomst in te plannen om 9.25 uur en kunt u het zich veroorloven om 5 minuten te laat te zijn in geval van een probleem.
@MatthieuM .: OP besloot om iedereen eerst om 9.30 uur te laten komen, waarna hij met opzet de vergadering om 9.30 uur had gepland om iedereen te dwingen vroeg te komen. Er is het verschil tussen het opzettelijk vroeg plannen van de vergadering en op dat moment daadwerkelijk een vergadering hebben zonder de onderliggende bedoeling om mensen op een bepaald moment te laten komen.
@JohnMcG: Binnenkomen als nieuwe manager om dingen te verstoren zonder iemand een mandaat te geven, is een groot probleem, een teken dat je niet luistert en een teken van gebrek aan respect. Dergelijke veranderingen kosten tijd, zelfs jaren. Probeer anderen te respecteren voordat u * respect eist. Uit de bewerking: zijn team is niet bereid om de flextijd in gevaar te brengen, wat ik denk omdat ze er een gevestigd belang in hebben en zich waarschijnlijk hebben aangemeld voor dat soort werk. Wat de reden ook is, het is jouw taak als manager om ermee om te gaan en verwachtingen te managen ... of het team te ontslaan ... maar dat is een slechte oplossing.
@JacobG: Uit de chatdiscussie die door voretaq7 is gelinkt, lijkt het erop dat uw situatie kan worden samengevat als "Ik moet leiding geven aan een afdeling verwende prima donna's die het werk niet goed doen, slechte relaties hebben met andere afdelingen en laat komen" - in een dergelijke situatie is "kom laat" de * minste van uw problemen *. U kunt dit echter in uw voordeel gebruiken - als u met het senior management kunt afspreken dat punctualiteit kan worden versoepeld in ruil voor verbeteringen op andere gebieden, * en * dit als een tegenprestatie voor uw team kunt presenteren, kunt u * * krijg overal verbeteringen.
@Spoike - Het klinkt alsof het erg moeilijk zou zijn om mee te werken. Je lijkt 'te laat komen' in de ogen van de leidinggevende niet echt een probleem te vinden. Het maakt niet uit wat het beleid was met de oude supervisor om eerlijk te zijn. Als ze de genoemde veranderingen niet leuk vinden, zijn ze welkom om te vertrekken en kan de nieuwe supervisor ze vervangen door mensen die op tijd ZULLEN zijn.
@Ramhound: Nu maak je aannames die er niet zijn en waar niet om gevraagd wordt. Ik ben meestal op tijd voor vergaderingen, en ben er zelfs liever een paar minuten eerder en meestal gemakkelijk om mee te werken, dat vertellen mijn collega's me tenminste op mijn LinkedIn-profiel. :-) Ik wil alleen maar zeggen dat, zelfs als iemand te laat komt voor een vergadering, ik niet al mijn cognitieve energie wil besteden aan het kibbelen erover, er veel dringender zaken zijn waar ik aandacht aan moet besteden.
Ik vraag me nog steeds af waarom het verliezen van een uur of twee venster in de ochtend zo rampzalig is voor de coördinatie met andere afdelingen. Als je ontwikkelaars meer dan een uur per dag aan dit soort dingen besteden, is dat voor mij een indicator van een serieus management (niet per se OP's) of een cultuurprobleem. Als de ontwikkelaars prima donas zijn, is het mogelijk dat het allemaal klootzakken zijn. Het is ook mogelijk dat iemand ze uren aan vergaderingen per dag heeft voor constante voortgangsupdates van al het werk waar ze pas na 5 uur aan kunnen komen als alle anderen vertrekken. Ik ben daar geweest / heb die kolossale verspilling van deversalarissen gezien.
* Ik heb de volledige steun en steun van het senior managementteam en ben bevoegd om alle apparaten te gebruiken die ik geschikt acht om dit te laten regelen. * - En u denkt dat dit u zal helpen een cultuur van punctualiteit op te leggen? Veel succes, kerel.
@JimG. Dat was slechts potentieel relevante informatie die iemand mogelijk heeft gebruikt om een ​​productieve oplossing te formuleren om een ​​cultuur van punctualiteit 'aan te moedigen' in plaats van 'op te leggen'. Voel je vrij om deel te nemen aan de community en je eigen productieve oplossing aan te bieden.
De vraag is een oxymoron ...
De intensiteit van de werkdag van een programmeur is onvergelijkbaar met die van de werknemers op een andere afdeling, daarom kunnen ze niet gelijk worden behandeld. Als je bijvoorbeeld een paar cv's doorneemt of een telefoongesprek voert, moet je er natuurlijk van 9.00 uur tot 17.00 uur zijn. Ik bedoel, er zijn banen waar je geen uitdagende taken hebt, maar je aanwezigheid is de hele dag nodig, en er zijn andere waar je een deadline hebt en een hoeveelheid werk te doen daarvoor, ongeacht wanneer je binnenkomt. ochtend.
* "Ik heb onze dagelijkse stand-up meeting om 9.30 uur ingepland als extra motivator ..." * - noem je dit een * "motivatie" *? OMG..
Is er een reden waarom je moet onderstrepen dat jij degene bent die de dingen in je team beslist?
OP klinkt als een dictator. "Waarom legt u een puur niet-technisch managementbeleid op? Het valt binnen de reikwijdte van mijn functie zoals gedefinieerd door het uitvoerend management." Power-trip veel?
"We hebben goedkoop veel mensen ingehuurd in ruil voor superflexibele werktijden. Nu ze het aas hebben gepakt, willen we graag wisselen." Als je "punctualiteit" wilt, zet dan de (kern) werktijden in het contract.
Ik ben nieuw op de site en ik zou dit bericht hier graag achterlaten: als ontwikkelaar zou ik graag willen weten voor welk bedrijf het OP werkte op het moment dat hij deze vraag stelde, dus ik stuur ze nooit mijn cv.
Door de vraag, opmerkingen en chat door te lezen is het me niet precies duidelijk waar de motivatie voor deze 'perk-verwijdering' ligt tussen "we moeten coördineren tussen afdelingen" en "andere afdelingen zijn jaloers op ons voordeel". Waarschijnlijk voor de hand liggend, maar als uw ontwikkelaars vinden dat de eerste reden slechts een façade is voor de tweede, is de reactie die u krijgt volkomen voorspelbaar: als u toch bezig bent, waarom zou u dan hun salaris niet laten vallen om af te stemmen op andere afdelingen? Als het echt het 'coördinatie'-probleem is, is het dan elke dag een probleem? Zo niet, dan moet er een andere mogelijke oplossing zijn
Ik vroeg me af waarom er "angst" heerste op de andere afdelingen. Kunt u hier wat meer over zeggen?
@ThorbjørnRavnAndersen Ze speelden waarschijnlijk Bright Eyes op hun afdeling.
Als * ze [...] denken dat ik een extraatje van de baan * wegneem, is dat omdat jij dat bent. Het kan ook gerechtvaardigd, noodzakelijk, onredelijk, dictatoriaal zijn, maar het is wat het is, hoe dan ook.
De reden voor de vroege start is dus dat andere afdelingen jaloers zijn? Misschien moet je kijken waarom 9-5 überhaupt een standaard werd, en de vele redenen waarom het niet langer van toepassing is op de meeste softwareontwikkelaars in het tijdperk van telewerken ...
Zeventien antwoorden:
#1
+155
Nicole
2012-04-13 00:42:13 UTC
view on stackexchange narkive permalink

De beste motiverende factor is vertrouwen. Teameenheid is van het grootste belang bij het bereiken van uw doelen. Regelculturen zijn gekweekt uit wantrouwen, en stokken en prikkels om regels af te dwingen zullen het vertrouwen van je team alleen maar verder aantasten.

In plaats van je zorgen te maken over exacte tijden en informele culturen, probeer erachter te komen 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 heel belangrijk dat alle leden meedoen aan de dagelijkse stand-up?

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

Ik zou naar de kern van het probleem willen kijken, namelijk dat uw team het idee niet heeft overgenomen . Kijk waar de verbinding is verbroken, 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 vinden), zal je team geloven dat je ze ziet als kinderen die niet te vertrouwen zijn.

+1 - Ik denk dat dit de meest beknopte manier is om het probleem * en * de oplossingen te formuleren. Welke regels u ook stelt, ze moeten het gemakkelijker maken om dingen voor elkaar te krijgen, en zo moet dit worden aangepakt met de werknemers.
Ik vind dit antwoord leuk en ik ben het er ook mee eens. Ik geloof dat ik heb geprobeerd hen de onderliggende problemen te laten begrijpen en hoe ze zouden worden geholpen met een Core Hours-beleid. De ene ontwikkelaar reageerde met superioriteit (d.w.z. schroef de andere afdelingen omdat ik speciaal ben) en de anderen concentreerden zich uitsluitend op het verlies van een extraatje. Ik geloof niet dat ze zichzelf zien als een deel van het grotere team, maar als de superster van het grotere team. Ik wil ze niet 'naar huis sturen', daarom heb ik om een ​​alternatieve tactiek gevraagd, want ik weet niet wat ik anders moet doen.
@JacobG Weet je, de tweede ontwikkelaar _does_ heeft een punt - in staat zijn om tussen 10.30 en 11.00 uur ** binnen te komen is ** een extraatje, zelfs als het er een is die je niet goedkeurt (zoals bijv. , rook breekt). U mag het niet verwijderen zonder een vorm van compensatie aan te bieden.
+1 absoluut mee eens. Ik zou hieraan willen toevoegen dat het probleem misschien kan worden verzacht door te overwegen "dekking" te hebben tijdens de kernuren in plaats van _everyone_ ter plaatse te hebben tijdens de kernuren. Kunnen sommige ontwikkelaars zich vrijwillig aanmelden om eerder te verschijnen, terwijl anderen later blijven?
Ik ben het eens met de motivatiefactor, maar ik ben het er niet mee eens dat een regelscultuur een slechte zaak is.
als mensen slechte gewoonten hebben, is het niet geweldig om hen te belonen / compenseren voor het opgeven ervan. Ik beloon en compenseer liever resultaten.
Enkele goede punten, maar ik ben het niet eens met uw uitgangspunt. Vertrouwen, niet wantrouwen, maakt heersende culturen mogelijk. Het probleem van het OP is dat zijn rapporten hem niet genoeg vertrouwen om te doen wat hij van hen vraagt. Misschien hebben ze gelijk als ze dat niet doen. Dus liever ** De beste motiverende factor is eigenbelang. **
Dit is geen probleem met * vertrouwen * het is een probleem met * respect * en iemands directe manager ondersteunt hun mening door deze te respecteren en ervoor te zorgen dat hun stem wordt gehoord. Lees de opmerkingen bij mijn antwoord, er is geen overtuiging dat het ontwikkelteam een ​​stem in de zaak zou moeten hebben, het is een dictatoriale benadering en geen insulaire benadering van management.
Als teamleider of lijnmanager die met slimme, creatieve mensen werkt, is luisteren de belangrijkste vaardigheid. Zolang het team productief en effectief is, loop ze niet in de weg. In dit geval komt de druk van buiten het team - ik zie mijn rol als het * beschermen * van het team tegen dit soort "organisatorische regen" en heb daarom de neiging om voor hen te vechten met het management, en niet andersom. Als het team efficiënt en productief is, knoei er dan niet mee. Als de tijdregistratie de teamcohesie verstoort, zorg er dan voor dat dit in je retrospectieven naar voren komt als een probleem dat het team moet oplossen.
+1 voor het focussen op het kernprobleem en het vermijden van het creëren van een regelcultuur. Het punt over flexibiliteit als voordeel is ook een goede.
#2
+124
jmort253
2012-04-13 11:26:15 UTC
view on stackexchange narkive permalink

Het creëren van een cultuur van punctualiteit kan enige tijd vergen en is misschien iets waar je een beetje een compromis over moet sluiten. Omdat je te maken hebt met intelligente kenniswerkers, zul je succesvoller zijn als je ze ertoe kunt krijgen om mee te doen aan het plan. Concentreer u niet op de tijd, maar op het probleem dat wordt veroorzaakt door de planningsproblemen.

Presenteer het probleem als een uitdaging voor het team en kijk wat ze bedenken. Het antwoord kan bestaan ​​uit vaste schema's of het kan iets anders zijn dat het probleem oplost. Het kan maandag, woensdag, vrijdag zijn de 9 am-scherpe dagen, terwijl dinsdag en donderdag de flexdagen zijn. Hoewel het plan misschien niet perfect is, en het zal ook niet precies zijn wat je voor ogen had, zal het vinden van een middenweg ergens waar zowel het ontwikkelingsteam gelukkig van wordt als het daadwerkelijke probleem oplossen, voorkomen dat je personeel verbitterd wordt en je als de vijand ziet. .

Houd in gedachten dat je niet te maken hebt met een fabricageproces waarbij iedereen om precies 9.30 uur moet verschijnen, wanneer het fluitsignaal klinkt, zodat ze kunnen beginnen met de geestdodende taak om hetzelfde te monteren kleine plastic widgets herhaaldelijk, totdat het fluitsignaal weer klinkt en het geestdodende personeel naar de plaatselijke bar gaat voor happy hour.

Mijn team komt niet op tijd. Ik heb geprobeerd ze te dwingen, maar het werkt niet.

Slimme mensen dwingen werkt nooit. Je moet niet vergeten dat je te maken hebt met hoogopgeleide, slimme, creatieve mensen die goed zijn in het oplossen van complexe, abstracte en unieke problemen. Deze mensen, althans de echt goede, zullen nooit blindelings bevelen opvolgen. Dit gaat terug op het feit dat ze het probleem in eerste instantie in hun handen hebben gelegd. Als ze niets doen, wil je met je eigen oplossing instappen.

U zei dat u een nieuwe teamleider bent. Een dergelijke nieuwe functie betreden is uitdagend en stressvol, omdat je niet zeker weet hoe je respect voor het team kunt krijgen en ook een goede leider kunt zijn. Dit komt met ervaring, en het is normaal dat onervaren nieuwe teamleiders proberen mensen te 'dwingen' of te dwingen de dingen op hun manier te doen. Dit is geen leiderschap.

Ontwikkelaars en andere kenniswerkers hebben geen manager nodig; in plaats daarvan hebben ze een leider nodig. Grote leiders inspireren anderen om geweldige dingen te doen, en dit is uw kans om uw team tot grootsheid te leiden in plaats van het tot wanhoop te dicteren.

Onderzoek toont aan dat mensen eerder geneigd zijn zich in te zetten wanneer ze hebben deelgenomen aan het bepalen van wat de oplossing zal zijn in plaats van die oplossing verteld aan hen, en dit is vooral waar met kenniswerkers.

Voor inspiratie, zie Seth Godins Interview over het verschil tussen leiderschap en management. Ik raad iedereen met leidinggevende functies ten zeerste aan dit korte interview te bekijken.

"Laat ze maar een plan bedenken" was ook mijn eerste reactie. Afgaande op opmerkingen en chat lijkt dat in dit specifieke geval echter niet te werken ...
@Benjol - De toon van de vraag doet me denken dat dit meer is dan op het eerste gezicht lijkt. Het voelt te Theory X-stijlbeheer, wat niet effectief is bij het beheren van ontwikkelaars. We horen maar één kant van het verhaal, en de waarheid zit altijd ergens in het midden.
Zie mijn antwoord :)
Het belangrijkste punt is dit: Slimme mensen dwingen werkt nooit. Je kunt je zeer intelligente teamleden niet als kinderen behandelen en verwachten dat ze niet klagen, terugvechten en je er niet om kwalijk nemen (voorbeeld; ik heb hier niet direct last van, maar ik vind het nog steeds moeilijk om niet persoonlijk beledigd zijn over hoe het OP zijn team probeert te leiden). Technische medewerkers zijn over het algemeen ongeveer net zo slim als hun managers (zo niet meer), dus de enige effectieve manier om ze te benaderen is als leeftijdsgenoten, niet als dwaze ondergeschikten die zouden moeten doen wat je zegt omdat je het zei.
Ik ben laag opgeleid en heb er nog steeds bezwaar tegen dat mensen mijn flextijd wegnemen.
#3
+64
Andrew
2012-04-12 23:19:20 UTC
view on stackexchange narkive permalink

Het is mijn ervaring dat kenniswerkers er niet van houden om gedicteerd te worden over beleid waarvoor ze zien geen doel hebben. U geeft wel een doel aan, maar de medewerkers die u aanstuurt, schijnen het niet goed te vinden. Verder zijn er waarschijnlijk alternatieven die u niet hebt overwogen, 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 dat gewoon zouden zijn. neergeschoten.

Als de enige reden waarom u het beleid implementeert, de spanning is met mensen op andere afdelingen, is het uw taak om die spanning te beheersen zodat uw mensen zo effectief mogelijk kunnen werken. Ik denk echter niet dat dat de enige reden is. Wat als er bijvoorbeeld een ontwikkelaar nodig is om een ​​urgent productieprobleem op te lossen dat zich voordoet om 8:00 of 9:00 uur of op een ander tijdstip? Het is echter onwaarschijnlijk dat u al uw ontwikkelaars nodig heeft om dit probleem op te lossen. Wat als u een roterend (tenzij iemand zich vrijwillig) "vroeg" schema had, zodat elke ontwikkelaar om de beurt om 8.00 uur (of 9.00 uur, enz.) Aanwezig moet zijn? Die oplossing lijkt eerder te voldoen aan zowel de zakelijke behoeften als de wensen van uw werknemers. Iedereen "deelt de pijn" (of legt het op aan iemand die het niet erg vindt). Mensen kunnen meestal binnenkomen en werken wanneer ze denken dat ze het meest productief zouden zijn. Dit is slechts één mogelijkheid, maar het kan leiden tot discussie met uw werknemers over hoe u de echte problemen kunt oplossen en ieders belangen kunt behartigen.

Als je ervoor kiest om de meer disciplinaire weg te bewandelen, en de "starttijd" -kwestie echt belangrijk is voor je ontwikkelaars, zul je je goede aan ander werk verliezen. Uw werknemers zullen zich waarschijnlijk onzeker voelen in hun baan (wat als er op een dag echt een noodgeval gebeurt waardoor iemand te laat komt?). Verder kan dit worden gezien als een verschuiving in het management in de verkeerde richting (vanuit het perspectief van uw medewerkers), aangezien ze eerder ervaring hadden met het werken onder iemand anders.

Het is natuurlijk aan jou, maar Ik verzoek u dringend een stap terug te doen en beter uw best te doen om de situatie vanuit het perspectief van uw medewerkers te bekijken. Je hebt natuurlijk werk te doen, maar ik denk dat er oplossingen zijn die beter voldoen aan ieders belangen dan degene die je voorstelt.

Ik ga niemand straffen als ze een legitieme reden hebben om te laat te komen. Drie keer per week verslapen omdat ze de hele nacht WoW spelen, is niet legitiem. We hebben een vroege persoon die het liefst om 7.30 uur komt opdagen. Het grote probleem is dat als Dev X aan een project werkt met Designer Y en Designer Y om 8 uur, hij tot 13.00 uur of later wacht om iets te krijgen dat hij misschien nodig heeft. Wanneer er een beroep op wordt gedaan, zien de ontwikkelaars er geen probleem mee. We zijn een klein bedrijf en zouden allemaal in hetzelfde team moeten zitten. Serieus, 9:30 is niet erg vroeg. Ben ik echt onredelijk?
@JacobG Ik kan niet zeggen of je onredelijk bent zonder meer informatie, maar de sleutel tot flexibele tijd is dat het werk *** moet worden gedaan. Als u zegt dat het werk ** niet ** klaar is, kan het schrappen van flextijd van de onproductieve werknemers (of het betalen van betaling / vakantietijd) de juiste keuze zijn. In jouw voorbeeld. Dev X en Designer Y zouden moeten coördineren, dus geen van beiden zit met hun duimen te draaien op elkaar te wachten. Als dat niet gebeurt, is dat zowel een procesprobleem als een planningsprobleem ...
"je zult je goede verliezen aan ander werk" - dat is de kern van de hele kwestie, @Jacob. Als het werk niet wordt gedaan, heb je diepere problemen; uw ontwikkelaars en ontwerpers moeten beter coördineren. Als werk * ​​wordt * gedaan, verspil dan geen tijd aan ontwikkelaars met onzin, zoals het instellen van een specifieke starttijd.
+1 voor verlies van andere werkgevers. Als ik van een omgeving zou gaan waar ik vertrouwd was om mijn eigen schema te houden en mijn werk gedaan te krijgen naar een omgeving met klokkenluiders waar ik te laat kwam, zou ik mijn cv afstoffen.
@ErikDietrich: Dus als je je werk niet op een bevredigende manier gedaan krijgt en je baas zei: "Weet je, je werk wordt niet op tijd gedaan en zo-en-zo klaagt dat je niet genoeg beschikbaar bent tijdens hun vaste en voorgeschreven schema, dus laten we uiterlijk om 9.30 uur volgens een consistent schema beginnen. " zou je nog steeds je cv afstoffen?
@JacobG Als ik uit een flex-urenomgeving zou komen en nu onderdeel van "bevredigend" is "op tijd zijn", dan zou ik dat absoluut doen (en, denk ik, je team ook). Flex-uren zijn niet een kwestie van gamers om de hele nacht videogames te spelen - het gaat om een ​​cultuur van vertrouwen. Als het mijn team is, vertrouw ik erop dat ze hun eigen persoonlijkheden en gewenste werktijden goed genoeg kennen om dingen voor elkaar te krijgen. Het schrappen van de flexuren betekent het intrekken van dat vertrouwen en de boodschap sturen dat ze (micro) beheerd moeten worden omdat ze lui en incompetent zijn. Zelfs als het waar is, zullen ze het niet leuk vinden.
Ben het eens met @AdamRackis over de vraag of "Het grote probleem is dat als Dev X aan een project werkt met Designer Y en Designer Y om 8 uur aan het werk is, hij wacht [...]" Ik zou stemmen dat Designer Y vooruit moet plannen en zeggen op het einde van de dag "Hé, ik ga hier morgenochtend aan werken, kun je ervoor zorgen dat je morgen vroeg komt om me te helpen, of het af te krijgen voordat je vertrekt" Om ze samen te laten werken kost ook minder tijd .
"Drie keer per week overslapen omdat ze de hele nacht WoW spelen, is niet legitiem." Wat betekent "verslapen"? Zitten we hier nog op de lagere school? Acht uur is acht uur, of het nu om 6 uur 's ochtends of 10 uur' s ochtends begint.Als je mensen nodig hebt om aanwezig te zijn voor vergaderingen en dergelijke, laat ze dan bepaalde kernuren kiezen waarin ze beschikbaar zijn, bijvoorbeeld van 10.00 uur tot 15.00 uur. of wat dan ook. Maar of het werk wordt gedaan, staat er orthogonaal op of ze op een bepaalde tijd binnenkomen of niet. ** Heb je geprobeerd met de ontwikkelaars over het probleem te praten en * hen * te vragen om met een oplossing te komen? **
@Kyralessa - Als je baas zegt om 9.30 uur op het werk te zijn, dan kun je beter om 9.30 uur op kantoor zijn, anders BENT U LATE. Ik kan niet geloven hoeveel mensen een probleem hebben met de vraag van deze auteur, laat staan ​​hem vertellen dat hij geen redelijke leider is, ik heb geleerd om elke dag op tijd te verschijnen.
@Ramhound Het probleem is dat de vorige cultuur er een was waarin 9:35 NIET te laat was, en het OP wil verschuiven naar een cultuur die het is, vermoedelijk voor mensen met talenten die niet gemakkelijk te vervangen zijn en die een zekere mate van vrijheid hebben over waar ze kunnen werken. Hij kan schreeuwen "JIJ BENT LAAT", veronderstel ik, maar dat kan ertoe leiden dat sommige mensen vertrekken en het moreel verlagen, wat lijkt alsof hij probeert te vermijden.
@Renan Het is zeker niet voor alle situaties ideaal. Het punt is om er zeker van te zijn dat aan de zakelijke behoeften wordt voldaan. Als er op een kritiek moment een urgent productieprobleem is, moet iemand dit kunnen oplossen. In mijn huidige functie ben ik dit vaak, maar wat er gebeurt, is dat ik een e-mail krijg op mijn telefoon, ik erken het en ik spring * thuis * op mijn machine en los het probleem op. Als er een noodgeval na een noodsituatie optreedt, zijn er problemen die veel verder gaan dan wie wanneer op kantoor is.
@Ramhound Een willekeurige starttijd instellen terwijl er nog niet een was en verwachten dat iedereen gewoon zijn hele levensschema eromheen aanpast _is_ onredelijk. Overigens is het ook onredelijk om een ​​moeilijke starttijd in te stellen wanneer het niet echt nodig is. Het is duidelijk dat de ontwikkelaars het niet als noodzakelijk beschouwen, daarom lijkt het hen onredelijk. En aangezien ze veel langer bij het bedrijf werken dan de manager en ze het allemaal eens lijken te zijn, hebben ze misschien wel gelijk.
#4
+50
Erik Reppen
2012-05-06 00:55:38 UTC
view on stackexchange narkive permalink

Het precieze antwoord op uw vraag is: iemand ontslaan en vervangen die de boodschap niet begrijpt en vervolgens iemand anders ontslaan die de boodschap niet begrijpt.

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

Constructiever zou ik je willen voorstellen het volgende te overwegen:

  • Je ontwikkelaars hadden flexibele tijd. Nu wil je het wegnemen.

Het maakt niet uit of het een officieel voordeel is in een geschreven beleid of niet. Het is een de facto beleid en een onderdeel van de gevestigde cultuur. Rond deze uren zijn de levens en schema's van mensen vastgesteld. En voor ontwikkelaars zoals ik, die liever de spits ontwijken en die in de winter een vreselijk smerig geval van SAD krijgen, maar geen dev-vriendelijke plekken kunnen bedenken die dichter bij de evenaar liggen waar ik liever woon, is het zo groot van een deal die gezondheidsvoordelen oplevert.

  • Wat is de aard van deze "angst" die u noemt? Is het a) voornamelijk jaloezie of b) legitieme communicatieproblemen tussen de afdelingen, zoals moeilijkheden bij het plannen van vergaderingen / algemene communicatie.

a) Ontwikkelaars hoeven geen interactie te hebben met klanten of andere bedrijven. Mijn ervaring is dat hoe rigide de bedrijfsstructuur is, hoe middelmatiger de ontwikkelaars. Hoewel een groot deel van de ontwikkeling uit de hand loopt, is het ook een creatief probleemoplossingsproces waarvoor mensen op hun scherpst moeten zijn. Het is ook een onvoorspelbaar, door deadlines gestuurd proces dat soms resulteert in zeer, zeer late uren. Een neveneffect hiervan is dat ontwikkelaars vaak de "creatieve" behandeling krijgen. In een bedrijf met 30 personen zou het niet moeilijk moeten zijn om erop te staan ​​dat mensen volwassenen zijn over werknemers die op hun best moeten zijn wanneer ze aanwezig zijn en die in de loop van een jaar waarschijnlijk veel meer uren zullen besteden dan een 9-5er dat is meestal hun spullen inpakken om 16:55 uur elke dag.

b) In een bedrijf van 30 personen zou u niet zoveel vergaderingen moeten hebben dat dit een probleem wordt. Zaken als sprintvergaderingen of andere tweemaandelijkse planningssessies niet meegerekend, is het een absurde, grof incompetente verspilling van geld om je ontwikkelaars elke dag meer dan 30 minuten vast te binden aan vergaderingen. Evenzo met algemene communicatie. 30 mensen betekent dat je naar de andere man loopt en met hem praat. In flextijdscenario's is het redelijk om een ​​tijdspanne in te stellen waarin iedereen tegelijkertijd op kantoor is. Ik kan geen goede reden bedenken waarom die tijdspanne meer dan 3-4 uur van de werkdag zou zijn en waarom het niet zo dicht mogelijk bij het midden van de dag zou moeten zijn.

  • Waarom een ​​morning-standup?

Hoe komt het dat het eerste idee-management dat scrum, agile, enz ... schrapt, altijd het advies is dat je niet het eerste bent? Bij het programmeren duurt het even voordat je weer volledig op de hoogte bent van alle details en problemen waarmee je te maken hebt over een bepaald probleem. Als je eerst stand-ups doet, zullen je ontwikkelaars niet volledig op hun kop worden gezet. Stand-ups zijn essentieel voor communicatie en het verbeteren van de efficiëntie, niet iets dat u als eerste doet om "uit de weg te gaan".

  • Lukt het uw ontwikkelaars niet om de klus te klaren?

Zo nee, waarom zou je met iets goeds rotzooien? Het is niet hun taak om te communiceren met de andere zorgen binnen het bedrijf. Het is van jou. In een gezonde managementstructuur ligt uw verantwoordelijkheid bij uw directe manager en de mensen die u beheert, niet bij de zure druiven van andere afdelingen die om praktische redenen op een meer typisch uur aanwezig moeten zijn.

Ik gaf een antwoord op de vraag. En dan een heel lange follow-up / addendum.
#5
+46
user718
2012-07-12 12:30:04 UTC
view on stackexchange narkive permalink

Beoordeling van de vraag: er is veel ontbrekende context en informatie

Wat zijn enkele aanvullende strategieën om de cultuur van de ontwikkeling te veranderen als nieuwe technische leider in een nieuw bedrijf? team zodat mensen verschijnen op het moment dat ik heb aangevraagd?

  1. Hoe nieuw van een technische lead?
  2. Waarom legt u puur niet-technisch managementbeleid op?
  3. Wat zijn uw managementreferenties?
  4. Welke eerdere ervaring op het gebied van personeelsmanagement heeft u?
  5. Heb je het respect van het team op een technische manier verdiend?
  6. Heb je het respect van het team op een leidinggevende manier verdiend?

TLDR: Mijn team komt niet op tijd. Ik heb geprobeerd ze te dwingen, maar het werkt niet.

Kan geen oplossing bieden tenzij we specifiek weten waarom je de cultuur moet veranderen, dus drastisch. We weten ook niet wat je hebt geprobeerd om hen te dwingen om je te kunnen vertellen waarom het niet effectief is. We kunnen het raden, maar dat is speculatie.

Waarom heb je de taak om een ​​wellicht niet-technisch mandaat voor personeelsbeheer op te lossen? Draag het over aan een leidinggevende die manager is en laat ze het afhandelen. Good Cop vs Bad Cop.

Achtergrondgegevens:

Klein bedrijf, 30 werknemers, 5 leden van mijn team. De vorige lead zit nog steeds in het personeel als een reguliere ontwikkelaar.

  1. Is de vorige technische lead afgetreden?
  2. Is de vorige technische lead gedegradeerd?
  3. Was de vorige technische lead effectief?
  4. Heeft de meerderheid van het bestaande team een ​​meer persoonlijke relatie met de vorige technische leider?
  5. Heeft de vorige technische leider effectief nog de leiding ?

De cultuur voorafgaand aan mijn aankomst was er een van informaliteit zonder vaste grenzen of kernuren. Deze cultuur werd niet uitgedaagd door de bedrijfsleiders.

  1. Dan moet het hebben gewerkt?
  2. Was het team succesvol in het leveren van nuttige producten op het moment dat het beloofd was?

De meeste mensen in het team kwamen tussen 10.30 en 11.00 uur opdagen vanwege deze. Andere afdelingen hebben, vanwege de aard van hun werk, starttijden van 8 of 9. Deze discrepantie en onvoorspelbaarheid veroorzaakt veel onrust tussen mijn afdeling en andere afdelingen.

Specifiek hoe dat zo is, er zijn hier niet genoeg details om zelfs maar een antwoord op deze vraag te formuleren. Elk soort antwoord zou complete speculatie zijn.

Als zodanig zette ik het team neer en specificeerde ik een 'niet later dan'-tijd van 9:30. Ik legde mijn redenering uit en ik legde de voordelen van een dergelijke regeling en de nadelen van de huidige regeling uit. Het was een lang en omstreden gesprek en 3 van de 5 mensen in het team waren behoorlijk ontevreden.

Geef ons je voordelen en negatieven zonder hen kunnen we niet beoordelen hoe redelijk noch hoe effectief uw communicatie is geweest. Het klinkt niet alsof je zelfs maar een soort compromis hebt overwogen of onderzocht met je team of de externe teams op basis van hun negatieve feedback. Heeft u dat gedaan?

Onnodig te zeggen dat mensen niet op tijd komen opdagen (en 9:35 is niet op tijd.)

Dit doet ' Het klinkt als een erg positieve of effectieve houding.

Ik heb onze dagelijkse standup meeting om 9.30 uur ingepland als extra motivator. Wetende dat het een beetje tijd kost om de starttijden over te zetten (met woon-werkverkeer, enz ...), zou ik aanvankelijk wachten om de vergadering te beginnen totdat iedereen kwam opdagen, maar nu start ik de vergadering (en beëindig ik vaak de vergadering) met iedereen die aanwezig is. Dat lijkt ook geen verschil te maken en het maakt het team minder hecht.

Dus eenzijdige acties die jij onderneemt, maken het team minder hecht. Denk aan it.

Gesprekken op individuele en groepsbasis leveren dezelfde resultaten op als het oorspronkelijke gesprek (dwz ze zien de waarde niet, denken dat ik een extraatje van de baan wegnemen, enz ...)

We horen en kunnen extrapoleren wat ze niet accepteren, hoor je ze?

Ik heb de volledige steun en steun van het senior managementteam en ben gemachtigd om alle apparaten te gebruiken die ik geschikt acht om hier voor te zorgen.

The Catholic De kerk had dezelfde macht tijdens de inquisitie, kijk hoe dat afliep!

Mijn huidige volgende stap is om iemand naar huis te sturen en hem een ​​dag vrij te laten nemen. Is dat te ingrijpend? Zijn er alternatieve strategieën die ik over het hoofd zie en die me kunnen helpen dit probleem op te lossen?

Escalatie klinkt ook niet als een haalbaar alternatief. Ze onbetaald naar huis sturen is beledigend en zal het bedrijf meer pijn doen dan de werknemer. Je ziet er nog dictatoriaal en tirannieker uit. Door ze als kinderen te behandelen, zullen ze zich nog meer als kinderen gedragen.


Voorspelde uitkomst van uw huidige aanpak

  1. U verliest alle respect van het hele team, ze zullen steeds ondoelmatiger worden, u zult steeds minder effectief worden gezien naarmate de productiviteit tot stilstand komt.
  2. Uw falen met beleidswijziging en vaardigheden op het gebied van personeelsmanagement zal ervoor zorgen dat u als ondoelmatig wordt beschouwd voor uw meerderen.
  3. U verliest het respect van mensen niet in uw team vanwege communicatie tussen kantoren. Het zal ook bij hen toekomstige kansen op technisch leiderschap saboteren.
  4. U zult uw reputatie bij het bedrijf zeker schaden, zowel in de keten als in de keten.
  5. De betere werknemers zullen mondeling stoppen eerste.
  6. De nog betere werknemers zullen stilletjes na hen stoppen.
  7. De marginaal gekwalificeerde werknemers kunnen stoppen of niet, afhankelijk van de pijn die u oplegt.
  8. De niet-gekwalificeerde werknemers zullen op dezelfde manier blijven hangen. tikt en verdraagt ​​alles wat u oplegt.
  9. Het bedrijf verliest uiteindelijk en krijgt extern een slechte reputatie van de werknemers die zijn vertrokken.
  10. Perceptie is alles! Vergeet dat nooit!

Enkele voorgestelde benaderingen

  1. Als hun manager zou u moeten vechten om hen te isoleren van beslissingen van het hogere management. Je zou moeten vechten om hun stem te laten horen. Je moet ze helpen om gezamenlijk een reactie te vormen en ze terug te dringen en hen te ondersteunen met hun reactie.
  2. Dit is een niet-technische beslissing en puur een bedrijfsmanagement. Waarom heb je ermee te maken en de implementatie ervan? Hier een superieure deal mee hebben, dat is hun taak.
  3. Gedraag je niet als een dictator of tiran. Misschien is niet hetzelfde als goed.
  4. Neem wat mensenvaardigheden, zachte vaardigheidstraining.
  5. Beweeg langzamer. Dit soort dingen veranderen niet van de ene op de andere dag.
  6. U moet de vorige technische leiding aan uw kant krijgen als ze een goede verstandhouding hebben met het team.
  7. Een alternatief compromis sluiten, hoe over de mensen die het niet erg vinden om vroeg langs te komen, doen de andere mensen dat niet?
  8. De verplaatsing van de stand-up tijd is willekeurig, iedereen ziet dit en wordt niet als praktisch gezien of redelijk, maar als dictatoriaal.
  9. Laat de externe teams waarmee u te maken heeft, deelnemen aan de discussie en help u de beleidswijzigingen te verkopen.
  10. Ga terug, ga met hen akkoord, wees de goede agent. Laat uw meerdere de wet voorschrijven. Dit is een beheerprobleem, niet een technisch probleem. U bent een technische leider, geen manager, toch?
  11. Laat de externe teamleden en uw teamleden gewoon tijden bedenken om te ontmoeten wanneer ze elkaar moeten ontmoeten. Vooraf bepaalde dagen en tijden van beschikbaarheid zouden een goed compromis zijn. De ontwikkelaars willen niet constant gestoord worden door het externe team en lijken er alleen te zijn om op hun verzoek naar vergaderingen te springen.

Laatste gedachte:

Mijn Managementstijl, zowel technisch als niet-technisch, is gebaseerd op Wu Wei Principal van The Tao te Ching.

Het Wu Wei-principe kan worden begrepen door een stukje kurk drijvend in water. Hoe harder je erop slaat, hoe meer het oplevert: hoe meer het oplevert, hoe harder het terugkaatst. Zonder energie te verbruiken, kan de kurk u gemakkelijk verslijten.

Hoe meer u doet, hoe sneller u waarschijnlijk zult falen. Hoe minder je doet, hoe groter de kans dat het ding dat je wilt gebeuren, wordt gedaan.

Indirect transparant leiderschap

In het beste geval merken mensen een leider nauwelijks op. Vervolgens aanbidden ze hem en juichten ze hem toe, waarna ze hem vreesden en hem uiteindelijk verachten. Dus een verloren geloof kweekt verloren geloof.

Wees niet richtinggevend, maak uw paar woorden kostbaar. Als het werk af is, wat gewonnen is, zal iedereen zeggen: we hebben het natuurlijk zelf gedaan.

Haal de mensen van de externe afdeling die de klachten hebben samen met uw mensen in een kamer en laat ze zoeken intern een acceptabele oplossing, zonder jou in de kamer . Wees bereid om te accepteren wat de uitkomst ook is. Dan is de oplossing voor hen, ze bezitten het, en je zult het broodnodige respect van hen krijgen omdat ze het hebben laten uitwerken. Dit is de niet-gerichte benadering.

+1, Dit zijn allemaal geweldige benaderingen. Persoonlijk vind ik de aanpak om het team in staat te stellen het probleem op te lossen, goed. Het is verbazingwekkend waartoe volwassenen in staat zijn als ze worden behandeld als ... nou ja ... volwassenen. Martha moet John ontmoeten, dus plannen en coördineren ze samen, zonder dat de grote gemene baas binnenkomt en dictator speelt.
Ik heb mijn vraag aangepast om enkele van uw specifieke vragen te beantwoorden.
@JacobG Zelfs na uw bewerking is een ding dat nog steeds niet duidelijk is: bent u een * technisch leider * of bent u deze mensen * niet-technisch hoofd / lijnmanager *? Dit is een belangrijk onderscheid, als technisch leider, leidt hij bij technische besluitvorming. Welke ** technologie ** te gebruiken, ** niet ** wanneer de ontwikkelaars aan het werk komen! 10 jaar technische beslissingen nemen is geen enkele vorm van kwalificatie voor het omgaan met niet-technische management, sociale / persoonlijkheidsvraagstukken zoals deze, vooral zonder formele training.
@JacobG Je begon met de * stick * -benadering, geen enkele hoeveelheid * wortelen * zal daarvan herstellen. Een kenmerk van een geweldige leider is om te weten wanneer ze niet gekwalificeerd zijn en niet effectief zullen zijn en om hulp vragen, ik denk persoonlijk dat dit een van die momenten is waarop je je gezicht kunt redden en deze strijd aan iemand anders kunt geven . Je hebt de oorlog psychologisch verloren, zelfs als je de strijd * wint *, zullen jij en het team wederzijds verloren hebben. De ** enige ** manier waarop u dit kunt oplossen, is door de leiders van de externe afdelingen samen met uw team te krijgen en ze een oplossing * zonder * u in de kamer te laten bedenken.
@JarrodRoberson - Ik weet niet zeker of ik uw onderscheid begrijp. Ik ben verantwoordelijk voor het controleren van de technische richting en ik ben ook verantwoordelijk voor hun beoordelingen. Ik keur aftakas goed en lever functies. Ik doe beide dingen al 10 jaar. Verder is er technisch gezien geen "stok" -benadering geweest. Dit beleid kwam tot stand via een discussie van meer dan 2 uur met het hele team. Het werd niet dictatoriaal voorgesteld en er zijn geen gevolgen voor. De leidinggevenden hebben sindsdien de boodschap met het team versterkt en hadden in feite dezelfde discussie van meer dan 2 uur.
@JacobG * "werd opgezet via een discussie van meer dan 2 uur" * is een oxymoron. * "werd ingevoerd" * impliceert een ** eenzijdige ** beslissing gedicteerd door iemand en toegepast. De meeste plaatsen waar ik de afgelopen 22 jaar heb gewerkt, realiseerden zich dat er een scheiding moest zijn tussen technisch leiderschap en management. Dit is een zeer gevestigde organisatiestructuur in de meeste grote (ik bedoel multi-miljard $ $ $ per jaar) bedrijven waarvoor ik heb gewerkt als technisch leiderschap. Het samenvoegen van de twee verantwoordelijkheden is een recept voor strijd. Als u 2X 2+ uur * discussies * hebt, zou u moeten vertellen dat het beleid slecht is en dat de aanpak erger is.
@JarrodRoberson Ik denk dat we over elkaar praten. 1) Dit bedrijf is veel te klein om een ​​niet-technische ontwikkelingsmanager te rechtvaardigen. 2) Deze vraag komt eigenlijk neer op "hoe een cultuurverandering te beïnvloeden", ongeacht de specifieke kenmerken van de verandering. Het is een feit dat de leidinggevenden de noodzaak van een culturele verschuiving erkennen en tot een conclusie zijn gekomen over wat de verschuiving is. Alle betrokkenen zijn het erover eens dat de verschuiving correct is. De hoop was dat het bespreken met het ontwikkelteam ertoe zou leiden dat ze dezelfde conclusies zouden trekken. Dat is niet gebeurd en dit fiasco is het resultaat.
+1 dit is een goed antwoord ... hoewel ik de voorkeur geef aan een meer gestructureerde omgeving, is dit een echt antwoord met praktische suggesties.
@JacobG: "Alle betrokkenen zijn het erover eens dat de verschuiving correct is." Toch zei u dat 3 van de 5 ontwikkelaars sterk bezwaar hadden tegen de wijziging. Betekent dit dat de ontwikkelaars niet "betrokken" zijn bij de verschuiving? Of bedoel je dat na de discussies alle ontwikkelaars het erover eens waren dat deze verandering nodig was?
@MarkBannister - Sorry voor de verwarring. Ik bedoelde dat iedereen die de leiding had die de noodzaak van een culturele verschuiving bepaalde, het erover eens was dat dit een gepaste stap was.
@JacobG je blijft maar zeggen * je hebt het met hen besproken *, je hebt ze niet verteld hoe het nu zou zijn en blijkbaar was er een ruzie van meer dan 2 uur. Dat is geen * discussie * over een beleidsverandering. ** Een echte discussie ** zou zijn geweest * we hebben de volgende klachten van andere afdelingen, een idee van die teams is een eerdere starttijd, welke andere ideeën hebben jullie die we kunnen terugzweven naar de andere teams om op te lossen de werkelijke problemen die ze hebben? *. Omdat het niet lijkt alsof iedereen 100% van het team vroeg aanwezig is, is eigenlijk het probleem.
@JarrodRoberson: Ik heb het gevoel dat ik nog steeds niet duidelijk ben. Leiderschap erkende systemisch, cultureel probleem, bedachte oplossing via uitgebreide discussie. De punctualiteitscomponent was een onderdeel van die oplossing. De discussie met het ontwikkelteam was om hen door dezelfde logica te leiden die het leiderschap tot hun conclusies bracht met de verwachting dat het team dezelfde conclusies zou trekken. Dat gebeurde niet omdat het team het er niet mee eens was dat er een probleem moest worden opgelost. Ze kozen ervoor om zich boven alle andere op dit specifieke onderwerp te concentreren.
@JacobG een discussie impliceert bi-laterale communicatie, zelfs hier geeft u zelf toe dat dit een eenzijdige mededeling was van * hoe de dingen nu zullen zijn *. * "Ik heb onze dagelijkse stand-upvergadering om 9.30 uur gepland als een extra motivator." * Is een willekeurige ** stok ** die probeert compliant gedrag af te dwingen. Iedereen die dit leest, merkt dat, uw "team" dat zeker heeft opgemerkt! Het is een regel die is ingevoerd en die zij zien als een straf voor acties die nog niet zijn ondernomen en die in opstand komen. Als je deze perceptie niet accepteert, zal niets wat je doet effectief zijn. U bent duidelijk, u luistert niet naar hen.
@JarrodRoberson Ik weet echt niet waarom we hier geen verbinding maken. Als 5 afdelingen klagen over 1 (echt / geldig) en de 1 vindt dat de 5 gewoon jaloers / inferieur zijn / eroverheen zouden moeten komen, dan lijkt het redelijk om hen ervan te overtuigen waarom deze verandering voor iedereen beter zou zijn. Zoals ik al zei, vroeg senior mgmt me om de verandering door te voeren, ik probeerde het team door de logica te leiden waar senior mgmt doorheen liep en het antwoord was dat er echt geen probleem was. Moet ik teruggaan naar mgmt en zeggen "sorry jongens, het ontwikkelteam denkt dat de klantenservice een stel baby's is en moet eroverheen?"
@JacobG mijn punt is ** uw benadering ** van het ontwikkelteam was slecht. Als je op deze aanpak aandringt, wat het klinkt alsof je doet, ** zul je blijven falen ** en zullen je leidinggevenden zien dat je faalt. Ik denk dat je moet terugdringen namens je team, * een groot deel van een managerstaak * is om hun team te isoleren van dit soort dingen. Je moet het ontwikkelteam in ieder geval de kans geven om een ​​alternatieve oplossing uit te werken om mee terug te dringen. Ik heb vele ** succesvolle ** benaderingen gegeven om tot een wederzijds compromis te komen. Ik geloof niet dat het ** hele ** team op hun wenken moet staan.
@JacobG stop met zoveel tijd te besteden aan het verdedigen van je mislukte aanpak en het rechtvaardigen van de meningen van de andere afdelingen en begin met het nemen van alle goede suggesties over ** hoe je je team kunt ondersteunen en hun stem kunt laten horen! ** Als je denkt dat ze dat niet hadden moeten doen! een stem, nou ik zou niet in dat team willen zitten. Zie mijn voorspellingen over wat er gaat gebeuren in mijn antwoord.
Als ik deze discussie lees, bedenk ik dat het echte probleem hier is dat hoger opgeleiden beslissingen nemen over details die hen niet zouden moeten aangaan. Elke laag moet zich bezighouden met inadequate resultaten van de onderliggende laag. Het hoe zou in uw rechtbank moeten zijn. Dat de ontwikkelaars op dit punt vrijwel iedereen wegblazen, suggereert me dat ze allebei het zat zijn en helemaal geen zorgen maken over het vinden van nieuwe banen als het erop aankomt. Als ze het zo willen spelen, kunnen ze het beste inschatten hoe moeilijk het is om het grootste deel van een ontwikkelteam te vervangen.
#6
+28
Tim
2012-04-27 00:55:45 UTC
view on stackexchange narkive permalink

Het eerste dat u moet doen, is ga naar "Peopleware"

Het is een vergissing om dit nu te proberen te wijzigen. Ik was manager bij een bedrijf waar we een behoorlijk flexibel werkschema hadden. Een van onze meest productieve ontwikkelaars kwam om 11 uur binnen. Hij rapporteerde een tijdje aan mij. Ik kreeg te horen dat hij zijn uren moest veranderen. Ik vocht tegen dit verzoek. Moeilijk. Ik werd overstemd.

Het resultaat:

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

Allemaal vanwege een of ander dom idee van "op tijd".

Concentreer u meer op productiviteit.

Het is uw taak als manager om belemmeringen voor de productiviteit weg te nemen - niet ervoor te zorgen dat iedereen er hetzelfde uitziet, voelt en handelt.

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

Als "nieuwe technische leider" kun je op geen enkele manier de cultuur snel veranderen. Vooral in de richting die je lijkt te willen. Heb je iets gedaan om de rollen / banen van je team te verbeteren?

Werk eerst aan het opbouwen van vertrouwen bij hen. Zoveel nieuwe managers / leads maken dit soort fouten.

Ontdek wat de andere groepen ECHT nodig hebben. Niet "ze moeten hier om half tien zijn". Ontdek echt wat het probleem is. Vind daar dan een oplossing voor.

In plaats van uw team te vertellen wat ze moeten doen - leg het probleem uit en VRAAG HEN OM SUGGESTIES / 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 ontwikkelaars bij voorkeur worden behandeld? Wat is het echte onderliggende probleem?

Ik heb geprobeerd ze af te dwingen, maar het werkt niet.

Daar is een reden voor. En je lijkt niet te luisteren. Reiken naar drastischer maatregelen en grotere hamers zullen de situatie niet echt verbeteren. Probeer de "wortel" -benadering in plaats van de "stok" -benadering.

Nogmaals, lees "Peopleware".

Je gaat niet ver komen met ideeën zoals dagelijkse vergaderingen of mensen naar huis sturen of met het idee dat het je handlangers 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? Jouw bazen? U? Zoek het ECHTE probleem uit en pak dat aan. Wanneer ze verschijnen zou NIET het probleem moeten zijn.

* Opmerking van de moderator: uitgebreide discussie in opmerkingen is gewist. Voor verdere discussies, ga naar [chat] (http://chat.stackexchange.com/rooms/3060/the-water-cooler). *
Ik had ooit een collega die om 12 uur kwam opdagen en wegging als hij daar zin in had.Sandalen dragen of helemaal geen schoenen.Als softwareontwikkelaar was hij geweldig.Hij was een van de weinige mensen die ik ooit heb ontmoet en die duidelijk beter was in dit werk dan ik.Proberen deze man te dwingen vroeg te beginnen zou (a) niet lukken, en (b) het meest belachelijk stomme zijn dat je ooit zou kunnen doen.
#7
+20
Kristof Provost
2012-04-13 15:03:29 UTC
view on stackexchange narkive permalink

Ongeacht waarom je het doet, voor je teamleden voelt het alsof je een extraatje wegneemt. Voor sommigen van hen kan het zelfs een van de belangrijkste redenen zijn waarom ze voor uw bedrijf werken in plaats van voor een ander.

In wezen vraagt ​​u hen om een ​​vermindering van hun totale compensatiepakket te nemen.

Het is mogelijk om ze te overtuigen om het te nemen, maar je hebt goede argumenten nodig en er zal vrijwel zeker een aanhoudende wrok over blijven bestaan. U kunt hier goede mensen door verliezen.

Uit uw beschrijving blijkt de belangrijkste reden jaloezie van andere afdelingen te zijn. Heb je overwogen om de andere afdelingen hetzelfde voordeel te geven?

Kortom: doe het niet tenzij je denkt dat het de moeite waard is om er een paar te verliezen.

Het is niet uitsluitend jaloezie en mijn fout als ik het als zodanig typeerde. Andere afdelingen hebben openbare kantooruren, dus flexuren zonder extra middelen toe te voegen is voor hen niet echt een mogelijkheid.
@Chad - Het antwoord is impliciet in de tweede alinea: betaal ze meer
@CurtainDog - Tenzij de loonsverhoging afhankelijk is van op tijd verschijnen, betwijfel ik of dit een blijvende oplossing zal zijn. Als het voorwaardelijk is, zijn we het er ongeveer mee eens.
Zou het mogelijk zijn om dit bericht te bewerken en uit te breiden hoe je het andere team hetzelfde voordeel kunt geven? Hoewel deze post een alternatief biedt, gaat het niet echt de diepte in en wordt niet ingegaan op het feit dat sommige werknemers ploegendienstmedewerkers zijn die een rooster moeten hebben.
#8
+18
Erik Dietrich
2012-04-23 20:37:03 UTC
view on stackexchange narkive permalink

Om je cultuur te veranderen, moet je je realiseren waarom je weerstand ervaart en vervolgens de oorzaak van het verzet aanpakken.

In mijn ervaring is 'coördineren met andere afdelingen' meestal de provincie van degenen met hogere functietitels en leidde een project / people management-traject. Werk-per-dag ontwikkelaars die alleen in code geïnteresseerd zijn, zijn hier meestal van afgeschermd. In meer gestructureerde winkels doen ze het misschien helemaal niet en in kleinere winkels doen ze het misschien informeler.

Of je het nu leuk vindt of niet, je hebt een cultuur van flexuren geërfd, wat een enorm voordeel is voor de meeste ontwikkelaars. Dat bij een van je eerste daden als leider van hen afnemen, zal hen niet alleen tiranniek overkomen (als je ze uitlegt dat 9:30 niet dat vroeg is, leg je je eigen schema op hen, willekeurig naar hun mening), maar is realistisch gezien de aftrek van een substantieel voordeel. Misschien vind je het leuk om aan een bepaald schema te werken en beschouw je dit niet als een zinvol extraatje, maar ze beschouwen het waarschijnlijk van onschatbare waarde. Beschouw dit op hetzelfde niveau als hen vertellen dat u een week van hun vakantie wegneemt of hun salaris met een paar procent verlaagt.

Om dat te veranderen, kunt u de wortel of de stok gebruiken. Je hebt het over het gebruik van een stok en misschien een grotere stok. Als je die weg bewandelt, zou ik van plan zijn een paar nieuwe ontwikkelaars in dienst te nemen, aangezien ik vermoed dat een deel van je team sollicitatiegesprekken bij andere bedrijven gaat volgen. Ik zou persoonlijk de wortelroute gaan om buy-in te krijgen voor het verwijderen van dit voordeel door 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, werken samen met andere teams, nemen verantwoordelijkheden op zich, enz. "Nieuwelingen" krijgen het flexvoordeel, maar mensen die serieus bezig zijn met vooruitgang, komen op tijd binnen.

Als je die cultuur creëert, vermoed ik dat sommige van je ontwikkelaars vanzelf op tijd zullen binnenkomen. Zowel vanwege interesse in vooruitgang als vanwege de perceptie dat "de belangrijke mensen vroeg binnenkomen".

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

Het korte antwoord is dat u dit NIET moet doen. Uw technische teamleden zijn (of in ieder geval zou moeten zijn) slim genoeg om te weten dat het geen tastbaar voordeel is om iedereen op een willekeurig moment op kantoor te hebben; de enige belangrijke statistiek is of hun werk al dan niet wordt gedaan.

Als uw team het werk niet gedaan krijgt, is dat een apart probleem. Maar als ze dingen voor elkaar krijgen, waarom valt u ze dan lastig alleen maar omdat andere afdelingen u lastigvallen?

Een deel van uw rol als leider is uw team te beschermen tegen triviale afleidingen en kritiek die wordt veroorzaakt door externe bronnen. Als uw reactie op andere mensen die klagen over uw teamleden is om de klachten door te geven aan uw teamleden en / of wijzigingen te dicteren uitsluitend op basis van die klachten, dan faalt u in uw werk. Ik stel voor dat, ervan uitgaande dat uw team daadwerkelijk zijn werk (en) doet (wat het klinkt alsof ze zijn, aangezien u geen klachten over hun productiviteit indient), een betere manier om op dergelijke kritiek te reageren, is door de klager "ja, nou mijn jongens werken hard en leveren consequent solide resultaten, en dat is het enige dat telt; dus waarom stop je je niet druk te maken over hoe mijn team hun taken afhandelt en ga je terug naar die van jou?".

En natuurlijk, als je doorgaat met een verplicht 'je moet op kantoor zijn op tijd X'-beleid, is het alleen eerlijk om dit aan te vullen met een' je moet het kantoor verlaten op tijd Y'-beleid, en een beleid "u mag niet buiten de normale kantooruren werken". Dat is alleen maar eerlijk als een manier om de balans tussen werk en privé van uw werknemer te beschermen, aangezien ik wed dat veel van de teamleden die u heeft die pas om 11.00 uur komen opdagen, waarschijnlijk ofwel laat terugblijven of extra tijd thuis besteden.

Behalve dat de auteur beweert dat het werk niet wordt gedaan.
@Ramhound - Nee, dat doet hij niet, althans niet in de oorspronkelijke post. In de waslijst met bewerkingen vermeldt hij dat de prestaties de laatste tijd aan het afnemen zijn. Maar aangezien het team in het verleden altijd flexibele werktijden heeft gehad, is er nog steeds niets dat aantoont dat de achteruitgang van de prestaties verband houdt met werktijden, of dat het stellen van een vaste starttijd voor enige verbetering zorgt. Afgaande op het oorspronkelijke bericht lijkt het erop dat de auteur zich het meest zorgen maakt over de negatieve feedback die hij van andere afdelingen krijgt.
Klinkt als "de afranselingen zullen doorgaan totdat het moreel verbetert".
#10
+13
bethlakshmi
2012-07-12 21:36:53 UTC
view on stackexchange narkive permalink

Ik benijd je deze niet - als medemanager zou het moeilijk voor me zijn. En eerlijk gezegd geloof ik dat je er mensen door gaat verliezen. Ik denk dat je een enkel symptoom hebt dat voortkomt uit de cultuurverandering van Start Up -> Medium Sized, en niet elke ontwikkelaar zal deze verandering met succes doorvoeren. Ik denk dat je voorbereid moet zijn met functiebeschrijvingen en kennis moet hebben van hoe je vacatureaanvragen 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 vertrouwenskwesties hebt, of een zaak waarin je mensen gemakkelijk tot overeenstemming kunt verklaren. En er is echt geen compensatie die de enorme flexibiliteit tijdens het werk perfect in evenwicht houdt.

Ik ben het ermee eens dat je een voordeel wegneemt. Flexibiliteit in de starttijd is voor sommige mensen een groot probleem, en het spreekt tot een informele cultuur die voor sommige mensen een sterke voorkeur kan hebben. Vermoedelijk is naarmate het bedrijf is gegroeid, de werklast betrouwbaarder geworden, is de werkzekerheid verbeterd, is het respect voor het product toegenomen en heb je misschien een aantal handige aandelenplannen, loonsverhogingen of andere verbeteringen kunnen aanbieden. Als dat allemaal niet waar is, dan moet je je afvragen of je een groeiend &-bedrijf hebt of een bedrijf dat in wanhoop stort.

De truc is dat mensen vaak niet de verbinding kunnen leggen tussen deze nieuwe waarde- voegt toe en het verwijderen van het favoriete voordeel. Je kunt het proberen uit te leggen, maar voor sommige mensen is dit geen goede afweging, en dit is niet het geval waar je de keuze kunt bieden. Het is een "mijn weg of de snelweg", omdat het een organisatorische impact heeft die niet noodzakelijkerwijs voelbaar is binnen het team, maar die wordt ervaren en ondersteund op de hogere niveaus van het bedrijf.

Het klinkt als je hebt de juiste dingen gedaan:

  • je hebt het duidelijk uitgelegd

  • je hebt gesproken over de reden en behoefte aan verandering

  • je hebt één op één ingehuurd (en blijft dit doen, neem ik aan) om individuele gevallen op te lossen zodra ze zich voordoen.

  • je hebt feedback gegeven

Ik denk dat je te maken hebt met "meent hij het echt?" punt waarop het meestal aan mensen bewijst dat je het serieus meent, en dat dit echt moet veranderen. Het zou mijn persoonlijke mening zijn dat 5 minuten te laat zijn op een kantoor in mijn regio niet zo erg is en dat vergaderingen die een korte tijdsspanne hebben (zoals stand-ups in een agile sprint) niet zo tegen de start moeten gaan van de werkdag dat een gemiste busverbinding of slecht verkeer een regelmatig probleem zal worden. Maar dit is enigszins regionaal - verschillende plaatsen hebben grote verschillen in de verkeerssituatie. Dus dat is net zo goed uw regio kennen en uit individuele klachten weten wat redelijk is.

De rest komt gewoon met een mechanisme dat slopend genoeg is om te bewijzen dat u serieus bent. Een dag van uitgesteld loon is een optie en het valt binnen uw wettelijke rechten - hoewel ik elk mechanisme dat ik zou bedenken via de advocaten zou laten lopen. Dat geldt ook voor een formeel waarschuwingssysteem dat leidt tot disciplinaire maatregelen. Ik neem aan dat uw HR-afdeling misschien suggesties heeft ...

Veel hangt af van wat het werk kan verdragen - wanneer u iemand naar huis stuurt, verliest u ook het werk van die dag, wat van invloed is op uw kosten & schema. Als je een waarschuwingssysteem hebt dat leidt tot disciplinaire maatregelen - inclusief ontslag - red je de rest van het werk van de dag, maar loop je het risico de werknemer te moeten ontslaan.

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

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

Het lijkt erop dat er hier een discrepantie is tussen hoe uw ontwikkelaars het probleem zien en hoe de andere afdelingen (of uw superieuren, of wie het ook is die eigenlijk om deze verandering vraagt) het probleem zien. Ik zou willen voorstellen om die kloof te overbruggen, indien nodig in meerdere fasen.

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

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

(Een persoonlijke opmerking: ik bevond me in de positie dat mij werd verteld om op een vast uur binnen te komen, voor zover het de werknemers betrof, geen goede reden, en het is echt buitengewoon ongemotiveerd . Het is erg belangrijk om ervoor te zorgen dat mensen de redenen begrijpen en niet het gevoel hebben dat u het beleid gewoon in een opwelling wijzigt of omdat u ze niet vertrouwt.)

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

Ik werkte vroeger bij een non-profitorganisatie die dit probleem had. Vergaderingen begonnen altijd te laat, 10 minuten te laat werd een "standaard".

Toen kregen we een nieuwe projectmanager voor een groot sleutelproject (en een met een vaste tijdlijn). Ze belde de eerste vergadering. Mensen liepen zoals gewoonlijk binnen, minuten te laat en terloops aan het kletsen. Ze zat in haar stoel en zei een paar minuten niets - helemaal niets. Uiteindelijk stierf het gekletst tot er stilte viel. We zaten allemaal te wachten om iets te horen. Ze liet de stilte nog even aanhouden. Ze keek om zich heen en zei: "Ik moet het duidelijk maken. De vergaderingen beginnen op tijd. Als je 5 minuten te laat komt, hoef je niet te komen, spreek me daarna gewoon af. Oké, nu voor het project zijn we doen deze week [wat dan ook] ... ". Dit maakte een GROTE indruk en mensen deden echt hun best om op tijd te zijn voor haar vergaderingen.

Opmerking: hieronder een aanvullend antwoord toegevoegd.

Houd rekening met op afstand gedaan werk.

Vaak doen de beste producers een groot deel van hun werk op afstand , dus soms evenveel tijd op afstand besteden 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, maar ga gewoon op zoek naar manieren om te laten zien 'ja, Joe was gisteravond laat op aan het werk aan x' en 'ja, Mary heeft dat opgelost op zondag, ze was op tot middernacht '.

Praat openlijk over het woon-werkverkeer. Als iemand om 10.30 uur binnenkomt, kan zijn woon-werkverkeer 15 minuten duren. Als hij om 9 of 9.30 uur moet zijn, kan zijn woon-werkverkeer een uur duren. Bovendien zou het hetzelfde naar huis gaan als ze 8 of 9 uur hebben gewerkt. Veel mensen vinden dat dit een grote verspilling van hun leven is. Ze werken liever een tijdje op afstand en komen daarna binnen. Probeer dit feit te integreren met uw behoeften wanneer u en zorg ervoor dat andere afdelingen daar ook van op de hoogte zijn, nogmaals door het regelmatig te noemen.

Zorg ervoor dat u technologie gebruikt om te helpen. Ik werk bijvoorbeeld virtueel - 100% van de tijd. Dus Skype hebben, mijn status als online laten zien, een videocamera, enz. Kan ook helpen.

De reden dat ik dit upvoot, is omdat het idee van de manager geweldig is - ze gaf praktisch iedereen een "gratis kaart om uit vergaderingen te komen".
#13
+8
Spoike
2012-07-17 14:04:35 UTC
view on stackexchange narkive permalink

Omdat ik in vergelijkbare situaties ben geweest, hoewel toegegeven in minder tijd dan het OP, heb ik alleen dit te zeggen over de toestand van zijn situatie:

De meest praktische en eenvoudigste oplossing ...

... zou zijn om te proberen de vergaderingen om 11 uur te starten. Maak je geen zorgen, je geeft niet toe. In plaats daarvan leid je de stroom om, net zoals de principes achter Aikido. Het idee is om je in plaats daarvan te concentreren op het helpen van je team om belangrijke dingen voor elkaar te krijgen, aangezien dit het allerbelangrijkste is, want er is echt één serieus probleem dat moet worden aangepakt:

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

Je team laten komen om 9.30 uur, wat ik kan toegeven dat het niet vroeg is, is hier echter geen oplossing voor probleem. Je hebt het geprobeerd en het is mislukt, dus stop ermee dit te doen. Sla niet langer met je hoofd op een bakstenen muur. Mijn enige tip hier is om communicatie altijd te waarderen boven willekeurig ingestelde vergaderingen.

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

  • Ga naar vergaderingen en verzamel doelen en vereisten van de andere afdelingen
  • Zoek uit wat er sinds gisteren is voltooid
  • Beheer verwachtingen en afspraken met de andere afdelingen over wat er moet en kan worden gedaan tijdens de werkdag
  • Breng goed nieuws en slecht nieuws naar de andere afdelingen
  • Werk eventuele plannen bij die relevant zijn voor het team als die er zijn
  • Zoek uit welke problemen met code en softwarearchitectuur moeten hebben aandacht vandaag
  • "NEE" zeggen tegen verzoeken die geen zakelijke waarde bieden
  • Kritiek accepteren van de andere appartementen en je verontschuldigen met de zekerheid dat de problemen zullen worden opgelost
  • enz. (er is altijd iets dat moet worden aangepakt)

En tenslotte, vóór de bijeenkomst vat een korte samenvatting samen voor het team over wat er gebeurt, om hen wat situationeel bewustzijn te geven. Als de vergadering om 11 uur begint en iedereen fris aan het werk is, heb je informatie en een vergaderprotocol voor hen opgesteld. U kunt de briefing en notulen van de vergadering als een nieuwsbrief laten schrijven en deze als een vriendelijke herinnering enige tijd na de vergadering als e-mail verzenden.

Tijdens de vergadering met het team heeft u twee dingen van hen nodig:

  • Vraag om schattingen voor taken die moeten worden uitgevoerd, vooral die met hoge prioriteit. Het hoeft niet precies te zijn, zoals in minuten. Hiermee kun je afspraken en deadlines veel duidelijker afspreken met de andere afdelingen. Als ze geen schatting kunnen geven voor een taak, vraag ze dan om het overdag of de volgende dag uit te zoeken.
  • Vraag naar belemmeringen of als ze ergens hulp bij nodig hebben, schrijf dat op en zorg ervoor dat deze problemen kunnen worden opgelost en dat ze worden opgelost.

Na een tijdje kunt u waarschijnlijk geleidelijk overgaan naar eerdere vergaderingen. Maar aanvankelijk tegen de stroom in gaan is niet de juiste keuze en leidt alleen maar tot een nog besmettelijkere cultuur (waarin herstel alleen mogelijk is door het hele team te vervangen). Als het, zoals je zegt, 'primadonna's' zijn, dan is het jouw echte taak om ze om te bouwen tot geweldige primadonna's die van hoge kwaliteit zijn. Het is duidelijk dat je team autonomie had en wilde. a>, dus begin die cultuur te exploiteren ten voordele van de doelstellingen van uw bedrijf.

Als het je is gelukt om een ​​betrouwbaar team te vormen, door communicatie in plaats van dwang, kun je drie uur eerder vertrekken dan alle anderen in het team weet dat ze hun werk doen (maar nog steeds bereikbaar zijn als de onzin de fan raakt). Dat is vertrouwen waarop u kunt rekenen.

Ik denk dat dit meer goed, solide advies is en een goede alternatieve benadering die tot succes zou leiden. De rol van een ** manager / teamleider ** is om het team te isoleren van lawaai en verwarring en obstakels te verwijderen die hun efficiëntie verminderen. Dit antwoord stelt een aanpak voor om al die dingen te doen!
#14
+6
pap
2012-04-26 17:26:40 UTC
view on stackexchange narkive permalink

Ik lees opmerkingen en antwoorden en ik moet bekennen dat ik een beetje stomverbaasd ben. Sinds wanneer zijn mensen op tijd "verlies van een voordeel"? Sinds wanneer hoeft flex-time zich geen zorgen te maken over de impact van uw acties op de rest van het team en het bedrijf?

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

Leg aan uw team uit dat u geen probleem met flextijd, maar dat het een zekere persoonlijke verantwoordelijkheid met zich meebrengt om ervoor te zorgen dat uw flexwerk het werk van anderen (in uw team of andere teams) niet beïnvloedt. Aangezien uw team duidelijk tekortschiet op het gebied van verantwoordelijkheid, zou ik zeggen dat met onmiddellijke ingang en tot nader order alle flextijden vooraf door u moeten worden goedgekeurd. Als je 's ochtends niet op tijd komt opdagen zonder goedkeuring of een redelijk excuus (nee, de wekker ging niet af is niet acceptabel) zal resulteren in disciplinaire maatregelen zoals uitbetaling van een dok of vakantietijd.

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

** Opmerkingen verwijderd. ** Gebruik opmerkingen om het antwoord te verbeteren of om verduidelijking te vragen, niet voor algemene discussie. Gebruik [chat] voor een uitgebreide discussie.
#15
+6
anonymous
2012-04-24 00:35:26 UTC
view on stackexchange narkive permalink

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

Met betrekking tot het verplaatsen van de ontwikkelaars naar een soort van vast beschikbaarheidsschema, kun je het beste is ervoor te zorgen dat eventuele "zware uren" zoveel mogelijk worden verzacht. Als de "kernuren" bijvoorbeeld van 11:00 tot 15:00 uur zijn, kunt u er ook voor zorgen dat de kernuren op vrijdag niet aanwezig zijn en dat vrijdag een echte flextijddag is. Omdat dinsdag, woensdag en donderdag traditioneel als de meest productieve dagen van de week worden beschouwd, kun je misschien de kernuren op die dagen toepassen en maandag en vrijdag ook volledige flexdagen toestaan.

Om ervoor te zorgen dat de uren worden nageleefd, als de richting van bovenaf komt en wordt goedgekeurd door het hogere management, moeten de ontwikkelaars zich er uiteindelijk aan houden als onderdeel van hun dienstverband. Je moet doen wat je kunt om ervoor te zorgen dat het gefaseerd wordt ingevoerd en als sommige ontwikkelaars flextijd hebben opgenomen in hun arbeidsovereenkomst, moet dit worden aangepakt (bijvoorbeeld door hun compensatie en secundaire arbeidsvoorwaarden te wijzigen, hen in te schakelen, enz.); op een gegeven moment zult u er echter voor moeten zorgen dat het beleid moet worden nageleefd, hetgeen mogelijk ook officiële disciplinaire maatregelen van werknemers vereist. Evenzo, als sommigen ervoor kiezen om te vertrekken, kan het de moeite waard zijn om te proberen om te zien of ze bereid zijn te blijven met wijzigingen in de vergoedingen en voordelen; maar je moet misschien ook accepteren dat je een aantal ontwikkelaars verliest.

Uiteindelijk, als je baan vereist dat je de groep een culturele verandering afdwingt om aan de behoeften van het bedrijf te voldoen, zullen je opties tot op zekere hoogte beperkt zijn. U kunt en moet er alles aan doen om de verandering te verzachten en eventuele compromissen met andere groepen uit te lokken, maar uiteindelijk moet u de verandering afdwingen en eventuele personeelswijzigingen accepteren.

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

Er zijn nog steeds meerdere manieren om dit probleem aan te pakken, waarvan er één zou zijn om de rol van de afdeling te veranderen, zoals bijvoorbeeld: als je met softwareontwikkelaars werkt, zou je de rol voor een bepaalde persoon kunnen veranderen tijdens de week om hen ondersteuning te laten bieden voor de andere afdelingen, waarvoor er 1 of meer nodig zijn om 9 uur of eerder binnen te komen en als dat niet werkt, kunt u altijd een beroep doen op een insubordinatieclausule die normaal gesproken aanwezig is in een arbeidshandboek in de VS . Persoonlijk ben ik altijd tegen het gebruik van deze clausule geweest, die een manager een manier geeft om iemand terecht te wijzen en zelfs te ontslaan om een ​​goede reden , maar in jouw geval kan dit gepast zijn. Neem daarom het werknemershandboek door en bespreek het met uw leidinggevende als u er een heeft dat u dit gaat doen.

Het basisidee is als volgt:

  1. U stelt de regel in dat ten minste 1-2 of alle mensen op uur X aan het werk moeten zijn.
  2. Als uw teamleden geen geldig excuus hebben om niet te verschijnen of vol te houden in deze praktijk, moet u als manager hen berispen en mogelijk ontslaan.

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

Het ongelukkige gevolg kan natuurlijk een hoge omloopsnelheid in uw groep zijn, wat een slechte weerslag zou hebben 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 één vraag: moet je team echt eerder aanwezig zijn dan wanneer ze binnenkomen?

In antwoord op uw vraag - Ja. We hebben meerdere afdelingen waar we regelmatig mee samenwerken. Deze afdelingen zijn tussen 8-9 en vertrekken tussen 4: 30-5: 30. Een late starttijd en lunch betekent minimaal - 1) Geen vergaderingen voor 13.00 uur en 2) Een halve dag of meer verspillen als iemand op iets van onze afdeling wacht. Ongelofelijk inefficiënt.
@JacobG het klassieke gevolg is "Je blijft laat om het werk af te maken, of we leggen vakantietijd aan". Met betrekking tot "iedereen" die 9:30 een redelijke starttijd vindt: ik niet. Aan de andere kant werk ik tot 8-9 uur 's nachts, soms later, en vaak nadat ik naar huis ben gegaan. Dat zijn mijn meest productieve uren, en ik zou ze er niet in stoppen als verwacht werd dat ik stipt om 09.30 uur binnen zou lopen "of anders" - ik zou een 9-tegen-5er worden. Elk team is uniek, en ik hoop dat u dat in uw evaluatie overweegt ...
@Jacob - wat voor soort ontwikkelteam is dit? Zijn jullie gewoon een ander bedrijf dat de interne X-app onderhoudt, of schrijven deze hoogwaardige ontwikkelaars solide code die de ruggengraat van je bedrijf is? Als dat laatste het geval is, lijkt het niet verwonderlijk dat sommigen van hen verwachten dat ze laat van huis kunnen werken en laat komen. Ik zou je aanraden om daar rekening mee te houden. Kwaliteitsontwikkelaars zijn * ongelooflijk * moeilijk te vinden. En ze hebben altijd andere opties als de huidige baan niet lukt.
@voretaq7 vat dit niet verkeerd op, maar ik vind dat grotendeels een kwestie van gewoonte. Als je er een gewoonte van maakt om om 23.00 uur in plaats van 03.00 uur naar bed te gaan en om 07.00 uur op te staan ​​in plaats van 9.30 uur, zul je merken dat na een tijdje je meest productieve tijd vóór de lunch zal zijn en dat je om 21.00 uur begin een beetje slaperig te worden. Mensen passen zich aan.
@JacobG Waarom is het 'een halve dag verspillen'? Komen deze andere teams om 8 uur 's ochtends aan en realiseren ze zich dan plotseling dat ze iets van een ontwikkelaar nodig hebben?
@robertc Er zijn zeker gelegenheden waarbij de andere teams om 8 uur arriveren en zien dat er iets is dat aandacht van de ontwikkelaar vereist. Maar dat was niet mijn punt. Mijn punt was dat als een andere afdeling iets van het ontwikkelteam blokkeert, de blokkering pas halverwege de dag van de aanvrager zal worden vrijgegeven. Soms is dat oké en vaak is het gewoon onhandig.
@JacobG Maar je mist mijn punt, waarom wachten ze tot 8 uur 's ochtends op de dag dat ze iets nodig hebben om te besluiten de ontwikkelaar te vertellen dat ze iets nodig hebben?
@robertc Omdat ze pas om 8 uur 's ochtends weten dat ze iets nodig hebben. "Een klant heeft gebeld en ondervond dit probleem ..." "Het lijkt erop dat deze gegevens beschadigd zijn ..."
@JacobG Geen van de voorbeelden die u vermeldt, zijn ontwikkelingstaken. Zelfs als u uw ontwikkelaars clientondersteuning laat doen (zoals u suggereert), waarom moeten al uw ontwikkelaars dan op een bepaald moment op kantoor aanwezig zijn om ondersteuning te bieden? Waarom hebt u klanten en andere afdelingen specifieke doorlooptijden beloofd voor ondersteuningskwesties als u geen toegewijd ondersteunend personeel heeft?
Ik heb in een handvol teams gewerkt die werden overtreden vanwege regels zoals hier voorgesteld. Een advies: mensen kunnen al een paar weken vroeg komen. Maar daarna ga je ze zien werken voor de concurrentie.
#17
+2
A quiet hum
2018-06-24 21:22:16 UTC
view on stackexchange narkive permalink

Kortom, u moet beslissen wat belangrijker is, de klus goed klaren of 8 uur op voorgeschreven tijden aan uw bureau zitten?



Deze Q&A is automatisch vertaald vanuit de Engelse taal.De originele inhoud is beschikbaar op stackexchange, waarvoor we bedanken voor de cc by-sa 3.0-licentie waaronder het wordt gedistribueerd.
Loading...