5 ms·
We've restarted doing 2-day hackathons at my work, and in the spirit of being as inclusive as possible for all team members, we don't require teams to submit co
by sbarre 5y ago
We've restarted doing 2-day hackathons at my work, and in the spirit of being as inclusive as possible for all team members, we don't require teams to submit code at the end.
Some still do though, but in the end we want teams to play to their individual strengths and deliver anything they want that fits the theme.
We do pick themes that are relevant to the business, but there are no other requirements, and we do it over 2 days during working hours (and even provide Doordash and Starbucks cards to the teams for meals and coffee), so there's no "free labour" shenanigans or weekend work.
So far it has been a great success, and I believe we've had much higher participation than if we had stuck to the more traditional definition of a hackathon.
- ketzo 5y agoThe working hours thing alone is awesome -- it sends a signal that "this is a good and valuable thing that you're doing, even if no software for our business comes out of it"
- sbarre 5y agoYep, and let me tell you it took negotiation with leadership to give so many people 2 days away from working on "deliverables" but in the end everyone was convinced that the team building and inspirational value was worth it.
- orwin 5y agoMy team managed to negociate half a day of internal presentation/keynote/formation each friday with the management and all the team (with one monitoring production and the whole team on call still). I thought at first it was interesting but without added value, i was wrong. Not only the teambuilding, but also understanding why your coworker work like they do, it help a lot. We also got a lot of hindsight on why stuff are build the way they are, why we have sometime /25, sometime /24 subnets, all historical debt origin, i think this is a net benefit for the business.
- sbarre 5y agoAbsolutely! It's so easy in large (but I'm sure any size) orgs for teams to not appreciate or fully understand what other teams do, and what decisions get made and why. It's certainly not necessary, but I agree with you that it can really help collaboration and decision-making even at the individual team level.
- mohanmcgeek 5y agoA success of a hackathon isn't determined by participation rate but by the number of prototypes your usual roadmap wouldn't have produced. These pitchathons and deck-athons don't really need 2 days to make.
- sbarre 5y agoHey! Thanks for telling me what my hackathon should and should not be. Ultimately we do them as team building exercises, and so _our_ measure of success is about team engagement, participation and the enjoyment of the participants. Certain ideas absolutely inspire further work on our real roadmaps but that's never the goal. And so on our metrics, they are a success. But thanks for the feedback.
- mohanmcgeek 5y agoI'm not why you're turning combatative. I was pointing what _a_ hackathon should be as the rest of the comment section is discussing. You definitely should continue to measure what you like at your "hackathon"
- sbarre 5y agoYou presented your _opinion_ as fact, as a direct reply to my message, and so I took it in that context, that it was about our hackathons. Also then putting hackathon in quotes in your response, implying it's not a real hackathon somehow (again in your opinion), certainly doesn't help your case. And so this all certainly comes across as a bit of a know-it-all attitude, if you're actually looking for constructive feedback on how to participate in discussions.
- mohanmcgeek 5y agoIt's not just my opinion if the rest of this post is any indication.