At the moment I’m preparing some research on collaboration techniques for productive outcomes, and I’ve been thinking about some recent success stories in online/offline collaborative exercises and activism. Now there’s no doubt that any collective action or idea still requires a phenomenal effort from a few people to put the pieces together – effectively to lead and administer a project – for a successful (productive) collaboration. But once you have that individual or small-group administrative system in place, there are also some other ingredients you need to ensure a successful result.
Most of us in the London technology and social media community will tell you that barcamps, hack days and either structured or unstructured conversations are incredibly useful and productive for the participants. They will have a number of reasons for saying this, but they perhaps won’t be able to tell you precisely what it is that makes these events so successful. Most will have perhaps some doubt as to the value of an entire event, but they’ll be able to hone in on one or several things that were particularly valuable. However, if there’s a cost associated with attending one of these events, their critical responses, and their estimate of the value of the entire event, will be more pointedly positive or negative, and they seem to be more inclined to speak of the whole event rather than their interests or concerns. (And the more an event costs, the more likely it is that attendees will be evangelists of the event, while non-attendees are more likely to be critical of it.)
This needs more research, but I think there could well be a recipe emerging for innovation from hackday events in particular, as an exercise in productive collaboration. First, you need to make attendance voluntary and free, but you need to make people register to participate. Further, you need to make the names of registered attendees public. This generates a kind of obligation on the registrant to turn up. It’s not infallible by any means; there are all sorts of things that can prevent a registrant from attending, but there seems to be a correlation between a public list of participants and a concerted effort to attend. In particular, those who end up not attending tend to broadcast that fact on twitter, Facebook or some other channel.
After that there are some internal aspects of the way that hackdays run that seem naturally to swing the balance in favour of innovation production.
1. Attendees implicitly acknowledge they have skills they feel may be useful to a hackday, and they are prepared to demonstrate those skills.
2. Hackdays tend to be held in venues that are architecturally social, and they are often scheduled over weekends or the event is given the sense of being ‘on holiday’.
3. Hackdays are often supplied with raw data or a few seed ideas. Data is usually collected for one or a few purposes, and collectors are so focused on their primary reason for data collection that they don’t have the time or task-oriented latitude to be able to repackage that data for other purposes or mash it with something else for a new result. Seed ideas are usually expressed in terms of collective benefit – beyond the profits of the companies, to the broader community. So statistically it’s likely that data can be used for an alternative prupose than the one for which it is collected, and where seed ideas benefit the broader community, there’s a public-good emotional benefit for those involved in working on a collaborative project.
4. For most hackdays there’s either a final part of the day where ideas are presented for applause (emotional benefit and public display of skills) or even better, there’s a prize for the winning project.
There’s no doubt that there is a novelty and elitism which is also embedded in hackdays at the moment. Only the technological early adopters and early majority are likely to participate voluntarily. This may well also unduly skew or influence successful innovation production. But I suspect that the four ingredients would work in any context.
Of course business strategic planning days, corporate training programmes and team building experiences are not so far removed from the hackday formula – and businesses recognise these entities as influential in raising office morale as well as productvity. And indeed the most common criticism of strategic planning days in particular, is that innovations and outcomes developed by business teams are not implemented after the event, for one reason or another.
But I think there are two crucial differences between the hackday innovation strategy and the intra-business innovation strategy:
– the scope of influence of a hackday is broader;
– the implications of failure to innovate at a hackday are few, and the concomitant loss of face for such failure is marginal to insignificant, as participants are unlikely to meet in a business context daily.
Of course it’s possible for businesses to replicate the hackday formula and overcome these barriers. They just need to use people from outside their current employee base, and they need to do things that won’t just profit the company and its stakeholders but the broader community.
So is the hackday formula a recipe for success? It needs to be more broadly tested to know for sure, but it certainly seems a robust hypothesis from which to begin.