Software Engineers try Walt Disney’s method to create ideas for animated films.

Photo by Marvin Meyer on Unsplash

A creative rut tends to strike when you least need it. And the worst place and time for a Software Engineer to have one is during a brainstorm session. Especially if it is part of work, in other words, you won’t get paid if you don’t get out of the rut. At Digible, Inc., Software Engineers use The Disney Method for successful brainstorming.

What is the Disney Method?

First presented by Robert Dilts, the Disney Method was used by Walt Disney to determine what ideas to produce as animated films or movies. In the method, brainstormers look at the idea from three perspectives or roles in order: first, the dreamer, then the realist and finally, the critic (sometimes referred to as the spoiler). In theory, and in practice, it is important that these stay separate and not mix with each other. Walt Disney went as far as having separate rooms for each step.

Let’s look at each stage. In The Dreamer stage, participants generate ideas with complete freedom. This is a step to fantasize. There are no filters. It doesn’t matter how absurd or unrealistic the idea may seem, it cannot be filtered at this stage by anything.

For the second stage, The Realist, participants worry about how to execute the dreams. This is still not the point to discard ideas, only to create plans or thoughts about how they could be achieved.

Finally, in The Critic stage, it is time to find all the possible holes in the ideas and plans. Participants play the devil’s advocate and see if the idea is bullet proof. Ideas that are shot down are not discarded completely, they are shelved and sent back to the dreamer stage to think of solutions for the issues detected. If the idea survived this stage, however, then it was produced.

How does Digible use it?

The Engineering department at Digible holds occasional hackathons. There are no fancy prizes or 36-hours of straight coding, but they are a time to break the rules and focus on feature development. This is pure gold for a developer, just ask any of them. The hackathon has one rule, though: it must produce a shippable product at the end.

Nothing makes better use of the hackathon time than a good brainstorming session. We could not afford to have a creative rut consume our hard-earned feature development time (the kind of work that we love ❤️💻). We decided to study Disney’s Imagineers and apply The Disney Method since the first brainstorming session. With a twist.

The Digible Brainstorming Steps

Step 0 - Prepare

Each time the Engineering team will hold a hackathon, one member is selected to coordinate all activities. This person prepares the brainstorming session: time, place and materials.

The time is set by a calendar invite for a two-hour session. This session is divided into time slots. A five-minute segue; a 10-minute inspiriational speech from our Engineering Director telling us the problem we want to solve and 1 hour and 45 minutes for brainstorming activities (the next steps).

Because we are in the midst of a global pandemic, place defaults to a Zoom meeting room and materials are virtual tools like Jamboard and Notion.

Step 1 - Introduction

At the time of the brainstorming session, after a brief segue, the coordinator selects one member of the team to share their screen, drive and present a blank Google Jamboard. The coordinator shares the link to the Jamboard with the team and creates a Notion page for the hackathon. The link to the board and other important information live on this document. The Engineering Director then gives us words of encouragement and unveils the problem to solve in the hackathon [1]. The person controlling the jamboard places a sticky note, with the problem to solve, in the middle of the white board.

Step 2 - We are all dreamers

With the problem to solve in our minds, we kick off the branstorming session! The first step is to dream and generate ideas. Each engineer selects a color of sticky notes in Jamboard [2]. The coordinator sets a timer for 15 minutes. During these 15 minutes, each engineer jots down ideas on how to solve the problem. We follow a set of rules [3], loosely based on the Rules of Brainstorming poster from IDEO:

• Focus on quantity 👉 Write as many ideas as you can
• Write one idea per sticky
• Don’t stop to think if your idea can be done, just write it
• Don’t focus on quality, but don’t throw it out the window. Your ideas can be crazy, so long as they solve the problem.
• Write clear ideas, with the least amount of words as possible. You want your stickies to be readable from afar or without needing to zoom into them.

Engineers continue to write ideas until the time is up. Originally we planned this first step to be between 5 to 7 minutes, but we always found ourselves needing more time, so we pushed the max limit to 15.

Step 3 - Organize the chaos

This is the twist we gave to the Disney Method. In this step, we classify the ideas into groups. Participants pool all the sticky notes to one corner of the board. Then, each participant takes turns pulling a sticky and place the idea in a “bucket” or group by asking a simple question:

Does this sticky note fit into an existing group or do we create a new one?

Of course, the first sticky note that we review will always create a new group. Groups can be whatever we need. Usually you find group names like “front-end”, “back-end”, “customer-facing”, “process”, “tool”, “task” and many more. It all depends on the theme of the hackathon or the problem we are trying to solve. At the end of this step, we have the the entire board divided in buckets and stickies in each one.

Digible, Inc. Archive

Step 4 - We are all realists

Back to the Disney Method. In this step, participants try to come up with plans to execute on the ideas. They focus on the “how”. At Digible, we ask ourselves if the idea can be executed with our current resources (time, skills, tools, etc). We go over each sticky note and decide if the idea can be executed. To keep track of this, we divide each bucket or group vertically. The ideas that are realistic go to the left, the ideas that are not, are moved to the right within each group.

Digible, Inc. Archive

Step 5 - We are all critics

This step is a relief for many because they can finally let go all those “devil’s advocate” thoughts that have stirred up in our interior. We go over each idea and try to punch holes in it or in the plan to implement it. These holes could be questions like:

• Does it help us solve the problem? Or does it make things worse?
• Is it something we must do to solve the problem? Or is this nice to have?
• Does it increase the scope of the hackathon? By how much?
• Can we do it with our current constraints? [4]

The ideas that fall victim to our questions are discarded. The ones that survive are converted into action items for the project. Usually, we create a Notion table inside the hackathon document to keep track of these.

Digible, Inc. Archive

Post-brainstorming

After the session, we are ready to begin our work. It is important to note what happens to all the work we did for the brainstorming session, including our discarded ideas. After each step of the brainstorm, we create a copy of the board and save it as another sheet in Google Jamboard. This lets us keep a history of each step in case we need to revisit past ideas. The link to the idea board is part of the hackathon documentation in Notion. And all hackathon documents live in our Notion Wiki. This creates historic material for current and future engineers.

Digible, Inc. Archive

Conclusion

Software Engineering may seem like it has nothing in common with making animated films. But it does: it requires enormous amounts of creativity. Sometimes this can be in short supply and we need something to jog the ol’ noggin. This method of brainstorming helps keep those creative juices flowing and create ideas. These ideas started Digible, made it grow and will continue to power it for a long time. We only scratched the surface on brainstorming and we found what worked for us. We hope this inspires and helps you just as it helped us.

Photo by Nathan Dumlao on Unsplash

Footnotes

• [1] Engineers are told of the “theme” for the hackathon or a set of likely problems that they will solve, but the final problem to solve is kept as a surprise.
• [2] We are a small team and can comfortably select a color without worrying someone else picked the same color.
• [3] To quote Hector Barbossa, they are “more like guidelines than actual rules”
• [4] Most importantly, time. Hackathons are usually 3 days long. Preferrably, the team validates and deploys the solution on the third day.

Reference

Dilts, Robert. (1996). Walt Disney Strategies of Genius. http://www.nlpu.com/Articles/article7.htm

Idea Sandbox. (n.d.). Disney Brainstorming Method: Dreamer, Realist, and Spoiler. https://idea-sandbox.com/blog/disney-brainstorming-method-dreamer-realist-and-spoiler/

IDEOU. (n.d.). Brainstorming. https://www.ideou.com/pages/brainstorming

Kamran, Cheyenne. (2017). The Dreamer. The Realist. The Critic. https://medium.com/@oneandonlyche/the-dreamer-the-idealist-the-realist-62400d56741b

Volkhover, Anatoly. (2019). The Disney Method. https://medium.com/become-an-awesome-software-architect/the-disney-method-d346f009e35e