Is my problem developmental or merely hard?
Solvable vs unsolvable problems
My previous essay characterized developmental dilemmas as problems, where your stuckness is a consequence of limitations in your current way of meaning-making. It presented a distinction between merely difficult but solvable dilemmas and developmental dilemmas.
Readers already familiar with Professor John Vervaeke’s work had questions around what makes a developmental dilemma, well, developmental?
As Vervaeke points out, every problem has a corresponding frame. Like him, I use this word to point to something broader than one’s propositional beliefs. It refers to the person’s total pre-reflective/unconscious orientation to a given situation. Within Vervaeke’s nomenclature, I’m referring to the full set of propositional, procedural, perspectival and participatory knowledge which shapes what you find relevant in relation to a situation. More concretely, the things that go into your framing of a situation involve your body’s assessment of safety or threat, the emotional dispositions that color perception before conscious thought begins, and the stories and beliefs that organize raw sensory information into meaning. These are all deeply entangled during the construction of your framing of a problem.
What distinguishes a developmental problem from a merely hard one?
A problem’s overall frame defines what counts as a solution, and once the solution is found it implies how it can be verified with certainty.
Hard problems are solvable in the sense that the frame is stable. The work involves finding the right answer within the frame. The answer can be verified with certainty.
Developmental problems are unsolvable in the sense that the frame itself is unstable and uncertain, and this instability precludes the problem having a “final solution” because such a solution presupposes that the frame itself is “final”. Developmental work isn’t merely about finding the right answer within the right frame. Rather, it involves finding a better frame despite the fact that it’s impossible to find the best frame. In contrast to hard solvable problems, increased clarity and confidence is the best you can hope for with developmental problems.
These two examples cleanly show this distinction.
Calculating whether I have enough money saved up to pay rent for the next twelve months at my current lifestyle is a hard solvable problem. It has a very clear frame with all the relevant variables and constraints, and it has clean verifiable solutions.
In contrast, “Should I leave my stable job at DeepMind for a risky sabbatical?” was a developmental problem. Answering this question involved engaging with a number of solvable problems (e.g. calculating how much money I actually had, projecting how much my current lifestyle would cost over the next year, etc). However, the core difficulty in answering this question arose from an overall framing of the question itself. This framing was built on past pain of taking risks and failing, my overall stories around safety and risk, and an underlying identity that got attached to stability and prestige. This identity got challenged whenever I considered leaving my job because there was an emotional charge of fear, dread, etc. All of this left me stuck. This stuckness was disproportionate to the “objective” reality of pushing buttons on a keyboard to send a resignation email, and subsequently pushing buttons on Google’s HR portal.
The previous essay described a causal sequence of pain generating stories, stories generating judgements, judgements generating fears and fears shaping habits. You then experience a “wall” when these habits pull you in competing directions. This sequence describes the layers of the overall frame that ultimately create the experience of the “wall”. The overall practice within that essay provides an opportunity to peel back the frame’s layers, and upgrade its underlying stories, resulting in a more spacious frame.
Is the distinction between solvable hard problems and developmental problems actually that clear cut?
Unfortunately not. Most solvable hard problems reveal developmental roots when examined more closely. All problems can be framed at multiple levels of depth, with the shallowest depths presenting solvable problems and the deepest depths presenting unsolvable developmental problems.
Here are two examples of problems that aren’t obviously developmental and might even be confused as hard solvable problems. They’re actually developmental if we engage with them closely enough.
Arun’s the CEO of a company and needs to set the company’s strategy for next year. It involves gathering market data, analyzing competitors, assessing the company’s resources, looking at the P&L, etc. So it superficially seems like a hard solvable problem. However, peeling back the frame reveals developmental roots. Arun’s pattern of risk-aversion shapes which strategies feel “realistic” or even “thinkable”. Consequently, the founding team’s unspoken dynamics in relation to Arun shape which directions feel “safe”. These then determine which options actually get serious consideration within their strategy meetings. The final strategy is framed by the developmental shapes of the people in the room. Although it’s primarily shaped by Arun since he has the most power in these meetings. Arriving at a genuinely “better” strategy might require Arun and the executive team to first shift and upgrade their current framing of the situation.
Similarly, Arun has an engineering team that keeps failing to ship a feature. They frame it as a technical problem (i.e. architecture, dependencies, timelines, etc). However, the real issue is that the Tech Lead and PM have fundamentally different visions and neither sees the other’s perspective. The TL previously experienced the pain of production failures due to messy code, and he’s determined to never let that happen again. These experiences frame what a “good product” means to him. The PM previously experienced the pain of losing users to a faster, scrappier startup where slow iteration killed that entire org within the megacorp. Similarly, these experiences frame what “good product” means to him. The PM/TL are genuinely experiencing the competing values of “stable architecture” and “move fast and break things”. Each of their framings strongly filters what feels “realistic”, “thinkable”, “viable” or “safe” to them. Resolving this tension requires resolving the underlying developmental problem, although many hard solvable problems will get solved along the way. This is why buying a fancy new project management tool, writing clearer specs, etc. often don’t work to resolve such tensions. Such tools are solutions to hard solvable problems rather than developmental problems.
The following example makes the nested relationship between hard solvable problems and developmental problems even clearer:
Layer 1 (hard solvable - technical problem): The codebase has too much tech debt, making changes slow and error-prone.
Layer 2 (hard solvable - process problem): The codebase is a mess because requirements keep changing mid-sprint, because customer requests get injected directly into the sprint outside formal planning. The team has to scramble and cut corners to keep up.
Layer 3 (developmental - behavioral problem): Customer requests get injected mid-sprint because Arun personally accepts every customer feature request. He routes them to the VP as a P0 priority. The team isn’t able to push back, and it looks like a behavioral problem between Arun’s and the VP’s dynamic.
Layer 4 (developmental - identity problem): Arun keeps impulsively saying “yes” because his identity is built around being a leader who “always delivers”. Saying “no” threatens his identity and feels extremely unsafe.
Layer 5 (developmental - biographical problem): Arun can’t say “no” because he internalized in his childhood that he could only earn love through performance, and transactional value. He has an unconscious story about what he believes makes him worthy of love and belonging, and that makes it hard to say “no”.
Layers 1 and 2 can be treated as hard solvable problems, and solved via technical solutions. However, such solutions only provide temporary relief since the “root cause” is developmental at deeper layers of Arun’s cognition. Fixing developmental problems at their earlier layers only migrates the symptoms elsewhere in the company. Superficially, they often look like totally disconnected problems.
As an aside, Brian Whetten calls such problems “beachballs” where developmental problems are confused for solvable problems. They’re beachballs because the moment you believe you’ve “solved” the problem by pushing it down into the water, it pops up with momentum the moment you let go. The harder you push down, the harder it pops back up. Leadership problems within a company are often beachballs.
All problems are embedded in human contexts. Human contexts are shaped by psychological development, so all problems become developmental if you dig into them deeply enough.
The practical takeaway isn’t that “everything is developmental”. Rather, people systematically underestimate how often the developmental layer is actually what’s most relevant to produce a satisfying outcome.
Whether a problem is developmental depends on the person-problem relationship, neither on the problem nor on the person alone. Different people have different life circumstances and therefore frame the same context differently. Being “unemployed” or taking a “sabbatical” likely means something experientially different to a minimum wage McDonald’s worker, a wealthy tech bro and a billionaire.
The useful distinction isn’t between problems that are developmental and problems that aren’t, but between problems where the developmental layer is relevant right now and problems where it isn’t. A developmental problem’s relevance depends on a person’s current developmental edge and the broader context they’re in. This in itself is a deep question and outside the scope of this essay. I plan on writing more essays on this soon.
If the frames of developmental problems are “the problem”, why doesn’t more information help?
Consider the following questions:
What are the pros and cons of leaving my job?
Do I have enough money to weather a market downturn?
What does my mentor think about me leaving my job?
Such problem-level analysis operates entirely within the frame. Every answer to every question is shaped by the very frame that may need to change. Given that the frame itself may be the obstacle, you often feel more stuck the more you analyze the problem’s content within the frame. Making pro/con lists, gathering more data, etc. are useful tools for hard solvable problems, but may not bring you any closer to shifting the frame itself if they don’t consider the frame’s underlying layers.
Instead, consider the following questions:
What fears and stories are shaping how I see the decision to quit my job?
What assumptions about risk am I treating as unquestionable?
Why does a given option feel unthinkable?
What judgements am I making about myself or other people whenever I contemplate changing the frame?
Such frame-level analysis makes the frame’s own structure the object of examination. It’s fundamentally different from problem-level analysis even though both involve careful, structured thinking. Your unconscious framing of a situation includes the body’s state (e.g. fears, judgements, pain, etc), and leaving them under the surface impairs the analytical tools that might be available.
This frame-level analysis is exactly what the practice from my last post does. It examines the frame’s own structure by unpeeling these fears, judgements and pain rather than wasting time gathering more information within the frame.
Both frame-level analysis and problem-level analysis are typically required to make progress on a developmental problem. The frame-level analysis provides better questions, and a better framing, within which problem-level analysis can flesh out more information. This then motivates some proportionate forward action, whose resulting outcomes set the stage for the next developmental dilemma and frame-level analysis.
Problem-level analysis often yields clean and “final” solutions, but frame-level analysis defies such finality.
If there’s no “solution” for developmental problems in the traditional sense, what does progress look like?
Progress on developmental problems often yields clarity on the framing, or actions that could improve the framing, rather than yielding “the answers” themselves. More specifically, developmental practices create more spaciousness to ask better questions to oneself, other people or search engines/AIs.
The archetypical challenge of psychological development is that the new frame can’t be fully specified in advance via problem-level analysis. Broader implications of the new frame are discovered “on the fly” via frame-level analysis or retrospectively once you’ve taken actions and new information has started to come in. This is why making developmental progress can feel both scary and exciting. You don’t know what will happen next until you do it.
This reveals another way to distinguish between hard solvable problems and developmental problems. Having the right question is often enough to produce sufficient clarity and forward movement to solve hard problems. The shape of the answer is knowable even if finding it is computationally difficult, because the frame is stable enough once the question is well-formulated. In contrast, even a well-formulated question doesn’t provide sufficient clarity to “solve” a developmental problem because the frame that would define what a “good answer” looks like is itself constantly evolving.
We can see this contrast between actions taken at Level 1 and Level 5 within the example above. The situation within Level 1 lends itself to very stable framings with clear “right answers” once the right question is found. The situation in Level 5 is far more nebulous, and might require substantial iteration until Arun makes progress on his childhood trauma.
Conclusion
Treating a developmental problem as a solvable problem wastes energy and reinforces stuckness.
The first move when encountering a “hard” problem is to ask yourself whether you’re engaging with a hard solvable problem, or a developmental problem.
Acknowledgements
Thank you to Brian Whetten, Charlie Awbury and Professor John Vervaeke for teaching me everything discussed in this post.