Mark Freedman’s Blog

Archive for the ‘Tutorial’ Category

Update
I’ve updated some of the points below, based on some of the comments I received, including points about when to answer questions, the appropriateness of jokes, and following through after the presentation.

Last night, I attended a terrific Speaker Idol event at the NYC .NET Developer’s Group at the Microsoft office in NYC. It’s one of the formats I mentioned in my post about user group meeting ideas.

This was the first user group meeting I’ve attended since I helped start a couple, and it was really nice to focus more on learning rather than coordinating. I had three main motivations for attending this meeting:

1. I wanted to finally attend a meeting rather than run one.
2. I wanted to see how a Speaker Idol event is run, in order to run one ourselves.
3. I wanted to see what it takes as a speaker, so perhaps I could try it myself one day.

I feel like I met these goals. First of all, attending these in NYC always gives me a rush of energy. I love going to the city, because it’s so amazingly alive and vibrant. It gives me the feeling of being able to accomplish anything. And there’s nothing like a warm summer night in the city that never sleeps.

And the second and third goals were accomplished with flying colors. Although I tried to make this a non-working event, I couldn’t help myself. I spent the entire night taking copious notes. And although this was the first Speaker Idol event I’ve ever attended, and it’s the only one I can base my observations on, I think it came off great. I think it can serve as a model for future events, so I put together a list of guidelines from this experience.

Although I haven’t presented at user groups yet, I’ve had similar experiences. My tips are a combination of those, of comments from last night’s judges, and of my observations from this and other user group meetings.

Great job done by Stephen Forte, Andrew Brust, Peter Laudati, Bill Zach, and all the speakers and judges!

Basic Rules

• Approximately five speakers should present (there were six last night).
• Each speaker gets 10 minutes to do their main presentation.
• There are four judges who are recognized leaders in the community, to give this legitimacy.
• During the presentations, the MC (Stephen Forte, for last night’s event) gives a silent two minute warning signal.
• The MC then gives a cut sign, signaling to the speaker that they have 20 seconds to wrap up.
• Once the presentation is complete, two minutes are alloted for a Q & A session with the audience.
• This is followed by a judge commenting session which lasts from three to five total minutes, rotating through the judges who comment on the presentation style (NOT the content). Sort of like American Idol. For each presenter, the comments are started by the next judge in rotation.
• At the end of the competition, bring all the participants to the front for a final round of applause, and announce the winners.
• There are three winners. At last night’s meeting, first place won an Xbox, second and third place won versions of Windows Vista.

Moderator Tips

A Speaker Idol event is similar to a mini code camp, where you’re pretty much going crazy trying to get equipment set up and tested. It was pretty hectic last night, with people downloading codecs, using borrowed laptops, etc. More about this in the Speaker Tips section, below.

• Have someone else handle the food. You’ll be too busy coordinating everything else with the speakers and judges, so try to get a sponsor to handle that. This was what the group did last night, and all it cost was about 10 minutes of a (deathly dull) sponsor presentation at the start of the session. Once you’ve seen one recruiter presentation, you’ve seen them all. They were sincere, but c’mon recruiters — use a little imagination. I don’t care how many clients and consultants you have. Tell me how you could help my career… anyway, that cries for another post…
• You may need to be the liaison between a speaker and the supplier of a solution if their presentation isn’t working on their own equipment. Set aside some time for this. It was a bit of a scramble last night, so I’d recommend requiring the speakers show up an hour before the session for setup and testing. Things will always get a little crazy, and a bit of luck is always involved, but this will increase the chances of success.
• I’m not sure how the presenter order was decided, but there’s a definite advantage that increases with each speaker. You could either have a random drawing, or use the reverse order of who volunteers to participate. Since most of us are so busy these days, I’d prefer a random selection.
• A quick 20 second intro of each speaker would eliminate the need for them to do more than a ten second "hello" at the beginning of their presentation. Most people are uncomfortable introducing themselves anyway, so it may keep them more at ease to start their presentation if they don’t have to concern themselves with that. They can just display a simple info slide at the start, while they introduce the topic.
• Clarify to the audience and speakers that for these types of presentations, especially with a dedicated Q & A period, almost all questions should be deflected for that period. The only time a question should be addressed during the body of the 10 minute presentation is if it’s critical for the direction of the rest of the presentation.

Speaker Tips

Do the three "P"s: Prepare, Practice, and Present. I’m sure I’ve heard that phrase before, but I’m not sure who to credit…

Preparation

• Tailor your presentation for 10 minutes (and I’d shoot for 8 to play it safe ).
• Be aware of whether your presentation is more of a discussion topic or a presentation, and prepare the style and flow based upon that. Make sure you structure the presentation to have a strong start, middle, and end. At the start, do the quick hit to get the audience engaged, and tell them what you’ll be talking about. Next, dive in and talk about it. Finally, quickly summarize with a couple of key conclusive points.
• Go for impact from the start, whether it’s through humor or a one liner that clearly sets the stage for the presentation.
• Slides should be minimal, and only used as cue cards for what you’re going to say.
• Since this is a 10 minute presentation, only pick a couple of key points to elaborate on — one positive and one negative, if possible.
• If your presentation calls for a comparison between two or more options, use visuals to compare. In a 10 minute window, you’ll need to get the point across quickly, so visuals work best for this.
• Use a large font size. The obvious reasons go without saying. But less obviously, it turns code into more of a quick-hitting visual.
• Don’t use blue font on a black background. It’s virtually impossible to read without straining. I’d actually recommend sticking with the default white background. A lot of developers seem to favor a black background these days, but although that may work well on your desktop, it doesn’t translate well to the large screen.
• Use very simple demos. If you can get your point across with a single visual, or just a tiny code snippet, then you can succeed in a 10 minute slot. Review your code several times as you prepare, stripping out everything you can, while still making it relevant. This is a common theme for writing, also.
• Plan the Q & A session, anticipating the types of questions you may get. You may need to balance leaving out a point or two in order to open up the possibility of a couple of good questions, but at the same time, don’t leave out critical info during the main presentation which will only leave your audience in a cliffhanger.

Presentation Style

• Project. You don’t want people straining to hear you, especially when you only have 10 minutes to state your case.
• Face the room. If you don’t face the room, your voice will just bounce off the wall behind you, and that ain’t gonna help with projecting.
• Rotate facing each side of the audience. This will help engage the entire audience.
• Don’t read directly from the slides, or repeat them word for word as if memorized. This becomes very robotic.
• Setting the slide show on automatic timer may be a novel way to keep you focused on your flow and time constraints, but it could be a distraction if you have to keep stepping back to a previous slide.
• If you’re natural at it, inject humor, especially at the start. It helps build rapport. Jabs at users are always good for a laugh in front of tech groups. But if it isn’t your normal modus operandi, don’t force it, because it will be obvious that it’s being used as a gimmick.
• Be aware of your audience. As I mentioned above, jokes about users are ok if your audience is a tech group, but don’t joke about topics and subjects that may offend your audience. If you feel any discomfort when about to tell a joke, trust your instinct and play it safe. Very little can take the air completely out of a presentation than a misguided attempt at humor.
• Show enthusiasm for your subject matter. If you can’t show enthusiasm for 10 minutes, you’re speaking on the wrong topic for you.
• When notified of the two minute warning, or 20 second wrap-up, don’t acknowledge it. It ruins the flow, and disengages your audience.
• Avoid silence, but don’t fill it with hemming and hawing ("um"s). Practice in front of mock audiences (or the mirror) is key. If you need to take a few moments to do something on the screen, at least explain what you’re doing while doing it.
• Don’t trail off or mumble when you speak. This is another variation of hemming and hawing, and people begin thinking they may be missing some important info.
• Be energetic. Watch someone like Stephen Forte when he speaks. He can make accounting sound exciting (sorry accountants ). We live in a fast moving, "MTV" world, and it takes a lot of animation to keep our attention.
• Stand in front of the podium. Stepping behind (for reading notes, etc.) only serves to disengage your audience. This is why you need to do the three Ps. You don’t want to sound as if you’re reading from a book. Show us you know your topic. You want to project credibility.
• Make eye contact with the audience. You can pick a handful of people (one from each side of the audience) to feel like you’re speaking one on one. I’ve heard a related recommendation for writing. Imagine that your audience is one person — a friend of yours.
• When things screw up, self deprecation goes a long way. The audience can relate to screw ups.
• Be honest. If you really don’t know the answer to something, say so. Otherwise, you risk the credibility of your entire presentation.

Presentation Content

• Make your intro of yourself and your company extremely short (if needed at all — see moderator tips, above). You can show a simple intro slide while you introduce the topic, in case people really want to know. Don’t be offended that we came here for the topic, and not necessarily for you.
• Explain why you’re presenting the topic, and what business reasons there are for it.
• Asking for a show of hands initiates interaction with the audience, but don’t leave it at that. Otherwise it just seems gimmicky.
• Use personal insight when discussing examples and experiences. This helps the audience identify with you and the topic you’re trying to convey. Otherwise, you may as well be reading facts out of a textbook.
• Never make comments or state opinions without following up with "why". "Why" is really the most important type of question you can answer. And the specific "what" and "how" always follow the "why".
• Have the demos open and ready BEFORE starting the presentation. Nothing leads to those empty spaces more than waiting for Visual Studio or PowerPoint and associated project files to open. You only have 10 minutes, and time always seems to run away quicker while waiting for these to open.
• Get to code as soon as possible. For a technical audience, getting to the meat is key for keeping us engaged.
• Switch to full screen mode when showing code (SHIFT-ALT-ENTER). Popping panels are a major distraction.
• Display your resources slide during your 20 second wrap-up and into the Q & A. The judges mentioned to leave it up there after speaking to it, but I wouldn’t even recommend speaking to it. It wastes valuable time, and your audience expects to see this at the end anyway, so it’s obvious.
• Use the regions feature in your code examples to make it easier to focus on small snippets.
• When discussing unknown technologies, give quick, one-line intros. It may help to show an analogy to technology your audience is familiar with. For example, EJB to .NET Enterprise Services. It may not be exact (like my example?), but it’ll give us the proper context.

After the Presentation

Many people attend these presentation for the educational value, in order to keep up with what’s happening in their field, and they make a significant time commitment to attend your presentation. Whatever your motivation for speaking, the reputation you earn is based upon more than your session. How you follow through also counts in a big way.

• For speakers of any type of presentation: please try to make yourself available, at least through email, for any follow-up questions attendees may have. Due to the nature of presentations, there are almost always outstanding questions that cannot necessarily be answered or even anticipated during the presentation, so you should always expect questions after the event.
• It’s also a good idea to provide the organizers of these events with presentation material and supplements to post on the organization’s website, to help with the follow-on.

I anticipated such an event to be a lot of fun, and it exceeded my expectations. I’m sure it was nerve wracking for the speakers and the moderators, but like my experience with the code camp, I’m sure it was well worth it. I’ll use this post as a guideline for when my group runs a similar event, and hopefully others will find this useful, even though I’m basing it upon limited personal experience. If you have anything to add or suggest, please comment.

John Zablocki was one of the presenters at the our first ever code camp. He’s written a related article about presenting at code camps, with the story behind his preparation and presentation. This article serves as a cousin post to my posts about running a code camp. Ok, maybe it’s a sister post. Or a brother post. Oh, brother — you get the idea…

Also, since he recently presented at our .NET user group, he’s written a related article about presenting at user groups. He had a fairly unique experience, thanks to the fact that the Microsoft Visual Studio 2008 Installfest was happening (to his surprise) on the same evening. We did that just for you, John! Serves you right for taking a long vacation during the announcement.

As soon as I gather enough courage to speak at one of these things myself one day, I’ll be sure to re-read these. In the meantime, I’ll continue to help organize these, and occasionally participate from the audience. But I will speak one day! I will! The more presentations I see, the more confidence I have that I can do it well.

Of course, when that day comes, you can be sure I’ll be whimpering on the floor in a pool of sweat…

In my previous two posts, I discussed guidelines for the preparation of running a code camp, and then I went through all the tasks for handling the actual day of the event. Here, I’ll be discussing the things you should do after the event is done — after you’ve given yourself a few hours (minutes?) to bask in its afterglow.

Evaluation Feedback
Tally the feedback forms as soon as possible after the session. I experienced an interesting phenomenon at the end of the day, after the attendees had all left and the speakers were waiting to go out to dinner. They were all over the evaluation sheet box, checking ratings and feedback. The visual is quite an experience, and in my bewilderment, Melissa Demcsak (who didn’t speak at this event, but has done so at others) observed that I must be new to this, because it’s a common occurrence. I certainly understand it though.

I gathered all the ratings and averages for each category, sending it along with comments specific to each speaker’s session, and also the general comments about the code camp. You can download a copy of our eval document as a starting point for your own.

I’m sure you’re thinking there must be a high-tech way of handling this, but for gathering feedback while the sessions are still fresh in attendees’ minds, I’m not sure there is. Even if we had set up kiosks, forcing people to line up at a few really isn’t an attractive option. The goal is to make it as friction-free as possible. It’s the facilitators’ job to deal with the work involved afterwards. Yes, it was a pain manually tallying all the sheets, but I got into a rhythm, and was able to push through it in decent time. It was pretty interesting reading the comments, and quite a challenge deciphering the handwriting. And, yes, even some normally detail-oriented developers still have trouble following directions .

I created a spreadsheet with a worksheet for each speaker, one for general comments, and one for tallying results from the venue-specific questions. Here, you’ll find a semi-fictionalized sample (the names and ratings have been changed to protect the innocent). I then split each speaker’s worksheet into its own spreadsheet, which I emailed (along with the General worksheet) to each speaker.

Follow-Up Communication with the Speakers
Of course, don’t forget follow up with the speakers right after the event to thank them for volunteering their time and effort, not to mention their sheer courage for speaking in front of a crowd for at least an hour straight. Like I said before, without the speakers, there is no code camp (no user groups, no education, no growth and no interest in the field — nothing). These people deserve all the credit in the world for making all of this possible. This would also be a good time to remind them to send you their presentation slides, etc., if they hadn’t already. You probably already have attendees bugging you for these.

Post the Session Presentation Material
Shortly after the event is complete (by the following Monday, if possible), try to post all the material you’ve received up until that point. We placed a session list on the home page of the code camp for easy access, with links on each square leading to a zip file of the material. Also, if a speaker has a web page, link their name to that page. And if you happen to take photos and/or videos of a session, also create a link to it from within that box. Keep these up-to-date as you continue to receive material. I created a standard naming convention to easily create and update the links. In the future, I plan on making this data-driven. For this code camp, I’ve been updating a simple table, but it’s still error prone.

Final Call for Presentation Material
You don’t want to be too annoying (I’m known to be a bit annoying ), but a week or so after the event, you may want to send out one last reminder for presentation material. As top members of our field, the speakers are probably all very busy, so sometimes a little nudge will help give them a chance to refocus for a few minutes to gather up their material.

Plan the Next Event
What? Already? You bet. You don’t want to lose the momentum. I’d wait a few weeks, but not much more than a month after the event to follow up with both the speakers and the attendees. We haven’t done this quite yet, but we’ll be sending out an email shortly, asking everyone about the topics they’d want to see next time, and ask the speakers if they’d be interested in presenting follow-up topics in either our next code camp (around May, if we do these semi-annually), or if they’d want to expand upon their topics at a user group meeting in 2008.

Wow, there were a lot of guidelines, but this is a big undertaking — much larger than I had realized. But it was well worth it! It’s definitely not something that you’d want to take on more than a couple of times a year. With solid planning, dedication, and some seasoned guidance, you can do this, and it’s an experience you’ll not soon forget.

Please let me know if I missed any important points. I hope these guidelines prove useful, and I’ll keep these posts updated as a reference for anyone who wants to run a code camp or similar event in their community.

In my previous post, I discussed guidelines for preparing for the running of a code camp. If you’re not out of breath yet, hang in there. This is where it all pays off. I’ll then follow up with a post about the follow-up steps to be done after the event.

Arrive Early
If you can get into the facility early, try to get in at least an hour and a half before the opening general session. I made it in with the volunteers an hour early, and we did a LOT of last minute rushing around. Our opening general session was scheduled for 8:00 AM, so we arrived at 7:00 AM. I think our next code camp will start at 8:30 AM.

Volunteers
Recruit a couple of volunteers to help with handouts, badges for the attendees and speakers, posting signs giving directions to the important rooms, and monitoring the registration desk, amongst other miscellaneous items. As I mentioned in my first post, I’m so glad that my co-chair, Louis, thought of this, and recruited the help of Vicki and Sylvia from the UCONN School of Business office. Not only did they help with the preparation of the materials needed for the event, they also helped tremendously on the day of the event.

Feed the People
Make sure that breakfast is set up about a half hour before people are scheduled to arrive. Make sure the coffee is flowing (both regular and decaf). We want everyone to be awake for the early sessions .

Session Schedule Grid Display
Display the large session schedule grid by the registration desk. You’ll need a huge blank wall or bulletin board to use. Depending upon the wall, you can use regular clear tape (which we used) or something like painter’s tape, to ensure that you don’t damage the walls, or leave behind any residue. You may even need a ladder to reach the earlier sessions. The wall we had to use was a little limited, so what we did was posted about half of the entire schedule up at first, and then as the day went on we discarded the finished sessions, and shifted the rest up to make room for later sessions. This led to a slightly confusing situation, though — a couple of people assumed that the latter sessions were canceled, because we hadn’t posted them yet (there was no room to post them yet). Next time, we should post a bottom row that indicates that more sessions would follow.

Post Directions
Post the directional signs directing people to the rest rooms in addition to the session rooms. Also, signs should be posted directing people to the food. We didn’t do this, and location we used for food was tucked away a bit, so several people didn’t know where to find it, especially if they came late and weren’t there for breakfast.

Last Minute Corrections
Have a thick black magic marker on hand, because you know you’re going to need it to fill in some extra arrows and extra instructions on the signs that you posted. There’s always going to be things you think of based upon the logistics of where the signs are placed after you’ve already printed them out.

Temporary Storage
Have a secure place to store the speakers’ material (handouts, props, extra hardware, etc.) before and after their session. After all, they’ll normally be attending other sessions, and don’t need the burden of carrying these around. We left poor Michael de la Maza dragging a box around until his session, because we hadn’t considered this. We ended up using Louis’s office for this for the balance of the day.

Registration Desk
Make sure that at least one person is handling the registration desk most of the day. Many people show up late at these events, maybe waiting until the first session they’re interested in. We had a rule — in order for an attendee to be eligible to win free swag, they must pick up their name badge (so we know they actually did attend), and still be present at the end of the day. This is also an incentive for people to stick around for the sessions.

Quiet Areas
Make sure you have areas outside of the meeting rooms where the speakers can set up and practice or do last minute changes before their session. Being able to provide them with an Internet connection is a major bonus, in case they need to download any extra support material, etc. We were lucky enough to have this event at UCONN, so we had a couple of great lounge areas to sit down and relax before and after the sessions. It was also great for the speakers to be able to sit down in these quiet areas to chat with other speakers.

Opening Session Considerations
Make sure you’ve given enough time for an opening general session. Although you don’t have to do much at this session (give some minor instructions about the room locations, when and where we’d be serving food, eligibility rules for the swag raffle, filling out the evals), it provides an opportunity for networking (although many people seemed to still be a bit too sleepy for this), and just as important — to give the first speakers of the day a chance to set up their equipment and test the facility’s equipment (and give us a chance to find a different room if need be). One of our sessions started a bit late because of a setup issue. I would start the code camp a little later next time. Otherwise, the first speaker could get shortchanged.

Delay Issues
Another potential issue you want to avoid with setup is any delay taking too much time away from the speaker’s session. Running over is not much of an option — at best, you can “cheat” by grabbing most of the ten minute break between sessions. Since people can switch between tracks, if one track is delayed, all subsequent tracks also have to be delayed in order to allow the attendees to see the next track in its entirety. Setup issues can still happen later in the day, especially if there is special equipment involved, so I recommend saving such sessions for the last session of the day, if possible. We had such a situation, but because it wasn’t the last session of the day, the speaker lost about a half hour, and had to eliminate most of his examples.

Encouraging Interaction
Audience participation (or lack thereof) can make or break a session. A room often does not have to be very dark in order to see a projected image. We made a mistake in one of the rooms we used, and kept lights down too much, and I think it kept the audience energy level for those sessions a bit too low.

Photos and Video
Although it’s not required, I recommend taking some photos of some of the sessions in progress (don’t forget to use a flash — I forgot, and the photos didn’t come out too well). Not only is it nice to capture some of the moments, it’s also good promotion for future events. It also helps the facility sponsoring the event to see the amount of participation, so they may be willing to allow you to run similar future events. I also took a few seconds of video of some of the sessions, but you may feel more comfortable asking the speaker if they’re ok with it before doing so. I didn’t really ask, but the videos were so small that I didn’t capture more than 10 to 15 seconds of each, anyway. We considered video recording all of the sessions in their entirety, but that would have been way more than we could have handled. I don’t see even trying to tackle that one for a long time. I know they did this at Remix in Boston recently, and I was warned about the massive effort that took. From what I understand, it’s a task that’s still in progress for the editing and all.

Between Sessions
Have a person posted at each room at the end of each session for two reasons: 1) to announce to the attendees a reminder that they should register at the front desk if they had not yet done so (and why), and to fill out the evaluation forms (and why), and 2) to help the next speaker prepare for the next session.

Feed the People Again
Make sure that breakfast is cleared out, and lunch is set up about a half hour before the scheduled break. Because you’ll be so harried much of the day, I recommend grabbing some food about five to ten minutes before the lunch break, just so you could escape in peace for a few minutes into a quiet room.

Raffle
After you get a final list of attendees, you’ll need to draw the raffle winners from the list. I believe we may have worked too hard on generating this list. What we did was download the latest list from the Microsoft Group Events site in Excel format, removed the names of the people who didn’t pick up their name tags, then Leo wrote a little macro to generate random numbers based upon the remaining count, and at the final session we assigned the winners from the least to most valuable prizes. It turns out that we didn’t select enough numbers since several people left early, so for the few remaining prizes, based upon an attendee’s suggestion, we picked a winner on the spreadsheet line corresponding with a random number called out by an attendee, and continued from that line on down. Because the list was not in alphabetic order (it was actually in the order people signed up for the event), it was pretty random. I think that for next time we’ll do it completely this way. The only thing we’ll do is pick a single random number, and work our way down the list from that point forward. There wasn’t a real reason to worry about subtracting the unclaimed badges from the list, because if we read the name and the person wasn’t there, we’d just skip to the next line. The person must be there and be wearing their badge to claim the prize, anyway.

Speaker Dinner
Finally, it’s time to go to dinner, and celebrate the day’s event! Take photos and video, and pat each other on the back for a job well done!

Your Goals from the Event
Don’t expect to learn much in the sessions if you plan on running a code camp. That’s what other code camps run by other people are for. When running one you’ll be spending way too much time coordinating the event to do much more than take the pulse of a few sessions. You’ll be learning a lot, but it will be about how to organize and run such an event. You’ll be experiencing this from a completely different angle than you may have in the past, which will be just as valuable as the type of learning you would gain from being an attendee. As you gain experience in running these, I’m sure you’ll get more opportunities to sit in on sessions, because you’ll have a lot of things down to a science, more or less. But the concentration will not be there for a full tech learning experience. Keep your eye on the real goal for running one of these events — to facilitate learning for your community.

In my final post, I’ll discuss follow-up steps to be done after the event. Yep, your job is not done yet!

I’ve only been involved in running one code camp, but I think we learned a lot, and it went well enough to be able to recommend some guidelines. This first post will list my guidelines for the preparation steps. It assumes you’re already involved in running a user group. I’ll follow up with posts about running things on the day of the event, and then follow-up steps to be done after the event.

Get Help
The number one rule — do not try to do this yourself! There is no way to successfully run a significant event without the help of others. In addition to our core team (Leo, Louis and I), Louis recruited the help of a couple of really nice, helpful, and diligent people from the UCONN School of Business office — Vicki and Sylvia.

Find a Mentor
If you’re running a code camp for the first time, getting input from experienced facilitators is invaluable. We were fortunate to have the support of Peter Laudati and Bill Zack, who ran the code camps for the NYC .NET Developer Group. Don Demsak, experienced with his NJ events also provided some valuable insight. I think it also helped that I was present early at the NYC code camps to help a bit with their preparation, and to observe some of the steps they had to take before the events began.

Pick a Date
Check for other events in your area. Check with user group leaders, local regional directors, local Microsoft Developer Evangelists, other members of the development community, and sites such as Community Megaphone to make sure that your event won’t overlap with other area events.

Make a List
Make a list of everything you can possibly think of that would be needed — every action step, from beginning to end. You can use these posts as a checklist. These also contain items we forgot about or didn’t realize we needed until it was too late.

Pick a Venue
If you’re already running a user group, you may already have a venue that’s ideal for a code camp. If not, the costs could increase a lot, and you’ll need more contributors to make this work. We are extremely fortunate that we can use the facilities at UCONN. Virtually every room is equipped with projectors and white boards, so the speakers can basically just plug in and power up. Otherwise, you’ll have to rent or borrow projectors (at least a couple more than you may use for your user group meetings), and would possibly need to find a different location with a few rooms to use, preferably large enough to fit 25 to 30 attendees in each.

Create a Website
I recommend obtaining a URL for the sole purpose of the code camp. Try to get one with a similar name to your user group site, and definitely cross-link. This is where you should post the original announcement, the “call for speakers” announcement, and the eventual the list of speakers / sessions, the session schedule, presentation material, and all other info pertaining to the event.

Call for Speakers
About six weeks before the event, send out a call for speakers announcement to all the people on your mailing list, known speakers in your area, other user group leaders in your area, local regional directors, and local Microsoft Developer Evangelists. Blog about it, post the announcements on message forums frequented by your targeted community (if it’s allowed by the forum), and ask others to blog about it. In the announcement, suggest topics that define the nature of the event and that reflect current industry interests. Capture the following info: name, company, email, phone, track level (basic, intermediate, advanced), session name, session description, and bio. A phone number is important. I made phone calls to everyone a couple of days before the event to confirm and make sure there weren’t any unanswered last minute questions. Email is great, but sometimes a phone call right before the big day helps close any loops.

Code Camp Questionnaire
This may not always be needed, but we were surprised with the number of responses to our call for speakers. We had 19 people offer up about 35 different topics in total, and wanted to take the pulse of the community to see which of the offered topics they’d be most interested in, so we could pare it down. We created a spreadsheet listing both the speakers and available topics, and asked people to rank their top ten, giving 10 points to the topic they’re most interested in, down to 1 point for their least. We sent out this spreadsheet with our emailing of the internal announcement, described below. In hindsight, we should have also sent out the detailed session abstracts along with it.

Microsoft Group Events Account
If you don’t have one already that you use for user group registration, create an account at the Microsoft Group Events site. You can also give other members of your team their own accounts so that they could also update the event info. Add this event to your list, and set the enrollment limit up to 50% higher than the amount you can handle (and the amount you state). We allowed for 150 enrollments, and 122 signed up, 9 then canceled, and about 80 showed up. From what I understand, this is typical. The site also generates automatic reminders, and looks professional.

Internal Announcement
At about the same time, you may want to post an “internal announcement” — that is, only to members of your user group. You want to give your local community the first shot to enroll before opening it up to the general public, since they’re the main group you’re doing this for. Remember — this is for the community, by the community. Post a special announcement on your user group’s website which will already have a cross-link to the new code camp website, and announce it at user group meetings.

Call for Contributors
Code camps are free to the general public, but they are not free to run. Your costs will include food (including the speaker dinner) and possibly the facility. We were lucky enough that UCONN was willing to let us use the facilities in exchange for publicity about their programs, and a questionnaire on our eval forms. The remaining costs is where sponsors are your best friend, although due to the nature of code camps, they aren’t really sponsors – they’re more like contributors. Local companies can be extremely helpful in this regard, and you’ll want to post a thank you on the home page. Also, software vendors are great for either contributing funds or swag for this, in exchange for posting info about their products on the home page. Telerik and Infragistics gave us several software licenses to raffle off. Techies love the books and software, but aren’t crazy about recruiters at such events, so I’d save them as a last resort. Microsoft also has a generous budget for supporting community events like these, and they basically covered most of our food costs and plenty of swag.

Swag for Raffles
Always try to secure swag to raffle off at the end of the event. We love books and software, and it’s a lot of fun giving this stuff out. In addition to the software Telerik, Infragistics, and Microsoft contributed, Microsoft also contributed around a dozen books and a mouse. In exchange, we posted Telerik and Infragistics info on our code camp website, and gave out promotional demo disks from Infragistics and Microsoft.

Choose the Sessions
This was made a bit easier by the Code Camp Questionnaire. We had room for 21 sessions (we’ll probably cut this down to 15 for the next code camp), and had 19 speakers apply. Because we were able to accept all the speakers, we only needed to pick two to do two sessions each. We added up the point rankings, and although that played into the chosen two extra sessions, we weren’t scientific about it. We took into account all of the sessions in order to provide a good balance. But we also took into account the rankings in order to do the next step — the session tracks and schedule.

Session Tracks / Schedule
Don’t worry about making specific session topic tracks. We tried doing it anyway, even though Don Demsak warned me about it. Trying to coordinate this was the most painful part of the whole process. We wanted to make sure we had the right mix in each track, and kept adjusting the track descriptions to keep things even. Trying to do that on top of trying not to have well-known speakers present at the same time as new speakers (to make sure that one session wasn’t grabbing all the attendees, leaving little for the lesser-knowns), and at the same time not wanting to place the well-known speakers opposite each other, frustrating the attendees. Bottom line — I learned not to worry about it. We had to swap sessions around during the last week anyway due to timing / commitment issues, and one burnt-out laptop caused someone to back out, which threw much of the planning out the window. It turned out that we had nothing to worry about. All of the sessions were well attended, the balance was pretty even, and I don’t think any speaker felt shortchanged. I guess we initially tried “over architecting” this . Don’t forget to schedule in breaks between sessions (10 minutes worked well), as well as an introductory general session with breakfast, a closing session for raffles, and lunch.

Session Scheduling Considerations
Try to schedule sessions so that a speaker who needs more preparation has their session right after lunch, or even first thing in the morning. This will give them around an hour head start. Also, after you create an initial Code Camp Session Schedule Grid and Code Camp Speakers / Sessions document, email them to all the speakers. You will get requests to shift things around, likely up until the last few days. You’ll also get updated bios and session abstracts. Always try to keep the speakers in the loop with updated versions up until the day of the event.

Session Length
This leads to the question of time allotted per session. This was one of our biggest mistakes. We gave an hour to each session, which turned out to be barely adequate. Part of the reason is that we wanted to avoid turning down speakers who volunteered, and wanted to put in as many sessions as was feasible. For the next meeting, I think we’ll set each session to at least 1:15, and preferably 1:30 each. I’d rather not mix them, because in that scenario, if we needed to swap two, we’d likely have to swap out six. I’m leaning towards three tracks of five sessions each, at 1:30 each session. I’d like to get more feedback on this.

Call for Presentation Material
Try to get the speakers to email you their presentation material the week before the event, so that you can avoid any mad rush after the event from people asking to download the material. Successfully receiving these is lot harder to do than you may think, though, because many speakers like to tweak their presentation up until the last minute. They may even need a couple of days after the event to make any corrections, etc. But the more you can get up front, the better.

Public Announcements
About two weeks after the internal announcement, now that your core community has had ample time to register, start making the code camp public. Contact other user groups, tell other bloggers, contact Dot Net Rocks!, speak to local publications, etc., and ask people at work to contact their friends about it. We tried to have an article published in a local paper about our host, CITI at UCONN, students and local companies impacted by their programs, with a mention of the user groups and code camp prior to the event, but missed the deadline to get it in on time. But once the article does come out in December, it should give a great boost to all parties.

Post Schedule and Session Details
Around the time you send out public announcements, the sessions, speakers and schedule should be pretty close to where it’ll end up, so it’s time to post this info on the website. We created separate pages for each. Make sure to keep these updated, and specify the last update time for each, so attendees know what to expect.

Large Session Schedule Grid
Print a large version of the session schedule that you can display on a wall near the registration desk. For each session, we printed the title on a separate sheet of paper in a large font. We also printed row and column headings on their own pages. Bring clear tape and/or painter’s tape for posting these without damaging the walls or leaving residue.

Room / Track Schedules
Print a single sheet for each room to show which sessions will be held at each time period for that room. You can post this outside the door of each room.

Directional Signs
You should investigate the layout of the venue beforehand, in order to know what signs you’ll need to print directing people to each of the session rooms, the food, and the restrooms. We didn’t know exactly which rooms we were going to use until that morning, because several events were being held at the campus that day. Thankfully, Louis was able to print directional signs at the last minute from his office.

Feedback Evaluation Forms
Design a feedback form to allow the attendees to rate each session over several categories. There should also be a space for comments about the sessions, and the event in general. We also included a questionnaire on the back of the form to capture data to help the facility sponsor. After all, they provide us with the facility to use for the code camp and the user groups. I think this is a good idea in general for any facility you may use. It can be placed on the back of the form so it’s not obtrusive, and almost everyone who handed in the form to us actually answered the mostly yes/no questions. You can download a copy of our eval document for an example of such a form, and to use as a starting point for your own. Print out copies to include in the information packets

Session Schedule Grid Handouts
Print out copies of the session schedule grid to include in the information packets. I grabbed an image of the web page, and just pasted it into a Word document.

Name Badges
Print out name badges for each registered attendee and speaker, at the last feasible moment. Bring along blank ones for write-ins for late registering attendees. I recommend that you require that an attendee can produce a name badge if their name is called in the raffle.

Information Packets
When preparing packets of information, include the session schedule grid, feedback evaluation form, and a pen, at minimum. I also recommend putting in a small pad or a few pieces of blank paper for notes, although we didn’t do that. Also include some promotional material for the venue of the event, as a return favor for hosting it. If any speakers want to hand out fliers for some of their services, you may want to consider placing them into the packets also, although at a free event such as a code camp, you want to try to avoid blatant marketing. We made fliers available from one of our speakers who happened to be providing some free training, so that was an ideal situation.

Security Concerns
If you’re planning to use a secure facility, make sure that the local security or police department is aware that the facility will be used on a weekend. Arrange to have the facility opened in time to prepare for the event, and if the doors lock from the outside after a period of time, make sure someone could monitor the doors so nobody gets locked out, or leave a cell phone number so they can call someone to get back in. If there’s a period of time after which the doors are locked, be sure to state this in the information details when people sign up, since people often arrive late.

Arrange for Food
Always try to supply both breakfast and lunch for all the attendees. Serving breakfast is an incentive for people to come for the early sessions. A significant number of people showed up early, so the early speakers had a good audience, and the day was off to a flying start. The catering group over at UCONN provided us with food for about $1000 for 100 people. Also, make speaker dinner reservations for your team (at approximately an hour after the event). You can probably assume that about 50% of the speakers would be able to join you afterwards. Definitely take the speakers out for dinner after the event — not only for thanking them for volunteering (remember, without the speakers, there is no code camp), but this is also a phenomenal networking opportunity for everyone involved, and a LOT of fun. These are experts in the field; some well known, and others fairly new to the public speaking arena, and they can share war stories. Not only that, but they have a lot of insight into how to improve future events. You’ll probably need a few hundred dollars to cover this. Again, thanks to the contributors for helping to cover all of this.

Directions to Venue
Make sure all the speakers have directions to the venue, both by car, and by public transit. Don’t forget any special info about parking, which we nearly did until the night before.

Your Contact Info
Always give out the cell phone numbers of at least a couple of organizers to the speakers. I forgot to do this until the night before, but it came in very handy. A few speakers got a bit lost trying to find the venue, and another would have been locked out of the building because he came late in the day, and security had already locked the doors from the outside.

Final Confirmation Phone Call / Email
A couple of days before the event, call each speaker to make sure that they’re ready, that they know exactly what time they’ll be presenting, and to remind them to get there early enough to do final preparations. Make sure they have directions, and ask if they’ll be joining you for the speaker dinner afterwards (as your guests). Also ask if they have any final questions. Follow up this phone call with an email to each, especially to the people you had to leave a voice mail.

In my next post, I’ll discuss how to handle the day of the event. It can get pretty frenzied, but at least there’s less actual work to do than in the preparation phase. That’s where all this preparation work pays dividends.