What Makes an IN-effective Engineer?

When I ponder this question I think back to the various engineers I have worked with whom I would consider failures in their field. Unfortunately there is no single archetype of an ineffective engineer. Tolstoy once said that all happy families are alike, but every unhappy family is unhappy in its own way. Likewise, you could say that each failed engineer is a failure in his or her own unique way.

I had one employee who could not accomplish anything unless they had all the minute details of their project answered by management. How big should this button be? What should the exact text be for this label? Should I put this code into two files or just one? Perhaps they were trying to please, but they gave the impression of being unable to accomplish anything without excessive handholding.

Another engineer was an avid musician who did his day job just for the paycheck. He would do the absolute minimum work necessary to get by, and his teammates often found themselves having to fix his bugs and generally clean up after his mess. When confronted with the inadequacies of his work, he was a veritable fountain of excuses and blame. He refused to take responsibility for anything, and showed no accountability for his work.

There were also a couple of engineers who were just argumentative by nature. When there were the slightest little details that someone let slip by, these people would pounce on them. And where there were no controversies or disagreements they would manufacture them, just so they would have something to argue about. They did this in the name of generating healthy discussion, but in reality they just liked to argue and waste everyone’s time.

Then there was the fellow who had exhibited decent technical skills and quality, but who just rubbed everyone the wrong way. He was openly critical and dismissive of other peoples’ work and ideas. He was especially hard on non-technical people, all in the name of ‘honesty’. His influence was like poison on the team, and no one wanted to work with him – not other developers, product managers, project managers, QA, or anyone else.

Of course I’ve also had those employees who where well meaning and positive but yet just weren’t quite there technically. A few bricks shy of a load, as the saying goes. Not playing with a full deck. The lights are on, but nobody’s home. The elevator doesn’t go all the way to the top floor. A couple of fries short of a happy meal. But at least I could manage around these employees by assigning them simpler tasks and giving them more time to develop (hopefully).

You may wonder which of these people were eventually let go. Ultimately that’s not important; what is important is that you take away from these stories some qualities to avoid, both in yourselves and any people you might be involved in hiring.