The IT Ego

From time to time you come across something in IT that just seems ridiculous. I just happen to come across them more than most because readers send me stories all the time. What I’m talking about specifically is the IT ego… and we’re all guilty of it at one time or another.

It starts innocently enough. You get assigned a project, and you may or may not know exactly how to do every part of it, but you finally get it worked out and it’s up and running. It doesn’t perform as well as some think it should, but not having anything to benchmark it against, everyone pretty much just accepts that some processes just slower than others. Then a couple months later some know-it-all comes in and sees the process you worked so hard to put into production, and craps all over it by telling you that it’s written poorly and he could improve the performance 10x over in just a couple hours. Quick, what do you do? Most people’s first instinct is to let that IT ego step in and insist that it be done your way. Nobody likes to be shown up in front of their peers, and after all, you did work hard on it. It’s not your fault you were assigned something you knew nothing about. Of course, we all know the problem with this. It gets in the way of real progress and of learning. True knowledge is knowing that you know nothing, and I firmly believe that. There isn’t anyone reading this, no matter how junior or senior who couldn’t teach Ken Henderson, or Kimberely Tripp something about SQL. We all have different experiences. And nobody knows everything, and the super-mega SQL gurus will be the first ones to tell you so. I’ve never met anyone who was considered a world leading expert in SQL who wasn’t relatively humble about their skills. And it’s almost certain that the guy who comes along and improves your process will probably need your help one day.

The problem comes when you get the ones who just refuse to let go of their pride and improve things. They coded it, so it must be perfect, and there’s no room for improvement. And there’s certainly no room for others in the company to find out they don’t know everything. It puts everyone in a bad situation because hundreds of people have to live with your lousy process. It may not have even been written badly. It may have been written fine for the technology or situation available at the time, but now things have changed that make other options viable. In fact, that’s really the best way to approach someone like that. Hey listen, I like the process, but SQL has this new feature that really improves this kind of thing and it would be great if we could take advantage of it. In fact, I was talking to a friend of mine a MS and he told me that they want people using this new process, so they’ve actually made the older one perform much worse. That’s why your process is so sluggish. MS has sabotaged you. And since we’re not going to change their minds, we’d might as well roll with the punches and implement their new method so they’ll at least support us if we need it.

I’ve found it’s best to stroke their egos for stuff like this, because it’s nothing to me, and it’s really the results that matter. The process needs to change, and it doesn’t matter how much you have to butter them up to do it. I actually used this a couple years ago, and the guy believed every word. Of course, the exact improvement I was talking about at the time had been around for years, but since I didn’t use it to begin with, I figured he hadn’t heard of it. I was right.

The point is, let’s get around those egos people. I’ve been guilty of it at times, and I actually had to take a step back, swallow my pride, and say, you’re right. Your process is better. Thanks. Then I limped away and felt small for a couple days while my ego healed. It actually takes a lot of experience to understand that you don’t know everything, and I do it most of the time. But I’m sure I’m still guilty of it sometimes. It’s called being part of a team.

OK, I’ve officially dismounted my high horse.