Mastering Collaboration

by Gretchen Anderson

In most organizations, decisions are either made through a democratic process or by a monarch (or worse, by a monarch with the trappings of democracy). Many executives actually see their value as being someone who makes tough decisions based on their experience. Team members may pick up on signals from superiors and simply fall in line, even if they aren’t fully bought into the decision.

  So what can I do?

  Avoid sales pitches

  Jake Knapp’s book Sprint (PCC) suggests avoiding having people present or pitch their idea. Try having people read or review the idea on their own, or have a third party present all the ideas. If someone can understand the idea without the sales pitch, there’s a greater chance it’s a strong one.

  Host a museum tour

  Along with “no sales pitches” Knapp suggests having ideas synthesized and posted on the wall with no names attached or much explanation provided. Participants can review the work individually and silently, placing dot votes or taking notes on those they find compelling.

  Vote blindly

  If you are going to vote, do it blindly—keep who created the ideas anonymous, and count and collect votes separately. Otherwise, when people see dots accumulating on one idea, they may add their own dot, especially if they are tired or intimidated.

  Success Criteria Aren’t Helping

  Success is something felt rather than expressed explicitly among many groups. Even, or maybe especially, in cases where there are clear KPIs that solutions must meet, the connection between what makes a solution a good idea and the leading indicators of success may not be clear. Even if you thought you were diligent defining your objective (as we looked at in Chapter 6), you may find that once you’re trying to make use of them they’re just not that helpful. Sometimes this dysfunction manifests by the team allowing every idea to pass because the criteria aren’t judgmental enough, or by people twisting the criteria to defend any and all ideas.

  So what can I do?

  Focus on the users

  Whether it’s a product, a service, a policy, or a process you are developing, there are likely people on the other end of your solution that will be affected. How would they define a good solution?

  Map the territory, then revisit it

  Sometimes you need to work backward to define success, not just options. If you have criteria that seemed useful at the start, but they’re not helping you weed out and elevate ideas (and let’s be clear, this is very common), it can be useful to look across your options to see what actual differences they reflect and then use those to move forward again. If you can develop one or two axes of qualities that your solution set fits on, you might begin to see aspects of new criteria you can use. For example, if some ideas are simpler to use but less secure, you can decide which option makes more sense and has higher value than the other.

  Too Much Conflict

  Every collaboration will have conflicts, but one of the worst experiences, which often leads to groups breaking up and going their own ways, is when the conflict becomes too personal or too poisonous. In Chapter 1 we looked at what happens when conflict arises because of cultural clashes on the team. But what happens when the disagreement is about specific ideas?

  As a leader and facilitator, you can help keep tension productive by helping teams share perspectives.

  So what can I do?

  Apply the Five-Minute Rule

  At Cooper, a leading design consultancy in San Francisco, we had a rule that if teams were disagreeing about something for more than five minutes, they had to go get another person’s opinion on it—anyone’s opinion. This wasn’t about breaking a tie or getting expertise. Having to explain the disagreement to an outsider is a great way to clarify thinking and arguments, and often the outsider made observations that no one had considered.

  Swap perspectives

  As Vanessa Cho did with her team, it can be useful in this situation to make opposing parties explain and defend the perspective they disagree with. Or, you can have people take on refining the ideas they dislike to see if they can improve them. What’s important is to get people to worry less about the specifics of an idea that they don’t like, and instead try to understand why the other person is suggesting it and what validity their view might have.

  Disagree and commit

  If a group simply can’t come to agreement about an idea even after much discussion, it’s time to pick a direction and ask the team to commit to it to gather more data and see what can be learned. As Matt LeMay says, it’s key that every person explicitly say they’ll commit to the selected direction rather than not voice disagreement. The direction can be selected by the person playing the navigator role, or by a leader in the group who can trust the team not to say, “I told you so” if the decision doesn’t work.

  Conclusion

  Once you’ve explored ideas widely and put aside constraints, it’s time to intentionally shift gears and get judgy. Teams can frame the discussion of ideas constructively, and then use constraints to make them more practical and workable. The type of discourse that you want to support in this stage is democratic, making room for the various diverse members of the team to weigh in and avoid the common traps of collaborative decision-making. Ultimately, it’s beneficial to have one person be accountable for making the decision, with the benefit of broad points of view at their fingertips.

  Teams that can dig into harnessing their good ideas will necessarily have tension, so don’t try to avoid it. Instead, make the tension productive by keeping it focused on ideas, not their creators. In the end, you may need to ask people who disagree to commit to a direction to test the solution and learn from its intended users what does and doesn’t work.

  Key Takeaways

  Be intentional about separating the processes of exploring widely without constraints and of evaluating and selecting ideas to refine and test.

  Selecting ideas can fall prey to psychological biases about what we think we want versus what meets the needs of the situation. Help teams be disciplined about evaluating ideas, not simply having a free-ranging discussion of them.

  Keep the process of evaluating ideas open and democratic, but try to avoid a blind vote for final decisions. You want the benefit of many perspectives, but don’t leave selecting ideas to a popularity contest.

  Critiquing and discussing ideas can lead to tension in the team. Don’t shy away from tension, as it can lead to breakthroughs, but make sure it’s productive and not personal.

  Chapter 9. Find Out What Others Think

  A team that has done a solid job of gathering diverse perspectives and exploring ideas will likely have arrived at some conclusions about how they can solve the challenge they face. Great collaborators will never stop being curious to put those ideas and conclusions to the test, and will continue to seek out the opinions of other people. And while putting ideas to the test is part of a process, it doesn’t have to take a long time to get to this point. Each cycle should set aside time to make sure that the ideas generated aren’t just put into action without feedback about how they perform (Figure 9-1).

  Figure 9-1. This stage of the team’s cycle will give you valuable feedback, even early on in the process

  Running through the process in a few days or a week and then repeating it to refine further can be more useful than spending a great deal of time trying to do it once and declare victory. The biggest mistake many teams make is waiting too long to get their ideas prototyped and tested with those they are meant to serve.

  In this chapter, we’ll look at why sharing in-progress work is so helpful, and how to go about making sense of the feedback you receive so it helps to strengthen ideas. Teams should be clear about how “finished” the work is that they are sharing, and present it in way that leads to actionable feedback. You’ll also learn how to help team members deal with less-than-positive feedback on their work.

  Share Early and Often

  Matt LeMay, in his book Agile for Everybody (O’Reilly), says tha
t sharing work early and often is critical for teams to succeed. Because organizations typically share finished work for a final approval, versus seeking input to refine work in progress, solutions can become inflexible, requiring specific conditions to function. When work can be shared ahead of time, before certain assumptions become etched in stone, solutions become better adapted to real-world conditions. Sharing work in progress also helps organizations continually refine and communicate their understanding of the problem(s) to be solved. LeMay told me that “having people at all levels understand what you are trying to solve for is absolutely critical,” and showing solutions in progress is an effective way to create that understanding.

  Sharing early and often means being curious to hear what others think about ideas even before they are fully fleshed out. Sharing also helps keep a large group more engaged in the problems and solutions at play. LeMay has found that when meeting time is used to dig into and make decisions together, it can feel more meaningful than when it’s used simply to inform people of finished work.

  When we find out what others think, we’re doing three things:

  Turning assumptions into knowledge

  Testing ideas and hypotheses to see if they show promise with those they are meant to help

  Opening up our thinking to find blind spots and mistakes

  This means that you need to help your team keep track of and be transparent about assumptions, develop artifacts that test them, and be prepared to hear answers to their questions.

  Share Especially in Challenging Situations

  Sharing work also tends to fall by the wayside when a team is going through a rough patch. Whether it’s a release that’s gone wrong or negative feedback about work, when we experience failure, it’s natural to hunker down to get through it.

  In The Logic of Failure (Basic Books), Dietrich Dörner shares insights from psychology studies about what happens in our brains when we’re confronted with challenges and failure. In one study, participants were asked to play a “war game,” like a low-resolution version of The Sims, where the player must balance different forces to keep a population safe and healthy. The game involved balancing a large number of competing factors, and the goal was not easy to achieve. The researchers found that as the game progressed, the difference between success and failure could be seen in the ratio of activity to asking questions. In other words, when things get tough, some people tend to start taking action after action without gathering information about the situation or the effects of those actions. But to succeed in balancing complex forces and make good decisions, the opposite is needed; when things become challenging is exactly when we need more information, not less. Communication goes two ways: when you don’t communicate out, you’re also not getting new info in.

  As an example, Dörner looks at the 1986 Chernobyl disaster, when a nuclear reactor exploded at the atomic energy plant in Chernobyl, Ukraine, polluting the surrounding area and most of Europe with radioactivity. The engineers had decided to conduct an experiment to improve safety systems at the plant and reduce the operating capacity of the reactor to 25%. Instead, the operator inadvertently reduced the capacity to 1% by using manual controls, missing the fact that the system had automatic damping functions that also kicked in. Operating at such a low level is dangerous because the reactor becomes unstable, with irregularities in nuclear fission as a result. Operators knew that this situation was dangerous and immediately took steps to monitor and correct the resulting capacity level. Each step they took affected the capacity in one direction or another, however, which eventually led to the explosion. Dörner says, “This tendency to ‘oversteer’ is characteristic of human interaction with dynamic systems…We find a tendency, under time pressure, to apply overdoses of established measure. We find an inability to think in terms of nonlinear networks of causation—an inability, that is, to properly assess the side effects and repercussions of one’s behavior.”

  We also benefit from sharing our work with those who will make use of it, even when it all goes horribly wrong, because, as Dörner says, “theoretical knowledge [of risks and consequences] is not the same thing as hands-on knowledge.” The operators at Chernobyl violated some safety precautions during the event, just as we all tend to bend rules, usually without suffering any consequences for it. But they didn’t “conceive of the danger in a concrete way,” just as your team may not fully understand the implications of decisions that entertain a little bit of risk. Especially when what you are working on isn’t a nuclear reactor, it can be tempting to just launch it into the wild rather than testing it in a contained way.

  When we hunker down when things go wrong, we rob ourselves of the information and perspectives of those who could spot our mistakes and help us correct them. Sharing isn’t just about communicating what works, but about helping everyone avoid oversteering and missing the nuances in complex systems.

  Be Disciplined and Intentional About Sharing

  Sharing work with those who haven’t been closely involved is so valuable, but it also takes some effort to prepare for. Even with a group that holds different views and has different skills, once an idea has made it through the group’s exploration and deciding stage, they are naturally attached to it. This idea may even be something you’ve asked people to “disagree and commit” to. This step doesn’t need to become a huge effort, especially early on, but it also won’t just happen naturally. As you begin sharing an idea that is more and more developed, it can be tempting to just start lobbing work out to an audience and assume the feedback will be useful. But to get the most out of your collaboration, it’s important that you know what questions you have and share work that will get you answers to those questions. The team should also be clear on whether what you’re sharing is something small that you will grow over time, incrementally, or whether you’re open to actually throwing out previous work to make a new iteration. When you plan properly to find out what others think, it yields so many rich benefits; but when sharing work “just happens” at the end of a sprint, your team may get distracted or bogged down in feedback that is not actionable or leads you astray.

  There has been much written on the art and science of conducting user research, and my advice in this area is simple: hire professionals to do it. That being said, a collaboration that wants to get close to users means even the nonprofessionals should get some experience understanding their audience. When doing upfront, exploratory research, in which you’re being omnivorous and nonjudgmental with people to understand how they see the landscape you’re working in, it’s important to be disciplined in your approach.

  Know What You Are Listening For

  The best way to prepare for research is to create (or, better, always have) a running list of questions and assumptions you want to learn more about. At the start of your project and each cycle, turn back to your objectives that say what you think will happen and why, based on what you know and what you can guess. These questions will form the basis of a plan to guide you.

  A basic plan should have:

  A statement of the objective, or the part of the objective you are focused on. For example, if your objective is improving physical security at a location, and the idea(s) being tested focus only on stopping tailgating (i.e., people following others into a site without badging in), state that.

  The key questions you want answered, such as: Is the solution understandable? Will people adopt it? Does it appear to take too much effort? These are often the same questions that came up when the team was developing the idea. Review what was contentious about the idea to see what others think.

  The method you will use to test ideas out. Are you showing people example solutions in context for them to use? Or are you sharing a description of a solution in a conference room or over a video call?

  Who you will share the work with and how you will reach them. If the people you need are difficult to schedule and talk to, you should plan for that. Especially if you are working wi
th customers, you may need to follow certain rules or enlist others in the organization to get to them.

  In Just Enough Research (A Book Apart), Erika Hall says, “assumptions are insults,” and she’s right. However, since we can’t know everything all the time, we can’t avoid making them. What you can do is be clear and transparent with yourself and the team about just what truths you hold to be self-evident, and revisit them when you hear something that doesn’t fit. Most likely when feedback doesn’t match the team’s expectations, you are running into an assumption that should be challenged and revised. A red flag is when a person or team begins discounting what they hear from outsiders because it doesn’t fit with their worldview. If you can keep your own head on straight, you can help model the behavior of checking assumptions, and eventually get the group to police themselves and each other. Learning to get past bias is a behavior that can be learned, and it pays great dividends. You can help teams that struggle with this by pointing to or adding the assumption in your plan to make sure you don’t take it for granted.

  It’s generally preferred to work with people one-on-one, or in realistic groups that reflect actual usage. In large panels of strangers, or focus groups, data can be skewed by participants who dominate the conversation or who express agreement they may not actually feel.

  Fidelity Matters