Something for the mentees: snippets of advice

Greetings and Salutations,

Today, I was looking through some correspondence with previous mentees, saw a recurring pattern of questions and thought (removing any identifying information) that it may be useful to some others in similar situations … so I thought I’d share.

The only unfortunate thing in doing this, is that in generalising and de-personalising the streams of information, some of it may lose it’s value or impact … but them the breaks. So without further ado, here we go.


How familiar is this scenario to you? How many of these questions have you asked?

  • “I’ve inherited a bunch of hand-built systems with no documentation, (other than passwords)”
  • “There aren’t any standardised services”
  • “I’d like to standardise the server platforms and OS revisions”
  • “I’d like to be able to automate patch/release management”
  • “I need a system where I can rebuild each server from scratch (there’s no money for clusters or warm-standby systems)”
  • “I’ve inherited systems that were put together with a few too many short-cuts and I have to somehow convince management to spend some money – or learn how to make things work another way.”
  • “I need to be able to manage vendor maintenance contracts on the hardware, software and applications”
  • “There’s no [standardised] system documentation for each server”
  • “How do I implement change management policies?”
  • “I need to maintain patch management and upgrade paths – the previous admins had a ‘if it ain’t broke, don’t fix it’ attitude which means we now have systems that are on an unsupported or end-of-life version”
  • “I need to figure out how to manage my manager”

These are the sorts of questions that seem to make up a pattern between the mentees I’ve taken on in the past. I may not have all the answers – let’s be honest, if I did, I’d probably be a full-time consultant charging first-born rates to give you your golden ticket, but hopefully some of the distilled responses below may help.


Managing Up/Getting buy-in

Okay, so do you know what the first rule of managing up, internal selling, gaining stakeholders, etc is? It’s a little known Radio station – WII-FM. Funny thing is, most people claim they haven’t heard about this radio station … yet it has a 100% market saturation rate. It stands for ” What’s In It For Me?” and everyone listens to it! Like it or not, the majority of people you are going to deal with in your daily working life are not there for the betterment of (wo)mankind, for the longevity of the company nor even for the best/purest/correct technological solution.

Surprise, surprise, they are in it for themselves – for their key performance indicators, or whatever the performance management system in place requires they achieve to get their next pay rise, or the corner in the office or the status among their peers. The sooner we accept this, without judgement (in the workplace at least) the better off we’ll be in the long and arduous journey that will make up our quest for getting “things” done. So, now that we know that’s the secret … the trick is to tune into their personal broadcast. What’s driving your manager? Just as importantly, what’s driving each manager in the chain up to the CIO and CEO of the firm? {See Exercise Opportunity: 1 at the end of this entry} So, that’s all well and good you say, but it still doesn’t help your current issues, right? Unfortunately, there isn’t a quick answer unless your boss is also technically inclined … In the meantime, the task list here is going to mean some additional work and research. When it comes to arguing these things back up, it’s not enough to argue the merits of best practice, technical requirements or how many hours there are in a day. This is the unfortunate reality – you can only argue the ‘value proposition’ of any item you present to management.


Vendor maintenance contracts on the hardware, software and applications.
I have many mentees inform me that they dont have any form of mainenance contracts with their vendors. Generally, this is due to a “that’s why we have hired you” attitude.

Personally, I always think these are necessities as opposed to nice to haves in any workplace. However, the commercial realities may not always make this a viable option. So, how do you sell this? Three words: Worst Case Scenario (WCS).

Below is an easy argument for a hardware contract – but the same scenario can be utilised for software or application contracts. e.g. Big Server 1 holds the entire customer database. The I/O controller dies, thus causing a corruption to data as the hardware fails. Unfortunatly, the server being over 3 years old, means that getting a replacement could take up to 3 business days. Add to that an additional half-day to rebuild the OS and the 10 hour data restore. This all leads to anywhere from an approximate 24 to 96 hour potential downtime (which has a collaterl damage bill of?). This can be offset with a maintenance contract that would supply us with the spare part and assist with the rebuild – which means a worst case of only 24 hours if we go cheap.


A trusted system on the internal LAN from which acts as a repository for system files and server images
I would use the same argument here for the reduction in the WCS timings. To be honest, this could be difficult … but I’d present it merged with a Patch management and change management as a combination system. This means you can flesh it out with the reduction in costs related to the manual rebuild, bug fixes, patching and controlled maintenance windows for each system.


Standardised system documentation for each server
Getting this right is so important.

Documentation is the kryptonite of all system administrators. Having a standardised template makes this process less painful – and we all know that having full doco on each system is important. We can talk about doco at length … suffice to say though, this is one of those tasks that you either need to get the buy-in of your team mates to make work – or do it all yourself and then have others utilise it as a matter of fact part of their duties.


Change management policies
The good news is that you don’t need a financial backer to implement this initiative.

The bad news is that cultural change can be so much harder.

Is this a nice to have? Hell no! This is an urgent requirement! I can’t conceive how any IT department with more than a handful of servers can be run without a change management policy. I don’t want to be too evangelical about it so I’ll stop my rant about now… The ideal will be to map out a number of requirements – not just the technical details but also the business impacts and regulatory requirements. This should be integrated with a dependency matrix {Exercise Opportunity: 3}, maintenance windows based on business impact, a stakeholders list ( i.e. business unit managers or system owners) as well as a records management system style of recording the change, the testing prior to implementation, the backout strategy, etc … I’d suggest building the change management system and putting it in place for all direct infrastructure ( e.g. mail server, file server, etc) systems. This allows you to fine tune it a little and demonstrate the business value of it’s implementation to management – and thus their buy-in for implementation across the corporation.


A server and an application licence, to allow us to run a production and staging on two different boxes
Oh, one of the hardest things to fight for in any corp! Ideally, the process for any IT implementation should be three stages – development -> testing/staging -> production. Some of the larger corps (like banks and national telco’s) split the testing and pre-production-staging areas into separate stages. Again, the argument here is the WCS – loss or corruption of data, followed by data restoration windows – but having a loss of sales at this same time, etc, etc, etc … Ideally, you would sell this as part of a greater change management system. But, in the meantime – look at utilising virtualisation to accomplish as much as you can without having every server physically duplicated.


Exercise Opportunities:

1. The Driving Force: What’s behind the Management team all the way up to CEO? As you talk to each person up the chain, ascertain what’s important to them, from both a professional ( i.e. what they see as their role) and personal (what is actually their hidden/not-so-hidden motivation?) and you will need to do repeat this task for each role each time a new person fills it. Start collating this information into grids – what are the common factors trickling down the line? Is there a specific common theme that can be utilised from a business case justification point of view? What common theme is running down the line from a personal motivation? These will become important at a later stage when you’re ready to begin pro-active up-selling.

2. An Historical View: If you know where you’ve been, it’s easier to work out where you’re heading. What’s the history of your team? department? workplace? Collating as much information as possible – not just the surface reasons can improve your understanding of what has happened, and what to expect. For example:

  • what were the team expectations, and did they meet them?
  • What were the SLA’s for the team?
  • Are those same SLA’s still in place?
  • What were the ratios of admins to services?
  • Has the number of system’s increased since?
  • What are the business impacts that have come about since these changes? i.e. how many requirements are on the waiting list?
  • How many servers are running above capacity?
  • How many down times have occurred and what is the impact to the business in real terms or in ‘collateral damage’ amounts?

3. Creating a dependency matrix. This is not as simple an exercise as it sounds. Start by documenting out each of the physical systems across the company under one column. In the next column, add the services and applications running under each system against that physical system. Once each system is documented vertically, repeat the listing horizontally. In the ensuring grid, start colour-coding the dependency relationship within each grid square. e.g. full dependency = red square, application dependency = yellow square, data dependency = blue square, regulatory dependency = black square, etc. Of course, if you’re more coder-focused, you can turn this into a pivot table with custom scripting or dump it into a DB with the appropriate DBA magic.


What I mean by “Collateral Damage”: One of the factors I used to utilise in the fight to justify costs of ‘doing it right’ to the business. The idea is to put a dollar value on all factors related to downtime – lost productivity, lost sales/revenue, customer dissatisfaction, etc. It’s important to be able to vocalise this figure as a direct side-effect of downtime or slow systems or ‘whatever’ as it is easier to justify costs for what ‘business types’ will see simply as an ‘insurance policy’ when you can show them the ‘damage bill’ and provide the value of the proposition as a percentile factor. Gathering the data for this is generally easy as there is always someone in the company who has already worked out figures for their area (especially in insurance/finance corps – where someone has actually put a dollar value on each lost call, etc) … this is where you start putting your people skills to work and talk to key members in each department and in a very short time you can have this information … and usually the entire level of current gossip and political play as well.


I know this is sparse … but it may assist one or two of you … hope it does.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s