14. Disney Problem-Solving Method for Engineering Teams

As engineering leaders, we constantly face complex problems: scaling systems, reorganising teams, balancing delivery with quality, navigating company changes, fighting technical debt. Some of these are not just “tickets” to solve - they are multidimensional problems that require creativity, strategy and realism at the same time.

One of my favourite tools for this kind of challenge is the Disney problem‑solving method (sometimes called the Walt Disney Strategy).
I especially like to use it with whole teams - not alone at my desk - and to make it a bit more experiential: changing music, changing lights in the room, and literally changing where people sit depending on the role they are in.

In this post I’ll explain:

• What the Disney method is.
• How the three roles - Dreamer, Realist, Critic - help engineering teams.
• How I run these sessions in practice.
• When to use it - and when not to.

What is the Disney problem‑solving method?

The core idea is simple:

Instead of trying to be creative, realistic, and critical at the same time, you separate these modes into three distinct phases:

1. Dreamer - generate bold ideas, without limits.
2. Realist - turn ideas into concrete plans and steps.
3. Critic - stress‑test the plan, find risks and gaps.

Walt Disney was known for switching between these modes deliberately. Modern facilitation turned this into a structured technique teams can use.

For engineering leaders, this is powerful because our default habits often push us too quickly into Realist or Critic mode. Someone shares an idea and we immediately think:

• “We don’t have capacity.”
• “This won’t scale.”
• “Security will never approve this.”

We kill creativity before it has a chance. The Disney method gives permission to be in one mode at a time - and that changes the quality of thinking.

Phase 1: Dreamer - go wide without limits

What it is

In the Dreamer phase, the team’s job is to imagine what could be possible if there were no constraints:

• No budget limits.
• No legacy systems.
• No team size problems.
• No approvals.

This sounds naive, but it has a purpose: it breaks us out of the default “we can’t” mindset and surfaces ideas that would otherwise stay unspoken.

How I run the Dreamer with teams

When I use this with a team, I like to make the environment different from normal work:

• I change the lights - warmer, softer, or coloured light if possible.
• I play background music that is calm or slightly inspiring (no lyrics if possible).
• I ask people to change seats in the room - so it doesn’t feel like another standup.

Then I set a clear rule:

“For the next 20-30 minutes, we are in Dreamer mode.
We are not allowed to say ‘this won’t work’ or ‘we don’t have time’.
Our only job is to imagine: what would amazing look like?”

We capture ideas on sticky notes, a Miro board, or a shared doc. Quantity over quality. People can build on each other’s ideas with “Yes, and…”.

I treat this like a psychological safety exercise too (related to 10. Building Trust in Engineering Leadership):
no judgement, no eye‑rolling, no laughing at “crazy” things.

Phase 2: Realist - turn dreams into a concrete plan

What it is

Once we have a wall full of ideas, we switch mode:

Now we ask: “If we wanted to do this, what would it actually look like?”

The Realist is not a killer of ideas - they are a planner:

• Which ideas are worth combining?
• What is the first version we could realistically deliver?
• What resources would we need?
• What are the steps over the next 3-6 months?

How I make the switch visible

Here I also like to change the environment:

• Lights become brighter, more like normal working mode.
• Music changes to something more neutral or slightly energetic.
• We might move to a different part of the room or a different board.

I announce the switch clearly:

“Now we are in Realist mode.
Assume we want to make some of these ideas real.
What would be a practical, concrete plan?”

We cluster ideas, vote on what to focus on, and start drafting:

• A rough roadmap.
• Ownership and responsibilities.
• First experiments we could run.

This is where tools like delegation (see: Effective Delegation Framework) or prioritisation (The Truth About Prioritization in Engineering Leadership) come into play.

The important thing: we still don’t criticise here. We might say “this would require three teams” or “this needs a new data pipeline”, but not “this is stupid”.

Phase 3: Critic - stress‑test with care

What it is

Only after we have a concrete plan do we move into Critic mode.

The Critic’s job is not to destroy the plan, but to protect us from naive failure:

• What are the biggest risks?
• What could go wrong in production, with customers, or with security?
• Where are we over‑optimistic about time or capacity?
• What are we not seeing?

This connects well with my view on truth with care from The Biggest Challenges as an Engineering Leader: say the hard things, but with respect.

How I set the tone

In this phase, I might again change the environment slightly:

• Lights more neutral or slightly cooler.
• No music, or very minimal.
• Rules on the board: “Critique the plan, not the people.”

I remind the team:

“Now we are in Critic mode.
Our job is to find risks and blind spots -
so we can improve the plan, not to shame the Dreamer or Realist.”

We often use simple structures:

• Red / yellow / green dots on parts of the plan.
• “What could go wrong?” followed by “What would we do then?”
• Pre‑mortem: “Imagine this failed in 6 months. Why?”

At the end of this phase, we capture:

• The key risks.
• Mitigations we want to build in.
• Things we will explicitly accept as risks.

Why it works so well with whole teams

I like using the Disney method especially:

• For cross‑team problems (e.g. reorganising ownership, redesigning an on‑call model).
• For product‑plus‑process questions (not just feature design, but how we work).
• When the team is stuck in a loop of “this won’t work” and needs a new angle.

Using it with the team (not just in my own head) has several benefits:

• Shared understanding - everyone sees how ideas emerge and evolve.
• Inclusion - different personalities can shine in different phases (some are better Dreamers, some better Critics).
• Trust building - people experience that it’s safe to think big and also safe to question.

And yes - the music and lights matter more than you think. They are small signals:
“We are in a different mode now. It’s okay to think differently.”

This connects with the broader theme from Mental Models for Engineering Leadership: being explicit about which “hat” you and the team are wearing at a given moment.

When not to use the Disney method

It’s a powerful tool, but not for every situation:

• Production incident at 2am - you don’t need a Dreamer then; you need clear roles and a Regulator mindset.
• Tiny decision - don’t run a 90‑minute workshop to rename a field.
• Already decided topics - using the method as a fake consultation when the decision is fixed will only damage trust.

Use it when:

• The problem is ambiguous, multi‑dimensional, and worth team energy.
• You have at least 60-90 minutes and a reasonably stable group.
• You are genuinely open to the outcome.

Final thoughts

The Disney problem‑solving method is not magic. It doesn’t guarantee perfect answers.
But it does something very valuable for engineering teams: it separates creativity, planning, and critique into clear phases, and gives people permission to fully inhabit each mode.

By changing music, lights, and space, you make those shifts visible and felt. The team experiences something different from another “normal meeting” - and that alone already opens new thinking.

Next time you face a big, messy problem with your team, try it:

• Start as Dreamers with warm light and inspiring music.
• Move to Realists with a clear plan and ownership.
• Finish as Critics who protect the plan from naive failure.

Then, of course, go back to execution - and see what happens.