The Goldilocks of Hackathon Challenges
The six things every hackathon / unconference / barcamp needs are well known, namely:
You get all those ticked off and you have an event - my favourite bar, Saturday at 1pm-4pm, "HackMike 2018", "Increase Mike's Knowledge Of Diversity", you and me, and a load of knowledge and techniques ... see, that's an event. Or you could call it catch up with a buddy, but once you have the six items in place the only thing you're increasing is scale - how big and shiny do you want your event to be?
btw: it has to be ALL of the items, you can't have an event that doesn't tick off each item; and nor can you have an event that doesn't focus on each item to ensure the best you can get - it's a great way to split up your 'committee'/organising team ... plus a layer of logistics underneath each one.
First some definitions that I use:
Let's take the Purpose first - this is tied up in the event's Identity. A good purpose is present in the naming of the event, the tag line of the event, and it is expressed in any logos and design elements of the event. The Purpose is the reason the people want to come along to the event.
Good purposes:
Bad purposes:
So what makes a "good" purpose and what makes a "bad" one - level and desired outcome. If the purpose is way too woolly it can be akin to giving people a blank piece of paper and saying, "Go on, get creative" - it can be done of course, and some people love that, but most of us need a little guidance a few hints as to what on earth we are here for.
As for outcome the best are purposes that explicitly state an outcome that benefits all concerned, most likely a wider community, or even the whole country. And when you have that defined audience, pop it into your purpose - "Save One More New Zealand Life". If the purpose obviously serves just one party then it will feel out of balance - you will know when this happens as you send a disproportionate amount of your time discussing IP ownership, access to internal systems, how the event will be PR'ed/spun, and how are to be technically constrained.
Just like Goldilocks and the three bears we have "too hot", "too cold", "just right", or perhaps you prefer, "too soft, "too hard", "just right".
Challenges that are too high level, ones that don't really have an immediate outcome that would be of benefit to someone, make for "bad" challenges. However, don't throw them away as they almost invariably end up making a great event Purpose. Whilst "Free Up Peninsula Transport" maybe too high for a particular challenge it makes for a good overarching theme to the whole event.
Challenges that are too low level are just bloody awful. These are the "We have a problem API x and need help re-developing it to ensure we can do blah blah in the future". These are challenges that don't belong in a Hackathon as they are BAU for an organisation who is likely to have an IT Department and/or the money to get on with it and solve their own damn problems. And if they don't then sure, ask for external help ... but be aware it's the bread and butter of a tech person's life so don't expect it to be free.
And then we have those that are "just right". My rule of thumb for these is if you can discuss such a challenge with 3 different parties and they quickly "get it", and can come up with wildly unrelated potential projects to resolve it then you're on the right track. If the creative juices are engaged as you discuss a challenge, if people gravitate to it with ideas, if people say, "Oh yes, I have that problem" then you're on the right track.
But remember, not too many challenges - even if they are "just right" one can have too much porridge and that'll just make everyone sick.
I thank Dascha Elliot for the initial inspiration for this article
I help people, organisations, and agencies that need to engage with communities in order to solve hard problems - I do this using the hackathon framework. Contact me if this is you.
- Suitable venue
- Convenient date / time
- Engaging ddentity ("logo")
- "Just right" Purpose
- Relevant people
- ALL the "Playdo"
You get all those ticked off and you have an event - my favourite bar, Saturday at 1pm-4pm, "HackMike 2018", "Increase Mike's Knowledge Of Diversity", you and me, and a load of knowledge and techniques ... see, that's an event. Or you could call it catch up with a buddy, but once you have the six items in place the only thing you're increasing is scale - how big and shiny do you want your event to be?
btw: it has to be ALL of the items, you can't have an event that doesn't tick off each item; and nor can you have an event that doesn't focus on each item to ensure the best you can get - it's a great way to split up your 'committee'/organising team ... plus a layer of logistics underneath each one.
"Just right" Purpose
Having organised a number of hackathons I have discovered that one of the traps for the inexperienced is to target the challenge / purpose of the event either too high or too low.First some definitions that I use:
- Purpose: the reason for the event existing
- Challenge: an area someone would like the event to tackle
- Project: what a team ends up working upon
Let's take the Purpose first - this is tied up in the event's Identity. A good purpose is present in the naming of the event, the tag line of the event, and it is expressed in any logos and design elements of the event. The Purpose is the reason the people want to come along to the event.
Good purposes:
- Save One More Life
- Free Up Peninsula Transport
- Creating Healthier Kiwi Homes
Bad purposes:
- Use Government open data
- Collect Ideas To Help Agency X
- Fix The xxx ICT System
So what makes a "good" purpose and what makes a "bad" one - level and desired outcome. If the purpose is way too woolly it can be akin to giving people a blank piece of paper and saying, "Go on, get creative" - it can be done of course, and some people love that, but most of us need a little guidance a few hints as to what on earth we are here for.
As for outcome the best are purposes that explicitly state an outcome that benefits all concerned, most likely a wider community, or even the whole country. And when you have that defined audience, pop it into your purpose - "Save One More New Zealand Life". If the purpose obviously serves just one party then it will feel out of balance - you will know when this happens as you send a disproportionate amount of your time discussing IP ownership, access to internal systems, how the event will be PR'ed/spun, and how are to be technically constrained.
Challenges
If we move on to Challenges they also come under the "level" criteria, but even more so.Just like Goldilocks and the three bears we have "too hot", "too cold", "just right", or perhaps you prefer, "too soft, "too hard", "just right".
Challenges that are too high level, ones that don't really have an immediate outcome that would be of benefit to someone, make for "bad" challenges. However, don't throw them away as they almost invariably end up making a great event Purpose. Whilst "Free Up Peninsula Transport" maybe too high for a particular challenge it makes for a good overarching theme to the whole event.
Challenges that are too low level are just bloody awful. These are the "We have a problem API x and need help re-developing it to ensure we can do blah blah in the future". These are challenges that don't belong in a Hackathon as they are BAU for an organisation who is likely to have an IT Department and/or the money to get on with it and solve their own damn problems. And if they don't then sure, ask for external help ... but be aware it's the bread and butter of a tech person's life so don't expect it to be free.
And then we have those that are "just right". My rule of thumb for these is if you can discuss such a challenge with 3 different parties and they quickly "get it", and can come up with wildly unrelated potential projects to resolve it then you're on the right track. If the creative juices are engaged as you discuss a challenge, if people gravitate to it with ideas, if people say, "Oh yes, I have that problem" then you're on the right track.
But remember, not too many challenges - even if they are "just right" one can have too much porridge and that'll just make everyone sick.
I thank Dascha Elliot for the initial inspiration for this article
I help people, organisations, and agencies that need to engage with communities in order to solve hard problems - I do this using the hackathon framework. Contact me if this is you.
Comments
Post a Comment