Do You Do What You’ve Always Done?

When I was an intern at IBM twenty something years ago, my job was deploying new laptops to people. The job was easy enough. Transfer their few hundred megabytes of data to the new machine and ensure their email was all setup correctly. There was a checklist that needed to be followed in order to ensure that it was done correctly.

When I arrived for my internship, one of my friends was there finishing his. He was supposed to train me in how to do the job before he went back to school. He helped me through the first day of deploying laptops following the procedure. The next day he handed me a different sheet with some of the same information but in a different order. He said, “I realized we had too many reboots in the process and this way cuts about twenty minutes off the deployment time.” I’m all about saving time so I jumped at the chance.

Everything went smashingly for the next month or so. My friend was back at school and I used his modified procedure to be as productive as possible. One day, my mentor wanted to shadow my deployment day to see how I was doing things. I invited him along and we did the first one. I pulled out my deployment docs and made sure to follow the procedure so I got a good grade. When we were done, my mentor pulled me aside and said, “I noticed you went pretty fast and did some things out of order. Why?” I mentioned that my friend and I had modified the deployment procedure a bit to make it easier and faster. That’s when my mentor hit me with a phrase that I’ve spent a lot of my career deconstructing:

“But this is the way we’ve always done it.”

You Do What You’ve Always Done

Process isn’t a bad thing. It makes jobs easy to break down into steps to assess timelines as well as being able to make a job repeatable. There’s nothing worse than a process that only lives inside the head of one person. If you can’t replicate your job you can’t ever stop doing it. Sure, it may be hard to write things down sometimes but you have to have a way to capture that data.

However, process all needs to make sense. If the process for starting my computer involves pushing the buttons in a certain order, there should be a reason for it. If the process for starting my computer also includes extra steps, such as getting a cup of coffee or banging on the monitor twice, there needs to be a reason for those too. Maybe the employee really likes coffee? Or maybe the startup process for the computer takes long enough that you can get a cup of coffee by the time the login is complete and if you try to do it earlier you’re going to run into slowness or indexing issues.

Documenting the steps is important. You also have to document the reasons behind the steps. Why must we tackle the project in this specific order? If you are doing Task A and then Task B why can’t you do the second task first? If you have no good justification then you should be able to do them in any order. But if Task B requires something from Task A to be able to be completed you need to document that. Otherwise people are going to do them out of order and miss steps.

Going back to our IBM deployment guide, why did there need to be so many reboots in the original document. Well, some of them were necessary. We needed to change the machine name before we joined it to the domain. We needed to log in with the username locally to create the profile before we logged in with the domain account so everything was created properly (this was NT4 domain days). Now, the instructions had us rebooting after every change, which added 3-4 minutes to every step along the way. My friend and I knew we could cut that down and do multiple changes for each reboot as long as they didn’t depend on the others being done first. But the original process was the “way it had always been done” and we had to prove it was better this way.

You’ll Always Get What You’ve Always Got

It’s not enough to challenge the process for no reason. Maybe your way is better. Or faster. Or just easier. But you have to prove it. You have to be willing to examine the process and ensure that what you’re doing is objectively better. It’s like taking a shortcut to work. It may feel faster for you. However if it takes 2 minutes longer on your drive is it really worth it? Or are you doing it because you don’t like driving or walking the other way?

Back to IBM and the laptop deployments. In order to get the revised process approved, I had to prove it was faster and provided the same output. I had to go into the lab and deploy using the old method and capture all the settings and data. Then erase the machine and deploy using the new settings and repeat the data capture process again to make sure the results are the same. Once I could prove that the new process resulted in the same output, we could move on to the second step.

Step Two involved timing the deployment. Now, in order to make sure I wasn’t juicing the numbers in either direction, we had our oldest, slowest laptop deployer use the new instructions. He would regularly take over an hour to setup a new machine with the old directions. We handed him the new page and told him to use this instead. Same steps, just in a different order. He went through them all cold twice and managed to average around 45 minutes for his deployment. He even remarked that our process was better.


Tom’s Take

Once we had it proven that it was faster and easier to do the things the new way we updated the deployment procedures before the next group of interns arrived. I had left my mark on things and proven that “this is what we’ve always done” isn’t always the best justification for things. But you do have to justify why your way is better. Facts beat opinion every day of the week. And if you aren’t willing to do the work to prove why you can make things better, you’ll always be where you are right now.

Changing The Baby With The Bathwater In IT

If you’re sitting in a presentation about the “new IT”, there’s bound to be a guest speaker talking about their digital transformation or service provider shift in their organization. You can see this coming. It’s a polished speaker, usually a CIO or VP. They talk about how, with the help of the vendor on stage with them, they were able to rapidly transform their infrastructure into something modern while at the same time changing processes to accommodate faster IT response, more productive workers, and increase revenue or transform IT from a cost center to a profit center. The key components are simple:

  1. Buy new infrastructure from $vendor
  2. Transform all processes to be more agile, productive, and better.

Why do those things always happen in concert?

Spring Cleaning

Infrastructure grows old. That’s a fact of life. Outside of some very specialized hardware, no one is using the same desktop they had ten years ago. No enterprise is still running Windows 2000 server on an IBM NetFinity server. No one is still using 10Mbps Ethernet over Thinnet to connect their offices. Hardware marches on. So when we buy new things, we as technology professionals need to find a way to integrate them into our existing technology stack.

Processes, on the other hand, are very slow to change. I can remember dealing with process issues when I was an intern for IBM many, many years ago. The process we had for deploying a new workstation had many, many reboots involved. The deployment team worked out a new strategy to streamline deployments and make things run faster. We brought our plan to the head of deployments. From there, we had to:

  • Run tests to prove that it was faster
  • Verify that the process wasn’t compromised in any way
  • Type up new procedures in formal language to match the existing docs
  • Then submit them for ISO approval

And when all those conditions were met, we could finally start using our process. All in all, with aggressive testing, it still took two months.

Processes are things that are thought to be carved in stone, never to be modified or changed in any way for the rest of time. Unless the stones break or something major causes a process change. Usually, that major change is a whole truckload of new equipment showing up on the back dock attached to a consultant telling IT there is a better way (TM) to do things.

Ceteris Paribus

Ceteris Paribus is a latin term that means “all else unchanged”. We use it when we talk about having multiple variables in an equation and the need to keep them constant to be able to measure changes appropriately.

The funny thing about all these transformations is that it’s hard to track what actually made improvements when you’re changing so many things at once. If the new hardware is three or four times faster than your old equipment, would it show that much improvement if you just used your old software and processes on it? How much faster could your workloads execute with new CPUs and memory management techniques? How about collapsing your virtual infrastructure onto fewer and fewer physical servers because of advances there? Running old processes on new hardware can give you a very good idea of how good the hardware is. Does it meet the criteria for selection that you wanted when it was purchased? Or, better still, does it seems like you’re not getting the performance you paid for?

Likewise, how are you able to know for sure that the organization and process changes you implemented actually did anything? If you’re implementing them on new hardware how can you capture the impact? There’s no rule that says that new processes can only be implemented on new shiny hardware. Take a look at what Walmart is doing with OpenStack. They most certainly aren’t rushing out to buy tons and tons of new servers just for OpenStack integration. Instead, they are taking streamlined processes and implementing them on existing infrastructure to see the benefits. Then it’s easy to measure and say how much hardware you need to expand instead of overbuying for the process changes you make.


Tom’s Take

So, why do these two changes always seem to track with each other? The optimist in me wants to believe that it’s people deciding to make positive changes all at once to pull their organization into the future. Since any installation is disruptive, it’s better to take the huge disruption and retrain for the massive benefits down the road. It’s a rosy picture indeed.

The pessimist in me wonders if all these massive changes aren’t somehow tied to the fact that they always come with massive new hardware purchases from vendors. I would hope there isn’t someone behind the scenes with the ear of the CIO pushing massive changes in organization and processes for the sake of numbers. I would also sincerely hope that the idea isn’t to make huge organizational disruptions for the sake of “reducing overhead” or “helping tell the world your story” or, worse yet, “making our product look good because you did such a great job with all these changes”.

The optimist in me is hoping for the best. But the pessimist in me wonders if reality is a bit less rosy.