I’ve been thinking about innovation, and how we can support and encourage fresh thinking in our organizations. Some of this comes from my interest in trying to better understand how organizations can renew themselves when their current business model is no longer supporting them in providing value to their stakeholders (see my recent posts on why innovation is so crucial for all organizations and the sigmoid curve of the timing of innovations in business model and organizational practice).
One thing that has drawn my curiousity is the open source software movement – I think of this as innovation on a mass scale, with the invitation to participate and contribute being issued to anyone who is interested. I went in search of further information on open source movement, and was led (as we so often are these days!) to an entry in Wikipedia called “The Cathedral and the Bazaar“
The title references an essay written by Eric Raymond, a software engineer, and his reflections of the early days of Linux, and the struggle between top-down and bottom-up design approaches. The wikipedia article summarizes the essay, and Raymond’s outline of 19 guidelines for creating good open source software.
I was struck by how many of these guidelines are relevant to the field and practice of change and innovation. See what you think of the list below!
Below I have provided a list of the 11 guidelines that have the greatest application for organizational work, with some of my own comments added…
1. Every good work of software starts by scratching a developer’s personal itch.
Every change process starts with an itch, be that a need to change an unsatisfactory situation, or to give shape to some potential, such as a vision for what might be…
2. Good programmers know what to write. Great ones know what to rewrite (and reuse).
Good change leaders know how to review and reuse what has been developed before by others, and don’t feel a need to invent it all themselves.
4. If you have the right attitude, interesting problems will find you.
Speaks for itself!
5. When you lose interest in a program, your last duty to it is to hand it off to a competent successor.
I like the orientation here – we are stewards of what happens in organizations, part of a community of people interested in its effectiveness and impact. When we don’t want to continue our involvement, how do we pass our responsibilities to others, rather than abandon the effort?
6. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.
View stakeholders as partners and co-creators – whether they can support and inform the process, or are beneficiaries of the change. It reduces resistance, and can introduce invaluable new insights and energy for positive change.
7. Release early. Release often. And listen to your customers.
While analysis, consultation and design are important, so too are field tests and experience. We will never get to the ‘perfect design’ of a change, so it is better to get started and make continued improvements as you get feedback from the early implementers or adopters of the change.
10. If you treat your beta-testers as if they’re your most valuable resource, they will respond by becoming your most valuable resource.
The early adopters are a critical and supportive audience. They want you to succeed, so their feedback is well-intentioned to help improve your design and your implementation efforts. Listen to them, and take on their suggestions.
11. The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.
… because the users are in the heart of practice, field-testing your ideas. They may have insights into what works, and why, that you may never gain from a distance. So value, acknowledge, and use their suggestions.
12. Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.
Our interests in developing and introducing necessary changes may be well-intentioned, but if we misunderstand the nature of the situation, we can too easily design ill-fitting ‘solutions’ that will not survive their engagement with reality. Listening broadly to different perspectives, and listening deeply to their analysis and insight, can allow us to appreciate the problem in fresh ways that lead to new thinking, and new solutions.
18. To solve an interesting problem, start by finding a problem that is interesting to you.
You need to have a stake in the problem, or else it is simply an intellectual exercise. You must genuinely be interested in the issue, and really want to see positive changes, as this is the source of motivation that will keep you engaged and listening when the work becomes more difficult.
19. Provided the development coordinator has a communications medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one.
Mobilizing a team of people as interested in the problem as you are, and taking the time to develop the communications platform and protocols to support your thinking and working together, will pay off. Diversity of experience and perspective will allow for a richer analysis of the problem situation, and provide a foundation for identifying and combining different ideas into novel solutions.
So what do you think? Which of these guidelines resonates with your experience of change in organizations?