The Big Picture for IT

Information Technology as a department of mainstream businesses has a very short history. Accounting departments have been around as long as banking. The Marketing department has existed as long as advertisements have existed. Many executives in institutionalized businesses started before their companies even had a server, let alone smartphones, VOIP, or data centers. Businesses don’t bother hiring an IT person until their systems are broken more often than they’re working, and then they’re hired for their ability to fix broken computers and not their ability to lead the company into the future. This has been the status quo for so long that it has become institutionalized.

Most institutions think of Information Technology as a tool: you ask for it when you need it, but you expect it to sit silently in the shed until then.

And you can feel it.

It’s a familiar feeling.

It’s the feeling of being picked last for kickball.

It’s the feeling of getting calls only when someone needs your time, not to offer you theirs.

It’s the feeling of having your stomach sink when you get an email from a C-level executive because you know it’s bad news. Or of having your spirits fly when you get that email, because you haven’t heard from them in weeks.

It’s how IT has operated for 30 years – perceived as just above Facilities, but with Masters degrees.

And it cannot last.

Just as computers are no longer just an upgrade to typewriters, IT professionals can no longer be viewed as an upgrade to electricians.

Information Technology must have an active role in leading the ongoing development and future direction of business. We need to stop waiting for the phone to ring. We need to stop waiting for the emails to arrive. We need to make the phone calls that make the changes we want to see.

And we need to do it ten years ago.

Goals vs. Problems

I have come to understand that I am “problem oriented” rather than “goal oriented”.

This is not a question of pessimist or optimist. This is a question of how you look at what needs to be accomplished.

A “goal” is the end product that you wish to bring to fruition. A “problem” is what keeps that goal from becoming a reality. So, a goal might be to increase revenue by 20%; while the problem might be that your revenue isn’t as high as you want it to be. They are obviously very closely related. And I am not saying that my way is the correct way to see things, just a different way.

In my estimation, a goal cannot be achieved without overcoming a number of problems that keep it from happening. Once that goal is achieved, progress on the issue ceases. You made your quota, now you can move on. But problems may remain. Problems are what keep perfection at bay. Problems are the difference between 20% better and 100% perfect. Problems never cease.

Don’t get me wrong, I am not one who can’t see the big picture. I don’t think you can see the problems without grasping the big picture first. I just think that goals are short sighted. Goals are settling for “good enough”, or, at least, “better”.

Now, I can see it from the other side: problems are only a small piece of the bigger goal. A problem can be overcome, but the goal is what motivates the problem solving. I get that. But, for me, the problem itself is the driving force. The goal is one by product of problem solving.

We shall see how this mentality works out. I know that perfectionism is not always the most desirable trait in a person and can cause conflict, but I think it is also what drives me to constantly improve rather than settling for good enough.

Ending Joblessness (Update)

I spent a good amount of my short time in Chicago interviewing for jobs. That was my goal well before departing, so I’m glad I was able to make that work out.

Here’s one such story:

Upon arriving in Chicago I got a phone call from one company that I applied with wanting to schedule a phone interview. They didn’t know that I was in Chicago and could’ve done it in-person, but the phone interview was good. Mostly a lot of predictable form questions that I have come to expect and have pretty good answers for – “How do you like to solve problems?”, etc. This interview, I thought, went well, despite the fact that I had to jump off of my train mid-route and conduct this interview on the side of the road in Roger’s Park. I must have done pretty well, because the cheery HR woman on the other end asked me if I would do a second interview with the I.T. Manager.

The I.T. Manager called me a couple of days later read through a list of technical questions for an hour. Seriously. “What’s the difference between SATA and IDE?”, “Can you give me an example of a MAC address?”, “What is an IP address?”, etc. This bothered me for a couple of reasons, which I’ll get into later.

After this awkward exchange of information, I was asked for a third, on-site interview.

When I applied for this job, I knew that it wasn’t especially close to my home in Chicago. Going to the on-site interview gave me a whole new understanding of “long commute”. I missed rush-hour, but it still took me almost an hour of driving to get there. I had to take three highways. One of them was a toll-way.

I got there a little early and started doing some math on the back of an envelope (literally). That commute was going to be about 30 miles each way, at about 22 MPG, or 2.7 galons. At $4.50/gal, it’d be $12.15 per day for gas, plus $1.60 for the tolls, or $13.75 per day for the commute. Twenty days in a month at $13.75 is $275 per month and $3,300 per year. Plus 2-3 hours per day of my time.

Going into the interview, I knew I was going to be asking them for A LOT more money than I would be if it was going to be a short commute.

This interview was a little more loose and informal, but I was still being asked the kinds of questions that a brand-new HR person reading “Interviewing for Dummies” would come up with. And this was with the I.T. Manager. Who would be my boss. My requested salary was “within the range” of what they were willing to pay, I was told, but I still had my doubts about the job.

When I got home, I emailed the cheery HR woman and told her that I wasn’t interested. Here’s what bothered me:

1. The company claims that it is doing things to help the environment and reduce their impact, but any employees who live in the nearest large metropolitain area have to commute ~30 miles to get there.
2. The commute was unreasonable. No way am I driving >2 hours per day to get to a job…at least not for very long.
3. The working environment was dead. Cubicles too tall to see over, no noise, no fun, a boring office park in the middle of ticky-tacky little boxes, all the same.
4. Not to insult anyone, but the interviews were awkward, long, and impersonal. The interview questions might as well have been a web form. They revealed nothing about me and guarantee that you will only get even more people like your current I.T. staff.

I can do better.

Oh yeah, and the reason being quizzed about I.T. stuff bothers me? I’ve spent the last 10 years of my life working with computers and the last 5 in a verifiable, professional, hands-on way. Being treated like I’m lying on my resume makes me wonder how I’m going to be treated at work. I don’t mind being asked a few higher level questions by someone who knows what they’re asking, but an hour long vocational-school level test of minutiae is not appropriate in my opinion. For a great discussion on the topic, see this Slashdot forum.

Process Management

…is turning out to be more a part of my life and this job than I expected.

Right now we’re implementing a new business management system. It is, in fact, the reason I am staying on another month after I’ve “moved” to Chicago.

As some of you may know, I already did this once at this job. But the last one wasn’t all-inclusive and lacked important features (CRM, accounting, parallel workflows, splitting and combining jobs, etc.) that made us immediately begin shopping for a new one. The one we chose (TQT) has everything we wanted, with the flexibility to allow us to build it to reflect the way we do business.

The problem is that it has the flexibility to allow us to build it to reflect the way we do business – even if we’re doing it wrong. In comes “process management”. This is where we figure out what we’re doing and how we could be doing it better, faster, stronger. Maybe not stronger.

Building good processes means not only figuring out how to build processes that work, but figuring out how to break the process.

This is much like programming. It’s easy to build programs that work when you have a well trained, well intentioned user. It’s much harder to build programs that still work when you have a poorly trained user. And if your well trained user is malicious, too, you have to think of everything.

Hopefully we won’t have to deal with malicious users. And once this system is implemented, we should have everyone trained. But still…

“Hope for the best, plan for the worst.”