Jon Robertson leads Data and Innovation projects at Future Cities Catapult. In this interview, he shares his insights from delivering FCC’s flagship data project. Tombolo is an InnovateUK grant funded project focused on bringing a new product to market to support those preparing data for analysis in our cities and increasing data capability for our cities.
How do you define ‘innovation’?
Innovation is about coming up with new and better ways of doing existing things or searching for new opportunities to do what was previously considered impossible. Innovation sort of builds like a wave. Once enough people have pushed complementary ideas forward, the wave breaks and a torrent of new products and services can flow. In innovation, it’s important to tackle your own project whilst simultaneously connecting with others.
Is the process of innovation difficult? If so, why?
People and organisations can be overly optimistic that they can make big changes and leaps forward in innovation by themselves, but this is often not the case – collaboration is so important. Whilst working at Future Cities Catapult, I’ve come to realise that there are so many activities going on at a grassroots level by different people and businesses. A mix of complementary and duplicative activities. Private motivations mean that we can sometimes be protective of our work but impactful innovation for the whole sector comes quicker from open collaboration between those who operate together in the same domain.
What about this project excites you?
For me, it’s being able to speak to other fellow innovators working in this area, the people who are trying to make data processing more efficient, so we can get to meaningful insights more quickly and act on them. I enjoy meeting with people from different backgrounds, who are looking at the same problem but from different angles.
What has been the biggest challenge with managing this innovation project?
The project has been challenging for many reasons. The biggest challenge I identified when I took over managing it is that, at 3-years, this is a very long project. Lengthy projects bring with them resourcing difficulties, challenges around keeping a team engaged for so long, and innovation fatigue. We’ve tackled these problems head on as a team over the past 12-months.
In terms of lessons for others, I’m a firm believer that if you set more constrictive boundaries around a challenge, then people can rise to that challenge and innovate. It’s important to make innovation short and punchier from the outset or be prepared for the inevitable troughs.
If you were to do this again, what would you change?
I’d have embedded talking about innovation, through communications and events, throughout the entire life of project. There are have been lots of great stories which could have been shared, and lots of opportunities to have learnt from others. We’re doing this more now, and we’re getting great reactions and ideas from other people about the project. Doing this throughout the project’s life would have helped us get even more value from it and it’s something worth keeping in mind for new innovators starting out.
What is the most important thing you’ve learnt from this project?
When collaborating with partners, you need to have a shared vision. If you don’t, collaboration can be painful. It’s about being empathetic to what each collaborative organisation is trying to achieve, yet still making sure you can agree on enough of the project’s core objectives, so you can work together to deliver something successfully.
How have you managed the collaboration of multi-disciplinary teams?
We got all the team members to work in the same place. It sounds crazy, but this can be such a challenge in multi-disciplinary organisations where we all sit all over the place working on separate projects. We do weekly stand-ups and we take turns at organising interesting socials related to our field every 2-months to bring the team together. I’ve also encouraged team members to become knowledge leaders around topics important for the project that they might necessarily not have a background in. This has allowed the team to engage with the project more broadly, rather than sticking to their specific domains. These measures have helped the team to be appreciative of all the diverse parts that make up the sum on a project like this and it helps team members with communicating to others on how we’re making an impact on the project.
How do you get other people behind an idea?
For internal stakeholders, the most important thing is ensuring there’s a strong shared vision of what’s being delivered. This can be difficult with R&D projects where part of the project is tailored to researching the solution and team members can have diverse opinions. From there, you need to ensure that senior stakeholders are championing the project, so your team and wider staff members can see the value it’s bringing to the organisation and the outside world. Externally, it can be challenging to get stakeholders on board – especially if you’re working on something for which there are currently no solutions in the market. We’re currently exploring ways of building a grassroots community around our project, such as tapping into existing external networks and getting feedback on our idea from the software development community. This is a real challenge when you’re new to innovation and trying to establish your network. It shouldn’t be underestimated. We’re always open to new approaches – so if you’ve got anything to offer let us know!
What is the implication of failing, or not failing, during a project such as this?
Often when you come from a commercial background, you view failing as a really bad thing. This makes it initially difficult to adjust to the world of innovation, where failing is so important. In innovation, it’s very good thing to recognise failure early on, to almost set yourself up for failure by sharing information about your product or service to an external audience as soon as possible.
We’ve failed a bunch of times on this project. We’ve pitched at events that we’re too academic for us. We’ve over presented content to others. We’ve set down a course to develop a product feature, only to realise from feedback that we should be focusing on other priorities. Just last week we received feedback that the onboarding materials for new users should be much more accessible.
You’ve got to take constructive feedback on board, so you can develop something that’s more suitable to the genuine needs of others out there. But more importantly, encourage others in the team to feel that failure is fine and that recovery through an alternative course of action is always sweeter.