Underachievers

I don’t like underachievers, people who tend to do the absolute minimum. I don’t like people who only do half of what needs to be done, those who think it’s good enough if it works. Even if their code is illegible or takes fifteen lines to do something one can do on one line.

Professionally I come across these people a lot. I am a consultant and visit quite a lot of companies. Recently I was a guest at a company to help the IT department because one of them had broken his foot and couldn’t walk around in the field. The job: a bit of helpdesk and prepping computers for a roll-out. Not quite my thing as I am a developer, but I had some experience at a service desk. I used to do third line support and was not used to the normal, daily problems of the average user.

The guy I had to help did not follow up on anything. In two months he managed to accumulate no less than 150 issues which were not even close to being resolved. The company had at most 100 users. “I don’t have any time to solve all that” he said.

Thinking back as far as last April, when I had to go to another company to help them out because they fired their helpdesk agent. This man also succeeded to leave a lot of tickets open for a long time. The manager and I agreed I would automatically close all tickets older than one month. This was a very repetitive job.

In a week’s time I closed six hundred (600) tickets which were left around. Because there were only about thirty calls a day, I could spend some time doing this. This man only had to take the call, create a ticket and assign it to someone who could actually solve the problem. “Catch and dispatch” they call this. Of the 780 open tickets only 57 were assigned. I was stunned. When I left after two weeks, only thirty tickets were left open and assigned. Fortunately my sales manager could convince them a service desk is not my line of work; otherwise I would still be there now.

Another underachiever: someone I met in a bar. He’s a web designer but also develops from time to time. This man thinks security (mitigation of Cross Site Scripting (xss), dictionary attacks on login pages, minimal trust, using encryption, SQL injection, logging exceptions etc.) is an option the customer has to choose. The client has to decide whether he wants to spend time and money on security. He doesn’t put these measures in place by default. He likes to spend days cleaning up or restoring the database more than making sure his application is safe.

Well, Sir, that is so completely wrong! Of course the client chooses the cheaper solution. A decent developer, someone who takes his work and himself serious, informs the customer. Such a person explains why security matters. In the long run it saves money.

People tend to tell me that I am an expensive guy being a consultant. That’s true, but they all forget one thing: I’m there to clean up the mess they made. There are two possible reasons why I am hired:
– An expert is needed to do the job
– No-one in the company wants to do the job

It’s me who has to prove time and again that the decision to hire a consultant was a good one. I go for perfect solutions; solutions containing everything. I give it all (yes, dare I say: 110%) to keep the customer happy and that works every time. Not any customer has been unhappy. Almost all of them wanted to extend the contract. Unfortunately, they were often late as our sales team tends to look for a new project when the previous one is about to finish.

I shouldn’t look at them the way I do. After all, these underachievers provide me with a line of work.