Mastering Collaboration

by Gretchen Anderson

  Part IV. Communicating Clearly

  All can go well in a collaboration, with clear objectives, productive participation, and meaningful exploration of ideas, only for it to fall apart when exposed to outside forces. You can’t expect people who haven’t been involved deeply—or at all—to blindly accept information about where you are in the process, what you’ve learned, and what’s working. This part addresses how to handle both formal and informal communications to reduce friction due to misunderstandings or poor memories.

  Chapter 10. Communicate Transparently

  In Chapter 9, we looked at the virtues of finding out what others, especially the end users, think about your work in order to make it better. In this chapter we’ll look at how sharing also extends to communicating progress with those stakeholders and others who need to know what’s happening and what to expect. Keeping a large, diverse, and potentially distributed group working well together requires that everyone have a clear view of what’s transpired and where you’re headed. Communicating clearly doesn’t have to mean spending a great deal of time creating status reports, however. Instead, if you take an approach of having the right view (at the right level) into the work actually being done, and showing work in progress, you’ll build trust and reduce anxiety among those who are interested in the effort but not focused on it full-time.

  It can be scary to put all your cards on the table, especially if you exist in a culture that tends to regulate and gate-keep information as a matter of course. Many management structures, especially in large organizations, exist specifically to screen, package, and transmit data with the idea that it helps build a higher level of understanding. Whether or not this actually works is a topic to be debated elsewhere, but when it comes to teams working across silos and functions, relying on typical lines of communication is counterproductive since often the information needs to flow against the normal currents, without packaging and with a level of detail that enables deeper understanding.

  At the 2013 Boston Marathon, two improvised explosive devices detonated, killing three people, causing serious injuries, and creating mayhem in a crowded area as runners all pushed toward the finish line. John Simpkins, the Executive Director of the Transformative Health Institute in Greenville, South Carolina, was one of the participants that day, and he says what he found reassuring as he and others were held at a safe distance was the consistent updates and communication from race organizers about what was going on. “Even if the message was, ‘We don’t have new information, but when we do, we will let you know,’ that went a long way,” he told me. Just as we prefer knowing that our flight will be delayed by 30 minutes versus anxiously wondering if the flight will happen at all, those in even the most command-and-control environments value knowing that the situation is being handled over wondering what’s happening. When we don’t keep people updated, they fill the void with their own projections and assumptions.

  Simpkins takes this approach in his own work, leading many large teams to transform health care in the Greenville community. His organization not only runs hospitals and health clinics, but also engages community organizations and patients, and runs a medical school in conjunction with the University of South Carolina—all with the mission of delivering preventative care as close to patients’ homes as possible to improve the health of people across the community. He feels that the only way to drive a mission that large is to make sure that he is completely open about what they are trying to achieve, and how they are performing. “If you don’t provide a view into what’s going on, other messages will fill the void,” he says, even if that feels challenging at times. Health care is a topic that touches everyone in the community, and transforming the way it is delivered—from a reactive, ER- and hospital-focused model to a preventative, patient-focused one—can’t be scoped down and contained. His mission is as much to transform the culture of how health care is perceived as to deliver it.

  Simpkins learned to value transparency as a key to culture change when he was in the Office of Management and Budget under President Barack Obama, where he watched initiatives like the United States Digital Services (USDS) take shape. The USDS has changed how the government creates and maintains tools to support everything from the Veteran’s Administration to the IRS, relying less on outside government contractors for such services and helping the government “do for itself again.” This mirrors the journey of many companies who similarly are looking to develop more innovative solutions and fewer Band-Aids to problems as our society becomes more networked and interdependent.

  This chapter looks at how you can communicate more openly to support efforts at scale, and to drive larger cultural adoption of a collaborative approach. Transparency means being able to share work as it happens, with clear context, in a way that reduces the overhead of communicating. When the team runs into the inevitable rough patches in the effort, their tendency can be to shut down communication and try to hide the struggle. Learning to be transparent even in those moments is one way to help change the culture in an organization to be more open and trusting, rather than relying on silos and barriers to hide perceived imperfections.

  Transparency Supports Collaboration at Scale

  Matt LeMay, author of Agile for Everybody (O’Reilly), pointed out to me that some companies claim to be very transparent and collaborative, and even run individual feature teams who are very effective at cross-functional collaboration and sharing at the team level, but struggle at scale to carry that collaborative approach across teams. You can see this played out in fragmented service experiences, or products with features that don’t interoperate well. As each team works effectively on their own, there’s less incentive to communicate with others because it’s seen as distracting from what makes them a “high-performing team.” Management may find it hard to curtail this behavior, because the worst offenders are often the teams who are hitting their marks. I’ve found that it’s just as important to pressure the teams who deliver well to slow down and communicate more clearly as it is to support teams who struggle to deliver outputs. Transparency about what is happening and what’s working (or not) is key to realizing big outcomes the organization wants to see happen. Teams who prioritize delivery over communicating across interdependent efforts will continue to deliver Band-Aid solutions, even if their Band-Aids might look better than the old ones.

  When done well, real transparency communicates a coherent vision or plan, even all the way out to customers or users. Blair Reeves, coauthor of Building Products for the Enterprise (O’Reilly), calls out Adobe as a stellar example of transparency done well. Adobe routinely publishes plans for each of their product lines publicly, even if the information inevitably changes. This transparency helps keep their many interrelated product offerings clear internally and among their customers, who rely on the suite of products to create their own complex products and services. Reeves compares this approach to companies like Oracle or Salesforce, where, through acquisitions and growth, their offerings have become a sprawling set of capabilities that customers implement to solve individual problems, but never achieve the promised outcomes of improving the way the business works overall.

  “More Is Less” Communication

  Many people balk at the idea of being transparent not simply because it feels risky, but because it also feels time-consuming. This is understandable. When teams are working hard to deliver results, they can resent being asked to account for what they are working on, seeing it as a distraction from just getting the work done. Having to be “transparent” may seem like an additional burden that no one wants to take on. Feeling exposed and under the microscope can be draining, and once a team has a cadence together, it can be tempting to retreat into seclusion and start simply sharing that “everything is fine, nothing to see here.”

  To address this reluctance, it’s worth looking at how expensive more typical status reporting really is. Most large organizations I’ve seen focus on standardized reports of different efforts, with so
me sort of “traffic light” rating system for how each is doing. Projects are given a green light when everything’s going according to plan, yellow when issues are arising, and red when the work is behind schedule. There’s little effort spent on showing what the team has done, and more on convincing others that the work is going just fine. The problem is that very often efforts show up on a dashboard as green, right up until the moment they turn red. Because status reporting forums are generally not troubleshooting forums, there’s little incentive to rate the effort as “at risk” until it’s too late to hide the problems. The sidebar “Template to Communicate Status” outlines a more effective alternative.

  I’ve found that when you broadcast work more openly, you spend less energy communicating overall. This doesn’t mean spending a whole lot of extra effort writing reports and holding status meetings. Instead, focus on always making key context and progress visible, either physically on walls or via tools like Slack and wikis. Teams should share their objectives, assumptions, work in progress, and key learnings not only for themselves, but also so that others outside the effort know where to find information when they want it, rather than relying on packaged status reports and status meetings. By grounding everyone in the content of what is being worked rather than the meta-level status, you increase the bandwidth of communication and instill a deeper understanding, all with less effort.

  Tools to Help Communicate: Template to Communicate Status

  Rather than relying (only) on traffic light signals of the health of the effort, it’s better to frame the work in terms of where it has come from, and show what has actually been done. The outline in Figure 10-1 is one I use to keep communication of progress clear and crisp.

  Figure 10-1. A template to help you keep people updated clearly and simply

  Not every effort lends itself to showing “work.” Sometimes the status is more about how metrics have moved, or about developing infrastructure that on its own isn’t compelling to show. In those cases, you should describe the progress in terms of what has been achieved, rather than what was done. “We consulted 14 experts,” or “We completed an audit of our unit,” isn’t as compelling to share as, “We found three key problem areas during our audit and consultations.”

  Be Transparent in Multiple Modes

  When your teams share information, make sure to do so in several different ways for different people and circumstances. I’ve seen teams who post information to a wall near where they work and consider their work done. While that’s a great practice, consider that not everyone will know to look there or, especially with physical artifacts, be able to “swing by.”

  Emailing regular, brief recaps (one page max) of what the current objectives are, what’s being done, and what’s been learned is one way to keep those who aren’t an everyday part of the team updated on what’s happening. It’s a low-bandwidth communication channel, so it won’t give them deep appreciation or clarity, but it will give them the basic talking points about the effort.

  Having a regular day where the team shares their work (sometimes called a “demo day”) is a better way to give those who are interested a closer look at what’s happening. You can do this both in person and over a video call, or even record it for those who can’t be there in person. I suggest that you reserve a 15-minute block at the end of each session for questions, rather than letting people jump in while the team is sharing their objectives and learnings. Hold this meeting every few weeks or once a month, rather than having sporadic reviews when you feel ready. The regular cadence means that over time people will learn that you are always sharing, so they won’t worry if they miss one. It also models being transparent for those who are used to reviewing only “finished work.” Framing this get-together not as a “review,” but as a view into current work and assumptions and a chance to ask questions, is critical. If you have work that doesn’t “demo” very well, like some backend coding or basic research, all the better. The idea isn’t to “sell” work here, but again, to give everyone a view into the work.

  Posting work to walls or a shared wiki is a good supplement to the demos. Again, this isn’t about packaging things up neatly. Posting a video or other recording of the demo day goes a long way. Remember to always preface what’s being shared with a concise statement of what the work is focused on, how that’s changed, and what assumptions it’s based on. Over time, it might be tempting to think that everyone knows this information, but don’t stop including it. Those who are familiar will skip it, but others will need the valuable context to avoid the “swoop and poop” approach (see Chapter 7) in their response.

  Troubleshooting Transparency

  Communicating “meta-level” information about the team’s progress and status need not take a lot of time and effort, but it can run into roadblocks. This section covers a few common challenges teams face, and ideas about how to get past them.

  The Trough of Despair

  Over the course of my career as a consultant with hundreds of clients in different industries and with in-house teams, there’s one challenge that stands out in every collaboration. Somewhere, just after the excitement of starting an effort and the rush of learning about the problem, but just before a clear answer has been found, lies the “trough of despair.” This is where those who aren’t close to your efforts, your clients, your stakeholders, your boss, all start to wonder, “When will they have this solved?” Managing expectations during this stage feels scary, so the tendency is to hold back rather than be transparent because you have “nothing” to show. This is a great time to practice being open about the fact that while the effort has taken off, it’s not landed anywhere yet. I used to joke with my teams that we should make sure to “schedule the fight” with our stakeholders and just get it over with. It’s that consistent.

  So what can I do?

  Don’t fight it

  Plan for a dust-up with clients or stakeholders at the moment when you’ve finished up the research and preparation, but don’t yet have the answer. Anxiety about the situation is natural, since whoever gave the project a green light probably stuck their neck out and now they’re wondering if they’ve made a mistake. Trying to alleviate their anxiety with all of your analysis and findings about the problem is unlikely to help, and often makes the situation worse, as they see the focus as misplaced and just want you to get on with it. Just as you tolerate conflict in a team, learn to help stakeholders be resilient in moments of tension to break through.

  Include the anxiety-ridden

  If you are facing serious pressure from stakeholders and clients that you can’t just breathe through, try holding a session and inviting them into the collaboration to generate ideas, instead of trying to present findings you don’t have. Robert Bales of McKinsey Digital taught me to intentionally leave misinformation and blanks in materials at this point, just to give his stakeholders something to “fix” and be transparent about where you are. This approach also means you can enlist these potential problem people in brainstorming the solution. One thing to consider is whether this working session is best done in a more intimate setting, or if your stakeholders need a more public forum to be seen weighing in.

  Entertain the obvious, but keep pushing

  If there’s a predictable, and maybe problematic, solution facing you, now is not the time to dismiss it entirely. You can certainly keep it in the consideration set, while still looking for other options. Arguing that the only lifeboat your stakeholder sees in the ocean isn’t quite right won’t do anyone any favors. It can also be hard to move people, especially a small group, off of a default idea.

  Sharing What Happens, Not What Matters

  So often, I have sat through hours of a meeting, only to find a play-by-play of the entire proceedings awaiting me in my inbox. The exhaustive style of note taking seems intended to serve those who weren’t there but need to be kept in the loop. However, in all of that noise, signal gets lost. And those who weren’t there are unlikely to understand o
r need all of the detail of a transcript. Instead, the meeting is usually held again to bring everyone up to speed on what really matters, key decisions, and open issues.

  This problem isn’t just limited to meeting notes, either. When you’re posting work and showing progress, it’s less about sharing all 75 ideas that the team explored, or verbatims from research participants, than about what the key deciding factors were or what was learned from the participants.

  So what can I do?

  Summarize together

  When everyone is tired after a few hours of togetherness, it’s tempting to split off without fully concluding and summarizing what happened. If your recorder is struggling to synthesize the group’s work, make sure not to skip this step. Many meetings already conclude with “Let’s go through next steps,” even when the next steps are evident or completely unknown. For your collaborators, use that last 15 minutes to instead collectively answer: “What did we explore? Why? What did we conclude? Why? What do we still need to know?” Rather than focusing on action items, this reinforces a learning culture over a doing culture, when needed.

  Focus on framing

  Just as I’ve advised elsewhere in this book, whenever you are sharing work with those outside the team, don’t assume they have the context of the problem being solved or the objectives, especially since those have likely evolved. I find that once you have a crisp way to frame the work, it becomes simple to post, say, or send it as a preface to ground the audience.