The Innovators

Last Sunday I watched the first episode of Innovatörerna (The Innovators) on TV8. The Innovators is a reality show about two management experts that help companies in a crisis. (Once a show has been aired, it is available for watching at The Innovator's web site. In Swedish though, with no English caption.)

If you have seen Gordon Ramsay take a restaurant at the brink of ruin and whip it into shape, you get the idea. The Innovators are Swedish though, so a whipping is when they say "we are disappointed with you". If they are very upset this may escalate into a devastating "we are really disappointed with you".

In the first episode they helped F.O.V. Fabrics. F.O.V. Fabrics invented the airbag fabric eighteen years ago. At its heyday the company had 300 employees. Today only 75 are left.

When the financial crisis hit the automotive industry, F.O.V. Fabrics saw its market collapse. They had to do something fast, or go out of business. The TV show The Innovators gave them their chance.

What the innovation team, Hans Björkman and Kaj Mickos do is really very simple: They gather people from all over the company, including the people at the workshop floor, and brainstorm to get new product ideas. Then they select the most promising ideas, investigate their market potential, make prototypes, and check if the idea can be patented.

I filmed a similar brainstorming session awhile ago. It has the advantage of being in English:






One thing you will notice, whether you watch The Innovators or my videocasts, is that there is no magic involved, no superhuman effort, just ordinary people coming together and doing very simple, very effective things.

The most difficult part is to break some bad habits. For example, when Hans and Kaj told management to set up a brainstorming meeting with both managers and production personnel, only managers showed up. Management had ignored the request to call production personnel to the meeting.

Kaj and Hans were "very disappointed", and gave the F.O.V. managers five minutes to fix the problem.

Here is the really interesting thing: The brainstorming meeting produced at least three excellent product ideas. At least two of these came from production personnel, two middle-aged ladies. One of them told the TV team this was the first time in her 35 years with the company management had been interested in the ideas of anyone on the factory floor.

I can't help but wonder how much competitive power management inadvertently has repressed over the course of those 35 years. How many great ideas left the company with the 225 people that were let go when management tried to make the company more "cost effective"?

Is your company making the same mistake today? Probably. Can you learn to avoid it? Certainly!

My experience is that while most organizations are in drone mode, the people in them are wonderfully bright, inventive and inquisitive. All you need to do to get fantastic results is to flip the switch to ON. Listen to the people in your organization, actively draw the bright ideas out of them.

Far from being the scourge of your company, the crisis can actually be a great boon to you. It is when people are faced with a crisis that they get the incentive to break old habits, innovate, bring forth their best.

Do you have the will to survive? Do you want to flip the brains to ON in your organization?

If you do, take the first step by calling me at +46 708 56 23 65, or just email me.

Comments

Post a Comment

Popular posts from this blog

Waterfall vs. Agile: Battle of the Dunces or A Race to the Bottom?

Image
The major software methodology wars since the mid 1950’s. Someone was wrong on the Internet, so here we go… In a recent HBR article, It’s Time to End the Battle Between Waterfall and Agile , the author sets up a false premise: There is a war between Waterfall methodology and Agile. The war must end. And finally, you can combine the approaches to get the best of both worlds. This sounds good, but the article is based on a misunderstanding of both Waterfall and Agile. Also, there is no war between Waterfall methodology and Agile. There can’t be, because Waterfall methodology does not exist! Waterfall is a name for large projects that failed in the 1960’s. Waterfall was never a methodology, but a failure to apply the methodologies that existed back then. As I will show towards the end of this article, at least one of the “successful” Waterfall projects mentioned in the HBR article was neither successful, nor a Waterfall project. I got invaluable help from Alistair Cockburn. He fact che
Read more

Performance Evaluations, Business Strategy, and Agile Methodologies

Image
It is performance evaluation time in many companies. This can be stressful, both to the people being evaluated, and the people doing the evaluation. In companies adopting agile software development methods, the tension can be extraordinary. Individual performance evaluations run counter to agile philosophy, which emphasizes team performance over individual performance. However, managers and corporate leaders need to take a few steps back, and consider the impact performance evaluations have on the organization as a whole. Especially now, in the midst of a recession, it is important to look at a companies current policies to see if they can be improved, or if they are actually holding the company back. So, how can a manager evaluate policy? Performance evaluation policies can serve as an excellent example. I'll confine myself to discussing the so-called ‘rank and yank’ methods. These are performance reviews were employees are ranked using a forced ranking system. It usually looks so
Read more

Agile Requirements Structures, Part 1

Image
If you have worked in large Agile projects or programs, you may have noticed that there is often quite a bit of confusion about requirements, what the requirement types are, their purpose, how to write them, how to use them, and above all, what not to do with them. There are many causes for this confusion. Here are some of the more common I have seen: Nobody in the organization has read up on the requirements model it is using, so everyone makes their own interpretation. The organization deviates from a standard requirements model, but nobody knows which standard model the organization is deviating from, and/or there is no agreement about how they deviate from it. The organization has not documented its own requirements model very well. The organization mixes two or more different requirements models, often without realizing it. The organization has documented its requirements model, but finding the documentation is an epic project in itself, on par with when Henry Sta
Read more