Ruby developer. CTO. Swimmer. Always trying to write more

I’m sitting in the faraday cage of the climbing centre, with no Internet access to distract me, so I’m watching the kids attempt the different walls. Some are starting on a slightly angled wall, then progressing to a vertical wall with lots of hand holds. Others are learning to tie ropes, belay and navigate overhangs etc. It got me thinking a lot about the problems we solve.

There are easy problems to solve, and there are hard problems to solve. And you can solve those problems with a varying degree of speed, efficiency, quality, predictability, and so on.

This wasn’t something I appreciated a lot early on in my career, when I was the person doing the work. Now, though, I have a different perspective and I see problem solving along two main axis: Complexity (of the problem) and Quality (of the solution).

(I’m using “easy” and “hard” to represent two extremes of the complexity axis but of course it’s a scale with many many points on it, and is relative to your current experience)

Typically, we start out being given “easy” problems to work on and we eventually figure out how to solve them. With repetition, feedback, and by intentionally levelling-up our work, we can solve those “easy” problems quicker, to a higher degree of stakeholder satisfaction etc. We’re solving the problems at the same complexity level but to a higher degree of quality.

At this point though, we’re looking for new challenges. We’re probably getting bored with the repetition of the easy tasks and we’re feeling like we’re stagnating and not growing.

Our managers are also feeling a little jumpy and stressed. You see, those easy problems you’ve been solving are not the problems that keep your manager awake at night. They are not the meaningful problems which are written about in strategy documents, or investor meetings, or roadmaps. No, easy problems are not valuable problems. There are just more people who can solve easy problems than who can solve complex problems. This occurs at the team/department level but also at the global market level: companies that solve hard problems can differentiate themselves against competitors, charge more, and attract the best challenge-craving employees.

Now that we’re competently solving easy problems, our managers see an opportunity to give us some of those harder problems which are more impactful and meaningful to the company. Their problem is not just the complex problems, but that they have fewer team members they can give that work to.

If we want to do more valuable work—and, in turn, be considered a more valuable employee—we need to start solving more complex problems. We need to take the uncomfortable step from “easy” problem to “hard” problems. Hopefully we’re given the time, resources, mentors, and a supporting environment to maintain our psychological safety as we make this leap. It will inevitably be a little stressful but all growth is.

Solving hard problems *at all* makes you a valuable person to have around. You’re probably slower than others though, and with a higher chance of failure, and lower quality of solution. Perhaps your solution is more fragile, has a higher cost, is slower to operate, or harder to maintain. You’re *a* problem solver but you’re not yet a sure-thing, an easy bet, a default choice for your manager when they need that hard problem solved.

Again, you level-up: you look around at what good looks like, you seek feedback and apply it, you critique your own work, and you aim to become a more reliable problem solver.

Congratulations, you’re now a very valuable employee. A solver of hard problems. A vanquisher of relevant business problems. A go-to person when something needs fixing.

This is the point when you can easily justify your salary… and more. This is a point when searching for a new job or asking for a raise becomes a *much* easier task because you can justify yourself as a solver-of-business-relevant-problems.

There’s also a positive feedback loop which happens when you can reliably solve hard problems: you get offered hard problems more often and you always have opportunities to seek out new problems, try new approaches, mentor others, and grow yourself. That means you’re not getting stuck at the lower levels of the complexity pyramid, where there’s more competition for your job.

Except that’s not the end… there are always harder problems to solve, or solve to a higher standard, and the progression really looks like:

And then you switch domains, a different codebase, a new language, frontend to backend, etc so sometimes you reset back to easier tasks done to a lower quality.