Prelude…

I have been back blogging for a few days, so it is well past time for a rock climbing-related post. Though this site being what it is, I’ve twisted this thought round to apply to the world of IT.

Living in London, real rock is always a reasonably lengthy drive away, but in normal circumstances I would train indoors at least twice, and normally three times, a week and climb outdoors as often as possible. However, for a variety of reasons (including an ankle injury to myself, a chronic shoulder injury to my partner and both having an awful lot of other things on), I have not been climbing very much for several months. About a month ago, my partner and I decided to make a point of once more getting to the wall at least once a week. The problem is that, after a lay-off, your mind can remember climbing at a certain level but your body is way off the pace.

A combination of keenness, a desire to make up for lost time, pride and pig-headedness often sees a climber who is returning from injury quickly try to get back on to the level of routes/problems that they were achieving before. My limit, both indoors and out, used to be around V4 (fairly low down on the overall scale of climbing), with the occasional V5 indoors only. Having a few tentatively successful sessions under my belt, I found an indoor V5 that played to my strengths and was making some progress on it. It was a bit fingery and required use of a technique called crimping (see the image below):

This is a very effective way of getting purchase on small holds, but puts a lot of pressure on your fingers. Levering my body up from sitting on the ground with both hands crimping like mad I felt a sort of crunching in the ring finger of my left hand. I stopped my attempt and decided that I would warm down on some easier stuff. Sadly even easier stuff can be quite demanding on the fingers and on my next but one climb I ended up pulling quite hard on the same left hand. There was a very audible pop, my left hand exploded off of the hold and I found myself on the floor holding my swollen finger in quite some pain.

After intensive icing at the wall and some therapeutic treatment in the four or so weeks since, I am still able to bend the finger (so hopefully do not have a full rupture of the tendon), but am a long way off of going back to climbing. I also have an unhelpful mental image of the tendon hanging by a thread, it is going to take quite some time for me to get over this; even if the finger itself heals.

It doesn’t help that I fully ruptured the same tendon in my right ring finger when playing rugby as a teenager (see above). I can’t bend the top section of that finger and it has been a bit of an issue for me when climbing on occasion.

Professional climber Tommy Caldwell (above) cut off one of his fingers in a DIY accident and still climbs to an astonishingly high level, so I can’t complain too much about this earlier injury. However I am now rather concerned about having matching tendon problems on both hands. I guess time will tell how serious this new injury is and what level of recovery I will experience. I hope to be able to avoid surgery, which is in any case no guarantee of a cure.

One of the most frustrating aspects of all this is that I feel as if I had a warning with the initial crunchiness, I chose to ignore this, which then led to the more serious injury. I guess it rather feels that I could have avoided getting myself in this situation with a little more thought.

The learning here is twofold: specifically how easy it is to injure yourself when returning from a lay-off; and generally that it is also much too tempting to try things that you are not yet ready for – to run before you can walk. The first lesson applies to climbing and sport in general, the second has wider applicability and some pertinence to the work of IT in particular.
 
 
…and Fugue

Running before you can walk seems to be something that particularly afflicts IT departments and IT people when they are in a bit of a hole already. If an IT department has been under-performing, or has become semi-detached from the business (the latter often leading to the former), there can be a desperate desire to get onto firmer ground quickly. I have seen this manifest itself in a couple of ways:

1. An overwhelming urge to do something that will be appreciated by the business and make a difference – here the desire is for a quick redemption, unfortunately the concomitant rushing and even omission of key steps in the development process are just as likely to lead to more business disappointment and an increasingly tarnished reputation.
2. The second symptom is virtually antipodal to the first; an unhealthy clinging to formal methodologies, or (much worse) an attempt to introduce new and improved ones – this can have almost a totemic quality, as if by simply adhering to ISO 9000 / Agile / ITIL / RAD (delete as appropriate) things will miraculously turn around.

Unfortunately both of these extremes are essentially displacement activities. I have led the turn-around of a number of IT teams. In my experience, what is generally required is a heavy dose of pragmatism and a focus on doing the basics well and without any elaboration whatsoever. It is nearly always best to try to fix the existing machine, or at most to tinker with it slightly in the first instance, rather than to make drastic modifications or try to build a new machine in entirety.

When IT is under-performing it is not normally a case of absent or ill-adhered to formal procedures. Rather the malaise is more likely to be a human one, relating to a lack of leadership and direction, a consequent lack of motivation and a group that begins to spiral in on itself. If the problem is essentially with people, then the solution often lies with them as well. It is not easy to motivate demotivated people, it is not easy to provide direction to those who are lost. However both of these things are easier to do than relying on the same lost and demotivated people to either make lighting fast redemptive deliveries, or to cheerfully adopt a new and fool-proof development methodology.

If a formal methodology is important – and it generally is – then my recommendation is to implement this once you have put a lot of effort into creating a happier and better functioning IT team. It is a bit like the old adage about not outsourcing a problem. Best practice instead is to resolve the issues and only then outsource a functioning process.

It is worth also saying that, as well as being more effective, working to make your team happier and more functional is a lot more rewarding and a lot more fun. If you achieve this it is amazing how much more easily the successful system deliveries start to flow.
 
 
Coda

In business, as in rock climbing, if you try to run before you can walk, try to jump to the desired end-state without putting in the necessary hard work, then you are only likely to get hurt. If you don’t believe me, I can tell you all about my finger injury again.