We love hard problems, or at least we love solving hard problems.

That feeling of breakthrough, when you’ve achieved something that felt impossible just yesterday is addictive! As software developers, we get this all the time with small challenges and I would suspect that it's the continuous problem solving and breakthrough that draws many of us to software engineering.

However, hard software problems are on the easier end of the scale of hard problems. We know how to divide and conquer, or how to systematically work through logic, or when to just use trial and error.

It's the really hard problems that can feel like there is no way forward and these are usually human problems, rather than software problems.

Poop

There’s a great proverb:

Without oxen a stable stays clean, but you need a strong ox for a large harvest.

Which basically means, if you’re getting things done, there will be poop on the ground. We see this all the time with people who are high achievers — they often leave a mess behind them. Technical debt is another great example — you wouldn’t have any if you didn’t write any code but if you prioritise moving quickly, then you’re probably going to leave behind technical debt. Poop on the ground. Of course, there’s time for getting things done and time for cleaning up — but sometimes the poop feels like things aren’t going right, or someone is causing problems by getting things done.

If you contrast a SaaS product with growing sales, vs one with no sales — the growing product is far more satisfying, but will also have far more problems. The sales team will be making promises, deadlines will feel unrealistic, customers will be asking for more, things will be breaking. All in the name of growth.

Or if you’ve ever worked for a visionary entrepreneur, who zigs and zags and is always thinking about the next great thing and seems to have forgotten about the super-urgent-top-priority from last week. They create mess, because they are moving fast.

I’m not trying to excuse the mess — we still need to clean it up, but I do want to say that if we can see it for what it is, then perhaps it will feel more like a hard problem that is worth solving, as opposed to a bad situation that there is no way out of.

Control

The hardest class of hard problems has got to be when we lack control. When someone else is making decisions that we have to live with. If you’ve ever worked on a software product with a team bigger than one, then you’ve probably had to live with decisions other people have made about the architecture, the tech stack and of course, deal with the tech debt they left behind.

Often someone else is making decisions about priorities and budgets. And why do you always end up trying to deliver against an estimate that someone else gave the customer?

Patrick Lencioni has a great model for working through hard problems like this in his book, The Five Dysfunctions of a Team. The short version is that if you want a high performing team, then you need accountability. You need your team to confront difficult problems and solve them together. But to have a culture of accountability, you need commitment. Commitment comes from having clarity around what the team’s purpose is, but clarity also comes from being able to identify problems, instead of just living with them. But to be good at identifying problems, you need a culture where conflict is ok, where people can raise issues and discuss them, instead of just complaining or ignoring the problems. And this all starts with trust — so if you are lacking the ability to identify, discuss and solve hard problems, then start by building trust in the team. This looks like people being willing to be vulnerable and it looks like healthy conflict in every meeting.

I can highly recommend reading Patrick’s book — in fact, read all of his books once a year!

IDS

A great model for hard problems (and for bad smells) is IDS. This is borrowed from Traction by Gino Wickman with some insights from Shane Parrish.

Identify

Don’t assume the initial problem stated is the actual problem. Often we only have a bad smell (ie something feels wrong), but our instinct is to dive in and solve or dismiss the problem, as opposed to stop and think about whether we are solving the right problem. Dig deeper, look for the root problem, explore the problem, ask, “what would need to be true for this problem not to exist in the first place”. Get agreement from everyone on what the root problem actually is.

Discuss

Once you’ve agreed on what the problem is, discuss it before solving it. Brainstorm. Listen to everyone. Don’t assume the first solution is the only solution or that the options are binary. We so often get blinded by the idea that we only have two options in front of us — option A and option B. A good way to create a third option is to ask, “what would we do if option A wasn’t possible? Ie, if it was illegal”. Find an option C. Then ask, “what would we do if option B wasn’t possible?”. Find an option D.

Solve

Agreeing to solving a problem can come with risks, but the worst outcome is to discuss the problem and do nothing. This is what often happens in retrospectives. Don’t fail to do anything, because you are looking for 100% certainty. Data is your friend, but trying to rely entirely on data is another great way to do nothing. A great way to solve a problem, when you lack certainty is to run an experiment. For 1 or 3 months, we will try doing X. Then we will circle back and discuss how it went and be prepared to try something else.

Consequences

A few years ago, I was in a position where I was lacking control on a project. None of my ideas were being listened to, the customer kept changing their mind and we were going around in circles. What I failed to do at the time, was identify, discuss and solve this problem. Instead, over time, I started to feel like I had no control, then I lost hope, then I gave in and just did what I was told. At the time, it felt like the right thing to do, but it wasn’t. It was the easy thing to do. Identifying this as a hard problem would have required me to be vulnerable and to initiate a conflict with a customer. I didn’t do this at the time and things didn’t end well. All trust was lost, because the project was over time, over budget and sub-standard. It was one of the only times in my career when I’ve done something I didn’t believe in.

So I’m writing this blog to myself, my team and anyone who’s listening. We’re faced with hard problems every day, but we often don’t recognise them as hard problems. It's easier to complain that someone is creating a mess, or that there is nothing we can do about a situation. If you find yourself here, this is a classic case of the five dysfunctions at play and the only way forward is as a team.

Build trust, encourage conflict, commit and hold each other accountable.