Who is responsible for product innovation? Is it an individual, a specific role, a devoted team, or is it everyone? I can tell you now that unless the answer is the last of these options then you could well have a situation that undermines the motivation and performance of your development group.
The Innovation Silo
A couple of weeks ago I was discussing with a colleague the challenges of innovation. We'd both encountered in previous roles the situation where one individual or group was given a free role on innovation. These people went by different titles, either as individuals or teams : Chief Scientist, Architect, Research Team. The result was the same: those given the freedom to research and innovate would perform those activities in isolation from those working on the main product streams, operating in what was effectively an 'innovation silo'. The focus of the innovator's activities would be to come up with advances in technology or capability. Their output would be aimed at senior management, with the goal of demonstrating to them a 'working' capability of an idea that they had developed and obtain approval to push it through to production.
The Motivation Sink
Arrangements like this were great ... if you happened to be the ones in the innovator roles. These people enjoyed a high level of job satisfaction and operated with a low fear of failure as their work was rarely exposed directly to live use, instead it fell on the regular development team to take these initiatives and carry them through into production.
In addition to inevitable practical issues of handing over prototype code, (which I've decided is a big enough topic to merit a post of its own shortly), the problem was that this arrangement caused a huge amount of frustration for the individuals that weren't part of the innovation activity. The freedom that one individual or team enjoyed came at the expense of many other developers and testers working hard to deliver the commercial obligations of the company. The people who were responsible for the day to day delivery of release schedules and customer deadlines would rarely have the time or the freedom to try out new ideas, unless done in their personal time. The closest many would come to innovation would be in struggling to understand, implement and test designs (if they were lucky) or code (if they weren't) of new products or features which had been created by someone else.
The inevitable outcome of this type of activity on the development and testing teams is demotivation. Fundamentally what we are saying to these people is - "we don't trust you to come up with good ideas". Not only is the exciting work of innovation and research out of reach to the rest of the development group, but to add insult to injury they are then asked to take the output of that innovation and perform the necessary yet uninspiring activities that are so crucial in software, and deliver these in an atmosphere of unrealistic expectation and high fear of failure. I've never encountered the situation where a developer was ecstatic to be working on someone else's code, however at least when that code has been working as part of a live system there's an element of respect in it. When the author of the code has never had to expose it to formal testing or the rigours of production use then that respect is absent and resentment can result.
The arrangement places testers in a frustrating situation as well. Being isolated from the process of innovation results in a separation from the goal of the development. In order to perform effective testing a tester needs to be on board not only with the behaviour of a solution but also to have a keen grasp of the problem that is being targeted. When product research is performed in isolation from the testing group then testers are forced to work within the solution domain. Any benefits of having the critical thinking of a tester integrated in the design process to question decisions and refine early designs is lost. Even if the tester does have valid concerns it can be politically difficult to raise these in the face of support from influential technical staff backed by senior management. Instead the tester politically and practically is compelled to limit their frame of reference to what functional understanding they can gain from behaviour of the developed solution. Their role is diminished to a confirmatory one of verifying existing behaviour rather than a wider scope of questioning value.
An open innovation
I'm hoping that I've just been rather unfortunate to see this type of relationship in more that one of my past jobs - I'd be interested to know in the comments here whether anyone reading this has encountered a similar situation. It it a common scenario for opportunities for innovation to be restricted to a chosen few?
I'm sure that many companies out there have very open and inclusive approaches to innovation, and I'm keen to help make sure that my current company is one of those - so what are the alternatives to innovation silos? In a recent product workshop I ran, some ideas that we identified to avoid this kind of situation included:-
- Getting everyone in the company on a user feedback forum to share their innovation ideas and vote internally for their favourites
- Allowing people time to pitch their ideas and provide the support for small cross-functional teams to be created to develop them together.
- On a similar vein one of the developers at River pitched an interesting idea recently of having 'ideation sessions' where at regular intervals different cross functional groups were given the chance to try out an idea and develop it.
- Having innovation sessions at whole company days to get everyone involved at the same time to generate ideas.
- Developing and trialling new capabilities into our own internal version of our engagement software
Whatever form it takes, I think the important thing here is that everyone should be able to contribute and feel part of innovation activities. At the very least everyone should feel included in the process and able to actually raise their concerns over any new approaches being adopted.
As I stressed in my post on 'sharing the vision' there's a huge amount of value in simply having all of your team members engaged with a vision and able to identify connections and opportunities that help to move towards it. You don't have to be the smartest person in the company, with a job title of 'Scientist' or 'Architect' to come up with an idea that advances your capabilities. Naturally some individuals are more inclined to innovation and will generate more ideas than others, however at the same time many great advances come from simply making connections, such as applying an existing approach to a different problem, which anyone can do. The less we think of innovation as part of a role, and more part of an organisational culture, the more likely we are to get everyone driving and supporting our innovations rather than resenting them.
Image: https://www.flickr.com/photos/vitahall/9337199735
Post a Comment