Wednesday, June 15, 2016
I hosted one of the sessions...
Embedded Software Team Lead
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.
- 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.
- 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.
- 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.
- 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.