Alexey needs a web presence

Realizing Rewards from your Hackathon Sponsorship

So, you've handed over some hard-earned cash to sponsor a hackathon - awesome! On behalf of hackathon organizers everywhere, thank you.  Let's make sure you maximize your return on investment.  

Aside: why should I be sponsoring a hackathon, again?  I go into more detail here, but the TL;DR version is: meet and recruit top up-and-coming hackers, expose them to your company and build relationships for when they start or join companies.

(1) General Advice:

• Show up.  Seriously.  Figure out who your friendliest outreach person is and have them come to at least part of the event. I recommend sending an engineer or (if you have one) a developer evangelist - they know how to speak the language and represent your company well.  You don't have to be there the whole time, but show up enough to meet the cool kids.  If you're not sure who the cool kids are, ask the event organizer. We know, and are happy to make the introduction.
• Teach.  A lot of hackathons (at least on the college circuit) are preceded by a series of tech talks. Figure out what you are good at - is it Coffeescript? iOS development? mobile CSS?  Talk to the organizers about hosting a tech talk. A big part of the motivation for hackathons is to learn a new technology. Seeing who shows up to the talk, learns quickly and asks the right questions is a great way to both introduce yourself and start building a relationship with the right hackers.
• Be personable. Companies do a much better job when they stop trying to be impressive. Don't send hackathon participants to a generic 'apply' page - hand out your email address left and right and talk to people. In most cases, this will be their first impression of your company. Make it a friendly one.
• Be a good judge.  First, (and this deserves its own post) being a sponsor doesn't necessarily mean you should send a judge, nor is judging the most efficient use of your representative's time.  That said, if you are one of the judges, make sure to (1) talk to the organizer about their criteria (at PennApps, for example, we don't care at all about whether the hack has a business model or not, which is clearly not the case for Startup Weekend.  Participants need a mix of encouragement and feedback; make sure your representative is comfortable addressing a reasonably-sized audience and generally upbeat in demeanor.
• Swag away. At PennApps 2010, Twitter sent us 50 t-shirts with the iconic twitter bird logo.  I still see these proudly worn around the Engineering quad, often followed by "whoa, how'd you get that shirt?" Corporate swag is the clearest win-win-win proposition I've seen - companies increase their brand exposure (to exactly the people they are trying to hire), hackathon organizers have goodies to hand out to participants and hackers get swag they can wear for +3 geek cred. You don't need to have the brand recognition of Twitter, but you do need to give student's a reason to wear your branded shirt. I recommend cartoons - engineers love cartoons.

• Get creative. In September, the Venmo guys decided (without any prior warning) to show up at 3AM with bags full of Geno's cheesesteaks.  I cannot begin to describe the sheer amount of goodwill they generated through that. A lot of students have started using Venmo since; I can't help but think that this is at least in part due to the sheer magic of 3AM Geno's. Another example: in January Arkitech brought massage therapists to offer 15-minute massages, a service greatly appreciated by hackers who had spent the last 18 hours in $5 chairs.

We even got one of the therapists to lead everybody in a stretching exercise.

(2) Specific Advice

You're hiring

• Ask for resumes. Not during the hackathon, though - that is neither the time nor the place. Instead, ask the organizers if they might be able to help with recruiting as part of the sponsorship package. For PennApps, we collect resumes from participants opting in, (usually about 50% of participants) organize them into a spreadsheet, group them by hack, and send them to sponsors.  Even if your hackathon doesn't do this, take a look at what has been built (either by attending the demo session or looking through the demos online) and ask the organizer for introductions to your favorite several applications.  Be careful to be specific about this: as an organizer, I'm much more likely to offer to help if you've shown interest in things people have built than if you just ask for introductions to the "winners".

• Connect and follow up.  When you have somebody attending, make sure your representative writes down contact info/emails for anybody who they were particularly impressed by. Wait a couple of days (let people sleep the weekend off) and then reach out: "Hey, I was pretty impressed by X that you were working on over the weekend - I'd love to get a cup of coffee and hear what kind of cool stuff you've been working on."  Even if they don't end up working for you, the good kids at a school will, by and large, know one another - leaving a positive impression on one will get them to introduce you to others in their circle.
• Hang out and help. HackNY did this at their most recent hackathon - at the end of the API demos, Chris asked mentors in attendance who were solid at particular layers of the stack to stand up and introduce themselves, IE "Hey, I'm Alexey from AlexeyCo, and I'm pretty good at Python, Ruby and the Facebook API. I'll be around until pretty late tonight so come bother me if I can help!" If you're trying to hire Python developers, establishing yourself as the company that has solid Python coders makes you an attractive place to work for quality Pythonistas.

You've got an API to evangelize

• Knock your demo out of the park.  Demo quality makes or breaks whether hackers get excited about the possibility of using your API.  John Britton, who represented Twilio, knocks these out of the park (here's his advice). You have a couple of minutes to get attention, and you're competing for mindshare right there and then.  If you're just getting started, here's a sample demo format we used as a guide last time around. 

(credit to Fred Wilson for finding the video).

• Make developers feel special.  In January, John not only hung out with us throughout the hackathon answering questions, but also handed out $100's of dollars of Twilio credits to anybody that talked to him about using the API. As a developer, that's great - this company respects me enough to give me special treatment - now I definitely want to give them a try.

You're an angel/VC

• Connect with future dropouts.  Ask the organizers who they think is most likely to stop out of school.  See what they're working on and give feedback.  Especially in the current climate, building relationships early on helps make the difference when entrepreneurs seek investment.  Seed funding is raised through lines, not dots. 
• Help your portfolio. "Oh, you're passionate about marketplaces and design?  Let me connect you to the folks at Etsy - you might enjoy talking to them!" Figure out what skills and culture your portfolio companies need and keep them in mind as you meet participants. 

... Now that you know how to get the best bang for your sponsorship buck, can I interest you in sponsoring PennApps in September?  We throw a mean hackathon.

PS 

Interested in hosting hackathons? Check out the rest of my posts about lessons learned:

• Convincing sponsors to give you money
• What to do when: The organizer's checklist
• The hacker, the talker and the runner - the hackathon organizing dream team

Hosting Hackathons: The Organizer's Checklist

This is a second in series of posts on how to host a student hackathon, based on my experience with PennApps, as well as from participating in HackNY and PhillyGameJam and the hackathons at Facebook last summer. For other posts in the series, see here.

The first PennApps hackathon took place on September 2010, and was put together during the summer before, working nights and weekends.  Below is a (non-exhaustive) checklist of what kind of things needed to get done in preparation to, during, and after the hackathon.  A list like this would have been useful to me last year as a new hackathon organizer, so (hopefully) it'll be of use to you.  

Note: You can put together a Hackathon in much less time than a Summer, so your mileage on the dates may vary.  

3-4 Months Before

• Event Timing and Format: Figure out when you're going to have your hackathon and what the format is going to be like (12/24/48 hours, or some longer period like Columbia's DevFest).  
• Key Partners: Figure out what key groups from your university you're going to work with to get things done. We got a ton of support from the Student Government, our Innovation Center and the Provost's Office. You'll need these as proof of legitimacy for your website.  
• Funding Instrastructure: You also want to make sure you're all set up to take funding once it becomes available. We've found most companies are happy to either pay via Credit Cards or write us a check.  Our organization (the Dining Philosophers, Penn's CS club) is University-affiliated, meaning all of our funding needed to be made out to the University. If this isn't the case for you, feel free to give something like KickStarter a try.  Either way, reach out to your relevant University partners and make sure you've got a way to take money once it's available.
• Design Standards: You're going to make t-shirts and print posters. To keep a reasonably consistent design standard, see if you can get your designer friend to contribute a logo that will work across various background colors and ideally a color scheme.  Good design is a solid way to show legitimacy when asking for funding
• Website: Put together a simple static website explaining what the hackathon is, who is organizing it, what you're hoping to do and what you need (hint:probably money).  Your audience at this point are the sponsors - when you email them asking for funding.  

  For the first PennApps, we ended up writing a bunch of plain HTML and using the Posterous API to pull in blog content to the main page.  The second time around, we used WordPress - this took away some of our design flexibility but made it far less painful to drop in new content.  We're sticking with WordPress.

• Location (ideally): if you're lucky, one of the Key Partners (above) will be able to help you find a location for the hackathon that works for you. More likely, you'll need to spend some amount of time reaching out to the University to try and see where you might be able to host the event.  We wrote up a Location Requirements document to help streamline our conversations with the administration. 

2-3 Months Before

• Key Sponsors: Once you have a basic website and an idea for the event you're going to have, you're able to start reaching out to sponsors to get funding for your event. We started with high-profile sponsors with whom we had established relationships first, largely through internships.  We reached out to Microsoft, Google and Facebook first; getting confirmations from those sponsors and being able to put them on our website made the rest of the sponsors easier to convince.
• Blog Content: By no means is it necessary to have any blog content for your site, but I figured that between interviews with past participants and the rolling out of updates, a simple blog would be an easy way to make the site 'alive' and develop some early buzz amongst students.
• Location: Try to have your location down by this point.

1-2 Months Before

• Sponsors: The Key Sponsors are going to make your life easier in finding the rest of your funding. Make sure you've approached the funding sources suggested in an earlier post.
• Judges: If you want awesome, important people to come serve as Judges for the demo session, you're going to need to ask them reasonably far in advance (at least a month would be nice).   
• Tech Talks: One of the fun things to do at Hackathons is try new APIs and frameworks. Start to figure out what companies or individuals in the area you want to reach out to to introduce the APIs before the hackathon. Developer Evangelists tend to be pretty high in demand (on the Android team in particular), so make sure to start this at least a month in advance and try to work out the talk schedule in a way that works for everybody.  
• Schedule: Start to put together a preliminary schedule for tech talks, the hacking itself, meals, and awards/prizes. This schedule will be bound to change, but having a first draft helps get judges/sponsors/tech-talkers give feedback and start to form their schedules around the event.
• Website: Start addings sections on the website for the sponsors, judges, talks and the planned schedule (basically, each of the points above). If you're going with a blog, keep posting.

3 Weeks Before

• T-Shirt Design: T-shirts matter.  Come up with an awesome design and make sure to get yours made ahead of time, rather than rushed and therefore more expensive. Fewer colors is cheaper (add about $1/color/shirt).  We used a local store but I've heard reasonable things about customink.
• Outreach: Figure out who your attendees are going to be and how to find them.  For Penn, emailing the relevant CS department list-servs and clubs on campus got the job done.  Externally, we reached out through friends to invite hackers at other schools.  Get people to sign up and commit to coming. We used a Google Form the first time around and EventBrite in January.  Neither quite satisfied our needs (which is motivation for another post), but EventBrite isn't bad.
• Location: In case you don't, you should REALLY have your location figured out by now.
• Food: Compile a list of potential caterers for the event, doing your best to keep it varied, healthy, and cheap (we aimed at <$5/person/meal and only doing Pizza once).  Go down the line and start contacting caterers to see if any of them are interested in providing food for free or at a deep discount in exchange for a sponsorship/recognition/etc (hey, it can't hurt to ask).  Get prices and lead times (IE, if 20 more people than expected show up, how much in advance do I need to tell you by) and start working on a short-list. 
• Tech Talks: At this point, most of your tech talks should be solidified.
• Local Sponsors: There's a category of local sponsors that should be able to give you stuff (Red Bull, stickers, schwag) that are worth reaching out to, but can be dealt with on a shorter time schedule. Note: some barter sponsors from larger companies may need several weeks to get things things approved within their companies - make sure to reach out to them in advance.

5 Days Before

• Tech Talks: should be completely booked and know exactly when they are going. The finalized tech talk schedule should be up online and emailed out to participants
• Participants Counts & Finalizing Orders: At this point, you should know approximately how many people are going to make it (so you can order T-shirts and food appropriately).  I was off by more than 50% both times I tried to estimate the participant count for PennApps.  Here's what I recommend: email everybody that has signed up about 5 days in advance and ask them to respond with 24 hours to confirm attendance.  The number of people who have responded are a reasonably solid guess (something like 10-20% of even those people will have something come up, but yet others will end up inviting their friends, or somebody will hear about the event, etc).

The Day Before/During

• Posters, Posters, Posters: Put signs everywhere. If you're within a couple of blocks of the event, you should be able to know how to get to it.
• Event Logistics: Make sure the website is ready for the event.  Figure out what your channels of communication are going to be throughout (Twitter? IRC back-channel?) and have links on the site. Figure out who the contact people are going to be for the event and create a Google Voice number that forwards to all of them.  Put the number on the website.
• Social Media: Somebody ought to be manning your Twitter account/taking photos and potentially video interviews throughout. Participants will have worked their ass off throughout the event and deserve to have evidence to show for it.
• Back-up Plan: Things are going to go wrong day-of (out of power cords/need more food/X just broke) inevitably, spending money is going to be the fastest way to solve a lot of your problems. Make sure you know where that money is coming from and who is getting reimbursed for it, and how. Save receipts.

Post-Mortem

• Demonstrate Results: Either host links to teams' work or (ideally) share the videos of their presentations.  Teams (and the hackathon itself) need to be able to point to tangible results. 
• Promises to Keep: Whatever value proposition you made to sponsors, make sure you've kept up your side of the bargain. We send out emails to participants after the fact thanking and listing sponsors as well as making it easy for sponsors to recruit from participants.
• Get Feedback and Iterate: Both from the sponsor, judge, and participant side of things, ask for feedback and take note of what kind of things can be different next time around.
• Mark your success: The Hackathon organizers probably haven't slept in a while. Now would be a good time to buy them a drink.

Obligatory: we've just opened up sign-ups for PennApps 2011. If you're anywhere near the Philly Area this September, sign up for updates and we'll keep you in the loop.

Hosting Hackathons: The Team

This is a second in series of posts on how to host a student hackathon, based on my experience with PennApps, as well as from participating in HackNY and PhillyGameJam and the hackathons at Facebook over the summer.  For other posts in the series, see here.

With finals over, we are starting to lay the groundwork for the next PennApps 2011 hackathon, scheduled from September 2011. As we go through the process, we're making sure to have an organizational structure that ensures that key tasks have owners who are ultimately responsible for getting things done.

It's (theoretically) possible to organize a hackathon by yourself, but the task is pretty large if done right. At least three distinct skill-sets end up being required:

• Technical Your hackathon is going to need a website.  Depending on the technology being used, you may want to provide simple hosting/accounts for participants or unlock a number of phones if you're offering loaner units.  If you have any sort of popular voting or demos after the competition, that part probably needs to be built as well.

  Somebody who understands and can (at least competently) put together a website and administer a Linux VPS somewhere is going to be helpful. We had several people work on the technical side for PennApps, but having a key person understand the entirety of the tech stack meant that there was a central go-to person who could troubleshoot and distribute work.

  Gareth adds: One thing we found in 7Cubed was that it was a huge headache if we used personal accounts for blogs/website registration/etc. This made it so only a single person could make changes to these resources, which caused a bunch of friction. 
  
  The solution there (or at least one we've been using) is to create a your-hackathon@gmail.com (or, if you don't mind configuring Google Apps, hackathon@your-domain.com) and share the password across the people that neeed to register/maintain everything.  This is not a particularly high-security approach, but works splendidly for something limited like a hackathon.

• External Hackathons require a lot of conversations, from sponsors to judges to the University administration to the providers of the location to the students themselves.  We also ended up working with the University's innovation hub and the student government as well.

  Reaching out and keeping all of these stakeholders happy is a job all in itself, requiring a diplomatic approach and an enthusiasm for convincing people to help you.  In practice, the external person tends to also make sense as a reasonable MC for the kick-off and the person who gets enough sleep during the hackathon itself to be coherent enough to run the demo session.

  Gareth adds: There should be a single person operating external relations, or at least a single person assigned to manage each single external relationship. This prevents the "oh I thought you replied to that three days ago!" syndrome.

• Operational We've found that a hackathon demands a reasonable amount of 'running' during the event itself. From registering participants and making sure they have a place to work and sleep to ensuring timely food delivery to ensuring that judges and speakers are able to arrive on time to are well treated during the event, to running midnight raffles, we've found that having a dedicated "behind the scenes" role ends up being critical to a smoothly-running event.

  Unlike the first two, the operational role doesn't require a substntial amount of work until a few days before and during the event. Bringing in somebody who hasn't spent the past several months sweating over the planning details helped us get a fresh perspective and not worry about the quality of day-of execution.

Your organizational structure may have multiple people wearing multiple hats or certain roles split; regardless, make sure everybody on the organizing team (and probably amongst the participants as well) knows who the go-to people are when questions arise.

@Bluffn from HackNY

I was at HackNY over the weekend; our resulting demo is below (starting at the 9 minute mark).

Given a chance, I'm hoping to put together a longer article about solid Hackathon demos and building the product vs building the demo.

We didn't win anything, but (until my __real__ bug) I was pretty happy with the quality and interactivity that we were able to achieve.

Hosting Hackathons: Getting Awesome Sponsors

This is a first in a (hopefully) series of posts on how to host a student hackathon, based on my experience with PennApps, as well as from participating in HackNY and PhillyGameJam and the hackathons at Facebook over the summer.

Organizing a hackathon costs money - even without paying for the space, large prizes and t-shirts, we spent nearly $3.5k (~$35/competitor) for PennApps Mobile on food and drinks over nearly 48 hours. How do you raise something like that?

Possible Funding Sources

Here's what has worked for us:

1) Tech Companies (Google, Facebook, Microsoft, Yahoo, etc)

Software engineers/hackers are in high demand. Recruiting is hard, both in terms of gaining exposure and figuring out who the good candidates are. For tech companies, sponsoring a hackathon address both of those issues. Companies gain exposure by giving tech talks about their APIs and sending their developers to come hang out/answer questions/participate as judges.  Being perceived as hacker-friendly helps get participants excited about working for your company; when participants do apply, they've certainly got at least one project under their belt. Further, Students who are passionate enough about building stuff that they're willing to spend a weekend without [much] sleep are an appealing group of students to be hiring. I don't have exact numbers (yet) but it should be interesting to see how many people ended up getting jobs or summer internships from companies they met through PennApps.

The bigger the company you contact, the more used they are to similar requests for sponsorship and the more likely they are to have a budget for it. Local start-ups (or, if a company wants to get its APIs in front of developers, start-ups in general) can often be a great fit since there's a good chance you can get the founders to come judge or hang out with the participants, but may have less immediate funding to offer; in general, secure most of your funding from well-known companies before reaching out to smaller start-ups; if nothing else, saying (though not directly) "Google and Microsoft are already lined up to sponsor; would you be interested in joining them?" helps establish your credibility as you raise funding.

[from Gareth:] Contacting a University Recruiter will tend to go further at a large company than contacting a friend who works there, since recruiters have a direct budget for things like this.  If you have a friend at the company, ask them to put you in touch with the recruiter directly.

When speaking to tech companies, we made a point of getting either places that students are already excited to work for (Google being the prime example) or those with a reputation for treating developers well. There's some sense of responsibility here for getting sponsors that fit in. 

2) Venture Capitalists

Venture Capitalists have two ways to gain from hackathons: as above, they are able to benefit from helping their portfolio companies recruit from the hackathon talent pool for summer or new-grad positions. The added bonus for VC firms, however, is using hackathons to measure the pulse of the developer community - what phones are people using, what development stacks are popular, what kind of ideas are floating around in the aether. There's also always the possibility of finding a great technical team and encourage them to turn toward entrepreneurship, building a relationship early on.    

3) University Entrepreneurship Groups

At Penn, the Weiss Tech House is a hub for student entrepreneurship and was a natural partner for us to work with, providing free space as well as offsetting all security-related costs. In general, if there's a Technology/Innovation/Entrepreneurship organization or group at your university, sponsoring or being part of a hackathon is right up their alley and makes them look great. Even if they won't be able to help substantially with your budget, they'll be able to help with things like convincing university facilities that it's perfectly fine to hold an event that requires keeping a building open overnight. The Computer Science department or CS clubs may also be game for sponsoring if you need it. All in all, your school should be excited about having a Hackathon: it makes them look cutting-edge and tech-savvy.

[From DJ]: Having some University group giving you official support also makes sponsors comfortable that your event has appropriate backing and is actually going to happen. Consider adding your official university affiliation to your website right at the beginning.

4) Local Groups/Barter Deals

Energy drink companies are the cleanest example of this, but there are others: what sort of products are trying to sell their goods to engineering students/hackers and would be interested in free advertising in exchange for their goods?  We've been able to get discounts from new restaurants in the neighborhood, laptop stickers and web hosting (that I can remember).  The value proposition is simple: let's get your product in front of people that are in need of something exactly like this. A couple of days after the hackathon, we'll send out an email thanking the sponsors; hopefully, enough will convert or buy the product next time they need something like this to make it worthwhile.

5) Don't Charge Students

Your goal (or at least ours) is to maximize turn-out. Free food and drinks (and give-aways) for the course of a weekend is a solid selling point. Even something as low as $5 or $10 creates a barrier to entry. I've heard the argument that charging money filters out people who aren't serious about hacking; honestly though, not sleeping for two days is enough of a filter as it is. Charging students isn't worth it, especially given the alternatives.

Levels of Sponsorship

We had a complex system for levels of sponsorship that will probably evolve as we host more hackathons. If you're going to have tiered sponsorship, here's what you should do:

• Figure out exactly the ways you create value for your sponsors; the above is a reasonable starting point. Distinguish the various types of partners you're speaking with; a food truck isn't looking to get the same thing out of a sponsorship as Google.
• At each level, offer substantially more value than at a level immediately below, a clear and obvious reason that adding more money is worthwhile. For us, this was the Resume Drop: at $1,000 or above, sponsors received a resume pile of all participants who opted in, making contacting and reaching out far less of a pain.
• Create a 'reach' sponsorship level that you don't expect to get: for us, this was the $5,000 'IPO' sponsorship level: certainly, fund-raising would have been easier if we got an IPO-level sponsor, but even without one we made the $2,500 sponsorship level look cheap in comparison. Anchoring: make it easy for your champion at their company go his or her boss and argue for the amount of money you'd like.
• Make sure to collect the actual sponsorships well in advance of the hackathon. Sponsors, even well-known ones, have bailed at the last minute before. The safe thing to do here is to get checks (or payments, however you're processing it) from sponsors at least a couple of weeks in advance.

Contacting Sponsors

Ignoring unsolicited emails is ridiculously easy. For tech companies and VC firms, we had a far higher success rate for funding if we first got introduced through a student that had interned or was interning at the company or through a professor who had worked or done research with them. That said, we were successful by contacting recruiters directly at Yahoo and Bloomberg, amongst others; if you can't find somebody to introduce you, going directly might be worth a try.

For the initial email, something like 

Greetings,

I'm a CS Junior at <University>; we're putting together a hackathon (<link>) on <Date>. I was thinking that <Company> might make a great sponsor, since <reason>.  Let me know if this is something you may be interested in and I'd be happy to send your more details or set up a phone call.

<Student Organizer> 

worked reasonably well.  

We made sure to have at least a simple website up before sending out emails, to add some weight to the operation (IE, this isn't just some random dude emailing to ask for money).  We kept our intro email short in most cases; the longer an email is, the easier it is to ignore. We included a line or two in the email about the exact value proposition (IE, "because you're recruiting on campus and this is a great way to get the word out about your company"), both to ensure that there was at least some hint of the value proposition and to avoid the impression that this was a mass email we were sending to hundreds of potential companies.  Finally, the email was sent from a person rather than from an organization, in an effort to make a personal appeal and begin building a relationship with the potential sponsor.

Assuming the company responds, send a longer email detailing the exact value proposition and the possible ways that a company could get involved (sponsor a custom prize, bring a judge, etc).  To start, though, keep it short, credible, simple, and personal.

What have I missed? How have you done things at your school? Leave a comment.