Does dedicated innovation time work?
I wrote a popular post awhile ago with an opinion on Google’s 20% time concept. Howard Baldwin from Computerworld interviewed me about this. Sadly, none of my comments made it into his article. The good news is here are the questions he asked with my answers.
HB: Please characterize the importance of creativity and innovation in the context of the working environment?
SB: All work is problem solving. Creativity is simply another word for the process of solving problems. If you give me a tough problem and I solve it for you, you may tell me “wow you are so creative” but really what I did was solve a set of problems. I may have used some old ideas, or some new ones, but to you it’s all the same since your problem was solved. Obsessing about how innovative you are is a mistake because it distracts from the real goal of solving important problems. The more ambitious the goals of a team, the more problem solving skills they will need to be successful and they better they need to be at identifying the real problems to solve.
Assuming you have a great idea you still need a good project team to execute it. Success for that hinges on 3 factors:
Is there a small creative team driving the project? IT groups are often dominated by committees, and suffer from too many cooks. It’s harder for good ideas to thrive if there are dozens of people who have the power to veto them while they are still young. You need a small (3-5) team of people who have power over the creative process.
Trust. Most teams are dysfunctional. They are competing for promotion and resources. If the VP of the group isn’t successful at creating a culture of trust, the most brilliant ideas in the world will be destroyed by infighting.
Leaders willing to make change happen. All good ideas demand change. The bigger the idea, the more change that’s required. Change makes people who like the status-quo very uncomfortable. If the leader isn’t willing to take on the risk of change, no progress can happen no matter how brilliant the team or the ideas they produce are.
HB: How many of these innovation/creativity programs are you aware of?
Many. It’s very trendy now for executives to create innovation programs. Most of them fail. They fail because new ideas are the easy part. What happens when the VP gets 10 good new ideas – is he willing to fund them? Bet the division on them? Cut an old project loved by another VP to make room for one single new idea? The real challenge is on the leader’s willingness to change and take on the risks of change. No method can do that for them – they have to do that for themselves as leaders.
HB: Is there something that keeps these programs from being more popular?
Shallowness and hubris. The most common practice is taking a small slice of a culture from a successful company (Apple, Google, etc.) without studying the larger context, and trying to jam it into their own culture. It’s organ transplantation surgery done with a butter knife. There is great hubris in assuming that making a poor copy of something that is not well understood will have instant positive effects. Typically the thing being poorly copied is then blamed as ‘not working’ and the cycle continues with the next fad.
It takes a long time to change a culture and IT departments are generally very conservative, risk-averse and focused on the short term. Often it’s not their fault as those characteristics are defined for them by the CEO. But the end result is the same regardless of who is the cause.
HB: What’s the coolest program you’ve seen?
The coolest programs I’ve seen are IT groups that are led by people who have experience making new products, rather than only working in IT departments. They’re more willing to embrace change, they understand how to sequester risk on new ideas, and they are better at learning new lessons.
HB: What advice would you give a CIO considering implementing such a program?
Start small. Pick one project team. Pick a good leader who is good at new projects. Let them work with a different set of rules (e.g. 20% time). Agree on the goals (small) for the project but then mostly stay out of their way and focus on protecting them from annoying people and roadblocks. When they finish, ask them to evaluate the results. Did those new rules afford better results? Ask why or why not? Ask the team ‘what did we learn? what should we do differently next time?” then share those results with the rest of the company, and repeat. If the ‘new rules’ result in progress, the VP should encourage other teams to use them. If they didn’t, the CIO should repeat the experiment with a similar team, but with new rules, fueled by the team’s own opinion for what to change.
Related posts:
This week: Assigning programming work
Innovation by firing people
This week: Fear of changing direction
This week: the joy of team rivalry
Why innovation efforts fail
