[xpost] Who needs to be involved in running a successful "Show and Tell" event for a Hackday

[This article was originally posted to the IBM internal hackday blog, but it is not really IBM specific]

I find that one of the most enjoyable parts of any Hackday is the Show and Tell event  when the hackers get to quickly present a summary of their project. Typically these events involve about 20-30 projects being presented and since it is unreasonable to expect the audience to sit through more than 1-1.5 hours of talks it is necessary to impose a strict time limit on each presentation (typically 2-3 minutes each). When most people first hear about this event format they predict that this will become a chaotic mess. This is a real danger so it is important that the event is very tightly controlled and well planned.

We are currently planning the show and tell event for the Ireland Lab in conjunction with the recent Hackday X. The main organiser was asking how many volunteers he needed to recruit and so I thought it might be worthwhile to list the various roles which are needed to help run a sucessful show and tell event. Don't be scared by the length of the list, it is of course possible for one person to fulfil more than one role during the event, but it is good to clarify exactly what you are asking each person to do and if you are lucky enough to have enough volunteer helpers it is nice to have a job for everyone so that they feel useful.

• Time Keeper: because of the tight schedule this is probably the most important role. We normally use a highly visible clock that can be seen by both the audience and the speaker so that there is no surprise when the time runs out. It is essential that no leeway is allowed because distilling a presentation down to 3 minutes is hard and if any speaker is allowed to over run the allocated time it is unfair to the other speakers whose speaking time will have to be cut even shorter (alternatively all of the speakers will assume that if the prevoous speaker was allowed to run over by a minute it is OK for them and the entire schedule goes out the window). We find that a referee's whistle or some form of a loud gong is a good way to remind speakers that their time has expired.
• Master of Ceremonies: It is important to have someone speak at the start to tell the audience (and speakers) what to expect and they should also speak briefly at the end to tell people about the judging process (see below). The MC can also help the time keeper by subtly stepping forward as each three minute time slot expires to say "thank you x for your presentation and up next we have y" - it is a very brave speaker who will continue speaking over the MC.
• Speakers: Naturally you can't have a good event without speakers, but it is important to check that you know exactly who is going to present (typically people might not want to present their project if they feel they didn't achieve anything to boast about) and in what order. Someone (either the MC or someone else) should make sure that they seek out the next speaker while the current presentation is bing given and get them to stand next to the podium. Since the allocated time is very short, a significant proportion of it can be wasted waiting for the speaker to walk from the back of the room.
• Judge(s): Normally we give out some local prizes (even if these have only a token value e.g. a certificate). This means that you need at least one judge who is taking notes and scoring the presentations. If you have a judging panel of several judges, you need to clarify how they are going to interact. Typically it is a good idea to ensure that the judges turn up anout 15-20 minutes before the show and tell itself starts so that they can discuss judging logistics among themselves.

The above roles are needed for a single site show and tell. However, in the Ireland lab we have a number of different physical locations and so we like to hold a virtual show and tell so that we can have both presenters and audience taking part from wherever they are based. This is a good idea, but it does add some additional logicistcal challenges and so you need some more roles to be filled:

• eMeeting Moderator: someone needs to run the eMeeting. In IBM we typically have a choice of eMeeting servers to use each with their strengths and weaknesses. Sometimes we choose to use an experimental version of the eMeeting service (this is Hackday after all), but if there is any doubt that the service will be working during the show and tell it is a good idea to have a backup plan in place just in case the primaty server is acting up.
• eMeeting Observer: as I mentioned it is possible that the emeeting service will either fail completely or else be working sub-optimally (e.g. noticable delays in updating the screen in the eMeeting). Therefore it is a good idea to assign someone who is physically in the same location as the speakers to also join the eMeeting as a participant so that they can alert the speaker and/or the eMeeting moderator if there is any problem with the emeeting.
• Recorder (optional): It is not ncessary to record the show and tell, but when you have gone to the effort of arranging the event it is a shame to lose it. Most eMeeting tools and/or teleconference services offer a recording service. The recording might need some post-processing, but you can often find that some of the hackers have a dream to get involved in the movie business and would love the chance to practice their skills