Design Sprints started at Google. Design teams used this framework to solve critical business problems and build better digital products. Because it was designers, who were the early advocates and facilitated designs sprints there is this common misconception that one needs strong product expertise and/or design skills to facilitate design sprints.
After training hundreds of professionals within the Design Sprint Academy, and running dozens of service, product and vision design sprints, we believe that being a designer is in fact, the least important criteria for defining a great Design Sprint Master.
But before explaining what makes a good Design Sprint Master we must look at what is this role all about.
WHO IS THE DESIGN SPRINT MASTER?
In the context of a Design Sprint, the Design Sprint Master is someone capable of achieving effective outcomes by guiding the team through the 5-phase process while managing the group dynamics.
A Design Sprint Master should have both the necessary knowledge, plus the capacity to transfer that experience to others, and on the other side, the ability to facilitate the team discussions and dynamics and decide the best course of action when it comes to unique, distinctive Design Sprint scenarios.
Usually, professionals like Product Managers, Project Managers, Strategists, Consultants, UX Designers, Innovation Managers, UX Leads, Agile Coaches, Design Thinkers and Workshop Facilitators are more interested or had the opportunity to gain experience with design sprints.
WHAT ARE THE ACTIVITIES OF A DESIGN SPRINT MASTER?
There are four main activities a design sprint master should do::
- Prepare the sprint
- Manage the group dynamics and the conversation
- Manage time and facilitate the process
- Document the progress and outcomes
BUT, WHAT MAKES A GOOD DESIGN SPRINT MASTER?
While there could be a lot of criteria that make a good Design Sprint Master we boiled it down to three traits which we believe are essential:
- The ability to create synergy within the team while guiding them to an effective outcome.
- The capacity to iterate and adapt.
- The intrinsic motivation to unleash creativity in others.
In what follows we will go through all three.
The ability to create synergy within the team while guiding them to an effective outcome.
We all know that a design sprint is a collaborative problem-solving process, where synergy needs to occur in order to get to effective solutions.
Synergy = when the team’s collaborative efforts produce a greater outcome than the sum or average of their individual efforts.
Experience taught us that synergy doesn’t happen by itself, by merely putting different personalities and expertise in one room, playing with post-its and following the process by the book. What happens between people is extremely important and a Design Sprint Master should manage the team interactions by:
- actively listening to their opinions and concerns,
- supporting their efforts to do well,
- allowing for debates and managing different views constructively,
- providing equal time for participation and involvement in discussions.
We define all this as managing the Interpersonal Process.
Equally important in making the synergy happen is the Rational Process, where the quality of the ideas or decision is essential. Managing the Rational Process means guiding the teams from problem to solution by using methods like:
- understanding the context,
- analysing the root causes,
- identifying clear objectives & goals,
- considering possible solutions and collateral benefits,
- visualising adverse implications,
- reaching consensus and alignment on the final decision.
We know synergy has occurred when we have an effective solution, that is both endorsed by the team and of higher quality than their individual solutions (based on Norman R. F. Maier’s classic work).
We have once entered a design sprint where there was a lot of tension in the room, caused by some recent organisational restructuring measures that led to more than 30 people leaving the company. The CEO and CTO of the company, together with some other key roles from Product and Marketing joined the sprint team. On Monday morning we could immediately sense that people were not talking to each other; they were not smiling or engaging in group discussions; they were even avoiding direct eye contact with the management. At this point, our main priority became taking care of the people, so we iterated the workshop agenda on the fly, and we used the entire morning to get to know our team members as individuals, find similarities and shared traits between them in order to re-establish trust. We created a safe space for both the management to be vulnerable and for the team to express their hopes and fears. Only after the energy level in the room raised, people started talking to each other, made jokes about the current situation, shared their mistrust and concerns, we reverted to the sprint exercises. Also, during the entire sprint, we focused on keeping the team honest and engaged, by providing constructive feedback, managing discussions and endorsing equality.
From our perspective as external facilitators, the sprint week felt like working on a minefield, making sure that no bomb goes off so at the end of the sprint, seeing the team working in unison, creating a unique concept that also got a lot of good reactions from the end-users was a great success.
A success that would not have been possible if we only followed the process by the book without taking care of the humans first.
2. Critical Thinking.
The capacity to iterate and adapt.
Facilitators don’t have the luxury to follow the rules blindly because there are no two identical design sprints, and they will start to encounter situations where the rules don’t apply, or where it’s unclear which rules they should use. A great Design Sprint facilitator should have lots of tools and methods in their toolbox and know which one to use or not depending on the situation they are in.
To give an example, a design sprint rule is that the Decider decides. But sometimes this rule may need to be broken, or even more, the Decider needs to remove himself from the sprint. So, a while ago we ran a design sprint for a 500 people product company. In our sprint team, we had two committed Deciders (present in the room for the entire week) and one sponsor making cameo appearances). During the sprint week, despite our pre-sprint agreement, some team members got shifted by the client to other priorities, and new people joined the workshop. Even more, during the storyboarding day, a third Decider joined the sprint, and he had his personal agenda. Although we tried our best to put him up to speed with the sprint methodology and mindset, as well as with the team’s progress until that point, it was a little bit too late into the game, and we realised that when we heard him open the conversation with: ‘We will start the development of the sprint prototype in two weeks from now. This prototype needs to be feasible, so our engineering team can start working on it, and it should be a valid one. We don’t have the time to experiment.’ It is easy to imagine that after this statement everyone panicked and shifted their mindset from experimenting with bold ideas to building feasible features. Everything was now about: “What we can build quickly?”.
At that point, we had to stop everything and revert to where we started. We had a talk with the Decider and explained to him the possible consequences and damage created by the development deadline pressure and asked him to remove himself from the sprint. We then needed an entire hour to reset the team reminding them about: What mindset should we have in a design sprint? Why do we test? How do we prototype? Why thinking in features will not work? Why may only one design sprint not be enough? Why is the design sprint prototype not a product roadmap? And so on.
To reach this proficient stage, facilitators need lots of experience and knowledge. No hacks or tips can replace the years of deliberate practice (workshops, team meetings, client meetings, public speaking, coaching sessions, leadership training, communication training, design thinking workshops, design sprints, actively managing a team, etc.) necessary to reach this point. Only a vast repertoire of facilitation experiences will allow a Design Sprint Facilitator to decide what is the right tool to use, course of action to take to achieve a specific goal. This quote by Pablo Picasso sums it up quite well: “Learn the rules like a pro, so you can break them like an artist.”
The intrinsic motivation to unleash creativity in others.
All the skills and abilities mentioned above are indeed crucial in differentiating an expert facilitator from a novice, but beyond skills and knowledge, we need to also look at the intrinsic motivation that drives a person towards mastery, towards getting quality outputs.
If we were to quote Kai Hailey, Lead of Google Design Relations and Sprint Masters Academy, who trained over 1000 googlers as Design Sprint Masters, she wouldn’t recommend for this role only UX designers, despite their fantastic design skills and vision. She would recommend the ones passionate about unleashing the creativity in others, the ones getting energised by seeing others work together, the ones focused both on soft skills as well as on getting quality outcomes.
Now if we zoom out, we can see how all the three abilities mentioned above revolve around one single trait: empathy. By merely being empathetic a Design Sprint Master can set up the right stage for a sprint, can sense what the team is going through during the process and adapt accordingly, and recommend the correct course of action after the sprint.
Of course, understanding the process and knowing “what to do” and “how to do it” is essential, and we consider this as a prerequisite for any facilitator.
And now, to answer the question: “Is Design Sprint Facilitation reserved for Designers?”. The short answer: Absolutely not.
“Can designers be great facilitators?” Absolutely yes, but so do other people with different roles, that have a strong understanding of the process and score high for the three traits I explained in this article.