Rehearsals of Concept

Have a big, cross-functional process you're trying to iron out? Feel like it's full of buffers? Try a Rehearsal of Concept. To get started you'll need to think about the people, the process, and the guidelines. 

The People: Coordinate a time for key participants to rehearse.* Key participants usually look like the following:

• Function reps for each role involved
• E.g. if looking at invoice-to-cash cycles you might include customer support, delivery, collections, and accounting
• Reps for the systems involved
• E.g. if using an ERP to coordinate work, someone should "speak" for the ERP
• A facilitator to keep the group within the guidelines and on track

The Process: To use the group's time effectively, be specific about what will be rehearsed. A rehearsal can't cover everything, and that's okay. 

• Describe specific conditions
• Create a specific example that represents a likely scenario. This may feel limiting, but that's not the point. Your goal is to create a shared sense of understanding among the participants. Coordination and communication problems likely cut across products and services. 
• Start with a written plan
• Similar to a script for a play that gets edited as the actors try it out on stage. For some great reading on building descriptive process languages, I recommend Bruce Silver. 

The Guidelines: I'll lay these out like ground rules, but recognize them for the guidelines that they are. 

• Each rep speaks for themselves
• Including systems reps
• This is the hardest and most important guideline to follow!
• When speaking, think:
• What is received
• What is done to it
• What completes the work
• Mind the gaps!
• Everyone should listen for logic gaps or assumptions as the "work" goes from rep to rep
• Accept change!
• The whole purpose of the rehearsal is to smoke out the little gremlins that always creep into big plans. Be prepared to change your plan based on the interactions you observe in the rehearsal. In the inimitable words of an 82nd Airborne Division NCO, as recorded by Gordon Livingston, "if the map don't agree with the ground, then the map is wrong."

In my experience, "practice" is seen as a nice-to-have that is the first thing cut when resources or time get tight. Consider, however, the last big change you worked through. Did you practice before hand? How did it go?

Remember, the purpose of a rehearsal is as much or more about developing a shared sense of understanding for the participants than it is about the mechanics of any particular process. That shared understanding can then become a foundation for future changes. Without a cross-team understanding, how sustainable is effective cross-team action? Run a rehearsal, reduce the buffers, and learn as you go. 

Say what you will about the military, I think ADRP 5-0 nicely sums up rehearsals, "Effective rehearsals imprint a mental picture of the sequence of the operation's key actions and improve mutual understanding and coordination."

* Can't find a time for all your key participants to rehearse? Consider what that might signal about the long-term prospects of your group's project.

Ask more open-ended questions

Think about the differences between these two questions:

• Do you know why this happened?
  
• Why do you think this happened?

"Do you know..." could be answered with just a yes or no, whereas "why do you think..." could not. These are broad questions, of course, and I find many times people answer them the same way, so consider more nuanced questions:

• Did the third step in our process cause this defect?
  
• What do you think are the likely causes of this defect?

Again, the first question just needs a word, but the second question needs more. Assuming you don't know what caused the defect (hence the questions), will the first question get you what you need to know? Maybe. Who's asking? What's the team atmosphere like? How does management tolerate uncertainty? How safe do people feel when proposing new ideas or admitting they don't know something?

Karen Martin offers a handy guide with examples of the differences between close-ended and open-ended questions. Just becoming aware of the difference is a good place to start. Some methods I've developed or picked up to build this capability in myself and others are:

• Practice deliberately. Enlist a colleague and ask them questions about a project they're working on using only open-ended questions. Switch roles and repeat.
• Ask about what you don't know. Might seem simple enough, but think about the "atmosphere" questions above. Asking people what they thought, what they did, how they reacted, or how they felt are all examples of asking about what you don't know. 
• Know your time, setting, and audience. Avoid putting peers or subordinates on the spot in big group settings if you want to deeply understand something. Be proactive about finding another time and come back to the group with material changes. 
• Use some structure. Open-ended questions don't have to be vague. Consider these questions and think about how you can blend what you know with what you don't know:
• What happened?
• It looks to me like we completed this task successfully eight times today and failed on the ninth. What was different about the ninth time?
• Recognize when close-ended is okay! Sometimes you need to learn and sometimes you need to test hypotheses. Close-ended questions can be great for testing hypotheses, but if in doubt, I would recommend open-ended questions (because of the doubt!). 

Listen carefully in meetings, find a partner for practice and get started, or pause yourself before you send your next email and look at the questions you ask. Think about the types of responses the questions set up and whether that helps or hinders the cause.

Questions that are poorly worded, heavily structured, fraught with bias, or designed to trap people will increase the buffers around you and make it harder for you to see and understand what is truly happening. 

Stars & Guardians

One way to think about the perspectives individuals and teams have on their world is to place them on a spectrum from Stars to Guardians. I first encountered this in a class with Jim Baron. What I'll present below may not follow exactly what his book lays out (I leave out foot soldiers, for instance), but this is how I've come to apply this framework in my experiences. 

Think about the random events we encounter every day. How do they fall in relation to where you are on a spectrum from worse to better. Do your random events generally make things better than status quo? Or are random events for you generally worse than status quo?

Stars generally benefit from random events, whereas Guardians typically dread random events. Classic Star positions might include entrepreneurs who get traction with a product, marketers creating content that goes viral, or consultants that deliver a big project that delights an executive audience. 

Contrast that with some classic Guardian positions that could include a company IT team that has unexpected network downtime, an electric utility that experiences a transmission failure, or an auditor that misses a key bit of data. 

In my experience, Stars frequently have great ideas about how to make things better, while Guardians are often charged with protecting or managing critical resources of all types (e.g. time, energy, materials, labor). Neither position is wrong, but not recognizing the different perspectives can make it difficult for two sides to communicate. How can one reduce that buffer?

Stars: Seek to truly understand what it is the Guardian you're working with is protecting. Understand what some random events are that they've encountered recently and how they reacted to them. Learn their language and talk to them in their terms, developing ideas and approaches that have a grounding in what matters to them. Help them understand all facets of the random events they face, and perhaps they can shift down to the spectrum a little bit. 

Guardians: Don't hide your concerns under a blanket of "everything's fine." Understand that a Star may have different perspectives on the challenges you face that could be beneficial. Don't become lax in your responsibilities, but maintain mental flexibility and recognize that there is almost always more than one way to do something. 

Starting a new team with an expanding mandate? You may find yourselves shifting from Stars to Guardians over time. Facing a decline in relevance of the resources you're guarding? Think about examining the random events you're facing and look for upside you may not have seen before. 

There is no right answer, there is only right effort. 

What buffer?

In 1988, John Krafcik wrote an article in the Sloan Management Review. In his article he introduced two new terms: lean and buffered production systems.* Since then, Lean has come to mean a lot of things to a lot of people, including me. Rather than focus on being lean, however, my intent is to help people reduce the buffer. So what is the buffer?

Any situation that involves two or more people interacting with each other will have buffers; they're inevitable. The thoughts and ideas we have in our head simply cannot be fully communicated (fully!) to someone else.

But while buffers can never be eliminated, they can always be reduced, and that's where the work comes in. One must be able to see a buffer before attempting to reduce a buffer and there will always be more than one way to see a buffer.

There is no right answer, there is only right effort.

My hope is that by experiencing different frameworks and perspectives in a given situation, we can all pick up different ways to see the buffers around us. If we can see them, we can try to reduce them. And in doing so, we can see the world around us a little bit more clearly. 

Wherever possible I will try to include source material. I welcome comments and questions. 

---

*Krafcik observes in a footnote that this typology builds on previous work done by other researchers who used fragile and robust. It's little wonder that lean caught on better than fragile in English.