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'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'd like to add that there is counter-bias for this, the so-called "analysis paralysis". I've seen this a lot. Thinking and building is a delicate balance.
Anyway, don't miss his thread: https://twitter.com/shreyas/status/1282169207350648832?s=20
I'd like to add that there is counter-bias for this, the so-called "analysis paralysis". I've seen this a lot. Thinking and building is a delicate balance.
Anyway, don't miss his thread: https://twitter.com/shreyas/status/1282169207350648832?s=20
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't you support X" "Can you implement Y". Both internally and externally.
We've learned to ask politely to state "problems to be solved" h/t @Padday
We'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
9/ Over the years I learned to think more about the problem. If you are early on your career, this is counter-intuitive. We are wired to solve and be useful, but bad decisions compound quickly.
That's why it's a muscle worth exercising.
That's why it's a muscle worth exercising.
