The path to rapid innovation
The path to rapid innovation

Terence Eden

The South Central Ambulance Service tweeted that they had an iPhone app showing you where the defibrillators are:


Just iPhone? He called them on that – and they threw it right back into his court:


So, he built a web app in a lunchtime, using their data and OpenStreetMap.

Biggest takeaway? Just f*ing do it. Get on with it, don’t wait for a committee meeting.

Richard Feynman came up with the Feynman method for solving problems:

  1. Write down the problem
  2. Think really hard
  3. Write down the solution

Of course, he didn’t say the right solution. Everyone fails – but we have problems admitting this at work. But the most important thing about failure is to learn from it.

They try to spend no more than six weeks on anything, assess success or failure, and go from there. Sometimes they sit down with sheets with the screen outlines of various devices on it, and spend 30 minutes just sketching ideas, until the get something they’re comfortable developing a bit further. Get soundings around the table about if it’s going to work long before you take it to the rest of the company – and go with something working.

And try to do this sort of thing all the time – and not just for your job.


If you can’t get something done in six weeks, you won’t get it done in six months, realistically. Artificial restrictions are useful.

Asking permission versus asking forgiveness can be troublesome to a lot of organisations. Christine Townsend asked if she could set up a Sussex police Twitter account, was told “no” – but did it anyway. She ended up being told to write the regulations that she’d effectively broken.

People don’t like change. Different perspective is useful.

“Bikeshedding” – imagine you’re in a parish council meeting, and there are three things to discuss. One’s hugely expensive (say: a nuclear waste processing centre), one’s an average bit of money (say: bikesheds), and one’s tiny (say: sandwiches). All the debate centres on the medium amount, because the tiny is too small to worry about, and the big one is so big and expert that no-one feels able to comment. So the one at the scale you can most easily grasp gets the most attention.

Terence prototypes in pencil, so he can rapidly change it in response to feedback, stopping people getting hung up on details. The discussion about livestreaming earlier successfully avoided getting hung-up on copyright, which is something to discuss and resolve after the service is up and going.

Innovation is about finding out what is possible or impossible as quickly as you can. Get feedback from anyone outside you can – grab someone on the street, or someone from another department in the canteen.

Permission to disrupt granted

Being disruptive – playing with innovation – gives other people permission to do so. You can’t just be a small team or individual doing innovation – you need a company culture that supports experimentation – and failure. Telling people that you made mistakes both allows them to experiment, but also prevents you from making the same mistake.

The fire service are good at debriefing from incidents. They’re less good at managing the communication of changes from that. Some small changes create staff ire, some big changes flow through easily. They’re not capturing well what make stye difference.

They bought a 3D printer and built it in the middle of 02’s office. Whoever walked by and complained or questioned it, got asked what they’d do with it. It was a social object that allowed people to think about doing new things. They’re only about £500 these days – well worth trying.


#ukblc14 – the path to rapid innovation
Tagged on:             
%d bloggers like this: