Posts

Why Your Problem Solving Process is Probably Backwards (And How Mine Used to Be Too)

Related Articles:

Three months ago, I watched a senior manager at a major Melbourne firm spend forty-seven minutes in a meeting trying to solve a problem that didn't actually exist.

I know this because I was the consultant who'd been called in to "fix their communication breakdown," and by minute twelve, it became crystal clear that what they thought was a team performance issue was actually just one person forwarding emails to the wrong distribution list. But here's the kicker - nobody bothered to check the basics first.

That's when it hit me: most of us have our problem-solving process completely arse about.

The Dirty Secret About Problem Solving Nobody Talks About

After seventeen years of running workshops across Queensland, New South Wales, and Western Australia, I've noticed something that'll make your head spin. About 78% of workplace problems get "solved" without anyone actually defining what the bloody problem was in the first place.

We jump straight into solution mode. It's like trying to navigate to a destination without knowing where you're starting from.

I used to do this too, don't get me wrong. Back in 2009, I spent three weeks redesigning an entire customer service process for a Brisbane logistics company, only to discover later that their main issue wasn't process-related at all - their phone system was dropping calls. Sometimes the simplest explanation is the right one, but we're too clever for our own good.

Why Most Problem Solving Frameworks Miss the Mark

Here's an unpopular opinion: those neat, tidy six-step or seven-step problem-solving models you see in textbooks? They're brilliant in theory and occasionally useful in practice, but they miss the messy, human reality of how problems actually unfold in real workplaces.

Real problems don't arrive with clear boundaries and obvious symptoms. They're tangled up with personalities, office politics, budget constraints, and that bloke from accounts who "doesn't like change."

The traditional approach goes something like: identify problem, gather information, generate solutions, evaluate options, implement, review. Sounds logical, right?

Wrong.

That's backwards thinking disguised as forward planning.

The Problem With "Problem Identification"

Most of us think we're ace at spotting problems. We're not.

What we're actually good at is spotting symptoms, complaints, and the loudest voices in the room. But symptoms aren't problems - they're just the evidence that problems exist.

Take that Melbourne firm I mentioned. The symptom was "communication breakdown between teams." The actual problem was one person's email mishap that snowballed into interdepartmental finger-pointing. But because we focused on the symptom (teams not talking), we nearly implemented a whole new collaboration platform.

I learned this lesson the hard way during my early consulting days. A Perth mining company brought me in because their safety meetings were "too long and unproductive." I spent weeks analysing meeting structures, participant engagement, and agenda formats. Turned out the real issue was that they were holding safety meetings during shift changeover when half the attendees were mentally checking out for the day.

Sometimes the problem isn't what everyone thinks it is.

The Reverse-Engineer Approach That Actually Works

Here's what I've discovered works better than traditional problem-solving processes: start with the outcomes you want, then work backwards to understand what's preventing them.

Instead of asking "What's wrong?" ask "What does success look like, and what's stopping us from achieving it?"

This shifts your entire perspective. Suddenly you're not fixated on everything that's broken - you're focused on the gap between where you are and where you want to be.

For instance, instead of "Our customer service is terrible," try "We want customers to feel heard and valued. What's preventing that experience?" The second framing opens up completely different solution pathways.

This approach has saved me countless hours of chasing red herrings. When a Gold Coast retail client complained about "staff motivation issues," we reversed-engineered from their ideal outcome: "Team members who proactively help customers and feel proud of their work." Working backwards revealed that their staff weren't unmotivated - they were confused about their role boundaries and frustrated by inconsistent management expectations.

The Uncomfortable Truth About Information Gathering

Another controversial take: we often gather too much information, not too little.

Analysis paralysis is real, and it's expensive. I've seen teams spend months researching problems that could've been solved with a conversation and a cup of coffee.

The trick is knowing what information actually matters versus what just makes us feel thorough and professional.

Here's my rule of thumb: if you can't action the information you're gathering, don't gather it. Sounds obvious, but you'd be amazed how much time gets wasted on "comprehensive data analysis" that leads nowhere.

A Sydney tech startup once hired me to help with their "productivity crisis." They had spreadsheets tracking everything from email response times to coffee consumption patterns. Seriously. But nobody had bothered to ask their developers what was actually slowing them down. Turns out their deployment process was a nightmare, and fixing that one bottleneck improved productivity by 40%.

The Power of "What If We're Wrong?"

One question that transformed how I approach problem-solving training is this: "What if our assumptions about this problem are completely wrong?"

It's uncomfortable to ask, especially when you've already invested time and ego into a particular problem definition. But it's also liberating.

Last year, a Darwin-based construction company was convinced they had a workplace safety problem because incident reports were increasing. They were ready to implement expensive new safety protocols and additional training programs.

But when we asked, "What if the increase in reports is actually a good thing?" everything shifted. Turns out, a new site supervisor had been encouraging more detailed incident reporting, including near-misses that previously went undocumented. The "problem" was actually improved safety culture in action.

Sometimes what looks like a problem is progress wearing a disguise.

Why Solutions Should Come Last (Not First)

Here's where most of us go wrong: we fall in love with solutions before we understand the problem.

We hear about a great strategy that worked for Company X, or we read about an innovative approach in Harvard Business Review, and suddenly we're looking for problems that fit our favourite solutions.

I'm guilty of this too. About five years ago, I was obsessed with agile methodologies and spent months trying to convince a traditional manufacturing client that they needed to revolutionise their project management approach. What they actually needed was better communication between their planning and production teams - a problem that could've been solved with weekly catch-ups and a shared calendar.

The Reality Check: Implementation Actually Matters

This might sound obvious, but implementation is where most brilliant problem-solving processes fall apart.

You can have the most elegant solution in the world, but if it requires three people who hate each other to collaborate seamlessly, or if it depends on technology that breaks down every second Thursday, you're dreaming.

Real problem solving means designing solutions that work with human nature, not against it.

When I work with clients on creative problem solving approaches, we spend just as much time on "How do we make this stick?" as we do on "What should we do?"

Because honestly, most workplace problems aren't that complicated to solve in theory. The complexity is in the execution.

The Bit Nobody Likes to Talk About

Problem solving isn't just about logic and process - it's about politics, personalities, and the uncomfortable realities of organisational life.

Sometimes the "right" solution isn't politically feasible. Sometimes the person causing the problem is the boss's favourite. Sometimes the budget for the obvious fix got spent on something else entirely.

Effective problem solving means working within these constraints, not pretending they don't exist.

A few months back, I worked with a Adelaide-based service company where everyone knew their scheduling system was hopeless, but the general manager had personally chosen it and wasn't interested in admitting mistakes. The "perfect" solution would've been replacing the system. The practical solution was training staff to work around its limitations while gradually documenting the need for change.

Not sexy, but effective.

What I Wish I'd Known Fifteen Years Ago

If I could go back and tell my younger, more idealistic consulting self one thing, it would be this: the best problem-solving process is the one that actually gets used, not the one that looks most impressive in a presentation.

Simple beats sophisticated every time.

Complex frameworks and detailed methodologies have their place, but most workplace problems respond better to curiosity, common sense, and the courage to ask awkward questions.

The most powerful problem-solving tool I've encountered isn't a framework or a methodology - it's the willingness to be wrong about your initial assumptions.

Because here's the thing: if you're solving the wrong problem really efficiently, you're just creating bigger problems down the track.

And nobody has time for that.