What Not to Do with a Video Cable

I had an employee once who was setting up a test system for an important project. This person was not a junior engineer; in fact, the person was recommended highly and transferred temporarily at great expense to my group because of reported effectiveness.

After a couple of days of setup, I looked in on the progress and found out that there had been a snag. Additional people would be needed and it could be resolved in a day or two. I approved and made the assignments so it could get done.

At the end of that first week, there was one specific issue still outstanding. Now keep in mind that all of this is in the setup for the project, not in the project itself. The one issue outstanding would require us to ship hardware across continents to fix. I recommended a few things to try while the hardware shipment was underway.

Another week went by and the emergency shipment of hardware arrived just in time for a progress review. Still no-go; the system was not working. At this point, nothing was beyond my suspicion and frankly, I was mad. I was having to report that we could not even start this project and all the resources I had applied were not helping.

So I visited the lab. I poked around the system and within 3 minutes (it was just that long -I wish I were exaggerating) I discovered that they had a video cable where a serial cable should be. It was a DB9 cable for those who care; the old-school monochrome CRT's had a DB9 connector and so did the second version of PC serial ports. The connectors were the same but the cables were not.

Another two minutes to find a decent serial cable and test it... everything worked. I went from mad to nuts... why had nobody realized it was the wrong cable? Why had nobody tried a different cable just for the hell of it while they waited a week for new hardware? Why had all of my resources yielded nothing? Why do I have to do everything myself?

I behaved badly. I was frustrated, and it showed. This would have been a great opportunity to teach people, regardless of seniority, about how to diagnose this kind of problem. How to separate hardware from software issues. How to troubleshoot a big system. All sorts of things could have been taught. But I taught them something different.

By getting angry, I taught them to avoid telling me what was really happening in their work. I taught them to avoid any opportunity for me to enter their workspace. I taught them to avoid getting on another project where I might judge their ability to do exactly what I would do instead of measuring their ability to show a balanced blend of many different skills including teamwork, client focus and camaraderie.

I should have been in the lab more - I might have even spotted the problem a full two weeks earlier. I should have talked more in-depth about the problem and asked the right leading questions to exhaust silly things like bad cables. I should have celebrated finding the solution rather than getting angry when the trouble was over.

The funny thing is that no mater who I blamed for the problem, it was my responsibility. I was entrusted with the people and the goals. If I managed well or poorly, made good or bad things happen, it was all mine. So I might tell myself that the people involved should have known better and that other people would not have failed me but the fact is I picked them and made the assignment. I gave them two weeks of rope and carte-blanche resources. In retrospect, I really had no idea what they were doing - which means that, as the manager, I had no idea what I was doing.

Thanks for reading this Management Use Case. I'm the co-author of a new book on software development leadership entitled You.next() that features dozzens of other use cases for leadership. Please see more at www.youdotnext.com.