We were holding a formal design review for a large and complex system with many requirements. Important players from the project’s customer organization were present, although this was a step in my client’s internal engineering process and not specifically intended for design review by their customers. It was, however, the customers’ first comprehensive opportunity to see essential aspects of the design in any depth. They had been pressing for months for a review and complaining when it hadn’t happened. 

Imagine the reaction, then, when our program manager stood up and began to give a presentation summarizing a large number of design shortfalls. In the ensuing uproar, he tried to explain that these were simply gaps in the design that we’d identified and were developing plans to address. But his efforts were in vain. The customers had heard the emotive word “shortfalls”—and none of the explanations that followed. The room reverberated with their powerful feelings of alarm and anger. 

Customer-vendor relations had been contentious for some time, with accusations of bad faith and periodic outbreaks of recrimination on both sides. On many occasions, customer stakeholders had expressed, either in person or in writing, their suspicion that we were trying to duck out of our contractual obligations to deliver on all the documented requirements. Now, having heard there were “shortfalls,” they were convinced we were presenting a design for a critical system that fell far short of requirements. 

The review chairperson eventually managed to get the meeting back to its agenda, but only after much hasty backpedaling and earnest explanation, plus a welcome coffee break for intense negotiation in corners. Our senior management team had to promise to share the complete, detailed list of shortfalls and schedule a separate long session for that evening to walk the customers through our process for disposing them. 

Problem solved, right? Well, no—more like “problem papered over.” And this was a problem we could have avoided. If instead of “shortfalls” we had used the familiar word “defects” for the design gaps, we would have better positioned our customers to understand what we were talking about. They would still have questioned our commitment to correct all of those defects, but the language would at least have shown them that we saw the gaps as problems we were tracking and needed to address. 

It had been an innocent enough mistake on the program manager’s part. “Shortfall” came out of that internal engineering process and was the word we had used amongst ourselves on the project team. We had been living daily with identifying, triaging, and disposing holes we’d found in the design. In our lexicon, “shortfalls” were not items we weren’t going to deliver but potential issues to deal with. We knew what we meant. But our customers did not and they assumed the worst. 

Blowups like this happen in our personal lives, too. Have you ever had a conversation where the other person latched onto one thing you said—something that wasn’t at all what you meant to say—and acted as if he or she hadn’t heard anything else? The other person had the wrong end of the stick, and now you needed to correct the misapprehension. 

If you examine the problematic word or phrase, you will often find that it has acted as an emotional trigger. Hearing it prompted a strong reaction in the other person, and once that occurred, the other things you said didn’t go in. The emotional reaction may have been so strong that the other person even forgot what you had said beforehand. Your words meant something to someone else that you didn’t intend.

Our customers heard something we weren’t saying because we were not speaking their language. It’s a mistake we make in IT over and over again. As practitioners, we are immersed in our own view of software development, testing, and delivery, and we use a vocabulary for those activities that makes sense to us. But those less involved in the day-to-day project—such as customers and executive stakeholders—are usually business people with their own priorities and their own vocabularies. They may ascribe very different meanings than we intend to the words we use.

Exhibiting a tin ear for customer vocabulary doesn’t always trigger major emotional reactions, but it does signal that the speaker is an outsider to the customer’s world, and it can be subtly damaging to working relationships. Using unfamiliar language—or familiar language in unfamiliar ways—inhibits clear communication and can irritate or offend people. Sometimes, customers perceive our insistence on speaking our own language as lack of respect for their business culture or a sign that we are out of touch with their concerns.

Am I saying we can’t introduce our customers to new words or new ideas? Not at all. There are many circumstances where it’s our job either to promote new concepts or to put a different slant on old ones. For a change agent, it can be advantageous to be an identified outsider.

 But before we can introduce a new reality, we first need to understand the current reality—where the people we’re working with are coming from and what the words we plan to use mean to them. If we want to avoid misunderstanding and needless upsets, we may sometimes have to compromise and use different words for the same thing in different customer contexts. 

We need to be sensitive to our customers’ perspectives and work within them. We can begin with by exercising awareness of the words we use and conscious intent in how we use them. Because the thoughtless use of a single word could so easily cause someone to get the wrong end of the stick.