The Gorilla Process Conundrum

November 17, 2014

There is a story that is told to show us how we all behave stupidly in corporations

  1. Place five gorillas in an outdoor cage in a cold, windswept location.
  2. Suspend a banana in the cage above a ladder.
  3. When any gorilla attempts to use the ladder, soak all five gorillas with a fire-hose.
  4. Repeat until they avoid the ladder. After a short period of avoidance, replace one gorilla.
  5. Note that when the new gorilla attempts to use the ladder, the other gorillas will beat him up. Take the fire-hose away.
  6. Repeat step 4 until all original gorillas have been replaced.
  7. Note that at this point, no gorillas use the ladder, any that try are beaten up, and none of them knows why.

…and aren’t the gorillas all stupid and everything for being unpleasant to each other for no reason.

The cheeky bit in this story is that little bit at the end of step 5: we know the fire-hose has been taken away but the gorillas don’t. People who have more information than others should not feel they are being clever, or the others are being stupid, when the difference is merely who has been told what.

If we keep the fire-hose with intent to use it, then the moral of the story becomes very different: the gorillas as a group are behaving in a way that keeps them dry even if they don’t know why.

Which is one use of process. We can follow process without requiring deep understanding, and that means in practice we can quickly learn ways of working usefully before finding out why it’s better to work that way. Once we know the work and the team well enough, then we can – and should – challenge poorly understood process.

That is, there are of course problems with simply accepting process or traditional practice, but there are also problems with letting every new gorilla climb the ladder to find out for himself: it takes time, and everyone gets wet and cold and miserable.

Many skilful tasks can be reduced to a checklist for routine use. For example, deploying webapps to Weblogic can become a routine task and there is no need (or wish!) for a skilled Weblogic guru to do this simple task when it can be written on a list and given to ‘junior’, cheaper staff, leaving the expert to work on other things.

Having a check list improves organisation capability and reduces effort. Coders whose attention is on building applications to solve difficult business problems can work from that checklist to to deploy their work themselves, without also having to learn the quirks of this particular web container or wait on the expert The checklist will tend to be written for simplicity and readability, so may contain some redundant or long-way-around methods. As odd problems arise, extra steps may be introduced (such as routinely restarting the container) that are not strictly necessary. It is not the ‘correct’ way to deploy, but a pragmatic one.

The list can be distributed without the expert which can be useful for quickly gaining capability, or can cause failures where they are not appropriate and people have referred to the list rather than look up an expert for their particular problem. The expert might leave out of boredom when all the challenging setup work has been done, or be ‘leaned out’. In both these cases we now have a checklist, or process, without the expertise to monitor it or review it. Workarounds are added by ill-informed rumour and the process gains warts and weights. Business needs change and the tools change, and process users attempt to shoe-horn them into the process, because there is no-one around to review it, or even authorise change to it – or worse, there may be people around whose job it is to enforce use of it, without understanding it.

Discarding process at any excuse is also not helpful as people then continuously relearn tasks, and the mistakes of the past, to a depth that exposes the reasons why the discarded process is the way it was.

So where then is the happy medium? An organisation should be willing to challenge process by the users of that process. It should have, ‘close’ to that process, experts who can carry out the technical arbitration when process users want different things from it. And the risk holders must be aware that not changing a process might be more harmful than changing it.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: