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 BottleneckAspiration 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,1 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.
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.2 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.
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.