While I’ve been an attendee and speaker at several virtually conferences recently, organising the Microsoft 365 Developer Bootcamp (ANZ) was the first time I’d really had control over how to structure and run a virtual event. We had 4 Australian MVPs involved in organising the event, we had all been involved for several years in running the in-person M365 Developer Bootcamps in different cities. I wanted to share some of the decisions we made in moving this event virtual, why we made them, and how it worked out on reflection.
Individual city events or one consolidated event?
Going virtual this year, it just didn’t make sense to run lots of small city based events since we would be repeating content and there’s no physical barrier to people travelling to attend. We decided to combine Australia and New Zealand into one event. We’d host the event targeting ANZ time zones but welcome people from any location.
How long can we expect attendees stay engaged?
With an in-person bootcamp we would typically cover 3 or 4 main developer topic areas in a full day bootcamp. This would involve a 30-45min presentation per topics and then hands-on labs in those areas where people could choose which labs they wanted to do and work through at their own pace with assistance from expert proctors. Our observations from recent virtual events is that attendees tire and lose attention much faster in a virtual format then they would in person. So rather than taking the same full day format and making it virtual, we decided to stick with presenting 4 different development topics but running them in shorter 4hr sessions across 4 days, focusing on one topic per day. We also chose not to do consecutive days, but run the sessions each Friday for 4 consecutive weeks. Trying to tap into the Friday afternoon ‘social’ unwind setting as well. The format we used was a 1hr presentation followed by self paced hands-on labs with proctor assistance for 3 hours.
How do we make the labs a success and effectively help people?
The session content
We knew being able to see the progress people are making through labs and if they are having trouble was going to be one of the key challenges. For this reason we knew that carefully choosing the labs, making sure the instructions were clear and that they worked was going to be essential. Also making sure we had enough proctors on hand to help people that required assistance. We decided to split the 4 dev topic sessions up and 1 person would lead each session and would be responsible for the presentation, choosing the lab, and generally take the lead throughout the session. The other 3 organisers would then be proctors. The labs would be shared ahead of time so all the proctors could run through and become familiar with the labs.
Providing assistance
This was going to be vastly different to an in-person experience where you could see everyone’s progress, who was struggling, what problems people were having. Largely we would be relying on people reaching out or speaking up. The attendee is in just as isolated position as they can’t see how anyone else is progressing either. Here’s a few tactics I employed during my session to try and address this:
- Try to make the session as inclusive and safe as you can. I’d pre-filled the Teams channels with welcome messages, ‘leave ego at the door’, ‘I expect problems and questions’, ‘I might not know the answers but I’m here to Google the answers with you’ type messaging, we are all here to learn myself included. I re-iterated this messaging during my presentation, it helps that I also strongly believe it!
- Give people multiple ways to reach out for help so they feel comfortable to do so. For the brave, unmute and ask, post a chat message explaining the problem, post a chat and ask for assistance (without telling others what you’re stuck on), or for those that really aren’t comfortable start a private 1:1 chat with a proctor asking for help. Make sure people know they can use any or all of these ways to communicate.
- Set an expectation for how long you think a lab would take, or a section of a lab would take. That way people will know if they are taking a lot longer than expected.
Creating engagement and atmosphere
The 1hr presentation at the start is pretty standard, keep it interesting and ensure you also set the scene for what people will be building in the labs and try to build some excitement. The challenge comes once people start the labs because it’s easy for it to be silent for the next 3 hours and people to just drop off the call. Here’s some things I tried (and feedback I received was that this worked very well):
- Once the presentation finished I left the meeting running (with everyone in it and my camera running) for the next 3 hours while people were doing the lab
- Following the presentation I invited those that wanted to start labs to go for it and I’d also take questions about the material in the presentation.
- At the end of the presentation I walked through the lab instructions but I told people I wanted to give them enough time to try and follow the instructions up until a particular point that I knew was a barrier to most developers. This gave me the opportunity to come back on and talk in-depth about something that everyone would be familiar with after trying it during the lab. This spawned a lot more questions and flow on discussion.
- Come back on and address everyone on why you selected those particular labs and what learning you hoped they would get. This in turn spawns more conversation.
- If multiple people have the same issue or problem, again come back on and let everyone know so they are aware.
- Share developer tips! Keyboard shortcuts, code extensions, whatever – it’s a great conversation starter to keep people engaged and together.
Feedback I received is that people really liked that we just had one meeting open the whole time and they didn’t have to jump around trying to figure out where they should be.
How to structure Teams with channels?
This was how I’d setup teams for my session.
General channel – the meeting for the presentation then left open all session. Chat here about anything general.
Lab (exercise channels) – People where to go to these channels and the instructions would be on a tab within the channel and any question/discussion about that lab could be had in the channel. In hindsight I think it would have worked better just having all chat in the general channel. It’s less places for the proctors to check and people would be missing out on conversations as they are hidden away in these channels.
Proctor channels – These were just if we had the need to screenshare when providing assistance. Proctor would ask you to go into the channel and use Meet Now to start a meeting then screenshare. This worked quite well.
Don’t skimp on proctors!
I’m really thankful to the proctors I had and I was fortunate enough to have few of my colleagues (who joined as attendees) help out answering questions and helping other attendees out. It took a lot more time and effort assisting people virtually than it does in person. Plan for it and don’t leave yourself short.
Keep things simple
You are going to have a lot more to deal with than you do with in-person event. Virtually you have all the issues that arise with people not being able to join, missing chat functionality, loss of audio/video. If you are doing Teams development while running a Teams meeting it can get super confusing super quickly. You will mostly likely have people joining under one Microsoft identity and doing the labs using a dev tenant identity so it’s really important that you identify these scenarios and give very clear instructions and use labs which don’t introduce unnecessary complexity.
I don’t pretend that I know the secret formula! – this was my first virtual event and I learned a lot going through the process and made a few mistakes along the way. Hopefully by sharing it you are able to take away some useful ideas.
See how it went
The recording of the presentation, slide deck and lab instructions are all available if you want to take a look.
Cameron Dwyer 