Category: Process

• Balance control with collaboration – First Draft

  To solve tough problems, we need the active participation of a diverse group of people. Instead of control residing only with managers, each person on a team should have the authority and responsibility to contribute fully. Rather than command them from above, the team leader should facilitate the team’s efforts.

  Since the industrial revolution we’ve needed a lot of science to deal with the changing nature of work. Science in the form of organizational theory helped us structure giant corporations. And the scientific method made time-motion studies possible which vastly increased manufacturing speed. Frederick Winslow Taylor wrote a book in 1911 about the latter field, appropriately titled, The Principles of Scientific Management.

  These days our work increasingly consists of complex problems that cannot be divided into simple, repeatable tasks. Take, for example, the Global Earth Observation System of Systems in which 60 countries have agreed to participate in a 10-year effort to collect and share thousands of measurements of the Earth. This data has a wide variety of applications, from monitoring pollution to predicting the weather. But this requires hundreds of scientists with different agendas to agree on thousands of decisions. As one of the project leaders says, “‘We have been able to make computers work together. The challenge of the 21st century is to get people to work together…’ noting that the problem will be overcoming bureaucracy, politics, and turf.”

  Science alone wouldn’t have a chance to make this project work.

  The work practices we used throughout the 20th Century are still important and useful. But for complex, 21st Century work they’re not sufficient. Because the problems are bigger, they require more people with more skills to solve them. These complex problems require the combined effort of people with complimentary experience, knowledge, and ways of thinking.

  Working involving new combinations of people requires effective collaboration.

  Collaboration requires each person on a team to have the opportunity to drive the processes and outcomes.

  In other words, success with complex problems depends on sharing control with others. Joe Kraus, the founder of Excite and JotSpot has said, “Very early on, the founders of startups make an important choice. Do they want success or control? …I’ve picked success. And success implies giving up control – hiring people who are much better than you, or being willing to be the janitor if that’s what’s required.”

  Of course, groups that have no leadership at all can easily slide into a death spiral of debate and fail to accomplish anything. Success today requires balancing control in the form of management with collaboration in the form of facilitation.

  Try it now
  On an interdisciplinary team, assign a team lead that is a contributing member of the team, but also has responsibility for two critical functions:

  1. Facilitate the process – This is an art in itself, but it includes eliciting each team member’s best work, resolving conflicts, and finding alternative paths when the team gets stuck.
  2. Make executive decisions – There will be times when team members will have opposing opinions and can’t resolve them. The team lead synthesizes everyone’s viewpoints, weighs the project priorities, and makes the tough decision, but only when absolutely necessary.

  3/13/2006

  ---

• Agile publishing

  37 Signals’ new book Getting Real is out, and looks like a great read about applying agile techniques and spirit to web app development. It’s agile both in the content and in having small chapters, something we’ve seen in books like Godin’s Purple Cow and what I’m working on by re-interpreting agile principles for general managers in Evolve.

  Who has time to read long books?

  3/2/2006

  ---

• Use simple tools

  The tools we use to create and communicate should be so easy to use we rarely ever think about them. With simple tools we naturally focus on what the tool allows us to do.

  The famous typography designer Matthew Carter has said that when you read you should not see the letters on the page, you should see through the type to the message. If printed type was the tool we’ve used to communicate for thousands of years, today we do our jobs using mobile electronics, software user interfaces, rapid prototyping devices, and so on.

  And yet, as I write this in 2006, I still can’t use my computer to make an appointment with someone working for a different company and know that the meeting will appear on both our calendars. I may spend time trying, but I know this everyday task is still completed more easily (and with more accuracy) if I simply call the other person and schedule the appointment over the phone.

  If your calendar software makes it difficult to schedule a meeting, use something simpler. If it isn’t obvious how to use the functions of your mobile device, get something easier. These tools should be just as transparent as the type you’re looking at now. Communicating and executing our ideas is too important to let technology get in the way.

  Robust tools are seductive, but their complexity quickly results in diminishing returns. Adopt tools with as many features as you need, and no more. Usually a few essential features will enable you to do many things well.

  Try it now
  As you go through your days, write down a list of every tool you use to create and communicate. Mark those that are cumbersome, and find an easier replacement for each cumbersome tool. Do the same with your team.

  2/24/2006

  ---

• Agile everywhere

  I’m finding examples of agile work practices in more and more places, and see them as perfectly aligned with the application of design practice in innovation services. Here’s a running list…

  • Agile programming has the most robust expression, including a philosophy, an alliance of various approaches, tools, software, and measured results.
  • Agile project management
  • Get Real from 37 Signals is an effective framing for web application developers
  • Lean manufacturing
  • Lean manufacturing applied to programming
  • Adaptive Co-management in forestry
  • Artful Making is the application of theatrical processes to business
  • The Knowing-Doing Gap
  • Research into pre-mechanization group work

  I think people in the product design and user-centered design disciplines work in agile ways as well, but haven’t yet found a common frame that other disciplines readily understand.

  2/16/2006

  ---

• Dancing elephants: Lockheed

  I love seeing big companies move in agile ways (because it’s so unusual), even if it only arises from panic of losing their old revenue streams. Here’s an example from Lockheed, whose old culture (despite their Skunk Works-style innovation) included bitter internal fights over whether to pursue unmanned aircraft…

  …It also designed and delivered the seven-pound Desert Hawk within 127 days of receiving an Air Force request. The total cost for the first six drones and laptop-computer control system was less than $400,000, Mr. Cappuccio says. To date, Lockheed says it has supplied 126 Desert Hawks, which are used for surveillance to protect U.S. bases in Iraq.

  When you also produce the most expensive fighter jet in the world, that’s certainly overcoming your innovator’s dilemma.

  Incidentally, here’s an article about another group at Lockheed using agile practices.

  2/16/2006

  ---

• Swallowing stones

  “Some thoughts are like the digestive stones that birds swallow.” — Owen, in a conversation on change.

  1/31/2006

  ---

• Is Angie a design thinker?

  German Chancellor Angela Merkel is making waves at Davos. I like her attitude: “She acknowledged the political necessity to move ‘in small steps.’ She added, ‘In Germany, sometimes things never get going because one doesn’t know how it will work out, and maybe it’s better to do nothing. That’s not my maxim.’“

  1/26/2006

  ---

• Periodic process renewal

  There’s a funny (or cruel, depending) dilemma to improving your work over time. If you don’t do it, your organization becomes less and less valuable over time, gradually failing, and dying an unfortunate death. If you do all the time, you never get to benefit from each change very long and probably suffer from change fatigue. We’ve even labeled these positions in our worldviews: conservatives want to keep things just the way they are – thank you very much – and progressives always want to embrace the something better that’s just around the corner.

  My fix for this is simple: Instead of never changing or constantly changing, set a regular period when you revisit your process. And just so you’re pretty sure the change is leading to improvement, have a simple way to keep track of what you did, why, and what happened as result. Not every change will result in improvement, but at least you’ll know that and not repeat your mistakes.

  We can look at this in evolutionary terms using the example of sharks. A shark doesn’t evolve constantly, it evolves by having baby sharks (which are amusingly called pups) that have unique DNA that make them more or less successful than their parents. While each shark is alive, her life is a time of trying out her DNA and either succeeding or failing to have her own pups. Reproduction is a time of trying slight variations (aka gene mutation) on what worked before and only passing on the DNA of successful sharks. Over time, sharks become more and more successful at being sharks.

  I’ve started developing a simple model of the nature and frequency of process change in companies based on what I’ve seen in the dozens of companies I’ve worked for or with. The model boils it down to three types:

  1. Deteriorating: When the company was young they designed and established productive methods, but over time the methods gradually lose value as the environment changes. We see this trend in the Management Practices across Firms & Nations survey.
  2. Chaos: Change is constant, usually reactionary, and there’s little history of past changes to help judge the effectiveness of future changes.
  3. Periodic Renewal: The company designs and establishes some methods and measures the results, periodically revisiting them and making improvements.

  I might draw them like this:

  

  And I might track the change over time like this:
  (diagram coming soon)

  Periodic renewal requires the organizational discipline to stick with what works as well as the resolve to occasionally improve it, a careful balance. For many companies, the closest analog is periodic performance reviews. We don’t formally judge our colleague’s performance and award raises every day, we do it periodically (or suffer the wrath of seriously pissed off colleagues). How good is your performance review process? Judging your ability to improve this process over successive versions may indicate your current ability to institute periodic renewal of other processes.

  1/18/2006

  ---

• Tell the Truth, part II

  So how do we tell the truth? Here are a few ways I found work:

  Inform the uniformed: Challenging the accepted situation by citing reality may get you sent to Siberia. But it depends on whom you’re talking to. Over time executives become ill informed – ironically – because timid employees avoid giving them bad news. For the executives, the truth becomes a rare and valuable revelation, and you a valuable messenger if you relay the truth in a way that isn’t tied to your personal agenda.

  Collectively decide to be honest: Being honest is much harder than it sounds. Much of the mediocrity in companies is a result of superficial niceties that make it impossible to productively critique ideas. Being honest means praising ideas worthy of praise, and criticizing ideas worthy of criticism. Before doing it on an individual level, everyone in a group should agree that honest interaction is necessary to improve the organization, and that honest expression is not personal condemnation.

  Reframe ideas: Any current business issue stands on an implicit context of ideas that are part of the company’s culture. This collected wisdom is the frame through which new information is interpreted, even if the freshness date of those ideas is long past, such as growing for years but thinking, “We’re only a small company.” You can reframe the issues by presenting an alternate idea supported by a different context. “Now that we have 2000 employees and four offices, we have the capacity to consider exporting our products.”

  Appeal to science: Disinformation is rare among scientists and engineers because their livelihood depends on working within the physical constraints of reality. You’re not likely to hear, “That’s right, Victor, we’ll have that Internet bandwidth commodity exchange done by Tuesday afternoon.” When I work closely with engineers and programmers, they ruthlessly critique business ideas because they know exactly what it takes to implement them (and know they’ll later be responsible if they don’t speak up now). Citing scientific reality – or aligning yourself with scientists – becomes a useful sieve to filter out disinformation.

  1/12/2006

  ---

• Tell the Truth

  Over time a company’s official history becomes ideology and people need the truth of reality to help them grow.

  On my first trip to Berlin I toured the former Deutsche Demokratische Republik including a number of museums and memorials describing the former communist state, the Berlin Wall, and life within its boundaries. We’re now well aware of the reasons the totalitarian state collapsed. Central planning failed to provide for the needs of citizens. Official “full employment” resulted in idleness and dissatisfying jobs. And the need to further a core ideology made experimentation – and therefore innovation – highly unlikely. Nothing remarkable was possible, the human spirit suffered, and eventually the whole system collapsed.

  It reminded me of some companies I’ve worked for.

  “Comrade Lombardi, I think you are mistaken in your effort to respond to these so-called customers, as the Party Leader has already informed us, there are no customers. There are only distribution end points. I am sure that lowering your bread rations will help you understand this.”

  This management-knows-all behavior creates fear that quickly overcomes the simple desire to tell the truth. When official disinformation is possible in entire countries, it easily happens in companies.

  Central planning. Unnecessarily large teams. Official ideology. Poor moral. Are you working in a totalitarian company?

  1/11/2006

  ---

• Work with a partner

  There are times when working with a single other person – pair management – is better than working alone or with a team.

  Some professions such as police have a long tradition of working in pairs. Recently software programmers have started to practice pair programming where two people sit together and alternate roles of writing and reviewing software code. The resulting quality improvements can make this process more productive overall.

  Pair management has some of the benefits of teams. A pair will generate more ideas than one person working alone. A pair generates a greater diversity of ideas, increasing the chances of having better ideas. A pair can work in parallel, going faster by simultaneously working on two related tasks. A pair can improve quality by working together on the same task. A pair of people can morally support each other, and people feel more satisfaction and learn more when working in pairs than alone.

  A pair can work more quickly than a team because communication and coordination between two people is easier than among a team.

  Do it now
  Begin with a defined project or task that can benefit from more than one person but doesn’t require a team to complete. Collaborate with someone who has complimentary skills and select an interaction style from the list below.

  Work with a partner who has complimentary skills, such as:

  • Different skills with the same perspective, such as a more creative person to compliment a more analytical person
  • Similar skills with a different perspective, such as knowledge from inside the organization to compliment knowledge from outside the organization
  • Broader or deeper skills, such a range of relevant experience to compliment deep expertise in a particular area

  When working with a partner, choose an interaction style suited to the activity at hand, for example:

  • In continuous review one person does the work and the partner continuously reviews the quality of the work. The pair periodically switches roles.
  • In problem solving both partners work together to solve a problem through tasks like generating ideas and building an analytical model.
  • In complimentary tasks each partner does a different task that benefits from real-time communication with the other partner. For example, if you’re testing a prototype one person can run the test and the other person records the results.

  The main pitfall to avoid when working in a pair is groupthink. Partners need to feel comfortable showing healthy skepticism toward each other’s ideas. Careful matching of personalities is important in forming effective pairs. For example, it can be difficult for someone to provide honest feedback to another person higher up in the organizational hierarchy.

  There are times when working alone or with a proper team is better, see Work Alone and Work as a Team.

  12/17/2005

  ---

• Work as a team

  A group of people working as a team is often the best way to complete a project because teams can generate more work of higher quality than individuals or large groups.

  Do it now
  Form a team of people for a project requiring new ideas and more work than one or two people can do. Keep the team small (seven or fewer people). Include complimentary skill sets and knowledge in the people you choose. Establish a goal for the team and establish a way the team should work together. Ensure everyone knows the whole team is responsible for the team’s performance; no one person can succeed without the whole team succeeding.

  A team can generate many ideas of a greater diversity because each person contributes their own ideas. A team can work quickly by simultaneously performing several tasks. A team can improve quality be checking each other’s work. Through collaboration (see Create by designing together), teams can apply complimentary expertise to one goal.

  For small or well-defined tasks, teams can be less productive than other configurations of people. At some point the added communication and coordination required among a team results in diminishing benefits and it becomes better to work alone or in pairs.

  The biggest pitfall is a group of people working together who think they’re a team, but don’t act as one. If each individual primarily works in his or her own department and collaborates by trading emails and meeting occasionally, this is not a team. A team is a small group of people collaborating closely on a daily basis to accomplish a defined goal.

  12/17/2005

  ---

• Work alone

  There are times when working alone is more productive than working with a partner or a team.

  Working alone is useful when you need to expand on an existing idea, to carefully synthesize information, or do imaginative thinking. Working alone can also be useful to finish a familiar task quickly without interference.

  Working alone isn’t always the most productive; particularly when you want to generate a large diversity of ideas, accomplish a team’s worth of work, or check the quality of your own work. There are times when working with a partner or with a team is better.

  Do it now
  Reserve time on your calendar for working alone. Go to a quiet place that stimulates productive work, like a library. If you have a definitive goal, start by planning how you’ll use your time.

  12/17/2005

  ---

• Create by designing together

  Working directly with other people to design or build something – co-creation – can produce significantly more productive results when creating a product than talking only.

  Do it now
  At the next meeting of your team, set a single goal for everyone to accomplish together. Post big sheets of paper on the wall and give each person a marker to contribute. Ask everyone to express his or her thoughts on the goal in the form of writing/drawing on the wall.

  When talking, people may address the same topic but talk about it so that they further their own goals instead of the group’s goals. To align the group, set a goal that the product must produce and instruct them to work together to create a product that achieves that goal. The group can work on building the actual product, or design it on paper or electronically, though to Radiate information it’s often best to start with big sheets of paper or a whiteboard. By changing the style of work from discussion to creation the individual agendas become secondary to the shared agenda of designing the product.

  Here’s a story: A programmer and a marketer were in a meeting talking about creating a new watch for runners. “If we use satellite positioning, we can show runners where they are at any time,” said the programmer, “it’s a killer technology.”

  “So what?” replied the marketer, “it’s a novelty that will get old. Our research shows they want a watch that will make their daily run less monotonous. Maybe it plays a different melody at each 100 meter mark.”

  “That’s definitely not a novelty,” joked the programmer. “We can’t charge more money for that, but we could if we included satellite positioning.”

  Pulling out a big sheet of paper, they write down the goal: A watch that makes daily running less monotonous and can sell for $150. They brainstormed different ways of making running more fun, of using the available technology, and of which product features consumers pay a premium. Every suggestion had to make sense within those constraints. Eventually they designed a satellite positioning watch that plotted a different route for each run through the runner’s neighborhood.

  12/14/2005

  ---

• A bakeoff of product innovation methods

  Malcolm Gladwell’s The Bakeoff is now online, in which the food R&D firm Mattson tries to create the perfect cookie. Project Delta created three teams: one traditional in-house team, an “XP” (extreme programming) team of two people, and an “open source” dream team of the industry’s best working remotely. For anyone thinking about how to arrange people to create innovative products I’d say it’s a must read primer. With a couple caveats:

  1. The “open source” and XP methods are for building products, not for inventing new ones. The article illustrates why they don’t work well for inventing new things. We need some vocabulary to distinguish between innovation teams and building teams.
  2. Either the implementation of the methods or the description of them lacked key elements of what make them work. Open source is not simply an unstructured group of people contributing independent pieces. In Linux, for example, code is tested and reviewed by a central committee. And XP uses structured roles for programming vs. reviewing.

  The explanation of getting team size right alone is worth reading the article for. Some expertise on the team is good, but too many people create friction in the process and impedes progress. Also see What Makes Teams Work?

  11/10/2005

  ---