Firing David Lightman

Got quite a few emails about my recent article No Profit in a Fast Employee Axe dealing with the situation where we had to eventually fire an IT employee for low performance. As you note from the article subject we want to dig into human elements of our profession at times and not always the tech stuff. This article seemed to hit a chord with many readers. In the extended entry for the blog entry I have some reader comments and some of my responses.And, bonus prize for the person that can tell me where I came up with the alias of David Lightman. (well, no prize, but I will give you profs here on the blog) Feedback from Reader "CS"One reader vented his unhappy experiences with a call center. In my reply I noted that I am always open to listen and draw parallels back to our RealityIT articles. I explained that in his case he was dealing with a call center, not a traditional helpdesk. But I agreed that the theme of poor customer service is frustrating. And we all would agree that customers (internal or external) deserve proper service.

Excerpts of Email from Reader CS:I read your column in the current issue of Network Computing and don???t quite agree with your stand on gentle and gradual correction of poor help desk employee performance."

I have a small retail sales company that does quite a bit of shipping to addresses in the U.S. About a year ago I switched nearly all of my shipping business from and to because their rates were about 30% less than either of the other two companies.

However, during the next several months I encountered 4 different glitches or bugs while using the website to process my shipments. I contacted their tech support desk on each occasion, and was effectively helped only once. Two of the three times that my problem was not solved I was given incorrect solutions to the issue. The third time, the help desk employee simply told me, ???That???s just the way the system is. Sometimes it doesn???t work. Just try it again tomorrow and it will probably be okay.???

I have subsequently stopped using for any of my shipping. I guess that means I am willing to pay 30% more for a service in order to avoid bad technical support experiences.I understand that my experience with may not be directly applicable to the situation in your column, in that the problem at seems to be systemic rather than limited to just one employee. However, my point is that lost my business after a relatively small number of negative contacts with their technical support help desk, and I don???t believe I am alone in my willingness to rather quickly abandon a business relationship based poor technical support.

No other client-contact department has a more critical impact on a company???s client retention rate than the technical support desk, and while protecting your employees is a commendable policy you have to be very quick to act on negative performance in order to protect your business. This is even more critical if your help desk people serve internal clients as well as external. Incorrect information or lack of interest from your help desk to internal clients will inevitably make those departments appear weaker to their external clients, thus affecting the perception of your company as a whole.

There is also the larger issue of the steady decline we have been seeing in the quality of customer service in general over the last 30 years in our society. While that decline has several complex sociological causes, a large part of it is due to an overall relaxation of expectations and quality standards on the part of companies that employee people in customer service roles.

My company???s experience has been that if we state clearly our expectations, and maintain very short corrective processes for those that don???t meet those standards, customer service quality and employee morale both remain high. We weed out the problem children before they can become chronic, and that boosts the morale of the employees that are performing well. Nobody likes to carry dead weight, and believe me, coworkers always know who is the dead weight in their area. I???m not advocating immediately firing someone who makes a mistake, but I am advocating requiring immediate and lasting improvement. We have found that lengthy corrective plans simply don???t work as well as short ones, and we have had at least as many employee turnarounds as we have had terminations for poor performance while adhering to this policy.

Feedback from Reader "DK"Another reader was concerned that David Lightman may have had some personal issues affecting his work and that we maybe acted too hastily. I noted that we didn't give too much background into why maybe David Lightman wasn't performing up to standards. I also explained that we have to cover these topics in about 700 words where to cover this situation it might have covered many pages to note all the issues. For instance David was also late at times, a trend increasing in his case, but not enough space to also toss that fact into the article. And I agreed with the reader that we often have to take into account who is the source of the complaint and what is going on with them at that time. For the article I tried to use this scenario of a more clear-cut example, which was the case. In the situation we had - David was not under some personal stress for instance. I am a bit worried that maybe the article came across that ACME is not concerned about employee welfare when I was trying to show that we took specific measures to ensure we did show concern.

I do personally keep things in mind such as you noted below. Meaning I have had to deal with employees who are suffering some personal setback outside of work and that can't help but affect their work, and I haven't held that against them and actually work to show that we support them. I try to know employees and their families both as a related matter.

Excerpts of Email from Reader DK:Reading you article in the recent Network Computing issue reminded me at the lessons learned in a course at the university about human behaviour in complex organizations. During this class we were confronted with many scenarios of troubled workers or difficult situations in companies and we had to develop creative solutions. Anything was possible other than intentionally creating more work and firing anyone. The first few weeks were difficult and let both students and instructor in despair. But after a while of thinking we learned about "third heart" feelings, about emotions, about approaches that were so against the management 101 stuff.

In your article you mention that the employee David Lightman showed shortcomings in his work that reflected badly on him and on the department. Attempts were made to work with the employee to make him do the work he was hired for. It did not work out, so he got fired - end of story. Maybe some proceedings were omitted in this article, but it never ever even gives a hint that anyone tried to understand why Mr. Lightman's work did not meet the expectations. Who knows if he has a chronicly sick child at home, or his neighbour revs a compressor engine until early in the morning (my neighbour does that sometimes), or maybe he got some personal issues with Mr. Slick. Maybe Mr. Lightman has often migranes that make it difficult for him to even function, but he is to afraid of getting fired when admitting to this or calling out sick frequently.

Maybe Mr. Lightman was at the wrong spot within the company. Who knows if he would have been a tremendous help in marketing with his great idea, but did not have the credentials for such a position and had to settle for a helpdesk job. I used to do more software support for end-customers and are grateful that I now can hide in internal support. Helpdesk jobs are frustrating and thankless, it is a legitimized form of constant abuse. Nobody is happy, one can never get it right, one is always behind. Some people like this type of abuse, others don't. Helpdesk support is as important as any top notch sales rep, but helpdesk staff gets paid a fraction of the sales rep income. Developers and sales reps tend to think only on their terms knowing that there is always the helpdesk to put outthe fire.Did anyone ever ask Mr. Lightman what he likes to do ? Maybe he is really good at fixing printers, but lousy when it is about ordering equipment. Nobody ever seemed to even have thought about what Mr. Lightman's problem could be. He did not perform, he got another chance, he blew it, so let's just fire him. Instead of letting go of a worker who at least shows up for work and is already trained well all others involved in this story should attend the same university class that I took. It really made me look at those things from a different perspective.

Feedback from Reader "WC"Yet another reader provided his own experiences and concerns over how his own performance might have been viewed during his career. I replied that slow and steady in my experience includes good quality and attention to detail. I have always valued a developer/programmer that reviews the systems analyst's products provided before merely charging into the coding. I noted that in the case at ACME it was not that David was just being thorough, he was making silly mistakes and we worked with him professionally to try to assist him, get him more up-to-speed, and so forth. We were not pushing him to be fast, but to be accurate. However he didn't improve.

Excerpts of Email from Reader CS:I was, and probably still am, kind of like David. Only my problem, according to my past supervisors, has been that for a high level programmer analyst (mainframe), I was very slow in performing my job. In other words, what they thought was something that should take the average programmer 2 weeks to do may have taken me 3.

Mind you, there really weren???t any hard and fast deadlines, unless they were legislatively mandated. Believe me, if they were legislatively set, the work was done by that time! Most other deadlines were kind of like ???we???d like to see this in two weeks if possible???.

If the fix was relatively easy (???cosmetic??? changes and such) then the job was done and over with before the ink was dry on the Service Request. But, if it was a major project, that was another story.I never had the nerve to tell my supervisors that I wasn???t ???slow??? ... I was just very cautious and thorough in what I was doing.

Where I worked other analysts were responsible for getting all the requirements and putting together a Systems Impact Analysis Packet (what other systems or programs were going to be impacted by the requested changes or additions).

Because I wasn???t part of this team, I would ALWAYS thoroughly review this packet. Usually verifying or redoing research to ensure all ???holes??? had been discovered. In a lot of cases I would find more affected programs or processes than what were shown in the original packet. I would present my findings back to the originating group and in a lot of cases would be told to ???not worry about it. Everything would be all right???. Just do my job.

Well, I basically would ???ignore??? that kind of response (maybe its from 20+ years of doing this job) and would work from ???my??? list of needed modifications. Doing those things found in the original analysis first, so as to look as if I was following the original course of action. But in reality fixing EVERYTHING that was found.

It would take a little longer than planned to do all this. But when you looked at the numbers, I had better than a 90% success rate on ALL new first time programs or processes that were installed to the production environment. On those projects just requiring simple modification or small process changes it was around 97%. Most of the ???young guns??? in the shop didn???t have better than a 50-60% rate in either case.What do I mean by this? It usually meant that my new/upgraded processes ran first-time/every-time! No immediately having to yank things back out of production or resetting the system to some pre-move up condition and then working like jack rabbits to fix whatever was wrong, testing and then trying to move the whole thing up all over again. Not me!!! I prefer doing things right, if possible, the first time so I can go home and sleep in my own bed at night!!!

I was ???talked to??? many times because of my ???slowness???. But, when presented with the ???numbers??? there wasn???t really much they could do.

I still work for the same employer and we???ve adopted a new approach for development that uses a slightly modified Microsoft Solutions Framework approach. This has made it much easier on all the staff. Allowing for more involvement in the analysis and design phases. Thus allowing the setting of more reasonable deadlines by offering a better ???lifecycle??? for analysis, development and deployment.

All that being said (typed in this case)... I???m really not trying to boast about myself. All the credit really goes to the first set of instructors I had in college. Two teachers who took me under their wings and drilled into me that sometimes deadlines can be just that. Dead ... lines. Something when finally reached you???re dead-dog tired meeting it and glad the whole project is over so you can now go into an immediate ???maintenance mode??? to fix all the compromised work ... just for meeting a deadline. Or, because of bad analysis and judgment, your job is dead because of something you didn???t do to get the product right the first time.

I want to reiterate ... I???m still here doing what I love to do. Others, who tried so damn hard to make deadlines, and in the process compromised their integrity, their company???s integrity, and their customers reliance on them for a ???superior??? product, are not!!!So, I???ll continue to take the ???slow??? road and provide for my company, and customers, the best product I can produce. Built to their specifications and business requirements. A product/process that WILL work, if possible, the first time they use it and every time thereafter. While maintaining my integrity, my company???s integrity and keeping the customer???s faith in us.