Read on Twitter
Thoughts around problem thinking and finding root causes.
And some techniques to avoid falling into solution-mode too quickly.
0/
And some techniques to avoid falling into solution-mode too quickly.
0/
1/ In general, we don& #39;t spend enough time thinking about the problem. We jump into solution-mode quickly. Why? Because we get rewarded for solving. But sometimes that leads to solving the wrong problem.
I say this as a serial problem-solver. So how do we fight against that bias?
I say this as a serial problem-solver. So how do we fight against that bias?
2/ Sidebar: @shreyas call this Bias-for-Building Fallacy.
I& #39;d like to add that there is counter-bias for this, the so-called "analysis paralysis". I& #39;ve seen this a lot. Thinking and building is a delicate balance.
Anyway, don& #39;t miss his thread: https://twitter.com/shreyas/status/1282169207350648832?s=20">https://twitter.com/shreyas/s...
I& #39;d like to add that there is counter-bias for this, the so-called "analysis paralysis". I& #39;ve seen this a lot. Thinking and building is a delicate balance.
Anyway, don& #39;t miss his thread: https://twitter.com/shreyas/status/1282169207350648832?s=20">https://twitter.com/shreyas/s...
3/ Back to main: 15 years ago I read about Ishikawa. Back then, the concept blew my mind. However, I did not know where to apply it. I saw the power of it but did not have much real-world applications for it.
4/ Years later, at Auth0, when we started to scale and had our first outage, I learned about the "5 Whys" technique. Someone from AWS introduced us to this concept. Pretty simple but very powerful. Just keep asking why...
I started exercising more the muscle of "root cause"
I started exercising more the muscle of "root cause"
As sales ramped up we would constantly get requests to implement things "Why don& #39;t you support X" "Can you implement Y". Both internally and externally.
We& #39;ve learned to ask politely to state "problems to be solved" h/t @Padday
We& #39;ve learned to ask politely to state "problems to be solved" h/t @Padday
6/ Another: an assertive executive asked for a specific solution to a problem. It turned into an OKR.
Spent a few weeks digging in (interviewing people internally). Turned out that everyone had a diff idea of the problem. Once we aligned on the problem, the solution was clear.
Spent a few weeks digging in (interviewing people internally). Turned out that everyone had a diff idea of the problem. Once we aligned on the problem, the solution was clear.
7/ Recently, I learned these two rules from @ShaneAParrish from @farnamstreet (lots of great content there).
Rule 1: Never accept someone else’s definition of the problem.
Instead, think of it for yourself.
Rule 1: Never accept someone else’s definition of the problem.
Instead, think of it for yourself.
8/ And Rule 2: put a firewall between the problem definition vs problem solution.
Two meetings, one day apart from each other. Give time/space to problem thinking
Two meetings, one day apart from each other. Give time/space to problem thinking
