Task Sets for the Emergent Approach

Introduction to the Task Sets

The five task sets are a guidebook for framework design and implementation that embodies the theory and practice established in The Emergent Approach. Each set consists of one-to-eight tasks, each of which is an objective. The label “tasks,” instead of “steps,” highlights that the design principles—not the order of completion—are the guiding discipline.

The tools and design principles for completing the tasks are in the book. The relevant chapters and figures are referenced throughout. Each task is followed by a simple illustration from the continuing evolution of your bike shop venture, headed with the B i k e S h o p icon. (As a reminder, the bike shop is only a simple made-up illustration, not a study of the biking industry.)

Some tasks may take minutes, some may take days, and some of them may be longer. The amount of time depends on the scope and ambition of your endeavor, the team’s skills and discipline, and any deadlines. The tasks are grouped in the draft it—evolve it—finalize it format introduced in Chapter 11, Figure 11.5.

The tasks are addressed to you as the strategy program leader. You may be part of the organization or an external facilitator. You may be a thought leader in the field of endeavor or not. It’s rare, but you might be the leader of the organization. Or, if it’s your personal endeavor, you might be all alone. Included in the introductory section are suggestions for staffing your programs and techniques that apply throughout the task sets.

Staffing Your Framework Design Program

For large, multifaceted strategy endeavors with diverse, spread-out organizations, you may need several unique roles and teams. In small endeavors, team members will wear multiple hats. Where strategy development is embedded into the fabric of the organization and not an event (the nirvana case), some or all people will fill roles as part of their normal assignments. Staffing may change as you learn people’s skills. This section describes options for roles and teams and offers guidelines for what to look for in participants, including the use of consultants. If you do not have the authority to choose, maybe you can influence team composition. Included is the recommendation to extend the design process in time where feasible to enable key people to participate (Chapter 11).

Roles and Teams

There should always be tension and a trade-off between the benefits of inclusion and the complications of additional participants. Inclusion supplies more diverse experience, more workers, should lead to better decisions,¹ and gives more people the chance for internalization and emotional ownership. On the downside of inclusion, it is hard to design by committee; an open and honest dialog may be difficult, and the larger the group, the harder it may be, depending on the culture of the organization. Though online conferencing helps, scheduling and sheer availability become a challenge, which is more difficult still if people are in different parts of the globe. The other downside is that more people involved in an endeavor, the less any individual may feel accountable. The staffing techniques presented here suggest ways to find a good balance between inclusion and smallness. When in doubt, start small
and add more people as needed.

1. G. Paul and S. Kovvali. July 01, 2018. “The Other Diversity Dividend,” Harvard Business Review.

Sponsor

The person you report to or take direction from may be the “boss” or the sponsor. This person is likely the controller of resources and someone who has authority or strong influence in the system to be worked on. If you are from outside the organization and serving as a consultant, this person may be your client. Usually, this person has a vested interest in the success of the program, but if you are driving it, they may not.

The sponsor role may be a steering team that likely includes the boss, from which you can gain the buy-in from decision-makers and advice from people with potentially broad, diverse experience. The steering team can also simply be a de facto part of the organization, a business leadership team, for instance. If you can influence, limit the steering team to two or three people. Members of large steering teams (like
boards sometimes?) may feel safe making decisions without investing time to learn about the endeavor.

Program Participants

The design team is your core working team. By having, say, two to five key members possibly representing the various functions of the organization involved (e.g., sales, R&D, product management, supply chain), you will have more experience and awareness of what’s going on throughout the organization. If your endeavor is large, and the organization is large, more diverse, and/or geographically separated, you might consider adding:

Extended design team. This team includes people you consider important for their knowledge, their position, and in whom you wish to instill a sense of ownership. An extended design team will meet and work less frequently than the core design team and should especially include people in the organization who will be a part of implementation. In larger endeavors, where there are multiple functions spread throughout the world, this team could be 20 or more people. The extended team may be only occasionally brought together as a whole, but they can be kept in the loop, informed, and ask for feedback often.

Ad Hoc teams. These teams are commissioned to solve a specific problem, answer a question, or evaluate, assess, or draft an aspect of the design. You can form these teams from people already inside the project or from outside. Ad hoc teams are efficient, use people’s strengths, honor people’s expertise, and test people’s ability and leadership. Members of the extended design team may be good candidates
for ad hoc assignments.

The percentage of time team members give to the program depends on the scope of the endeavor and the degree to which you extend the process in time. However, expectations and commitments should be clear and required.

Facilitator

The facilitator, sometimes called a process leader, gives technical guidance and training on the framework design approach to individuals and teams, leads or assists in running meetings and interactions (whether in person or on video), and assists with live capture of group work. The facilitator must be respected and supported by the program leader and sponsor. Beyond technical knowledge of the emergent approach, the facilitator should have the skills (and confidence!) to:

• Keep people engaged and work through pain
• Help the team get unstuck
• Pick up vibrations and undercurrents of what people are thinking
• See through seduction by easy answers
• Manage disrupters
• Keep their own prejudices at bay
• Stop at any time

Neutrality—controlling prejudices and biases—is particularly important for the facilitator. This goes beyond content. It may be hard for a facilitator to stay neutral if they favor a person who likes their approach or likes them personally. All leaders are faced with this challenge.

It may be best for the facilitator to be an outsider. You, as program leader, or another team member, can be the facilitator, especially in a small endeavor, but this is tricky. It’s hard for a leader or invested team member to be neutral.

If you must use a facilitator who is an insider, be cautious of “playing it safe” by choosing someone who ruffles no feathers. Even-tempered people are great, but not when they have a personality that aims to keep everyone happy, or that lacks the sensitivity to see and feel the subtle differences in what people are saying.

Individual Team Members

Everyone wants to work with knowledgeable, thoughtful, and helpful people who can create brilliant designs quickly. Consider the following when staffing your teams (again, assuming you have the right to choose):

• Will they contribute diversity of thought, style, unique skills, experience, anda network of connections? Lafley and Martin recommend having at least oneteam member who was not part of designing the current state.²
• Are they on the “front line,” directly contacting customers, constituents, competitors, or supervising production?
• Are they from other parts of the company that might be impacted by yourframework?
• Will they be part of implementation, either as part of a special team or as partof the line organization? People who are part of both design and implementation give valuable continuity and have valuable buy-in. Including these peopleis an important reason to extend in time (Chapter 11).
• Do they represent an important functional group or organization? Does thatgroup need to buy into the approach for it to succeed? Are they connected tothe bottleneck or important to busting it?
• Do they control important resources?
• Are they at the right level of the organization? A CEO working on a majorcorporate change may or may not benefit from participation by accountantsor fork-lift operators.
• Will they do work? In meetings and outside? Multitasking and occasionally saying something in meetings isn’t much help. Doing offline work that will be presented to and scrutinized by the team requires a different level of effort
• Will they be so pliant that they go with the flow on everything and suck-up to the leaders? Or the opposite, will they be too independent, unable to follow the leader, and potentially subvert the process?

The Three Ws capture several of these criteria—will a person bring Work, Wisdom, or Wealth to the team? (Other criteria are captured by the four Ds: will people be Dunces, Disrupters, Dilettantes, or Dorks.)

2. Alan G Lafley et al. 2012. “Bringing Science to the Art of Strategy,” Harvard Business Review 90, no. 9, pp. 3–12.

Geniuses and Jerks

Some team members are sure they have everything already figured out. Sometimes, instead of using the process to get their ideas burned into the system, they subvert the process with anger, cynicism, or passive-aggressive stonewalling. Some people insist on being the smartest in the room. And sometimes, you may really be dealing with a “genius” (or they may be encouraged to believe themselves a genius because the organization is analytically weak or nonconfrontational).

You must decide whether to coddle and bend to such people. Will they alienate everyone else? Do they have the ear of a leader who can kill your process (or your career)? Not all brilliant people are easy or fun to work with. Of course, if someone can create excellent frameworks in their head and can get people throughout the organization to follow them with great energy, no matter what their style, then stop reading this book and give that person carte blanche and a raise.

Whereas it’s easy to see who the jerks are, it is sometimes the best-behaved people that are the most useless for making change. People who won’t ruffle feathers or who smile and gently nod their heads to everything that’s said are not helpful.

Using Consultants

Consultants can be great for:

• Bringing specialized domain knowledge, specialized techniques and research,or theories and data on how things are in the world.
• Providing high-quality hands and skills when you simply do not have enoughpeople, or when in crisis.
• Lending credibility for your ideas by supporting them. (This may be good orbad.)
• Helping you discover or face truths that you could not on your own, assuming they have techniques and skills to do so.

Consultants are not as good for giving you the strategy (i.e., the framework) answer—doing strategy for you, or worse, doing it to you,³ especially in a quick linear sequential program where you are perhaps left with a massive PowerPoint deck. Even if the consultant has insight that you do not have, it may be useless if your organization does not have the ability to grasp it. Just taking the superficialities and the slogans of consultant insights does damage, not good.

Don’t put your consultants into this situation. If the company is committed to your endeavor, and organizational capability matters, then take responsibility for strategy yourself, using consultants to guide and do it with you, versus consultants doing the strategy with the company’s help.

Hiring consultants for fast action can be effective when the goal is tearing something down (the proverbial hatchet man). Tearing down, “revolutionary destruction” as described in Chapter 2, is always easier than evolving something new—especially revolutionary creation.

3. Rosabeth Moss Kanter said, “Change is disturbing when it is done to us, exhilarating when it is done by us.”

Three Challenges for Process Leaders and Facilitators

Be sure that the sponsor or client who has engaged you really has the buy-in of the organization. This doesn’t mean quitting if they don’t; it means figuring out why they don’t and what, if anything, can be done.

Second, the client may not be a good judge of the approach, or of you. If you are skilled and the program is a success, people should think they did it themselves. In many ways, they did, but only because you gave them the underlying discipline. Developing people is about the best a facilitator can do for a client. Unfortunately, if the boss hears you were not important because you were a teacher and not a doer, it might not help your (internal or external) consulting practice. You can encourage people to see and understand your role in the process, but sometimes all you can do is suck it up.

Third, when using the emergent approach, the client may believe nothing is getting done until the results emerge. You may hear statements like, “We’ve met seven times, but today is the first day we got something done.” This is like spending months designing a building, locating a site, securing funding and permits, and buying materials, and when finally starting construction, someone says, “Hey, you’re finally getting some work done.”

Being sensitive to these issues will help you better manage expectations.

General Techniques that Apply Throughout

The following techniques and guidelines apply to the task sets in general.

Lite Approaches

The task sets are detailed for use in multifaceted and spread-out organizations and endeavors of some magnitude. If your endeavor is smaller, a lighter approach will be more appropriate. You can achieve a lite approach naturally because most tasks recommend starting simple and digging deep only as needed. If you have only a single simple goal, you can breeze through the section on aspirations. If your endeavor
includes only a small number of people, you can skip the sections on nested frameworks or putting together multifaceted design teams. A simpler endeavor will mean a simpler Strategy Alternative Matrix (SAM). But be sure to go through all the tasks to be certain that you can skip any of them.

A lite approach might be needed when there is a deadline, real or imagined, even if your endeavor is not simple. If so, get to a draft SAM as soon as possible by articulating the reason for the work (Task 1a) and then focusing on the Strategy BottleneckAspiration triad in Task Set 2 to design framework alternatives and a few key fitness criteria. Then ask experts, stakeholders and whoever else can bring clarity to weigh in on the alternatives. If you can’t invest further to narrow uncertainties and critique the SAM, be sure to reflect the high level of uncertainty by including a strategy alternative with optionality.

An extreme case of a lite approach is used when you are in crisis. Your framework will be built around a strategy relating to doing whatever it takes to survive in the short time horizon, while striving to maintain core values. The tasks would simplify to:

Naming

Naming comes up repeatedly for programs, strategy alternatives, and scenarios. You may want to be bombastic or humble, specific or cloudy. A good name communicates a unique spirit and will speed design by providing a shorthand enabling the team and the organization to visualize the case. Make names short, and be sure people understand what the name symbolizes.

Do not use default names like Alt 1, Alt 2…, or Framework 1, Framework 2…., or Scenario 1, Scenario 2. Names do not have to be fancy; they need to viscerally mean something to people. Generic names like business as usual (BAU), conservative, crazy, new direction, experiment, simple, scary, comfy, timid, aggressive, high-optionality, and low-optionality are OK. Names specific to the endeavor are better.

If you wish to convey information, do not name the program by cliché superlatives, especially if the organization hears them all the time. If the name includes “transformation” or “excellence” and it’s the seventh program title in the last ten years that includes these words, people might not take note. What will the next IT program be after Digital Transformational Excellence? Extreme Digital Transformational Excellence (EDTE)? How about just calling it your Digital Migration TECHNIQUES THAT APPLY THROUGHOUT 12 Framework and demonstrate its importance and your expectations of excellence
by your designs and actions. Use the opposite disqualifier to eliminate words like breakthrough, superior, and optimize (Figure 8.3a). When superlatives are allowed, the organization becomes laden with a mess of internal branding creating noise and worthless competition between leaders and functions that does nothing for customers, growth, or profitability.

Some facilitators may recommend naming alternatives and scenarios after movie or pop stars or your favorite supermodel—Stevie, Mattie, and Rollo. These can be great; just be sure they mean something specific. Don’t choose names after the work is done—“Oh, this is the Thom Yorke Alternative, or this is the Rhianna Alternative.” Use names that grow organically out of the work and use them early. You can
of course change them. It may take a while before finding the names that make sense and resonate with the team.

Choosing When to Seek Feedback

It is challenging to know when to seek feedback from the boss, key stakeholders, or subject matter experts. Early feedback can be wonderful if it points you in the right direction, just like good early research and experiments do. But use caution when seeking high-level opinion (Chapter 17, EAS). Some feedback may not be based on understanding and send you in the wrong direction if you are overly suggestible. Of course, you may need to listen to the boss or people of influence whether they are
right or wrong (assuming you know).

Some people find it hard to keep quiet about what they are doing. They have a naive view that transparency is the best policy. Some people are desperate for recognition. Try to restrain yourself if any of these apply. If early communication is required, you might avoid the “organizational immune response,” as Gifford Pinchot called it in his Intrapreneuring,¹ by using simplified versions of your work for different audiences.

Leaders also have a challenge. The organization may be afraid of early feedback from leaders even if it is no way meant to be threatening. People may become unnecessarily cautious if they are asked to show work in progress. This is a sign of a weak organization, but it may be reality.

1. P. Gifford. Intrapreneuring. Why You Don’t Have to Leave the Organization to Become an Entrepreneur (New York: Harper & Row, 1985). p189. He also quotes Buckminster Fuller’s sharp advice, “Never show fools unfinished work.” p181. Perhaps we can add that when shaping the future, everyone is fool.

Should You Use Retreats?

The good, and the bad, of retreats is that they help clear people’s minds of everyday reality. Sometimes retreats are the perfect, neutral setting for inspiring good thinking and conveying the importance of the program. They may be perfect for hitting the organization with something big and scary where you need to manage the response. Retreats don’t have to be in Timbuktu, just far enough away from your working space. Somewhere next door may do. Depends on the vibe you want to convey. Be wary of using retreats as a replacement for inspiring or engaging people, or to mask a lack of depth of content. The worst use of retreats is to create an artificial sense of importance that is then not followed up with real leadership effort. In this case, the extreme difference between the launch and the reality after will signal to the organization that they don’t have to care (see Chapter 19, EAS).

Data or Question/ Hypothesis First?

Should data be withheld until a well-posed question or assertion is available for the data to answer? This isn’t necessary when you are solving a puzzle. Introducing data that you think are relevant without knowing why can stimulate thinking and raise important questions. (Just don’t introduce so much data that you turn off the brainstorming flow.) What’s crucial is to know the pedigree of the data. Bad data is worse than no data. Bad data is when you don’t know how or from where they were obtained. If you don’t know the pedigree of the data, label it as suspect in bold letters and throw it away if you can’t establish the pedigree. It’s great if you have data early to support an assertion or to answer a well-posed question, but do not roll out or gather data just because it is traditionally used in a strategy process (see Chapter 11, EAS). As a general rule—if the data is readily available, likely relevant, and easily digested by the team, then use it early.

Be Cautious with Pareto, Ockham, and Other Conventional Wisdom

It has long been an axiom of mine that the little things are infinitely the most important

—Sherlock Holmes

The following points of conventional wisdom are important. The danger is leaning on them to escape necessary work. Use with caution.

Paralysis by analysis—This uber-popular phrase misses the point. Analysis doesn’t cause paralysis. Bad analysis causes paralysis. Bad frameworks, bad goals, bad strategy, bad metrics, casual thinking, and a lack of rigor at low levels create paralysis. Clichés and platitudes and truisms and “just go do it” when no one really knows what to do causes paralysis, especially as captured in a massive PowerPoint presentation filled with unending historical data, hockey stick projections, and countless bullet-point lists of good things to do. Making statements with obviously absurd opposites in the hope it will drive unobvious fabulous results leads to paralysis— paralysis by platitude. Trying to make point predictions about currency, markets, and the rest of the future, especially by using detailed spreadsheets, leads to paralysis. The paralysis may not come until the future, but it will come (unless the leader just quits and declares victory without ever finding out).

No strategy or framework approach teaches to keep analyzing (or synthesizing) past the point of value. The team should be able to articulate why further analysis is no longer needed and avoid letting gut feel, frustration, lack of skill, wishful thinking, or fatigue stop the process.

Pareto’s Rule—About 100 years ago, the Italian polymath Vilfredo Pareto offered insights that have led to the notion that often 20 percent of the causes supply 80 percent of the benefits. It’s right to invoke Pareto to avoid diminishing returns or to avoid spending time on small stuff when there is big stuff to attack. Be sure not to apply Pareto as follows:

#1: Leaders invoke Pareto to reduce their anxiety that the people are just jerking around with worthless detail (perhaps when there’s no leadership framework to show what should be worked on, just goals).

#2: People invoke Pareto when shit gets hard to do.

What are the chances of finding the 20 percent of real causes after exploring the first 20 percent of possible causes? It takes hard effort to know the 20% real causes. It demands exploring much more than the first 20 percent. Sherlock Holmes says, “little things are infinitely the most important,” because at first they appear unimportant. Not all situations are 80/20 either. Leaders and facilitators need to be sure that when they implore their people to focus on the 20 percent that matters, the people know how to do it, and that they will not conveniently use the directive as a free pass to say, “we’re done.”

Ockham’s (Occam’s) Razor—The common version of William of Ockham’s 700-year-old guidance is if there are two equally good explanations, pick the simpler one. It is even better to say pick the one with fewer assumptions. But not only is simple not automatically better, the two options really need to be equal. Simple may just mean that people don’t yet have the needed insight and they invoke Ockham, or Pareto, to declare they are done. People may be comfier with tidy explanations than messy and difficult ones, especially at the beginning of an endeavor. It is not easy to make a framework simple; it is just easy to be simplistic.

Don’t reinvent the wheel—This seems obvious. Why reinvent? But there’s a twist. Maybe, because people have to learn, some rediscovery may help. Without experiencing a technology or a technique, people may not be able to judge what is needed or know how to move on to the next innovation. Say an organization needs a software application to perform analytics in an unfamiliar domain. Which case is preferable? (1) people develop a rough model on spreadsheets and work it until they see what’s really needed and what is inefficient, and then go out to purchase an expensive and powerful analytics system that meets their specific needs? Or (2) they say, “this capability is available from vendors,” and they go out and buy a system at once. The second option seems expedient, but the first might be better in some cases. Without the intuition that experience brings, the team may not have the insight to judge if the software will fully meet the needs or if they are buying an overdesigned system. Once big money is spent on something, it is hard to change direction.

Invest in Housekeeping

Housekeeping is a core principle of safety in any workplace, often with reminders like the 5Ss: Sort, Set in order, Shine, Standardize, and Sustain. When tools and work in progress are in their proper locations, and when order is established, accidents decrease and efficiency increases. A hammer or a drill left on the floor is both a tripping hazard and unavailable to someone who needs it. Housekeeping has meaning in design work too. It is hard to follow ideas captured haphazardly. If framework elements, data from research, or the results of a model are put in the wrong place, they may be misinterpreted, and they will be missing from where they are needed. One way to invest in housekeeping, and encourage internalization of what is being done, is to share responsibility for maintaining the SAM among team members. Responsibility for capturing changes in the SAM teaches people much more than watching someone else do it.

Brainstorming—Sometimes Tight, Sometimes Loose—But Always Disciplined

Brainstorming may be useful at many points during strategy framework design. The idea is to discover new variations by allowing people to freely associate, without heavy censoring, about some focal issue. The premise is that the lack of constraint and the feeding off each other’s comments efficiently enables variation generation. All thinking about change includes some brainstorming. It is simply variationselection-retention (destruction with stressors) (Chapter 2, EAS) with particular focus on variation. It’s the team interaction that makes it a unique process.

A misconception is that brainstorming requires no discipline; no judgment of what is said. Yes, the idea is that the variations obtained will be refined later with stronger stressors, but as with all creative work, brainstorming needs to be simultaneously free and disciplined (Chapter 2, EAS). The trick is to find the right level and type of discipline—the right degree of stressor.

Several techniques that can help facilitators maneuver the group to get the most out of brainstorming.

1. The focal issue depends on where you are in the program. For instance, at the start of a program you might brainstorm overall approaches or overall beliefs and diagnosis. Later, you may brainstorm on how to make a single assessment, or how to make a single measurement. Like variations in nature, most contributions will fail and not be useful, but a very few might contain the germ of a useful new idea. Brainstorming technique is the same no matter what the focal issue.

2. Focus more on Understanding and less on Judgement. It’s assumed when brainstorming that either no one has “the answer” or, if someone does say the right answer, it’s possible no one will recognize it as such. Therefore, it is dangerous to judge whether an idea is right or wrong. A better stressor is to judge whether people know what’s being said. You will be amazed how much right and wrong becomes evident just by clarifying statements.

Hint: The facilitator (and the team members) should repeat what people say back to them in different words, summarize, and ask questions of other to see if they understand it. Do not ask, “Do you understand this?” People may say yes thinking they do when they don’t, and in other cases they may just nod their heads yes to get out of further work or to avoid embarrassment.

Hint: Some people can’t stand even to see statements they disagree with. If things get dicey, say, “I am not asking if you agree; I am asking if you understand what your colleague is saying.”

Hint: Avoid capturing on the screen ideas that are obviously wrong and idiotic. Not only is it a waste of time and ink/electrons, but it may drive participants to feel the process is goofy and not take it seriously. These rejections do come at a price, though. If someone’s silly or crazy idea is judged as wrong, or stupid, you may shut the contributor and others down. Some people may already have difficulty saying their truths or letting it all hang out in front of a diverse group. To solve this, create a ‘we’re-not-sure-we-understand-it’ list, so that it doesn’t contaminate the process, yet it honors the person who said it.

3. Don’t Just List Ideas—Categorize as You Go. A second stressor is to assign ideas to categories. This is a gentle stressor that will not shut people down. Lists of ideas with no structure tend to become noise that is ignored, just like lists of subgoals and plans give little guidance (Chapter 8, EAS: The List Disqualifier). The literature describes many categorization techniques, sometimes called clustering or affinitizing. Categorizing is especially important at early stages of tasks when the team is groping for orientation. Tentative categories can be created at first, or you can create them as you go. In either case, add and modify categories as needed. It is a trade-off between less structure and increased freedom that can generate more variation.

Hint: The nature of these categories depends what task is being tackled by the group. Task 1-4 shows suggests several categories useful at the start of an endeavor, including using the framework components themselves, or more generic headings that relate to such things as certainty level, or stakeholders’ views. Another option is to use the categories from various analysis tools shown in the Additional Techniques (Chapter 17, EAS) including Lifecycle Analysis, Porter’s Five Forces, and so on. As always, use minimal ink and photons.

4. Scale the Stressors to the Stage of Design Development. Not only do the categories depend on where you are in the process, but the stressor level you exert doestoo. For instance, when brainstorming initial beliefs and diagnoses of the endeavor,you might use the Five Disqualifiers only to categorize and affinitize ideas. Forexample, you might say at this stage of the process, “Since this statement fails theNumbers Disqualifier, let’s categorize it as a plan or subgoal.” Later, however, whenworking the SAM and working toward getting an alternative to emerge, you woulduse the Disqualifiers to eradicate any strategy that fails the Numbers Test.

5. Be Prepared to Stop to Capture a Faint Idea.² Brilliant ideas are first spoken by asingle voice. Maybe an uncertain voice. All great storms start as zephyrs. The idea2 Ludwig van Beethoven wrote in 1823 to his patron Archduke Rudolph, “Continue, Your Royal Highness, to write down briefly your occasional ideas while at the pianoforte. For this a little table alongside the pianoforte is necessary. By this means not only is the fancy strengthened, but one learns to hold fast in a moment the most remote conceptions.” Beethoven’s musical memory was astonishing by any measure, yet he captured first ideas in his many sketchbooks.TECHNIQUES THAT APPLY THROUGHOUT19may not be vivid, it may be difficult to see and grasp, like a ghost. Most variations will sound wrong at first, whether in a brainstorming session designed for new ideas, or in the normal course of work. You may need to stop what you are doing and take some effort to capture first-spoken ideas. If you don’t, they may get lost in the shuffle and never come back, because the circumstances that allowed them to emerge may never again occur. It can be hard to know whether a new idea will be useful or not. One person’s rat hole is another’s gold mine.

Here are techniques for dealing with ideas that no one yet grasps, listed in order of increasing time required:

• Ask the person who thought of it to write it down for later discussion
• Capture the idea on the screen and explain it will be discussed later
• Capture and discuss the idea immediately

Knowing which to use depends on how many people are rolling their eyes, but don’t risk completely losing an idea that someone has a gut feel may be important. If you decide to capture it, but then see the team is struggling, you can always shelve for later. Of course, you can ignore the idea and hope it will come back at a more opportune time if it was important.

2. Ludwig van Beethoven wrote in 1823 to his patron Archduke Rudolph, “Continue, Your Royal Highness, to write down briefly your occasional ideas while at the pianoforte. For this a little table alongside the pianoforte is necessary. By this means not only is the fancy strengthened, but one learns to hold fast in a moment the most remote conceptions.” Beethoven’s musical memory was astonishing by any measure, yet he captured first ideas in his many sketchbooks.

Drawing Out Inhibited People

The presence of a boss or peers or reports inhibits some people and keeps them from letting it all hang out, even if everyone is supportive of the process. If this is the case, you might work privately with a sub-group and then bring the result to the whole team. Perhaps off-site or more casual settings will help loosen people up. Obviously, the facilitator needs to limit anything that approaches personal attacks, though what constitutes a personal attack varies from organization to organization. In some cases, aggression may encourage people. Another technique is to have people write down their ideas privately and then compile.