Cooperation on Day Two
Developer Camp is a three-day hackathon and community event, held regularly in cities all around the world. It relies on a certain pattern and schedule to create trust and foster cooperation — right up until the presentations begin. Here is how the second day works.
Schedule
0900–1000 — Continental Breakfast
1000–1200 — Introductions & Inspiration
1300–1400 — Lunch
1200–2200 — Side Session Presentations by Attendees
1800–1900 — Dinner
2200–0900 Sunday — Overnight: Tea, Games, and Coding
Summary
Organizers and sponsors are welcome as early as 8am, when breakfast is delivered and our hosts open doors. Usually, there are people who have registered, but couldn’t attend the night before. These people are welcomed by our volunteers, as well as people who have yet to register for the weekend.
After doors open to the public, we allow for an hour or so for people to arrive, and then begin our orientation. This is a chance to reiterate the rules of the space, the contest, and give more of our sponsors some time on stage. Following this, there is time for people who hadn’t pitched their idea, skill, or need the night before to do so.
The main hall is a space for the most people to congregate. It’s doubles as a lecture hall, while the organizers give a brief presentation on the stories of those who’ve come before. After 9 years of events, there are more than a few great startups that have had success, and a few spectacular failures that teach us how to face rejection gracefully.
After a presentation on the nature and process of innovation, I usually set up my workstation on stage. This way, anyone who has a question to ask of the whole group can solicit my help. Also, this allows the illusion of “adult supervision” which encourages good behavior and sharing.
A generous lunch is provided, and everyone is encouraged to break in the early afternoon together. By then, most of the side session slots have been filled, and those who are interested can listen and learn. Side sessions range from presentations on sponsor offerings, like SDKs, APIs, and collaborations, to how-to clinics like Hello World, to design critiques.
Side sessions are offered away from the main lecture hall, in rooms slightly larger than a meeting room. These are rooms designed for small presentations, and are ready with projectors and classroom seating. Presenters are responsible for marketing their own content to attendees, although announcements are encouraged in the main hall for the widest reach.
By the end of lunchtime, everyone should have a partner or team. Our organizers and volunteers remain available to augment these teams with “pinch hitters” or mentors who have specific skills to overcome obstacles and challenges throughout the weekend. Sometimes the way forward is to design your way out of the problem, but sometimes it requires a bit of coding or debugging.
By dinner time, most people have been at it for six or eight hours. At this time, we encourage a longer break, and I sometimes organize games for attendees to break up their experience. Often, I’ll project a game experience up on the big screen, and encourage a tournament or display of skill to entertain everyone in the main hall.
By closing time, around 10pm, we make announcements about the rules for overnight stay. I offer my camping equipment, and note that doors will be locked at 10. Exit is permitted, but doors don’t open again until the following morning. Security and host representatives remain on site during the night.
Day two is all about the cooperation of individuals, groups, and technologies. Often the Internet will get spotty during the day, under constant load from the multitude of devices on site, and despite our best preparations. Usually, there are last-minute team pairings or swapping or scrapping of ideas that happen.
The organizers sweep the halls, looking not just for what people are working on, but how they are working. Are they cooperating? Is there a spirit of excitement, focus, or frustration? Wherever we go, there is inevitably something to learn about the participants, their ambition, or their methods.
I always take time on day two to sit in a new location, watch the process of innovation and contribute as much as possible. Usually, I’m diverted from this, but it’s those moments of passing peace that make this experience so meaningful.
My side session is usually about presentation skills. A good demonstration is 50% great interactivity and 50% great storytelling. This means that, while your app may physically work, the concept could be lost without a compelling narrative and a strong voice to tell it.
Here are a few presentation tips:
- If you’re having trouble getting the demo to work correctly every time, record a video or screen capture of the experience.
- Try not to rely on the WiFi network, as it can get overloaded during presentation time. Cellular service can sometimes be more reliable then.
- If you’ve got more than one presenter, consider a conversational style, showcasing the voice of each presenter.
- Describe the problem you are solving. Then tell the audience how your solution is unique.
- Bring the description of your idea down to 140 characters, and think of it like a marketing tag line.
- Hold the microphone close to your mouth when you speak.
- Engage the audience — ask them a question, or ask for a show of hands, or try to generate a response like laughter or surprise.
- People will forget who you are, they’ll forget what you have said, but they’ll never forget how you made them feel.
