Q&A on the Book OpenSpace Beta - A Handbook for Organizational Transformation in Just 90 Days

The book OpenSpace Beta by Silke Hermann and Niels Pflaeging describes an invitation-based approach for rapid and lasting organizational change using concepts such as OpenSpace and the BetaCodex. It provides a visual timeline with roles and components to guide a co-creation based transformation.

InfoQ readers can download a sample of the OpenSpace Beta handbook.

InfoQ interviewed Hermann and Pflaeging about how OpenSpace Beta looks, what makes a self-organizing and engaging approach robust and successful, the role game mechanics play in organizational change, the role of the sponsor and master of ceremonies in OpenSpace Beta, the function of the Proceedings that come out of the two OpenSpace meetings, what happens during the 90 days after the first OpenSpace, and why the role of Coaches is time-boxed in OpenSpace Beta.

InfoQ: Silke, why did you and Niels write this book?

Silke Hermann: In early May 2018, Niels and I spent a few days in Portland, Maine, due to a speaking commitment Niels had at the Agile Maine conference. This was just a few weeks after I had sold my shares in Insights Group Germany, a company that I had co-owned and led together with a German partner for more than a decade. So I was a bit concerned about my professional future at the time, even though Niels and I had started founding a new company called Red42. On that particular evening in early May in Portland, Niels and I had dinner with Daniel Mezick, the agilist maverick Niels had just toured with for a couple of days. We talked about changing organizational systems, or models, and about how to make use of people's motivations and potential. Daniel shared his ideas about invitation-based approaches to change, instead of imposition-based process. We talked a lot about how to frame change differently, so that it can be time-boxed, reliable, robust and “with all the right people”. Daniel had developed this sort of approach to make Scrum and agility happen, calling it OpenSpace Agility. And we had this hunch that the same kind of approach should also work transforming not just software development, but entire organizations of any kind.

The next day, the idea for OpenSpace Beta was born. Niels and I fleshed out the rough concept over the two following days, during a stay in New York City. We re-shuffled the launch agenda for our start-up Red42. Thanks to Daniel and his consistently open source way of collaborating, we were able to draft and develop the whole approach very quickly. We managed to write and publish the OpenSpace Beta handbook & timeline within just five months, and offer the first sold-out certification/qualification course within eight months.

InfoQ: Why the rush?

Hermann: In a way, OpenSpace Beta came to us like a shock. We wanted to share this with the world as quickly as possible. Not just in a few years, but now. In order to understand our urge, we should add a little context, though. Niels and I have been working on organizational transformation to Beta for some 15 and 10 years, respectively. Niels, in particular, was a Beyond Budgeting Round Table director from 2003 on, and he first experienced the struggle of creating an appropriate method for full-fledged organizational transformation during that time. Niels went on to establish the BetaCodex Network, in 2008. And that network was set up specifically to solve the riddle of fast & robust transformation. At pretty much the same time, he and I began to write articles, papers and books about Beta organizations, about organizational transformation, and the two of us devised concepts such as Org Physics, Complexitools, and Change-as-Flipping.

But we were never quite satisfied with the overall approaches to the change work itself that existed or we had put together. Even though we took inspiration from the likes of John Kotter, William Bridges, Alan Deutschman, Art Kleiner and many more, the actual transformation work still took way too long. And the process was way too fragile; the work was always over-dependent on consultants such as ourselves, and on the relationships that the consultants would forge with the client system.

So we had been screening the market for years, in order to find dramatically better ways of pulling off the organizational transformation. And when we grasped the power of Daniel´s OpenSpace-based, invitation-based approach to transformation, all the pieces finally came together. By combining the elements of Beta with OpenSpace Beta, Very Fast Organizational Transformation is becoming possible anywhere, and available to anyone. And we thought If we can make this available in just a couple of months, what keeps us from doing it? Better still, Beta, OpenSpace Beta and OpenSpace are all open source social technologies. So “available to all” is not meant as just another metaphor here. We mean it literally. It can actually be done by anyone, by just adhering to the CC-BY-SA license from Creative Commons. And we think that is pretty cool.

InfoQ: For whom is your handbook intended, then?

Niels Pflaeging: The OpenSpace Beta handbook is a how-to guide. It serves to explain the approach and method, and it works as a companion guide to the OpenSpace Beta experience itself. No more, no less. In the handbook, there is a short introductory chapter about foundations of Beta, and there is a glossary at the back. All else is about how to actually set up the rite of passage that is OpenSpace Beta. We wrote this handbook with organizational developers, change professionals and managers in mind, but also with the aim to make it readable and attractive for literally anyone working in a company that goes through, or wishes to go through, the OpenSpace Beta rite of passage. Consequently, we aimed to keep the prose in this book as simple as possible.

Early in the process of conceiving the approach, we decided to make the handbook colorful and readable for everyone: The handbook texts had to be short and crisp. We also decided early on to use icon-like illustrations for each of the 31 key concepts in the book and to design a cool, colorful timeline to OpenSpace Beta that everyone would want to use. We wanted to bring home the message that OpenSpace Beta is a highly attractive alternative to the boredom and the imposition-based squander that is change management as we know it.

InfoQ: A full sequence of components of OpenSpace Beta is called a “chapter”. What does an OpenSpace Beta chapter look like?

Pflaeging: The overall structure of OpenSpace Beta is simple: invite everyone in the organization to do the change work, together. Then begin in OpenSpace and end in OpenSpace, with a 90-day period of joint Practicing, Flipping, Learning in between. That is the fundamental structure of OpenSpace Beta that is also visualized in the timeline.

To make full-fledged organizational transformation happen in such a simple, elegant way is not trivial, of course. It contradicts great many conventional assumptions that we hold about change, about organizational development and leadership. One also has to set the right boundaries to unleash the level of self-organization required. In other words, you have to put all those 31 indispensable components in place that Silke just mentioned. If you do that, then self-organization, engagement and mindful organizational development undertaken by all can unfold, making very fast transformation possible.

InfoQ: What is it that makes a self-organizing and engaging approach like this robust and successful?

Hermann: I think the best way to put it is that coherence matters. We summarized the approach in an indivisible set of short principles for what we have come to call Very Fast Organizational Transformation. The principles go like this:

1. Principled, not ambiguous
2. Timeboxed, not indefinite
3. Radically inviting, not imposing
4. Whole-system, not piecemeal
5. All at once, not stacked

If you look closely at these principles, then you will notice that traditional change management and even the way Agile and Scrum are brought into organizations today, flatly ignores or opposes these principles. That is why we see so much failed Agile and fake Agile out there today. Those principles must really be adhered to, in order to keep the energy up and liberate engagement. To work the system together. To focus everyone on the outcomes. To involve everyone right up front - not later, when some kind of “implementation”, “execution” or some sort of “roll-out” is supposed to happen!

InfoQ: How can game mechanics make organizational change easier?

Pflaeging: I would not say that game mechanics make change easier: Game mechanics are one of these things that are absolutely indispensable if you want to work the system together, with all members of an organization. Without the mechanics of a good game, radically self-organized, fast transformation simply cannot be pulled off. Why? Because you cannot involve everyone, up-front, and get them to work the system if the whole endeavor does not have the characteristic of a “rite of passage”, or a good game! The amount of collective energy unleashed will just not suffice if game mechanics aren't employed. In essence, game mechanics have little to do with “games” or gaming, but more with social dynamics and the boundaries that are required to release collaboration and self-organization, combined with a high level of social density.

InfoQ: Does this mean that you would liken work to a game as well?

Pflaeging: Oh yes. We always like to emphasize that the business itself is already gamified. Always. Business is the biggest game that exists! So, generally speaking, we would not have to “gamify” work - it should be feeling like the greatest game already.

However, what studies such as Gallup´s engagement index and our day-to-day experience in work and organizations show is that it does not appear that way. Even 40 or so years after the end of the industrial age, work remains a burden for most. Work, broadly speaking, still sucks. While the nature of the work has changed profoundly for most of us, we have not transformed the systems of work or our organizational models. We remain stuck with bosses and command-and-control, instead of look out to clients, and sense-and-respond to markets. That is our responsibility today; not so much to change the nature of our businesses, but to change the nature of work systems. We have to take out the impediments that hinder people from experiencing value creation, from the fulfillment of their own potential, from growth, fun and joy at work. And that is very much the essence of Beta, or the BetaCodex: to release the full potential of people, teams and organizations that are already there, but which until today is just sitting there, crippled by steering, bureaucracy and command-and-control organizational models.  

InfoQ: Two roles seem to stand out among the 10 roles that are described in OpenSpace Beta, the Sponsor and the Master of Ceremonies roles. What are these roles about?

Pflaeging: That is exactly right: The roles of Sponsor and Master of Ceremonies are certainly the most complex of all the roles in OpenSpace Beta. The Sponsor role is taken on by a single person in the organization who is capable of inviting everyone to join the first OpenSpace Meeting in OpenSpace Beta. The Sponsor also has to write the invitation; in this written document, the Sponsor outlines the urgency or the rationale of the transformation, and the principles to be adopted. And the Sponsor will take care that the agreements from the OpenSpace Meeting will be put into practice. So the Sponsor is really the key figure with whom OpenSpace Beta starts.

The Master of Ceremonies serves the Sponsor to fulfill her or his role and guards the OpenSpace Beta rite of passage. We like to think of the Master of Ceremonies as the “guardian” of the OpenSpace Beta chapter. This person must be from outside the organization in question of transforming. He or she is something of a “process Gandalf”. While the Sponsor might be compared to Thorin Oakenshield because he is in charge of the mission at all times, the figure of the guardian is more like Gandalf: a confident, knowledgeable and wise companion. This person understands the dynamics of the rite of passage, thinks ahead calmly, and safeguards the rite of passage.

InfoQ: What is the function of the so-called Proceedings that come out of the two OpenSpace meetings in OpenSpace Beta?

Hermann: Looking back at how OpenSpace was formed, or conceived, by Harrison Owen in the early 1980s, it is obvious that Harrison intended to apply OpenSpace inside of organizations, for the sake of organizational development. He was part of a significant 1980s/1990s movement of consultants, Marvin Weisbord and our friend Paul Tolchinsky among them, who attempted to “get the whole system into the room”, in order to employ self-organization and emergence for profound org change.

Once you take a closer look at the history of OpenSpace, however, you notice that it never actually took hold in organizational development. Instead, during the last 10 years or so, it became increasingly popular, even fashionable, as a technique for open, public conferencing; out of the window with the monotony of frontal PowerPoint fatigue - here comes the self-organized, multi-choice peer gathering, in which no one shall obey speakers or a set agenda, but the law of the two feet alone! All bar camp and unconferencing method today is rooted in OpenSpace, to a certain degree. Which is great, in principle. But it also creates a problem; because within these OpenSpace derivatives, documentation of session outcomes does not matter much. There usually isn't even a shared “burning platform”, or a specific, urgent problem to solve. When you employ OpenSpace in the context of organizational development, then session documentation, as well as crafting things like well-defined OpenSpace themes and invitations matter very, very much!

So usually, if you have experienced OpenSpace-based public conferences alone, you may have never noticed elements of OpenSpace that are actually indispensable - such as a pointy theme, a well-crafted invitation, and session proceedings, or documentation. Now, in OpenSpace Beta, the proceedings from OpenSpace Meeting 1 and OpenSpace Meeting 2 are the raw material for disciplined, and focused Practicing, Flipping, Learning. Without them, it would be impossible to follow up on the agreements made during the OpenSpace Meetings.

InfoQ: What typically happens during the 90 days after the first OpenSpace?

Pflaeging: Well, the Kraken is released. So to speak. (smiles)

Members of the teams and the organization are empowered to take action within a predefined period of three months, and within the principles of the BetaCodex - to which additional principles such as those of the Agile Manifesto, Scrum, Lean or QRM can be added. This way, in effect, everyone can work the organization, within the consistency of the vision of the BetaCodex.

InfoQ: What's the purpose of the second OpenSpace meeting?

Pflaeging: It is great you are asking that Ben, because I know you have written a successful book about agile retrospectives. And what the second OpenSpace Meeting or OS 2 is, in OpenSpace Beta, is exactly that: It is a Very Large Retrospective - done after a 90-day period of working the system, together. OS 2 is longer than OS 1, to allow for more in-depth retrospective and reflection.

InfoQ: Why is the role of Coaches time-boxed, in OpenSpace Beta?

Hermann: This is one of those brilliant ideas we picked up from Daniel Mezick. This little concept solves a huge problem of organizational development, by creating a crucial boundary. In conventional agile projects, or in change management, support by outsiders - experts, consultants, coaches - drags on and on and on forever. And that creates a plethora of problems. Among them, the problem of dependency, or learned helplessness on the side of the client organization. The problem of uncontrollable, excessive cost, and of immoral incentives on the side of the consultants (“Let's keep on working for them because it pays our bills!”, and more). So with the second OpenSpace Meeting, all Coaches, and the Master of Ceremonies as well, must go away and quit their roles for the client organization, for at least 30 days.

The resulting Quiet Period gives the organization the opportunity to level up. To become aware of its independence from external support. And to consolidate its learning. After that, it may star the OpenSpace Beta ritual all over again!

About the Book's Authors

Silke Hermann and Niels Pflaeging are founders of Red42, an innovation-centric start-up on the fringe of organizational development and Learning & Development (L&D). Hermann and Pflaeging are the authors of three books: the recently published OpenSpace Beta (2018) and the work/life organizer The Uncomplicated Year (2016), and the forthcoming Complexitools (in English in 2019). They have each authored business books, individually, too. Together, Hermann and Pfaeging are the creators of Org Physics and Change-as-Flipping - to name just two of their most influential concepts, or thinking tools so far. Both have run businesses for more than 15 years. As entrepreneurs, advisors, speakers and authors, Hermann and Pflaeging have earned a reputation for being highly progressive business thinkers and innovators. You can reach them at Silke.Hermann@RedForty2.com and Niels.Pflaeging@RedForty2.com.