Appreciating Complexity

For four years, I played the French Horn in school. I learned a fair amount about music. Mainly, I learned how difficult it was to write music. Not just writing it, but also performing it at a high level. Once I understood that, I gained a new appreciation for musicians. It doesn’t even matter whether I like their particular music or not. I can appreciate the skill required to create and perform music. I have a fair amount of albums by musicians that some people think are garbage. One of those is John Tesh. When I would ask why they didn’t like his music, it was usually because it was too soft or boring for them. If they were a sports fan, I might actually play them a song from John Tesh’s Victory album. It contains an assortment of songs that have been used in various professional sports broadcasts. They would hear it and say something like: “I know that song. They play it during NFL or NBA games.” Sometimes, their opinion might change a little because they can now associate him with something they enjoy, or something they understand like sports.

Music is something we are all familiar with. We can play a song and just enjoy it for what it is. When we understand what is involved in creating it at a much deeper level, we can enjoy it even more. We are no longer just listening to simple song. We’re picturing the musicians that have practiced over and over until they produce a perfect product.

The Problem

 
Apply this same concept to what we do in the IT world. There is an art form to taking hardware and software and making it perform at a high level. We poke and prod and tweak our infrastructure to squeeze every ounce of performance out of it. We work nights and weekends to ensure everything is running as it should when the users come back in to the office each morning. We’ll spend hours and days plowing through logs to find out why an application is running a few milliseconds slower than it should. We do all this, and yet plenty of times, the IT department is seen as a cost center. A black hole for money. The IT people are expensive, and the equipment they work on can sometimes cost more than most people’s homes.

In many organizations, every dollar has to be justified and each additional IT body required is debated and debated. Do you REALLY need that extra person? Can’t you just handle it with the current staff? Can we outsource that function? Is maintenance REALLY required on all of that hardware and software? Certainly the vendor can come down on the price. Certainly that reseller can charge less. $150 an hour seems rather expensive for a consultant to come in and perform a routine upgrade. Why can’t our own people do that? The list goes on and on.

I’m not telling you anything you don’t already know. The problem has always been a lack of understanding on the business side when it comes to technical things. Of course, there is something to be said for engineers who just want to buy the latest toy because it is new and shiny. They don’t do IT departments any favors. Throw in the vendors and resellers that oversell a solution under the guise of “future proofing” the network and you have an even bigger problem. These days, there seems to be a push for the technical folks to understand the business requirements. I can’t disagree with that push. While I still contend that I don’t need an MBA to understand how to make the business successful, I DO need to understand the direction the business wants to go in to make sure I propose and implement the right solutions at the right cost. Sometimes those solutions don’t involve buying more hardware or software. Sometimes those solutions require more bodies or simply refining processes or advocating standards.

In a perfect world, the business would understand the technology and the IT department would understand the business. We don’t live in a perfect world, so we have to work around imperfect humans and imperfect execution. Maybe there’s a different approach to take for one side of that equation. I propose that if the business can appreciate the complexity of IT, they will tolerate it a little more. I suppose that already happens in plenty of organizations, but I still run into quite a few where that isn’t the case. I also understand that we all get paid to perform a certain role. I shouldn’t fault the accounting department for not having a thorough understanding of all things IT, just like the accounting department shouldn’t expect the IT department to have a thorough understanding for all things finance.

If I Ruled The World

 
This may all be a pipe dream on my part, but if I were trying to build a better appreciation of all things IT within a business, I might do the following:

1. Be nice. – There are plenty of stereotypes regarding IT people, and one of them is that they talk down to their end users they support. If you plan on making a career out of IT, you have to accept the fact that when people call you with a problem, it is usually because something is broken. They aren’t calling to tell you how good a job you are doing. They are reaching out because something is preventing them from doing their job properly. The best thing you can do is hear them out and assure them that you will take care of it as quickly as possible. After all, you are there to support the business and not the other way around. Yes, there are some people that are never happy, but I have found that most people are reasonable as long as you take the time to explain what is involved in fixing the problem. Sometimes, the end users can help you fix their problem even faster by sidestepping corporate bureaucracy via their management chain. If they know you are genuinely trying to help them, they’ll do what they can to remove any barriers within their control. However, if you treat them like idiots, they might take pleasure in seeing you struggle through the various obstacles you come in contact with when working on their problem. Be nice. It can only help you in the long run. The more allies you build in the various departments, the better your chances of getting what you need to be successful in your job.

2. Explain as much as they will let you, but do it in small increments. – People are naturally curious. I always like to explain as much as they will let me. Using analogies and examples they can relate to will help them understand technology that much more. However, I also don’t try to bombard them with more information than they are able to absorb in that particular moment. Over time, they’ll understand more and more and will be even more helpful when they encounter another problem down the road. At least, that has been my experience. I’ve never had an interaction with an end user where I told them that they gave me too much information. Successful problem solving can often come down to one little piece of information that would have gone unsaid had you not pried it out of them. If they know more about technology, they can give you better information to solve their problem. I know next to nothing about cars. Anytime I need work done on a car, I always want to know what the problem was and how it was fixed. I’ll ask the mechanic numerous questions about it. If something similar happens again, I am able to give better information to the mechanic in the hopes that it will help them come up with a solution quicker, and thus cost me less to fix it.

3. Know your infrastructure. – You MUST know as much as you can about how the software and hardware you support works. You cannot be content with simply being a tactile engineer and just pointing and clicking your way through your job. Of course, this has to be tempered with the level of depth required for your position. In larger departments, there are usually senior people that you can ask for greater understanding. In smaller departments, there might not be anyone else. Leveraging consultants, social media, or everyone’s best friend Google, can help out tremendously in that regard. It isn’t acceptable to be content with not knowing. Find an answer.

4. Spend what you must, but no more. – Focus on needs and not wants. If you have to fight for every dollar you spend, make sure you are only buying what you need. If you have a room full of unboxed equipment that exceeds normal spare levels, there’s a problem. If you bought some fancy software package that you just had to have and ended up not using it, there’s a problem. If the business knows you are cognizant of how much money you spend on gear, you’ll have an easier time when you need extra funds for something that wasn’t budgeted for. If you are able to explain in great detail why you need that upgrade or net new purchase and tie it to the success of the business, you’ll have a lot more wins than losses. If you are allowed to spend money at will and with little oversight, at some point, someone will shut off the money and you’ll have a harder time in the future getting projects funded.

5. Consider “A day in the life of IT” programs. – This one is probably the most unrealistic point, but it still bears mentioning. One of my friends in high school had a father who was a career police officer. One night, I rode out with him on the night shift. He was a shift supervisor, so a fair amount of his time was spent directing various officers here and there. I learned a lot in one night about the various things a police officer does in the course of their shift. It was an eye opening experience. By simply observing what he did and asking questions for clarification, I learned to appreciate how difficult that job can be. It helped me to understand why some officers might seem annoyed when interacting with the various citizens of whatever jurisdiction they work in. I’m not saying cops can do no wrong, but I gained a little more insight into their thought process. I can understand their lack of trust with people they come into contact with. In short, it helped me see things from their point of view. While I am sleeping soundly in bed at night, they are dealing with things I very rarely experience, and they do that every shift. If you could get people outside of IT to just come hang out with a few engineers for a half day or so, they might gain a better appreciation for how much work is involved in keeping a network up and running. This, coupled with my first two points(Be nice and explain as much as they’ll let you), can go a long way in building better relationships with departments outside of IT. While I don’t expect the CEO of a large corporation to come hang out with IT for several hours in a day, it would be great if they did. Just make sure than when people do something like this, that you aren’t sitting around surfing the Internet and reinforcing stereotypes that all we do in IT is play on the Internet instead of fixing problems.

Closing Thoughts

There are no easy answers to narrowing the gap between IT and the business. I could put it all on management within IT(ie CIO, CTO) and say that it is their problem. Unfortunately, that doesn’t do anything to help the problem. Everyone in the IT department has to help the business understand that we are there to enable them, but that it comes with a price tag. Getting businesses to view IT as something other than a cost center can make things a lot better for that IT department in terms of funding and head count.

 
What do you think? Is this just a bunch of unrealistic babble? Or, do you think that giving people a greater understanding of the complexities of IT will help?