Wednesday, November 9, 2016
Tuesday, November 8, 2016
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.
Tuesday, June 14, 2016
Wednesday, March 9, 2016
Tuesday, March 8, 2016
In the Shu-Ha-Ri paradigm, how to get to Ri level quickly? By let your brain do what it does best: pattern matching, i.e. absorbing knowledge by the unconscious part of the brain (like a child learns a language) and make it instinctive so one doesn't have to think much, sparing our limited cognitive resources for what really matters.
Kathy Sierra - Making badass developers
Robert Greene - Mastery
Sandro Mancuso - The Software Craftman