Employee discipline: Overcoming your own lame excuses

Many IT managers find disciplining employees difficult, if not debilitating. In this week's Artner?s Law, Bob Artner identifies two weak excuses managers make for not taking employees to task.

As an IT manager, after a time you realize that there are certain inalienable facts about your job. First, there will always be more projects in your queue than your department has time to finish. Second, vendors never come in under estimated costs. Third, there’s never a good time for you to take a vacation. (More on that topic next week.)

Here’s another one: No matter how good your staff is, from time to time you’re going to have to discipline an employee for performance issues. Surprisingly, while most technical managers I know jump right in on any current technology problem, they are strangely reluctant to tackle personnel problems until a crisis erupts. In this column, I’m going to look at a couple of the excuses you may be using to avoid dealing with employee discipline and provide you with reasons for doing what you know deep down is the right thing to do.

Great excuses for not doing your job
All managers realize that dealing with problem employees—as well as good employees who occasionally screw up—is part of the job. In fact, it’s one of the biggest parts of your job. However, it’s not very pleasant. Therefore, in order to avoid having to deal with something that’s unpleasant, we make excuses to ourselves to justify our behavior. Here are some of the most common excuses we tell ourselves.

The indispensable man–or woman
This is the granddaddy of all excuses. We tell ourselves that we simply don’t dare discipline a particular employee because that person is critical to making things work: I know that Joe (or Joanna) is out of line, but he (or she) is the only one who understands X. Now X could be anything: a particular piece of hardware, a troublesome vendor, or some spaghetti-laden legacy code. Whatever the specifics, the results are the same: You determine that the risks of dealing with the performance issue are so great that the employee is, for all intents and purposes, untouchable.

Notice for a second how that logic rests upon some assumptions. First, what is the risk of calling in the employee and confronting him or her about his or her behavior? Why do we assume that the person in question will always quit? Believe it or not, most employees know when they cross a line, and while they don’t have to like it, most will usually respect the manager who calmly corrects them.

As a practical matter, if an employee is sensitive to criticism, it’s probably because previous managers abdicated their responsibilities earlier and let them get away with minor excesses, creating a snowball effect.

Not too long ago, I talked with a talented IT professional who disparaged his boss as not being tough enough. “After all,” he said, “look at what he lets me get away with!” Granted, he was being unusually candid, but I’m willing to bet that most IT professionals would prefer to work for someone they respect rather than someone who lets them do whatever they want. Sometimes being the boss means being the one to say “No.”

Finally, is the person in question really that unique? Isn’t there anyone who could pinch-hit in an emergency? We’ve talked before about needing to treat your org chart the way a football coach looks at his depth chart. (See “Think about the org in your org chart.”) Aren’t your people documenting their work? Aren’t you making sure they cross-train each other? The bottom line: If one of your people truly has no backup, then you’re not doing your job.

The indispensable project
This excuse is related to the earlier one. In essence, we’re saying that while the person in question may not be indispensable, the project that he or she is working on is so critical that you can’t risk any delays that might accrue from confronting the employee about the performance issue. Just let me get X finished, and then I’ll deal with Joe (or Joanna).

This excuse suffers from the same fuzzy thinking that mars the earlier excuse. For one thing, it also assumes that any kind of discipline will so upset the employee that the project will suffer. For another, it assumes that finishing a particular project is your organization’s most important goal, overriding any other considerations.

This excuse also suffers from a unique flaw–the idea that after the current project is done, you’ll be free to finally discipline the employee in question. The fact is that as a technical manager, you’ve always got a project to work on. Thinking that there will be some point in the future when things slow down is a fallacy that you should jettison as soon as possible.

Do it for the rest of your staff
During our look at both of these excuses, we’ve been concentrating on the perceived opportunity costs of disciplining a particular employee. While we often overlook them, there are opportunity costs for not disciplining that employee. First, if that employee finds out that you don’t feel you can discipline him or her, what do you think will happen? If nothing else, you’ve provided a powerful incentive for that person to push the envelope even further.

More importantly, think of the rest of your organization. They no doubt know about the employee in question’s problems. Are they likely to see your forbearance as an act of generosity—or weakness? Even worse, what if they interpreted your actions as indifference? For all these reasons (and many more that space prevents our detailing), don’t delay.

Methods of discipline
How do you discipline employees? Let us know by posting a comment below or e-mailing.

Editor's Picks

Free Newsletters, In your Inbox