> In the town near our house there's a shop with a sign warning that the door is hard to close. The sign has been there for several years. To the people in the shop it must seem like this mysterious natural phenomenon that the door sticks, and all they can do is put up a sign warning customers about it. But any carpenter looking at this situation would think "why don't you just plane off the part that sticks?"
I usually refer to it as a "problem-solving mindset" – a way of thinking where you approach a situation as something that could have a universe of solutions, but then learn to break down what exactly you want to solve, whittle down solutions to try, or whether you even need to reframe the problem, etc.
Another related thought (sorry but I don't remember where I saw it) is the idea of solving a problem vs making a problem go away, which are slightly different things. Solving a problem is like removing toxins from a car's emissions. Making the problem go away is to stop the car from having any emissions in the first place.
But the carpenter analogy is apt also because software people tend to think that the solution for many things is software (since that's what we're skilled in), whereas in some cases it's a human collaboration solution or something else.
This analogy is also a good example of how perceived solutions always stem from what people are comfortable with (the every problem is a nail when you have a hammer). A door installer may see the sticking door a see it as an alignment issue and adjust the hinges.
I think the shop-owners, the carpenter, and the door installer all actually had a problem solving mindset. The shop-owners solution was to post a sign, the carpenter to plane, the installer to adjust. Each just had a different knowledge and experience base to work with.
I really identified with that part too. I also really liked what you said about the idea of solving a problem vs making a problem go away. Tell me if you think I'm wrong, but I've always believed that the 4 things those two different philosophies/approaches have in common is that they both require:
1.) elevating others' needs (the problem you're solving) above your own
2.) Sensitivity to others' needs
3.) Earnestness
4.) A world/psychology/personal belief system that's positive sum and collaborative in a global sense (outside of context-dependent contests and competition that are limited in scope).
I find that being able to put yourself in another person's shoes (whether you're understanding their motivations when designing solutions) etc, is absolutely key in performing all those.
But it's also important to adapt a solution to an environment where there are bad actors that do act in their self interest or incentives that are different in different places/professions/cultures.
For example, I am very curious about any AI-based solutions in the legal world where all the incentive structures are skewed heavily towards hourly billing. How are you going to get law firms to adopt technologies that might cut their billable hours in half?
> In the town near our house there's a shop with a sign warning that the door is hard to close. The sign has been there for several years. To the people in the shop it must seem like this mysterious natural phenomenon that the door sticks, and all they can do is put up a sign warning customers about it. But any carpenter looking at this situation would think "why don't you just plane off the part that sticks?"
I usually refer to it as a "problem-solving mindset" – a way of thinking where you approach a situation as something that could have a universe of solutions, but then learn to break down what exactly you want to solve, whittle down solutions to try, or whether you even need to reframe the problem, etc.
Another related thought (sorry but I don't remember where I saw it) is the idea of solving a problem vs making a problem go away, which are slightly different things. Solving a problem is like removing toxins from a car's emissions. Making the problem go away is to stop the car from having any emissions in the first place.
But the carpenter analogy is apt also because software people tend to think that the solution for many things is software (since that's what we're skilled in), whereas in some cases it's a human collaboration solution or something else.