Creating the High Performance Team, Continued…
Pareto -- Finding Your High Performers
In an earlier post, I discussed the use of the Pareto Principal or 80:20 rule in a variety of technical situations. One I lightly touched on was applying Pareto to your teams to find identify the top 20% of your team that was contributing to roughly 80% of your work. I continue to struggle with this notion as a leader. I want to subscribe to standard views that team performance follows a more balanced distribution and that my role as a leader is to be constantly improving my overall team.
I do subscribe to this somewhat. However, I've come to the conclusion that it doesn't truly recognize, acknowledge and grow the true stars in your team -- your top performers. You spend so much time working with everyone to improve that you can easily forget your strongest and best engineers. And top performers come in a variety of flavors, depending on the situation, so don't think this has to be an exclusive club.
For example:
- Find the most productive coders on your team. Those who can really be creative and churn out code when it counts
- Find the best toolsmiths on your team. Those who are familiar with a wide variety of scripting languages and tools and are very good at solving problems with these tools
- Find the best debuggers or unit testers on your team. In my opinion, these folks are gems when you're getting close to a delivery point
- Find the best testers and system thinkers on your team. Those who gravitate to customer intimacy and just love finding juicy bugs
- You get the point
And this list extends to designers, reviewers, architects, etc. High performance isn't a one size qualifier. You need to map it to your project domain and skill requirements. Then analyze your team from these perspectives and truly understand your top performers and strength areas. Then get better!
Setting up Mentoring Relationships
Another valuable practice within teams is setting up mentoring relationships that help improve the team while not draining your overall performance. Again, having data insights into the nuance of your teams' performance can help you to determine who are the "good pairs" and who are not.
One way to do this is to monitor Active Time performance levels. Let's say you assign a senior developer to mentor a junior team member, but you notice the senior developer's weekly Active Time drops by 50%. You should at least investigate why and perhaps consider a pair change or some other route to achieve better performance for the junior developer.
You can also extend this concept to Agile Pair-Programming! With 6th Sense there is finally a technique where you could really measure the true effectiveness of your pairings and make adjustments as required.
Wrap-up
I don't want this post to seem too harsh. Team leadership and performance needs to have an experienced, subtle and light-hand applied in order to be effective. While I love George C. Scott's interpretation of Patton, I don't think he would make a very good software team leader.
I want to wrap-up this post with a few links to similar thoughts. At the very least, please read the Joel on Software reference.
- http://www.joelonsoftware.com/articles/HighNotes.html
- http://arneyconsulting.blogspot.com/2005/06/...
- http://blog.tomevslin.com/2006/05/why_a_great_pro.html
If there is a theme to this post for leaders, it's two-fold. Use data-driven analysis to understand the strengths and performance dynamics of your teams. Then, focusing on strengths, amplify your teams' abilities to truly create a high performance team.
If you want to measure how well you've taken this to heart, take a look at your annual reviews. You should notice a distinct change that is data-driven and strength focused -- to the tune of 80:20. You'll be amazed at the difference!
Previous Post:
Creating the High Performance Team
Next Post:
Dana Gardner on 6th Sense Analytics
