This article is part of the series on workshop planning. Check out the whole series!
Theory is nice, but there’s nothing better than practice, right? In this post, we’ll go through an example of a workshop plan. I’ll explain some details, and you can download the files I use and plan your own session. Let’s start!
Imagine you want to have a workshop with your team in which you discuss and agree how to work together in the future. This can be a team that worked together in the past, but has some inefficiencies, or a team with new members, or a merged team after departments were restructured. There’s plenty of opportunities out there to use this workshop format!
Setting The Goal
You as the leader will have something in mind already – otherwise, you wouldn’t consider doing a workshop for this topic, right? It might have something to do with changing the way of collaboration, maybe going towards a more agile approach. Sometimes, improving the communication both within the team and with other teams might be a focus. Depending on your goal, you can formulate a SMART goal for your workshop.
After this workshop, my team will have agreed on new working structures and communication rules. We will have formulated action items to follow up on, assigned them to owners and set clear deadlines.
This is the explicit goal of your workshop, which you can also share with your team upfront (if you want), or use as an introduction for your workshop. However, there will be several other goals you might consider implicitly.
You might want your team to start thinking about their working structures.
You might have received feedback from other departments regarding the communication habits, and you want your team to identify improvements.
Topics like this can also be part of the explicit goal, but this will set a focus on those topics. There’s a very solid reason why you sometimes should not make everything explicit: If something needs improvement or there have been problems that need a solution, one option always is to ask your team to think about them and discuss how to deal with them. The moment you do this, you as the leader gave them a task. This might work out fine, and sometimes it’s also necessary, but it will also create a meta level on which your team only talks about this because they were asked to do so. If you keep those goals in the back, and just offer the time and place for them to talk about topics that will touch these issues, the chances are high that they will themselves realize that something should be changed. In the latter case, they are the driving forces behind this. The team themselves resolved the issue, without your help and without your request. You empower your team to solve problems on their own, and they will be proud upon themselves and feel much more in charge. And there you have another implicit goal, which I like to note down for all of my workshops:
The team feels empowered to take their own decisions and to take care of their own working structures and communication rules. The team feels in charge of themselves.
This is something that you really cannot make explicit. The reason is simple: It’s about a feeling that has to come from within the team. So again, the only thing you can do to support this is to provide the time and place for your team to gain these experiences. You cannot request from someone to feel empowered; so if you make it explicit and add this meta level of My boss told me to… – you might actually hinder the empowerment of your team.
I talked about three possible structures in another post. You have to decide whether you want to go input first, discussion first, or discussion only. For this topic, all three are possible:
- You can provide input first, for example you could give them a case study of a team that started working more agile and afterwards talk about the consequences this had. When this theoretical case is discussed, you could change the topic to compare this case with your team, and ask them to work out differences and similarities. The result could be a list of changes that you want to implement in order to improve your ways of working together.
- You can start with a recent problem (maybe an issue with another team), or an open question (How would you describe our collaboration within the team?) and let your team discuss this for a few minutes. You could then identify pain points as well as strengths, and afterwards listen to a podcast about new working forms, watch a video, or read a text. You can then ask your team to identify action items to improve the pain points or get rid of them completely.
- The theoretical input in the above mentioned scenario can also be skipped; you can immediately and without any additional input to consider, ask your team to find solutions for the pain points. The result will again be a list of action items to follow up on.
I would go for the discussion first scenario. It starts with the team themselves – this usually triggers motivation and engagement. Afterwards, you provide a bit of input. This will be great for participants that like to learn new stuff and will keep them engaged and motivated as well. Additionally, you can direct your team to certain solutions without telling them explicitly just through your choice of input.
This is all you need for your basic structure. Six phases in total are great, you can already see that you have a clear red thread that guides you through the whole workshop. Of course, we’ll add some workshop standards afterwards, like warm-ups, feedback phases and recreational phases, but these are best planned when the rest is already set. The next step will be to add the horizontal layers for each topic, which we’ll tackle in the next post.