Storagebod Rotating Header Image

General IT Management

Archicultural….

May 1st, 2012
by Martin Glassborow.
No comments yet

It seems the more that I consider the architectural and technical challenges and changes to the Corporate IT world, the more I come back to the cultural issues which exist within many IT departments and the more I find myself feeling strongly that this is where the work really needs to be done.

Unfortunately it is pretty hard to buy a culture from a vendor, even though I suspect if Chuck could work out exactly how to do so; we’d have a product from EMC called V-CLT (or is that VMware?); so building a culture is going to be have to be an internal thing and that means it is going to be tough.

Too often the route into IT Management means either promoting excellent techies into management or sometimes promoting people into positions where they can do no more harm as opposed to moving people into positions which suits them and their personalities. I am sure that we can all think of examples of both; this is especially true in end-user organisations as the career paths are less varied than that of the vendor organisation. Vendor organisations have sales, marketing and other avenues for progression; they also have the traditional IT paths as well.

But all IT organisations are suffering from cultures which neither scale or are sustainable in the long term. There needs to be a long term shift which ensure that training and development are in more than just technical skills; there needs to be a move away from a hero culture that sees staff at all levels of an organisation regularly halving their hourly rates by working longer than their contracted hours, not taking leave and forgetting that you ‘Work to Live’.

Careers need to be thought of more than the fastest route to the top and when people find their natural level; this does not mean that they do not stop being valuable members of an organisation. Work on developing people horizontally (and you with the dirty mind can stop sniggering); I think that there is something relatively unhealthy when you find managers who have worked their way up through a team and only worked in one team.  Horizontal moves have immense value; I have learnt such a lot in the past couple of years running a test team as well as a storage team.

Horizontal moves will help to break down some of the siloed mentality; even if you do not believe in DevOps, moving people between these two disciplines even on secondment must have value.

If you have a graduate scheme in place, the natural roles that most graduates gravitate to are in development; make sure that they have a placement in an Operations/Infrastructure team. They will learn so much.

And if you work in management; you are doing a pretty hard job, make it easier on yourself by standing on the shoulders of giants and actually study the art of management and leadership. Most get to management by being good at something; being good at that something does not mean you know anything about management.

Thinking Architecturally

Apr 16th, 2012
by Martin Glassborow.
1 comment

If you start an architecture with a shopping list of technologies that must be used; that architecture will be compromised. However this does not mean that you start working without an appreciation of the possible, obviously you need to be aware of limitations such as constants such as the speed of light and other real constraints.

But currently I see a trend from many, both vendors and users, trying to fix round-hole problems with square-shaped blocks. Not enough time is spent on the problem definition and truly understanding the problem; your existing tools may not be sufficient and although it may feel that it is more expensive to implement something new, at times it might be cheaper in the long-term to implement something right.

Also be aware of falling into the trap of implementing a feature just because you’ve made the mistake of purchasing something that does not fit your problem definition. If you’ve been sold something that you can’t use effectively, you have a couple of option; suck it up and learn from experience or shout and holler at your vendor/partner for selling you something which is merely shelf-ware. In my experience, the latter is often ultimately pointless and simply results in the vendor promising you some other product which you put on a shelf and not use. Use the experience to move away from architecting to utilise a feature and architecting to solve a problem.

This does not mean that you simply purchase a new system/technology for every problem; governance has a role but I would suggest that governance should be applied after the initial high-level-architecture. I like to think of it like more more traditional bricks and mortar architecture; the architect relies on a whole bunch of technical people to fulfil their vision and bring it to reality. At times these technical people will tell the architect that the architect is a complete moron; sometimes the architect will agree and sometimes the architect will work with the technical teams to come up with something innovative and new.

But in general the architect does not start their design with a specific make of brick in mind. Neither should an IT architect.

The Steve Ratio

Apr 4th, 2012
by Martin Glassborow.
1 comment

I’ve seen a few blogs recently about management and especially man management in IT but before I begin, I’ll explain the title! In my career, I have had four managers called Steve; two have been good, one indifferent and one who words cannot describe, not when I know that are some ladies who read this. And actually, the ratio of 2:1:1 is pretty much representative of the managers I have had so far.

So what makes a good manager? Well for me, the most important quality of the two good Steves was that they allowed me to make decisions that I was comfortable with and when I made a mistake, they would sit down with me and work through the mistake and then let me fix it. Let’s break that down

1) They trusted me….good managers trust!

2) They let me make mistakes….good managers do not second guess and do not blame!

3) They gave me guidance but not the answers! Good managers show the way but don’t carry you!

4) They trusted me….good managers don’t let mistakes destroy trust!

Now with my current numbers of direct reports, around thirty (I loose count); I have no choice but to follow those principles and do any more would rapidly hasten my descent into insanity but I owe those two Steves a great debt.

For me, man management is the great under-rated skill in IT; they aren’t always the most senior people and sometimes they aren’t the greatest techies but they ensure your organisation works and that you can do your job.

It is ironic that so many people say that the road to Cloud requires a cultural change; perhaps this should also include a change in attitude to man management. Perhaps we can change the Steve Ratio and make it 3:1:0; no arse-holes and a majority of good managers.

Reflections on a Professional Future

Apr 1st, 2012
by Martin Glassborow.
No comments yet

Yay, go me…I’ve survived another year on this rock; although I’ve noticed my first gray hair which is little concerning. My birthday and other anniversaries around this time of year always lead me feeling a little reflective and thoughtful; this time, I am thinking about our profession and it’s future. I’ve wanted to work in IT pretty much as far back as I can remember and apart from a long-held ambition to be Indiana Jones and be an archaeologist uncovering lost cities and mysterious temples; I still can’t really think of any other profession that I’d be in.

Yet I am concerned about this profession and the direction it is taking; no I am not talking about the technical direction it is taking but more what it is doing to it’s people. This may be simply a factor to do with the economy and that we are also in the throes of a ‘transformation’ but this could be something more concerning.

I am seeing increasing numbers of people surfing the edge of burn-out; both in end-users and vendors. 60-80 hour weeks and more becoming the norm; not the exception and demands on people’s time increasing all the time. The mobile revolution leaving people on call all the time; the liberating impact of mobility being lost as the contactability at all times becomes a ball-and-chain.

Yet all the research suggests that most people are generally most effective when working something between 35-45 hours a week; we pride ourselves on being a smart bunch in IT, yet we seem to ignore both common sense and scientific research.

And if we factor in the high degrees of introversion in our profession, we are tending to force people to be always on when they need to be given time and solitude to recharge. Meeting after meeting, interaction after interaction, chewing away at the spirit of some of our most talented people.

The best people love this profession and they are an odd bunch; how many surgeons take patients home to operate on? How many dentists build home surgeries to try out the latest techniques? How many teachers? How many accountants? Lawyers? Very, very few! But amongst our fellows, it’s relatively common…I would argue that even those who do manage to stick to their official working hours, normally put in another day’s work in keeping themselves updated.

Yet as a profession, we pride ourselves on enabling our users to work smarter and better; our output makes people lives better and richer. Perhaps we should think about how we do the same for ourselves?

After all

Young man, as you perambulate down the pathway of life toward an unavoidable bald head bordered with gray hairs it would be well to bear in mind that the cemeteries are full of men this world could not get along without, and note the fact that things move along after each funeral procession at about the same gait they went before. It makes no difference how important you may be, don’t get the idea under your hat that this world can’t get along without you —Abilene Reporter, 1909.

 

Empower the Cloud

Mar 26th, 2012
by Martin Glassborow.
1 comment

As various organisations continue their journey to the Cloud, I wonder how many will be truly successful and how many will simply Cloud-wash their existing IT. As vendors continue to wash their products and make them all fluffy and cloud-like, so I suspect will many end-user organisations. And in that, they will miss many of the benefits.

But what will guarantee a successful Cloud deployment? Well, if you start with infrastructure, you will probably seriously reduce your chances of a successful deployment. You have to start with the organisational culture, this is something that many pundits agree with but there is not a lot of real discussion about what culture needs to be in place.

I think fundamentally, Cloud is about empowerment; an empowered work-force will get the most out of Cloud and without an empowered organisation, Cloud will fail and dissipate on the old hierarchies.

Cloud empowers users to make decisions and more importantly make mistakes; fail early, fail often but fail cheaply. A huge investment does not need to be made in putting together an infrastructure to support an initiative; it can be quickly brought-up and then ripped-back down again without blame and significant cost. You can run innovative projects ‘lean’.

Cloud empowers IT to put in place standards which are not seen as restrictive as they become almost invisible to the users. A change in hardware should not necessitate a huge round of regression testing; hopefully we will get to the stage where a change in platform full-stop will not mean a massive amount of rework and regression.

Cloud should empower your IT teams to work cross-discipline and cross boundaries but if your teams are already siloed and not able to talk to each other, then ask yourself why? Are you so focussed on internal hierarchies and control that you are preventing this? You need to empower your teams to have peer-level conversations and decision-making ability.

Often when people talk about the tools required for Empowerment, they talk about ensuring that people have the right information to make good decisions; in many organisations, information is still hung onto; knowledge is power and many like to hoard power.

If your organisation already has a culture of knowledge sharing, then moving your knowledge infrastructure to Cloud is a logical step but if you have a culture of controlled ignorance, then the journey is going to be hard.

Refactoring the Future….

Feb 5th, 2012
by Martin Glassborow.
1 comment

Most of my career has been spent in infrastructure and I guess infrastructure related technologies is the thing which really interests me professionally but I have spent time working as a developer, leading a development team managing the transition to agile development and more recently, as well as running a storage team, I also manage an Integration and Test team; this has hopefully led me into becoming more rounded professionally. And I think we as Infrastructure techies have a lot to learn from our colleagues in development; they’ve probably got more to learn from us but we can learn something from them.

Recently I’ve been wondering if Infrastructure could be treated more as an application; something that is more dynamic and less static than it is traditionally. Can an Infrastructure be Agile? And can it be managed in an Agile manner? The received wisdom is almost certainly, no! More outages are caused by change in infrastructure than any other cause;’  ‘if aint broke, don’t fix it’ is not actually a bad way to go but is that necessarily the case?

One of the big changes that Cloud brings should be that applications are engineered to cater for failure and change; an application should be able to move, replicate, grow, shrink and be resilient in spite of infrastructure.

Now this could mean that we could deploy, change and improve infrastructure a lot more rapidly; refresh becomes a constant task and not something which needs a special project to do, tuning and maintenance become routine and not scary. We have an infrastructure that is being constantly refactored in the same way that good developers refactor code; we fix kludges and workarounds, no longer living with them because we are fearful of the consequences of changing them.

Yet we also need discipline not to change for change’s sake; anyone who has run an Agile team will tell you about the importance of eg0-less developers (an oxymoron if there ever was) but you can run into the problem where more time is spent refactoring than adding value. I am not convinced that we will have this problem initially in Infrastructure, the culture of  ‘if aint broke, don’t fix it’ is heavily ingrained.

Refactoring is a small part of Agile but it is something that we can learn from in our Infrastructure domains. However there is a big problem; vendors don’t really like change and they throw all kinds of obstacles in your way, like interoperability matrices and the like. They really don’t like the idea of incremental change; they want big change where they can bill big tickets and big services.

I think that vendors and service providers who are going to win big are those who can deal with incremental change and improvements; those who are reliant on big changes and refresh cycles may well struggle as we move to a more dynamic model. I include internal IT suppliers in  this as well; the big change is a cultural change to accept that change is constant and good.

The True Scourge

Nov 22nd, 2011
by Martin Glassborow.
5 comments

Many people believe that email is the scourge of our modern life and there is some truth to this but I do not believe that for many of us; especially of those in the middle management layers that this is the real scourge.

The real scourge is Online Diaries; generally Outlook but all are evil.

When I started my career all those years ago; I had part share in secretary who managed my diary, if you wanted to book a meeting with me, you would generally ask Audrey who would check that I was free and would apply common sense.

1) She would not accept a meeting booking when I was on leave.

2) She would not accept a meeting booking when I was already booked.

3) She would not accept a back-to-back meeting booking, especially in different buildings and would always make sure that I had time to get from one meeting to another.

4) She would generally ensure that I actually had time for a break and time to do some work during the day.

Unfortunately these days; even staff at my ‘exalted level’ do not warrant a secretary or PA and my diary is on line for all to see and so people feel happy to

1) Book meetings when I am on leave

2) Book meetings when I am already attending another meeting; I have an example this week when I am in six meetings simultaneously allegedly.

3)Book me solid for a whole day with no time eat, breath or think and seem to expect me to be able to teleport across campus.

4)Leave me no time to do any work

In fact meetings have proliferated to the extent that they are meaningless. Online diaries have made it easy to invite a cast of thousands; book even more meetings, book meetings at the last minute and generally destroy the working day of many.

Meetings are now badly run with no agenda, no minutes and often over-run causing even more running about the campus. There are now so many meetings, that most places have a shortage of meeting rooms and hence meetings are now run in rest areas, canteens and anywhere else that can be found.

So it is not email that is the scourges; it is the modern meeting which is the true time-soak and scourge of many.

Solutions and Specialists…

Nov 21st, 2011
by Martin Glassborow.
No comments yet

Solutions are great, a vendor turns up and sells a turn-key solution, it’s a marvellous world and everything just works; it’s all certified and lovely. There is a single supplier to kick and trouble-shoot the problem. Or at least that’s the theory….

But what happens when the supplier can’t fix the problem? Who do you turn to then? Funnily enough, that’s the situation I’m in today. A turn-key media solution which we’ve been kept at arms length from for years has developed issues and now who do the customer turn to when not getting good answers from the solutions vendor? That’s right, our little team of specialists..

A couple of hours of investigation and a meeting with the vendor where we expose what we see as issues by treating the solution as just another piece of infrastructure has been enlightening to both our internal customer and the solutions vendor. There will be no arms-length going forward; solutions still need specialists.

You need specialists to ensure that the wool is not being pulled over your eyes; you need specialists to ask the right questions and know when the answers are not good enough. Too often you will find that the solutions vendor themselves have little clue about the underlying infrastructure; focusing on the application whilst using the hardware as a nice little revenue lift. This is fine until you hit problems.

If you are buying integrated solutions and stacks; make sure that they are integrated and that the solutions provider can actually support the stack. Don’t be afraid to dig into what is being provided as part of the stack/solution and keep some specialists around.

 

Singularly Selfish….

Nov 20th, 2011
by Martin Glassborow.
No comments yet

Despite the ever shifting sands which are most large IT departments/divisions/directorates; the underlying structure has not changed for many years. Indeed, most IT departments look very similar to the IT departments of the mainframe era and mostly are analogues of the past. And the longer something stays the same, the longer it stays the same; the resistance to change will cause most organisations to simply spring back to a previous form.

Yet we are talking about new paradigms and new delivery models but how do we stop this simply springing back into the previous form.

Transformational change is required but can most organisations actually achieve this? Only you can answer that question for your own organisation but I would suggest looking around you and think about the changes that you can make. It might be worth being a little bit selfish and ask yourself these questions?

How do I have more fun and go home happy pretty much every day? How do I make my job more satisfying?

I think until you can answer that question and decide on your destination; all the technological changes in the world are probably going to be little difference to the delivery of the IT Service. I think ultimately, a new service model will make your life a lot easier and a lot more fun…in fact, the positive impact on you may well be greater than that of it on the Business.

Yes, we spend a lot of time talking about technological and organisational change but take it back to you and work on being happier.

Innovate At Your Peril

Oct 22nd, 2011
by Martin Glassborow.
5 comments

This article was linked to by some of the usual EMC suspects; a fluff and puff piece about Private Cloud with the normal warnings about security in the Public Cloud. It is this section of the article which I find especially disturbing both in tone and message…

I’ll leave you with what has become my favorite story and it was told at CIO 100: Apparently, two engineers at a pharmaceutical company had to complete a critical project quickly and bid it out to IT. IT came back with a massive cost and a timeline in months. The engineers instead used their credit cards to use cloud services and completed the project in a few weeks and won an award for cost savings. The day after winning the award, both were terminated for violating the firm’s security policy as the project, which was ultra-secret, hadn’t been adequately secured.

I can almost imagine the teller of the tale’s gleeful smile as he recounted that story, perhaps the CIO involved. Now I think there should have been several different actions, none of which lead to the dismissal of two obviously talented and thoughtful engineers.

1) The CIO should have been hauled up and made to explain why his team could not provide the services that the engineers needed in a cost effective and timely manner. He put them in the position that do their job properly, they had to bend the rules. In fact he should be the person loosing his job and as a result of his inability to provide service; the company had had to terminate two valuable employees.

2) The team which looks after security should have been asked to look at the project and what the engineers had done; make a proper security assessment and work with them to ensure that such projects could be delivered in the Public Cloud in a secure manner. Proper procedures and guidelines should be put in place to support innovation.

But instead, a vengeful IT department decided that best thing to do is to shut down anyone innovating in their space.

And if anyone thinks that the large pharmaceuticals are not using public cloud; you should probably think again. They are regularly and I suspect securely; or perhaps, its not 100% secure but the opportunity for quicker delivery is worth risk.

Security is an issue but don’t let vendors and IT departments use it to block innovation and keep their castle intact. Security needs to move on from ‘No!’ to ‘How can we help you achieve your goals!?’; a bit like IT departments in general.

← Earlier Posts Newer Posts →