This post is not focused on the “right” structure of hackathons (as if that wasn’t completely dependent on the organization). So regardless of whether you are striving for a Google’s 20% time approach, Atlassian’s ShipIt approach, or any other model…there are some common pet peeves that drive me bonkers.
- Innovate now: Seriously, does anyone believe you can schedule innovation? Once a quarter, for 24 hours…I want you to be innovate. Really? Don’t you want your teams to be innovative every day? Don’t look at hackathons as innovation time but as autonomy to explore different priorities. Sure it might result in something innovative and it might not.
- Valuable: Innovation is great. So is fixing crap that never seems to make it to the top of the backlog – and would go a long way in building bridges across departments. As noted above, hackathons are not only for innovation…what can you do to make the organization better within the hackathon period of time.
- Silo Innovation: We can’t claim that the wisdom of the crowd makes for better results but not apply it during the times when we want innovation the most. If every team (and/or department) is doing a different time for hackathons, that means very little collaboration, which will increase the likelihood of less than stellar results. Give people the potential for true cross functional teams during a hackathon.
- Sorry, maybe next time: People will get the first Friday of the month for hackathons. The Thursday before the first Friday of the month…”so sorry, but we really need you to do this work instead. You’ll get two days next month.” Only guess what, that doesn’t usually happen. If you as a leader want to see what happens when you trigger people’s fairness threat, frequently cancel something you proclaim as a benefit.
- Now what: “That’s awesome”, “That’s really going to help”, “Thank you so much”…all wonderful sentiments to hear at the end of a hackathon. However, if you can’t release what you just did or you don’t know what the next steps are for something new….then what we’ve created is more frustration for people. Sometimes there are no next steps but if there should be, people need to be able to accomplish them.
As much as these are pet peeves, they are mine and as a leader that doesn’t mean I get to simply judge others. Instead, these serve as opportunities for others and for me to grow. If this stuff was easy, I wouldn’t be sharing.
What are your hackathon pet peeves?