Moving out of the comfort zone can put your career back in your hands

Glenn Martin tells how moving to a challenging new role gave him greater control, but warns that being too protective of your staff can hinder project success


Back in 2001, I was five years into my role as CIO of Citigroup’s European investment banking operation, and the IT team I headed had just won an industry award.

Citigroup is the largest financial services organisation in the world, and I was feeling proud of the successful programme of change my team had overseen in the previous 12 months, following a succession of takeovers.

It was not an obvious time to move on, but I received an approach from Cazenove, the privately owned UK stockbroker, and went along with an open mind.

After some initial meetings, I was intrigued. I liked the people I had met at Cazenove, but it was not clearly a better prospect. After all, why leave the largest financial services firm in the world and my hugely talented colleagues there for a far smaller UK operation – and one that was mired, at that time, in old technology?

I drew up a detailed decision matrix to reach a verdict – and it came out narrowly in favour of making the change, principally for the huge challenge that looked likely to await me.

It proved the best professional decision I ever made. At that time, Cazenove was preparing for a public listing, and the need for better IT had rapidly risen to the top of the agenda.

Cazenove’s chief executive, Robert Pickering, was a man I decided from the beginning I could trust, and that proved a good call. He gave me the freedom and the support I needed to take on the massive programme of IT investment that Cazenove needed – and to make a real difference.

But hadn’t I had the same freedoms at Citigroup? I would say that one of the odd things about a regional CIO role in a global organisation is that it looks very powerful, but in reality you are quite constrained.

The US banks, in particular, keep their command and control centres in the US, and that was true of Citigroup. Back in 1996, when I originally joined what was then Salomons, there was a fair degree of autonomy, but that became less once Citigroup became established.

As CIO, my role became far more administrative and far less dynamic. I was no longer calling the shots.

This is all with the benefit of hindsight, of course. It is working for Cazenove that has given me that perspective on my time at Citigroup.

But that is not to say that all was rosy in the Cazenove garden from the outset. To be frank, when I joined them I found even bigger problems than I had imagined. Their IT services were poor, while costs were off the chart and rising. The reputation of IT was terrible – and for understandable reasons. If you are providing a poor service at high cost then you will not win any popularity awards.

Would I have taken on the job if I had known? Absolutely. I love a challenge – and this one gave me free rein to express myself. For good or ill, I was in total control, with a very supportive CEO and board. No one was second-guessing me and it felt fantastic.

I was lucky, too. I joined during a slow period for the IT industry, which made it easier to recruit some great people who would have been harder to attract in more buoyant times. And that made all the difference as I embarked on what proved to be the most rapid and successful change programme of my career.

We introduced the most advanced technology platform in the City, reduced costs by over 60%, and increased service quality nine-fold. In my final year the Cazenove IT team won an industry award – this would have been inconceivable when I joined.


To build a successful IT business, you need excellent people. It sounds like a simple formula, but when you make a bad call, everyone suffers.

Many years down the line, there are still some poor staffing decisions – or indecisions – I made that I regret.

In one particular instance, I inherited a senior, articulate guy who was looking for a new role. In one business there was an urgent need for a critical new system. With not much to go on, I decided to hand him this new project, but within two months the head of the business unit had come to me voicing his doubts.

When I went back to my newly-appointed project head with these concerns, he gave a good account of the wider problems he had been forced to contend with, which included past relationship problems between IT and the business unit.

Much of what he said was quite fair and I took the decision to give him more time to prove his worth. However, in the months that followed the project continued to suffer in his hands and I was eventually forced to take a far tougher line to avoid further damage being done to the business.

With the benefit of hindsight, I was certainly guilty of being too protective of my staff, which in turn made me slow to investigate the problem. And by taking longer over the decision than I should have done, I ultimately made an already fraught relationship that much worse.

On a more positive note, I guess it helped me learn the hard way that when a member of your team does come under the spotlight you need to be prepared to really drill down into the business to get to the bottom of things.

That means speaking to the top 10 or 15 individuals in the business who have contact with the person you have concerns about, as well as speaking to the team member’s peers and subordinates within IT.

Of course, it is generally easier not to do that. But when you take the decision to stall, invariably it does not help the business, it does not help the reputation of IT – and it certainly does no favours to the individual concerned.

No one likes getting rid of staff members, and especially not long-term employees, but as the CIO you will sometimes have to make that tough choice. Keeping someone in an organisation where they are unlikely to have reasonable prospects is not the right thing for them and is not right for the business.

In light of the difficulties I have seen, I would now say that to build a successful team you need to spend a lot of effort up-front deciding who will be part of the team and who will not.

Those who fall in between – the maybes – you should give three months to prove themselves, but in those three months start looking for potential replacements, just in case they do not come good.

It is a tough line to take, but it is the right one.

>> Looking for a job in IT? Visit Computer Weekly Jobs today

Read more on IT jobs and recruitment