I was terrified the first time I had to teach a technical workshop. Not because I didn’t know the material - I’d been working with Selenium WebDriver for years. But because I had no idea how to get 30 people from different backgrounds, with different skill levels, all writing working code in a few hours. What if everyone got stuck? What if the software didn’t install properly? What if I ran out of time? What if nobody learned anything?
The workshop was at a conference in Kitchener-Waterloo, and I was supposed to teach people how to write automated web tests. Most of them had never touched Selenium before. Some were developers, some were testers, some were managers who wanted to understand what their teams were doing. I had three hours to get them all from zero to working code.
I spent weeks preparing. I wrote detailed instructions, created sample projects, tested everything on different operating systems. I rehearsed my presentation over and over. I made backup plans for when things would inevitably go wrong. I barely slept the night before.
The day of the workshop, I got there early to set up. I tested the projector, checked the internet connection, made sure I had water. I was nervous but ready. Then people started showing up, and I realized something important: they were just as nervous as I was. They wanted to learn, but they were worried about looking stupid or falling behind.
I started by telling them exactly what we were going to do and why it mattered. I showed them a simple test that clicked a button and verified the result. Then I broke it down step by step. I walked around the room constantly, checking on people, answering questions, helping them debug when things went wrong.
Some people got stuck on software installation. Others had trouble with the syntax. A few had questions about why we were doing things a certain way. I tried to help everyone individually while keeping the group moving forward. It was exhausting, but it was working.
The breakthrough moment came when someone raised their hand and said “I think I understand this now.” Then another person said the same thing. Pretty soon, people were helping each other. They were asking good questions about how to apply this to their own projects. They were excited about what they could build.
By the end of the workshop, almost everyone had working code. More importantly, they had confidence. They knew they could figure out automation problems on their own. They had a clear path forward for learning more.
What I learned is that teaching technical workshops isn’t about being the smartest person in the room. It’s about creating an environment where people feel safe to try things, make mistakes, and ask questions. It’s about breaking complex topics into digestible pieces and giving people time to practice. It’s about being present and responsive to what’s actually happening in the room, not just following a script.
The preparation mattered, but not in the way I expected. Having backup plans and detailed materials was important, but the real work happened in the moment. I had to read the room, adjust my pace, and help people when they got stuck. I had to be comfortable not knowing everything and willing to learn alongside them.
The workshop opened doors I didn’t expect. People reached out afterward with questions about implementing automation at their companies. Conference organizers asked me to come back. I built relationships that lasted years. But the biggest impact was on me - I realized I actually enjoyed teaching. I liked helping people understand complex topics and seeing that moment when something clicks.
What I ended up doing was treating the workshop like a conversation rather than a lecture. I focused on creating a safe space for learning, being responsive to what people actually needed, and helping them build confidence through small successes. The technical content was important, but the human element was what made it work.
I tried to capture my learnings in a guide for myself and others who want to run technical workshops.