One of the most interesting personnel phenomena that I have seen in the IT world is a person I call the “Band-Aid.” This person has several positive traits:

  • Hard working
  • Constantly getting into the middle of every problem to understand the cause
  • Does not finger-point
  • Works well under pressure

This person also has several negative traits:

  • Takes on more than his/her capabilities
  • Does not have clearly defined roles and responsibilities
  • Afraid to say no

The making of a Band-Aid
At one company I was assigned to as a consultant, there was an application server administrator whom I will call Jim. Jim was the most willing guy you’d want to meet. Every time there was a problem, he was in the middle of it. He shied away from nothing. Usually, eight or more people would stand around Jim’s PC. He always figured out a solution. Unfortunately, 90 percent of the time it was a manual solution.

The next day, the same problem would rear its ugly head. People would phone Jim and he would fix it again…manually. Everyone would be happy.

The next day, the same thing would happen. Again, everyone would call Jim and he would fix it…manually. Everyone breathed a sigh of relief.

Guess what would happen the following day? History would repeat itself. The same people would phone Jim and he would fix the problem…manually. Everyone would be frustrated.

…You get my point.

Of course, new problems have a way of occurring when you least expect them. And they did. Instead of one, Jim might have had two or more problems to fix…manually. At this rate, Jim was manually fixing well over 17 problems a day. He showed up every morning with baggy eyes and sloped shoulders to a cubicle filled with people demanding that he solve the next round of problems.

Slowly, everyone grew angry and frustrated with Jim. Jim was always the one that corrected the problem, so it must be his code that was breaking all the time. Management was getting irritated. “What is the problem, Jim? The application server?”

The nightmare of a Band-Aid
Finally, the day came when Jim’s wife, who was sick of him working 17-hour days, told him that he was going on vacation. Jim’s manager agreed and asked another consultant (yours truly) to cover for him. On the first day of Jim’s vacation, I could hardly fit into the cubicle because there were so many people in it. “The application is frozen again!” “We ran out of Oracle cursors!” “The data migration failed last night!” “Sometimes my arm hurts when I go like this!” Find a different problem, please.

I told them that I would address each problem individually. There is no time, they complained. Fix the problem and let Jim deal with it when he gets back. I started investigating the problems by running production in debug mode. I began scratching my head and pressing my throbbing temples as the errors started spewing across the log screen.

Jim’s manager dropped by his cubicle to see if the good little consultant needed anything. I bared my best consultant-smile and explained in layman’s terms how each of these problems were not problems with the application server. I was frustrated at having all these problems dumped on me and there was nothing that I could do to solve them.

We called Jim in Canada and asked for a moment of his time, before he began luging. I went down the list of problems that had been handed to him to solve. As Jim began explaining the solution to each problem we discovered that Jim was covering up the problems but not solving them. When you solve a problem, it disappears. When you cover up a problem, it will return to haunt you.


If the database is running out of cursors, there are two scenarios. The first cause is that the developer is not closing the database connections. The second cause is that the DBA does not have enough cursors available. Rebooting the application server frees up all the cursors, however the clock starts ticking the moment the users start hammering on the application again.

The meeting about the Band-Aid
All the developers, DBA, managers, users, and I were called into a meeting to discuss Jim’s problems. Quickly it turned into a Jim-bashing fest. The developers and DBA were all over Jim in front of the users and management. I sat scratching my forehead and staring at Rick, the IT manager.

Rick silenced the crowd and asked if I had anything to say. I promptly got up, walked to the whiteboard, and began listing each problem that was being blamed on Jim. I pointed out that the problems were not Jim’s, because Jim was the application server administrator. These were bad coding and database configuration problems that should have been corrected by the developers and the DBA. It is the job of the application server administrator to help identify these problems, but not to fix them. By this time, the developers and the DBA had started looking at their watches, unbuttoning their shirts and chugging their soft drinks.

I had analyzed six problems that were placed on my shoulders, dividing them into three categories: database, code, and application server. Not surprisingly, five ended up in the code section, with one being shared with the database and the application server.

Removing the Band-Aid
My advice was that from now on the developers should solve their own problems. Jim needed to be sent on a course about administrating the application server. He also needed a job description that would not handcuff him but would protect from getting too involved in the solution. Jim’s manager took it one step further and made him telecommute for a month. People would not be able to walk over and dump all their problems on him.

The healing process begins
Make sure problems never persist. A manual solution to a problem is not a solution. A real solution prevents the problem from ever happening or corrects the problem. Jim was a Band-Aid. He was basically holding the entire application together with his bare hands. Without him the application did not work. Perhaps Jim really didn’t want the application to work without him, but sooner or later everyone needs a vacation.

As a manager, a general rule of thumb is to ask yourself, “Do I feel comfortable letting each person on my team go on vacation?” If you don’t, ask yourself why and do something about the Band-Aid. You’ll be glad you did.

Chris McManaman is a business integration architect for RCG Information Technology, Inc., a three-decade leader in IT professional services.