Storagebod Rotating Header Image

General IT Management

More Management Musings

Now, as regular readers are aware, I not only pretend to understand Enterprise Technology but at times I also masquerade as a mid-level IT Manager; fortunately, I’ve had a number of good mentors and I like to think I’ve learnt something along the way.

The best managers know their team’s capabilities and trust in them; the best managers are the ones who don’t have a permanent frown and stressed look. In fact the very best managers often appear to do very little at all and just give a gentle nudge here and there.

It’s a confidence game, if you look confident most of the time, your staff will do too. And it’s not just about having confidence in your staff, you must have confidence in your own capabilities; for example, ‘Could you do your manager’s job?’; it always surprises me when a manager expresses the opinion that they could not do their manager’s job or even their manager’s manager’s job. Not would they want to do it but could they do it if push came to shove? And could they do it well?

If you can’t do it; you should be asking yourself why? What is it that you are missing? What skills do you need or do you think you are just not good enough? If it’s the latter, you’ve got a problem because you are a bed-blocker and your team is being held back. If you are missing some skills, perhaps you need to get some development and mentoring.

Or perhaps you are just not interested and are confident that you’ve reached your level of competence? Or perhaps you simply have different priorities? That’s fine and actually you might have a lot to offer your staff as long you ask yourself some questions and are honest with your team. Often it is teams run by such managers who feed an organisation with some of its best people.

And you also need to be asking yourself, who in your team can do your job? And then ask why not  again? If no-one in your team is capable of stepping into your job; ask yourself what do they need to do and how do you get them there.

I see too many managers who are so insecure in their position that they are holding themselves and more importantly their team back simply because they are protecting their position without  having the confidence to move on to the next level. And yet it is often those managers who won’t let their star performers move to further their career.

Yes, you can judge a manager by the quality of his team but I reckon you can really judge a manager on the quality of the people that they move on into bigger and better things.

The Internal Service Provider

There’s a lot of discussion about how the Internal IT department moves from being the gate-keeper to all things IT and to a position where they become a Service Provider with Business units given OpEx budgets to purchase service from either the Internal Service Provider or from an External Service Provider.

There is certainly a lot of logic surrounding this but there is also a two way dynamic which also needs to be addressed.

If we move the Internal IT department to service provider status, a few things may need to happen to level the playing field.

i) The Internal IT Department needs the right to ‘no bid’ a service i.e we are not interested in doing that.

ii) The Internal IT Department in the event of finding a workload shortfall should have the right to bid for external contracts.

iii) There needs to be solid agreed SLAs/contracts between the Business and the Internal Service Provider. SLAs cut both ways; if you change your mind half-way through a project, change direction etc; you take the hit, not the service provider.

And there we hit the crux of the problem; if you want to move to a service provision model, it’s not entirely one way traffic. You cannot just expect the IT department to do the shit which no-one else wants to do; the IT department should not just be the provider of last resort.

The Service Provider Dynamic is a two-way thing!

Facilities Management

We’ve all sat in the meeting about infrastructure delivery and someone will pipe-up;

‘We need to do it faster, we need to be agile!’

And we’ve all seen the faces pulled or at least the flicker of disgust and loathing which crosses the face of most of the people in the room.

‘What do you mean faster….what do you mean agile? You can’t deliver infrastructure in an agile manner!’

And it’s funny because I think generally they’re right; you can’t deliver infrastructure in an agile manner if you carry on delivering infrastructure the way that we are expected to deliver infrastructure today.

In fact infrastructure can’t really be delivered in an agile manner unless we all become service providers but even then agility is an illusion. In order to build infrastructure in an apparently agile manner, we need to build it in a structured controlled manner out of standardised components; these could be vendor defined stacks or internally-defined infrastructure stacks.

And then we need to build them ahead of demand; you wouldn’t expect your facilities team to build a new office complex every week or if you did…

You wouldn’t expect your facilities teams to be able to bespoke a different desk and a different chair for every one; you’d be presented with a choice (or sometimes a choice of one) from a set of standard options.

I think that the move to commodity based IT is a bit like the move to open-plan offices; lots of people hate it but ultimately it suits most businesses better.

You present the business with a floor and a catalogue and tell them

‘There you go, you fill it with your choice of stuff from our choice of stuff and it’ll be here next week.’

And if your business suddenly needs some extra space; well, it’s a bit like moving into a managed office.

Furnish on demand not construct on demand.




Jeremy Burton of EMC tweeted the following

The last 50 years were about computer science. The next 50 will be about data science. #BigData #EMC

which lead me to reminisce that I started my career in the Data Processing Department which was then renamed the Computer Services Department over 20 years in a large Retail Bank in the UK. So over 20 years ago we were already talking about Data and Services.  And actually I will argue quite strongly that we were focused on both, they were the life-blood of the department and we probably had a better relationship with our users than many IT departments have today.

It was a very different relationship though; the Business would ask us for a service and we would go away and ponder it; spend an inordinate amount of time building something and they would be grateful for what they got. There was rarely a challenge to this state of affairs; rarely any indication that they did not have faith in what we were doing. We had a few hairy moments but they were pretty good times.

And then the PC came along and ruined it all; the users wanted their own computers and we in general could not really see why they would want to do something themselves. Could they not simply be grateful for what we provided? I mean we were giving them everything they asked for, well mostly.

So, then started the war between Corporate IT and the users; both sides believing that they knew better and at that point, I  think that it became a struggle for control and sight was lost as to the function of the Information Technology department. In fact, it seemed to stop being about Data, Information and Service but about control of Technology.

After a battle of attrition, it looked like that Corporate IT had won but at a cost; IT became a much resented cost, a blocker to progress, a slow moving entity divorced from reality and it’s original function.

And then the Internet happened and more importantly the Web happened; new businesses started to spring up and grow rapidly. Businesses which had IT departments much closer aligned to their aims and ambitions.  Home-computer ownership exploded and broadband opened things up to people at home, the fragile peace was shattered again.

Throw in the growth of mobile devices and a pervasive, always on, data network with rapid commoditisation of computing power; the battle this time is not one which is winnable by the Corporate IT department.

And so we find ourselves talking about Services, Data and Information again; we are beginning to see Data Managers, not Storage Managers; Delivery Teams, not Implementation Teams. I find myself working in a Broadcast Services Delivery Team; I spend a goodly amount of my time talking with users to find out what they want and not just expecting them to be grateful for the crumbs that I give them.

So although at times, it may appear everything is circular; the relationship between IT and the users has actually gone through a Metamorpheses and will continue to do so but at the end of it all; it’s all about Data and Information…’and not the wrath of Jove, nor fire nor sword nor the devouring ages can destroy’ this fact and we fight it at our peril.

The Complexity Conspiracy

For many years, there’s been a cosy little conspiracy between vendors, IT departments, analysts and just about everyone else involved in Enterprise IT and that is that it is complex, hard and generally baffling to everyone else. And in our chosen specialism, Enterprise Storage; we are amongst the most guilty of all.

We cloak simple concepts in words which mean little or can have multiple meanings; we accept bizarre and arcane commands for basic operations, we accept weird and wonderful capitalisations, we map obsolete commands onto new functions adding yet further obfuscation, we allow vendors to continue to foist architectures on us which made perfect sense fifteen years a go but have no real validity now.

I at times wonder just what a mess we would be in if new vendors such as 3PAR and Compellant had not come along and massively simplified things; hands have been forced a bit but arguably this has not yet gone far enough. The mid-range systems are generally better than they were but we need to see this pushing up the stack to the high-end.

It is not enough to sit back and plead ‘backwards compatibility’ as an excuse for not revisiting tools and terminology.

I think what I would like to see is a big push to simplify and clarify terminology; let people in and stop veiling with false complexity. And ironically enough, I think if we were to do so; we might find that in de-mystifying what we do, our users appreciate what we do more.

It will become easier to explain concepts such as availability and recoverability; the concepts will become understood and appreciated more and with that understanding, there will be more demand for them. Hand-waving and muttering that its complex and pretending to be the gate-keepers to IT nirvana is no longer really a tenable situation. They are going off to do their own things and they are no longer believing in the power of the IT department.

They *know* that this stuff is not complex and they are going to prove it themselves. But although it is not fundementally complex, it is not always easy and we only have to look at the impact that large Cloud outages have. We do know how to do this but we have to share and embrace; people often talk about how Cloud can enable collaboration and how true this is; it enables and encourages collaboration at a multitude of levels.

But this is not just about Cloud; it is about a change in how we work with our end-user colleagues;  it is about telling our vendors that the systems that they are shipping are unnecessarily complex; we should be demanding simplicity and not allowing them to ship us product which is only useable by occultists engineers or whatever else we want to call ourselves; we need to invest in simplifying our environments and we need to stop being complicit in a ‘Conspiracy of Complexity’.

Managing IT….people

I have just finished carrying out the end of year appraisals for my teams; yet again I come out of them feeling slightly despondent and that I have generally let the people down. Development plans often are not followed through due to the pressures of actually doing a job, training budgets often don’t allow all the training that people need/want and actually finding the opportunities to progress people is hard.

I know that I am not unique and I probably shouldn’t beat myself up about it too much; I look round and see plenty of people struggling with similar issues and at least I was developed in my early management career, given at least some of the skills needed to do the job.

Just calling someone a manager does not make them a manager; too often I see good technicians promoted into management positions with little or no support. Managing people is hard and it is not for everyone but in far too many companies, it is the only way to progress.  Some people do take to it straight away but these people are few and far between, rarely are they your best techies; to be an excellent techie takes a different kind of focus.

Of course, then there are the companies who decide that they need a technical specialist track; so they create a technical career track but then it all goes wrong.

1) The technical career track often tops out before the management track; so people are left high and dry with only way to progress being to move into senior management. But unfortunately, they are ill-equipped to do so because they have skipped out a lot of the management training which comes with middle management.

2) The technical career track often forces people into an architectural/design role and yet again, some of the best hands-on techies make terrible architects and designers. They often find it extremely hard to move out of an implementation/support role and drive those teams mad. Technologies change and unless you actually have experience in supporting them on a day-to-day basis; you have no real basis doing low-level implementation.

So what happens? The only way to progress in most end-user organisations is to leave and take all that organisational knowledge with you. And then we get into the argument, that if I train people, they just leave and so you stop training/developing people; so they leave anyway and even worse, they might stay.

It’s time to stop trying to push people in to career paths which don’t suit; it’s also time to allow people to fail at some things. A couple of years ago, I had a staff member who wanted to try something, I was fairly certain that it was not the right move but I let them anyway, I just made sure that I was around to catch them and had another position to allow them to bounce into. We now have a happy employee who was allowed to fail, learnt a lot and moved into a role which allows them to progress and be happy.

We need more of this; introducing people into roles gradually and allowing them to re-trench if needed. We also need to acknowledge that there many different tracks to progress in IT and we need to value each of the tracks/roles within IT. I’ve seen so many people try to succeed in a specific role and not take the perfect role because they thought that working in change management for example was not a valued role.

If people are our most valued asset; we don’t half have a funny way of showing it at times.


GPs in the UK and I suspect all over the world have the term ‘Heartsink Patient’; a patient who just makes them go ‘Oh no, not again….!’ and they just know that the ten or so minutes that they are allocated for an average consultation is just going to go out of the window. The patient generally presents symptoms which are vague and ever-changing; full of complaints yet rejecting advise and when advised to stop doing the thing which hurts, they continue to do it.

And in IT; we have exactly the same problem, we have ‘Heartsink Projects’, ‘Heartsink Project Managers’ and ‘Heartsink Users’. They exasperate us and drive our tempers close to boiling point; I suspect this causes more cases of IT burn-out than almost anything else.

So I wonder if looking at some of the advice given to GPs on how to deal with their Heartsink Patients may be of use to us in the IT World.

Accept Them

Every company has them; don’t overly fret about it and realise you’ll never get rid of them. But also remember it probably isn’t anything to do with your abilities as an IT Practioner

Listen Carefully

There are generally requirements in there somewhere, listen and pick them out. Take notes and reinforce with reflective listening. Always summarise the meeting with a note and agreed actions on both sides.

Be Realistic About Outcomes

Calmly manage expectations; if a project manager presents a date which is completely unrealistic, step through the required actions with timescales; let them see where the critical path is and try to work through to a sensible date. Of course, they are going to want to do it quicker and cut corners; understand that this timescale has probably been dropped on them but you can sometimes arm them with the information they need to get the project rescheduled.

Keep Cool

Keep cool and smile understandingly; try not resort to the geek defence/offence of extreme sarcasm.

If you can manage to do that, you are probably a better person than me.