Posts tagged: execution

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?

“Obscure and pregnant with conflicting meanings”

We’ve all heard the cliché “hindsight is 20/20” a thousand times. And it’s pretty much true. It’s a lot easier to figure out the path to a particular event when you know the final outcome. But if “what happened” is something bad, determining the reason after the fact doesn’t change the negative event.

How can we do a better job finding those problems in advance of our next new strategy implementation, site redesign, store remodel or other big effort?

It’s worth digging a little deeper to better understand why our hindsight is so perceptive. One of the most famous cases of 20/20 hindsight comes from the investigation into the attacks on Pearl Harbor (although, we could also argue the investigation into 9/11 and the more recent Fort Hood shootings have many similarities). In her book Pearl Harbor: Warning and Decision, noted military intelligence historian Roberta Wohlstetter wrote “it is much easier after the event to sort the relevant from the irrelevant signals. After the event, of course, a signal is always crystal clear; we can now see what disaster it was signaling since the disaster has occurred. But before the event it is obscure and pregnant with conflicting meanings.”

Of course, Pearl Harbor was an unexpected disaster that seemingly came out of nowhere. While we have those occasionally in business, more often than not our “disasters” come from strategies, redesigns or promotions that did not perform as expected. And those expectations can also lead to our blindness.

Whenever we’re implementing some new and exciting strategy, we tend to be very optimistic about the results. We’re convinced these new strategies are going to provide positive returns or we wouldn’t be implementing them. That optimism can lead to the same sort of crystal clear signal Wohlstetter referenced, but in the opposite direction; i.e. we tend to only see how everything we’re doing will lead to greatness and can easily overlook variables that have potential to lead to negative outcomes.

So, what do we do about it?

It seems some of the most common solutions today involve pulling together a committee to review what went wrong and putting together processes to prevent those specific problems in the future. These new processes don’t prevent all potential problems in the future, but with any luck they’ll prevent us from repeating the same mistakes.

But all of that happens after the fact.

There’s got to be a better way. My problem with the “committee and new process” approach is there’s a tendency to introduce lots of new and –all too often — needless bureaucracy. Inefficiencies ensue without greatly decreasing the probability of problem-free future efforts.

A technique I’ve found effective invokes much of the clarity of hindsight by drawing on the power of imagination.

During the ROI process for the strategy or project, we’ve already imagined the positive outcome. So before we wrap up planning, let’s also imagine a couple horrific scenarios. For example, imagine that four or five months after a site redesign, sales are down 50% and customer satisfaction has tanked. What happened? Now let’s assemble the same type of committee we would in that scenario and pour over the plan to find the causes of our imagined disaster.

Some might say this technique is really just standard contingency planning, but I find some pretty big differences. Contingency planning tends to look at the current plan to identify execution risks. It doesn’t often uncover key strategic or design problems.

The Scenario Imagination technique provides us with a different sort of lens that taps into our hindsight abilities to separate the signal from the noise.

We certainly won’t find every potential problem, but every problem we mitigate increases our probability of success and reduces our risk. And if we can reduce a lot of risk without strangling ourselves in bureaucracy, we’ll likely lower costs, increase efficiencies, and increase profits. I like the sound of that.

What do you think? Have you run into these types of issues? Do you think this technique would work for you? Do you have any techniques you would like to share?

Photo credit: me’nthedogs

Retail: Shaken Not Stirred by Kevin Ertell

Home | About