Personal Story from Running a Hackathon

Diving into Leadership: lessons from leading a hacktahon project

Hackathons can be quite intimidating scenarios to put yourself into. You’re probably meeting a whole load of new people and getting to grips with a new project or programming language. On top of that, you probably only have a couple of days or less to demonstrate your skills by producing something that is either a prototype or a mock-up version of a product.

Now imagine if you were to lead and coordinate a group of people to work on your project idea?

Yeah! That is challenging for many! I’ve been there, and I was intimidated too! So let me share some of the things I learned the first time I led a hackathon project at the first Microsoft Research Software Reactor sprint.

Don’t just focus on the code

There are lots of different things that go into making a project, beyond the code itself. Similarly, there are lots of different people with different skills who may join your hackathon project - not just programmers! Good leaders can identify the strengths of their team, specifically where different skills can be put to best use on a project.

Things like documentation are often left until the last moments of a project even though it’s just as important, if not more so, than the code itself! If you have someone on your team who likes to write, documentation can be kept up-to-date as your codebase changes through the hackathon.

The largest benefit of having a well-documented piece of software at the end of the hackathon is that it will be much easier for your team to continue to contribute to the project after the event is over. The last phase of getting a project into a production ready state takes the most time and effort, but luckily you’ve already documented your scoping process and pathway to getting there! 😉

Find your style of leadership

Given this was my first hackathon as a project lead, I found it very beneficial to be operating as an overseer of the project, rather than taking a deep dive into the code.

I felt much more able to keep track of the project as a whole and could more easily identify if everyone’s skills were being utilised on appropriate tasks. I also found it much easier to mentally switch gears if a team member asked for help or input because I didn’t have to disentangle myself from a coding mindset.

Hackathons can also turn GitHub repositories into a the Wild West of version control 🤠 - so it’s not a bad idea to have someone managing issues and pull requests as new work comes in.

Now just because this leadership style worked for me, that’s not to say it’s right for you. It may take some time but it’s important to test and find a style you’re most comfortable with.

Summary

In short, I think hackathons put a lot of emphasis on the coding aspect of project development (helped along by the unfortunate naming convention, check out the last paragraph of the Bio-IT Hackathon blog), but this is not the sole pillar on which a good project stands.

So my advice to you if you feel nervous about leading a hackathon project is: break the mould. Your project doesn’t have to follow the rules of a typical hack event! Work on and in whatever manner is most suited to your teammates and the task at hand. And most importantly, have fun!

Happy hacking! (Or not!)

The following blog post was written by The Turing Way contributor Sarah Gibson. To read a longer version of this blog, please see the original post on Medium.