The other day an old friend asked me about a roadmap I put together in 2016. It contained 5 initiatives that I felt were strategic and important and he had just wrapped up delivering on all 5. (RP you prompted this article!) It had taken 7 years but innovation is a watch that often runs slow. My friend asked “How did you know you were right?” and I was completely caught off guard. Here’s why…
At Amazon, we had 14 leadership principles (they’ve since added 2 bringing it up to 16). When I first read through the list of principles they almost all made immediate sense, e.g. “Bias for Action”, “Customer Obsession” and “Frugality” but one jumped out; “Are Right, A Lot”. Are right a lot? What a pompous notion! How about “Be humble”?
It was around this time I was becoming exposed to the tight-knit and highly revered Principal Engineer community at AMZN. This group was spoken off in hushed tones and consistently cited as “being right a lot”. I thought wow, they must be really smart, or at least have a high opinion of themselves. Or both.
It turned out I had completely misunderstood the principle.
How to be Wrong
Being wrong is something I am VERY familiar with. When you use data to drive decision making there are only two ways to be wrong;
Your reasoning is right but the data it’s based on is wrong.
Your data is correct but your reasoning is wrong.
I lied there’s a 3rd way; Your data and reasoning are both wrong! If this is the case you should stop reading now; I cannot help you.
Let’s dig in a bit further;
Data can be wrong in any number of ways including but not limited to:
The data is unreliable, inaccurate, biased, or incomplete.
You’re suffering from Cognitive Bias and only acknowledging the data that suits your hypothesis whilst ignoring data to the contrary. This is known as Cherry Picking.
Your reasoning can be wrong due to…
Lack of experience - You’ve never encountered this situation before and hence cannot anticipate all the factors that can influence an outcome.
Lack of self-awareness or The Dunning Kruger effect; Those with little knowledge overestimate their expertise and those with a high degree of knowledge underestimate their skills.
If your data is right, and your reasoning is right - your conclusion will be right. Let’s restate this in more general terms; If your data is genuine, unbiased, and inclusive, and your reasoning is internally consistent, then your conclusion will be defensible.
Reframing things in terms other than “right and wrong” is important as I’ll explain in a minute.
With good data and solid reasoning you can explain your conclusion to an objective 3rd party. They might not agree, but at least they’ll acknowledge that your conclusion is reasonable and the conversation can progress from there.
How to embody “Are Right, A Lot?”
So how can we live up to this principle like a true Amazonian (or just a solid engineer)? The secret is to constantly question your conclusions. When you find a flaw embrace it and if necessary change your mind! Try to disprove your own thinking and adjust your conclusions as new information comes in. Do this and you will embody “Are Right, A Lot”! It’s that easy!!! In practice, however, when pitched against the frailty of our human emotions and egos it’s actually very, very hard.
Some tips to get you there;
Have Strong Opinions…Loosely held - A good engineer regardless of career level should always have a point of view. However! Let go of your opinion as soon as new information comes along that doesn’t support your conclusion.
Keep an open mind - Be open to new ideas, especially those you disagree with.
Practice Introspection - question everything, most of all yourself.
Avoid Dogmatic beliefs - “Only a Sith deals in Absolutes”
Decide last - Try to understand the implications before making the decision. Be cautious of “one-way doors”. Is this decision reversible? If so move fast. Is this a one-way door? be cautious before jumping through it.
So much of our world is colored in binary terms of right and wrong. Good and Evil. On and Off, 1 and 0. Engineering is never that simple. Even the simplest technical problem is a balance, a trade-off between ambiguous alternatives.
“How did you know you were right?” - the truth is I wasn’t trying to be “right” back in 2016. I was just trying to write down what I thought made sense based on the data I had at the time and my own experience/reasoning. Younger me used to strive to be right, to have perfect judgment and prescient knowledge. Nowadays I just try to be open to new information and adjust as I go. For me, that’s very, very hard, but it feels right.