How super-fast Beta transformation was invented
Companies of all kinds can transform from Alpha to Beta in just 90 days, thanks to the OpenSpace Beta approach. Before 2018, pulling off something like that seemed entirely impossible
In early May 2018, Silke Hermann and I spent a few days in Portland, on the US East Coast, taking advantage of a speaking commitment I had at a conference called Agile Maine. Silke and I had visited Maine once, and we thought experiencing Springtime in Portland together could be a treat, before heading down to New York City. In early 2018, Silke had sold her shares in a company she had co-owned and led for more than a decade. Consequently, while in Maine, she felt a tad uneasy about how exactly her professional future would unfold. But we had already started to make arrangements to form a brand new company, which would specialize on organizational development and learning, called Red42. Things would take another turn soon.
On that particular evening in May, Silke and I had dinner with Daniel Mezick (pictured above), the agilist maverick I had just toured the US East Coast with for a couple of days. Dan and I had keynoted at Agile Maine during the day. Now we discussed with Silke, who was in a terrific mood, about the decline of Agile, the quest to change organizational systems, or models, and about how to make good use of people's motivations and potential, in software development and beyond. Daniel shared his well-formed ideas about invitation-based approaches to change, as opposed imposition-based process. We talked a lot about how to frame change, or transformation differently, so that the change work itself could be time-boxed, reliable, robust and performed together “with all the right people”.
Over the course of the previous years, Daniel had developed this sort of approach to bring Scrum and Agile about, calling it OpenSpace Agility. Over dinner, Silke got a hunch that the same kind of approach might work for transforming not just software development, but entire organizations as well. Later that night, the idea for OpenSpace Beta was born. Silke surprised me with the insight that the key to successful, stable and very fast organizational transformation was in time-boxing it – and make the seemingly impossible happen in just 90 days.
I coudn’t disagree. Over the following days, during a stay in New York, we fleshed out the rough sketch of the first-ever take on time-boxed transformation. Thanks to Daniel and his consistently open source way of collaborating, we were able to draft and develop the new transformation approach very quickly. Silke and I had to re-shuffle the launch agenda for our company Red42, but we managed to write and publish the OpenSpace Beta handbook & timeline within just five months. The book, now in its 3rd edition, was released with BetaCodex Press in October 2018. The first sold-out certification/qualification course with participants happened in January 2019. The first international course, with participants from seven different countries, followed in June of the same year.
Surprise element
In a way, OpenSpace Beta came to us as a shock back then, in Maine. Now that we had the insight, Silke and I wanted to share this approach with the world as quickly as possible. Not just in a few years, but right then. In order to understand our urge, some context might help. Silke and I had, at the time, worked on organizational transformations from Alpha to Beta for some 15 and 10 years, respectively. I was a Beyond Budgeting Round Table director from 2003 to 2007, and it was during those years that I first experienced the struggle of creating appropriate method for full-fledged organizational transformation. The challenge seemed impossible, and just two of the Beyond Budgeting directors, my colleague Robin Fraser and I, even attempted to pull off robust transformation for entire organizations. Robin did transformation work in Italy, as a consultant, while I was taking on mid-sized companies in Germany and Austria.
As the Beyond Budgeting Round Table had entered an era of stagnation, between 2004 and 2007, conflicts within the group of researchers emerged. I left the BBRT and went on to establish the BetaCodex Network, which was set up specifically to solve the riddle of fast & robust transformation for all. At pretty much the same time, Silke 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, Change-as-Flipping, Organizational Hygiene and Peer Recruiting - leading to the publication of a joint book in German called Complexitools, in 2015.
But we were never quite satisfied with the approaches to the change work that either existed or that we had put together ourselves. Even though we took inspiration from all the great minds of organizational development, like John Kotter, William Bridges, Alan Deutschman, Art Kleiner and many others, the actual transformation processes we undertook with our consulting clients took way too long. And the change processes were way too fragile: The work was always overly dependent on consultants such as ourselves, and on relationships between the consultants and the client systems that were prone to malfunction.
For years we had been screening the market for dramatically better ways of pulling off organizational transformation. Thus, hen we grasped the power of Daniel’s OpenSpace-based, invitation-based approach to transformation, all the pieces finally came together. By combining the principles of the BetaCodex with the principles of Very Fast Organizational Transformation, such transformation could become possible anywhere. Better still: As BetaCodex, OpenSpace Beta and OpenSpace are open source social technologies, “available to all” would be more than just a metaphor. It could literally and be undertaken by anyone, by just adhering to the CC-BY-SA license from Creative Commons. We thought that was a pretty cool proposition.
An alternative to the boredom and imposition-based squander of change management
The OpenSpace Beta handbook is a how-to-guide. It serves to explain the approach, its principles and methods, and it works as a practical companion guide to the OpenSpace Beta experience itself, from beginning to end. No more, no less. We included a short introductory chapter in the handbook, about foundations of Beta, and there is a glossary at the back. All else in the book is about how to practically set up the rite of passage that is OpenSpace Beta. We wrote this handbook with organizational developers, change professionals, executives and business owners 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 transformation process. 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 hand-drawn icons 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 in their work. We wanted to bring home the message that OpenSpace Beta is an attractive alternative to the boredom and the imposition-based squander that is change-management-as-we-know-it. To make full-fledged transformation happen in such a simple, elegant way is not trivial. The overall structure of OpenSpace Beta is simple, though: 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 which is also visualized in the timeline:
To make full-fledged organizational transformation happen in such a simple, elegant and fast way is not for the faint-hearted, of course. It contradicts a great many conventional assumptions that most of us hold about change, about organizational development and organizational leadership. One has to set the right boundaries to unleash the necessary level of self-organization during the transformation process. In other words: You have to put all of the 31 indispensable components in place that make up OpenSpace Beta. Only by combining the components of transformation with the structure in time the process offers, self-organization, engagement and mindful organizational development undertaken by all can fully unfold, making very fast transformation possible.
The message of OpenSpace Beta: Coherence matters
I think the best way to articulate the challenge is that coherence matters. Silke and I summarized the approach in an indivisible set of just five principles that we have come to call Very Fast Organizational Transformation, in a BetaCodex Network research paper from early 2019. The principles go like this:
Principled, not ambiguous
Time-boxed, not indefinite
Radically inviting, not imposing
Whole-system, not piecemeal
All at once, not stacked
If you look closely at these principles, you will notice that traditional change management, and even the way Agile or Lean are brought into organizations today flatly ignores or even opposes these principles. That, we believe, is part of why we see so much failed Agile and fake Agile out there today. The five principles of superfast transformation must really be adhered to, in order to keep the energy up and liberate engagement, in order to work the system together. To focus everyone on the outcomes. To involve everyone right up front - not at a later point, when some kind of implementation, execution, kick-off or roll-out would happen!
Daniel Mezick described the way in which time-boxed change approaches transformation as one that uses game mechanics. In essence, game mechanics have little to do with games or gaming, though, but more with fully embracing the social dynamics that are at play in change situations. These dynamics can only be made use of when boundaries are set in time and behavior, so that the necessary amount of collaboration and self-organization can unfold, unleashed by the highest level of social density. 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, right up-front, and get them to working 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.
We always like to emphasize that all business is already gamified. Business is the biggest game that exists. So, generally speaking, we don’t have to gamify work - work should always feel 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 character of work has changed profoundly for most of us, we have not transformed the systems of work, or our organizational models, by and large. We remain stuck with bossism (“looking up”) and command-and-control, instead of looking outwards to clients, cultivating sense-and-respond principles of working.
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 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's already there, but which until today is just sitting there, hindered by steering, bureaucracy and command-and-control organizational models.
The roles of Sponsor and Master of Ceremonies
In OpenSpace Beta, the roles of Sponsor and Master of Ceremonies are certainly the most complex of all. The Sponsor role is taken on by a single person from the transforming organization. That person must be authorized and capable of inviting everyone to join the first OpenSpace Meeting. The Sponsor has to write the invitation her- or himself: In this written document, the Sponsor outlines the urgency, or the rationale of the transformation, and the principles to be adopted. The Sponsor will also take care that the agreements from the opening OpenSpace Meeting will be put into practice. So the Sponsor is really the key figure with whom any OpenSpace Beta process starts.
The Master of Ceremonies serves the Sponsor to fulfill her or his role, and she effectively safeguards the OpenSpace Beta rite of passage. This person must be from outside the organization that is transforming itself. We like to think of the Master of Ceremonies as the guardian of an OpenSpace Beta chapter. This person is something of a process Gandalf. While the Sponsor might be compared to Thorin Oakenshield, because she or he is in charge of the mission at all times, the figure of the guardian is more akin to a confident, knowledgeable and wise companion Gandalf, who will rise to the occasion when the moment requires it. Like no other individual, the Master of Ceremonies understands the dynamics of the rite of passage, thinks ahead calmly, and safeguards the rite of passage. For good reason: Gandalf knows precisely what is at stake, and why the mission must be completed.
A few words about OpenSpace
Every OpenSpace Beta chapter employs the OpenSpace large-group interaction method twice. Looking back at how OpenSpace was formed, or conceived by Harrison Owen, in the early 1980s, it is clear that Harrison intended to apply OpenSpace inside of organizations, for the sake of organizational development. He was part of a significant 1980s and 1990s movement of consultants, that included people like Marvin Weisbord, and our friends Paul Tolchinsky, Bill Pasmore, Ron Purser and Peter Block. They all attempted to “get the whole system into the room”, in order to employ self-organization and emergence for profound systems change.
Once you take a closer look at the history of OpenSpace in particular, however, you notice that it never actually took hold in organizational development: Instead, in the 2000s 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 in which the law of the two feet shall rule! All bar camps and unconferences today are rooted in OpenSpace, to a certain degree. Which is great, in principle. But it also creates a problem: 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 that everybody wants 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.
If you have experienced OpenSpace-based events, you may have never noticed elements of OpenSpace that are actually quite 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 (OS1) and OpenSpace Meeting 2 (OS2) are the raw material for disciplined, and focused Practicing, Flipping, Learning. Without them, it would be impossible to follow up on the agreements achieved during the OpenSpaces. In 2025, we outlined the concepts of OpenSpace DEV, or a form of OpenSpace that’s suitable for organizational development, or super-fast transformation in particular, in a separate BetaCodex Network research paper, here.
So what happens during the 90 days after OpenSpace Meeting 1?
During the 90 days, the Kraken is released, so to speak. Members of all teams and from the entire organization in question are empowered to take action within a pre-defined period of three months, and within the principles of the BetaCodex - to which additional principles such as those of the Agile, Lean or Time-Oriented Work Systems can be added. In effect, this way of proceeding with transformation allows everyone to work on the organization’s system, consistent with the vision outlined by the set of chosen principles.
The second OpenSpace Meeting, OS 2, is a very large retrospective - performed as a by-invitation meeting together with all the willing. OS2 closes the 90-day period of working the system, together. OS 2 takes just a single day, like OS1, and will allow for in-depth retrospective and reflection, and agreement on next steps.
The role of Coaches in OpenSpace Beta
With OS2, the Master of Ceremonies and the so-called OpenSpace Beta Coaches, or external advisors, are gone. This is one of those brilliant ideas we picked up from Daniel Mezick: The work of consultants or external advisors must be time-boxed, too. This little concept solves a huge problem of organizational development, in that it creates another crucial boundary. In conventional change projects, or change management in general, support by outsiders - experts, consultants, coaches - drags on and on and on forever. And the dependencies on outsiders creates a plethora of problems for the change and in the change. Among them, the problem of learned helplessness on the part of the client organization. Or 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!”). So, in OpenSpace Beta, with the 2nd OpenSpace Meeting, all Coaches and the Master of Ceremonies will leave and quit their roles for the client organization, for a period of 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 Quiet Period, an organization may start the OpenSpace Beta ritual all over again, if necessary – with another theme, mission and topic.
Since 2018, Silke Hermann and I have helped a company undertake Beta transformation with OpenSpace Beta every year - without exception. We have undertaken OpenSpace Beta-based transformations with tech companies and service firms, with industrial companies – from consumer goods to high-end manufacturing.
Now the question is: Why aren’t you doing it?
About the OpenSpace Beta book
OpenSpace Beta. A handbook for organizational transformation in just 90 days by Silke Hermann & Niels Pflaeging. BetaCodex Publishing, 3rd edition 2023. Print book: 148 pages, illustrated and fully colored. EUR 15,00. Ebook: EUR 12,00.
Videos on OpenSpace Beta
Watch highlights from the 5 years of OpenSpace Beta event. A list of videos related to OpenSpace Beta and Beta transformation -including keynotes and conceptual introductions - here.
 | A guest post by
|
What memories! What possibilities! I see the seeds of those possibilities in that picture of Silke and Daniel. It’s so great that they have been realized in so many places!