You read that right, it’s a choice. Companies often make a conscious decision to not innovate. Why do companies choose to do this? Why is it so hard for their employees to innovate? Let me count the ways:
- Because it is easy, embarrassingly easy, to kill an idea –How often have you been in a meeting, when a coworker comes up with different approach to solve a problem or new idea? What is the reaction? “Oh wow! Great idea Jane! I’ve got some ideas on how we can implement that.” Or is it more like this: “That won’t work, and here’s why…” “We tried that before and it didn’t work, because… “ Why? Because it is part of our corporate culture. It is easy (and comfortable) to find reasons why an idea won’t work. It is easy to poke holes in a new idea or product, but hard to figure out how to make it better and even harder to figure out how to make money with it. The latter requires an extreme use of brainpower to take a germ of an idea and grow it. It requires research, strategic knowledge of your customer base, economics, sales and marketing.
- Confuse innovation with entrepreneurship – Innovation could be defined as a cool new idea or process. Entrepreneurship is the ability to take that idea to the next level, and make (or save) money with it. Simply having smart creative employees is not enough. In order to gain business value, a process (and supporting infrastructure) needs to exist which allows companies to nurture and capitalize on ideas. Far too many companies create cumbersome and unnecessary obstacles by forcing employees to fill out copious amounts of paperwork, go before review boards, etc.
- Not providing the time or environment to innovate – One of the main tenants of economics is that people make rational decisions. It is irrational to expect employees to work overtime to create innovation for a company; on top of their normal 40-50 hours a week. If an employee wanted to work overtime on an idea, the rational decision would be to simply work his/her 40-50 hours, then put in personal time on his/her idea. This part-time innovation approach is how many startups are initiated. So, by expecting employees to work overtime on innovation for the company, the company is actually incentivizing them to innovate (and hopefully profit) on their own.
- Risk Intolerance – If companies choose to allow innovation time, or try to implement something like the Google 20% rule; corporate leaders must understand the nature of risk involved. Many companies are simply unable or unwilling to accept the risk that most ideas will not create value. For those unwilling to accept risk, it becomes a pure opportunity cost, and therefore a wasteful expense.
Issues, 1,2 and 4 above are the result of a toxic, but not uncommon, corporate culture. It has been ingrained into our tech DNA to challenge and vet new ideas (which I view as a good thing). However, I have witnessed corporate cultures, which pride themselves on establishing nearly impossible impediments to innovation. Moving towards an entrepreneurial culture which accepts risk takes time, leadership, and an unwavering commitment to the following principles:
- There is a commitment to experimentation, innovation, and being on the leading edge
- This culture does not just quickly react to changes in the environment—it creates change
- Effectiveness depends on providing new and unique products and rapid growth
- Individual initiative, flexibility, and freedom foster growth and are encouraged and well rewarded
Culture changes must come from the top of the organizational food chain and it doesn’t happen overnight. It will most likely take years and require vigorous attention to change management principles (see Dr. John Kotter’s Our Iceberg is Melting).
So where does Scrum come into the mix? This is after-all an Agile blog. While a culture change is required to bring about strategic innovation and entrepreneurship, you can use Scrum and Agile methodologies to address issue #3 – Innovation time.
6x2x1 Rule – One way to enable innovation time is to introduce the concept of a Scrum hack-a-thon. For teams that have two-week iterations: every 6 iterations have a 1-week hack-a-thon. This is known as the 6x2x1 rule: After six 2-week iterations, have a 1-week hack-a-thon.
How it works – I first learned this from Kenny Rubin, who originally taught me Scrum. I took it a step further and add a few rules:
- A separate product backlog is created to track innovation ideas. The stories are not prioritized. They may or may not be groomed, that is up to the team. For the hack-a-thon, the team members decide what to work on (within reason – see below). Should a story start to mature into a product, the product owner can move it into the product backlog.
- Prior to the start of the hack-a-thon, the team presents what they want to work on to the team and product owner. The team and the product owner are responsible for making sure the ideas make sense for the company and the team (or individual team member).
- Employees can work on their own idea, or join other team members.
- It doesn’t have to be a new product idea. For some, it could be a learning session (e.g. I don’t know JQuery, so I am going to spend the week learning it); which could be used to reduce technical debt or improve an existing product.
- The team is free to work on what they want. However, the project(s) they work on must be beneficial to the employee as well as the company. For example, it isn’t beneficial to a telecom company for an employee to create an iOS video game.
- Other than emergencies, nothing else happens during a hack-a-thon that interrupts the team (e.g. no meetings, planning sessions, etc.).
The 6x2x1 Rule is one method, there are probably many others. Even if you use the above method, you are still below the Google 20% innovation benchmark, but it is a start.
This is a really great post and addresses an important problem for many businesses. It’s far too easy to discourage employees’ innovation because of misunderstanding or fear of the unknown. I believe the most successful businesses actively foster innovation.
There is no doubt that this is morale booster and has led to some innovations, most but not all of them are incremental.
I would also point out that Google is not a deadline company, they don’t lose revenue if they don’t ship, and since a large part of their business is expected to be non-profitable they have a tremendous amount of slack off the back of their revenue engine.
The real issue I have with your suggested approach is that dedicating an entire week to the process seems too immersive, and therefore disruptive to the other projects, which is why at Google this is typically done on a designated day ( it might be better if you could say after 5 for 2 hours but it probably would lose it’s morale boosting effect )
I also disagree that you should focus on your core business practice, that defeats the purpose to a very large degree. If they want to work on a game, look at it as gamification research, there is always a positive in there if you don’t limit yourself. Is it a harder sell politically, yes and no, pointing out success cases like google mail should push those out of the way.
If you do want to implement this at your company I would highly recommend the first step as reading Steve Blanks new book and getting the employee’s to figure out how to define problems before they start tossing out random solutions/products. Random approaches only succeed randomly so if your going to invest in this do it right.
The biggest problems employees will encounter even if you can get political buy off is if they are successful at finding a real innovation that is not incremental to existing product.
The DNA of most companies is so ingrained that anything they create outside that DNA will either be rejected or morphed (killed) to fit the company. Read the innovators dilemma / solution to see more about that universal problem and a potential solution. rejecting a project that employees have worked on for a long time usually results in the exact opposite of what you want. So you better be serious about recognizing success when you see it.
One way to sell this to your company is to look objectively at the production levels which are typically lower the longer you work people so why not use that “dead” time to get them re-energized, the obvious retention benefits, and yes occasionally the really cool stuff that comes out of it.
One major rule I would apply to this is that if they work on this project outside of the designated time at work the privilege is revoked ( been there done that )
Finally if I were to do a single day I would pick one that is least productive, at my last company that was always Fridays, it really did work as they naturally wanted to get things off their plate before “Their” day arrived even though we made no rules to that effect.
We did come up with a few useful things out of this, and it did boost morale, but I consider it more of a cultural and educational investment (They learned newer tech like Mongo, Ruby, etc) that benefits the company long term.
They also did work on this at home quite a lot in their off time, so the benefits are usually matched x2-x3 by the employee’s
Wow, long post, sorry !
Good post Todd, and thanks for your comments! We did try multiple methodologies. One of which was using one day a week. That is much closer to the 20% time. The 6x2x1 Rule (as mentioned above) only gets us to about 8% innovation time. The problem my teams encountered with every Friday (or every other Friday), was the context switching. Switching from normal day-to-day work to innovation work, for a single day was difficult. Most wanted several days in a row to work on their project. One day a week felt too fragmented. As with most things in Agile/Scrum, I let the team decide. Overwhelmingly they choose the one week approach. I doubt there is a one-size-fits all approach for all companies.
As far as entrepreneurship goes, for-profit companies simply will not support an approach that does not benefit the company, at least indirectly. I believe in (and have experienced) hack-a-thons that benefit both the company and the developer.
My goal with this post was not to agree or disagree with any single approach. I would endorse anything that works for the team and potentially results in delivering business value.
Reblogged this on JDPOWERGROUP.
Pingback: Why Companies Choose Not to Innovate | System Dynamics