Good News! Smart People Misunderstand Each Other, Too

Dealing with disagreement can be hard and messy, so here’s some good news. Sometimes a disagreement is just a misunderstanding. Misunderstandings can come with a lot of the same energy and emotion as a disagreement, but once you’ve found the end of the knot they often untangle much more quickly. 

Forty years ago, in 1984, there was a Saturday Night Live sketch where the guest host, Ed Asner, played a well-respected veteran engineer heading off to retire on a remote island after a career spent running a nuclear power plant. His final words to his team, were, “Remember, you can’t put too much water in a nuclear reactor.” 

No sooner had the party ended, and Ed was unreachable, than one engineer started to leave, saying, “I’m going to go put some water in the reactor.” “No!” Countered another, “Didn’t you hear him? You can’t put too much water in the reactor!” “Right!” someone else said, “so we better add some.” This went on as people took sides in the great debate arguing over what exactly their revered mentor meant. And, it all ended with a big boom. 

(Sadly I can’t find a video online, but this blog has a summary and some screencaps.)

In the example above, ambiguous wording left people with very different views of what to do and a lot of disagreement followed. Overloaded or ambiguous words lead to a lot of misunderstandings and knowing where to poke is a great skill to cultivate. Here are some examples drawn from my own experience: 

• Different definitions of done. What does “shipping a release” mean, anyway? Does it mean a few customers have access to it, a closed beta, an open beta, or that it’s fully available and ready for sale? I’ve worked with teams that use “done” to mean ready for their QA engineers to start testing. (I changed that.) It’s a big disconnect if product engineering means “we’ll have a closed beta for ten customers” and the sales team hears “we can sell this thing!” And those misnderstandings lead to a lot of disagreements about how to get ready and what’s good enough to ship.
• Using ambiguous words for time. I once worked on a huge project that had a goal to “ship in the fall.” When we’d started may months prior that was right level of fidelity but as we got to summer I started pointing out that fall ended December 20. But, most people hearing “fall” (or “autumn” for those of you out of the US) think “September, maybe October.” As we got closer we had to tighten that up to be clear about what we meant—which was, in fact September. Finance and sales teams run on monthly and quarterly goals so especially when crossing departmental lines, it’s essential to get on the same page. We could have equally as well said “look we think this might take the full fourth quarter, don’t forecast any revenue against this.” I’ve done that too. It’s better to painfully get on the same page early on than to have to deal with the fallout of a misunderstanding, especially when revenue and commissions are involved. 
• The term “system” often leads to misunderstandings because of its many meanings. Not long ago I was at odds with a sales leader who told me he had to have a new sales system in place in the next few months. I thought he was talking about a full-on Salesforce implementation and knew that was impossible. It turned out he meant a new workflow for his sales team—something he full well knew he could in that time frame as he’d done it several times. Boy, did my blood pressure drop when I realized that! When someone says they need or are implementing a “system,” ask more questions to be sure you know what they mean. 
• Anything process related usually benefits from very explicit definition. I’ve argued with people telling me “you need QA” thinking they were telling me I had to hire dedicated QA team. When I realized they meant, “you need to test better” I was suddenly in complete agreement! So when someone says “you need a process for X,” dig into the why. 
• “Too much,” “not enough,” and other relative quantities depend on your point of view. I worked with a product team that had spent a lot of time cutting cloud computing costs and I didn’t know why. It turned out, they’d heard that engineering was spending “too much” on the cloud and so they focused on saving money. But, in fact, that team’s total cost was a small fraction of the total spend, and the overall savings weren’t a big impact to the bottom line. That team actually had higher priorities to work on but had misunderstood a statement as a directive that cutting all costs was the top priority. When someone says something is too much or not enough, find out what their frame of reference is. 

As I talked about in previous articles in this mini-series, describing the disagreement and restating the problem are also good ways to find and clarify misunderstandings. Sometimes when you describe or restate, lights come on and people see where they’ve crossed the wires. 

All of this points to another tip, too. Even if you’re feeling angry or attacked, double check your understanding before you blow your top. If I’d started yelling at that sales leader that he was asking for the impossible and setting my team up to fail with his unreasonable expectations, it would have torn a hole in our relationship. Fortunately, I asked enough questions while keeping my cool that he never knew I’d been seeing red. At least not until I could laugh about it a few days later!

Your Dot Release: The next time you disagree with someone, or hear some people on your team disagreeing, pause and clarify at least two of the terms being used. Some prompts to identify  areas to clarify are terms related to definition of done, timeline, systems, process, or quantities. 

P.S. A few weeks ago my husband and I were on a road trip and stumbled on the Experimental Breeder Reactor-I museum in Idaho. It was like nerd Christmas. That’s the source of the photo above. No booms happened in the making of this reactor or photo.

This article is part 4 of 4 in a mini series on Alignment 101: Smart People Disagree. The others are:

• Smart People Disagree—That’s Not a Bug It’s a Feature
• Describe it to Defuse it When Smart People Disagree
• When You're the Smart Person Disagreeing-Restate the Problem

Welcome to the Dot Release, my newsletter for focused and actionable career, leadership, and product advice. You don't need a full upgrade, just implement a dot release! If this has been helpful for you, please forward and share with a friend.  Subscribe.