An recent article from the Economist made me think about how companies could learn from the distributed innovation of open source to find the great ideas within. The article is about InnoCentive, which helps connect problems with solutions:

[Innocentive] is based on a simple idea: if a firm cannot solve a problem on its own, why not use the reach of the internet to see if someone else can come up with the answer? Companies, which InnoCentive calls “seekers”, post their challenges on the firm’s website. “Solvers”, who number almost 180,000, compete to win cash “prizes” offered by the seekers. Around 900 challenges have been posted so far by some 150 firms including big multinationals such as Procter & Gamble and Dow Chemicals. More than 400 have been solved. InnoCentive reckons the approach can work for innovations in all sorts of fields, from chemistry to business processes and even economic development. It has formed a partnership with the Rockefeller Foundation, a charity, to help solve problems posted by non-profits working in poor countries, with some initial success.

InnoCentive is now looking inwards with a new service called Innocentive @Work which “replicates the solver network inside a firm”:

Challenges are first offered to “seeker” companies’ own employees. Only if they cannot help is the outside network brought into play. “Companies often don’t know how much they already know,” says Dwayne Spradlin, InnoCentive’s chief. An early challenge at one firm was to find a source of some data, which, it turned out, had already been acquired by another division.

This is particularly interesting given that InnoCentive began in 2000 as e.Lilly, a place for pharmaceutical giant Eli Lilly to put out the problems it was failing to solve internally.

Right under their noses

The fact that InnoCentive is successfully being used to solve problems shows the power of setting up a structured framework for innovation. Why is this important? Let’s take a look at the open source software community and ask this: how can thousands of individual coders collaborate on something as huge as Linux or Android?

A large part is the framework in which contributors operate. Much of the coding that needs to be done is well defined and there is a solid framework for executing the solutions. Want to fix a bug? Go into the source code repository, download the project, work on your bit, test it and then upload it for community approval. All your contributions are tracked, and you can see who’s working on what and resolve conflicts. Because of this, a lone coder can quickly change just a single line of code (that’s what most do), while at the same time huge companies can put thousands of their people to task (for example, IBM has contributed 6.3% of Linux, and Sun is mostly responsible for Java).

What would happen if the strengths of this model were applied to business problems, which are a whole lot fuzzier? By what framework could a salesperson easily fix a bug in a large marketing campaign? Or an engineer contribute to an ethnographic study for a new vacuum cleaner? To be fair, programming has the particular advantage of being a granular, text based medium, but tools like Innocentive@Work could make problems visible within an organisation and give solutions a place to go (and the solvers to be rewarded).

InnoCentive is not the only service to link problems and solvers. In the same space are Hypios, InnovationXchange, NineSigma and Tekscout in US, PRESANS in France, Innoget in Spain, and Fellowforce. Moreover, this approach is not only for research and development in the traditional sense: just look at the success of Threadless in generating t-shirt designs, Fold.it for science (see NYT article) or the several dozen sites like TopCoder and ODesk which allow you to outsource self contained business problems, from coding to marketing.

As web based applications, these companies are essentially a testing ground for highly automated processes which allow people to contribute innovative solutions (or even just good work). Organisations should therefore keep a close on eye on the fittest of these services to see exactly what they do to make it easy to specify problems, maintain relationships with solvers and to communicate clearly.

Too often, innovation is forced to squeeze through bureaucracy. Implemented correctly, such automated frameworks could make it look a lot more meritocratic.

What do you think? Please comment below.

Wired has a great piece on the new trend of Hacker Spaces (via Boing Boing) communities of makers and hackers pitching in to create a space with the equipment that would be difficult for an individual to afford and make the most of:

There are now 96 known active hacker spaces worldwide, with 29 in the United States,  according to Hackerspaces.org. Another 27 U.S. spaces are in the planning or building stage.

For many members, the spaces have become a major focus of their evening and weekend social lives.

Located in rented studios, lofts or semi-commercial spaces, hacker spaces tend to be loosely organized, governed by consensus, and infused with an almost utopian spirit of cooperation and sharing.

“It’s almost a Fight Club for nerds,” says Nick Bilton of his hacker space, NYC Resistor in Brooklyn, New York. Bilton is an editor in The New York Times R&D lab and a board member of NYC Resistor. Bilton says NYC Resistor has attracted “a pretty wide variety of people, but definitely all geeks. Not Dungeons & Dragons–type geeks, but more professional, working-type geeks.”

Pretty cool. There’s an interesting detail in the piece about what has catalysed these Hacker Spaces:

The recent crop of hacker spaces has followed a rough blueprint prepared by Jens Ohlig called “Building a Hacker Space” (.pdf). Ohlig’s presentation is a collection of design patterns, or solutions to common problems, and outlines some of the best practices used by German and Austrian hacker spaces.

Design patterns are self contained best practices for solving specific problems, whose invention is credited to the architect Christopher Alexander. The idea is simple: even a complex design problem with no obvious solution is likely to be composed of many smaller elements which have been tackled before.

Christopher Alexander, an architect and author, coined the term pattern language. He used it to refer to common problems of civil and architectural design, from how cities should be laid out to where windows should be placed in a room. The idea was initially popularized in his book A Pattern Language.

Alexander’s book The Timeless Way of Building describes what he means by pattern language and how it applies to the design and construction of buildings and towns. However, the system has been used in many fields of design, from designing computer programs to designing a classroom curriculum.

When a designer is designing something (whether it is a house or a computer program or a stapler), they must make many decisions about how to solve problems. A single problem, documented with its most common and recognized good solution seen in the wild, is a single design pattern. Each pattern has a name, a descriptive entry, and some cross-references, much like a dictionary entry. A documented pattern must also explain why that solution may be considered a good one for that problem, in the given context. (Wikpedia)

Design patterns are ubiquitous and will be discussed again in more detail – for now it’s well worth checking out Jens Ohlig’s presentation for an example of the patterns you might use to design a successful community over and over again.

The most important thing in design and business in general is to put yourself in the shoes of your customer. Unless your target base is yourself, you will not see the product/service you have created in the same way as them. Just as importantly, even if you do understand your customer, or user, they will experience your creation in a different way. For example, they will probably have to discover it (you know everything there is to know), buy it (all you need to do is ask) and use it without anyone telling them what to do (you made it, you know how it works). Finally, how can you know that the service you have designed is delivered right?

The answer is this: dogfooding. Use your product! It’s that simple – although it sometimes means going out of your way (and it can be particularly difficult if you aren’t the target audience). And it’s not just about putting yourself in the position of the ultimate customer – you also have to understand the people making and delivering your idea.  The concept is well known from programming, but applies absolutely everywhere. Take Bobby McFerrin, an amazingly talented singer. He has found a way to manipulate his voice so that when he performs he doesn’t need any accompaniement to create multi-layered compositions. For example:

How does he do it? By being brutally honest with himself:

“It took me at least 2 years, 3 years, of going into a room by myself and turning on a tape recorder and singing before I felt comfortable singing in front of other people. I was afraid to sing around anyone. I was intimidated by the sound of my own voice. I would wait until the house was empty and then I would sing. So it took time. It took six years before I did my first solo concert. So it took about six years of singing constantly, doing a lot of practicing. For the first two years I didn’t listen to another singer. Because I wanted to find what my voice sounded like. Knowing myself, I’m very impressionable. It would have been very easy for me to shop around for a singer whose technique I liked, and use that as my base and try and do what they did, but I made the conscious decision not to do that. I just wanted to make sure that I had a strong base of my own, because I could easily flounder by going out and just copping somebody else’s licks. I used to do that as a piano player and I knew that wasn’t going to get me anywhere.” (link)

You can’t improve until you know what you’re doing.

A bit of homework

So take this concept of dogfooding and think about these two stories about the management of two well known companies. Here’s your homework: which of these two companies has bucked the trend of a declining industry, becoming a globally recognised innovator, and which one is the poster child for its tragically collapsing, bailout-needing sector?

AirAsia’s and its CEO, Tony Fernandes – (link)

Mr Fernandes says that he came to the industry with no preconceptions, but found it rigidly compartmentalised and dysfunctional. He wanted AirAsia to reflect his own unstuffy, open and cheerful personality. He is rarely seen without his baseball cap, open-neck shirt and jeans, and he is proud that the firm’s lack of hierarchy (very unusual in Asia) means anyone can rise to do anyone else’s job. AirAsia employs pilots who started out as baggage handlers and stewards; for his part, Mr Fernandes also practises what he preaches. Every month he spends a day as a baggage-handler; every two months, a day as cabin crew; every three months, a day as a check-in clerk. He has even established a “culture department” to “pass the message and hold parties”.

General Motors and its top management-(link)

Not only are managers and executives insulated from learning what goes in their company because they generally talk rather than listen, they are also insulated from experiencing what it is like to buy and own a car. GM has a perk for managers down to fairly low levels where all are given a GM car to drive – they rotate from one car to another. I am not sure of the exact details, but answers to the questions I’ve asked over the years  suggest it goes something like this: the lowest level managers have to buy their own cars, the ones at somewhat higher levels get a new car to drive every six months or so but have to do some servicing, the managers who are somewhat higher-up get somewhat fancier cars and are freed from any servicing (gas is even put in the cars of some executives so they don’t have to go to the service station), and the highest level executives get a car and a driver.

In other words, this system effectively insulates people in management – especially those in senior management — from experiencing what it is like to shop for, bargain for, purchase, service, and sell a car. They only get the driving experience. Well, except for the most senior executives, who don’t even get that experience — they watch a person in the front seat drive a big car.  Now, it is true, that the most senior executives do own GM cars for personal use, but it is my understanding that when a car is delivered to a senior executive, special attention is devoted to the car – even during the production process –to make sure the top brass aren’t exposed to a car with any flaws. Wouldn’t that be nice?

So there you have it, a system that seems designed to isolate executives from reality. They talk instead of listen and are protected from the experience of owning car. I might be exaggerating some, but not much.

It’s not too hard to guess…

How did Cisco go from one or two big new initiatives a year to 22 in the last one?

Most would call Cisco a bellwether for the technology sector as it is well managed and sells to businesses rather than consumers, which puts its in the front line of Mr Market‘s fluctuations. The company is now in the news for its planned New Year shutdown to help trim €1bn of costs (link). In last month’s earnings call, it announced that it is expecting Q2 2009 revenue to be down 5 to 10 percent on the previous year. Not great.

But Cisco is good at this. In the face of the 1997 Asian financial crisis, it continued to invest heavily in the afflicted economies and obtained a number one market position which it keeps to this day (source: HBR article). As John Chambers reminded listeners in that same call, “Cisco has always navigated [economic slowdowns] very effectively. We did this in 1993, 1997, 2001, 2003, and in each scenario gained both wallet share and in my opinion profit share. As a result we were better positioned coming out of these transitions versus our peers.” (link)

How will it deal this time around?

Collaboration!

Cisco’s TelePresence and other communications technologies make collaboration easier (and have allowed it to slash travel costs by 20%). However, it is the structuring of the organisation that is most interesting.

Cisco appears to have put the onus on employees from across the company’s divisions to form ad-hoc groups to pursue new opportunities, rather than being told what to do from up-on-high. The seniority of these groups depends on the estimated size of the opportunity, but each has enough independence, authority and flexibility to move decisively. In the words of John Chambers:

“At Cisco, our major priorities are managed not by our top five or top 10 executives but instead by cross-functional, collaborative councils and boards. And, in fact, our engineering organization – which is a third of our total employee base – is not run by a single leader but instead by what we call our Development Council, which is made up of the nine senior vice presidents who lead our engineering divisions. This companywide, council-based leadership model has allowed us to move from taking on only one or two cross-functional priorities a year in the past to addressing 22 this year. We think this is what organisations of the future will look like.”

He goes on to explain how boards and councils actually work: “boards and councils are the equivalent of social-networking groups, where groups of people with relevant expertise work together to make and execute key decisions supported by networked Web 2.0 technologies. Councils are established where we believe we have a $10bn opportunity, boards are created for €1bn opportunities, and working groups are formed for more tactical initiatives related to a board or council.”

“Working groups are accountable to boards, boards to councils, and councils to the Operating Committee, which consists of two dozen or so senior leaders at Cisco. Each person on a board, council, or working group has the authority to speak on behalf of their entire organisation, allowing decisions to be made in real time, with all who may be affected in the same room.”

V.S.E.

To push things further, there is a clear process driving these groups and keeping a consistent standard: VSE. These are three steps: 1) vision, 2) strategy and 3) execution.

“The councils and boards propose possible initiatives to the Operating Committee through highly detailed business plans that have to answer three questions: What’s the vision? What’s our strategy for sustainable differentiation? And how are we going to execute the plan over the next 12 to 18 months?”

“Each plan has an owner who makes a commitment to his or her peers and is held to that commitment and measured on his results. In fact, compensation for many of our top executives is based more on their success within the councils they belong to than their individual performance. In this way, management can consider many, many opportunities spanning the capabilities of the company, instead of just viewing them by silo or by function. This allows us to have a constructive discussions, get buy-in and execute rapidly.”

Why is this interesting?

Technology usually comes up when collaboration is discussed, but is often just a tool with little benefit in the wrong hands. Collaboration is hard, and is often implicitly discouraged by the organisation of large companies. The example of Cisco highlights how much (of the right kind of) structure it takes to get ideas flowing freely and has allowed it to run with 22 ideas at the same time. How?

1. Cisco has put together a structure which makes it much easier for ideas to bubble up from its 67,000 employees. Every corner of any business (sales, marketing, R&D, support, etc…) has its own approaches, strengths and weaknesses. Formalising these cross company groups allows the different functions to collaborate and speak with one voice.
2. Breaking down structures speeds up innovation and development, but can make it hard to channel. However, Cisco’s clear mantra of VSE gives each group the same benchmark against which to plan its offering and a clear plan to get it to market. This ensures they speak the same language so they can be heard within the company.

A final quote:

“To me, collaborative management means putting a lot of people who speak a common language to work towards a common goal.”

What other rules make collaboration work, and gets the results in the hands of customers?

Full article here (sadly behind pay wall).

“How quickly you get to the first crummy prototype, and show it to people, is directly proportional to the success of the product”
David Kelley

Iteration is the bedrock of successful creation and IDEO are one of its pioneers. Here is a short video of founder David Kelley explaining just how important it is.

Source: Stanford

In my own words:

1. Don’t spend months working on a product without showing it to anyone
2. You don’t find anything out until you show it to people
3. It’s like writing: get a draft and then it’s just an iterative process of correcting
4. If you show someone a prototype, people rarely tell you what’s right with it, but they sure as hell will tell you what’s wrong
5. Write everything they tell you and fix it – you’ll soon have a pretty good product

“Come on, it won’t take long. Just squeeze it in with that round of bugs. I’m sure it’ll work just fine. After all, it’s pretty simple isn’t it?”

Whether your team is stuck in the dark ages of waterfall development or has adopted an agile methodology (agile what? read this or this), this thought has probably gone through your head. Unfortunately, it far too often comes out of the mouths of managers.

The problem is that you often end up with unfinished, half working features which bloat the code, distract developers and confuse users. Left unchecked, these can become toxic to the project’s credibility and usability.

This is particularly important for projects with limited budgets, which can run into the wall with a backlog of bugfixes/feature requests (they’re not that different, really). These can hound you for a very, very long time.

The complicated answer? Follow a tried and tested agile methodology.

The simple answer: iterate thrice. Don’t implement anything that can’t fail at least twice.

What does this mean? Release quickly, test it on users, fix the problems, rinse, repeat.

How long does this take? If your users use your software daily, give them at least a week to spot the room for improvement. Increase this time as necessary. If you have a limited budget, never start a new feature unless you have that time before the money runs dry.

At best it’ll be only partly useful.

Worst case: it will come back to bite you.

You’ve just started a small software project with just one programmer or a small team. You’ve read Peopleware and Joel and your specifications are so lucid they bring a tear to the eye. You think you’ll be done in a couple of months.

This is how to screw up.

1. Don’t enforce high standards from the start. Tell yourself you’ll mention any sloppy work ‘later’ when things ‘kinda work’.
2. Micromanage. Whatever you do, don’t chunk tasks into interesting, self contained problems and certainly don’t trust the programmer to work out a good solution by himself. Got a little technical knowhow? If you can make enough highly specific suggestions you might just be able to atrophy his creative thinking completely.
3. Ignore gaps in your programmer’s skills; treat every task equally. Demand feats he finds impossible without offering training and motivation.
4. Be a bottleneck. If you’re lucky you’ll completely drain the momentum from the project.
5. Don’t communicate every day. It only serves to maintain the sense of urgency, and nobody has ever needed forum to resolve issues before they escalate.
6. Allow your programmer to ignore good testing practices. Also, make sure you test his work for him, so he never feels that quality assurance is his responsibility.
7. Never set clear, reasonable deadlines.
8. If by some freak chance you do set one and it is missed, never talk through the why and how.
9. Never, ever, ever communicate the impact of your coder’s hard work on the business. Keep it abstract, you wouldn’t want any perspective to creep in.

What have I missed?