How To Order a Steak Exactly the Way You Want It
I was at Del Frisco’s in Denver recently and ordered a steak. On cue, the server asked, “How would you like that cooked?”
To which I replied, “Medium rare, please.” Of all the dining experiences, having a steak cooked to a diner’s liking is perhaps the most error prone. But in ordering my steak that evening something fantastic happened. The server clarified my request with a follow up. “Our medium rare is a hot pink center. Does that work?”
And in that simple clarifying point, she removed the ambiguity in our exchange. She effectively found a common language that transcended lived experience and culinary praxis differences.
It got me thinking about business requirements, the pitfalls of communication assumptions and what made her clarifying question so darn effective.
“The single biggest problem in communication is the illusion that it has taken place.”
– George Bernard Shaw
In one sentence, the late Irish playwright perfectly encapsulates what costs companies millions of dollars annually in project budget overrun – miscommunication from what was intended to what is realized.
There are numerous articles about the consequences of bad requirements, or how the use of better, more succinctly designed artifacts can improve clarity in communications. This is not an article about that. This is about creating awareness and mindfulness of costly communication assumptions and how to avoid them. Whether you are the business stakeholder, the business analyst capturing the stakeholder’s want or the team responsible for executing, you play a role in achieving clarity.
“Communication (from Latin commūnicāre, meaning “to share”[1]) is the act of conveying intended meanings from one entity or group to another through the use of mutually understood signs and semiotic rules.” (Wikipedia)
Based on this definition, communication seems simple, right? So why the “illusion” as Shaw puts it? If you read the definition closely, you’ll notice that communication requires “mutual understanding.” But how do we know that we’ve achieved mutual understanding? This definition surfaces the crux of the problem – assumptions about what is “mutually understood.” What each entity or group understands and perceives is based on unique lived experience. If I say, imagine a blue car, everyone reading this is picturing a different car based on what they’ve seen and what they’ve experienced. Maybe not so simple after all.
We often assume we’re communicating effectively . We write exhaustively thorough documentation and assume we’ve done our job in knowledge transfer. We read requirements and assume we understand what someone wants based on our own interpretations (captured brilliantly in the classic illustration, “How Projects Really Work”)
So how can we get past the hurdle of assumptions? How do we find the common language. It begins with awareness of communication pitfalls and requires a deliberate effort to combat them.
First, understand that we all perceive and interpret information differently. There will always be assumptions that require clarification.
Let’s chew on the steak analogy (Warning: this article serves up many bad puns). What might be wrong with my request of “medium rare?” Medium rare has a temperature range of 130 – 140 degrees Fahrenheit which can impact the outcome. I may be accustomed to 130 degrees steak and the chef may prefer to let a steak reach 135 or 140 degrees. Where did the chef complete her training or gain experience? A French chef may interpret medium rare to be more on the rare side than an American chef. Medium rare doesn’t clearly communicate what I want.
Second, don’t be prescriptive. There are too many variables that can skew an outcome.
Let’s suppose I told the server, “Please tell the chef to cook the steak for two minutes per side on medium high heat. This is how I cook it at home and it always comes out perfectly.” Does that guarantee the outcome I want? Why not? I don’t know how her stove top performs relative to mine. I don’t know if she also reverse sears the steak by placing it in the oven. I don’t know the thickness of the steak which informs the required cook times to reach the optimal temperature. These are all variables that can skew the outcome. As the person requesting, I am not the expert in the execution methodology. Best for me to stay out of the kitchen.
Lastly, eliminate the ambiguity. Clarify the ask and find the mutually understood language.
The business analyst must play the interpreter role here much the same way the server did in the restaurant by capturing what is mutually understood in a way that clearly communicates what the stakeholder (or in this case, the steakholder) wants. I don’t actually want a medium rare steak. I don’t want a steak cooked two minutes on each side at medium high heat. What I really want is a steak with a hot pink center. Creating a mutual understanding of what is wanted is the measure of a good business analyst and the key to avoiding costly miscommunications.
Who’s hungry?