Finishing The List: Priority #8 – Priority #13
Today’s post will wrap up this series about the top ways to improve long tech events.
Depending on your reasons for organizing or participating in a long tech event, you’ll likely prioritize these items differently than I did. Regardless of what order you’d arrange them in, items 8 through 13 all present significant opportunities to improve your events.
- Priority #8: Learning
- Priority #9: Levels of Commitment
- Priority #10: Ongoing projects
- Priority #11: Participant contributions
- Priority #12: Fair competition
- Priority #13: “Flow” for coders
#8: Learning More Than Expected At Event
Most events designed to do training do pretty good job of it. Or if they don’t provide effective training, it’s not because they don’t have that as a high priority.
However, some of the more informal tech events, especially if organized by inexperienced events wranglers, may benefit from putting more thought into how to help people walk away with more information and understanding than they expected to get.
The minimum training target should be that event marketing materials and available information made it clear what learning would be gained at the event and the necessary activities happen to provide the promised learning. Because plans rarely work out exactly as expected, it makes sense to raise the training target a bit higher, under-promising and over-delivering. Attendee delightment and appreciation is what you’ll get if they walk away having learned more than they thought they would.
Strategies for delivering a superlative educational experience depends heavily on what people are coming to learn, but a couple ideas include:
- Thoroughly vet the “teachers” and speakers to ensure they not only know a lot, but that they effectively help people learn the subject matter.
- Provide opportunities for practical application of what people are learning, e.g. if the training is about robotics, have a variety of robots or other relevant equipment people can experiment with and reinforce what they learned.
- Provide access, during and after the event, to resources that are discussed during the training session. Make it easy for them to locate those resources when they need them.
#9: Allow For Different Levels of Commitment
Enabling different levels of commitment at a long tech event is especially important for attracting people whose schedules and responsibilities don’t allow them to spend an entire day or an entire weekend at the event.
Regarding committing to long events, one person had this to say:
Me: I’m kind of interested in your thing. How can I get involved?
Them: We have a hackathon coming up. You should come!
Here’s how that sounds to me:
Me: I’d like to get a little more physically active.
Them: You should come run a marathon on the weekend!
They exclude people with lives and responsibilities…A hackathon usually takes up a whole weekend, often starting Friday night and going through until Sunday evening…I have other things going on in my life: errands to run, friends to see, a veggie garden to keep watered, and other community events and commitments to schedule around…That exclusion is not evenly distributed. I see fathers of kids at hackathons pretty often, perhaps because their wives are looking after the kids. I see mothers far less often…It’s well documented that diverse teams have more creative ideas. So why exclude entire categories of people by holding an event that is hard for them to participate in?
If you need the contribution of people who are interested in the theme or focus of the event, but aren’t willing to dedicate a whole day or weekend for that purpose, look for ways to break the goal down into smaller chunks.
Creating an agenda and event format that allows for those chunk level commitments can be challenging. If you’re running a hackathon whose goal is to develop the maximum number of ideas, the best apps or the most useful application of a piece of software or chunk of hardware, someone who wants to only spend two hours at the event is unlikely to contribute significantly toward your goal.
It is tricky to design a long tech event to enable people to contribute effectively or to get something useful, inspiring or exciting out of their short time at the event. It’s certainly worth the effort to try to accommodate participation in short time blocks, but it can’t always be done.
If you just can’t come up with a plan for widely varying levels of commitment, make it clear in your event marketing and communications that you considered that and could not find a way to make two-hour or four hour commitments useful and rewarding for everyone. If it works out for your agenda, invite people with schedule conflicts or lower levels of interest to come to the event at a specified time for talking with people to see or learn about what they worked on. Showing up for a relatively short demo and info session may get people interested in working on a project after the event or might convince them to show up at a future related event.
#10: Optimize Potential Of Ongoing Projects
Ongoing projects was one of the issues covered in the Follow-up For Greater Impact post, but it’s important enough that I also separately focus on this one of the thirteen ways to improve long tech events. By emphasizing it with a stand-alone priority, I hope to prevent it from being lost in the blur of everything else in the priority item for follow-up.
As soon as planning starts for your event, figure out if one of the outcomes should be ongoing projects. Communicate to all potential registrants whether those projects are an expected takeaway. Get them thinking about what they need to do during the event to make the post-event work most worthwhile and effective.
During the event, document and publicize all projects expected to continue after the event. Consider formal or informal agenda items which focus on and enhance the projects. Schedule small group work sessions for the projects. Have team-forming opportunities while everyone is at the same location. Identify local restaurants which have good facilities for small group meetings, such as separate rooms or large tables, and help project teams schedule a project dinner to discuss relevant issues and build personal connections or relationships. Discuss potential sponsorship with organizations that may benefit from the project. Encourage and facilitate the scheduling of post-event project meetups. Provide an opportunity near the end of the event not only for pitches or demos of projects, but also for explaining post-event work plans and expectations for the projects.
Finally, ask each project team how you, as the events wrangler, can contribute to the success of their project after the event. If you can help them with their request, do so. If you can’t help, let them know that and suggest other people or resources who might be able to help.
#11: Participant Contributions: The Secret Sauce
Participants’ contributions are the key to success for participant-driven events like BarCamps and other unconferences, but can also be valuable for traditional conferences, workshops and other long tech events.
At unconferences, the Law of Two Feet was instituted to encourage everyone to find a way to benefit or contribute at all times during the event.
“the One Law of Open Space…is a law only in the sense that all participants must observe it or the process will not work. We call it the Law of Two Feet. Briefly stated, this law says that every individual has two feet, and must be prepared to use them. Responsibility for a successful outcome in any Open Space Event resides with exactly one person — each participant. Individuals can make a difference and must make a difference. If that is not true in a given situation, they, and they alone, must take responsibility to use their two feet, and move to a new place where they can make a difference.”
To maximize the chance of participants making an unconference successful, I try to make sure everyone understands:
- There are no attendees at an unconference. Only participants.
- Leading a session about a topic of great interest to you will likely connect you with other people knowledgeable about or involved in that same topic.
- All participants are welcome to suggest and lead a session. (There are never enough time slots at an unconference for that many sessions, but if a participant is passionate enough about their session topic, they can always do an informal session with other interested participants in a quiet corner of the venue, or outside, or after the slotted sessions are done for the day.)
- Session leaders are not “presenters.” They are most effective when they introduce an interesting aspect of some main topic, bring up a couple of their thoughts about that aspect, or maybe work they’ve done involving that aspect, and then get the other session participants involved in the discussion. People with relevant knowledge can contribute what they know, or ask insightful questions. People interested in, but not highly knowledgeable about the topic can ask questions or offer a viewpoint the session leader hadn’t considered before. The last thing a session leader should do is put up a PowerPoint presentation and trudge through a one-to-many talk about the session topic.
- If you are aware of something that needs to be done before or during an unconference to make it successful, don’t say, “Somebody should do X.” Instead, say “I’m going to do X, and if anyone else wants to work on it with me, let me know.”
Even if the event isn’t participant-driven, the attendees can still contribute in ways that help other people enjoy it more. Make someone’s day better simply by being truly pleasant and starting each interaction out with a smile and friendly greeting. Help your fellow attendee out by carrying their coffee if they look like they’re going to drop their food or spill the coffee if they don’t have a little assistance. If a person looks lost or confused, ask if there’s anything you can help them with. Be patient when there are long lines. Be understanding when the inevitable glitches occur, such as a room that’s too cold, a meeting location that got changed at the last minute, and don’t complain loudly about petty issues to everyone who will listen, or at least to everyone who is near you.
#12: Rules And Format For Fair Competition
Most long tech events don’t include a challenge or competition, but for the ones that do, especially if there are significant prizes for the winners of the contest, do everything possible to ensure fair competition. Doing this will:
- Be beneficial to, and appreciated by, the people competing
- Bring the most value to the sponsors of the event and the prizes
- Make people more likely to compete in future events organized by the same group
Various people over the years have pointed out instances of unfair competition at hackathons and other challenge events. Brian Chang had this to say:
“Many projects begin well before the hackathon. There are a lot of teams who bring their existing projects to the party. This is unfair to newcomers who aren’t well calibrated to understand what can be accomplished in a given amount of time. Remember the Dreamforce 2013 hackathon? The winners of that event had been working on their project for 2 years which is not within the spirit of a time-constrained hackathon.
Salesmanship is rewarded. The rewards are given strictly based on the presentation. Never mind that you solved a really challenging problem. If you can’t sell it, you can’t win it. And often times the winners are those who put together the most polished presentation irrespective of actual execution.”
Learn from history. If you’re organizing a competition, research how fairness is ensured in similar competitions and find out what complaints people have voiced regarding unfair tech challenges. Don’t repeat other people’s mistakes, avoid them.
#13: Environment Conducive To “Flow” For Coders
For certain aspects of coding or hacking systems (concept of flow applies to more topics than just coding), the most valuable work is done during an extended period of concentration, which is often called “flow”.
The concept of flow was brought up earlier in this series in the post focused on health. In that post, Joel Spolsky was quoted as saying flow is especially important to coders because “With programmers…productivity depends on being able to juggle a lot of little details in short term memory all at once. Any kind of interruption can cause these details to come crashing down. When you resume work, you can’t remember any of the details (like local variable names you were using, or where you were up to in implementing that search algorithm)…”
What this means is that an event involving writing code will be most productive if it is structured to include long periods where the programmers can figure out and design their code, as well as extended sessions of writing the code itself. Not all developers will want to code through the night or be programming for more than two or three hours at a time. However, there are valid reasons to provide the option for coders to do overnight or long-session programming at a tech event.
- First, and foremost, as Andrew H says, “The experience of programming in the zone…was tremendously satisfying, relaxing and…hyper-productive. It was not an everyday experience. It could not be planned or scheduled. I could not force myself into the state.”
- Coding competitions usually have limited time for programming, often 24 hours or a weekend
- Some developers enjoy, or are most productive, working at night
- The tech event may be one of the few times the members of a project team are together in the same location
Think about ways you can organize coding events so developers have the best chance of achieving flow, including:
- Providing a variety of spaces and uninterrupted time slots (including overnight) where coders can work uninterrupted if they’ve gotten to a productive and enjoyable state of flow.
- Have healthy food and beverages that minimizes excessively high and low metabolic periods.
- Have some of the healthy meal food available (in fresh condition and the right temperature) when the coders want to eat it, not just in the first 15 minutes after the caterer drops it off at the venue.
- Designate separate areas where coders can sleep or nap when they want to recharge, as well as social areas where they can eat, talk, play game, or otherwise rejuvenate their minds and bodies.
- Make sure programmers have useful tools for programming, such as reliable high speed internet access, white boards (with fresh markers and erasers), plenty of conveniently-located power outlets, mentors or tech advisers for unfamiliar APIs, libraries, languages or other software required for the coding.
There are more ways to improve long tech events than just focusing on the thirteen topics I highlighted. Each of the thirteen points I mentioned can be worked on or approached using a whole horde of strategies and action items which weren’t mentioned in any of the ten posts in this series. Entire books have been written on how organize and run events, so a few blog posts will only scratch the surface of this activity.
However, if a reader picked up just one or two ideas from this blog on how to make their next long tech event more memorable and worthwhile for the people at that event, researching and writing these posts was time well spent.
Posts in this “Improving Long Tech Events” series:
“Making Long Tech Events Better”
“Improving Long Tech Events: Priorities”
“Improving Long Tech Events: #1 Priority”
“Improving Long Tech Events: #2 Priority”
“Improving Long Tech Events: #3 Priority”
“Improving Long Tech Events: #4 Priority”
“Improving Long Tech Events: #5 Priority”
“#6 Priority: Follow-Up For Greater Impact”
“Priority #7: Storytelling & Documentation”
“Improving Long Tech Events: Priorities #8 – #13“