Wednesday, December 15, 2010

Should Developers Be Allowed to Talk to Customers/End-Users?

--------------------------------------------------------------------------------


Courtesy: Eric Spiegel, Datamation

“If you make me do this I will quit.”

Dmitry looked at me, not with anger, but more with a determined angst. He was obviously shaken by my request that he take a call with a customer who had technical questions about our company’s software product.

Dmitry was one of the leads on our development team. He was very quiet, brimming with intelligence and could actually get quite lively as he discussed with his fellow developers. But one thing was clear. Dmitry avoided extended interaction with anyone in the office who was not a technically trained engineer.

Typically, this wouldn’t have been a problem. However, just this one time I asked him to consider taking a customer call because the sales engineer assigned to this customer was out sick today. The rest of the sales engineers were traveling on assignment. Besides, I knew for a fact that Dmitry was THE expert on the module this customer would be most interested in learning more about.

I tried flattery. “Dmitry, I have seen you talking about these features with the utmost confidence with others on the development team and even the QA and support teams. You helped architect this code and you wrote the majority of it. And this discussion will be over the phone, so how hard could it be to talk about something that you are the obvious, unqualified expert in?”

He glared back at me. “Not doing it.”

I briefly considered giving in and asking one of the less experienced developers take on this task, but this was a very large deal for the company. I knew if the call went badly, the account executive who owned this customer would raise holy hell. That she would be angry about losing a huge commission wasn’t the issue. My boss, the CEO, would also not be happy – and that was most definitely an issue.

So I tried for sympathy. “Look Dmitry, please consider my position. If I have someone less experienced talk to the customer, I’m just asking for a disaster. All you have to do is answer a few questions on a topic you know the most about. How hard can that be? Besides, this customer isn’t even that technical.”

No response. So I tried the “Feel - Felt - Found” method of persuasion. “I know exactly how you feel. When I was a developer, my manager asked me to sit down with some end users to explain how a new application worked. I felt the same way as you – scared to death. But you know what? Once I started talking about this app, which was quite familiar with, I found that there was nothing to be worried about. If you know your topic, you will be respected and well received.” He just shook his head. And as he got up and started for my office door he said, “Sorry, but this isn’t in my job description.”

So I went for the jugular. “Do you still want to go to the Microsoft Tech•Ed conference next year?” Dmitry stopped in his tracks and swiveled around. “Yes,” he said tentatively.

I smiled. “Well, if you do me this favor and take this customer call, I will approve the conference.” Of course, I was likely going to approve this conference anyway, but had been dragging my feet waiting for more clarity on next year’s budget. Evil of me? Bad form? Maybe. He shrugged.

“Deal!”
Later that afternoon, Dmitry, the account executive, and me sat around a large conference table with one of those speakerphones that looks like a small UFO. Daniel, the account executive, dialed the number.

I looked over at Dmitry and noticed he looked pale. I caught his eye and smiled reassuringly. “You’ll do just fine. Simply answer the questions.” He gave me a nervous, terse look.

The customer answered the call. To our surprise, he introduced a second person on the call. “Hope you all don’t mind but I asked my buddy Jerry to sit in on the call. He is an expert in this type of application.”

Daniel piped up: “Not a problem at all, I’m sure he’ll be impressed and we welcome his feedback.” Daniel had no idea Dmitry was nervous. I mouthed the words “Don’t worry” to Dmitry as Daniel finished the introductions. I noticed his leg was going a hundred miles an hour under the table – up and down.

The customer, who had been nice as pie on my prior call with him, hardly talked at all. As soon as his “expert” consultant started in with “I downloaded your software trial and to be honest, I wasn’t very impressed,” my heart sank. “I connected to the database with no problem, but I kicked off the update process and it has been running for 12 hours and still hasn’t finished. That isn’t acceptable, even for an overnight batch process.”

After an uncomfortable pause, I spoke up. “Sorry to hear that. The update process shouldn’t take more than an hour.” I looked at Dmitry and motioned for him to chime in. Dmitry took a deep breath and said with a slight edge to his voice, “You must be doing something wrong. Nothing in the code would cause it to run that long.”

I cringed as Jerry the “expert” spoke up. “I can assure you, I followed your operations instructions to the letter and the system’s minimum requirements are in place. I’ll also mention we aren’t processing more than a few gig of data.”

Dmitry’s face began turning a shade of crimson and answered in a raised voice. “If you followed the instructions as you claim, then it should work.”

Daniel quickly interjected. “Hey, we can set a time to figure out what’s happening. I was hoping to focus on technical feature questions today.” Jerry the “expert” responded. “What is the use of talking features if the product doesn’t perform as promised? And your user interface was not very intuitive.”

Dmitry was now standing, with fists clenched and pacing. “Oh yeah, well you must not be very smart Jerry because my 10-year-old could use that UI without any problem.”

Daniel’s mouth dropped in horror. I decided to interject and attempt to end this debacle. “You know what, everyone, let’s set a time for a sales engineer to come out and take a look at your setup and I’m sure we can work this out. Our customer spoke up to put us out of our misery. “Actually, Daniel, I think we are going to move in a different direction. But thanks for your time.”

And just like that it was over. Dmitry gave me an anguished “I told you so look” and stormed out. Daniel just sat there with his head in his hands.

Guess what? It turns out that Jerry the “expert” was actually representing a competitor and had sabotaged our efforts. Daniel agreed that the call was a trap to begin with and even though Dmitry responded inappropriately, we were fighting a losing battle. As a result, luckily there was no major fallout for me from the CEO.

As for Dmitry, he tried to apologize and I stopped him. Instead, I apologized for putting him into a situation where he wasn’t comfortable.

Bottom line: Even the most brilliant developer may not be able to convey his or her knowledge outside of the techie inner circle. Dmitry’s strength was architecting and writing code, not customer interactions.

I have since learned that some developers do have an innate ability to communicate technical topics, but not all are suited for sales situations. Dmitry went back to writing great code, had a great time at the conference and I never again asked him to talk to a customer. Frankly, I was very lucky he decided not to quit after all.


(Courtesy: Eric Spiegel, Datamation)