While you want people on their feet, they can’t stand the whole time. Make sure you have seats for everyone, even if the chairs need to be moved in and out, or around, the room. In some cultures there are specific seats or positions that the boss occupies. Whether it’s the head of the table or a specific chair, shake things up by assigning seats and grouping people in different ways.
Consider your writing surfaces
If you need people to contribute written ideas, whether by writing on Post-its or sketching solutions, think about what they will write on. If possible, avoid having a big conference table; instead, use smaller tables or individual surfaces so people aren’t wedged apart or tempted to open their laptops and check out.
Clear some wall space
Jorge Arango’s advice to make things visible requires wall space. Whether you put up big Post-its or use whiteboards, be sure to create and label clear places where different parts of the conversation are recorded. Large foam-core boards, which let you carry the work around, are also useful. Keeping tidy isn’t as important as keeping organized. Good facilitators will use clear headings and colors to designate different topics, approaches, or hypotheses that the team can internalize.
Pay attention to mood
It can be useful to control the mood—for example, by dimming the lights or playing music when you want people to work independently on developing or critiquing ideas. Changing the mood when you want to group to reconvene sends a clear signal that you’ve switched into a different mode.
Don’t forget food
Low blood sugar can make people cranky, and breaking for meals may have your team wandering off. Feeding people during a meeting or taking the whole team out to eat is a great way to make room for people to socialize and get to know one another while sustaining them.
Conclusion
The physical and virtual spaces we work in can affect how well we collaborate, so it’s worth putting in some effort to optimize them. Physical spaces help people have higher-bandwidth interactions and create a spatial mental map of the ideas generated within them. But while it’s useful to be able to come back to a space and have impressions and memories of discussions, it isn’t always an option for teams that aren’t colocated or can’t always find time to be together. Virtual spaces allow for more asynchronous communications and support distributed teams. However, they can be difficult to get working right. It’s not necessarily that one option is better than the other, but people have different preferences for how they work and it’s important to support those whenever possible. It’s also important to supply spaces where folks not only can be together, but also can focus independently on their work, whether in person or remotely.
Key Takeaways
The space that a team works in is critical to the effort. It provides literal and figurative space where ideas can live, and helps teams create a mental map of what’s been explored and discussed.
Physical spaces have the advantage of giving people a spatial model of the work, and support face-to-face communication that is high-bandwidth.
Virtual spaces support asynchronous communication and distributed teams who can’t rely on in-person communication.
People need space to work in a “heads-down” manner, not just in a group brainstorm setting.
Provide choices about whether people meet up in person or virtually to allow for differences in how people prefer to work.
Part II. Setting Clear Direction
Collaboration that drives new solutions means being open to different ideas and perspectives, but that openness requires structure to keep it from getting messy and going off the rails. When the answer you seek isn’t obvious, group dynamics and corporate culture can get in the way. This part discusses principles to plan out your collaboration and set clear objectives for the team to help you know where you’re going, and know when you get there.
Chapter 5. Make a Plan
One misconception about collaboration is that it’s a freewheeling effort where teams are encouraged to work free from rules and processes that might constrain them. It’s tempting, especially when the problem has a number of unknowns, to just get the group together and dive in, because it’s true that we want individuals freed to participate. But the effort? That takes planning. In this chapter, we’ll look at ways to provide the right amount and kind of structure to help teams focus and avoid interpersonal clashes that arise out of stress. Structure comes from the natural cycle of idea development, and from establishing clear periods of time to start, complete, and reflect on work. Providing a plan to stakeholders also helps give the team enough cover to actually do work instead of fending off questions about when they will be done.
Creating a plan simply means stating what you think will happen, what steps you think are needed, and some idea of how long things will take. It’s common for some people to shun this step, because there’s often no way to know ahead of time what will happen and when. I emphasize with those I coach that when planning, you’re just making your best guess at what will happen, and as the person closest to the situation, your guess is probably better than anyone else’s. Creating a plan isn’t about controlling every step of the process, especially when the situation is complex and unpredictable. To help teams maintain focus, take some time to spell out what you think will happen. As Dwight Eisenhower once said, “In preparing for battle I have always found that plans are useless, but planning is indispensable.”
Planning helps teams make productive use of their time and sets expectations without being overly directive. In researching this book, I observed two elementary school classrooms where teachers with different levels of experience ran group projects to teach collaboration. The groups were to create a play to perform at a school assembly where the theme was collaboration. While both classrooms were loud, with many children speaking and moving around at once—some writing dialog, others creating dance routines—I noticed a big difference between the groups based on how the teacher set up the assignment. One teacher asked the children to self-organize into groups and create a play to teach the younger students what collaboration is and why it’s useful. The other teacher, one with more experience with this exercise, divided kids into groups and described the play they were to make. She also had them plan out how they would spend their time to create their masterpieces.
The kids with less structure did complete the assignment, for the most part, but with interesting side effects. Some children, given the chance to self-select into a group, chose not to join. One child, who tended toward the shyer side, said, “I’m collaborating with myself. It’s way easier.” The child’s natural aversion to chaos led him to not participate since he couldn’t see any way to bring order to the task. The groups that didn’t create plans for how to use their time had too little structure to keep them focused on the goal of the exercise. Their performances had a lot of energy and funny in-jokes, but weren’t fully understandable to the audience. A few kids told me they were nervous and wished they didn’t have to perform, worrying that the other students would laugh at them. In contrast, the kids that had structured their time were more confident in their performances and positive about working together.
Planning your collaborative work isn’t about making Gantt charts or deadlines, but rather structuring the time you have and tracking progress toward the overall goal of the effort. To develop this structure, you should understand the risks and consequences that you’re facing and align expectations about where you’ll be at different points in time. The plans you develop with the team should be made visible and revisited frequently, so that they serve their function as guidance for the team rather than a prescriptive set of steps to follow.
In this chapter, we’ll look at how ideas grow from initial sparks into more fully formed concepts and concrete solutions. Along the way, you will need to understand and manage the risks and unknowns your team will face, and plan to mitigate them. By structuring the team’s time and thinking to
test ideas out, run experiments, and gather data, you help them stay open to different perspectives while being grounded in the real issues that could harm the effort.
How Ideas Develop
Providing structure starts with understanding how ideas develop. I offer an adaptation of the “double diamond” approach, created by the Design Council in the UK, which structures efforts around divergent thinking, where the team loosens constraints and generates many options, and convergent thinking, where the team specifies criteria to select ideas and try them out. The process of being expansive and critical repeats as you learn more and bring new information back to the challenge to inform another round of work. The “double diamond” refers to the fact that teams can use this approach in a first pass for determining objectives, and in a second for developing solutions. Since I find that both of those activities often take more than one cycle, I’ve depicted it as a single diamond that can be applied to either understanding a problem or developing solutions (see Figure 5-1). The diagram shows the cycle and the key inflection points that you should be aware of to lead people through it effectively. It has four basic stages:
Set objectives
Where the problem to be solved is stated, and success criteria are set
Explore
Where diverse solutions to ideas are generated
Decide
Where solutions are evaluated critically and one is selected to be tested
Test and learn
Where solutions are tested and data is gathered to evaluate and learn how to improve
Figure 5-1. How ideas develop
The diamond shape alludes to the creative process mentioned earlier, where you are channeling energies to be either divergent (many options are explored) or convergent (criteria are used to select options to try out). What’s key is structuring activities to understand what you’re trying to solve for, giving the team time to explore, being disciplined about choosing what to pursue, and trying it out. This structure helps teams focus on the problem and solution, and know when to be critical and when to be expansive in their thinking.
Often, without active coaching or facilitation, teams will attempt to skip to the end of this process by developing the obvious solution rather than trying different approaches. Because the value of collaboration is to bring many different perspectives to bear on a problem, and not assume we know the answer to complex questions, you should help your teams avoid this tendency by planning out time and being intentional about when you are diverging and converging together.
I’ve seen many teams be especially challenged during the exploration stage where they have spent time understanding a problem and begun developing solutions, but haven’t landed on anything tangible yet. Providing stakeholders with progress updates here is tricky because there isn’t a satisfying conclusion to report, and confidence about how the work is going is low. Being transparent in your plan about how your teams are using time will help to manage stakeholders’ expectations and push back against pressure to “just deliver something.”
Plan to Experiment and Reduce Risks
Because collaboration can help with situations where there’s a lot of unknowns, it can be useful to plan for time to investigate and “de-risk” situations, not just create solutions. It’s worth asking, how much risk is there in finding the solution, or how possible is it that you’ll develop ideas that fail? And, if you do fail, how bad are the consequences for the users and the company?
One way to think about the output of your collaboration is to frame it as being either an experiment, where you try a variety of ideas in a safe space to learn how they might perform and ferret out any unknowns without exposing yourself to negative outcomes, or a launch, where you release things into the real world to learn more specifically how they perform (see Figure 5-2).
Figure 5-2. Sometimes you want to test ideas in a controlled experiment versus a launch
For example, when I was part of a team designing a robotic surgical system, we would run experiments weekly or daily, by creating a simulation of the doctor’s controls and display to understand how well different approaches worked without involving the actual robot, which took a lot of time and money to prepare. Our experiments were about building confidence around a specific idea, or learning what made another idea fail. The environment we ran them in was highly controlled, with low risk of catastrophe if we were wrong. We didn’t always try to make the environment realistic, either. In one case we had doctors race each other on the system as a way of seeing many different challenges quickly, even though in reality, speed is never the key factor. Other times, with versions we felt strongly about, we would conduct trials on cadavers, or even animals, to validate certain choices. The decision to operate on a cadaver or animal was sufficiently serious that the team would choose this option only when we had a high level of confidence in what we were learning.
A launch, on the other hand, is when you actually put your solution out into the world, with factors you can’t control and effects that are real. Whether you’re sending shoppers to a new checkout process or collecting important data in a new way, there’s a possibility that if (really, when) things go wrong, the effects aren’t confined to the lab. But just because a launch goes out into the world and escapes the controls doesn’t mean you have no way to manage the risks and downsides of failures. The simplest option is to limit the scope of those using it to a small group. This can help unearth problems in the details that are likely easy to address once you know what they are. Another mitigation is to keep redundant processes in place while you try out a new one. For example, at PG&E when we released apps for the workforce to use to inspect equipment, we kept the old paper processes in place for a few months so we could compare the two sets of data we collected to make sure we were getting the same, correct data with the new tools.
By understanding how complicated your problem space and solution space is, you can figure out how broadly you should cast your net when developing ideas. You can visualize this as the intersection of risk (i.e., the chance that you’ll choose a bad solution) and consequences (i.e., the material damage done by mistakes or inaction), as shown in Figure 5-3.
Figure 5-3. Mapping out complications versus risk in your effort helps you plan
Figure 5-4 shows how teams can manage risks and consequences by structuring their time in the form of experiments and launches to try things out and understand how well proposed solutions work.
Figure 5-4. Connecting risk and consequences to experiments and launches
When you are dealing with ideas in the lower left, quadrant 1, there’s very little chance that you will choose a poor solution, and if you do, the consequences are low, so you may not have to spend very long looking for a breakthrough idea. Likely there are well-known patterns you can learn from and test out. For example, driving traffic to a new feature may take a few A/B tests to work out specific wording or color choices, but it won’t cause catastrophe if you haven’t yet optimized it.
On the other hand, if you face a high risk of not finding a good solution and the consequences are dire, as they are in the upper right (quadrant 3), you’ll need to do enough exploration to drive down that risk and uncover some insights to learn what makes better or worse solutions. For example, creating a new heads-up display for use in mining operations has safety and cost concerns that mean you’ll need to take time to test out what works and/or learn how to reduce the negative consequences of mistakes with safety implications.
Most collaborations are likely to find themselves in the other two quadrants. Something that has high risk, in that no comparable solutions have been identified, but won’t have a ruinous effect if it fails (quadrant 4) can be explored quickly by the team, because you can move to testing with the audience to get “real-world” data about what’s working. For example, developing early capabilities that can augment a product offering might be worth the team spending a few cycles “dogfooding,” or working out kinks, before
launching to customers in a trial.
If you’re looking at a problem with serious consequences, but where the path to a solution isn’t risky (quadrant 2), you’ll want to try out ideas in a safe space for a bit longer. For example, rolling out changes to an ecommerce pipeline might affect sales numbers, and rolling out a sweeping policy for a part of HR operations might affect retention and morale. Both of the areas are well understood, so the risk of making a mistake is low, but if you do there will be major consequences.
So, when thinking about how broadly you want the team to look for solutions, consider how well understood the problem space is versus the consequences of failure. Working in an incremental fashion—that is, testing out ideas as you go—helps you avoid implementing a terrible solution, and acknowledges that any solution over time will be refined and optimized for a better return. By balancing efforts to think expansively and efforts to drive down risk, you can develop a plan that will help align your stakeholders in terms of how long the effort will take, and why. This is also useful information to periodically revisit with outside stakeholders to show incremental progress when you don’t have a big reveal.
Keep in mind that these models are intended to be used transparently, with the group evaluating and deciding the details of the plan together. Resist the temptation of keeping these models to yourself to create a plan and then asking the team to sign on. The team’s trust and buy-in will be strengthened when you all develop plans together. And when those plans change—as they will—it’s easier for the group to adjust when everyone’s got the same background. The sidebar “Planning Your Effort and Understanding Complexity” shows more specifically how you can lead a group to think through the approach together.
Mastering Collaboration Page 9
