JUST A THOUGHT: Innovation 2.0: Lessons from The Economist
In April 2006, when its Internet Strategy Group met to discuss ways of improving the company’s presence on the Internet, the Economist Group was doing very nicely, thank you. Global circulation of The Economist (its flagship newspaper) had passed one million for the first time in the previous year. Roll Call, a sister magazine, had been for some time the most widely read publication in the US Congress. The Group had also successfully launched titles in China and India, its website was profitable (a rare thing in newspaper publishing), and other Group businesses were flourishing.
All in all, it was a time when most businesses might have been happy to build on what they’d got. Instead, the Group Management Committee (GMC) approved a proposal from their CIO Mike Seery to recruit a team of five people plus himself from within the Group, remove them from their current jobs, and give them £100,000 and six months to develop and launch an innovative web-based product, service or business model.
By early 2007, when the team on Project Red Stripe started work, things were looking even better. Unique visitors to the Economist.com website were up 39% on the previous year and Economist Group profits, at £44.3 million, were 23% up on the previous year.
While all the circumstances looked auspicious, the enthusiastic young team soon found themselves challenged from all directions. Many of the problems they faced would be immediately recognised by any innovation team; the solutions they found were often ingenious and the lessons they learned could be applied in thousands of businesses around the world.
In a rare move, The Economist team invited me (my background is business writer, psychotherapist and, now, ‘trainee corporate anthropologist’) to observe them at work over the next six months. My account of that time has been published as a ‘serious’ guide for innovation teams[i]; but here’s the condensed story for teamworkers and innovators in a hurry.
Mike Seery used a series of webcasts to recruit his five fellow team members from across The Economist Group. He set out to attract (and found) people from editorial, sales, marketing and IT – to get a good balance of skills and interests. He also wanted to bring team members from around the world to the project (which was based in London) – and he managed that too. For an international business like The Economist this might all seem enviably easy.
With hindsight, though, it raised a couple of important questions:
Two of his team members came from afar: one relocated to London from Beijing for the six months (leaving his family behind) and another commuted weekly from Berlin. By their own admission, it put a strain on their family lives and an unexpected pressure on the team: team members normally based in London had life as usual to lead in the evenings, while the overseas visitors were free to work ‘silly hours’ without the usual domestic commitments.
The Economist not only kept open each team member’s job for the six months that they were on Project Red Stripe, but team members were recruited on the strict understanding that this wasn’t an opportunity for people who were bored with their jobs or wanting to leave the company. That meant that the team got people who were loyal to the company and happy in a corporate environment. The most potentially dissident or subversive (and therefore creative?) people were automatically excluded.
Think hard about ‘fairness’ when you recruit innovation team members from far afield.
Team members from different countries and cultures and from different disciplines and professional backgrounds brought a huge range of experience, but the team had a lot of catching up to do before they were able to work together really efficiently. For example, for a long time the techies’ knowledge of Web 2.0, mash-ups, emerging technologies (then) like Twitter, and so on, left some of the others floundering. And a lot of team-building needed to be done before the business of team-working could get under way.
Consider whether it’s better to bring together a team of people who already know each other, share a common professional language and have skills in common – and then buy-in financial or marketing or design skills as needed? Or do you prefer a broad knowledge-base but allow for problems in getting team members acclimatised to one another?
Recruiting team members who want to return to their old jobs at the end of the project helps ensure that you don’t just hire the disaffected. But the disaffected may also be the most creative.
Project Red Stripe was CIO Mike Seery’s baby. He developed the idea, recruited the team and ran the project. He was the default team leader. On one hand that was easy and obvious and saved a lot of time and discussion. On the other hand, he wasn’t necessarily the best person to lead that particular group at all times. At the creative thinking and execution stages, for example, might one of the others have been more effective?
The team discussed this and, for a while, they had an arrangement whereby whoever was standing up was temporarily acting as team leader. It didn’t last long. The coach to the team was convinced that, if you bring together people from one organisation, existing job roles and seniority are bound to carry through into the team. Another adviser to the team recommended that the job of team leader be treated like any other task and should be elected and/or rotated.
Think through how you’re going to handle leadership issues before the start.
Although the team members brought with them their own ideas about what The Economist should do next, they set about finding ways to harvest ideas from Economist readers and other interested parties. In using this crowdsourcing approach, they followed James Surowiecki who puts his faith in ‘The Wisdom of Crowds’[ii] rather than innovation expert Clayton Christensen, who maintains that you’ll only ever get modest, incremental innovation ideas from existing customers (who won’t be able to imagine ‘disruptive’ new innovation possibilities)[iii].
In fact, ‘the crowd’ didn’t come up with anything that the team hadn’t already thought of. So you could argue that the time they spent crowdsourcing was time wasted. But what if they had come up something spectacular that way? How would you ever know without asking?
And there was a further twist on this. Prediction markets are a way of getting large numbers of people to guess or bet on the likely outcome of something. They work remarkably well – better than even the most talented and experienced individuals at predicting the future. So what about starting a prediction market and inviting interested outsiders to bet on what innovation your team is going to come up with? It ought to work better than trying to decide yourself.
Think very carefully about who is best placed to identify the best possible innovation for your organisation. Is it you and your team? Your customers? Experts? The world at large?
On a related topic, Henry Chesbrough’s Open Innovation model[iv] suggests that innovation teams should use external ideas and external paths to market. In looking for external ideas, The Economist team met a lot of criticism from people who said that a wealthy company was looking for ‘free ideas’ that they could exploit and commercialise. (The team had offered a free subscription to the newspaper to anyone who submitted an idea that they used – on the grounds that you couldn’t possibly offer a share of a non-existent business and on the grounds that people who volunteered free ideas were people who could not hope to bring those to market themselves.)
If you use crowdsourcing, find a way to solicit ideas that won’t be seen as exploiting your customers.
The Economist Group gave Project Red Stripe incredible freedom. There were no guidelines on what sort of innovation they should look for and they were free to launch the idea without first getting approval from the directors of the company.
In practice this freedom caused the team a lot of headaches. For example, there was no requirement for the idea to make money and, for some time, the team was working on a not-for-profit idea. And, in the end, the freedom was unrealistic. The team weren’t willing to jeopardise the business by launching an idea they believed in without first getting approval from the top – because their employer stood to lose a lot of face and a lot of money if they closed down - or failed to back - a business launched by Project Red Stripe. And, when the team asked for approval, they didn’t get it.
In terms of creativity, too much freedom can cause problems here too. The Project Red Stripe team could do anything. If you work for Acme Gizmos, that may not seem too exciting. If you work for a newspaper that’s read by decision makers around the world and carries enormous influence, it’s a big deal. The team, at one point, were working with top NGOs and their advisers to develop a business that would help the United Nations achieve one of its millennium goals. When world peace is within your grasp, why would you consider a humdrum, commercial web venture?
Be realistic about how much freedom you can give an innovation team in practice. It may turn into a millstone that serves to hamper execution, even if it gets the creative juices flowing.
‘Thinking big’ is obviously necessary for a major innovation project, especially as it’s notoriously difficult to get people to think beyond the confines of their current reality. But giving people the freedom to try and change the world may leave them a little dazed by the enormity of what they might be able to achieve.
Doing it in public
Project Red Stripe set out with the intention of being completely open at all times. They had a public blog in which they recorded what they were doing, thinking and talking about. They had a webcam always on in their office. They sought publicity at every turn. But, at a certain point, they went quiet. Once they had chosen their idea, they felt that its commercial viability would be threatened by being too open. This provoked considerable negative comment.
At the same time, while they were in their ‘open phase’, and particularly because they were The Economist, they looked for – and received – a lot of publicity. This was good for morale, good for getting ideas in, and good for helping them find expert advisers. But it also meant that they had to devote a lot of time and thought to their own PR. None of them was a PR expert and they didn’t have the budget to hire one.
Think carefully about whether your ideals are achievable in a commercial world and consider the spin-off costs of overtly courting publicity.
Flocking and Hunting
Writers like Arie de Geus have talked about people’s need to ‘flock together’ to talk, share ideas, brainstorm and so on, and their need to disperse in order to ‘hunt’ ideas, contacts and new opportunities[v].
The Project Red Stripe team chose to move out of The Economist offices and take a room in their advertising agency’s offices. This removed them completely from the distractions of their day-to-day work. But the room was tiny and they spent six months working together in what their coach, Javier Bajer, called a ‘cockpit’. This was inevitably stressful at times, but it meant that they were almost always together to discuss ideas and developments as they happened. If they’d been working remotely, or in their usual offices, would the distractions and communication problems have outweighed the advantages of not being on top of each other fort six months?
Give very careful thought to the physical space that your innovation team is going to occupy and to their proposed working practices.
Innovation expert Jeneanne Rae and her colleagues (who recently analysed sixty innovations in the service sector), talks at length about risk aversion[vi]. She explains that big enterprises are large because they’re successful and success is a barrier to innovation. (We’ve already seen how well The Economist was doing at this time). So, why try something new and risky when what you’re doing now works? If it ain’t broke, why fix it?
So The Economist didn’t need a new business - they had a very good one already, and it wasn’t showing signs of drying up any time soon. In this case, therefore, the team found they had to do far more than just come up with a business. And this fact alone explains why the two key ideas developed by Project Red Stripe – codenamed Lughenjo and HiSpace – never happened. The Economist didn’t need them enough and the project team members had great jobs at a prestigious publisher – they didn’t need to leave and try to run either of the proposed businesses as a start-up.
Do a risk assessment. Is the sponsor organisation or the innovation team itself under sufficient pressure to want to run with whatever idea the team comes up with?
Early on, Mike Seery organised a number of teambuilding games and exercises. They worked well and some were seen as significant moments in the team’s own history and in the stories that it told about itself. But they also served to establish a particular mindset – ‘we’re good at this and this, but less good at that’. It might be useful to give a team the chance to redeem itself after exercises like these, rather than risking that it define itself as ‘bad at planning’.
The moments in a team’s trajectory when you most need to run team-building exercises (late on, when the team’s under extreme pressure) are, almost by definition, the moments when you haven’t got time to run them.
From the outset, and especially while they were looking for ideas, the Red Stripe team sometimes ‘wandered around’ without a clear sense of what was going to happen next and without clear rules about how it might be going to happen or what they should be doing about it. Jurgen Habermas talks about something like this when he discusses ‘action oriented to success’ and ‘action oriented to understanding’ and the different modes of thinking and communication that they require[vii].
Instinctively, drifting seems like an appropriate thing for an innovation team to do; but it’s also an uncomfortable and anxiety-inducing thing to do at any time, and especially in a business context.
For myself, I would choose this state of drifting as the most profoundly productive one. Others would say that safety is a prerequisite of productive enquiry or creativity. Probably both views are correct. Certainly there were some members of the Red Stripe team who worked hardest and fastest when they know where they’re going.
Drifting ‘aimlessly’ can be a profoundly creative process, but it’s also anxiety-inducing. Participants (and Finance Directors) may want something more regimented. Rules and guidelines can offer direction or serve as blinkers. It may be important to have some clear guidelines in place before the innovation project begins.
In the last weeks of the project, there was some debate later on about whether the team should have been offered a financial bonus for a successful outcome, or a share in the resulting business. All but one of them said that some kind of financial incentive would have helped. Yet it was clear from my conversations with them from and the websites and blogs that the participants had created as part of their applications, that the opportunity to work on a groundbreaking project like this for The Economist, to get away from the routine of their usual jobs and to have a chance of coming up with the next Google was already a massive incentive.
So what was it that led people to look for a further financial incentive? Probably it was connected to how the project was going. Had the team members felt that they were on the verge of creating the next Google, they would all probably have been happy with the kudos and happy just to be part of it.
If an innovation project is set up well, the drive for success ‘should’ be sufficient motivation for the participants. At the same time, not to give participants a stake in the project’s eventual success can seem inequitable. Then again, trying to work out an equitable way of giving them a stake in something that hasn’t even been thought of yet is almost impossible.
Even a team with a clear leader is likely to want to act democratically and move forward with general agreement that they’re on the right lines. This team, however, came together with some ideas already about what they might do. During the early months, different team members grew first committed and then attached to different projects. That made getting a consensus for just one idea almost impossible. For Mike Seery to make the choice himself, or for the team to move forward on a majority vote, but with some members clearly opposed to the chosen idea, seemed both undemocratic and divisive. On the other hand, they couldn’t afford to spend all six months deciding which idea to pick.
Consider whether you should opt for ideas that excite everybody or simply for ones that command a majority. If you can’t find an idea that excites everybody, for how long should you keep looking? Should you set a deadline for that in advance? If you do set a deadline for agreeing an idea, will the team inevitably keep arguing right up to the line?
Petruska Clarkson is one of several people to have written about the Achilles Syndrome[viii]. One of the characteristics of this particular fear of failure is a mismatch between externally assessed competence and internally experienced competence, leading to feelings of ‘I am a fraud’. For example, at Red Stripe, we’ve already seen that team members were hired for their experience and competence in particular areas. That’s useful, in that you get a marketing expert and someone with experience of putting together a business plan, and so on.
The downside is that the marketing expert may not have experience of marketing this particular kind of business, and the IT expert may not know that much about some aspects of Web 2.0. But everyone else on the team assumes that they do. What’s more, because there’s an ‘expert’ on the team, everybody else assumes that they don’t have to worry about things that fall into someone else’s area of expertise.
If you hire people who know a lot about a particular subject, they may have a vested interest in showing that they know everything about it. Hiring people who know less may mean that you get people who aren’t embarrassed to admit the gaps in their knowledge and go out and fill them. Or it may just mean that you get people who know less.
An obvious question for any innovation team is whether to start by thinking about a particular group of customers or market – and how to solve a problem they have or deliver a service that they need – or whether to think about existing products, services and skills and how to improve them, exploit them or develop them. Theorists tend to prefer the former, but plenty of great innovations come out of companies finding new applications for existing technologies. (Think of classic innovations like 3M and Post-It Notes or NASA and Teflon).
Starting with the customer and the needs of the market, or starting with existing products and knowledge and capabilities, may lead to very different innovative outcomes. While the Project Red Stripe team actively solicited ideas about what they should do, they did not solicit ideas about the group(s) for whom they should implement those ideas. Should they have invited an archbishop, an aid worker, a genetic researcher and others to pitch for a particular target market? I doubt it. But, for me, there was a noticeable change of temperature when they stopped discussing their ideas in a vacuum and began to consider whom they would benefit and how.
In any case, it’s possible to end up with a market that you cannot hope to serve, or an idea that nobody wants. Or, as one facilitator said to the team, ‘although there may be a gap in the market, the key is whether there’s a market in the gap.’
A deserving market may be motivational, even inspirational. But it doesn’t necessarily make for good business – as we can deduce from observing the investment priorities of any large pharmaceutical company. The team may need guidelines for how to value a commercial priority against an ethical one in business. In the same vein, if you’re going to wheel in technological experts or financial consultants, should you also wheel in archbishops and others to help you decide which market is the most deserving?
Early on, the Project Red Stripe team had decided to eschew ‘incremental’ improvements, largely on the grounds that The Economist would do them anyway. They were looking for something more exciting, more visionary, further over the horizon.
This is tempting thinking. But experience suggests that, while some great innovations, like the motor car or the telephone or the World Wide Web, look like quantum leaps, they were actually achieved by slowly and painstakingly building on existing knowledge and technologies.
It may be wise for an innovation team to remember that quantum leaps are actually composed of myriad incremental improvements.
The Economist’s Project Red Stripe succeeded in that it came up with a number of radical and innovative business proposals. It failed in that the company chose not to commercialise any of them at the time. It also succeeded in that it offered the business powerful learnings about its culture and about future innovation projects - just a few of which are shared here and may provide food for thought for other innovation teams around the globe.
[i] A. Carey, Inside Project Red Stripe (Axminster: Triarchy Press, 2008).
[ii] J. Surowiecki, The Wisdom of Crowds (New York: Random House, 2005).
[iii] C. Christensen, The Innovator’s Dilemma (New York: HarperCollins, 2000).
[iv] H. Chesbrough, Open Innovation (Boston, MA: Harvard Business School Press, 2003).
[v] A. De Geus, The Living Company (London: Nicholas Brealey Publishing, 1999).
[vi] J. Rae, “The Keys to High-Impact Innovation,” Business Week, Sept. 27, 2005.
[vii] J. Habermas, The Theory of Communicative Action (London: Beacon Press, 1981).
[viii] P. Clarkson, The Achilles Syndrome: Overcoming the Secret Fear of Failure (Shaftesbury: Element Books, 1994).