This post is dedicated to my father, who passed away on 12/5/2009. He was a wonderful father and husband. He made friends with everyone he met. He taught me so much, and always had faith in me. I miss him terribly. I love you dad. You’re in a much better place now.
I wrote my original series on running a code camp after running my first one back in 2007. As of now, I’ve been involved in the running of four code camps, and have learned a lot of lessons over these years, so it’s time for an update.
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.
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 others in the area. Also make sure you pick a date at least a few months out. You’ll have a lot of work ahead…
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 (including Leo Junquera and James Simon), Leo and I recruited our wives to help, and James brought in help from his staff. In addition, we reached out to some of our members to help on the day of the event. Make sure you reach out for help at least a few months before the event.
In addition to getting help, if you’re not very experienced in running a code camp, getting input from experienced facilitators is invaluable. We were fortunate to have the support of Peter Laudati and Bill Zack, who helped run 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 some 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.
If you’re 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 contributors to make this work. We’re 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.
If you are able to get a facility like that, you’ll have one less thing to worry about. Otherwise, you’ll have to rent or borrow projectors for each track, and would possibly need to find a different location with several rooms to use, preferably large enough to fit a minimum of 25 to 30 attendees each. Try to get at least one room that could fit 50% to 75% of the total expected attendees for the introductory and closing sessions, which you can also use for the anticipated most popular track.
Reserve the rooms several months in advance if your facility books quickly. We missed out on our favorite room this year because someone already grabbed it.
Obtain 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, the eventual the list of speakers / sessions, the session schedule, presentation material, and all other info pertaining to the event.
Although this site doesn’t need to be anything fancy, try to get a basic one up and running at least a few months before the event.
For the first couple of code camps, and for all our user group meetings over the first couple of years, we used the Microsoft Group Events site to create invitations. But we were having trouble with the site a couple of months before this year’s event, so I searched out alternatives. I found Eventbrite, which, quite frankly, blew away the Microsoft Group Events site in functionality and usability (hint, hint, Microsoft).
Add the code camp event to your list, and set the enrollment limit up to 50% higher than the amount you can handle (and the limit you may publicly state). We allowed for 215 enrollments this year, and about 140 showed up. The Eventbrite site also makes it easy to generate reminders and follow-up emails to people who registered, and it looks professional. We’ve been setting this up about a month before the code camps, but I think we’ll be setting this up about three months prior to let our user group members get first crack at registration (see next section)…
Once you’ve gotten the support in place, 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 articles as a checklist. Here’s a partial example of the checklist we used. I sent out an updated version of this list on a regular basis up until the day before the event. You can see that there are plenty of small specific sub-steps that aren’t necessarily obvious from the high-level checklist in this article.
About two months before the event, you may want to ask for community input on the topics they would most like to see. We tried this the first year, but we didn’t make the process as easy as we should have, and didn’t get the feedback we’d hoped for. We’ll likely create a poll for this next year. You can use something like Google Docs, with a multiple choice form over a spreadsheet. Or if you want better control over each person only voting once, you can use a site such as Survey Monkey. If you’re a developer, you may be tempted in rolling your own for the tools I’m recommending, but you’ll be so busy as it is, I suggest making use of the free tools already out there. If you still have the itch, roll something after your first couple of code camps to at least get some solid background experience under your belt.
If you do decide to do this “Call for Topics” step for your user group members, you should combine it with the “internal announcement” to give your local community the first shot to enroll before opening it up to the general public. Remember — this is for the community, by the community. Send out a mailing with links to the poll and to the registration site (also done easily with EventBrite). Post a special announcement on your user group’s website which should already be cross-linked to the code camp website, and announce it at user group meetings.
About six weeks before the event (or about two weeks after gathering the “Call for Topics” poll results), 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 Developer Evangelists. Blog about it, post the announcements on message forums frequented by your targeted community (if it’s allowed by the forum), tweet it, and ask others to blog about it. In the announcement, if you were able to get community feedback, suggest those topics as “high-interest”. Additionally, suggest topics that reflect current industry interests.
I strongly recommend setting up an input form to capture this data. We’ve done this via email in the past, but no matter what instructions we give, the responses are never consistent. Save yourself some time with something like a Google Docs form (see below). I wanted to do something similar with Microsoft Office Live, but nothing like that was available as of this writing (another hint, Microsoft). Capture the speaker’s name, email, phone, session name, session description (including target audience level and background), and a bio. The phone number is important. I made phone calls to several speakers a couple of days before the events to confirm and make sure there weren’t any unanswered last minute questions. Email is great, but sometimes lost in the shuffle, and when the deadline approaches sometimes a phone call helps close any loops.
Although code camps are traditionally cost-free to the general public, they are not cost-free to run. Your costs will include food (including a speaker dinner, which I strongly recommend), and if you don’t at least feed the attendees a developer’s lunch of pizza and soda during a long day of learning, you’ll have a lot of very grouchy, inattentive techies – not a pretty site 
. Your costs could also include use of the facility. Although we were lucky enough that CITI at UCONN was willing to let us use the facilities for the most part, in exchange for publicity about their programs and a questionnaire on the back of our evaluation forms, due to the economy we still had to pay for the use of the largest room this year. I don’t see that changing anytime soon.
These costs is where sponsors are your best friend, although due to the nature of code camps, they aren’t really considered sponsors – they’re more like contributors. Local companies can be extremely helpful in this regard. Reach out to all potential contributors at the same time you send out your “call for speakers” (six weeks prior). We waited too long this year, and had to really scramble the last few weeks.
Normally, software vendors are great for contributing swag in exchange for posting info about their products on the code camp home page. Several popular and upstart development tool vendors gave us software licenses to raffle off. But when you need their help to actually fund parts of the event, you may need to offer the opportunity to present their products during lunch. Telerik was a huge help for us in this regard this year. You can bring on a vendor for each track (room), if you need to.
Microsoft has also had a generous budget for supporting community events like these, and they’ve basically covered most of our food costs and plenty of swag. It should go without saying that if your code camp centers around Microsoft technologies, definitely get your regional Microsoft Developer Evangelist involved from the get-go. If your event focuses on another platform, work closely with the equivalent support teams from those vendors.
One final note on this – developers love books and software, but aren’t crazy about recruiters at such events, so save them as a last resort.
On a related note, try to secure swag to raffle off at the end of the event. We all love books and software, and it’s a lot of fun giving this stuff out. User groups should all be aware of, and make use of a very valuable resource – the User Group Support Services site. In addition to many other development community services, the UGSS can provide you with regular shipments of swag for your user groups and related events.
In addition to the software the vendors contributed, this year we gave out so many books, we ended up not even raffling the rest off. We just let people dig through the books at the end. Granted, many of the books were a few years old — leftovers from the UGSS overstock. But most of it was still relevant. In exchange for the software we give out, we post vendor info on our code camp website, and hand out promotional material.
If you’re planning to use a secure facility, at least a month prior to the event, 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 (I strongly recommend 1.5 to 2 hours before the opening session) 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.
About two weeks after the internal announcement (a month before the event), now that your core community has had ample time to register, start publicizing the code camp. Contact other user groups, tell other bloggers, contact community leaders and local publications, and ask people at work to tell their friends about it.
If you can gather input from your membership before the code camp, it will help you narrow your selection, especially if you receive several proposals from multiple speakers. We had 24 sessions and 17 speakers apply this year, several with multiple session proposals. Because we were able to accept all the speakers, we only needed to pick a handful to do two sessions each. When choosing the sessions, we take into account all of the sessions in order to provide a good balance. We try to avoid having anyone speak for three sessions. I think that would burn out anyone by the third session, and you always want to end the day on a high note.
This will be the most difficult step of all your pre-event activities. I can’t stress this next point enough – do not worry about making specific topic tracks. Just don’t. We tried doing it the first couple of years, although Don Demsak warned me against it. Trying to coordinate the schedule is painful as it is. The first couple of years I 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 established speakers weren’t grabbing all the attendees), and trying not to place well-known speakers opposite each other, is just too frustrating. Bottom line — I learned not to worry about it. We always had to adjust the schedule for one reason or another on the day of the event, anyway, which throws some of your precise planning out the window.
It turned out that we never really had anything to worry about. Most 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 breaks in between sessions (10 minutes works well, but it also depends upon your facility layout), as well as an introductory general / breakfast session, a closing session for raffles, and lunch.
Session Scheduling Considerations
This year, I focused more on making sure that anyone who had to do two sessions had a single session break in between. In addition, anyone doing two sessions would do those over a three-session period, limiting how long they had to stay and allowing them to focus on their turn to speak. This gave speakers the flexibility to arrive late or leave early, or to sit in on other sessions. It also gave them time to rest and prepare for their second session, and just to get a "breather" between the two. Again, that may seem like over-thinking, but I’d put a higher priority on this than on making topical tracks.
You may also consider scheduling a speaker who needs more preparation to have their session right after lunch or first thing in the morning. This will give them an hour or so head start.
Once you create your initial Code Camp Sessions Grid and Code Camp Speakers and Sessions document, email them to all the speakers. You will get requests to shift things around. This will likely occur up until the last few days. You’ll also probably get updated bios and session abstracts. Always keep the speakers in the loop with updated versions until you have to print them out for the handouts.
Session Length
Speaking of the session schedule, one of our biggest mistakes the first year was the fact that we only allotted an hour to each session, which turned out to be barely adequate. Part of the reason we did this is because we wanted to avoid turning down speakers who volunteered, and wanted to put in as many sessions as was feasible. For the next two code camps, though, we lengthened them to 1:15 each, which seems to be fine. In order to fit an 8:00 AM to 6:00 PM day, we do four tracks of six sessions each, giving us a total of 24 sessions. Including the 15 minute intro session, the 10 minutes between sessions, the half hour lunch, and the half hour closing session with raffles, you can see from the sample grid that this fits 8:00 to 6:00 perfectly.
One thing we’ve failed at doing was getting the speakers to email us their presentation material a couple of weeks before the event. We’ll try that going forward to avoid the mad rush of download requests after the event. I don’t expect this to be easy 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.
Another reason I’d recommend this is because it can be very difficult getting some speakers to submit their material after the event. They’re already on to their next tasks. If someone could suggest how to make this easier, please let me know.
A couple of weeks before the event, I recommend sending out a speaker presentation preparation email, which includes the dinner invitation. I have to thank Judy Calla, leader of the Central Penn .NET User Group, for many of the speaker recommendations listed in this email. I also link to an article of tips I wrote a while back. As I mention in the email, although many of the speakers may be experienced technical presenters, some of the guidelines may still be helpful. I think they’re great reminders, and worth reviewing before any speaking engagement.
You may want to combine this email with the “call for presentation material” step.
As I mentioned earlier, you’re going to need a lot of help on the day of the event. This year, we recruited a few of our members to help as “room monitors”. In their role, they help the speakers connect to the projector and the Internet (if needed), and provide them with 15 minute (Q & A time) and 5 minute (wrap up time) warning signs. They also announce reminders at the end of each session about the evaluation forms and end-of-day raffles, etc., as the attendees walk out.
About a week before the event, send them instructions to print. You can use a version of the document we used as a template.
About a week before the event, the sessions, speakers and schedule should be pretty close to where they’ll end up, so it’s time to post this info on the website. Create web pages for each, in addition to PDF versions people can download (and what we’d hand out at the registration desk). Make sure to keep these updated, and specify the “last update time” on the site for each, so attendees know what to expect, and can plan their day.
This is also the time you can start creating and printing the rest of the material you’ll need to post on the walls, and to hand out…
Print a large version of the session schedule that you can hang on a wall near the registration desk. For each session, print the title and speaker on a separate sheet of paper in a large font. Also print row and column headings on their own pages. I recommend painter’s tape for posting these without damaging the walls or leaving residue. It’s great for all your sign postings, also.
Print a single sheet for each room to show which sessions will be held at each time period for that room. You should post these outside the door of each room.
You should investigate the layout of the venue beforehand, in order to know what signs you’ll need to print for directing people to each of the rooms, the food, and the restrooms. Bring some blank pieces of paper and some thick markers, in case there are changes on the day of the event (there almost always will be).
If possible, create a map or floor plan for the facility that you can include in your handouts. We didn’t think about this until the last minute this year, but we’ll start doing this next year.
One final thing that would have helped us tremendously this year – if possible, I strongly recommend posting all these signs the day before the event. We were running around like chickens without a head trying to post them before the first session began. We weren’t done until after the second session, and there was already some confusion.
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 include 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 evaluation document as 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.
You may be wondering about creating an evaluation feedback page on the Web, instead. I don’t recommend that for a couple of reasons. First of all, most facilities used for free events such as code camps don’t necessarily have enough publicly available bandwidth to allow people to do this real-time. Secondly, out of site, out of mind – if you expect people to rate the sessions after they return home, you’ll likely be disappointed. Nor will they necessarily recall exactly how a session went. Your best bet is to allow them to fill out a form the old fashioned way, as soon as they possibly can. It’s not that difficult to tally these afterwards. I have a pretty good system where I take care of this over a few hours. I’ll discuss that in part three of this series.
Print out copies of the session schedule grid to include in the information packets.
The first couple of years, we printed out badges to hand out to the attendees and speakers as they arrived at the registration desk. Although I like the idea of name badges for networking purposes, the day is so hectic as it is, and it isn’t worth the cost of the badge holders. This year, we instead printed out all the attendee names in a badge format that we then cut into raffle tickets, and used them for the end-of-day raffles. The prior years, we handed out those popular red raffle tickets (keeping one half for the drawing), but it really slowed down the registration desk.
If you use a service like Eventbrite, you can easily print name badges from your attendee list. I selected the badge style of Avery 74536 – Clip Name Badges (3 x 4 inch) – Page Size 8.5”x11”.
When preparing packets of information, include the Code Camp Sessions Grid, Code Camp Speakers and Sessions document, and feedback evaluation form, at minimum. If your hosting facility can swing it, I also recommend including a small pad or a few pieces of blank paper for notes, and a pen (all promoting your venue). Also include some promotional material for the venue 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. One year we made fliers available from one of our speakers who happened to be providing some free training, so that was an ideal situation. Of course, if your contributing vendors supply you with flyers, include those as well. This year, Telerik not only gave us flyers, they also gave us bags to put these packets into.
Always try to supply both breakfast and lunch for everyone. Serving breakfast is also an incentive for people to come to the early sessions. You want the day to get off to a flying start. With the funding support from our contributors, we ordered breakfast from Dunkin’ Donuts the past couple of years (a little over $400 to cover 160 people). I recommend putting together an order list, and to place your order in person at least a few days before the event, leaving the list with them. Placing such a large order over the phone is doomed to get misinterpreted. Trust me; it happened last year.
The pizza lunch order is a lot easier. We stick with plain pies to make it simple, and estimate 1.5 to 2 slices per person. Don’t forget diet as well as regular soda, and some non-carbonated beverages, also. I’d also place this order at least a few days before the event.
Also, make speaker dinner reservations for your team (for approximately an hour after the event ends, to give you time for cleanup and travel to the restaurant). 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, they’ll have a lot of insight into how to improve future events. You’ll probably need a few hundred dollars to cover this. Try making this reservation at least a week in advance at a decent nearby restaurant (walking distance, if possible).
Microsoft covered the costs of lunch and dinner each year we ran the event, but this is always subject to change depending upon their budget. So don’t only count on Microsoft for financial support.
A couple of days before the event, send a reminder email to the registered attendees, giving final instructions including ticket info, parking info, directions, and links to the schedule and speaker information PDF downloads. I generated this email through Eventbrite, and some of the header information was automatically generated for me.
Make sure everyone has good directions to the venue, both by car, and by public transit, if available. Don’t forget any special info about parking. Don’t count on the registration sites’ mapping feature to get the directions right. They always get our location wrong. Several people got lost the first year. This year, we mapped it ourselves, and included the correct map link on our registration page and in the final reminder emails.
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, along with an attachment of setup instructions.
Always give out organizers’ cell phone numbers to the speakers. It will absolutely be used. 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.
Summary Checklist
Here’s a summarized checklist, with milestones, of everything I detailed above:
- Pick a date (at least 3 months prior)
- Get help (at least 3 months prior)
- Find mentors (at least 3 months prior)
- Pick a venue (at least 3 months prior)
- Create a website (at least 3 months prior)
- Get an event registration site and account (at least 3 months prior)
- Make a list (2 months prior)
- Make a call for topics / internal announcement (2 months prior)
- Make a call for speakers (6 weeks prior)
- Make a call for contributors (6 weeks prior)
- Obtain swag for raffles (1 month prior)
- Address security concerns (1 month prior)
- Make public announcements (1 month prior)
- Choose the sessions (2 weeks prior)
- Create the session tracks and schedule (2 weeks prior)
- Make a call for presentation material (2 weeks prior)
- Send a speaker preparation email (2 weeks prior)
- Send room monitor instructions (1 week prior)
- Post schedule and session details (1 week prior)
- Create a large session schedule grid (1 week prior)
- Create room / track schedules (1 week prior)
- Create directional signs and a floor plan (1 week prior)
- Create feedback evaluation forms (1 week prior)
- Create session schedule grid handouts (1 week prior)
- Create name badges / raffle tickets (1 week prior)
- Prepare information packets (1 week prior)
- Arrange for food (1 week prior)
- Send out attendee reminder email (2 days prior)
- Make final confirmation calls and send final speaker email (2 days prior)
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.
