Mastering Collaboration

by Gretchen Anderson

  Establish team norms

  Establishing team norms about things like when meetings will be held, or what the definition of “done” is, is a key practice. For managing conflict, it can be good to discuss and decide what the team considers healthy, and not, when facing a conflict. I’ve seen norms such as “Ask for explanations over offering attacks” that are the result of a diverse team striving to be inclusive of different views.

  Work asynchronously.

  Some conflict arises when people try to do too much all together. Keep an eye on people’s energy levels, be aware of those who may do better work on their own, and then come back to share and critique. Make time and space for people to be away from one another and keep their discussion focused on the content of work and decisions.

  Conclusion

  Collaboration at its core is about including diverse perspectives and people. Being inclusive makes teams stronger; you have more to draw on and get more people invested in the success of the effort. But groups often need help bringing their differences together productively. You can help teams be open with each other and develop shared norms to govern behaviors. You can also model what respecting differences and healthy tension looks like so that the group doesn’t just stick to what’s “safe” because it’s easier. In the next chapter, we’ll look at how to give people clear roles to channel their energies and contribute to a healthier environment.

  Key Takeaways

  Being inclusive of many different kinds of people, skill sets, and perspectives is a core part of collaboration that helps mitigate risks, engage the team, and find blind spots before they become a problem.

  Inclusivity can challenge the status quo of how people interact and may bring about interpersonal conflicts that are destructive to the team.

  Working in different cultures that aren’t naturally conducive to collaboration is challenging, but don’t get caught up in making changing the culture your mission. Instead, focus on practical, tactical changes that create a local space for teams to be productive and deliver results. Culture change will happen as a by-product of good results over time.

  Chapter 2. Give Everyone a Role

  In the last chapter, we looked at how encouraging diversity in a team helps generate and test ideas more easily and quickly, but can bring up conflict in some cases. Establishing clear roles for people helps channel their energies and can reduce unproductive tension around different responsibilities. In this chapter you’ll learn how to approach assembling different collaborators, and how to use explicit roles to channel different skills and impulses.

  Christina Wodtke, founder of Balanced Team, points out that “we know how to channel people from a skill set perspective—designers design and developers write code. But, if nonfunctional roles aren’t delineated, there’s guaranteed to be conflict.” She says clear roles deal with things like, “Who makes decisions? Who brings what perspectives? Who’s able to facilitate openly? Who will plan and track what the collaborators do?” Wodtke also acknowledges that roles are never a set piece that can work anywhere. “Different collaborations will have different shapes,” she says, calling up classic comic book collaborations as an example. Stan Lee and Steve Ditko, pioneers of comic book creation, approached writing and drawing together as two equals with different skills building one thing. Sci-fi and fantasy author Neil Gaiman, on the other hand, will turn over a full manuscript for a graphic novel without really having thought much about what the visuals should or would be. Both approaches clearly result in quality output, but each is suited to the individual collaborators.

  There are some conventional role definition frameworks that can be used/adapted for collaboration success, as well as some roles that don’t typically get called out in such frameworks but are critical nonetheless. At the end of the day, roles formally establish authority and scope in a way that the whole team can share. The importance of roles lies in their ability not only to channel power dynamics, but also to create growth opportunities for more junior team members or people looking to expand their skills.

  Next we’ll look at how roles help channel people’s energy and clarify boundaries and responsibilities within the team to keep everyone focused and productive. Roles should be defined both for those who are fully focused on the effort as well as for stakeholders and experts that advise the team. Roles aren’t like job functions that are stable; over time, you may find that they can shift to give people different experiences.

  Levels of Contribution

  When you are enlisting everyone, as we looked at in Chapter 1, there is a time and place for many people to participate, but there are also times when it’s more appropriate for a smaller, core group of people to dive into solutions. It pays to be clear about different levels of contribution, as shown in Figure 2-1.

  Figure 2-1. A model for understanding different types of collaborators

  At the center of this model, you have the inner circle of close collaborators, who do the bulk of the heavy lifting. This is where a few people who are very close to the problem explore ideas and develop them to be tested. These are the people who are focused on the problem fully, and who have the diverse skills needed to create solutions for it. The roles here need to support a balance between exploring divergent ideas and converging and testing ideas in a way that is traceable and transparent.

  Surrounding the close collaborators are highly interested stakeholders, who are collaborators in the effort even if they aren’t directly responsible for delivering the solution. In other words, these people are affected by the outcome of the collaboration but aren’t actively participating on a daily basis. They might be people who manage a critical function or effort that has dependencies or related priorities. The biggest challenge that arises here is when these stakeholders are not clear on how they are to participate, especially senior leaders who are accustomed to having their casual remarks about ideas or solutions taken as clear directives. Establishing the lines of authority around decisions and feedback mechanisms is critical.

  On the outside are onlookers who are watching your collaboration even if they haven’t been invited to participate. This may be because they are inspired by the effort, fearful of being left out, or simply bored and looking for a distraction. While it can be tempting to ignore these folks, it’s useful to make sure you are communicating to this audience so they don’t become active detractors.

  It’s important to point out that collaborators aren’t necessarily those within your direct organization. You’ll likely have to include clients, or outside partners with specific expertise. There isn’t necessarily a big difference in how people work together from different companies, but it is worth noting that their goals may be generally aligned but still not 100% the same as yours. For example, a vendor you rely on for key technology needs a seat at the table, but success for them may be selling you more product versus your end product being successful.

  The next sections go into more detail about assigning roles for those who work closely together on the problem “full time,” versus those stakeholders, subject-matter experts, and onlookers who need a different structure to guide their less frequent participation.

  Roles for Close Collaborators

  From Agile to sprints to design thinking, there’s a great deal out there about how to get close collaborators working well together. I have found that, when it comes to making use of roles, the world of pairing has a lot of value. Pair programming is a movement that started with software developers as a way to increase the quality of code and to move quickly through a variety of approaches to a problem. Pair design takes a similar approach to the architecture and overall design of a product or service. Pairing can be practiced by designers, developers, and product managers. In our book Pair Design, Chris Noessel and I look at how pairing works and show some variations of how it is practiced in detail. For our purposes, it’s less about people working in literal pairs than giving small groups of two to five collaborators structure for th
eir participation in an intimate team. The roles described next can help your team share responsibilities for working together as a core team. These roles aren’t about specific skills, but rather serve as a way to focus different people working in a small group.

  The Navigator

  Every journey needs a navigator, whether you’re heading out on a well-mapped road trip or charting unknown territory. And yet, most of the time, we think more about the driver who’s getting us from A to B than the person making sure we actually arrive in the right place. In small groups of close collaborators, you should have one person designated as the navigator.

  This role can be expansive or focused, depending on the context. At its most minimal, it involves tracking decisions and rationale and the process of how the group works. Like a lab book for a science course, it helps you make sure you have enough of a record to back up any findings you might discover. Navigators should focus on:

  Keeping track of the overall strategic direction of the work

  Documenting key decisions and rationale

  Communicating solutions, progress, understanding of context, and the problem the team is solving for

  Telling the story about how the work has progressed, what struggles were overcome, and what’s changed as a result

  When you’re assigning the role of navigator, there are several traits you should look for and actively support. This role carries a great deal of responsibility for keeping the whole together and being a credible source of documenting and presenting ideas. It can be a good role for more junior people who show promise and are looking for new responsibilities. Obviously in situations where communicating the collaboration is large-scale and critical, you should bring in people with more experience. Navigators should be:

  Detail-oriented

  Navigators must be detail-oriented and take seriously the job of keeping information for the group.

  Organized

  Navigators must be able to track (or even, in some cases, create) the course and progress of the work in order to loop in those outside the circle enough that they don’t try to undermine or solely nitpick it.

  Strong communicators

  The navigator is the natural person to be the “emcee” of the group, setting context in presentations so that other members can deliver more details about solutions.

  You can help those playing the role by making sure they have a supportive environment:

  Dedicated time

  Make sure they have the time and focus to track information.

  Real-time, transparent capture

  Encourage real-time capture and prompt synthesis. Navigators should function as the team historian, pulling together enough of what’s happened to build a story about how the team got there, not just where they arrived.

  Focus

  Help navigators focus on recording the right stuff, not all the stuff.

  The Driver(s)

  If the navigator within a collaboration is focusing on the bigger picture for the group to explore, the driver is the person (or people) working through possible solutions to the challenges within that space. There should be only one navigator, but there may be multiple drivers generating ideas. They will be holding the pen at the whiteboard, or using the keyboard to write code or draw ideas quickly. Drivers are less concerned with tracking the flow or keeping the whole picture in mind than navigators, focusing instead on developing divergent approaches to a problem quickly so that the group can evaluate them.

  Drivers are typically responsible for:

  Technical solutions

  Developing ideas and creating them (in code, on whiteboard, etc.).

  Expansive thinking

  Developing multiple approaches to a solution rather than simply homing in on one. This is where having several drivers is useful.

  Bringing expertise.

  Having more specific perspectives on the problem and solution space.

  When assigning the driver role, you are looking for people who have enough technical ability to render their ideas quickly in some medium for the pair or small group to react to. Drivers should also be able to easily come up with multiple solutions to a challenge, not zero in on a single idea and argue it. Drivers should be:

  Fluent in the medium

  Whether you are developing a new organizational model or creating a new feature for a product, drivers should have the requisite technical skills and knowledge to create substantive artifacts.

  Solution-focused

  Whether your driver(s) are extroverts who enjoy duking it out over ideas at the whiteboard, or more internal processors who need to work “offline” to generate ideas to critique, their job is to give options, not rehash assumptions or redraw the map.

  Invested in group success

  Driving is not about winning. Drivers should not be made to think they’re leading the team or competing to come up with the solution.

  Free to work in the style that suits them best

  Note that not all drivers need to be highly verbal types who think on their feet. Drivers who are more introverted may need to develop ideas on their own and then bring them back to the group to share and critique.

  It’s worth noting that, at least during early stages, this circle of close collaborators may be three or four (or even five!) people. When there’s more than a handful of people who have a great deal of trust and respect, it’s more likely that you’re workshopping ideas with a group that involves some stakeholders than actually doing deep, close collaboration. In these cases, you should be very clear about who the navigator is, and assign all others to be drivers. In a group of three or four, you might try having people work “alone, together” as Jake Knapp calls it in his book Sprint (PCC). In this vein, rather than having a pair work tightly out loud on the problem, you would have people work for a bit on developing ideas and sharing them, have a critique led by the navigator, and then refine the ideas iteratively in the group. It is a good idea to state clearly that all drivers in that setting are equals, even if there are technically more senior and more junior people in the role. As the master of collaboration, you can help the driver or drivers succeed by:

  Killing egos

  Model what it looks like to focus on group success; use group retrospectives to keep big egos in check and help others feel heard.

  Together time/alone time

  Most successful pairings I’ve seen have a schedule that might have people work closely together for a few hours in the morning, and then have them work independently in the afternoon. When they return the next day, they can check in about where each partner got to.

  Dedicated focus

  Like navigators, drivers need enough time and space to take the ideas that the pair has worked through to the next level. If drivers are spread across multiple problems, you’ll find that they resort to “swoop and poop” behavior (see Chapter 7) rather than being invested in the specific problem and pair.

  Finally, when wrangling people in very close collaboration, be aware that these roles can (and in some cases, should) be fluid. Especially later in the process when the collaboration is about specific implementations of solutions as opposed to a big vision, it can be useful to have people take different perspectives and switch often. Sometimes this happens naturally. When observing pair programming, I’ve seen two people working the same keyboard and mouse because each person is very familiar with the problem and has skills or expertise specific to solving it. There are also pairs who fit so naturally into the roles that no swapping happens. Often if one of the collaborators is a product manager or has another generalist skill set, they will fit naturally into the role of navigator and won’t have the technical expertise or fluency to be a driver. If you are filling one of the roles of close collaboration, make sure you yourself are keeping to your assigned role, and check in often to make sure you haven’t lost sight of the path you are navigating.

  Critics

  We’ve all had the
colleague who just can’t help but shut down every idea that they encounter. Whether it’s because “we already tried that” or “it’s not possible,” they’ve never met a solution they like. Their energy isn’t just annoying, it can infect the entire group by making people doubt themselves or exhaust themselves having to debate endlessly with someone who won’t engage.

  Explicitly assigning someone the critic role can turn their negativity into something productive, but it takes some doing. You must first decide when to assign this role. If you know that someone it’s important to include is likely to be a naysayer, approach them ahead of time and tell them you specifically want them to take this position. Be sure to frame it as a critical part of the process, explaining that you want to harness their expertise to find weaknesses in the solution set so it can be refined.

  If the resistance appears during the process of defining the objective or generating divergent options, you will have to try to reframe their participation after the fact, which can be awkward. I find it helpful to explain the overall process and timeframe of the effort, and be clear about when they will be called upon. You can give them a specific meeting or series with the group for them to “lead” their critiques. It’s important to remove them from the meetings where that energy won’t be welcome. I tend to say something like, “You can skip tomorrow’s session. We’re going to be doing more brainstorming, which is going to drive you crazy. Feel free to leave this part of the process to us, and we’ll share what we come up with afterward. We’d love to hear your thoughts in next week’s session.”