Following the Enron and Worldcom scandals of a decade or so ago, we might have been excused of thinking that a new era of more authentic, honest and open leadership would beckon.  Unfortunately, the last few years have demonstrated that no industry, or walk of life, is immune from deep-rooted dubious leadership.  One simply has to mention politics (expenses scandals), journalism (the Levenson inquiry), banking (sub-prime lending) and pharmaceuticals (drug use fraud) to reinforce the breadth and depth of the malaise.

There is clearly no single, or simple, answer to what is a serious global leadership problem, but one particular story in recent weeks highlighted to me an area where leaders could at least make a start on recovering some of the confidence and trust that will take a long time to regain.  I am talking about those two pillars of leadership – responsibility and accountability.

I was dismayed to hear the statements coming out from Stephen Hester, the chief executive of RBS, last week, following the serious systems outage that caused so much concern, inconvenience and, in some cases, hardship to so many customers. After several days of uncertainty as to when the problem would be resolved, during which various spokes-people provided updates and assurances that everything was being done to bring the systems back, Mr. Hester appeared in front of the cameras, and described the problem as a software ‘glitch’. Oh dear!  This was, in my view, a complete abrogation of responsibility and accountabilty, and an insult to so many people’s intelligence.  (see attached for the anger that such simplistic responses can stir up).

One does not need to be fully aware of the precise details of the software or technology issues that RBS faced to know that dismissing the issue as a ‘glitch’ is to miss so many points about the important role of leadership.

From my experience of the IT industry, all technology & software problems can be tracked back to a failure of leadership at one level or other.

• Who took the final decisions on how the software upgrade was to be implemented?
• Who looked at the risk analysis and made decisions about back-ups, back-out plans, the operational window for the upgrade, the resources to be put into testing before going live?
• Going back further in the timeline, where did the buck stop on decisions made about which technology to run with? Were compromises made, and technical advice dismissed on the basis of cost?
• Were any other (more costly perhaps) recommendations by the front-line operational teams overruled by the executive team?
• Is the culture within the organisation one where technicians and software engineering team leaders are encouraged and empowered to speak up and warn that things may go wrong?
• Or are they living in a climate of fear for their jobs, resulting in them keeping their heads down, even if they are worried about some aspect of deployment procedure?
• Was the upgrade managed by outsourced staff or contractors, perhaps with less intimate knowledge of the complexities of legacy system interfaces? Who made the decision to outsource and lay off in-house IT people to save costs?

Whatever, the answers to these, and many more questions that could be asked in a post-implementation review, the issue is that Continue reading →