<img height="1" width="1" style="display:none;" alt="" src="https://dc.ads.linkedin.com/collect/?pid=314913&amp;fmt=gif">

So, what does the status quo look like?

Troy Whittaker
April 14, 2016

If you are following my blog, you know I focus on systems management. If you’re new to my world, check this out for a primer.


When it comes to managing infrastructure, deploying content and enabling productivity – there is a right way, and then there’s everyone else. I’m not making the argument that this is a simple binary equation (e.g. either you are optimized or you are not). What I’m going to lay out in this piece are the signatures of an incomplete or immature strategy. It’s not meant to insult anyone, rather I have found in my hundreds of exposures to enterprise IT organizations that there are some key indicators upon which we can rely. Maybe as starting points, or in some cases, switches we can ‘flip’ to radically increase productivity.

Let’s take a look:

Indicator #1: Upgrade Hamster Wheel

So, something doesn’t work and the team thinks we need to upgrade to get it? Or maybe the vendor said “that feature is in our next release.” None of this is new to IT, but what you might be missing is how your internal maturity can affect this decision tree. That is, if you have a decision tree (zing!). 

More often than not, you are upgrading because you think you need a new feature or capability. Let’s back up the software truck a minute though, and consider how we got here.


IT Director says “Godfather (probably the CIO) wants Windows 10 on his desktop. When will it be ready?”

IT Admin says “Well, if I drop everything I can have an image ready by next month. But…”

IT Director says “Great! I’ll go tell him now (so I can look like I get things done)!”

IT Admin /logs off mentally


How many times have you seen this interaction in your IT organization? How many times has it happened to you?

There are sooooooooo many shiny things out there. Even this guy (points thumbs backwards) is known as Shadow IT ™ around the ITS offices. What can YOU do differently?

It’s pretty simple, but it’s not something the IT Admin or IT Pro can do (without some risk to themselves). Better decision making, and higher maturity, begins with the CIO. And that CIO should be embedding a process-driven decision tree framework in their directors and managers. I’m not going to give away all the secrets here, but let’s look at how that conversation goes in a higher-maturity shop:


IT Director says “Godfather (probably the CIO) wants Windows 10 on his desktop. When will it be ready?”

IT Admin says “Excellent, I’m also excited about Windows 10 and what it can do for our business. I have been thinking a lot about how we can streamline our patch compliance ops with Windows Updates for Business and that will be a key part of our Windows deployment strategy. Who can we leverage internally to build the business case? I’m happy to lead this effort and why don’t we aim for a presentation to the CIO in 30 days?”

IT Director says “Uh, yeah. That sounds good. I’ll set up the meeting (so I look competent at least) for you to present your findings.”

IT Admin /sips coffee, enjoys living in a world where decisions are not made outside of business processes and feels internal joy


You’re right though – it’s not that simple.

However, I will argue there are a few things that must be in place to ensure a better outcome. You may not think these are relevant to systems management, but they are.

Behold, thy truths:

  1. There are defined release and support cycles for operating systems
  2. There is a rapid-response protocol for new device form factors and use cases
  3. There is a cross-functional IT architecture team that drives all decision making for new releases
  4. Your business unit has an approved financial model in which you can evaluate the business benefits of any change or new release

Indicator #2: You always need consulting

I have been a consultant, and now I help manage an IT consultancy. Might seem crazy that I suggest this is a problem… let me explain why!

My view has always been that you shouldn’t bring a consultant in because you don’t know howto do something. You bring in outside expertise to get the benefits of their field experience and help accelerate your project. It’s about wisdom, not skill. We are all smart people… and frankly why would you pay someone else to push the Next button?

Anyways, where we see this problem become business-impacting is when your operations or project offices default to consulting for any change or incident. This is a leading indicator that your team is either under-staffed (meaning they don’t have time, and need outside augmentation) or unsure of how to proceed (there is a process problem).

The real point here is you should have a set process that includes a step to consider outside consulting. The process should not start with nor rely upon outside resources.

Indicator #3: FTE’s go up, but productivity does not

If you are an IT manager or director, you probably have a handful of key people that get things done for you. When a new solution is brought in, or IT expands operations, it is natural to take on additional staff to manage the new workloads.

There are a couple different ways to measure your productivity here: inside the IT team, and within the end user community. Let’s dive in:

IT Pros

Teams should have a defined set of responsibilities, and those should be matched against the available time and broken down by service or product owners. You cannot improve what you don’t measure, and if you’re not measuring you are stuck.

End Users

The ultimate metric for most systems management teams is the relative happiness of their end users. These are the folks that need apps & data to be productive. If you’re not giving them what they want, they way they expect and without compromises – you are probably losing traction with the community that can provide the most leverage for budget allocation – or worst case, your right to exist in the larger organization.

Give people what they want, or they will find someone else who will.

Indicator #4: Process questions are answered with vendor terminology

Finally, this one is a red light and air raid siren for most CIO’s. If you ask your team howsomething will get done, and the answer is specific to one vendor or product – you’re starting from the wrong place.

Systems and processes need to be born from hard wrenching the challenges to your business, not the tools or suppliers that help you deliver the necessary outcomes.

When you break it down to the most basic level, you need to define your why, which will lead you to developing the how. This all needs to happen before you start talking to vendors about how their offerings can help you deliver that.

You May Also Like

These Stories on Systems Management Insights

Subscribe by Email