Hackathon? No, not yet. Ideas Splurge!

by Chris Gathercole

In many cases, the answer to “How do you organise a Hackathon?”

appears to be “You don’t. What you need is an Ideas Splurge.”

Giving away the punchline: In crude terms, an Ideas Splurge generates more well-thought-through ideas per person in less time. More people meet and talk in less time. It is more inclusive, and less off-putting to newbies. It can be arranged at shorter notice, and there is less to go wrong. It leaves folks wanting more, rather than, as with many hackathons, “well, I’m glad that’s over”. An Ideas Splurge is, fundamentally, more effective at tackling the disconnects between disparate groups within a company.

Why do a hackathon?

Hackathons have become much more of a thing in recent years; high profile festivals of PR-tastic goodness. So much so that, rather than just being pushed for by the techies themselves, Hackathons are being mooted by senior management.

There are many good reasons to run a hackathon. They get the competitive juices flowing among the dev group, and promote the idea that this is a company where devs are given a chance to express themselves. They provide an opportunity for folks from different parts of the business to mix and gets them working together; a complete change of pace, with different people, without the same old same old. They are a chance to have a go at that thing which has been bugging you for ages. A chance to show off. A chance to circumvent the prioritisation process and get some sneaky dev work in via the side door. They are (or can be) big, publicity-loaded events, suitable to be shouted about internally and externally. And hackathons are perceived as a chance to bring lots of minds to bear on a particular sticky problem

Why not do a hackathon?

Let’s look at that list of reasons again.

• it gets the competitive juices flowing among the dev community
• it promotes the idea that this is a company where devs are given a chance to express themselves
• it is a chance for devs to show off

Hm, ok. Is your biggest problem a shortage of competitive juices? Improving the “it’s a good place to work” vibe is never a bad thing, but why might it need improving?

• it is a chance to circumvent the prioritisation process and get some sneaky dev work in via the side door

So, who’s got a prioritisation process which is leaving lots of good folks dissatisfied?

• it is a chance to have a go at that thing which has been bugging you for ages
• it is a chance for devs to show off

These are likely to be symptoms of how the current work situation is not as good as it could be. These are always bubbling under, minor annoyances, but if they have become big enough that this is truly and urgently an itch you feel needs to be scratched then is a hackathon actually the best way to tackle them? Is this really the only chance your devs get to show off? Do they not get the same pleasure for their day jobs?

• it is a big, publicity-loaded event, suitable to be shouted about internally and externally
• it is a chance to mix up folks from different parts of the business and get them working together
• it is a complete change of pace, with different people, without the same old same old

And here we get to some of the deeper reasons why hackathons can be a good thing. If you do not have good synergy between different parts of the business, particularly between IT and everyone else, that right there is the thing to fix. And yes, hackathons are a way of tackling that lack of synergy, or the negative perceptions between different groups.

• it is a (perceived) chance to bring lots of minds to bear on a particular sticky problem

Yes, definitely. This also is why folks run brainstorming meetings (where the evidence of effectiveness is not great). However, note the word ‘perceived’. There is a better way.

Add into the mix that hackathons are a lot of effort to organise, and a big commitment from everyone involved (at least two longer-than-9-to-5 days out of the working week). They are a daunting prospect for neophytes and teams of folks who have never before met or interacted in a sustained fashion, and highly stressful (if done properly) even for the experienced contestants. When it gets down to the nitty gritty of working on a hack, it is an exercise in a succession of increasingly painful compromises of the original idea. The whole event is sensitive to the choice of prize categories, the expressions of what constitutes ‘winning’. And at the end, there is a high risk of a “so what?” reaction from the rest of the business if the hacks as presented are not seen as relevant to their ongoing concerns.

What then, if not a hackathon?

I would humbly suggest that a better first step is, for want of a better phrase, an ‘Ideas Splurge’. This is proving to be a more effective use of the same people in a shorter length of time, with more immediate benefits, and in fact improves the chances of subsequent hackathons going well.

Let’s itemise some reasons why you might have arrived at the start of this article with the question “How do you organise a hackathon?”. Do any of these ring some bells for you?

• you are sensitive to a lack synergy in your business, particularly between IT and everyone else
• more than that, you have reached an impasse between IT not delivering fast enough or well enough and everyone else loudly demanding more and more. It has become confrontational. The groups on both sides of the barricades know for a fact that the other side is irrational and “just doesn’t get the issues”.
• you’d like to increase awareness and sensitivity in IT of what the rest of the business is battling with
• similarly, you’d like the rest of the business to have a better understanding of what IT does and could do
• the ‘command and control’ approach to deciding on and prioritising projects feels increasingly like flogging a dead horse
• right now you have a big knotty problem which is not succumbing to the current approach
• there are lots options on the table and it is not clear where to start
• you’d like to explore a different way of working
• someone suggested a hackathon

An ‘Ideas Splurge’?

It is quite simple. The cynical might dismiss it as “just talking more”, or wax lyrical about the awkward name, but that does it a dis-service.

We can define the aims of the Ideas Spluge event as

• air and share the hopes and dreams and hindrances of different groups and stakeholders of the business
• create a shared info repository of all the above
• demonstrate that each group in the business does in fact want to understand and help the other. The “them” and “us” could be stakeholders and IT, IT and IT, the business and IT and Product, or any of an excitingly wide variety of dysfunctional relationships.
• make some robust personal connections between individuals in different teams
• explore a given problem space (perhaps “how are we going to implement the company’s new strategy?”)
• create a productive buzz that lasts into the following days and weeks, and ideally leads to qualitative improvement in how the groups interact
• de-risk an imminent hackathon (I throw this in here because hackathons are still A Good Thing ™)

And here’s how to achieve them.

A working day, with everyone including stakeholders

Set aside a working day for as many folks as you can round up from the various groups. The more, and the more diverse, the merrier. For this you’ll need a large room, laid out so it is easy for small teams (of 3–4 people) to form. Get the stakeholders in there. No excuses. They don’t have to stay for the whole day, but they absolutely should be there contributing at the start, and to witness the presentations from each of the 3 iterations.

Set the scene

The start is roughly an hour of setting the scene. You should kick things off by briefly stating what you are hoping the day will achieve, and the day’s schedule for achieving it. 10 minutes, tops.

Then the quickfire, noisy stage begins. Don’t skip this bit. It should take an hour or so.

Air everything that may or may not be relevant. Everyone offloads all their mental baggage. Stakeholders, what do you actually want? What can you and your group do? What systems and APIs are available? What can’t they do? What would they like to do? What are the biggest “if only”s? Frustrations? Yes, bring them on. If there have been meetings prior to this to discuss various groups’ capabilities, then make sure the outputs are restated for the benefit of this gathering. Anyone can question anything and anybody. The Stakeholders, especially, should come prepared to defend and explain and embellish.

Make sure this is all written down as it is uttered. The compilation of all this is gold dust. You could stop now and the day will still be a win.

The last part of the start is the even-quicker-fire idea creation. For 10 minutes, everyone shouts out any ideas which have sprung into their heads as a result of listening to the previous info dump. Nothing is too stupid to suggest — absolutely no filtering. Riff on the previous ideas. Use a dumb idea as a springboard to a non-dumb idea. Don’t dwell on anything. More is much better than better, aka quantity over quality.

Keep asking questions, especially of the stakeholders (they should feel under considerable pressure to ensure everyone knows and understands all the issues and nuances and possibilities and fears washing around at the stakeholder level).

And again, make sure all the ideas are captured (they will crop up throughout the day).

Iteration 1

The scene is set, and iteration 1 begins. At last a bit of sanity. Filter those ideas. For 5 minutes, the group quickly highlights particular ideas or combinations of ideas which hit the spot. Nothing more is needed than a verbal thumbs up, or a tick against the item(s).

Now the awkward bit, team formation. 5 minutes to accrete teams of 3–4 people each, from different groups around the company (Doesn’t matter too much if chums sit together for this first iteration, because the next two iterations will shuffle things up properly.) The team-forming can happen in at least two ways: a team forms around an idea, or a team forms and then agrees on an idea.

Each team tackles one or more ideas for the next hour or so. There should now be a great deal of talk, talk, talk. There is insufficient time to actually build anything substantial (although, see the Ads team’ Ideas Splurge), so quick scribbles with a Sharpie and lots of hand-waving is perfectly satisfactory. Dig into the whys and wherefores and why nots. Highlight anything else that comes up along the way.

Time’s up. Now each team has two minutes to present the fruits of their deliberations. For this phase, make sure the stakeholders and any interested parties are called back in. They need to be here to feel the energy in the room and provide feedback with their questions and body language. Either things are going well, or the room needs a nudge in a more useful direction.

Two minutes per team? Yes, they need to compress their 1hr and a bit of discussion into something vaguely presentable. What thoughts occurred? What would be involved? How might this happen or not happen? “it was a stupid idea” is a fine as a conclusion. Blue tack, flip charts, Sharpies, hand waving: all good. Questions and suggestions from the audience are to be encouraged.

Make sure these are recorded on video, and the notes labelled and preserved.

LUNCH !!! It is ok if everyone leaves the room for a bit and goes off and does their own thing.

Iteration 2

And we are back for the same again, but first, take two minutes for a quick burst of introspection. Would the collective like to adjust anything? Perhaps 1hr and a bit more, or 1hr and a bit less?

Emphasise the next iteration is on new ideas only. This is important. If an iteration 1 idea is really sparkling, work on it tomorrow. Meanwhile, breadth not depth is the order of the day. Pivot to a new idea.

For team formation, mix it up. Move around the room. Think “speed dating”. Find a new team to join, new people to talk with. Each team picks a new idea from the earlier list or they agree one among themselves there and then. They start talking and hand-waving and sharpie-wielding.

Stakeholders and anyone with an interest back in the room for the presentations. Don’t forget this bit.

End with a short break. This is known to help with creativity, and bladder control.

Iteration 3

Once more into the breach.

This is hard work. Everyone is performing at a sustained, high energy level. There is no hiding in a corner for a breather.

Things might run out of steam in the 3rd iteration, but don’t fret. If some teams simply start chilling out and having a chat, that is also a win. They still present a summary of what they chatted about.

Perhaps this final round of presentations could include a summary, a re-presentation of all the previous iterations’ ideas, now compressed down to one minute each, perhaps by members of the teams who did not present it first time round. Again,condensing and rephrasing the thoughts can help with creativity, giving a chance to add in points which were missed when first presented or had occurred since.

And that’s it. Well, actually, for most of the room that is it. For the organiser, remember all those notes and recordings? They need to be preserved, tidied, typed up, summarised, categorised, mined, shared.

What do you get out of this?

You get

• the initial aggregation of all the capabilities, hopes and dreams and hindrances, of all the participants
• the lists of ideas, both unfiltered and filtered, and then
• some ideas tackled in more depth. For a room of 20 people, 6 teams of 3ish, 3 iterations, minus inevitable casualties, you might have 15+ ideas which have been explored in sufficient depth that sensible conclusions could be made about them.
• perhaps 50+ new, strong connections between people in the company across disparate groups
• the stakeholders now aware that all the various groups, regardless of previous issues, do in fact care and want to understand and help and contribute
• some folks sufficiently pumped about some of the ideas that they are straight into them the next day
• some ready-made teams and ideas, and a good shared understanding for when you do get to organising that hackathon after all.
• the stakeholders having their statements challenged in a positive, constructive way

So why is an Ideas Splurge better than a Hackathon?

In crude terms, an Ideas Splurge generates more well-thought-through ideas per person in less time. More people meet and talk in less time. It is more inclusive, and less off-putting to newbies. It can be arranged at shorter notice, and there is less to go wrong. It leaves folks wanting more, rather than, as with many hackathons, “well, I’m glad that’s over”.

An Ideas Splurge is, fundamentally, more effective at tackling the disconnects between disparate groups within a company.

If you still want that hackathon (and you should), the Ideas Splurge has prepared the ground for a subsequent hackathon, both in terms of identifying the challenges and themes, and in readying your good folks (from across the company) for working together.

Any questions?

3 iterations?

• see the next questions

1hr and a bit to tackle an idea ?

• this seems to allow sufficient time to dig into an idea and get a good appreciation of the issues, and yet not get bogged down in nitty gritty.
• The “and a bit” gives some wiggle room for the group to introspect and tweak things.

So, why 3 iterations?

• that fits neatly into a working day, given the 1hr and a bit per iteration
• the first iteration will be a little stilted, and the subsequent iterations will have a chance to move along a bit more smoothly, efficiently, productively
• repeatedly revisiting the list of ideas is useful

Do we need to have a ‘best’ idea and prizes etc?

• The jury is out on this.
• Personally, no.
• Feedback from the stakeholders and the rest of the group is sufficient.
• A hackathon is meant to be competitive, with a very different vibe.
• The Splurge is a synergy distillation process, and ‘best’ takes something away from that.

Do you need to provide lunch in the room?

• Not really. It actually helps the creativity to have a short break away from the room.

Any prep needed?

• by the attendees? no.
• by the organiser? yes. Make sure a good, representative mix of folk participate, especially the stakeholders who need to be here to hear and be heard.

What’s next?

• just analysing the data should take a while
• encourage the cross-pollination to continue
• go back to the group/teams to take some of the ideas further
• you can now go about organising that hackathon. They are ready for you.