5 simple steps to problem solving at work
In my early career, many times my enthusiasm got the better of me, and I'd forget to engage my brain before I opened my mouth.
I used to have a worrying habit in meetings. The moment a problem surfaced, the room would go silent as everyone suddenly found their shoes fascinating, praying the boss wouldn't look their way. That’s usually when my mouth would open and volunteer before my brain could stop it. In my mind, I was a heroic leader. In reality, more often than not, I had just adopted a problem that belonged to someone else, and sometimes the fix was way above my pay scale.
The trouble with adopting a problem is that it then becomes yours. Suddenly your name is plastered all over the status updates. You're now the one in the meeting room feeling pure panic while the issue remains unfixed. Sometimes your ability to solve the problem may also depend on your seniority in the company. It may well need someone more senior to bang heads together. Without that authority, you can’t fix the thing, but you can certainly be associated with the failure of it not getting fixed.
That's an accidental resignation in slow motion. It doesn’t happen in one dramatic exit, but rather in one well-meaning, self-inflicted "leave it with me" at a time. Before we look at how to fix this, we need to back up a step and ask, 'What does problem-solving mean in the workplace?'
What is problem-solving, anyway?
In their book Bulletproof Problem Solving, Charles Conn and Robert McLean define problem-solving as decision-making when there is complexity and uncertainty that rules out obvious answers and where there are consequences that make the work to get good answers worth it.
A simpler definition is the process of identifying a challenge or issue, analysing its causes, and finding and implementing an effective solution. And that’s the point. It’s about going through a process, not just reacting in the heat of the moment. The consequences of how you answer a problem can be huge, and they’re normally only revealed with hindsight.
A quick Google search will show you there are lots of problem-solving tools available. Some are simple, some are complex, and I’ll expand on some of them in future posts. But sometimes you need a simple process that’s easy to remember as your go-to default, one you can rely on, especially when emotions are running high.
The consequences of poor problem-solving can be costly and can hold back your career. You may not realise it, but poor problem solving can be a silent assassin.
Here are five simple steps to make sure you don’t find another unique way to resign.
The 5 steps to solve a problem
Step 1: Is it actually your problem?
Always start by asking yourself whether this is your problem or someone else’s. Make this your first thought. Don’t waste your time and energy trying to solve a problem that isn’t yours.
To help work out whether it’s yours, ask yourself two questions:
Have I contributed to the problem in any way?
Who owns the outcome if this goes wrong?
The first question tests whether it’s your fault. The second tests whether it’s your responsibility. They’re not the same thing. You might not have caused a delay, but if you own the deadline, the problem is still yours.
Try to be honest with yourself, because sometimes it’s tough to admit a problem is yours. Other times, people at work will try to put the blame on you and make you feel like it’s your problem when in reality it isn’t. This matters because it’s easy to panic and jump straight into solution mode, only to find out it was never your problem in the first place.
If it turns out the problem isn’t yours, hand it back properly. There’s an example of how to do that with the SAFE Method towards the end of this post.
If it turns out the problem is yours to solve, use the following steps to find the right way forward.
Step 2: Work out what’s really going on
Next, understand the issue by working out what's actually happening. That's simple to say but not always easy to do. If I am struggling to pin down exactly what the issue is, I use freewriting (read this post on freewriting)
To start, ask yourself whether it’s related to workload, people, communication, fairness, expectations, or something else.
I find that by letting my mind wander as I write, the issue becomes clearer. Keep emotion out and stick to facts. If necessary, breaking it down into manageable parts can help provide focus that will lead you to the real issue causing the problem. Whatever you do, avoid the trap of the vague problem statement. Stating that "the system is slow" or "communication is bad" is just admiring the mess, not defining the problem.
Also, be mindful not to fall into the trap of writing the solution at this stage. If an idea for a solution comes to mind, capture it, but then work through the rest of the steps to make sure you land on the best one.
Rushing into analysis with a vague problem statement is a recipe for disaster. It will waste your time and may turn out to be yet another way to resign.
Step 3: Picture the outcome, then find the routes
Now think about what you’d like to happen. Start by asking yourself: in an ideal world, where would I like to end up? What position, what outcome?
Once you know the destination, generate as many routes to it as you can. In true brainstorming style, don’t disregard anything at this stage. I’ve often found that combining parts of a couple of solutions gives me the answer I need.
A simple logic tree is a useful tool here. Put the outcome you want at the top and branch out the different ways you could get there.
Step 4: Evaluate and choose
Now it’s time to evaluate your options. Look at each one and decide how successfully it will get you to the outcome you want.
How much analysis you do depends on the size and complexity of the problem and its potential impact. A rule of thumb may be good enough. If you find you need a lot of analysis, other problem-solving tools may be more appropriate.
With this simple model, your gut feeling is normally good enough, but make sure you give proper thought to the risks behind each option.
Be mindful of your biases. Don’t judge an answer purely on your previous experience without testing whether it fits the problem at hand. Conn and McLean describe this as availability bias: reaching for a familiar mental model because it’s handy, rather than building the right one for the problem in front of you.
Step 5: Act, then review
Once you’ve evaluated your options, choose the best one, take action, and then review the results.
Did you get the outcome you wanted? What did it cost you in time, effort, and goodwill? If it didn’t work, go back to Step 2. More often than not, a solution that misses the mark started with a problem that was defined wrongly.
Using SAFE to hand the problem back
Back to that enthusiastic yes. Let’s say you’re in a steering meeting. Releases keep slipping, and nobody seems to know why. In a moment of madness, you say, "Leave it with me.”
Three weeks later, you’ve found the cause. Two teams share one test environment, and each has priorities set by a different director. You don’t manage either team, and you don’t control the budget. You can see the fix, but you can’t make anyone do it.
Step 1 tells you this isn’t your problem to solve. Now it’s time to hand it back, properly.
Situation
Stick to facts, not frustration. Releases have slipped three times in two months. Each slip traces back to the same test environment. Two teams need it at the same time, and each is following its own director’s priorities. Nobody is doing anything wrong. The system just has no referee.
Alternatives
Always arrive with options, not just a diagnosis:
The two directors agree on a booking rota for the environment.
Fund a second environment. Bring a rough cost so the conversation is real.
Leadership decides, release by release, which work takes priority.
You’re giving the owner choices, not choosing for them.
Firm words
Say it to whoever asked you to look into it, or to your manager:
“I said I’d look into the release slips, and I have. The cause is a shared test environment, and both teams have legitimate but competing priorities. There are three ways to fix it, and they’re on one page here. Every one of them needs a decision I don’t have the authority to make. I’m happy to help put whichever option you choose into practice, but the decision needs to sit with the directors. Can we get it on Thursday’s agenda?”
It’s calm and helpful, and it’s clear about whose decision this is. Notice what’s missing: no apology for not fixing it, and no blame.
Evidence
The release dates and slip log
The environment booking records showing the clashes
The cost estimate for option 2
A short follow-up email confirming who agreed to own the decision
That last one matters. If the problem resurfaces in six months, the record shows you handed it to the right owner, not that you dropped it.
A few practical tips are:
Before saying yes, ask: “Who owns the decision if this needs one?”
Separate fault from ownership. They’re not the same thing.
Write the problem down before you write the solution.
Decide where you want to end up before choosing how to get there.
If you can see the fix but can’t make it happen, hand it back with SAFE.
And finally a resignation trap warning:
The enthusiastic yes feels like leadership in the moment. But volunteering for a problem you don’t have the authority to fix can attach your name to its failure. Nobody will remember that you were trying to help. But they will remember that it didn’t get fixed and that it was your fault.
Comments