I have just received an email from an old friend. His update on work went something like this: my company (small, successful) has merged with another (large, failing) company. The outcome of negotiations is that the new company will be run by the executive team from the larger, failed company and according to their business model which has served them “so well these last few years”!
Pamela's response to this story was to recount how many times she had seen failure rewarded by promotion. That got me thinking.
In the early nineties I worked on a very large (more than 1000 man-years) IT project. I was contracted to IBM who ran the whole project, integrating various client companies and lots of independent contractors such as me. I really enjoyed the project: it was technically challenging, the IBM Laboratory at Hursley was a great place to work and I made some good friends there, particularly Gymnasium Jim.
Inevitably there were problems and delays. A key difficulty was to do with the sheer complexity of what we were trying to do. (The Agile development methodologies that emerged later were a direct response to these kinds of developmental problems.) I have worked on several very large projects and inevitably each becomes more and more complicated until they are just plain unstable.
Well, we hit that point on this project, just before we were supposed to make a nice clean delivery of code. Now, for that code to be delivered each software developer had to sign off on his or her bit, stating that it worked. But the problem was that many of the interlocking bits did not work. So what did the IBM senior project manager (lets call him 'Christian') do? He went round and instructed the developers to sign off their code, even though they knew it did not work. There would be some flack from the client when the code failed during testing, but so what? They were over a barrel and it would just mean more (re-)work for IBM (and thus more money from a captive client).
Years later, when I was Managing Director of Valtech I had an excellent team of guys (led by 'the bloke from Stoke') helping IBM with the technical parts of a large IT project. The team used to tell me how IBM kept instructing their developers to promote and sign off on code, even though they knew it was not ready. Now here is an interesting thing, the boss of IBM on site was none other than poor old Christian, who had been promoted in the mean time. There he was, still trying to push it uphill.
Christian's story is a common one, most people in large organisations are familiar with the standard response to corporate failure: blame the innocent, reward the guilty, announce a success and continue in the same old way. But why is this so common? What is going on? Why don't we learn?
You see, deep down, we resist learning. There is an emotional component to learning something really new (as against more of the same) which means it hurts. The pain comes because we are attached to our present state.
Learning means we have to change. Change means letting go of old, familiar ways of doing and being. Change means embracing the unknown. You will be different after you have learned something.
If it has not hurt, you have probably not learnt. It is difficult enough when you are the one doing the learning, but if you are trying to help someone else change – stand back from the fan!
Learning involves reflection and takes time, but our corporate and social compulsion to 'do' gets in the way. We have to deliver more and more, to work harder and harder, for longer and longer hours. We don't have time to reflect, and even if we do our colleagues probably don't have time to listen.
People who want to learn, who want to understand, tend to ask awkward questions, they make us feel uncomfortable. We reward those around us who do not learn because they let us feel comfortable, they do not challenge us.
Christian will probably be rewarded and retire after a long and 'successful' career with IBM, but the sad thing is that he may never have learned anything of any real importance.