Table of Contents

I was one of the lead organizers for MadHacks Fall 2023, a 24-hour hackathon at the University of Wisconsin-Madison. The amount of effort and time that went into planning and executing this was absurd, so I wanted to write a blog post about it and hopefully inspire others to organize more events like this, but hopefully with less stress and better tools and advice for the job.

I might be out of the hackathon organizing scene now, but if you’ve organized hackathons and have advice I’d definitely write a blog post of your own about everything you learned so that others can learn from it :D

My Role

I was unofficially the lead organizer of the event and did pretty much everything except for: judging plans (thanks Sam), day-of event logistics, catering, and taxes (thanks Grace).

However, I did:

• Finding sponsors
• Updating the website
• Designing and ordering swag and banner
• Marketing
• Planning the workshops
• Social media
• Coordinating to reserve space
• Attempting to make a photo booth
• Event Applications
• Probably more that I’m forgetting

The Planning

In this section I’ll try to break down the planning and execution of the event into different segments by the different segments of planning.

Getting a Venue

Luckily we get venue for free since we’re a school organization. So I’m not going to comment on it too much.

What I would do differently:

• Finalize the venue and dates earlier since this blocks sponsorship confirmation and outreach
• We used the educational sciences block, but this does limit our capacity as a hackathon as the space is large although not huge.
  • Having more individual rooms for hackers to go into with their team would be nice instead of like just one huge lecture hall

Getting Sponsorship

I was the main person to reach out to sponsors and to get them to give money, swag, or discounts to the event.

What I did:

I mainly used my LinkedIn premium messages to reach out to companies employees and try to get the direct email of who is in charge of sponsorships at companies that had already sponsored MadHacks before, or other hackathons on Devpost, and just local companies around Madison.

Honestly this was a bit of a nightmare and a grind to get companies to both respond to me and actually be interested in sponsoring. We ended up sending out more than 125 total messages to get in total 9 sponsors, of which 1 was a local company that was growing (Fetch Rewards), 1 had sponsored before (Epic Systems), 3 were almost guaranteed to sponsor (MLH, GitHub through GitHub Education, and AWS Cloud Clubs), 1 was our school, 1 was a company that gave us discount through MLH (StandOut Stickers), and 2 were non donating clubs/orgs that were running workshops (Girls Who Code, and UPL which organized the event).

So in total we got like ~$7,000 in directly from sponsor outreach, luckily we had ~6-7k as left over from previous events. Otherwise, we would have been in a bit of a pickle.

What I learned:

• It’s a grind to get companies to sponsor, it probably would’ve taken less time to just get all organizers to freelance for a few hours and then just donate the money to the event 😭
• LinkedIn probably isn’t the best way to do this, I have LinkedIn premium for free so I thought it would be a good idea but I think it’s mostly a waste of time.
• You might as well try to reach out to food/drink companies to see if they’re willing to give products to the event.
  • I reached out to Bubblr which from what I understand is somewhat of a joint venture with Pepsi, and our school is a Pepsi marketing campus so I reached out. They had a form on their website and with like 2 weeks notice I had 500 cans of Bubblr for 300 person evnet.
  • You might as well reach out to food companies, like I reached out to Culvers and Kwik Trip and a few others but nothing came of it however I think since the drinks were a success it would’ve been worth it to research and email a few more food companies not over LinkedIn
• It’s important to have some tracking software for who you’ve reached out to and who has responded, I used a Google Sheet and it was a bit of a mess but it worked.
• Having different variants of templates of emails for everyone to send out worked well as some people didn’t have experience reaching out to companies and it was a good way to get them started.
• Putting company sponsors on the website is beneficial to the companies! I had someone reach out to me that they got an internship after applying to one of our sponsors and that they wouldn’t have applied if it wasn’t for the sponsorship.

What I would do differently:

• I attempted to hand over some of the sponsorship outreach to others however I think partially because a lot of the work took place over the summer a lot of people didn’t do at least as much as I did on this.
  • Giving people more of a specific quota of companies to reach out to might’ve helped.
• Use Email not LinkedIn
  • I haven’t tried but MLH said that hunter.io works pretty good and given a company’s website it knows the email pattern that company uses so if you know the name of the person you want to reach out to you can probably guess their email, which I had through LinkedIn.
• Templating/versioning emails based on who I was sending it to
  • Some MLH coaches suggested mail merge for this, I think that would’ve been a good idea.
• Making emails more brief & generalized
  • Instead of like having to explain a hackathon and everything like that, I could’ve just been more general and said like “I’m hosting an event at UW-Madison with 300+ applicants and X% are seniors and I see that you have a lot of job openings for seniors and I think it would be a great opportunity for you to reach out to them” or something like that.
• Since finding the right person is so difficult I think it would’ve been worth it to reach out to some non-competing hackathosn to see if they would be willing to share the email of their sponsor’s representative.
• Email Opening Rate
  • It would be worth to invest into some software to tell if recipients opened your email or not to optimize the template further.
  • If we had a low opening rate we could try to change the subject line or the first few sentences to try to get more people to open the email.

Ok that’s probably the longest section of this blog post, I’ll try to keep the rest of the sections shorter.

Marketing

Luckily for this event we were reusing the same graphics and branding that someone the previous semester made because nobody wanted to design new graphics and I wasn’t going to make an entirely new design for the event because I was already too busy so we kept with the same design.

What I did

• Updated branding on older accounts that were lost from pre-covid like Instagram and LinkedIn and Twitter
• Updated website with new sponsors and new information
• Made announcements about applications through social media, our school’s newsletter, and through a few Discord servers that organizers had connections to.
• We attended school org fairs and handed out stickers and flyers to get people to apply
• MLH this year around had target application threshold perks where if you got 80% and 100% of your target number of applications (2x expected capacity) you’d get 1 free perk from them if you reached these thresholds each. So we were marketing it pretty hard and trying to reach these targets.
• Designed & Ordered a backdrop banner with company logos for people to take photos against
  • Idea with this was to create something that companies would consider a nice perk of having contestands share images with their logo on social media afterwards.
• Also see the photo booth segment which is also marketing

What I learned:

• What we worked did pretty well, I think because of how large of a presence the UPL which was most of the organizers had on campus especially in the first few weeks where a lot of freshman and people coming to explore the UPL we had a lot of people interested
• We closed applications ~a month before the event was to be hosted if I remember correctly, we might’ve wanted to do this earlier if it wasn’t for the threshold we were trying to reach.
• LinkedIn was good I think especially for post event as people could tag the account and it shows external sponsors our significance on another platform that recruiters might be more familiar with.
• My plan with the social media was not for it to pay off for this hackathon, but I think having a bigger presence with social media will help in the future for getting sponsors and applicants and just making the community more engaged. I think this is not something that should be neglected

What I would do differently:

• Honestly it went pretty well I think this went great
• I would maybe open applications like a week or two earlier, but we were stalled on finding specific dates
  • However maybe just send out applications form regardless earlier but just say TBA on the date
• Ideas For Getting More Applicants
  • We considered potentially partnering with another hackathon in our region and buying a bus to bring their students to us and back with the agreement that they’d do the same for their hackathon but never got around to this.
  • Not sure if we neccessairly want or should do this but we could’ve advertised through the Madison school district better and got more high-school students. I’m bias because I attendeed a hackathon that made me sure I wanted to do CS in hackathon, but it was run by high schoolers.
  • Probably could’ve targeted other Madison colleges better like Edgewood, MATC, College of Madison, etc.
  • Would’ve been nice to give at least some travel reimbursement but no money, would’ve helped bring in people at least from like Milwaukee.
  • For overnight guests, when I went to MIT for Battlecode 2024 they have a university wide program that lets and incentivizes people travelling to MIT for a competition they’ll match students who live in dorms to host these students. Most of the time it’s not paid for the host but when I did it, it was.
    • This could be something interesting to explore, although it really just depends if the university would allow this, but the university might allow it since we have MIT as a case example.

Applications

This is about sort of the internal hidden application process which was not fun and super annoying.

What I did:

• I decided to use tally.so since the previous semester used it and it would be easy to just copy and paste the form with conditional logic and slightly modify it to use it this year.
  • We specifically improved the form by requiring people under 18 at time of the event to fill out the form in their application step which saved a lot of time over the previous semester.
• We decided we needed to send out confirmation emails when someone applied because in the previous semester not doing this casued a lot of issues
  • Tally did not provide this functionality in their free tier but they did webhooks on submission with the entire content of the submission so I created a lambda function to use AWS’s SQS to send confirmation messages out
• Since we opened applications a little late this part was kinda a nightmare, I decided I wanted people to still be able to apply while sending out different “waves” of acceptances/RSVPs
  • I had like a folder with 50 files of csvs and scripts all trying to cross join between applicants and trying to mark if an attendee’s RSVP had expired since there was no protection on the RSVP form this was all done through a lot of tedious scripts.
  • This would not have been as much of a nightmare if we had closed applications before RSVP, although still wouldn’t have been a clean process
• Used AWS SQS to send out emails in bulk for RSVPs, reminders, day of logistics, etc.
• Used people’s phone number as a key to join against entries

What I learned:

• AWS SQS Generally Works
  • We did see some temporary email withholding by UW Madion’s IT Team because of the volume of emails we were sending out. If I remember correcty these did all clear out within a day but this is also an issue the previous semester faced.
• If given the option, people will mistype it. I had emails, phone numbers, names, and more all mistyped across forms making it super hard to join against.
• Expiration logic on an RSVP form is difficult to handle
  • We did have people just fill out the RSVP form without getting their application approved probably had link sent from a friend.
• I did each wave like every 3 days because our expiration window was 72 hours but this left too many people unsure of their plans if they had to travel up to like 2-3 weeks in advance which isn’t ideal.

What I would do differently:

• We didn’t at least significantly overadmit in advance to Fall 2023 which was a mistake. We had 300 RSVPs however I think we had an attrition rate to about 230 for RSVP’d guests. Then we had about 30 walkins which we accepted them all up to 263 in total out of 300 guests planned.
  • This worked fine in the sense that we had extra food for everyone and extra swag although we probably should overadmit in advance by maybe 20%? Could run numbers to do this smarter and see where our attrition came from, probably mostly Madison students.
• I was going to make a little script with a small database for handling RSVP logic that would give some access code to the form for each person, however I decided to make an entire open source event management platform because of it called ApplicantAtlas.
• As mentioned earlier I should’ve been more prompt with sending out RSVPs/acceptances, but we were also still trying to get more applicants for MLH which was annoying to deal with.

Workshops

We also decided that we should run more workshops than compared to the previous semester. Since the previous semester it was just one workshop that I ran on web scraping.

What I did:

• I helped pick topics of the workshops to run: basic html/css/js, intro to react, intro to full stack, and the same web scraping workshop I ran last spring.
• We ran through all of the workshops about 3-7 days before the event and they were mostly all nicely refined.

What I learned:

• The dry run through is essential to make sure the workshop is up to date and is fresh in someone’s mind. We approached it with
• When I created my workshop I went through an entire ideal target audience for the workshop like what classes they’ve taken, technologies/languages they’re familiar with, etc. I think this was valuable and that all workshops should be required to do this step.
• We need to have some way for participants to catch up with the code you’re typing and some nice way for them to run the code you’re running as close to real time as possible.
  • Like someone typing along in a shared google doc, google colab, or putting the solutions up although I don’t know if I’d reccomend that.
• Putting up on the first slide as people walk in the technologies they need and where to find everything to setup the environment was super effective.
  • Personally I like GitHub Codespaces but when I first ran this workshop issues I didn’t expect to happen like: random Codespaces issues, browser issues, pip versioning issues, and some people didn’t have a GitHub account, things like that which I didn’t initially expect.

What I would do differently:

• We need to kick people out of the workshop room before completely because teams stayed in who were just working on project not the workshop and made noise during workshops and such.
• We probably had too many workshops and not enough social events, I think we just kinda hoped that MLH would save us so we didn’t have to do our own fun/social events although that didn’t work out as well as we had hoped.
• Across the board we needed to be better at variations in voice and engaging people more in the workshops itself as many of them felt too lecturey. I think if an organizer’s role is to run a workshop it can be risky because the workshop isn’t the organizer’s main focus usually it’s running the event like mine was and I definitely was getting pretty exhausted and mine was one of the earlier workshops.
  • Some of the organizers were up for like 12 hours when running their workshop which isn’t great for being engaging and energetic.

Photo Booth

Ok this is a project that I attempted that did not work well enough to be used at the event but I think it’s worth mentioning.

What I did:

• I wanted to make an automatic photo booth that would send emails of the photos out to people who took them.
  • I looked at professional photo booths and they all around us would’ve been like $1,000 to rent for the event so I thought I could make one for cheaper.
  • I used my Sony a6400 and a raspberry pi to take the photos and send them out.
• All of the functionality that I wanted did work, although there were some other weird issues specifically with the library that I was using, you can see all the photo booth code if you want.
• My idea with this project was for more community involvement and getting posts on social media with our sponsors logos in the background without having to wait ~a week for final photos to be filtered and sent out to everyone.

What I learned:

• I used gphoto2 as a python binding, which was the main mistake. I kept running into issues with it segfaulting inside of the C bindings and I couldn’t figure out why and I couldn’t just use a try and catch because it was segfaulting in the C bindings which is outside of the python interpreter.
• One annoying thing was that the FPS was too slow initially so what I had to do because microusb only has so much data it can stream through it at once was lower the quality of the preview and the photo to get the FPS up to a reasonable level. Then when taking the photo I would just take a photo at a higher quality and then send that out.
• I also had a super confusing issue where gphoto2 when taking a photo would be like off by one, and when taking a photo the shutter would move and everything but the photo returned would be the previous photo.

What I would do differently:

• Try to avoid gphoto2 it seemed to be pretty annoying at least with my camera and was the major reason this project didn’t work out in time for the event, at least avoid using it as a python binding.
• Try to use the camera’s specific API or features to take a photo with it, unfortunanely there seemes like there’s a great sony camera API but it’s only for their professional cameras and not their consumer cameras.

The Event Itself

This segment is about the day of the event.

Problems:

• By far our biggest issue that arose throughout the entire event was that Milio’s fucked up our order and delivered our sandwiches randomly put into trays shared together meaning that all food allergens or dietary restrictions were in trays next to sandwiches not of those types.
  • This was a nightmare and we sent out announcements specifying this and I stood at the door asking if people had dietary restrictions or not to everyone who came in to make sure that they knew. I think we did the best that we could but I’m still pissed like months later writing this.
• Check-in wasn’t super fast which was a little bit chaotic like we had our waitlist line which we probably should’ve said to come later because we just had them in a huge line until checkin for the main event ended
  • Luckily we could admit everyone who waited in the line so it wasn’t too bad but it was not great
  • We probably should’ve had more people helping with check-in, for check-in we had a nice internal tool that would scan QR codes that the previous semester organizers created and let us scan for like meals and such to have data.
• Our space only really was two big lecture halls and a workshop room which was not ideal because people went to the workshop room to work on their projects and we should’ve kicked people out of the workshop room before the workshop started (see workshops)
• Judging was a bit chaotic and the room was crammed, we probably should’ve put down numbers on the tables for judging before the event started and had a little bit better communication between food and judging as there were a lot of people in the food line before judging started.
• We had chipolte and we had self service where we were scooping people’s food which took too long per person and is something we should not do again.

Overall though the event went pretty smooth outside of that and we had a lot of great projects and a lot of great sponsors and mentors. Although I did wish that we had more mentors to help out with the projects as I kept getting asked for help but also had to do a lot of other things at the same time which felt bad leaving someone I was helping to go do something else related to running the event.

Our Leadership Structure / Role Distribution

This section is about the leadership structure and how we failed to distribute roles and responsibilities in a great way.

Context

• This was the 2nd MadHacks event since after covid and there was a lot of lost knowledge and experience from the previous semester since it was also mainly run by people who were graduating.
• Most of the organizers were in the UPL which is a self guided student lab/club that is a part of the computer science department at UW-Madison.
  • The way that the mostly club operating lab is structured is super flat and there’s not really a leadership structure, so we didn’t really have a leadership structure for the event and it heavily relied on people picking up work and doing it.
  • I think this is a good thing for the club but not for the event, I think we should’ve had a more defined leadership structure for the event.

What We Did:

• We did assign people different roles like catering, judging, finance, workshop leads, swag, etc. And we did have leads for different segments however I ended up doing a lot of work for all of these different segments, partially because I just knew more about the event and what needed to be done and partially because I was the only one who was really doing work for a lot of these segments.
• People did not really have a great idea of what they were supposed to be doing and didn’t have like “success criteria” for their role and it was super broad and not well defined which probably didn’t help. However, when we assigned the roles we were operating under the idea of giving people responsibility and letting them figure out what they needed to do and how to do it.
  • I think this is a good idea, however maybe we put too many people on each task and these roles degraded into a “committee” without meetings or anything like that.
  • We did have regular meetings in the summer and during the school year but it felt like nobody was really doing much despite constant reminders and asking for updates on different tasks.

What I would do differently:

• We should have had a more defined leadership structure and more defined roles and responsibilities for the event. So that a few people don’t end up doing all of the major work for the event.
  • I don’t think this should be like an application process or anything like that but we need more well defined roles for making the event happen.
• Stagger role responsibilities a little bit better
  • I did a lot of prep work before the event but not much during the event or a week before the event this held true for other people.
  • I think we could’ve done better making sure people’s responsibilities by their role were more spread out like maybe the person handling marketing applications which is really early on in the process could also order swag something like that where they’re not doing all their responsibilities at once.
• We need a better way to communicate what tasks need to be done, who is responsible for what, and when it needs to be done by.
• Also potentially getting more people outside of the UPL involved in organizing the event before hand or at least with helping with day of logistics
  • Having 12 UPL coordinators is great however after considering for shift rotations for the event we should have more than like ~3-5 organizers there especially as many people needed help for mentorship and such.

Conclusion

I know this was a long blog post and it might’ve come across as I was complaining a lot about what went wrong, but I think it’s important to document what went wrong and what we could’ve done better so that we can learn from it in the future.

I thought the event went pretty great and tons of people had a great time and made some great projects and that’s what’s most important and I hope that going forward we can make the event even better and more organized and less stressful for the organizers.

Photo Gallery

Some photos from the event :D

I wanted to thank the most important people the attendees for making MadHacks Fall 2023 a great event and I hope to see you all at the next one!

Back to blog