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