I can’t hear you. There’s a banana in my ear!

I was working with a help desk leader who was struggling with the onslaught of tech support calls for a new product. Sure, the software was alpha-quality with plenty of nasty bugs but every single call was taking way too long to solve. Most of the problems were manifestations of the same core issue and could be fixed with a quick work-around. After I helped with a few of the call resolutions myself, I knew the problem was training. The help desk did not know the new product or any of the technology behind it. Never mind the methodology and process that could have prevented that; this was a startup. Of course we would eventually resolve many of the issues but sales were brisk and the next release was a few weeks away. The help desk needed to deal with the issues faster, even if only for a while.

I assembled a makeshift training course on the ints-and-outs (pun intended) of the new software and offered to train the help desk in a series of emergency sessions. We would give them a crash course in what-to-do-when and everything would be fine. With goodwill and a powerpoint deck, I met with my counterpart on the help desk leadership team.

The answer was “no”. More specifically, the help desk had no time for training because they were too busy. In fact they had just had to cancel training on the new benefits package because they were too busy with a lot of really long support calls that were coming in from the new product. If I wanted to help, I was told, I could come take some more support calls – or better yet, send the developers down to take support calls.

Remember ‘Sesame Street’? I distinctly remember an episode where either Bert or Ernie kept trying to talk on the phone and saying “I can’t hear you, there’s a Banana in my ear” while the other guy was at trying to tell him “take the banana out of your ear so I can talk to you.”

That’s what it feels like sometimes when you are trying to get people trained. They are too busy to get training on how to do their jobs more effectively. Too busy to learn products, too busy to learn tools. Too busy to be effective.

Of course my help desk counterpart did not intend to be stupid. She wanted to follow procedure, complete her role in an orderly fashion and do all the things that a help desk manager has to do when dealing with a deployed product. What she failed to realize is that we were not dealing with a mature piece of software; we were dealing with the shortcomings of a hasty release and we needed to bend the rules a little. What I failed to realize is just how important rules are in an environment like technical support or manufacturing (or shipping, I suppose, but I don’t have experience there yet) where the process is the job. I was basically telling this person to come learn some skills that would allow her people to perform work that was not really within their responsibilities.

The whole thing was out of whack. Years later I would understand that this was a violation of one of the parity principles of leadership. The help desk team was responsible for the success of the product in the field without having the authority to command resources that would make it successful. They could not stop the product from being deployed because they did not control QA. They were not trained on the product because it had not passed the right quality gate to require training the help desk (yes, even though it was being sold with clients fully aware of its quality level – thank you SOX). They could not demand that developers, who knew how the product worked, take the support calls.

If I had articulated it in this way to the help desk VP, the training I wanted to provide would have been initiated immediately. Instead, I got frustrated because the product my team had worked so hard to build was looking bad in the field. I actually accused the help desk manager of “not caring” and that’s when I realized that she had as much passion and pride of workmanship as I. Her challenge to me was to ask how it could be that we had created such poor software. We did not make poor software but we did release it half-baked because of pressure from above, and I knew it.

We muddled through the next few weeks, basically doing OJT by having developers suffer through support calls with technicians assisting at first, then flying solo. It is probably better that we did not do a quick training and wash our hands because the developers got to feel the pain of bugs in configuration apps that are too complex or quirky UI flags. We all pulled the bananas out of our ears and communicated until a patch smoothed things out. Then we went back to our functional silos and put them right back in.

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.