Insights into Change - from the Open Source Software movement

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?

Learning to facilitate - one step at a time

So just how do you learn to become a facilitator?  This is an important question, as many people are called on to serve as facilitators in meetings, and public training courses may not be easily available or affordable at a time when needed.

While I have been designing and running meetings for more than 25 years, I would say that I have been a professional facilitator for just over 17 years. I believe that I have become better at my craft over this time, and I cringe when I think back to some of the meetings that I ran back in the early days, when I did not know very much about facilitation!  Perhaps because I didn't attend any facilitation courses until I had been leading meetings for a good number of years (such things were not easily available in South Africa in the 1980s and early 1990s), I realized that I learned how to facilitate the same way many people do - by observing how other people facilitated meetings, and by being coached by more experienced colleagues...  (and I was fortunate to have some good coaches and role models!)

I had the opportunity recently to think about how people develop skills and experience in facilitating meetings.  Penny Walker, a colleague in London, wrote on her blog about how she works one-on-one with some of her clients, helping them prepare to facilitate meetings by themselves.

Responding to her blog, I recalled the way I have worked with a number of clients, advising them on how to facilitate meetings.  Because some of my clients are global organizations, it is fairly common that I am asked to help an individual or a team think through how they can facilitate a meeting or conference without the presence of a professional facilitator.  

In cases like this, I find that it helps to divide the task into 2 parts:

Design the Meeting.  What are your objectives?  Who is going to be there, and how long do you have for the meeting?  What design choices are available to you, given this context?

Facilitate the Meeting.  How much experience do you have leading and facilitating meetings?  What is your comfort level in running this specific meeting, according to the way it has been designed?  What support will you need to build your comfort to lead a successful meeting?

The starting point really does need to be the design discussion.  There are many more options available than plenary presentations with large group discussion.  And you can do more than have small group breakout sessions.  But your selection of activities should be driven by your purpose, and not by your comfort level in facilitating the session.

Once the design is determined, then we look at how to facilitate each step along the way.  As I said in my response to Penny, it can be intimidating to consider taking on an entire session by yourself.  But as we break the facilitation task into discrete steps (such as: forming small groups, giving instructions to the groups, managing small group reports), we give simple guidance and tips for accomplishing each piece.  And then as they are all integrated in practice, the task of facilitation become far more manageable for novice facilitators and meeting leaders!

What do you think?  Can you learn to facilitate meetings through one-on-one processes?

Newsflash: Penny Walker has written an article on this topic in the European newsletter of the International Association of Facilitators, and she kindly includes my original comments in the text.