Late one summer, I was called in to help an IT client learn to work better with their customers. I don’t ordinarily travel in the summer, but this sounded like a real emergency, one where I had to be on the scene to calm down both parties. The customers were enraged with the IT manager because a new system wasn’t ready on time, and IT manager was enraged with the customers because they hadn’t delivered some essential information as promised, thus causing the entire project to lag its schedule by 4 months.
It was over 100 degrees outside, but even hotter inside – emotionally. Jeff, the IT manager, would smack the table and say, “You promised that the component pricing data would be in our hands by February first.”
Penny, the catalog manager, would give him a steely-eyed glare and mutter, “We never promised that. Never!”
“Yes, you did!”
“No, we didn’t.”
And then they would loop back to the beginning, raising the temperature a few degrees.
I thought that the problem-solving would go better if I could cool things down, but all I was hearing was “yes-you-did-no-we-didn’t,” back and forth. I decided to attempt to establish some facts that were not a matter of opinion, so I asked for the original requirements document. Both Penny and Jeff seemed a bit stunned by this reference to data, then Penny recovered and said, “Yes, that will prove my point.”
“No, it will prove my point,” Jeff countered. “Good idea, Jerry. Now we’ll see whose fault this is.”
I was a bit surprised at how readily they each found the document. (Lots of my clients seem to lose requirements documents once a project is under way.) Jeff got his open first, and placed his index finger on the following key line:
The Catalog Department should deliver component pricing data by 1 February to the IT Department.
I thought Penny would find some other statement to “prove” her point, but a few moments later, she had her copy open to the same page, upon which the same sentence was highlighted in DayGlo pink. “There.” She said, triumphantly. “There’s my proof. We never promised to deliver that data that early.”
“Yes you did. It’s perfectly clear, right there. Should deliver by 1 February.”
“Exactly,” Penny countered. “It doesn’t say we will, but only that we should. And we did try. But you computer people apparently don’t appreciate the difficulty of getting every single one of those prices signed off by every person involved.”
Well, I eventually got things cooled down, and we moved from blaming to problem-solving, but not before I extracted a promise from both parties to attend a little workshop I designed for them. I designed the workshop because I didn’t want to have to come back the next summer when they ran into the same problem – a lack of understanding of the ambiguity of the English language. The following are some excerpts from that workshop:
I started the workshop with focus of their original problem, the nasty little word, “should.” Jeff read the original statement as
The Catalog Department [must] deliver component pricing data by 1 February to the IT Department.
Penny, however, interpreted the “should” differently, as
The Catalog Department [will make every effort to] deliver component pricing data by 1 February to the IT Department.
What I taught them was a safer meaning, of “should” would be “probably won’t,” so the sentence reads,
The Catalog Department [probably won’t] deliver component pricing data by 1 February to the IT Department.
“Oh,” said Jeff, “if I’d realized that, we could have designed the project differently. Could Catalog have delivered parts of the pricing data by February 1?”
“Sure,” said Penny. “We actually had about 90% of it by then, but that last 10% – mostly new items – took all the work.”
“Ah. If only we’d known. We didn’t need the entire table to proceed. Okay, next time we’ll just let you know what we really need.”
Jeff had given me the perfect opening for the next lesson. “Sorry, Jeff,” I said. That won’t do.”
“Because you’ve managed to sneak in another one of those discounting words.”
“Just.” I went to the whiteboard and wrote what he said:
“Next time we’ll just let you know what we really need.”
“Now, what’s the difference between that sentence and this one? I wrote:
“Next time we’ll let you know what we really need.”
“Well, it’s the same thing, isn’t it?”
Penny chimed in. “I get it. The ‘just’ makes it sound like there won’t be any problems. It discounts the difficulty.”
“Precisely. It’s what I call a ‘Lullaby Word.’ Like ‘should,’ it lulls your mind into a false sense of security. A better translation of ‘just’ in Jeff’s sentence would have been, ‘have a lot of trouble to.’”
“I get it,” Jeff said, coming to the board and snatching the marker from my hand. Then he wrote:
“Next time we’ll [have a lot of trouble to] let you know what we really need.”
“You know,” he sighed, “I wish we’d had this little lesson last month. My second-best analyst up and quit on me, and I didn’t see it coming. But a few weeks before, he told me, ‘We haven’t managed to hire another analyst yet, so I’m just working 80 hours a week until they do.’ I should have heard him saying,
‘We haven’t managed to hire another analyst yet, so I’m [having a lot of trouble] working 80 hours a week until they do.’
He was trying to tell me that he was overloaded, but the ‘just’ lulled me into discounting his message. And, because I didn’t hear him, he finally quit. Darn!”
Penny looked thoughtful. “I know another Lullaby Word that got us into trouble.”
“What’s that?” Jeff asked.
“You remember when we didn’t have the prices ready on February first, and you asked me when we would have them?”
“Sure, but I can’t remember what your answer was.”
“That’s because it was a Lullaby. I said, ‘Soon.’ And what that means is…” She looked at me, and I nodded.
“I think it meant, ‘I don’t know, but don’t keep bothering me.’”
“That’s usually a pretty good translation,” I confirmed.
“Actually,” Jeff chimed in, “what you said was ‘very soon.’”
“Oh, great!” Penny said. “And what did that mean?”
“Adding ‘very’ is like adding a sleeping pill to the lullaby. It makes it even more certain that it’s going to be a long, long time. Maybe never.”
We spent a bit more time on the subject of lullaby words, with examples such as
Only: It’s only a one line change. [That is, I didn’t think much about what could go wrong.]
Anything: I didn’t change anything . [That is, anything I thought was important.]
All: All I gotta do is … [A synonym for “just.”]
Eventually I noticed that both Penny and Jeff were yawning. I suddenly realized there were many ways to put people to sleep with words, so I stopped talking and they both woke up.
Later, I reflected on the deep lesson underlying all these lullaby words. In effect, they are designed to discourage feedback by putting both the speaker’s and the listener’s minds to sleep. And no feedback means that the meaning of the statement containing a lullaby word cannot be clarified. And, if it’s not clarified, it can mean almost anything – and that’s always the beginning of trouble. If you want to avoid such trouble, start converting those lullaby words to alarm words – waking you up to potential misunderstanding, rather than lulling you to sleep. Just do it!