Five Lessons Learned from Participating in a Hackathon
I must be a complete UX design geek. When one of my friends and cohort companions told us about her experiences winning a hackathon only a few weeks after we began job hunting, I was jealous. No lie. It sounded like a lot of fun and I tried to find one to participate in. Problem was, I didn’t know where to look. When I searched for hackathons on LinkedIn, I was only seeing completed hackathons. Everyone was either celebrating their victory of winning, or it was just being announced that a successful weekend was had by the hosts.
Then, the DevPost.com website was shared with me. I could finally see a list of open hackathons available in one place. I found one that was interesting to me and signed up. However, the one I found required a completed project- backend, frontend, etc. Since I am a designer and not a coder, there was no way I could participate alone. I let everyone else signing up for the event know I was in search of a team on my profile, and a few days later I received an invitation to participate on a team. And I just knew we were going to win.
We did not win.
I don’t want anyone reading this to think that I did not enjoy being on the team and that winning is everything. It truly is not and I find myself looking forward to taking part in the next Hackathon with the same team. However, I did learn five important lessons from participating in this hackathon.
- You need a team leader. A team leader makes sure everyone’s voice on the team is heard, but also makes sure that everyone clearly knows their role and that different portions of the project are completed by certain times. More on this in a bit. At the start of this hackathon, we had a clear leader. The person who reached out to me and invited me to take part had already competed in several hackathons. However, right before the start of this event, he had been extended a job offer. I would have taken it as well, and he fully admitted that he could not commit the kind of time that the project needed, but he would stay on to help as necessary. Unfortunately, there was no one to step up and take his place. For many of us, it was our first hackathon, and we had no idea what to do.
- You need a plan with deadlines. We planned out our website, discussed what should be on there, but did not set concrete expectations for each team member with a deadline for when something needed to be finished before moving on to the next step. This is where a little agile methodology should have been put into place. Knowing what could be feasibly accomplished during the hackathon and prioritizing those things would have helped. From there, we needed to determine when each part had to be done so the next step could move forward. I knew what I could accomplish during that short time frame but I was not sure what they could and couldn’t get done. I am familiar with HTML and some CSS, but they were using some coding that I hadn’t even heard of before. I was deferring to them how long they would need to code a feature but it was never communicated to me when was the latest that it had to be done. This caused a lot of confusion and a lot of missed opportunities. And, speaking of missed opportunities-
- You need to know you are not in control. This was perhaps one of the hardest lessons to learn. I finished my piece- the design work- and then handed off my assets. Once I let it go, I didn’t know if they had even looked at my design or not let alone incorporate the code for it into the webpage. I just had to trust! I wanted to help so much but knew there was nothing more that I could do. And this is why-
- You need communication. When a team member is lost, it should be a safe place within your team to admit that they are lost and that they have questions. It is important to answer those questions ASAP. I say this only because there were a few times when I was trying to get direction for my designs and asked the same question a few times looking for an answer that never came. That being said, our team was definitely a safe place, as one of our team members tried to learn React by watching YouTube tutorials over a series of a few hours. (The original team lead was supposed to take on that role and encouraged this other member to take on the task when he knew he couldn’t commit.) He felt really bad and kept apologizing that he couldn’t do it in the amount of time we had, that he was really lost and he was afraid he messed everything up. However, it was unnecessary because we all understood the situation. That leads us into my fifth lesson-
- You need mercy and grace. Yeah, he felt really bad because he couldn’t learn it and was afraid it was all messed up. Did it cost us the competition that he couldn’t finish? Maybe. Were we all okay with it? We were. It didn’t matter that we weren’t going to finish strong, or even finish at all. We still had fun and each one of us developed certain skills that are more important than winning a competition.
I also thought I would ask my friend about her successful experience if she had learned any lessons from it. She told me that “it’s definitely about the experience and connections you have. I would say keep doing them, keep growing through them.” I couldn’t agree more.
No one could enjoy my designs at the hackathon, so I’m including the home page here. If you would like to see the rest, here is the link to this post on my blog, which contains the rest of the designs. Enjoy! It’s not my BEST design work, but a weekend isn’t much time to come up with anything completely fancy. (By the way, if my wording gets a bit confusing in parts with the post on my blog, I’m going to beg your forgiveness- rule number 6 about hackathons is to be prepared for some extremely late nights. I wrote it at 11 pm on a Sunday night- after being up practically all weekend with the hackathon. I was exhausted and could barely keep my eyes open. I edited this version prior to publishing.)
If you are a young designer just starting out (or a career changer like myself) I feel like a hackathon is like a microcosm representation of what you’ll experience on the job. All these lessons still apply. A project manager keeps everyone on track, with an understanding of what can be accomplished in the time frame given, staying cognizant of the deadlines, and keeping the coffee and the communication flowing. Just perhaps on an even larger scale. Every designer should participate in a hackathon (or two) at some point in their career, but especially early on. Quite possibly the next one you compete in could be your winning one- mine was!
