The Theory of the Weakest Link
A chain is no stronger than its weakest link, and life is after all a chain. - William James
A chain is no stronger than its weakest link. Metaphorically, this applies to teams. But in actuality, this is simply not the case. Humans have not only tenacity, but the ability to countervail one another. This is a quality that inanimate objects simply do not possess. We can and will compensate for one another for the good of the team. Links in a chain are incapable of sharing their strength. No other link can compensate for the weakest.
The key is knowing how to compensate.
Applying Averages
Quantifying Ability
So perhaps the weakest link theory does not apply. But you can't argue with math, right? Quantify each team members ability, average them together, and you get the normalized ability of the team.
On a scale of 1 to 10 in some arbitrary (but extremely meaningful and accurate) quantitive skill measurement:
Name Ability Alex 7 Casey3 Chris 10 Jessie 4 Leslie 8 Logan2 Pat8
The Arithmetic Mean (Average) for the team is 6. Assume our scale is congruent with percentiles where 5 is average. We have a team that contains a clear prodigy and three above average individuals, yet the team's ability is barely above average.
Quantifying Delivery
I don't have a lot of respect for talent. Talent is genetic. It's what you do with it that counts. - Martin Ritt
This scale means nothing to us. Average ability? How does that map to work completed? Making it happen is where it's at, baby.
Let's assume for a second that our ability scale conveniently transfers to points per week completed.
Name Points/Week Alex 7 Casey3 Chris 10 Jessie 4 Leslie 8 Logan2 Pat8
Again, the Arithmetic Mean for the team is 6. Nothing changed. What's your point, Doc?
Fair enough. There is no difference. But wait, there's more!
Accounting for Counter-vailing
We discussed earlier in the theory of the weakest link that man is capable of compensating for one another, thereby raising the strength of the weakest point in the group. Something a chain can never do. And this is a beautiful characteristic. But is it enough? And how does it work?
To be fair, we should assume that in covering for someone else, we diminish our own performance. If I assist you in completing a point, I sacrifice some of my own delivery rate. While I can certainly work a few extra hours to make it up, that pace is not sustainable.
We adjust the points per week. Our top performer is now our team lead. The top performer contributes two points to the others and our other high performers provide one each. The new scale looks like this:
Name Points/Week Alex 6 Casey5 Chris8 Jessie 5 Leslie 7 Logan4 Pat7
And our average for the team is still 6.
This sure would be swell, Wally. But their just ain't no way. I think something is wrong with the Beaver....
If we are pairing people up and one of the members has to effectively carry the other, there has to be some loss of velocity. If, however, we don't pair, we end up with a lot of re-work and lower performers stay lower performers for much longer. If you are in the camp who believes pairing is a bad practice, you will likely find significant ammunition in this article. I, however, do believe pairing is a fantastic practice. The dividends of pairing are significant and outside the scope of this article.
Getting the math right
Each developer is capable of completing a single point in some period of time. We can extrapolate that to points per week. When two developers share the work, we average the rates together. But now we have an interesting twist. We are trying to determine how long it will take these two developers to complete a single point, assuming they evenly share the load of that point between the two of them. This average is not determined by Arithmetic Mean, but by Harmonic Mean.
Digression into Harmonic Mean
Let me see if I can explain this.
You drive from your home to the store, which is exactly one mile, in exactly 4 minutes.
1 mile in 4 minutes is .25 miles per minute, which is 15 miles per hour.
You drove to the store at 15 miles per hour.
You return from the store along the exact same route, but this time it takes exactly 3 minutes.
1 mile in 3 minutes is .333 miles per minute, which is 20 miles per hour.
You drove back home at 20 miles per hour.
For the complete round trip, you drove 2 miles in 7 minutes.
2 miles in 7 minutes is .2857 miles per minute, which is 17.143 miles per hour.
Your average speed is not 17.5 miles/hour, but 17.143 miles/hour.
Back to our developers
This applies similarly to our developers.
Chris delivers one point in .5 days, which is 10 points/week.
Logan delivers one point in 2.5 days, which is 2 points/week.
Together, they complete 2 points in 3 days, which is 3.33 points/week.
As long as Chris and Logan are paired with Chris compensating for Logan as opposed to each of them augmenting the other, their average rate is 3.33 points/week. So we drop one of them from the Arithmetic Mean calculation.
So what does this do?
Name Points/Week Alex 7 Casey4 Chris 3.33 Jessie 4 Leslie 7 Pat7
The average for the team is now 5.39
Harmonic Mean is a Bitch
Harmonic mean lessens the impact of higher outliers, while emphasizing the impact of the lower numbers, especially as compared to Arithmetic Mean. So Harmonic mean favors the lower numbers. If this is true, doesn't it make more sense to have one of our slightly above average developers help train Logan instead?
Let's ask Alex to do it.
Alex can complete 1 point in 1.4 days.
Logan can complete 1 point in 2.5 days.
Together they complete 2 points in 3.9 days.
They have an average of 2.56 points/week.
Name Points/Week Alex2.56 Casey4 Chris 10 Jessie 4 Leslie 7 Pat7
The average for the team is now 5.76
It does make more sense to have Alex pair with Logan. Theoretically, we could improve even more if we ask Casey or Jessie to pair with Logan. But now we are pairing all of our lesser performers together. Probably not a good idea.
Work Together
While my explanation may be a bit complex, my point is simple. You get a better return when everyone on the team pitches in and helps out. And you get a better return if you focus on pulling up the bottom numbers without significantly dropping the top numbers.
I am not advocating that you should only hire "top performers". If you do not grow your team from within, you fail to establish a sense of connection and purpose. And you set yourself up for huge salaries, huge egos, and ultimately high turn-over.
I am not suggesting you should silo your top performers and do not allow anyone to "bother" them. Not only will you have ego issues, but you will have established a cast class for the developers that will be difficult to break out of.
Most organizations take the top performers and put them in leadership roles where they are able to mentor and guide others. A single performer is expected to assist the entire team. Inevitably, those who require the most assistance, get it. We see an improvement as we pull the bottom up, but it is not nearly as significant an improvement as when each level pulls the one beneath it.
Don't blindly put your top performer in charge of the team. Odds are, they will not enjoy the role and your return will be less than optimal. Have the team work together. Encourage pairs with low performance disparity. Make sure your best performers pair with the next level down and so on.