To show, tell and then play is a surprisingly effective process – providing you have access to the right equipment.
Geeks-in-Residence is about co-design, collaboration and learning. It needs ongoing conversations and space for both parties to be heard and listened to.
The focus should be on the shared learning. There’s always something you can tweak, make smoother, code a bit better, and being clear on this from the outset is vital.
It has challenged some of the leading organisations in their field to open their doors and have a conversation about what technology might do for them.
Recognising output as just one part the puzzle, rather than the sole outcome, means both parties can be more conscious of the other pieces: subtle developments, new learning, friendships, networks, breaking barriers.
There has been a lot of debate recently about the value that things like hackathons or hack days actually deliver. What impact and sustained momentum do they create – and do you even have to create an impact?
A what? The term ‘free-range geek’ means being able to roam across residencies, rather than be confined to a single project for the entirety of the Geeks-in-Residence (GIR) programme. Compared to a typical residency, it offers the opportunity for extensive cross-project learning.
For Sync’s 2013 residencies, my role was to support the process/service side of things across all five projects, engaging with the specific needs of each host and geek when appropriate. I like this kind of brief; open ended and with space to think, while also having a framework to work within that isn’t too linear. It encourages the creative freedom to explore and build something outside the boundaries of conventional and often restricted briefs, and the results are often much more exciting.
Having been involved in the first year of the programme in 2012, I was delighted to get involved again. Five host organisations had a developer each to collaborate with, and having a role across all of the projects was an interesting experience.
For the 2012 programme, I worked closely with developers Alastair Macdonald and Phil Leggetter; we had the opportunity to establish roles and skillsets, and subsequently make the best use of our time together. For the second GIR programme, I had roughly two days with each of the five residencies, making it much trickier to get an appreciation of this. Subsequently my role, input and learning differed greatly across the five projects.
Over the two years, I’ve found out about a lot of stuff that works and a lot that doesn’t. I hope I can shed some light on my experiences and what I’ve learnt from the GIR process.
1. Show, tell, play
To show, tell and then play is a surprisingly effective process – providing you have access to the right equipment. It’s a straightforward enough thing to do: bring a car full of computers, gadgets, tech and anything else you can get your hands on, find a suitable working space, hook everything up, bring in some staff from your host organisation, show them how it works and then let them play.
For her residency with the National Theatre of Scotland (NTS), Kate Ho traveled through from Edinburgh to the NTS HQ in Glasgow, bringing with her a toolbox of tech. She then ran a session with staff, introducing the group to a load of stuff including things her company Interface 3 had built, including augmented reality (AR) work using Microsoft Kinect, and a project that brought to life Edwin Morgan’s poem Stobhill.
What Kate was able to facilitate throughout the day was a few hours of play, followed by an ideation session, with the participants now able to talk specifically about how they might adapt a particular piece of tech they had been exposed to.
A simple idea, but the impact this had was incredible. Having seen what AR was capable of, the NTS group could imagine how it might be integrated with more traditional theatre media such as scripts. Having wandered the NTS office, GoPano in hand, ideas sprung up about creating 360° trailers for future productions. Without the show, tell and especially the play, we would never have left with the quality of ideas that we did.
A few weeks later, in a workshop with a different geek-host combination, we adopted the same technique to identify ideas for them. Again, this worked really successfully in allowing the geeks to talk about and give examples of tech, and for the host to see how some of these things might be realised within their organisation.
This process achieved a number of things across some of the residencies. It introduced new ways of thinking and learning, it challenged participants to go beyond the common barriers of ‘we need an app’ and ‘technology = a marketing tool’, to a place where there was an opportunity to develop some really exciting outputs.
2. Geek etiquette: rules of engagement
You wouldn’t lean over an artist’s shoulder to add the final touches to a painting, or advise a photographer on how to compose their shot, so how should you approach a GIR collaboration successfully? It can be tricky – especially in the arts – but there are some rules of engagement that should be considered when looking to get the most out of a residency.
Hosts are usually busy and have plenty of other commitments – seats to fill, acts to book, writers to engage, audiences to entertain. Trying to plug in anything unexpected or new to this process can cause disruption, especially if the project/work is ongoing.
As a creative (whether that’s an artist, developer, composer, designer, photographer, writer, etc) you have, to differing degrees, a certain ownership over your work; your own vision and idea of what you want an outcome to look like.
These realities need to be carefully and sensitively negotiated – a geek-host relationship is an intricate one and for it to work for all concerned it needs good communication, clarity and patience.
Being clear from the outset on the role of the geek, what the boundaries are and what is expected from both parties, is key. For the host, the residency isn’t a marketing or communications exercise and it’s not a typical consultancy engagement – it’s about co-design, collaboration and learning. It needs ongoing conversations and space for both parties to be heard and listened to.
Location is a key barrier too. When people are sat across from each other, there is currency in the conversation. Trying to work on a residency remotely, or with little contact, can be difficult. So ensuring there is time to work together and discuss progress is vital.
As a geek, you have a responsibility to be mindful of the host’s commitment, whether they link you up directly with an artist or give you free rein with some of the organisation’s staff. There’s a juggling act between delivering work, developing ideas, getting feedback and iterating this – not just the project or idea, but the process. Geeks need to be flexible and able to juggle these needs.
One of the great things about the co-design element of the residencies is that you bring together two sets of expertise; the hosts with the knowledge of their organisation and the geeks with their skillset. This provides an opportunity for an effective partnership and, by amalgamating both sets of expertise, the chance to deliver something that will create impact, be that through new learning, relationships, opportunities or outputs.
3. You don’t need to code to build a hack
I don’t code. I’m choosing not to say ‘can’t’ because I’ve not properly tried it, except for a few experiments here and there. I understand bits of it, but what I feel is more important is that I understand how to work with developers to create cool stuff.
This learning reflects more on my free-range role during the second year. For the first year of the programme, I had roughly 10 days on each of my two projects, which meant we were able to build two cool products in Audilight (with Edinburgh Military Tattoo and Alastair Macdonald) and The Middlemans (with macrobert arts centre and Phil Leggetter). With only two days per project this year, it was harder to get my teeth into anything.
I enjoy the process/service side of things, but I’m a product designer and I like to build stuff. So I challenged myself to create something that came out of ideation following a trip with geek Alasdair Campbell to Bodysurf Scotland in Findhorn. Using Little Bits and some haberdashery, I built a wearable that responds to sound.
For me, a huge part of the programme is about making technology accessible; helping build a bridge between hosts, geeks and tech. You can liken coding to magic – you know something happened, something cool, and you’re impressed, but you’re quite happy just to leave it that way. (Nick Marsh wrote a great piece for Makeshift on why he’s not learning to code. It’s worth a read.)
4. Setting Expectations
Imagine going to see Oliver Twist in the theatre and they forgot to include Fagin, or to see Rodrigo y Gabriela and they didn’t have guitars – unthinkable, right?
The nature of the Sync residencies, though, means that you might not get what you’re expecting, and that everything you set out to do may not be achievable in the timeframe. Building a hack doesn’t mean developing an all-singing, all-dancing product, and both the geek and the host have to be on the same page in terms of what a hack means, what it might look like and that it’s OK if it fails.
There’s plenty of stuff been written and said about why failure is good for success – TED even have a page dedicated to it. With GIR, I’d prefer to call it ‘room for improvement’ rather than failure. More importantly, the focus should be on the shared learning. There’s always something you can tweak, make smoother, code a bit better, and being clear on this from the outset is vital.
Setting expectations of what a hack may or may not look like means that when a geek and host sit down together to update on progress or present the work, we don’t end up with an “Is that it?” scenario. Recognising output as just one part the puzzle, rather than the sole outcome, means both parties can be more conscious of the other pieces: subtle developments, new learning, friendships, networks, breaking barriers – and having fun.
5. What happens with the ‘collateral bucket’?
Without exception, there have been a number of ideas across the residencies that come up, have huge potential but are not pursued. These end up in the ‘collateral bucket’ – an amalgamation of learning, latent ideas and thinking that comes out of every single residency. One of the challenges is what the geeks and hosts do with this bucket. In my experience, the reality is not a lot.
There might be a document floating about somewhere with some bullet points after an ideation session, or some sketches and scribbles in a notebook. But imagine if we could somehow capture this and use it as a resource to fuel future projects. As a host, you are half way there – you have an idea, some insights into why it was worth pursuing, and all you need now is another geek. (Or ideally, hire your previous geek again.)
It’s a challenge that goes beyond the residencies. There has been a lot of debate recently about the value that things like hackathons or hack days actually deliver. What impact and sustained momentum do they create – and do you even have to create an impact? Food for thought. The important point, I think, is that there is intrinsic value being fabricated that is then almost immediately lost. It’s an eternal state of pause and we’ve lost the remote.
I’m not sure what the answer to this is – I’m working on that bit. But I’m curious to explore the best way to not just retain the content in the bucket but make it valuable.
6. Culture change – artists who work with code
The idea of writers or artists-in-residence is widely accepted, technologists-in-residence less so. (Or artists who work with code, call them what you will…) There are already, of course, plenty of examples of arts and cultural organisations engaging with tech.
Over the last two years, the GIR programme has been able to facilitate the opening up of new working in a safe space, where geeks and hosts alike get the opportunity to push boundaries into often unfamiliar territory, coming out the other end without the worry of being asked the question: ‘Where did the money go?’
But more than that, the residencies have also challenged some of the leading organisations in their field to open their doors and have a conversation about what technology might do for them. And that’s the key – opening the doors, having a conversation and perhaps explaining what ‘open source’ means for the project.
Whilst bureaucratic inertia isn’t something that one would necessarily attribute to cultural organisations, I believe many of us are guilty of finding a groove and staying comfortable. I remember one particular protest of “If it’s not broke, why fix it?” Well, who said anything about fixing?
The Sync team opened the door, and through GIR I know that a few of the 2012 geeks continued to work closely with their hosts beyond the residencies; many from 2013 are in the process of lining up further collaborations for 2014.
So how do we scale this and open doors en masse? What if we could open source the programme to allow other potential hosts across the UK and the world to use this framework to deliver similar residencies within their own organisations? I’d like to see that idea realised, but just for now it’s going back in the collateral bucket…