How to Facilitate a Technical Workshop Using the Techniques of Design Thinking

I was recently asked to facilitate a technical workshop that, over a couple of days, would define an architecture and dive into how to build that architecture.

My first reaction to this request was, why do I need to be there? What can a designer bring to this sort of discussion? Beyond the crafting experience, I thought, I have so little to offer my fellow architects that will help them turn that experience into working code.

This led to the next question: would my usual bag of design thinking activities work for such an engagement? How was I going to get the other architects to the expected outcome of a new architecture and the starting points of building that architecture?

Over the course of the workshop, my thinking changed dramatically. I learned that, in addition to my skills as a facilitator, I can provide a valuable point of view on how the architect’s decisions might impact the user’s experience. I realized that many of the core principals of design thinking apply to this experience.

Design thinking concepts such as collecting everyone’s ideas, diverge and converge, write more than you talk, and timeboxing the discussion work just as well with a technical workshop as with any other workshop. You’re not creating empathy maps or writing needs statements, but the methods used to create those artifacts can be leveraged to achieve similar results. One other thing I learned: you need to do your homework before the first day of the workshop.

Do your homework

Typically, we run workshops for our team or a team in our group of offerings. We start with a certain level of familiarity with the subject matter and the people that interact with those offerings. In an engagement like this technical workshop, since the workshop goal is to dive deeper into the technology, you need to dive a little deeper as well. You’ll want to, at a minimum, understand the language and terminology. Ask the lead engineer what information they feel is relevant before the workshop. In my case, the engineers created a list of education materials for everyone attending. The workshop brought domain experts from different areas of the platform together, and we needed a common starting point. Each expert was asked to contribute to the list of education topics as well. The education materials helped remove many of the assumptions about what people knew about the topic under discussion, in addition to helping us dive a bit deeper.

As for your contribution to the homework assignments, focus on the user’s experience. Provide links, videos, prototypes, or drawings that will support the conversation. Look for similar interaction patterns that users will encounter in their daily life. YouTube videos and online tutorials are excellent sources of this information. In my case, we were looking at container creation and usage, so I made sure the education list contained links to techniques and methods that dominate the market. This education led us to the starting point for the discussion.

Start with an experience

The goal of most design thinking workshops is to create an experience by mapping out the current and desired future state. When, as in my case, a description of a desired future state doesn’t exist, ask the team to develop a To-Be map or user journey before the workshop. Creating the experience map can be the hardest part of facilitation, since the team might get off track trying to jump into the details. If that happens, you’ll need to continually remind participants of the meeting goal and bring them back to the activity.

The reward of taking the team through this activity can be building empathy and creating a sort of conversation guide. The map will give everyone clear direction on what to discuss, when to address details, and will provide a way to keep the group on track. For example, say you start talking about file system isolation but suddenly end up on the topic of orchestration. You can point back to the map to show that you’re not ready to cover that topic yet. Place that question in the parking lot so that you can get back to it when appropriate. Remember to print out and hang this artifact in the room to use as a reference.

Hosting the workshop

Since this is a technical workshop, do we just dump design thinking techniques? No, they just take on a different form. I started each topic area with an ideation, issues, and questions map. Yes, I mixed the three concepts in one activity — this allowed participants to express everything in their head that was related to a topic. The outcome of this 10-minute activity was the points of discussion. After the 10-minutes of quiet time, I asked a participant to playback the board. This didn’t always speed things along, since some things on the board needed further discussion. However, the group of architects kept surprising me.

In one round, a participant mapped out a little scenario on the topic, causing other participants to expand on the steps. They even started bringing the conversation back to the personas, prompting each other with questions like, ‘Would Zach, a system architect, allow Deb, a developer, to make that change?’ Another surprise was that, when prompted, the architects documented their assumptions and questions to ask the user. This was great information for the design team to follow up on, and to better understand how architectural decisions would impact the persona or the interactions between personas.

In a technical workshop, as the conversations continue, you might not understand everything being discussed. Pull a couple of participants aside during breaks to check if you are on target to meet the workshop goals. Empower those participants to speak up when things are going off track, since it may be difficult for you to tell if the group is lost in the forest again or still on the trail.

Troubles in Engineering Land

I know what you’re thinking: this guy is so lucky to have a group of architects that were willing to participate in a deep dive in this way. My response is that it was not luck but five years of hard work by the design organization. Transforming the way we work is now paying off. You may not have the same level of maturity in your organization. In that case, what other ways are there to facilitate this sort of workshop?

One technique I’ve used in the past is to let things break first before you offer assistance. First, get invited to the workshop one way or another. Allow the group to talk themselves in a circle, looking for an opportunity to suggest a better way. This can be painful to watch, knowing you can help them. It might take four or more hours for them to wear out, so don’t jump in too fast.

Start by reading the temperature of the room — how many people are playing on Facebook? How many are participating in the conversation? At a break, pull the lead architect aside and ask how they feel the team is achieving the goals. Ask how they would describe the efforts so far to the sponsoring executive. These sorts of prompts will allow you to suggest a different path. Seize that opportunity by suggesting an experiment. It’s essential to get the most senior person in the room to buy-in to the suggestion, since the rest of the group will tend to follow their lead.

The first mistake that most designers will make is to jump into some empathy-based design thinking activity. Your workshop participants are probably not ready to have this discussion — they came to talk about 1s and 0s, not feelings! The trick is to start a simple activity of spending 10-minutes of quiet time, during which everyone dumps their brains on a given topic, posting post-it notes on the wall. Ask someone in the room to play back the wall of topics. This starts to facilitate the conversation. Don’t worry too much about timeboxing, just keep them focused on getting through the Post-its on the wall. Leverage that success to spend 20 minutes mapping out a scenario, with the understanding that you don’t want to miss some critical detail. If they are not ready for that activity, instead ask them to list out the topics to discuss and continue to use that 10-minute technique.

At some point, you’ll see an opportunity to suggest creating a scenario to make sense of all topics. Either way, you’re making progress towards the workshop goal. The trick is really to meet them where they are, remain flexible, and slowly nudge them towards the goal while building empathy for the user. A colleague of mine was dubbed a hero for not making a group of architects create an empathy map. Fast forward 10 minutes, and, while working on a scenario map, they all started talking about the user’s thoughts and feelings! You never know what is going to make it click, but it will eventually click.

By the end of the workshop, the team will have achieved the goal and will appreciate your efforts in guiding them. You’ll be remembered as the person who brought order to chaos, and the group may be more open the next time to leverage some other design thinking activities. They may even ask you to assist with planning their next workshop.

Wrap Up

Leading a successful engineering workshop is well within your grasp. Keep these things in mind:

• Start with doing your homework so you can understand at least some of the conversations.
• Create and leverage a user experience map to facilitate the discussion during the workshop.
• Use the principles of design thinking to facilitate the discussion during the workshop.
• Remain flexible.
• Check-in with key leaders throughout the day to verify that you’re making progress.
• Remember to wrap up by listing the next steps and assigning owners, so as not to lose momentum.

Before you know it, the team will have achieved the workshop goal and your efforts will be rewarded. Good luck with your next engineering workshop!

BJ Scheid is a IBM Distinguished Designer at IBM based in San Jose, CA. The above article is personal and does not necessarily represent IBM’s positions, strategies or opinions.