So as Iāve mentioned, Iām looking to put a workshop together this year (specifically on mental health/managing mental health in tech). Iāve not done anything like this before and so Iām wondering if there are any resources for the logistics side, as I think this will form the content to a point.
I thought yāall have some pretty good tips in your latest podcast! Things like the room setup, lights and so on are important but itās easy to forget.
That made me think of one thing that helps me, especially since I pair on all sessions. I collaborate with my pair at the start to put together a ārelease planā with milestones. We set target dates for writing the abstract, mind mapping the workshop, coming up with exercises, making a list of materials needed, drafting slides, rehearsing, when to start setting up the room before the session, what to put on the walls of the room and the tables, everything. We might use a simple spreadsheet or an online tool like Trello. I learned all these good organizing practices from Janet Gregory and it really helps prevent last-minute panics. We donāt beat ourselves up if we miss a milestone, but it helps us stay on track. Of course you can do this just for yourself if you arenāt pairing!
Some thoughts, not necessarily coherent, nor complete. Iām guessing you mean a workshop as something where a group of people work and play with an idea in mind and a goal of learning something by doing. And I expect youāre facilitating it. So hereās what I do when Iām doing that.
I plan using a circular timeline ā it helps me judge rhythms and see connections, and I find it helps me feel how something will work in context of neighbouring activities and the overall flow and energy of the full workshop.
I tend to look for some sort of narrative ā to learn means being changed, and a journey helps people to make sense of that change. Sometimes the narrative is a story, sometimes a linked set of ideas. I try to I change the space, or to encourage people to physically move, so as to stick flags in the timelines of peopleās memories. Make flipchart pictures as you go, stick them the on the walls, get people to walk up and interact with them.
I tend to to switch formats 3-4 times an hour. My usual formats include individual exercises, whole-group discussions, small-group activities and lecture-style bits. Everyone needs a break, too. If you need to hit hard timings, have a few short bits that are done in 5 minutes, and know how to reduce some of the longer activities by 5-10 minutes, too.
I try to think through my workshop, in sequence, from various perspectives; my own, various participants, various resources. Doing this helps me uncover points where the narrative breaks down, things I need to supply to the participants or to prepare beforehand, stuff that will need redundancy or backup. I try to run new bits for fun (but for real) before I get to put the whole thing together.
Iāve been meaning to write a blog post about this but Iāve been procrastinated/been lazy the last few months, with lots of unfinished blog posts!
Iāll share everything (that I can remember) that I did or thought about to prepare for my workshop:
First thing was just talking to lots of different people about my idea, the more I did this, the more I fleshed it out or came up with variations or alternatives. Whilst the learning objective of the workshop never changed, the āhowā did a lot and it mainly came from thinking out loud by explaining and discussing it with other people. I didnāt intentionally plan who I was talking to, but on reflection I talked to a mix of different backgrounds and experience both in terms of the subject matter and in terms of education/public speaking/workshops and Iām sure this helped a lot. Even if I didnāt conciously realise it at the time, I definitely shaped a lot of my workshop from those conversations. Even if it was just people saying I had good ideas, it helps my motivation to know Iām not the only one who thinks it could work.
This actually came before the first point for me, but I attended other peopleās workshops and paid particular attention to how they ran them. I made notes on their structure and timing which came in useful later as it led to me thinking about workshops in terms of timelines and difficulty curves.
Following on from the second point, I started writing rough timelines of how I think the workshop could flow. This helped me focus on the main objectives for the workshop and how much I could reasonably fit in 4 hours. I was keen to spend as little time talking and as much time having the students interacting and practicing, but balancing that with areas that I felt I needed to explain or bringing their attention to particular subtleties.
In my case, I was running a technical workshop and designing an application for it, so I made sure to finish a working prototype of the first part of the workshop as soon as possible. Partly to make sure it was technically feasible but also so I could practice it and think about how students my use it and how it would be helpful to learn with. Early ideas and versions I found were either not very fun or engaging or were too complex or distracted from the lessons I was trying to deliver. I then iterated on this until I had what I thought was more than enough content for the workshop. I guess the short hand of this is that I was practicing the workshop in small, focused chunks before I practiced it in one big go. You can ātestā the components before you ātestā practicing the whole workshop if you break it up into little lessons or chunks.
I practiced the workshop in full twice with two different groups at work. I made notes of how long it took my for each section and compared it my planned timeline. In my case, I was over the moon to find I didnāt need to make major tweaks to the content, what I delivered on the day was pretty much the same. However, I did vastly improve the quality of the delivery by practicing it, the biggest one being the paper notes I produced so that students didnāt need to take notes off of my slides. That was after I got feedback I went too fast past important information as people were still trying to copy it down.
Some general mindset kind of thoughts:
I prepared for my workshop expecting to be asked what things meant or challenged on my wording or explanations. This applies to talks too but I felt becuase you have more time with the students and because its more interactive, they hopefully feel more inclined to ask. So I tried to be fairly critical around my wording and explanations, I tried to avoid jargon and took the time to carefully explain jargon that the students needed to know. It was nice to realise there was plenty I didnāt really know and had to study (for example, I didnāt truly understand the mechanics of HTTP to explain it or I hadnāt studied the what, how and why of APIs before that closely).
I constantly tried to think about why someone would come on my workshop and why it was valuable. Am I still delivering something useful? I think this helped me avoid falling into traps where I could have built something that only I thought was interesting or cool.
How can I make my workshop more fun? Although being useful and interesting is important, I didnāt want to be boring, I wanted it to be engaging. I believe it helps people with retention if you deliver lessons with something memorable, and I choose to believe fun = memorable.
Thatās my unfiltered splurge of info, hopefully its helpful! Iām intending to write it up as a more carefully structured blog post at some point.
When I do a workshop itās for one general purpose - I want people to come to their own conclusions about an idea based on practical experience. So I prime them, then permit them to learn. Iām using emotion to enable people to learn and remember.
This means knowing, more so than usual, what experience one wants people to take away from oneās exercises. When I know that then I can put the exercises together to mirror the instructional parts, then I can use that to schedule everything. I include time for overdiscussion, argument, contemplation and whatnot. I donāt cut an exercise past the point that itās valuable - itās surprising how little someone can achieve in 5 minutes. Time is needed to get someone to try, fail, experience, learn and process an emotional reaction. I always find thereās more material than time, even for a simple subject. I usually find that people doing and talking is more powerful than me instructing, so if Iām going to cut something itāll probably be me talking at them - a point can be made better through a Socratic exercise than a slide. Talking of which itās good to have everyone talk about what they think they learned so everyone can take advantage of it, and in case itās not what you think they learned.
Oh, and pre-workshop setup is a black hole that can suck all the time and energy out of your hard work, so having spare everything, working power sockets, emergency handouts and multiple USB sticks if youāre sharing software, and calls of āI will email you the slidesā and such to save questions about it and enthusiastic slide-copy note taking, I find useful.
Oh, and donāt talk for more than a set amount of time. I canāt pay attention for very long, and Iām empathetic to my kin, so I always break up talking with exercises or pictures or I jingle my keys or something.
Hi all! Just wanted to add on to a couple things in case it is helpful.
So first of allā¦I have been lucky enough to work with @lisa.crispin and use the tactic of milestones. One thing that we tried to work backwards asking questions likeā¦āif we need to present on the 15th, when do we want to have our final dry run complete?āā¦which would then be followed byā¦āif we want our final dry run on the 5th, how long do we want to allow for edits after our previous dry run?ā etc.
Speaking of dry runs, I would say that they are so necessary (as mentioned by pretty much everyone else). It is particularly valuable to get a range of experience levels, but one trick I used for my first technical workshop was to pick the first group as a more experienced group. I knew that I needed to prioritise getting noobs up to speed, but I also felt a bit nervous and thought that someone who had some experience already could be helpful in working through some of the most glaring concerns first.
One last thing about prep, I have found that every time I am done with presenting I kinda crash. Therefore, it has been really important that I have any post workshop stuff already prepped and mapped out. Whether that be materials to give participants so they can run it themselves, leading materials on how to extend the learnings, or even reminders to self/structures to build feedback into the workshop for the next time so I donāt lose all that feedback.
As for structuring the workshop, I would agree with Matthew above that the outcomes of the workshop rarely change as I prep, but the āhowā changes a lot. I learned a lot from watching @maaret and Llewelyn Falco run their workshop on Mob Programming at TestBash NY (2015). They did a fantastic job of repeating very similar mechanics, but with deepening understanding and skills. I try and recreate this in mine as well.
The last thing I will ramble about is how to pick the take aways. I try very hard to make the topic and content project agnostic. Of course this is harder when you need to pick tech, but I find that a lot of time can be spent arguing Ruby vs Java or GCP vs AWS so if we can bypass that and get to more of the concepts that is a big win. And finally, I am looking at a way to excite people to learn more themselves. Even a full day workshop can only make so much of an impact in what people are doing on very complex contexts at work. If I can provide enough confidence that people can feel like they are on a runway towards more learning then that is a HUGE success!
Good luck and be sure to post back your own experiences
Just a quick one - I found Ash Winters Mindmap on successful workshops really helpful to look for inspiration or check if there are any areas or aspects Iāve not yet considered:
Time to time I am caught by surprise - people come to a workshop, but instead of listening and learning, first thing what they do - doubt the ability of trainer to give a workshop. But then again those most sceptic at the beginning are most thankful afterwards.
