My career began in the shipbuilding industry. It was the early 1980s, and I joined a shipyard along with nine other engineering graduates. I spent the first two years on the shop floor as a "fitter's mate" in order to complete my training to become a chartered engineer. During this time I learned little about engineering, but a lot about people, industrial relations and shop-floor survival tactics.
Following my stint on the shop floor I went into the planning department, and quickly became involved with putting computers on the shop floor for the first time. I ended up managing two major projects.
The first was a manufacturing control system, which I named Comics (Computer Oriented Manufacturing Information and Control System) and the second was an access-control system whereby entry to and exit from the shipyard could only be gained through a bank of 20 computer-controlled turnstiles.
At this point in my career I was unaware of all the potential problems normally associated with such ground-breaking projects. I was also unaware of the stages a computing project should go through, the development life-cycle and development methodologies. At the time, there were not any IT textbooks to help or guide me.
I therefore operated purely on instinct, gut feel and basic common sense. And yet both projects were a huge success. I cannot claim they went in on time, to budget or as specified, since there was no budget, plan or detailed specification.
However, the systems worked, they fulfilled the business imperatives, the workforce liked them and the unions were content. Over my stay at the firms I was promoted three times, my salary doubled and I became the youngest manager in the history of the shipyard.
As my career progressed, I learned how to manage projects and develop systems "properly". It was at this point in my career that things started to go downhill. Do not get me wrong: I never did a bad job, but I could never recapture my early successes. The question is: why?
By now I was a fully fledged member of the IT community and had moved to the finance sector where money was more plentiful. I was sent on training courses, learned about methodologies, processes, procedures and project management. I watched my peers and bosses, learned from them and tried to emulate their behaviour.
However, I had forgotten what came naturally to me: the people side, networking and building relationships. During the early part of my career I had naturally - for me, that is - focused on building relationships with people. I did this throughout my two-year stint on the shop floor.
Later, when I talked to the people on the shop floor and to the unions, they trusted me. When I told them IT would not threaten their jobs but would ease the more mundane aspects they believed me, and willingly helped my projects happen.
Understand the user community
During the middle years of my career I learned to consider the time I had spent on relationship building a luxury rather than a necessity. I therefore stopped doing it because I did not feel I had the time I felt that I should be concentrating on "work". Lunch breaks became a snatched sandwich while catching up on my e-mail rather than dining with, talking to and getting to know my user community and business peers.
I have now re-qualified as a psychologist and have reflected on where I went wrong. I now understand how I ignored a natural and important talent - that of relationship building.
I have recently embarked on a study of IT professionals who have progressed beyond the ranks of IT and made it to the position of CEO. Such individuals told me that they spent 50% of their time networking and relationship building while they were in that top IT role.
In hindsight, I should have handled my middle career years very differently. As one of the CEOs in my study so succinctly put it, "IT leadership is about getting the best out of people, not about building processes and procedures." If only I could have my time again
This was first published in November 2007