Over 20 years ago Steve Jobs uttered the words, “You’ve got to start with the customer experience and work backwards to the technology.” Some point to this moment as the birth of Design Thinking or Human-Centered Design.
Rituals and Routines: Interview with Mary and David Sherwin
Looking to improve how your teams work together? Create shared rituals. We talk with David and Mary Sherwin, authors of Turning People into Teams, to find out how.
David and Mary Sherwin are design professionals who offer coaching, advising, and training services together at Ask The Sherwins, LLC. Both currently teach at the Copenhagen Institute of Interaction Design and they have an extensive background in training for both design thinking and improving cross-functional teamwork. Most recently, they’ve been working with Philips Oral Healthcare, Google UX Community and Culture, and Eventbrite.
Mary and David Sherwin
We’re really excited about their brand new book Turning People into Teams: Rituals and Routines That Redesign How We Work. It’s a practical guide to creating rituals to build better aligned teams, something we value greatly here at MURAL.
Our Head of Customer Experience, Jim Kalbach, caught up the Sherwins to discuss more about rituals and routines.
JIM: Congrats on the book! What's the basic premise in a nutshell?
Sherwins: Shared rituals and routines are what turn people into teams. When we say rituals, we’re not talking about fluffy team-building activities. Instead, we’re talking about rituals that ask for input from each individual and shape it into a shared point of view, from start to finish of projects.
We think that every team should have the ability to transform their day-to-day experience of working together, and this book has dozens of rituals to help with just that. While many of our experiences have come from working on innovation teams, what we’re sharing in the book doesn’t require working in any particular process or methodology.
In almost all the rituals, every team member's input is captured and shared visually, in a flow that moves from individual perspectives to group decisions. The visual outputs are simple enough to be drawn on a whiteboard or a sheet of paper, or in a shared digital document.
"...they can point at a shared document and say: This is our team’s point of view, and we made it together. There’s a different kind of ownership that comes from that act, because each person was heard throughout the process."
JIM: We like sharing things visually here at MURAL. 🙂 Can you tell us more? Why is visualizing work together so important?
Sherwins: First, there’s the assumption that if each person gets a chance to speak in a team setting, we’ll remember everything that was said and be able to work with that information. But the human mind isn’t built like that. There’s a limited amount of information that we can take in and store in our working memory. If you don’t write things down as you go, then everyone will remember what happened differently—or forget what was discussed entirely!
Then there’s buying into the team’s direction. One of our mantras with teams is this: Everyone has a voice and a choice. Every team activity we create starts with individuals writing down their own ideas and perspectives, and getting equal time to share that information in a visual and a verbal format.
From there, the team clusters and prioritizes that information so agreements and tradeoffs are always visible. That way, when the team is done with their activity, they can point at a shared document and say: This is our team’s point of view, and we made it together. There’s a different kind of ownership that comes from that act, because each person was heard throughout the process. And if they aren’t getting their way, they know the reasons why.
JIM: That’s powerful. What other benefits does visualizing work have for teams?
Sherwins: Visualizing work for team activities has other big benefits if it’s done as part of a well-run activity. It can help reduce the influence of cognitive biases on team decisions.
For example, let’s talk about a bias called anchoring. What this means is, whoever speaks first in a team conversation causes everyone to weight their contribution according to whatever was said first. We see this happen in brainstorming a lot, where the first idea that someone throws out in a conversation ends up receiving more support at the end.
A team can evaluate their ideas more equitably if they’re visualized in a consistent format. Teams just need to make sure they also provide equal time for individuals to share their ideas. In the book, we put a lot of thought into how to pair these things together, so teams could yield the benefit.
JIM: Great points. But what if your team is remote? Does anything change in terms of your advice?
Sherwins: Remote teams actually have a slight edge when it comes to the power of visual output, because all of the assumptions found in what they created. In-person teams rely more on talking things out, which is difficult to track, while remote teams are already accustomed to using tangible outputs to support themselves.
A lot of the work we do with in-person teams is encouraging them to put the same time and energy into documenting their assumptions in the way that remote teams do. When there’s an output, it helps the team hold itself accountable.
"A ritual needs a team to be there with intention, for a purpose greater than themselves."
JIM: Fascinating. It's not often you hear that remote teams have an advantage. So, what's an example of documenting assumptions, as you say, and how is that a ritual?
Sherwins: There are a lot of different types of assumptions, but the ones that we run into the most revolve around user-product relationships. Teams assume that a user expresses wants or needs in a particular way, behaves in a particular way around that want or need, and that a product or service must respond to those wants or needs in a particular way. With every decision, a team internalizes each part of that relationship, so you have to pull it apart piece by piece.
You can’t really wait around for one of your engineers to have a brainwave in the middle of night thinking, “Wait! We’re assuming that people want to receive notifications. What if there were no notifications?” and hope that they remember that long enough to bring it to the team. A team needs a way to build a space to entice and capture those brainwaves. A ritual gives you just that - a time, a place, a team that chooses to engage together, and a visual output to track what you’ve learned.
We have a ritual in the book that’s specifically about assumptions, starting with documenting what the team already knows and what they need to find out. But the ritual doesn’t have to exist in rarefied air. It can be part of a larger ritual, like critique or feedback sessions. Without a ritual, those assumptions never get explored. They stay in the dark and grow… and not in a good way.
JIM: Can you describe the assumption ritual in more detail?
Sherwins: Each ritual in our book asks the team to work individually first before working together. We’ve found that’s the best way to ensure that everyone gets to speak and that everyone gets heard (which are not necessarily the same thing!).
For the assumption ritual, it’s a very basic setup. We modified our ritual from a process we learned from Twitter’s Mike Kruzeniski. You have a diagram with two columns, one for what the team knows and one for what the team needs to find out. Each person individually lists all the things that the team knows in the left column and then lists all the things the team needs to find out on the right.
You can have the team focus the lists if you want as well. For example, the team is listing everything that they know about the user or about the project outcomes or about current product functionality. Functionality is a great one for capturing brainwaves, while looking at users can spark a lot of discussions around research.
Then you pool everyone’s input on the diagram and discuss it, starting with the left column. The key question: how do you know this information is true? This is the chance for the team to pool their knowledge; some people already have the answers that others need. If there’s anything from the first column that you don’t actually know with confidence, you move it to the right column. Everything remaining in the left column is an assumption that the team is comfortable moving forward with.
The content on the right needs to be prioritized and the team can plan how they’re going to find out what they don’t know. You can refer back to these columns at any stage of the project, any time you get new information. You’ll move things from the right column to the left, and they’ll become new assumptions.
JIM: At the risk of opening a semantic can of worms, what makes it a ritual and not a principle or method?
Sherwins: It’s absolutely a can of worms, but it’s worth exploring. We say ritual because principle usually doesn’t have a process; principles lack applicable specificity and there’s no output. Methods are similar to rituals in function, but for us there are a few key differences. Methods are means and ends, they can function without a team, and they’re much harder to adapt for your needs. Methods often work in a way that allows people to abdicate responsibility; they just point to the process and it does the work for them. A ritual needs a team to be there with intention, for a purpose greater than themselves. They can choose to adapt the steps as they need, and they design that experience. Each time they do a ritual, there’s a useful output that they built together.
We talk a bit more about this in an article we wrote recently. The term has a religious connotation for some people, but it doesn’t have to be that way. A bar mitzvah is a ritual, but so is Taco Tuesday.
JIM: Great stuff. Just got your book and looking forward to digging into it more!
Get your copy of Turning People into Teams: Rituals and Routines That Redesign How We Work here.
Jim Kalbach is a noted author, speaker, and instructor in customer experience, experience design, digital transformation, and strategy.
October, 17 2018