For the past five years we in Rewired State have been running hack days. Initially to encourage the UK government to open up its data, removing the fear and uncertainty of what developers might do with the information once it was made available with no limitations. Now we run them for all manner of organisations, from media giants to corporates – as well as a continuous symbiotic relationship with central and local government
To briefly describe a hack day in 2009 it was usually a weekend with a number of software developers in a space with spankingly good wifi, some data, pizza, beer and a few dodgy prizes awarded to those who got the most claps, gasps, cheers or laughs. They were informal events that brought together groups of people and individuals who would never usually have time and opportunity to meet. The results, the prototypes, were less important than the community activity for the developers, and the meercat moment for the sponsors or people for whom the hack was being produced.
As with growth of any idea or concept, as Rewired State has continued to run these events so we have refined and learned what we do to make it better for developers, better for clients and to refine outcomes to meet the need that sparked the hack. I hope that by sharing this updated learning with you all now, it will help.
Here is how a hack day looks to us now in 2013
Ideation
We found that we were spending more and more time with clients refining the actual challenges being laid down to developers during the hack. It has always been profoundly important that hack days do not turn into bootcamp for building prototypes to a specific brief. In order to enable the unique collaboration, the creative ideas, the spark of solution that generates a number of prototyped digital ideas that resolve a particular issue – it is essential to define the problem first, not design the solution.
We advise that hack days have three of four challenges laid, and the associated data made available.
In order to define the challenges, the problem must be identified and this usually requires the meeting of several people on the client side of the hack. In Rewired State we spend the majority of our time initially with the client shaping these in such a way that they are clear enough without be prescriptive about potential solutions.
The Hack
Our hack weekends are hugely crafted in order for them to be simple and open. It takes us at least eight weeks from woe to go to get everything in place, including the developers. Luckily for us our network of devs and designers is made up of over 1000 people who can create working prototypes in 36 hours or less. So we have a hugely talented pool of people we can draw upon.
We take time to initially invite specific people from this pool to try to make up a group of people at the hack made up of 50% devs with expertise and experience of the field we are focusing on, and 50% with no experience whatsoever. We find that this mix tends to create realistic yet innovative ideas, without stifling creativity. And then we open the hack up to anyone who would like to join for whatever reason – we don’t second guess peoples’ passions!
The end of the hack event will produce ‘winning’ solutions for each of the three to four problems laid out in the beginning.
Modification days (Modding days)
It was becoming clear to us as we grew up that clients were increasingly wanting to take ideas forward from the hack, as the solutions were what they had been looking for. As we in Rewired State are committed to not becoming a body shop for developers, others are doing this perfectly well, we needed to find a way to enable prototypes to be taken through to product, with the teams who had come together in a perfect storm to come up with the concept in the first place; (often people with full-time jobs and geographically separated).
And so we created a modding process: the selected prototypes from the hack day would go through a process of development whereby the client would feedback to the dev teams on what would be useful to change or adapt, followed by a day or two of scrum-style programming and design, on all three or four prototypes so still a ‘hack’ format everyone is together again, followed by client internal review and feedback, and so the iteration process continues until the products are ready for the client to adopt.
When you don’t need a hack day – we have Rewired Reality
Clearly the hack days we run cost more than sponsoring beer and pizza, well the problem-solving ones do, and so sometimes people come to us thinking they need a hack day, but don’t have the time or money necessary to get the benefit from full-blown physical event. And so we created Rewired Reality, where we have a number of our Rewired Staters and Young Rewired Staters behind an online board. Here is how it works.
IP and money
IP is always the question that must be resolved up front. We are careful to ensure our community of developers feels like they are having fun as much as building solutions to real problems, and so we try to strike a balance between commercial hack days around specific problems, and those where it is just for fun (where we have found some amazing data being released that they would enjoy having a go at, or for a cause that we know touches the hearts of many).
For the former, we pay developers for their time. They are paid to attend hack days, they are paid for modding days and in most cases, the client will retain the IP. But they don’t always, in some cases they are happy for the developers to keep IP, so there is no real defined rule, but it has to be discussed and agreed in advance.
For the latter we don’t pay developers money, but we do provide a well-run hack, with good healthy food, some pizza usually thrown in, fun and frivolity. And they keep their IP.
This balance works for us right now, it may well change as the hack day continues to grow up.
Hack day Prizes
Originally hack days had some token prizes, often deeply ironic or just downright funny. As they began to become a thing outside of the developer-only zone, prizes became more valuable, cash sums or shiny kit. For a while we grappled with this – trying to strike the right balance.
A high sum of money would skew the attendance and reason why the hackers chose to come along, change also the dynamic of the event, less collaboration and more secrecy, and attracted a different kind of developer, often entrepreneurs with an unwilling and exhausted coder in tow. Not what we are about at all!
A low sum of money could be seen to be insulting.
So we try to avoid financial prizes.
“Stuff” is always hard, because it is tricky to second guess the number in a hack winning team, and if an individual but amazing thing is donated, such as a 3-D printer, how does a group of four strangers who have come together to create a prototype over a weekend, share that?
So we try to avoid “stuff”.
Experiences are good. Vouchers are good.
But actually, the conclusion at the moment is that we need to make the hack weekend itself so enjoyable that it is about that experience and not the prize – for our open and non-commercial events. Prizes more in line with the original ironic/playful times and a well-stocked bar at the end.
We do not award prizes for the winners of commercial hacks as the process continues through the modding days. but we maintain a consistently high standard of service to those devs who come along.
With thanks to Hudson Hollister who presumed that I had written all of this up and shared it, ad nauseum, as did I. But then I realised that this was all in my head, or in my conference slides, which is no use to anyone.
Emma Mulqueeny 