This is the first in a series of posts about ways to make long events better, especially ones that focus on technology and coding.
Examples of long technology events are hackathons, conferences, unconferences and workshops. Hackathons have probably received a disproportionate amount of negative feedback, and some of the issues discussed in this series of posts apply solely to hackathons. But many of the areas for improvement highlighted apply to daylong or multi-day events that are not hackathons.
My first post about making long tech events better is the beginning of a conversation (that started shortly after the first long tech event and will, no doubt, continue long into the mist-shrouded future of technology…). I’m writing this post series from a dual perspective; that of someone who has applied for the position of Automattic Events Wrangler (AEW) and that of someone who enjoys organizing and putting on a variety of event for the TIME community (Tech, Innovators, Makers, Entrepreneurs).
“Long Tech Event” Deficiencies Seen By Others
To kick off this conversation, below are excerpts from three posts written to highlight significant deficiencies in hackathons. Some issues apply primarily to hackathon, but a few apply also to unconferences and a variety of other long-format events
“Last weekend I attended the MHacks: Refactor hackathon on behalf of my company…the more of these events I attend, the more disgusted I become with the process…Here are my reasons for why hackathons as they exist today need to be banished:
- junk food is provided for sustenance…Occasionally, the organizers do a great job and offer healthier alternatives. But, these merely supplement instead of supplant the stereotypical programmer’s diet catered at these events.
- poor hygiene in close quarters.
- encourages sleep deprivation…
- 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…
- salesmanship is rewarded. The rewards are given strictly based on the presentation…often times the winners are those who put together the most polished presentation irrespective of actual execution.
too commercialized. Any grassroots efforts to learn, network, and have a great time have now been stifled by corporate involvement. Companies offer prizes for best use of their API or their product. Essentially, if you don’t use a companies offerings, you aren’t going to win a prize…”
“They’re too much commitment..
They’re usually a whole weekend of focused work…
They exclude people with lives and responsibilities
…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. Attending a weekend-long event means massively rearranging my life…
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?
I’ve been to a few of these events, and I’ve never yet felt like I didn’t come out of it less healthy than I went in…
Why can’t I work on an existing project?
Every hackathon I’ve been to has required that you come up with a new idea to hack on…I spend most of my time working on projects that I think are important and worthwhile. My head is full of them, I know my way around my toolkit and the codebase, and I have endless ideas for improvements and new features I want to work on…
And then they’re gone.
People say that hackathon projects are just prototypes, and that great things can later emerge from them. However, hackathon projects seldom survive beyond the weekend of the hack…”
“There’s been some prominent blog posts recently questioning the usefulness of hackathon events. Some focus on the cultural issues associated with many hackathons–that by default they appeal to a very homogeneous subset of tech workers (aka young white male coders who enjoy subsisting on beer and pizza). This can be mitigated by thoughtful event organizers–advertising your event in places where a diverse crowd will see it, explicitly inviting beginning developers and non-developers (designers, product managers, community members), having a code of conduct, providing child care, serving real food, etc…
A deeper criticism of hackathons is that, although they may be fun, since nearly all hackathon projects are abandoned after the event is over, they’re no good for creating startups, real useful products, or social change. All they might be good for is networking. Thus, these events are oversold. I think there is a point here, but I don’t think you can conclude from it that hackathons aren’t worthwhile to run or attend. Rather, attendees and observers should modify their expectations…”
Tentative Titles For Post Series
The above excerpts set the tone for this series of posts I’m publishing. I read these types of “negative” experiences as great opportunities to correct deficiencies in the long tech events, to make sure the events don’t try to be everything to everyone, and to do the best possible job of communicating what the events offer and what types of people are target participants or attendees.
Currently-planned topics for upcoming posts in this series are:
- Identify and prioritize opportunities for improving long tech events
- Deeper look at Number 1 Improvement Opportunity
- Deeper look at Number 2 Improvement Opportunity
- Deeper look at Number 3 Improvement Opportunity
- Overview of Number 4 – n Improvement Opportunities
- Automattic Events Improvement Opportunities
Additional Links: Deficiencies of Long Tech Events
As an organic outcome of my events wrangler activities over the years, I’ve captured information about how people wanted unconferences, hackathons and other long tech events improved. My “Unconferences and Hackathon” Google Doc is a repository for that information and is continually updated. Improvement ideas I learn or develop as a result of publishing this series of posts will be incorporated into the Gdoc to help organize and run more engaging, enjoyable and effective events in the future. For events wranglers or event participants who are highly interested in this topic, I pulled from my Gdoc the following eleven links to additional posts and articles which mention or infer improvements needed for long tech events.
Please check out the links above and come back to Events Wrangling tomorrow or in the near future for more about the issue of seriously improving long tech events. I hope you’ll join in this discussion by emailing me or otherwise generating online or in-person conversations relevant to this post series.
If you’ve written a post about this subject or have read worthwhile posts and articles on the topic, please send a link to it to me at bwaldron (att) gmail [dott] com.
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“