For just under two years now I've been a "Digital Guerrilla", working as part of a team of six in Birmingham, created by the BBC to "pilot and prototype new storytelling ideas", and help the broadcaster to "engage with its audiences and to deliver unforgettable content". I'm leaving this month for a new role, but wanted to share some learnings from being embedded inside a huge organisation and being tasked with—that dreaded word—innovation.
1. Ask forgiveness, not permission
I'm kicking off this list with some hypocrisy, because this was something I wish I'd done more of at the BBC. It's a large, complex and embattled organisation and therefore is famed for its processes, bureaucracy and policies. Most of these are understandable—even laudable—but they can certainly make for challenges when trying to push boundaries.
For example, releasing webapps that use public APIs like Twitter's or Facebook's require a custom development agreement to be put in place, because the BBC can't sign anything granting unlimited indemnity (eg. if our Facebook app broke your computer somehow, the BBC could be liable to pay all your costs). This means that before we can release apps using these platforms, we have to get custom, BBC-specific agreements in place with Legal first.
Other concerns are around editorial policy: some parts of the BBC's web properties I've worked on contain sex/drug reference. In one quiz we built (aimed at a middle-aged audience), we had multiple meetings to solve the (mostly theoretical) issue of an under-16 browsing our quiz and finding a link back to BBC Taster (which sometimes contains this edgy content) and being exposed to it. Lots of people were consulted on this before we signed off on wedging some copy into a text box intended for a survey, which warned curious youngsters not to click any further.
I mention this not to moan about the BBC (which, after all, is trying to protect the license fee payer), but to suggest that the world might not have ended if we'd just put these things out and taken the risk. Two of the apps I worked on were blocked from release at the end of the project for these kind of reasons. Clearly better up-front planning and discussion could have avoided this, but sometimes when you're being asked to innovate, you have to ruffle a few feathers. Just don't get sued.
2. Know your audience
Being asked to build things for a demographic you're not part of is challenging – more so when that demographic is "young people" / millennials / your-epithet-of-choice-here. Everyone kids themselves that they know what teenagers like online ("oh, it's all about Snapchat, right?" they say confidently), but really, it's a mystery.
With that in mind, the projects I'm most proud of are the ones where we got out of our comfort zone (and studio) and met the audience face-to-face. Lacking a proper UX process, we did it guerrilla-style: popped over to the local university and plonked our stuff in front of them. Watching a bunch of first years mercilessly tear apart a D&D-style Twitter game we made was sobering but powerful: we learned more that day than in the months of development we'd spent up to that point.
We also got to see the real people behind the glossy personas or the faceless demographic charts. Real people are messy, unhelpful, resistant to pigeonholing and a thousand times easier to make things for when you've spent time with them. Every time we put our work in front of people and waited to see if it could stand up on its own, I felt nervous, defensive, proud and informed all at the same time.
And on the projects where we didn't? I rarely felt much at all. Unique users on a chart are nice, but almost meaningless at an organisation the size of the BBC. We don't need vanity metrics when we're innovating, we need to see a real person recognise the value in the thing we've built. Get in front of them.
3. Throw things at the wall and see what sticks
I'm a firm believer in the agile/lean manifestoes – release early and often. Innovation should encompass this: you're supposed to be trying new things and by definition, not all of that stuff will be relevant to your audience. Maybe some of it will become so, but it's your job to work out what that might be.
With that in mind, life's too short to lock up ideas in a lab while you perfect them. The sunk cost fallacy quickly creeps into the picture when you do this, too, and we were victim to spending too much time (and cash) getting something done, and releasing it knowing it wasn't great but had to be launched.
The quicker you can drop professional pride and just get used to putting things out and seeing how the audience reacts, the quicker you can drop the stuff that isn't working and focus on what is. It sounds obvious, but it's surprising how hard it can be to switch to this mindset when you're not used to it.
Case in point: 360° videos. I can't think of a single other technology where the ratio of interest from publishers to users is so highly in favour of the former. The BBC loves them. Sure, it's cool the first time you see one, and when the entire world is wearing an Oculus Rift at all times then bring 'em on. But the high cost of production (in terms of both time and money) means you could pilot three or four quicker, more agile ideas for the same cost.
It's all about not being afraid to set a target for an idea (number of social engagements, time spent on average, or plain-old hits if you want to go all 90s) and then releasing it, interrogating it, and iterating – it's the digital equivalent of cutting a path through a dense jungle. Let someone else airlift a cement mixer to the forest later.
4. Be a unit
This was the first time I'd worked on a small team – in previous roles I'd been part of teams of a dozen or so, but here there were just six of us.
Geography played its part in challenging us – we weren't based in a mainstream BBC office (just on our own in Birmingham's "creative quarter", Digbeth), not all of our team were located in Brum, and frequent trips to London to work with other teams sometimes got monotonous.
However, the moments when the whole team were engaged on an idea: everyone focused on improving it, testing it, developing it – these were the standouts for me. You're more invested in the success of a concept when you've had a hand in shaping it, and you'll fight for something you know is a strong idea when you've sweated on the details and partnered with your teammates to make it better.
We had a few periods like this – all cylinders firing, everyone contributing to each others' ideas, everybody willing an idea to succeed. It's hard to capture and difficult to regain when it's disappeared, but team unity is paramount and correlates directly to the strength of your output: you need to be greater than the sum of your parts.
5. Innovation is relative
Finally, the dreaded I word. Explaining your work on an innovation team might become a millstone around your neck when you speak to certain folks – they'll think you're either trying to be the next Elon Musk, or about to sell them a VR headset. It's easy to get down about your work and think "this isn't innovative, someone could've done this three years ago".
Innovation, though, is relative to the organisation you're doing it in. When I started at the BBC they'd never been able to embed a Disqus commenting widget on a site. Small an achievement as it was (I'm not putting "embedding an <iframe>" up there with "inventing SpaceX"), it represented a step forward in navigating the BBC's legal/editorial policy framework (see above), and perhaps helped show the organisation that the sky doesn't fall in when these things happen.
If you're in a team tasked with innovating within your company, remember that you're not being measured against the entire digital industry. What are the things your organisation is afraid of or "unable" to do? Prove to them that it's possible and build those future paths for other people to follow.
--
By next month I'll be off on a new role, helping another organisation to challenge boundaries and explore new ways of working. Not everything worked the way I wanted it to at the BBC (though when can you ever say this about a job?) but I learned several useful things about how we work, how we develop ideas, and how to approach challenges in a huge organisation – I'd happily do it all again.