Choosing Problems That Compound
“Career growth” is mostly a story we tell after the fact. The causal engine is simpler: you’re paid to solve problems; the problems you choose determine the trust you earn; trust determines what you’re allowed to touch next.
The missing question isn’t really “How do I get promoted?” It’s: What kind of problem am I repeatedly taking responsibility for?
There are two types:
- Flat problems are closed and bounded. The problem has a box: clear inputs, clear outputs, few dependencies, and a stable definition of “done.” You can execute well without expanding the world you need to model.
- Recursive problems are open. The more closely you look, the more structure appears: adjacent constraints, second-order effects (and attributions), ambiguous edges, and mushy boundaries where your work touches other work.
People talk about impact, leadership, or “working on hard things.” The concrete mechanism is interface surface area.
A flat problem gives you a small surface area: you can be excellent inside the box, but the box limits what the organization needs to trust you with.
Recursive problems expose seams; Interfaces with other teams, other systems, and ground reality. Seams are where assumptions get audited, dependencies become visible, and tradeoffs stop being theoretical. If you can repeatedly reduce ambiguity at those interfaces, without letting scope dissolve, you become the default owner of adjacent territory. That’s what “more responsibility” usually means in practice.
The flywheel:
- Choose an open problem.
- Earn credibility in one tractable slice.
- Use that credibility to take on an adjacent slice.
- Repeat.
- Promotions, titles, and “scope” follow as trailing indicators.
This is why recursive problems accelerate responsibility: they create trust adjacency. Not “I like this person” trust, but operational trust: If there’s ambiguity, they’ll reduce it. If there’s risk, they’ll surface it early. If there are tradeoffs, they’ll make them explicit.
None of this makes flat problems bad. Flat problems are how organizations scale execution: stable interfaces, repeatable work, predictable delivery. Some careers are built on being the person who clears bounded queues quickly and reliably. If that’s your goal, flat problems are a feature, not a failure mode.
But if the goal is advancement, the shift is to stop treating problems as tasks and start treating them as territory.
The selection rule isn’t “pick the hardest thing.” It’s:
- Prefer the problem where solving it well creates more optionality over time (what I call parabolic adjacency). Where each unit of progress makes the next unit cheaper, faster, or higher-leverage. The returns are convex: early work looks slow, then it compounds.
- Prefer the solution that keeps the system legible and the next step available.
- Prefer work where “done” includes a clearer map of what connects to what.
In practice, that can mean choosing the more entangled project when you have a choice. It can mean choosing roles that sit at seams (product, platform, infrastructure, security, data), where interfaces are unavoidable. It can mean shipping a small fix in a way that preserves a path to a larger fix, so you ship fast without closing doors.
Recursive problems come with a predictable failure mode: people confuse “open” with “unbounded.” They expand scope until nothing finishes, then call it strategy. Open problems still need boxes, just temporary ones. The job is to pick a boundary, make it explicit, and revise it as you learn.
A useful test:
- If I solve this, does it mostly end here, or does it reveal the next constraint?
- Does this work increase the organization’s ability to make future decisions (better metrics, clearer interfaces, fewer unknowns)?
- When this touches another domain, am I expected to hand-wave or to coordinate, align incentives, and carry risk?
If the answers point outward, it’s recursive. And if you can repeatedly take a small, well-chosen bite out of a recursive problem, without pretending you can eat the whole system, you’ll accumulate the only asset that reliably compounds in a career: trusted range.
PS: You can think of organizational “bands” or “levels” as a direct mapping to this model. Higher levels/bands mostly reflect the kinds of problems you’re trusted to solve: not just bigger boxes, but more open problem spaces, more seams, more boundary-setting, more ambiguity that needs to be reduced into decisions.