Ask HN: How does one lead a team in a hackathon? | Hacker News Reader

Ask HN: How does one lead a team in a hackathon?

31 pointshackathrow25 comments

I'm participating in a week-long hackathon in a few days and gathered a team together for an idea I've been exploring recently. I guess this means people are looking at me to be in charge and that's not a role that comes naturally to me.

A few questions:

- How do you get people excited and aligned to the same vision, so we're all pulling in the right direction?

- My biggest concern is everyone will be remote, so there's no natural space for us to all occupy when working together. I'm looking for advice on how best to structure the week so we actually make it to the finish line. I'm guessing motivation will play a big part here.

I'm definitely not experienced in leadership (I'm just a typical worker drone here) so advice is appreciated!

Edit: Worth mentioning everyone on the team are engineers (with some extra skills on the side).

View on HN

A week-long hackathon, sounds fun!! I think the most important thing to do for a hackathon is often to set and agree with the team on what will be presented at the end. I emphasize presented and not built, because the biggest impact you can have is to influence future activity, not to solve all problems in a week. The story you tell with your presentation will be determine the future of the project, and the week's work should be prioritized based on what will best support the story you want to tell.

That said, it can also be really fun to set the goal of actually solving something with the time you now have, and showing it off. Just try to avoid a compromise where you build something 50% to production and tell 50% of a compelling story... you'll end up with leftover, low-priority homework that doesn't fit into anyone's schedule

I've never taken part in a Hackathon but I thought it was all about building something. Creating a story seems very much like fluff. That's not something I would be interested in

They started as one and the same but as in all multiplayer games, the meta evolves.

As hackathons started giving away bigger and bigger prizes the participants more and more join to won said prizes.

The Judges only get to judge what you present, so what you present becomes the most important aspect of the hackathon.

You don’t need to build a solution to present it.

And here we are.

> build something 50% to production and tell 50% of a compelling story

This seems like exactly what a hackathon should be, a quick hack, proof-of-concept, prototype, etc that you can use to tell the story of what it can be when done to 100%. What's the point am I missing here?

My advice from leading shorter-term hack sessions at work and game jams:

1) Emphasise that the primary goal is for "us to have fun". This immediately takes the pressure off, and helps put the 'thon in perspective.

2) Emphasise a secondary goal of "getting something complete", regardless of whether it's the perfect product or not. For gamejams, it's usually a struggle to get a fully-buildable and playable game out the gate, so setting expectations low re: functionality makes sure you at least have a working product at the end of it. Once you have that, you can focus on incrementally introducing features. Again, this takes the pressure off.

3) Think of it less as leadership, and more of a case of "filling in the blanks". In those times where there is a bit of silence amongst the group in terms of what to do, simply speak up and say what you think could work well. Others will often be happy to just accept that and move forward.

4) If someone else has strong feelings about a certain decision or direction, hear them out and go with it if it makes sense to you. It's more about exchanging ideas as equals rather than the "leader's" way or the highway.

5) Your leadership will come most to the fore when it comes to coordinating a completed product as time wanes on. Often the team can get caught up in what they're doing, so you need to push a little to make sure things are on track. Things like: "OK we have 2 days left. Shall we draw a line in the sand with the database by 12 noon, and then just focusing on tidying things up and making sure there are minimal bugs"?

6) Proactively offer to help or contribute to what other members of your team are doing throughout the 'thon. A good way to to this is to have something specific in mind to contribute, and ask the person if they are OK if you do that. This takes the pressure off them to come up with something you can assist with themselves. Doing this role models good teamwork to the rest of the team, and they may start doing this amongst themselves too.

You are going to learn a lot. Congratulations, leading a team in a hackathon can be an exhilarating, terrifying experience.

Create minimum (but not zero) formal communications and lots of informal routes with ways to find out information.

Slack is a great suggestion along with periodic all-team checkins/reports.

Set clear goals and a sense of mission, with open methods on how get there. As a leader, be involved and check in with team members to help clear roadblocks, connect resources and generally know where the team is at and their plans/progress/obstacles/workarounds is at any time.

A sprint model can work well, with a board of tasks and periodic checkins on process.

Past experience for me is that we all usually get real high, come up with some terrible ideas and chaos ensues.

Who knows what value we've added to the world at the end of it, but we've learned a few things and had some nice time away from being serious computer people.

In other words, don't take yourself too seriously, and enjoy the time with your friends. Don't get too tied up in details, structure and just focus on how you can grow through the experience.

Looking at the thread though, everyone else seems to be at serious computer people events, so my experience may not be relevant!

I led a hackathon team in an in-person 24 hour hackathon, so it's not exactly the same but here's my advice:

- Getting people excited means giving a good elevator pitch and following up with any specifics you've mapped out. Tell them what you're trying to solve, why you're solving it, and how. Engaging with feedback/criticism of the plan will help get interested people on board. Make sure you try to match people's interests to the work to be done. I.e. assigning a backend-oriented person to do frontend work is a great way to kill motivation (unless of course they've requested it).

- For remote: make sure you have clear lines of communication and a clear delineation of work. Be available at a moment's notice to answer any questions.

-- a Slack channel (or something similar) for your team for ad hoc, asynchronous communication is a good idea

-- daily standups over video/voice would be a good idea. Make sure to take longer conversations offline as to keep everyone productive.

- As far as structuring the week that's harder to answer. Map out the work to be done, break it up by person, and then giving a loose timeline with some wiggle room. Something like a Gantt chart could help here, but there are a number of ways you could organize this.

Don't focus on controlling everyone and the execution. Just create an environment where others can help. If you see task X, ask the team does anyone want to do X? It should do Y and Z requirements.

Focus on making sure you can deliver the MVP for your core idea and let people deviate with their ideas as long as it doesn't compromise the core MVP.

Hackathons can be chaotic and a time pressure, so don't add trying to be a perfect leader on top of those pressures.

I've attended 14 hackathons and captained many of the teams so I think I can answer this question. The two big things are to assemble the right team and set expectations early. Everyone is at the hackathon for a different reason and everyone has a different specialty. Find a frontend guy and a backend girl and make sure they get to work on what they want to work on. Make sure everyone is on the same page with the project idea: no one is going to stay up all night for free to work on an idea they don't believe in. Set expectations for how many hours everyone is working, how often everyone should be checking in and pushing code, etc. Set a good example as well by doing your part. Be flexible and try to find the natural compromise on points of disagreement because there won't be time for extended arguments.

A week long hackathon is a long time. People will have other things they need to attend to. Try to get everyone to schedule their time in advance and be open about what other plans may lie ahead.

And remember to have fun! The most valuable thing that comes out of hackathons is your friendship with your teammates. Keep this in mind whenever disagreements arise.

I've always been interested in going to a hackathon but I feel like I would be a burden due to my lack of experience and my basic to intermediate knowledge. On the other hand I think just being there would be a great lesson, but how does one get started there? I don't even know how things happen in there. You go asking around to see who needs a hand?

It depends on the hackathon. Pretty much all of the hackathons I've seen have a way to try to match people with uncompleted teams (or other people).

I used to feel exactly like you do. In order to get my "feet wet" the first thing I did was take part in the organization of a local hackathon as a volunteer.

You haven't said how big your team is.

From my experience, if your team has more than 4-5 people, you're entering a territory where managing people is going to become a significant role itself and not something that can be done on a side as you do your regular engineering. Teams this big often tend to either not finish at all or break up into several smaller ones. It's much easier for smaller teams to cooperate efficiently.

A week-long hackathon sounds like fun!

I think one of the best ways to get people excited is to Be excited; people are drawn to passion and some of that is probably already showing if you've managed to bring the crew together. I agree with a lot of the others in making sure the priority is to have fun, set expectations, don't take it Too Seriously, and facilitate communication.

I would actually recommend creating a Discord instead of a Slack for one big reason: Voice Chat Lobbies. I personally feel like they provide more of a Presence compared to slack channels and text on a screen. It's easier to see who's online and actively working on the project, it's easier to spontaneously just chat or talk to peeps. It's a lot more like being in a room together compared to a slack channel. If you have to break off into smaller groups, it's an Option.

For bonus points, this might be obvious but maybe set up a kanban board to help outline features & keep everyone organized and on the same page.

If it's a competition: find the member of your team that is best at presenting/pitching. Make sure they set a lot of time aside for practise, because to be honest that's the only thing that actually counts in the vast majority of hackathons.

I kind of burned out on them for this exact reason: I toiled away making a working demo of my idea only to watch teams with a couple of design wireframes and a splashy presentation win. I thought a hackathon was more connected to the old school notion of programmers hacking things together... the vast majority of the time it is not. But hey, it is what it is, just know what you're getting into going in!

(I wish there were more hackathons where it was required to demo a working prototype. Would emphasise the "hack" aspect of the whole thing!)

That's why I prefer game jams - while it's still possible to "hack" your presentation, it's usually much harder - and some jams even focus more on ability to play each other games rather than just present them on the stage, so faking it becomes impossible.

The way a conductor behaves at a jam session play along with or get out of the way.

The fact you think there is a "right" direction means it is not a hackathon but a work session.

If this not the programmers initative expect them to be looking for new jobs. For many programming is not a spectator sport.

> The fact you think there is a "right" direction means it is not a hackathon but a work session.

> If this not the programmers initative expect them to be looking for new jobs. For many programming is not a spectator sport.

I am also a programmer :) This is a real hackathon, with no expectations of "work" that needs to be done. I just want to make sure we hit the finish line with an MVP is all.

Seek to have first MVP done two-three days before end of week. That is when it should be "relaseable". The rest is buffer + testing + additional features.

Is the goal to win the hackathon or just hack together the best MVP you can in a week?

If your goal is to win start practicing your pitch early. Choose who will talk from the team and while the rest of the team finishes the product they should be identifying the problem you are solving and practicing the pitch over and over again.

The last 3 day hackathon I did we started practicing at the 1.5 day mark and smashed it. Despite our product consisting of just 17 lines of python code (ok with 500,000 lines of modules behind it) bechause we were comfortable pitching our product as a business solution instead of "Look how cool our ML/AI whatsit is...".

I have participated in a few hackathons. My teams have won some. And they have lost some. All of the ones I have participated in were 24-36 hours long. This comment is probably not that useful for OP, but I will still publish it anyway. Here is my (current) recollection of thoughts:

- In these short hackathons the probability of winning is inversely proportional to the amount of new technology you are using. I have seen teams quit because they got stuck in a particular issue and couldn’t finish their prototype in time. A similar thing almost happened to one of my teams. This is also a bit sad because it means that improving your chances to win implies reducing your chances to learn.

- Leverage frameworks, libraries, and templates. My go-to example for this one is a web server. Imagine your team tries to implement a web server in C. If the team you’re competing against uses Django you are going to have a hard time to compete. My secret leverage is Unity. With Unity, you can create something in 3D very fast that looks nice with very few assets. Remember, unless the jury explicitly says otherwise, they care more about the product than the code.

- Get your team on the same page. Because of the previous points, the worst thing that can happen is that some people on your team try very hard to win while others are just in for the experience. This will create friction. Get your team on the same page before starting. I can’t emphasize this one enough.

- Clear communication. On one hackathon one of our members left for dinner for what was going to be 2h. He was absent for about 4-5h. What annoyed me from that experience was the lack of communication in our team.

- I like to think before the hackathon starts there are no leaders, only developers. I believe leaders on short hackathons raise to the occasion on the spot. I’ve done it. But that wasn’t predetermined by any agreement. I’ve also followed people who led me. Whatever your role is, remember: you’re not an authority; don’t act like one. Responsibility is always collective.

- Principle of least effort. I’ll repeat it: Your jury cares more about the product than your technology. If you only have 24 hours, then you don’t have 2h to spare to discuss the design. You should optimize the ratio of results/time.

- (Post-Corona tip, whenever that comes) Come prepared. Come with Ethernet cables. A switch or two. Your batteries charged. I’ve seen wireless networks go down on these hackathons. On that occasion, our team didn’t even notice it because we were wired in.

For hackathons where you choose your own goal, scope is the killer. In my experience you're either stepping on each other the whole time or it's too big to finish. I've yet to see, the Goldilocks hackathon project, but if you can find it, that'd be ideal.

Focus on fun, next time get your company's marketing team involved to design special hoodies for the event, limited to participants. Trading swag for participation worked well for me

Define the communications channels and clarify what is the signal that a decision is made versus when discussions are still happening.

Since you're the lead, try to speak less and try to speak last.

Choose your tools beforehand and get them set up. Get the team set up on those tools.

Amplify good ideas. Give ideas a time to live and kill them if they don't work during that time.

Reply on news.ycombinator.com