The 60-30-10 principle

The general idea is that teams perform better than individuals. Nuance, good teams perform better than individuals. Small teams could suffer from lack of ideas. Large teams suffer from too much communication (or not enough). Both have a negative impact on productivity.

Organizations frequently use the following process for creating teams; “John, Frank, Emma, Erik and Lisa. You are now a team!” Chances are these members were between projects and available (great criterion!). Esther Derby taught me an alternative solution for creating teams. She wrote an excellent article about it, which I recommend reading.

The most valuable lesson from that article is the awareness of the 60-30-10 principle.

  • 60% of the variation in team effectiveness is attributable to the design of the team,
  • 30% to the way the team is launched,
  • 10% to leader coaching once the team is underway.

That means 90% of the team’s fate is determined before they have done any work. 90% (!), that’s a lot.

Let’s think about that. This makes sense. Suppose I would be the coach of FC Barcelona, I’m pretty sure the team will (still) win most of their games. Why?

  • 60% à The team is well designed, they have and almost unbeatable midfield (Iniesta, Xavi, Busquets) and some of the best strikers in the world (Messie, Neymar).
  • 30% à The team always plays the same system, they know what is expected.
  • 10% à They had a great coach Josep Guardiola, and have now a (my opinion) lesser skilled coach: Geradro Martino. But this hardly influences their result.

Making a team yell is a challenging and difficult task. Invest your time and effort wisely.

Why bother testing?

Working in the world of software, ensures me to frequently reread Weinberg’s Perfect Software and Other Illusions about Testing to get myself a sanity check. The book starts with 2 questions;

1. Would you test the program before investing every penny you’ve saved based on it’s investment-strategy advice? (IF answer = NO……don’t read any further)
2. Would you test the program if someone else had written te program?

Well, good questions. Recently Mt Gox, the third-biggest bitcoin exchange in the world, revealed a bug which made Bitcoin drop 20% in price. (ouch)

Well so far for perfect thinking and perfect software. Okay you can’t test everything, we know that. This week one of my IT suppliers wrote an e-mail to the team;

———————————-

Hi all,

Although it was not explicitly requested by you, we want to provide the latest Software version, since it contains in our point of view important technical patches that will positively affect stability and performance. We strongly recommend to test and install it on P as soon as possible. The patch including installation instructions you can download at the usual place.

Regards James

———————————

not explicitly requested….?…..excuse me…not requested, just discussed. No worries, let’s find some information about the quality of the latest version.

———————————

Hi James,

Do you have your testscripts and results of patch 1.3.182 for us? Based on that we can determine the teststrategy on our side. Regards, Frank

———————————

Hi Frank,

Unfortunately, we don´t, because the improvements were of technical nature. Therefore, we “only” executed module tests this time.

Best regards, James

———————————

Hmmm, an intresting collection of facts in only 3 short emails. Perhaps I should send a copy of Perfect Software or this blogpost to my IT supplier 🙂