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.