I’m going to tell a story on myself. It’s a lesson I learned a few years ago, and it’s one that many upstart IT professionals could stand to learn. The lesson is simple: If you’re given an assignment you don’t like, don’t bother trying to fake it. Pay the dues and master the task, or your procrastination will come back to haunt you.

Just learn it
Several years ago, I was the IT manager for a midsize company. I was a one-person shop, so I wore many hats—developer, troubleshooter, trainer, and system administrator.

I loved development work more than any other activity, so I tended to put in more time on those projects than the other assignments that were on my plate. One day my boss, the CFO of the company, informed me that he wanted me to “learn the accounting system.” It was a proprietary system that was used by only one department in the company. It had been put into place years before my manager or I had joined the company.

I didn’t want to touch that system with a 10-foot pole, but I couldn’t “just say no” to the assignment. So I put off learning it.

Luck only lasts so long
One day, the lady who’d been the main user (in fact, practically the only user) of the system was out of the office, and I was called up to run a report. That day I got lucky. I was able to use the RTFS (“read the full screen”) method to figure out how to run the report that was needed. I still hadn’t bothered to drill down on this particular application.

The next time I was called to answer a question, I couldn’t find anything in the onscreen help text to answer the question. However, I lucked out again. I made a quick call to the tech support hotline and connected with a technician who helped me zoom in on a solution. But I didn’t learn my lesson. I went away thinking, “Man, that system is a piece of junk.”

Then came the moment of reckoning. My boss told me to “get over to accounting right away.” The system had crashed—naturally at the worst possible time, during the month-end reporting period.

I was SOL—sorely out of luck. I had to admit to my boss that I hadn’t yet taken time to bring myself up to speed on issues such as how to revive this system, where the backups were stored, or how the restore utility worked. The vendor was in a different time zone, so I couldn’t even call for help. (Eventually we straightened everything out, but my credibility took a big hit that day.)

Do the homework NOW
I’m friends with a number of developers who find themselves in similar positions. Just because you don’t like a project doesn’t give you an excuse for not making yourself an expert on the subject matter. You’ve got to do things like:

  • Take the manual home and block out the time it takes to go through it.
  • Spend some extra time at work getting familiar with the system from the perspective of an end user.
  • Communicate with the people who use the system on a daily basis. Find out what their concerns are, and figure out a way to serve those in-house clients better.

Is there someone in your shop who’s shirking his or her duties?
Do you know someone in your shop who refuses to put in the time it takes to come up to speed on a given product or project? To share your experiences or thoughts on this subject, please post a comment below or drop me a note.
Each Tuesday, Jeff Davis tells it like he sees it from the trenches of the IT battle. And you can get his report from the frontlines delivered straight to your e-mail front door. Subscribe to Jeff’s View from Ground Zero TechMail, and you’ll get a bonus of Jeff’s picks for the best Web stuff—exclusively for our TechMail subscribers.