The Monkey Cage Sessions

monkey throwingI’ve seen a lot of strategies and “solutions” fail over the years primarily because the solution was crafted before the problem addressed was thoroughly understood.

Many times, the strategy or solution was the result of a brainstorming session filled with type A personalities (me included) ready to make things happen.

You may be familiar with the type of session I’m referencing. Usually, there’s a guru consultant leading the charge. He separates the group into teams and gives them Post-It notes and colored sticker dots. “Write down as many ideas as you can in the next 20 minutes. Don’t think too much. Be creative! No idea is dumb. Stick your ideas on the wall. Now go!” After 20 minutes, a leader from each group presents their best ideas to the rest of the room. Then each person in the room is allowed to vote for maybe six of his or her favorite ideas using the colored sticker dots. A few people are assigned the winning ideas and off we go.

Those types of session frustrate me. I’m concerned there’s too much action, too many unspoken assumptions, and not nearly enough serious thinking.

Over the years, I’ve developed a problem solving technique that I’ve found to work a lot better. I call it the Monkey Cage Sessions. The technique is all about thoroughly identifying the problems from all angles before developing carefully considered, thoughtful and collaborative solutions.

It’s got an intentionally silly name because the process should be fun.

Here’s how it works:

Step 1 Define the problems.

We start by gathering a group of cross-functional people – ideally from different levels of the organization – together in a room to talk about the problem or problems we’re trying to solve. This could be as simple as enhancing a Careers page on the corporate website or as complicated as building a complete company strategic plan. It’s important to define the general scope of the problem, but it should be defined fairly loosely so as not to stifle the discussion.

The rules of the meeting are fairly simple. We only discuss problems. No solutions. This is a license to bitch. Let it be cathartic.

I usually stand at the whiteboard, marker in hand, and write down everything everyone says. There is no need to be overly structured here, and anything anyone says is legitimate. We throw it all at the wall and we’ll sort it out later.

Sometimes people want to debate whether or not something another person says is really a problem. If someone said it, it’s at least a perceived problem. It’s legitimate. Also, there is often an attempt to offer an explanation for why a problem exists. The explanation is covering for another problem, so that problem should be written down.

People are always tempted to offer solutions, even when they think they’re offering problems. For example, someone might say it’s a problem that we don’t have a content management system. Actually, a content management system might be the solution to a problem. What problem might a content management system solve? Beware of any problem statement that starts with “We need…” and be prepared to break down that need into the problems needing the solution.

Sometimes the problems offered up are very broad and vague. In those cases, it’s important to work with the group to dissect that broad problem into its component parts.

This first session generally uncovers a LOT of problems, but the problem is still usually not completely identified yet. Which leads to…

Step 2 Categorize the problems

While the chaotic approach of the first session works well to get an initial set of problem descriptions, it’s important to create some order in order to prepare for the problem solving stage. So Step 2 involves writing down all of the problems and sorting them into logical categories. I don’t have any pre-determined set of categories. Instead, I prefer to the let the problems listed dictate the categorization.

Step 3 – Widen the circle

We probably have a pretty good description of the problems now, but we’ve also still likely missed some. For Step 3 we send the typed and categorized list of problems to the original group as well as a widened circle of people. The original group will likely have thought of a couple more issues since the day of the meeting, and the new group of people will almost definitely add new problems to the list. Since this is the final stage of problem description, we want to give this step at least a few days to allow the team to think this through as completely as possible.

Step 4 – Develop the solutions

Finally, we can start solving the problems. Woo hoo!

Now it’s time to gather a subset of the original meeting to start working towards solutions. There should be at least a few days between Step 3 and Step 4. We want to give people some time to think over the full problem set. The group should enter the Step 4 meeting with at least some basic solution ideas. There is no need to come into the room with comprehensive solutions that solve every problem on the list, but the solutions considered should certainly attempt to solve as many problems as possible (without causing too many new problems).

I usually find that by this point many of the solutions are fairly obvious. But there should be good discussion about the relative merits of each suggested solution, and the solutions should be measured up against the problem list to determine how comprehensive they are.

I like to end the meeting by assigning people to lead each of the proposed solutions. Obviously, any suggested solution from this session will need to be fleshed out in a lot more detail, and the leader from this meeting is responsible for determining the viability and solution and then potentially leading the development and ultimate execution to completion.

Subsequent progress is then handled via a separate execution process.

———————————-

I’ve had very good luck over the years using this technique. Some of the primary benefits I’ve found are:

  1. Better understanding of the problems
    As the initial meeting wraps up, most people are inevitably feeling enlightened about the problem. They’ve outwardly expressed their own assumptions (which sometimes even they didn’t know they were making) and they’ve understood the perspectives and assumptions of others. They’ve seen the problem in an entirely new light.
  2. More comprehensive solutions
    The heightened understanding of the problem and the critically important time between steps to allow the team to be more thoughtful in their ideas. Those ideas are usually pretty all-encompassing solutions to start with, but the discussions in Step 4 lead the team to collectively choose the best of the best of the solutions offered.
  3. Better execution
    Solutions are nothing but fancy ideas until they’re executed. And poor execution can cause even the best ideas to fail. The process of fully defining the problems and sharing that work with wide circles of people is an incredibly important stage that sets the foundation for success in execution. When the execution team provides input in the process and understands the basis for the solution, they are far more supportive in the effort. They are also far more prepared to make the daily, detailed decisions that are often the difference between success and failure.

So, that’s the Monkey Cage Sessions. I hope you find it helpful. If you try implementing the process in your business, I’d love to hear how it goes.

What do you think? Would this process work in your organization? Have you ever used a similar process?


8 Comments

  • By Mike Tausig, July 7, 2010 @ 1:21 pm

    Good post. Very similar, in a theoretical way, to the 6Sig DMAIC (or DMADV) process. Before a solution can be implemented, a “why” (read, reason) must be Defined, Measured, Analyzed, Improved, and Controlled. Too often, the reason for failure is not that the remedial process was implemented incorrectly, but rather, the reason for the process was not correct. Specifically, that the reason was not fully understood – every moment that passes allows the reason to evolve and grow, linking more and more to it, until it is no longer the original process we began studying. The greatest challenge is not the problem, but rather optimizing (therefore, maximizing) the time between problem and solution. In a vacuum, we would have a big book of solutions that serve as precursors to problems, hence providing us with what I like to the Mobius Strip of Change. If we can control our emotions (and egos) long enough to understand our reasons for needing change, we find our arrival at solutions much more natural, and thus, our solutions much more organic. Or, my philosophies are just jibberish, in which case, carry on.

  • By Mike Tausig, July 7, 2010 @ 1:24 pm

    That would be “what I like to CALL the Mobius Strip of Change”. I should have studied my comment a bit more before posting. Touche to me.

  • By Kevin Ertell, July 9, 2010 @ 3:38 pm

    Thanks for your comment, Mike. I think you draw a very interesting parallel with Six Sigma. I definitely need to do more research about Six Sigma is general and DMAIC in particular. I love your point about controlling our emotions and egos long enough to understand our reasons for needing change. That’s great stuff! Thanks again.

  • By Francis Norton, November 10, 2010 @ 8:13 am

    What I like about this is:
    [1] it resists premature solutions
    [2] it has many of the benefits of the “5 Whys” technique (http://en.wikipedia.org/wiki/5_Whys) which I personally think is such an effective critical thinking technique that it should be taught at primary school
    [3] it also resolves some of the listed limitations of the “5 Whys” technique such as “Inability to go beyond the investigator’s current knowledge”

    Nice work, nice post. Thanks.

  • By Kevin Ertell, November 10, 2010 @ 9:45 am

    Thanks for your comment, Francis. I appreciate your three point breakdown, and thanks also for linking to the 5 Whys page. I hadn’t thought of this technique in that context before, but I can see why you did. I also wholeheartedly agree that more critical thinking should be taught in primary school.

  • By John Robideaux, April 6, 2012 @ 11:49 am

    Kevin: I like thinking about the energy I could add to my client planning sessions if I incorporated a review based on your Monkey Cage Sessions. I could see going over the list of prioritized Opportunities and “fleshing out” problems that would interfere with the execution of each one listed.

    Normally, I work with top management, but you seem to include a cross section of people from the company or organization. How do you convince your clients to allow that type of meeting and what does it take to get people to talk so freely when it may cost them their job if they shared too many problems?

    I like the approach you take, it does seem to take longer than I’m used to allowing for meeting time, but I’m willing to stretch time if the client is willing to pay. Any chance you could share how much you charge for your time?

    Thanks for the post.

  • By Kevin Ertell, April 6, 2012 @ 12:39 pm

    Thanks for your questions, John.

    Let me start by saying I’m not a consultant. I’ve developed and used this process within the companies I’ve worked at. So, my perspective and situations might be a little different than yours.

    I find it’s critical to get people from different levels of the organizations in these meetings — at least at the problem definition stage. If it’s just one level of the organization — be that top management or entry level — the problems will not be very thoroughly defined because there will not be enough different perspectives. I also find it’s EXTREMELY educational for all involved to hear the perspectives of others.

    I think one key to getting people to be comfortable speaking freely is to start the meeting out saying all perceived problems are valid. While one person might not perceive something as a problem, another person clearly does and perceived problems are problems to be solved. It could just be more knowledge is the solution, but so be it. This process should be educational and cathartic for all involved. And it should even be fun. I gave it a goofy name specifically because I wanted it to be seen as something fun and not something so serious someone would get fired for stating his or her perceptions.

    Finally, in regards to the time spent, I personally feel time invested in getting teams to work better to define problems and then solve them is time well spent. If it takes a little longer to get to a much higher and well supported solutions, isn’t that well worth it?

    I hope that helps. Please let me know if I can provide any more clarity.

    And thanks a lot for reading!

Other Links to this Post

  1. The power of a little naiveté | Retail: Shaken Not Stirred by Kevin Ertell — November 9, 2010 @ 11:23 am

RSS feed for comments on this post. TrackBack URI

Leave a comment

Retail: Shaken Not Stirred by Kevin Ertell


Home | About