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).
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
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.
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.
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!
- 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.
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.
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.
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.
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.
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!)
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.
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...".
- 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.
Since you're the lead, try to speak less and try to speak last.
Amplify good ideas. Give ideas a time to live and kill them if they don't work during that time.