I hosted one of the sessions…
Tom Renken
Embedded Software Team Lead
Viavi Solutions
My questions were:
How do you handle low performers in an organization?
Is it worth your time to try to improve them?
I generally defined a low performer as someone who doesn’t contribute a lot of checkins, code, design, passion for the job necessary to get a product to market successfully. It is basically the 3rd or lower choice for who you naturally go to when something important needs to happen…
My notes are paraphrasing what I heard these individuals say.. I don’t want to suggest that I have a perfect quote or understanding of their suggestions/comments.
Here are the notes…
John Willis from Docker mentioned for me to research:
- Red Bean Experiment from the Deming Institute
- Watch Andrew Shafer’s "There is no talent shortage" video on youtube.
- Look up devopsdays.org for more suggestions.
Curtis Yanko from Sonatype recommended:
- Figure out what motivates each member of your team. 1 size will not fit all.
- Give developers space to flourish
- Look into Servant Leadership
- Read "Lean Enterprise – How High Performance Organizations Innovate at Scale"
- Experimentation is a good thing. If things aren’t working, try something different.
Brian Dye questioned:
- what do you do about the "Brilliant Asshole"? The consensus was that they are team killers and should be removed from the team if necessary.
Camilla Tabis questioned:
- If you have ownership for something that can fail and it is important, how do you avoid demotivation when things break?
- She and others noted that developers are less likely to take on high risk or high profile items if there is no safety set in place for failure to occur.
I mentioned that I’m also always planning to experiment and measure to see if things improve. Others were generally in agreement. Some ideas I bounced on the group included:
- move the low performer to a different team that has a better culture/environment.
- pair the low performer with a high performer to see if high performance is contagious… The risk here is that it might be the opposite.
Then the bell rang.. Time up.
Feel free to follow up with me if you have additional comments/questions/suggestions.
Tom