Business Tech: Perspective

I gave a speech to CMUG once where I started by showing the group a PCMCIA broadband card (figure A). I explained that my then-current computer can only use PC-Express cards, which are smaller. My wife had found me a reasonably priced PCMCIA-to-PC-Express adapter, which I plugged into the card (figure B). Finally, I pointed out the need to occasionally use the card in the old computer — and put a PC-Express-to-PCMCIA adapter on to the other adapter (figure C). This, I explained, was a series of good ideas that, collectively, form a bad idea.

Remember that bad idea, as we talk about perspective. Our viewpoint is informed by our own, personal series of decisions. Likewise, the people we talk to will have their own experience set, which will create their viewpoint. We live in the weeds. Our perspective is often tied to that low-to-the-ground position. Other people see things from a different angle. I was talking to a buddy recently and he said, "Don't they understand that they are doing it wrong?" I looked at him and pointed out that the mythical "they" in this story were getting the results that "they" wanted, without spending the money required to do it right. From where he sat, it was wrong, but from where his bosses sat, they were doing it right. We want the world to resolve to one truth, but it doesn't.

Bad Code On The Rise

I was hired by this one company who needed me to fix years of bad code. I was worried that I might get dragged into the day-to-day, and never get a chance to do what they originally hired me to do. It was bad code, and I wanted to fix it. I needed a compelling argument. How bad was the code? The code had wrested the company from the jaws of bankruptcy. The code put them on a profitable track. How could that be bad code? Here's the answer I wanted to give: The code had multiple reads and writes of the same records. It had single letter variables. It had hundreds of lines of dead code intermixed into the programs, making the code hard to read. It was laced with GOTO statements, some of which bent back upon itself. There were dozens of programs which were only a few lines different from each other. It used horribly inefficient code. Here's the answer we actually gave: The code can't be proved, so we are losing hundreds of dollars of manpower in re-re-re-reading the code each time a problem is reported. Maintaining this much code will require us to keep adding employees without adding features or functions. Code which cannot be proved will fail an audit. The second thing that sold them on the value of cleaning the code? One of the other IT guys grabbed a program that had been cleaned, and showed management the Before code and the After code. Good structure and good variable names in the clean code meant that the manager, who had never written code himself, was able to guess his way through the program with near perfect accuracy. The Before code was just letters to him. It imparted no content or context.

Risky Business

I was in another conversation where the tech bemoaned the fact that management wasn't paying attention to a specific business — not technical — need. He pointed out to me that he'd been around long enough to know that management didn't see technical issues as he did, but this was business. He was correct; they were doing it wrong. The reason his perspective didn't match their perspective came down to facts not in evidence. Management knew — but he did not know — that the issue in question represented a fraction of one percent of the business. Ultimately, they did agree with him, but fixing that issue was too far down on the list to be contemplated. So, functionally, it was permanently off their radar. Unfortunately, even when everyone agrees on the truth, we can still end up in a disagreement because not everyone has every fact. I've certainly seen the reverse, where us "weed people" know things not in evidence to the "10,000 foot people" at the top. How we communicate our "secret" facts can bring us success or bring us trouble. We need to know our audience when we speak.

A Bridge Too Far

There was a meeting in which one of the executives said that one of the "code monkeys" believed that the third party code we were using was inaccurate. When someone else in the meeting attempted to use the same term — code monkey — when referring to me, she was corrected with the statement: "No, Chuck isn't a code monkey. Chuck is more of a bridge." I cherish being a bridge. Any time people outside of IT see me as a translator, they see me as someone with whom they can talk. That sense that I can be approached gets me included in conversations which decrease the number of facts not in evidence. Having the same information, and working at using the same perspective, allows me to win the arguments that I should. It also helps me avoid starting arguments which will never go well. Before you think I'm painting myself as a superman, please realize that most of my bosses have never been sure exactly what I do for them. Even someone with excellent "bridgework" is facing a continuous uphill climb.

The Secret To Your Success

Like every Business Tech column, the value isn't in my storytelling. The value comes when it happens to help you. Not every column applies to every reader. Not every column is on your desk the day you need it. Making this one work is not about waiting for the moment. It is about creating moments. Bridge-building is a constant event. You can't simply always be on topic and on target when the situation hits. You need a reputation for being the right person. That means that you need to think about being a bridge at all times. Some of us are in massive, mega-multi-sized companies. Most of us, however, are probably in a more intimate setting. The smaller the venue, the better chance you have to be seen as part of the team, and not as "That Guy From IT." Even in the massive companies, it can be done. Most big companies have an entrenched tradition of keeping your bosses half in the dark. If they don't know, it is hard for them to clue you in on things. Wherever you work, there are always opportunities to know your audience. The most successful consultants are the ones who take this same approach. You never want to be on the opposite side of the table from management. You want to be seen as on their side.

All too often, IT, HR, and other departments are seen as outsiders, despite being part of the same company. The reason is often the gulf between what we see and what everyone else sees.

Featured:

Nov/Dec 2012