20 november 2006

hoe behandelen we onze 'beste' werknemers?

Stel je voor dat je een bedrijf runt en dat je ontdekt dat bijna de helft van je beste, meest performante werknemers actief bezig is met het zoeken van een andere job. Welk gevoel zou je dat geven?

Wel, deze fantasie blijkt niet zo veel van de realiteit te verschillen. Volgens een studie van Leadership IQ is 47% van de meest productieve en creatieve werknemers actief op zoek naar een andere job.

Da's heel veel, vind ik.

Volgens Mark Murphy (schrijver en CEO van Leadership IQ) komt het doordat de 'beste' werknemers het meeste (over)werk en stress op hun bord krijgen. En doordat nog geen 25 % (nog zo'n ongelooflijk getal) van de werkgevers met zijn werknemers praat over wat hen motiveert en demotiveert. Of toch niet voordat het te laat is...

Ik had verwacht dat er in deze tjden al meer en beter zou gecommuniceerd worden. Wordt er met jou gepraat over wat je motiveert in je job?

Meer info over deze verontrustende cijfers vind je hier.

3 opmerkingen:

Anoniem zei

En dan nog te weten dat je in de informatica mogelijk met 25 van de 200 mensen de job kan doen ...
Zie Mythical Man month Chapter 3

Programming managers have long recognized wide productivity variations between good programmers and poor ones. But the actual measured magnitudes have astounded all of us. In one of their studies, Sackman, Erikson, and Grant were measuring performances of a group of experienced programmers. Within just this group the ratios between best and worst performances averaged about 10:1 on productivity measurements and an amazing 5:1 on program speed and space measurements! In short the $20,000/year programmer may well be 10 times as productive as the $10,000/year one. The converse may be true, too. The data showed no correlation whatsoever between experience and performance. (I doubt if that is universally true.)
I have earlier argued that the sheer number of minds to be coordinated affects the cost of the effort, for a major part of the cost is communication and correcting the ill effects of miscommunication (system debugging). This, too, suggests that one wants the system to be built by as few minds as possible. Indeed, most experience with large programming systems shows that the brute-force approach is costly, slow, inefficient, and produces systems that are not conceptually integrated. OS/360, Exec 8, Scope 6600, Multics, TSS, SAGE, etc.—the list goes on and on.
The conclusion is simple: if a 200-man project has 25 managers who are the most competent and experienced programmers, fire the 175 troops and put the managers back to programming.

Jef zei

Dat zijn inderdaad straffe cijfers. In mijn (beperkte) ervaring zijn kleinere, gefocuste teams ook beter dan grote, logge projecten. En als je 25 projectmanagers nodig hebt, zou ik mij persoonlijk ook al vragen beginnen stellen ;-)

Bedankt voor je reactie!!

Anoniem zei

Individuele waardering vindt iedereen wel eens fijn. Wat in XP ?

zie Extreme Programming Perspectives

Chapter 16. Innovation and Sustainability with Gold Cards
"I am not a load factor—I am a free man."
—Julian Higman, Tim Mackinnon, Ivan Moore, and Duncan Pierce
Copyright © 2003, Julian Higman, Tim Mackinnon, Ivan Moore, and Duncan Pierce. All rights reserved.
An XP team delivers what the customer asks for and is collectively responsible for successful delivery. This can lead to two problems. The first is technical: There can be a lack of innovation because the customer does not necessarily explore options that are technically possible but not currently required. Consequently, cutting-edge knowledge may be slowly lost from the team. The second is personal: Team members may not feel that they have individual recognition, and managers may find it difficult to assign credit for individual contributions because of collective responsibility.
Perversely, both of these problems are more noticeable as the team becomes more experienced at executing the XP process. At Connextra, we have experienced this effect over the last two years and have successfully implemented a new practice called "Gold Cards" that addresses these issues. XP takes away the blame culture; Gold Cards promote a praise culture. Gold Cards allow developers time to explore technical possibilities in a controlled and focused way that leads to innovative stories that give team members a chance to be individually recognized. This has resulted in a noticeable increase in innovation and improved job satisfaction among developers.