How Fast Is TooFast for Wicked Problems and Quick Fixes?’

The “This Should’ve Worked” Story.

The project had all the usual signs that it would work: a committed team, a real sense of urgency from a partner, a clean process, and a prototype that looked great in the demo. The meetings were productive. The decisions were made quickly. The deliverables were spot on. There was even that familiar rush, finally, something's moving.

After that, it was a bit quieter..........

The solution was meant to be used in places like classrooms, clinics, internal workflows, and communities, but it ended up being used only sometimes. There was no dramatic rejection. No one's been left fuming. It's just a matter of lukewarm adoption. Just the odd time. It felt a bit weird to me that the project felt more like it was on slides than in everyday life.

Why Wicked Problems Make Us Rush (Even in Great Teams)

I've come to think that a lot of failures don't actually start when it's time to put things into action. They start earlier – in the urge to solve too soon.

Solving can be a defensive move.

It's not that action is bad, but some problems can feel threatening. They make things uncertain, ambiguous, and a bit unmanageable. When we don't really get what's going on, taking action can help ease the pain of not knowing, make us feel like we're in control again, and give us a sense of progress.

When it comes to innovation, like in start-ups, education, and organisational change, this becomes almost cultural. Speed gets a lot of praise. Motion gets rewarded. Pauses are seen as a sign of weakness. And sometimes what we call "momentum" is just a fancy way of avoiding dealing with what we can't yet name.

The tricky thing is, this pattern shows up in good teams too. People who think things through. Projects with real intent. It's not an ethics problem. It's just human nature: doing something feels safer than staying in the unknown.

3 Signs You’re Solving Too Soon (P.D Don’t Panic, It’s Common):

With wicked problems, premature speed often looks like productivity—until reality quietly refuses to adopt it.

I don't see this as an individual flaw. It's a pretty standard pattern. There are three symptoms that keep coming back, and they've been seen in different outfits:

The problem is defined by what's easy to measure.

It's easier to measure something complex because it feels tangible. What we're talking about here is the concept of "wait time". What's confusing is that it's called the "drop-off rate." What doesn't fit becomes "resistance to change." It's not about measurement. The problem arises when we measure to avoid looking, as the indicator replaces the thing we're measuring.

The user is reduced to "needs" without inner contradictions.

We talk about needs like they're clean, stable, and consistent. Real life rarely is. You can want support but still be afraid of feeling like you're not good enough. They might want to feel like they belong, but they don't want to put all their cards on the table. They can ask for more clarity while keeping things vague, because they feel comfortable with ambiguity. When the user becomes too "neat", it's often a sign that we simplified them so we could move forward.

The system is basically reduced to 'stakeholders', without any dynamics or side effects.

We list actors, assign roles, and build maps that look correct. But systems aren't driven by lists. They're driven by all sorts of things - things you can't see, costs you don't know about, reputation, fear, who's in charge, the hierarchy, and history. A solution can "fit" the org chart and still threaten something deeper, like how power is distributed, who gets exposed, who loses room to manoeuvre, and who absorbs risk. If we don't pay attention to those dynamics, the system won't make a big fuss. It just creates friction.

What This Looks Like in Real Life (Quietly)

The problem with premature solutions is that they don't always look like failure. They often look like productivity. The team ships, reports, and presents. Everything seems to be moving.

But to be honest, it's pretty clear where things are going:

• Not many people are using it, even though it's technically possible. It's not something that's used regularly.

• Quiet rejection: no open conflict, just people growing apart.

• Ups and downs: one part gets better while another gets worse (trust, freedom, coordination, motivation).

• Narrative drift: it becomes "people don't want change" when what's missing is a deeper reading of what the change actually threatens.

• Innovation theatre: there are loads of artefacts and language, but the underlying problem stays the same – it's just been given a better package.

I don't mean this cynically. I'm just saying it because it's common. And because it's so common, it's hard to interrupt.

Holding the Problem (Without Freezing)

I learned something the hard way:

Moving fast is a skill that's really valued, but it's not for everyone.

Before we can suggest any solutions, we need to understand the problem.

Holding isn't romanticising paralysis. It's not an excuse to avoid action; it's just a way of thinking. It's about being able to stick around in places where things aren't set in stone yet, places where there are layers we don't totally get, where language is a bit vague, and where causes aren't straightforward.

When you're honest about a problem, you might find things that you didn't know about, and that can help you solve the problem faster

• People who don't fit into simple sentences.

• systemic tensions that can't be 'fixed' without losing something important.

• Costs you don't see that change the whole equation,

• Qs that feel risky because they force a shift in responsibility, power, or story.

Sometimes the smartest thing a team can do isn't to speed things up, but to admit that they haven't read this thoroughly enough yet.

This isn't a critique of action. It's a critique of action without reading.

That is what matters. You can think about it like a kind of thinking tool. Implementing it can be a way of showing respect for people's time. What I'm challenging is the use of action as a substitute for understanding.

Here are some signs you're in solution mode:

1. You feel instant relief when the team "decides something", even if the understanding underneath is a bit thin.

2. You start to get a bit irritated by the ambiguity and push for definitions to calm the discomfort, not to see more clearly.

3. Sometimes, questions that are more in-depth are marked "out of scope" too quickly.

4. Things get complicated and it's hard to tell what's important and what isn't.

5. The thing is, output is becoming more important than the everyday reality in which it's supposed to be used.

That's all for today, folks.

I've worked with Design Thinking and with Systems Thinking. I really value them. I've also seen how, when it comes to real life, the things we reward like speed, shipping, and clarity can sometimes be a dangerous shortcut when they arrive before reading.

There's a subtle difference between moving with purpose and moving just to avoid feeling lost.

"Speed can be efficiency, or it can be avoidance."

If this idea makes you uncomfortable, the next piece looks at one of the most common mistakes in innovation ........... Thanks for your time Paola Hintze