The Best and the Worst CEO for Computerization

It is often the CEO who makes the difference between success and failure of a software driven transformation.

In my long career as head of IT and implementing software projects within companies, I have come across a variety of CEOs – some of them who were excellent change managers and others who were not. So, I classify all CEOs into 2 major categories – those who understand computerisation (not computers) and those who don’t. Understanding computerization for a CEO means understanding the psychology of change brought about by automation. How well he understands this determines the success or failure of software projects.

Whenever I speak of the role of CEOs or top managers, I always remember this COO who was the best CXO I have worked with in my career – the best at least from computerization point of view. His name was Mr S C Jolly and he was the head of Sarawati Sugar Mill in Yamuna Nagar, (a group company of the Saraswati group consisting of Sugar mill, heavy engineering unit, etc. where I worked as their Group IT Head). It was my first job as a IT Head with only 4.5 years of prior work experience, and I set up the entire IT department and was higly successful in developing and implementing complex applications (see success stories published in Computers Today and Times of India at http://pukamble.tripod.com/ct1frame.htm and http://pukamble.tripod.com/TOIframe.htm). Mr Jolly is the best IT enabler I have come across in 28 years of my IT career and 24 years as head of IT/Software). I hope Mr Jolly reads this. Anyone who knows him may please convey my feelings of appreciation for him. The last time I was in touch with him he was living a retired life in Delhi.

And what was it that he did best to enable successful automation? You will be surprised to know – the best thing that he did was that HE DID NOT REACT. He was so balanced that he did not react to complaints as they came in. I was just 29 – 30 years young manager but I used to chat with him in his office and he oftern shared with me some of his wisdom. He said that he received several complaints about computerization. Some of the users were fed up and frustrated. What was different about him (which I have rarely seen in many CXO’s I have worked with later) is that he did not immediately start blaming the computer department. He said that their frustration and complaints were not a result of any problem with technology or the tech department – they were a result of their reaction to change.

Let me paint the following scenario of an incident to illustrate what I said.

I had completed the automation of a very complex application very successfully (as the users were very cooperative and mature). I then started the automation of the most common and relatively simple application – payroll. But I was having great difficulty in implementing the system. The HR/Admin manager was simply not able to go live with the application. As is my style, I first tried hard to convince him and persuade him. But when I failed, I set up a meeting with the COO, Mr Jolly. The HR manager had several complaints on the system and lot of master data preparation was pending. And following is the scene at the meeting.

There I am sitting in front of the COO’s desk – a clean big table with just one Economic Times lying in one corner. By my side is the HR Manager – both of us facing the COO. And the Manager beside me starts off by cursing the system, fretting and fuming and blaming the system in no uncertain terms. “Our neighboring company has been using Payroll for years and they do not face any such problems. We just don’t know how to do it…”

The COO quitely listens to all that is being said. There is no reaction whatsoever and no expression on his face. He patiently waits for the manager to finish blurting out what he has to. When the manager is finished with his story, the COO – completely unmoved by all that was said and with no emotions on his face – asks what were the next steps. He reviews the steps to be taken, sets targets for master data correction (which was the primary reason for all problems) and closes the meeting.

And believe me, it worked wonders.

Later one day he gave me his words of wisdom, “The HR Manager was reacting as he did not because there is anything wrong with the system, but he is uneasy under the impact of change. The frustration, anger, complaints have nothing to do with the causes that the managers state. They themselves do not know that it is their reaction to change and has no relation with the issues that they complain about. But I give them a patient hearing just to allow them to let off steam.”

I have not heard wiser words than these from any CXO in over 20 years of my career after this incident. I have suffered from some of the worst CXO’s too – there were some who would believe the first guy who went and complained about computerization. And hell would fall on IT.

Technorati Tags: ,,,,

Challenges of being an in-house IT Head

Recently, as a head of in-house Applications Software group, I was asked a few questions related to my job. Given here are the questions and my responses.

clip_image001 Managing large scale software development, implementation and operations, can you give a gist of key challenges and how do you approach your implementations?

Everybody thinks that computers are smart and can do anything. But we, as software professionals, alone know that under the hood we are harboring a dumb, adamant and yet most powerful creature in the world (the computer) which can bring your world crashing with the silliest of mistakes. Computer software is like a glass house which needs to be handled with extreme care. A small change in a comma or a full-stop in a million-line code can crash the system or lead to completely erroneous results. For this dumb and powerful guy called computer to be faithfully serving you right, you need to have a very disciplined process where not even a small mistake is allowed. Now since the world has a very different image about computers, you run a great risk of being completely misunderstood and sometimes hated for your “over cautious and strange ways”. The big challenge for the IT guy is to continue to do the right things in the best interest of the company, even if people misunderstand you and you have to be the “bad guy”. In other words, you cannot be a nice guy and do the right things for your company.

………………………………………………………………………………………………………………………………………………

clip_image001[1] How does business and software development unit collaborate?

Software development and implementation is a very collaborative activity and needs perfect teamwork between the business and IT. The IT person who programs the computer does not know the business process and the business expert who knows the process does not know how to speak to the computer. In such a scenario, it is imperative that both collaborate and create automated processes. It is like two people doing rock-climbing, where both reach new heights by pulling and supporting each other. Having developed and implemented several solutions which are being used successfully by several internal customers, in itself, is a proof of the collaboration.

………………………………………………………………………………………………………………………………………………

clip_image001[3] What do think are the biggest challenge in a internal software development scenario?

Having worked both in internal software development scenario and also in software companies, I can say that internal software development scenario needs very specialized skills which are very different from what a software development company needs. It is a great balancing act between the pressures of your internal customers, senior management expectations, the dumb guy that is computer (as I explained above) and your own staff members who are ready to quit and join a software company at the drop of a hat.

Developing software in the confines of the computer department is relatively easier part of the job. The real challenge comes in implementations when you want to make the software work in the heated environment of personal preferences, attitudes, interests and fears. The people issues of implementation are unique to internal development scenarios which software companies rarely experience. Making it work and sustaining continued error free operation is the challenge only in internal IT.