bMusings

Listening for the Unknown

April 25, 2019

radio satellite dish

My team is presenting to a member of upper management. This meeting is to review our product strategy for the coming quarter. As we go through our slides, the presenter starts an exchange with the upper manager:

Presenter: “We think this team will create about three thousand.”
Manager: “Where are you getting that number from?”
Presenter: “That’s what I remember they told us or whatever.”

The manager immediately stops the presentation and proclaims “No. Not whatever. I don’t like whatever”. A tense air immediately fills the room, and my team spends the next few minutes uncomfortably going into detail over the number and how we got to it. While we do this, I’m secretly grateful; I saw exactly what our manager was doing that day: listening for the unknown.

Tuning In

What our manager did was the direct result of being tuned in to a very specific pattern of information. This pattern usually takes one of two forms: the assumed known and, closely related and therefore relevant, the unknown unknown.

The assumed known is information that you accept as true, but that has no underlying basis of truth. Sometimes it is a lie that was created and perpetuated unknowingly. Our “three thousand” number was a perfect example of this: it was offhandedly offered by one of our customers on another team, then reported back as fact to the rest of our team.

Let’s be clear here: assumed knowns fall into the category of the unknown, because your misinformation is obscuring the fact that there is something you don’t know.

The unknown unknown is much more difficult to characterize and can arise from a wider array of causes. It is information that you don’t know that you don’t know. This can be anything from an obscure bug in your database software that will add two weeks to your delivery time to the fact that your PM is going to get hit by a car next week. While some things are just impossible to know, these things share a common trait: they arise once we’re in the weeds and obscure themselves during high level planning. The devil really is in the details.

Why Listen?

Assumed knowns and unknown unknowns are markedly more deadly than things you know you don’t know because they typically remain hidden until the worst possible moment. If our manager had not called out “three thousand” as a possible inaccuracy, we might have based an entire portion of our product’s strategy on this number, only to find out a few months down the line that our customer team’s output is different than what we planned for, leaving us in an unfortunate position.

Any individual that participates in an organization can create or contribute assumed knowns as they partake in regular communication. As an organization scales, so does this information. Arguably, this information scales in non-linear fashion due to the exponential nature of social networks. Thus, the best leaders in an organization should put measures in place to identify and mitigate these pieces of misinformation. Otherwise, they may very well see their organization overrun by falsehoods and, consequently, failure.

One trait that distinguishes experienced senior managers/engineers/employees from their juniors is an ability to uncover and mitigate these toxic unknowns. By doing this, one is better able to deliver on their commitments and make informed decisions when new information arises. In other words, they become better at executing. Executors are those that are able to take a plan based on partial information and deliver a full solution on time. When you’re actively focused on uncovering unknown risks, you’re better able to translate the former into the latter.

How to Learn

Learning to listen for unknown unknowns is simply (although not necessarily easily) a matter of establishing a new habit. Assumed knowns and unknown unknowns display a clear and recognizable pattern that can be identified and easily mitigated, if one is able to notice it as it happens.

Assumed knowns tend to appear as assumptions or facts that are too vague. For example, a number that is a little too round (i.e. 1200 versus 1214), or a new set of requirements that seems to be missing a case or two that were previously must-haves. Any information that has an air of imprecision, inconsistency, or referential opacity is a likely culprit needed further investigation.

To mitigate assumed knowns, do exactly as our manager did: question everything. Throw out any decisions that were made using this piece of information. Then, ask for data and resolve any inconsistencies until the case for this information is rock solid. Only then can you reintroduce it to your ecosystem of facts. The cost of questioning is low, since any information that is good will easily stand up to your inquiry.

For unknown unknowns, the strategy derives from their shared characteristic; they’re woven into the details. Make a point to quickly delve into the details of any high-level project or idea before committing to it. You should be able to get to a point where you can outline a clear chain of actionable steps from where you currently are to the desired end result. Zoom in on anything that feels too high-level or hand-wavy and demand it be broken down into concepts and steps that are more concrete. This is where things like MVP implementations, demo prototypes, and design reviews prove invaluable. This process - breaking the nebulous into the concrete - is where these unknown unknowns start to appear, allowing you to revise your high level plans before committing to anything, thus coming full circle.

As you train yourself to identify these information patterns, you will start to become attuned to the characteristics of “unknowns” versus the characteristics of “facts”. Your estimates will become more accurate, and your listening more discerning. You will stop perpetuating misinformation and start demanding that your peers do the same. No more “whatever”.


Brandon Maushund

Personal blog by Brandon Maushund
I have the hard conversations about software