Recently, I was in Colorado for the hands-on assessment portion of a space medicine course (the rest of the course had been taught online). Going in, I honestly wasn’t sure what to expect. This was a beta course, and the course title had changed several times along the way. I had been asked to bring various camping and outdoor survival supplies, but the only thing that I knew for sure was that the course was going to be some sort of mash-up of space medicine, wilderness medicine, and wilderness survival.
In retrospect, the class ended up being really unique. The primary focus ended up being on post-landing contingencies in off-nominal situations. In other words, my classmates and I worked through numerous scenarios in which we simulated the aftermath of a spacecraft crash in a remote, mountainous area. We had to practice things such as removing an incapacitated crew member from the spacecraft, and treating wounds, broken bones, and countless other injuries, many of which would have been life-threatening.
In most of the scenarios, time was of the essence, and my classmates and I were always under the close supervision of medical professionals whose job it was to make sure that we adhered to proper medical procedures at all times. To say that some of the scenarios were stressful would be an understatement.
One of the things that made the scenarios so stressful was that often times my classmates and I did not have the supplies that we needed in order to treat a particular injury. We never knew from one scenario to the next what the situation was going to be, so we never knew what types of supplies we were going to need. However, learning how to cope with a less than ideal situation was one of the big learning objectives of the course.
One of the physicians who was in charge told the class that we needed to think like a medical MacGyver. Since we would often be ill-equipped to deal with a particular injury, we needed to improvise and use whatever we had available to us to get the job done. For example, we used a pair of hiking boots filled with rocks to make a makeshift cervical spine splint. We also used a tree branch, paracord, and duct tape to put a broken leg in traction.
MacGyver IT
On the flight home, I began thinking about the MacGyver approach to medicine, and about how it really wasn’t all that different from the early years of my IT career. Back then, I worked in a tiny IT department whose resources were stretched really thin. As such, improvisation was the order of the day, and the MacGyver approach to IT was the norm. Hardly a day went by when someone didn’t raid the storage closet to cannibalize an old computer for parts, use tape to fix a jammed printer, or make some kind of really obscure configuration change in an effort to resolve a software problem. I even seem to recall using a paper clip in place of a missing jumper on a system board. But would the MacGyver approach to IT work today?
The answer to this question really just depends on the size and type of organization, and on just how ludicrous the MacGyver-like solutions are. Back in 2012 for example, InfoWorld published an article called MacGyver IT: 20 Tools for Hero Hacks. In spite of the name of the article, however, none of the tools or techniques that it covered was really all that outlandish. In my mind, though, MacGyver IT means using the resources that you have available to fix a problem, no matter how unorthodox the solution might be.
So before I get too far into a discussion of MacGyver IT, let me just say in no uncertain terms that the MacGyver approach is definitely not an option for organizations in regulated industries. Health-care providers, financial services firms, and other regulated organizations are tightly controlled, and the potential penalties are too severe to justify taking a chance with rigging a solution to a problem MacGyver style.
MacGyver IT probably isn’t going to be an option in large enterprise-class organizations either (unless your goal is to get fired). Even if such an organization is not regulated, using MacGyver-like solutions to problems typically is not going to be an option, for at least three different reasons.
Why it won’t work
The first reason why the MacGyver approach probably isn’t going to work is because of team-member expectations. Large, enterprise-class IT shops are often segmented, with different teams being in charge of different parts of the infrastructure. Even though a team might “own” an infrastructure area such as DNS or Active Directory, the way that such resources are configured have a direct impact on others. Making a rogue, MacGyver-like change to the Active Directory for instance could easily have unintended consequences for other IT services groups, and for the user base as a whole.
The second reason why MacGyver IT doesn’t work in the enterprise is because it undermines the very thing that makes large-scale management possible — consistency. Let me give you an example. One of the places where I used to work had roughly 25,000 desktops to manage, but a relatively small IT staff dedicated to the maintenance and troubleshooting of those systems. On top of that, this was a very high-security environment.
The only way that the IT team was able to effectively manage so many systems, while also maintaining security, was to use a philosophy that is similar to the one that Las Vegas casinos use to catch cheaters. We did everything in a uniform manner so that any anomalies would be easily noticeable. So with that in mind, imagine what would happen if someone on the support staff decided to be an IT MacGyver. At the very least, their shenanigans would break the organization’s system management model. In this particular case, however, the rest of the IT staff would probably have noticed the change and mistaken it for a security breach.
The third reason why the MacGyver approach to IT is unacceptable in the enterprise is because it can potentially violate a cardinal rule. You should never operate a production system in an unsupported configuration.
OK, I will concede that this rule does not always hold true. Lots of organizations continue, for example, to use Windows XP in production, even though it is not officially supported. The difference, however, is that such organizations know that Windows XP is no longer supported, and have collectively deemed the lack of support to be an acceptable risk given the benefits that the OS provides. That’s a lot different from haphazardly changing configuration settings or rigging hardware to do something that it was never intended to.
Still a place for an IT MacGyver
Even though I made a strong case against MacGyver IT in the enterprise, there is a time and a place for everything. Even to this day, I use MacGyver-like techniques in my lab environment. What I do is deadline driven, and I have to make my lab environments work, even if that means getting a little bit creative. Even so, my labs are completely isolated from my production environment, within which I strive to adhere to established best practices.
Photo credit: Hulu
