Solve The Problem By Solving The Problem
A forcing heuristic that catches you managing a problem's symptoms instead of removing its cause.
- Difficulty
- Easy
- Time to result
- ~days to results
- Steps
- 5
- Confidence
- 88%
Emmett Shear built this out of an internet meme format - 'Have you tried solving the problem by X' - and kept the degenerate version as a life motto. His observation is that when people bring him a problem, the problem is usually obvious, and what they actually ask for is help handling the consequences, avoiding the need to solve it, outsourcing it to someone else, or copying how others coped with it. His canonical illustration: the website is too slow, so instead of designing a loading spinner that distracts people from the slowness, make it fast enough that no spinner is needed. He is explicit that the heuristic has a boundary condition - if the problem is a perpetual motion machine, the direct assault is itself the mistake and you should hack around it or learn to live with it. His read is that tech people in particular over-love the hack, so on balance the corrective points one way. He also links the flinch to responsibility: founders avoid the direct solve because owning it means there is no teacher and no customer who will hand them the answer.
Origin
Shear adapted it from a Twitter meme format - 'Have you tried solving the problem by [anything]' - and one degenerate variant became a personal motto he now uses when advising founders.
Core principles
- 01The problem is usually obvious; the avoidance is the interesting part
- 02Symptom management is not problem solving
- 03Check whether the problem is solvable before attacking it head-on
- 04Tech culture over-rewards the clever hack
- 05Avoidance is usually fear of owning the outcome
How to run it
- 1
State the actual problem
Strip the request down to the underlying problem rather than the help being asked for. When someone asks how to handle consequences, or how to get someone else to deal with it, note that the problem itself has not been named yet.
Pro tip If you cannot say the problem in one sentence, you are still describing symptoms.
- 2
Audit your avoidance moves
List every current activity that is about the problem but is not the problem: the mitigation, the distraction, the escalation, the search for prior art on coping. Shear's example is building a loading spinner instead of making the site fast.
Watch out Copying how others coped is the most respectable-looking form of avoidance.
- 3
Run the solvability test
Ask whether a focused stretch of work would actually make this go away and whether it is worth that work. Shear's test case for the failure mode is the perpetual motion machine - a thing too hard to be worth attacking directly.
Pro tip If people are flinching but the thing would yield to six months of work, that is the signal to go direct.
- 4
Pick the branch and commit
If solvable, kill the workarounds and put the effort into removing the cause. If genuinely unsolvable, stop trying to solve it and deliberately design the hack or the way to live with it more effectively.
Watch out Attacking an unsolvable problem head-on is the mirror-image mistake, not a virtue.
- 5
Name the owner
Assign responsibility for the direct solve explicitly. Shear ties founders' fear of this move to a reluctance to take responsibility for someone else's problem, where a wrong idea lands entirely on you and nobody can be trusted to do it for you.
Pro tip Expect to have to defend the answer to people who say it is wrong.
In the wild
Shear's standing illustration is a website that is not fast enough. The instinctive move is to design a loading spinner that distracts users from the wait - a well-crafted piece of work that leaves the underlying slowness completely intact.
→ The direct move is to make the site fast enough that no loading spinner is needed at all, which removes the problem rather than dressing it.
Shear applies the heuristic to himself and finds he passes it on the object level - when something needs programming, he programs it - but fails it one level up. He will dig indefinitely at a problem while never considering asking another person for help.
→ He reframed his own behaviour as trying to solve the problem while avoiding asking anyone for help, which is not really trying to solve the problem, and was surprised to learn other people do not have the same constraint.
Common mistakes
Applying it to problems that are actually unsolvable
Shear flags this as a huge mistake. When the thing really is too hard - his perpetual motion machine case - the correct response is to stop attacking it directly and go looking for a hack around it, or a better way to live with it.
Treating prior art as the solve
Asking how others have solved the problem in the past is the closest of the avoidance moves to a real answer, which is exactly what makes it dangerous - it feels like progress while nobody on your team has taken responsibility for removing the cause.
Confusing effort with directness
Elaborate mitigation work is often harder than the direct fix. Volume of work is not evidence you are pointed at the problem; only the disappearance of the cause is.
Is it for you?
Best for
Founders, engineers and operators in tech who instinctively reach for the clever workaround before the direct fix
Not ideal for
People stuck on genuinely unsolvable problems, where the correct move is a hack or an acceptance strategy
From the transcript
“Have you tried solving the problem by solving the problem?”
“sometimes the way to solve the problem is just like just to actually try solving the problem”
“That's a huge mistake, and you should be looking for a hack around needing to solve the problem.”
From the episode
Emmett Shear: Life After Twitch, Jeff Bezos Lessons & AI Doomsday Odds
Emmett Shear