1. Kijk naar incentives Hoe worden bonussen bepaald? Loonverhogingen? Promoties? Bij gebrek aan duidelijkheid dat het geen competitief proces is (en je hebt heel wat middelen nodig om er geen competitief proces van te maken), zal worden aangenomen dat het een competitief proces is. Wat is de snelste weg naar een promotie of verhoging in uw bedrijf (en er is er een, zelfs als het de deur uit is naar een concurrent met een solide cv)? Is er een schaars hulpmiddel dat niet alle ontwikkelaars zullen krijgen en dat proces wordt bepaald door werksucces? Gefeliciteerd, je hebt een competitief proces gecreëerd.

2. Kijk naar gewichtstoename. De ideeën van "teamverantwoordelijkheid" en "samenwerking" slijten erg dun wanneer het voordeel maar één kant op gaat. Was Bob die dag gewoon ziek of is Bob ook een familielid onder bijdragers?

3. Overweeg om verder te gaan met bouwen. Ik weet niet zeker hoe u uw projectmanagement doet, maar sommige soorten projectmanagement betekenen dat ontwikkelaars niet definitief worden verantwoordelijkheid voor een deel van het project. Bij gebrek aan een grote cv-lijn die waardig is om verantwoordelijk voor te zijn, blijven ze achter met alle concurrentiestatistieken van hun collega's. Hoe kunnen ze hun cv samenstellen zonder dingen te zeggen als "hoogste betrouwbaarheidsniveau van een team van 10 ontwikkelaars bij het behalen van sprintdoelen"?

4. Kijk naar open interne vacatures. sterk> Is er misschien een open senior functie? Concurrenten als onbetrouwbaar bestempelen is een aloude manier om competitiever te zijn voor die banen.

5. Bedenk hoe ze bij het bedrijf terecht zijn gekomen. In Amerika (en enigszins Canada) krijgt men een plek op de beste middelbare scholen door met succes te concurreren met andere mensen en te winnen. Je krijgt een plek op de universiteit door te concurreren en te winnen. Je krijgt stages door te concurreren en te winnen. Men kan worden aangenomen op basis van de prijzen en prestaties die concurreren en winnen, zodat u op uw cv kunt zetten. Maar dan schakelen veel bedrijven over op de afgeschreven verantwoordelijkheid van "teamplay" ondanks het feit dat ze mensen hebben aangenomen omdat ze erin geslaagd zijn andere mensen te verslaan. Ik wed dat uw bedrijf een competitief wervingsproces gebruikt, waarbij wordt gezocht naar de 'beste die solliciteert'. Hoe kom je in die positie met het bewijs om het te bewijzen? Andere mensen verslaan.

ontspan en stop met de concurrentie en geef de cultuur de schuld

Het moet niet langer gunstig zijn voor werknemers om op die manier. Maar het probleem is dat alleen in de meest perfect uitgebalanceerde omgevingen dat waar is, zonder dat het gedrag voortduurt of mensen die de top proberen te verlaten. Ervan uitgaande dat u een Amerikaan / Canadees bent, hebben uw werknemers hun leven lang competitieve processen gebruikt om te winnen, dus een hoge gevoeligheid voor incentives is een lang ingebed gedrag. U moet in feite de prikkels opnieuw in evenwicht brengen.

De beste manier om erachter te komen waarom ze concurrerend zijn, is door met ze te praten. Ik denk dat het beter is als je het in twee stappen doet:

1. Houd een teamvergadering met iedereen. Vertel hen wat u heeft waargenomen en dat u niet tevreden bent met de situatie. Geef ook aan hen toe dat u niet begrijpt waarom deze dingen gebeuren, en dat er misschien een goede reden voor is. Laat ze uitleggen wat ze willen / nodig hebben, VOORDAT je iets probeert op te lossen. Op basis van de feedback, zou je ze kunnen vragen om een ​​oplossing te vinden die zowel voor hen als voor jou werkt.
2. Als stap 1 mislukt (geen feedback of onbruikbare feedback), organiseer dan F2F-vergaderingen met elk van hen. Op deze manier worden ze bevrijd van de druk om beoordeeld te worden door hun collega's.

De basisregels:

• maak vanaf het begin duidelijk dat de discussie wordt niet in aanmerking genomen bij functiewaarderingen. Het zal zijn alsof het niet is gebeurd;
• verzamel zoveel mogelijk informatie VOORDAT u begint met het oplossen van iets;
• persoonlijk kunt u niets oplossen; als het team hun problemen niet oplost, zal geen enkele andere inspanning helpen; dingen forceren zal ertoe leiden dat mensen de boot verlaten;
• het probleem kan even duren voordat het is opgelost, zelfs als het proces onmiddellijk begint;

Goed gelezen in uw geval is om meer te lezen over teams en teamontwikkeling .

De feedbackregels zijn essentieel ook.

@Meg maakte een zeer nuttige opmerking:

Als iemand naar de werkplek SE kwam met de vraag: "Mijn baas vroeg om een ​​vergadering en zei dat het niet in aanmerking zou worden genomen voor latere evaluaties, kan ik dan wel eerlijk zijn? " Ik durf te wedden dat de meeste van de beste antwoorden in de trant van -ITS A TRAP- zijn, dus wees niet verbaasd als teamleden aarzelen om feedback te geven.

Dat is heel waar, dat een relevant aantal managers het ene belooft en het andere doet. Sommigen van hen zijn echter niet slecht. Hoe weten we welke manager slecht is en welke niet? Alleen ervaring zal het leren. En ja, ik had de ervaring toen managers zeiden dat de feedback meer op een teambuilding / trainingssessie leek, alleen om erachter te komen dat alle verzamelde informatie aan het eind van het jaar op de persoonlijke evaluaties verscheen.

Als een manager feedback vraagt ​​zonder het doel van de vraag te specificeren, is de kans groot dat de feedback bij de evaluatie wordt gebruikt. Maar de test komt als hij belooft de feedback niet te gebruiken. Als hij inderdaad zijn belofte nakomt, weet je dat je vertrouwen kunt opbouwen bij die manager.

Natuurlijk is het altijd een tweesnijdend zwaard. Het is altijd de vraag wie de eerste was, de kip of het ei. Maar iemand moet een sprong in het diepe wagen om te proberen de wereld beter te maken.

Natuurlijk moet je als teamlid natuurlijk niet vanaf het begin alles uit de kast halen. Maar als de manager de aardige vent blijft, kun je meer en meer openstaan, voor wederzijds voordeel.

Omdat ze lijken te vechten om snelheid, waarom zou je dat dan niet helemaal van hen afnemen? Het kan relatief eenvoudig worden gedaan - vergader aan het begin van een werkperiode, bijvoorbeeld maandag, en spreek af over het werk dat voor die werkperiode moet worden geleverd en bekijk de voortgang aan het einde ervan. Het kan een week zijn, het kan twee weken zijn, dealerkeuze.

Concentreer je vervolgens tijdens standups op het zeer eenvoudige formaat van "wat heb ik gedaan", "wat zal ik vandaag doen", "zijn er die blockers ', het afbreken van alle geklets / schuldspelletjes, enz. Als er een echt probleem is om te bespreken, neem het dan na stand-up met alleen de betrokken partijen in een privéruimte.

Als de hoeveelheid werk voor een woordperiode is opgelost, dan is er geen reden om het te haasten, in plaats daarvan is er een stimulans om de kwaliteit van uw product te verzekeren, zodat het compleet is en klaar voor overdracht, zonder dat u meer tijd hoeft te vinden om het vervolgens op te lossen. Dat zou nog steeds moeten voldoen aan hun behoefte om te concurreren, maar minder aan de "rush to deliver" -kant.

Met betrekking tot de kwestie van het wijzen op de afwezigheid van andere mensen: omdat u de teamleider bent, bent u degene waarop uw ondergeschikten antwoord moeten geven. Als hun werk te laat is, dan (zo denken ze), reken je dat tegen hen en zeg je dat ze ondermaats presteren. Daarom is er behoefte aan verantwoording in de zin dat u moet weten waarom ze hun werk niet af krijgen. Dit is niet iedereen die "Bob" de schuld geeft, dit is iets dat gebeurt; Bob is ziek, dus werk dat afhankelijk is van Bob loopt vertraging op, dus projecten en taken komen te laat, dus de persoon die verantwoordelijk is voor het op schema houden van die taken (dat wil zeggen jij) raakt boos op degenen die deze taken zouden moeten voltooien, zonder te weten dat de taken werden vertraagd, niet omdat de persoon die ze uitvoerde te weinig bijdroeg, maar omdat Bob weg was en de taak van Bob afhing.

Ik denk niet dat er een redelijke manier is om dit probleem op te lossen. Het is een belangrijk onderdeel van de Agile-methodologie dat wanneer doelen niet worden behaald, er een terugblik is en er een conclusie wordt getrokken over waarom die doelen niet zijn behaald; als de conclusie is "Bob was een essentieel onderdeel van deze taak en Bob nam een ​​week vrij", dan is de conclusie de conclusie, of het klinkt alsof Bob "de schuld krijgt" of niet. Dit kan worden opgevat als een les voor degene die taken plant (vermoedelijk u): laat uw werknemers u van tevoren op de hoogte stellen wanneer ze verlengde vakantie opnemen, en plan (of probeer) geen taken in te plannen die afhankelijk zijn van die werknemers wanneer ze weg. Dan zul je niet de schuld krijgen omdat er niemand de schuld is.

(Een betere oplossing zou zijn om het delen van informatie binnen het team aan te moedigen om de "Bus-factor" van je team te verminderen, maar dat is een ideale en niet praktisch in veel omgevingen)

Met betrekking tot het concurrentievermogen van het team, onder welke KPI-meting werkt uw team? Is het aantal gewiste tickets? Aantal behaalde Agile-punten? Aantal geïntroduceerde bugs (minimaliseren)? Iets anders? U moet duidelijk zijn met uw team over waarvoor zij hun werk zouden moeten optimaliseren. Het klinkt alsof de vorige leider van dit team het maximale "aantal voltooide tickets" heeft gemaximaliseerd, wat ertoe leidt dat code snel en los wordt geschreven, standaarden niet worden gevolgd, bugs worden geïntroduceerd, code wordt samengevoegd zonder beoordeling, enzovoort. De meeste van de problemen die u beschrijft, kunnen op deze manier worden verklaard. Mijn suggestie zou zijn om dat op zijn kop te zetten: het is belangrijker dat tickets goed worden gedaan dan snel. Geef codebeoordeling de allerhoogste prioriteit en zorg ervoor dat alle code aan de norm voldoet voordat deze wordt samengevoegd en geïmplementeerd. Incentives worden daarom geoptimaliseerd voor het aantal bugs dat achteraf wordt gevonden; als er een bug wordt gevonden in een stuk code, worden zowel de ontwikkelaar als de recensent negatief beïnvloed (op welke manier dan ook die u als teamleider geschikt acht). Zolang het werk wordt gedaan, kan het langzamer zijn om te worden gedaan, maar het moet wel goed worden gedaan.

In dit geval, als uw ondergeschikten concurrerend zijn met elkaar, is hun concurrentievermogen in dit geval afgestemd op het bedrijf: in plaats van enige code eruit te halen, zelfs als het slechte code is, zal het concurrentievermogen worden afgestemd op wie de beste code kan schrijven, en dat is min of meer het einddoel.

Als teamleider moet je het gedrag dat je wilt zien, stimuleren voor zover je kunt.

Probeer deze kwesties te bekijken vanuit het perspectief van het team. U zegt bijvoorbeeld dat ze strijden om snelheid ten koste van kwaliteit. Begin te vragen waarom. Heeft u leverbare data voor werkeenheden? Zijn er kwaliteitscontroles? Wie is verantwoordelijk voor het oplossen van de bugs die op deze manier zijn geïntroduceerd? Kortom, waarom maken ze zich minder zorgen over kwaliteit en wat kunt u doen om de balans te verschuiven?

Hoe stimuleer je in meer algemene zin teamwerk? In grote lijnen moet u proberen het werk als geheel te evalueren en het los te koppelen van de individuele bijdragers. Maak duidelijk dat je niet geïnteresseerd bent in wie wat heeft gedaan, of dat x iets niet heeft afgemaakt omdat hij of zij op y wacht, of dat de ene persoon iets sneller af heeft dan de ander. Het stellen van duidelijke doelen om prestaties / voortgang te meten, zou moeten helpen om de focus van elkaar te verleggen.

Door dit te doen, zal uw team het feit onder ogen moeten zien dat hun individuele bijdragen zo goed zijn als wat ze brengen naar het grotere doel. Ze zullen uiteindelijk worden beoordeeld op hoe ze samen zinken of zwemmen, en leren op elkaar te vertrouwen als ze willen slagen.

Ik stel voor om uit te zoeken hoe het überhaupt zo erg is geworden. Waar komt deze schuld vandaan?

Het kan afkomstig zijn van de vorige manager (die vertrekt) of het kan afkomstig zijn van een of twee teamleden die binnenkwamen en begonnen te roeren.

Aangezien je er bijna een jaar bent, en je hebt geen idee wie de giftige teamgenoten zijn, was het waarschijnlijk je oude manager die dit gedrag aanmoedigde.

Dat is best goed, want het enige wat je hoeft te doen is dit gedrag niet langer aanmoedigen.

als iemand zoiets zegt

"Nou, ik kon gisteren niet veel gedaan krijgen zoals Bob was ziek, dus ik moest de ondersteuning dekken "

Je kunt reageren door te zeggen:

Kan me niet schelen

Als ze elkaar de schuld geven in e-mails en "subtiel" naar elkaar uithalen, roep het dan snel uit met "het kan me niet schelen". U hoeft geen essay te schrijven over hoe giftig het is voor het team of de rest, maar laat het vaak weten dat het management niet langer geeft om de kleine onzin.

1. Praat er openlijk over dat je dit probleem hebt waargenomen tijdens een bijeenkomst met alle aanwezigen, en zeg zonder vingerwijzigingen gewoon dat je wilt dat dit verandert en je zult een aantal concrete maatregelen nemen om een ​​meer coöperatieve en productieve teamwerk dit is een schone lei. Niemand wordt veroordeeld voor wat er tot nu toe is gebeurd.
2. Probeer het gewenste gedrag aan te moedigen en te belonen : hoe te belonen? Regelmatige en strakke feedbackloops: "Hé, ik heb gemerkt dat je Bob hebt geholpen en ondersteund bij het bereiken van zijn taak: goed werk!", "Cool hoe je de kritiek van je collega's hebt geaccepteerd en de door hen voorgestelde veranderingen hebt doorgevoerd: het toont professionaliteit en dat je meer geeft om de code dan over uw handtekening in de code - dat is de manier om te gaan ”
3. Laat ze begrijpen dat het individuele succes van elk lid nauw verbonden is met het succes van het hele project / team - dus doe je goed werk als je zo bijdraagt ​​dat het team presteert op de best mogelijke manier (geen enkele persoon vergeleken met de andere teamleden). Het hebben van een slechte en vijandige sfeer binnen het team is duidelijk vergif en elk gedrag dat dit bevordert, moet strikt worden vermeden. Om dit te bereiken, is het het beste als conflicten tussen leden openlijk worden besproken en meteen worden besproken en er een compromis wordt bereikt waarbij alle betrokken partijen meedoen. Als dit niet mogelijk is (wat naar ik hoop niet het geval is, want dat zou een echt slechte sfeer) zou je zelfs moeten overwegen iemand te laten gaan die niet wil meewerken, zelfs als hij een slechte coder is. Maar het is belangrijk dat iedereen begrijpt dat wanneer ze zich niet goed voelen met betrekking tot een ander lid, ze zich zo moeten uitspreken dat er een of andere actie kan worden ondernomen - brand zo snel mogelijk blussen! Ook als andere teamleden er op de geringste manier slecht uitzien, zul je er op geen enkele manier beter uitzien, maar alleen dat je er minder goed uitziet. Als er een probleem is: pak het dan direct aan.
4. Maak van 'een goede teamwerker zijn' een van de eigenschappen die worden geëvalueerd voor verdere loopbaanontwikkeling Het is gemakkelijker te meten dan jij zou kunnen denken: vraag de anderen hoe graag ze werken met onderwerp A van 1 tot 10 of zoiets. Doe dit voor elk lid. Maar merk op dat ik een van de eigenschappen zei - natuurlijk moeten nog veel andere dingen worden geëvalueerd. Als dit nog steeds een van de dingen is, zullen ze meer bereid zijn om het goed te doen in deze categorie.
5. Laat ze van tijd tot tijd feedbackgesprekken voeren (paarsgewijs) tussen elkaar iedereen zou de anderen moeten vertellen wat ze goed deden en waar ze het gevoel hadden dat ze konden verbeteren en misschien zelfs iets waar ze last van hadden hopelijk kunnen er veranderingen zijn - je zou uiteindelijk de ingevulde formulieren moeten krijgen.
6. Om het 'nieuwe tijdperk' te laten beginnen, zou je zelfs een soort 'teambuilding'-evenement kunnen doen In ons bedrijf hebben we één evenement gedaan waarbij we een toren moesten bouwen met Spagetti en marashmellows, maar alleen eerst discussieerden zonder het spul aan te raken en dan bouwen zonder te praten (of zoiets). Maar het zou goed zijn als het minstens een hele middag van dit soort dingen zou zijn en misschien zelfs eerst samen voor de lunch gaan koken. Even een globaal idee ...

Punt 4 en gedeeltelijk ook 5 zullen u meer inzicht geven in de relaties over teamleden en in staat zijn om potentieel kritische relaties te zien en zaken vroegtijdig aan te pakken. / p>