Als manager is het uw taak om te voorkomen dat uw medewerkers worden afgeleid. Als ik het was, zou ik de slechte punten of de slechte code van deze persoon niet noemen. Moedig tegelijkertijd de slechte dingen die hij deed ook niet aan.

Iets in de trant van:

Bob was echt een geweldige programmeur en hij zal enorm worden gemist . Hij heeft ervoor gekozen om een ​​andere kans te grijpen en we wensen hem het beste. Ik ben erg trots op jullie als team en hoe jullie samenkomen om onze tijdlijnen in beweging te houden en door te gaan met het geweldige werk waartoe jullie in staat zijn.

Dit zegt niet iets specifieks, maar prijst tegelijkertijd uw team. Na verloop van tijd kun je een deel van de rotzooi voorzichtig ontrafelen en de zaken aanscherpen.

Zodra het stof is neergedaald, is het tijd om de bespreking van verschillende coderingsnormen te introduceren. Breng ze niet van bovenaf naar beneden, maar moedig het team aan om ze te ontwikkelen en vraag ze vervolgens om elkaar verantwoordelijk te houden. Dit zou enkele van de problemen die u had moeten verhelpen.

Door er iets negatiefs over te zeggen, loop je het risico er bekrompen uit te zien. Als leider kun je veel beter resultaten gewoon voor zichzelf laten spreken en het team met hun eigen theorie over de oorzaak laten komen. Als u prestatiestatistieken heeft die u in de gaten houdt, kunt u het team zeker feliciteren met 'een duidelijke verbetering in metriek X in de afgelopen Y-weken' om dat idee te bevorderen, maar vermeld absoluut niets als uw indruk van verbetering puur anekdotisch is .

Moet ik dit in een teamvergadering bespreken door feiten en redenen te noemen waarom hij afwezig was? of moet ik gewoon niets zeggen? Wat kun je het beste doen in een situatie als deze?

Ik denk niet dat het nodig is.

Als de voortgang veel sneller gaat zoals u het beschrijft, zullen ze ook de verbeteringen opmerken en hun eigen conclusies trekken.

Een vergadering bellen of iets dergelijks om in feite te zeggen "Voel je niet verkeerd dat hij vertrok, we zijn nu veel beter en efficiënter" is niet iets dat ik zou aanraden (omdat het in feite zijn reputatie opzettelijk vuil maakt).

Misschien was hij niet de beste programmeur die er is, maar uit uw bericht kan ik zien dat hij erg enthousiast en enthousiast was, en zelfs uw "go to" -persoon, dus ik zou zeggen dat u geef hem daarvoor de eer en laat uw professionele relatie gewoon soepel eindigen.

We hadden er hier een voordat ik begon. Hield van nieuwe frameworks, ontwerppatronen en tools. Begreep ze echt niet.

Het probleem was dat hij het oude management verliefd had op zijn 'vaardigheden'. Nieuw management met echte architectonische vaardigheden kwam binnen en 'Bob' * (niet zijn naam) begreep dat hij in de problemen zat. Bob * is net weggegaan en is nooit meer teruggekomen, hij kon de code die hij schreef niet ondersteunen, dus het was aan anderen (een van de redenen waarom ik werd aangenomen) om de rommel die hij achterliet te ontcijferen. Veel van zijn code is zojuist uit stackoverflow gekopieerd. Het probleem was dat hij niet begreep wat hij aan het kopiëren was.

Hoe ga je om met je team? Zeg "Bob * heeft ontslag genomen. Ik weet dat sommigen hem zullen missen. Nu is het aan ons om vooruit te blijven gaan". Iedereen die ervaring heeft, zal weten wat er echt is gebeurd en de junior ontwikkelaars zullen uiteindelijk (wanneer ze een aantal dingen moeten ondersteunen die 'Bob' schreef) waarom het het beste was dat hij wegging.

* Geen aanstoot aan iemand die Bob heet.

Ik zou ervoor kiezen om heel kort (30 seconden of minder, indien mogelijk) de technische en professionele redenen uit te leggen waarom deze persoon niet goed paste, terwijl ik toch waardeer wie ze zijn als persoon. Begin er dan nooit meer over terwijl je verder gaat met het werk dat voor je ligt.

Hoewel ik het eens ben met de meeste antwoorden hier, geloof ik dat een beetje transparantie veel goed kan doen voor het algemene moreel en de cultuur van de mensen die er nog zijn.

• Ze hun eigen conclusies laten trekken kan averechts werken en wantrouwen opbouwen.
• Dit kan een goed precedent scheppen voor junior ontwikkelaars door duidelijk te communiceren wat niet te doen (in dit geval toegeven aan bepaalde egoïstische "ontwikkelaarsverleidingen")
• Versterk het feit dat dit een team is, en van iedereen wordt verwacht dat hij codeert als een team
• Verminder de angst dat ze de volgende zouden kunnen zijn (omdat ze opkeken naar en bewondering hadden voor de vaardigheden en benaderingen van deze ontwikkelaar)
• Herinner de werknemers eraan dat er een stabiele toekomst is, zolang ze er zich bewust van zijn het bedrijf te dienen behoeften

Als je een agile-programmeerbenadering gebruikt, kun je deze altijd ter sprake brengen tijdens de scrum-retrospectieve bijeenkomst zodra de huidige scrum eindigt. Het bespreken van de gebeurtenissen van de scrum, hoe ze het team hebben beïnvloed en hoe je ze kunt gebruiken om vooruitgang te boeken, is eigenlijk het punt ervan, toch? Het bespreken van dit soort onderwerpen lijkt er goed in te passen.

Noem de positieve punten en negeer de negatieve punten:

We hebben nieuwe mogelijkheden om nieuwe patronen te introduceren en onze architectuur te verbeteren

als je nog steeds wilt wing it ... of ...

We hebben een nieuwe kans om coderingsstandaarden en best practices te introduceren

Als u wilt beginnen met het opschonen wat u heeft en praktische tips implementeert.