Posted on 22 December 2004 under Management

When eight year olds play soccer (football) something interesting happens. Both teams form a giant rolling pack of random legs from which, occasionally, the ball will emerge only to be recaptured a few seconds later. I’m being a little bit unfair. The goalkeepers do stand in their goals looking forlornly at the pack as it winds its way around the field. I wonder if psychological evaluations are needed to identify the kids who are least likely to crack and run into the pack rather than stand alone between the posts?

What does this have to do with companies and projects? I’m glad you asked. I often wonder if some managers don’t need psychological evaluations to see if they think that behaving in a similar manner makes sense.

Lets see - is there a crack team that is rotated into and out of projects to fix them when they are going wrong? Do projects get temporarily abandoned so that everyone can work on the current most important project? Have you seen these things happen? I sure have.

The crack team and learned helplessness
If projects can’t get done without a crack team of staff to fix things then I’d say (with no TOC expertise) that you have a pretty obvious constraint to the number of projects that can be done at one time. There are other problems - how do you think it feels to be one of the people who are underskilled, undertrained, underexperienced or undertalented and so are pushed aside while the crack team comes in to fix things? Pretty bad. Demoralizing. Insulting. “Why bother trying since were so bad?” “Those crack team guys will come and fix things anyway…”

Basically, a culture of learned helplessness is created. Everyone in the company begins to believe that the only way things can really happen is when the crack team is put on the case. It is self-fulfilling. As those excluded from the crack team see more and more reinforcement of the need for the crack team to fix their problems (or the problems of other teams) they can’t help but see themselves as somewhat incapable and inferior. This leads them to act in ways that are somewhat incapable and inferior.

Many of the practical day-to-day skills needed for software development are best learnt on the job from peers. If the crack team approach is used by a company then the crack team will get better and better since they are continually work with quality peers. Naturally, the remainder of the company doesn’t get this benefit - since they get to work with the leftovers - people who don’t have great skills to pass on and they have a mindset that leads them to believe that the skills their peers have aren’t actually very worthwhile (otherwise their peers would be in the crack team).

If you can do something about it - then start to wean your company off crack teams as soon as you can. Of course there will occasions when skills need to be imported into a project to help. But just as there is a difference between scratching your bum and tearing yourself a new one there is a difference between a couple of people helping out and a bunch of people taking over. Helping is good, teaching those being helped is better. Taking over is bad. Avoid wasting the talents of those not in the crack team. Split the crack team up amongst all projects. Your overall throughput will probably go up. Sack those people who weren’t in the crack team and who can’t or won’t perform. Give everyone in your company the opportunity to learn from your best and to be their best. I promise that you will be surprised.

I’ll come back to the “serial abandonment of projects to help the currently most important project” in a later post. Think of this as an end of season finale, will Michael be able to write coherently (ever)? Will it seem at all related? Will the post ever get done? Will new verbs and nouns be employed without anyone acknowledging it? Stay tuned…