Last week I was privileged to attend the ZingTrain leadership training class sponsored by the OpenStack Foundation. There were two days of formal training and a third unstructured day for the group to discuss how the lessons apply in the OpenStack community.


ZingTrain is one of the many businesses in the Zingermans Community of Businesses. The lessons Zingermans has learned apply to our OpenStack community, and the processes they’ve developed can be used to help us be effective in fulfilling our mission.

Belief Action Cycle
There are two big lessons from the training that stuck out to me. First is the “Belief Action Cycle”. The second is the Zingermans “Bottom Line Change” process. The Believe Action Cycle (BAC) is a relatively simple principle that states your beliefs about others influence your actions towards them, which in turn affects their beliefs about you and the work they are doing, which naturally affects their actions, which flows back into your beliefs.

This is illustrated like this:


This cycle can be applied to understand both one on one relationships and interactions between larger groups. For example, if my belief about a particular contributor is that their work is sub-par and a distraction from “more important” work, that will influence my actions toward this person. My actions, especially as a community leader, will then cause that person to be defensive about their work and even second-guess their own participation. Of course, if someone does not feel their work is valued in the community, they will likely withdraw, making their upstream work less connected to what’s going on. Unfortunately, this will feed into my own perception of the work being sub-par or a distraction, and the cycle repeats.

However, if I believe that new contributors are the lifeblood of any healthy community, that will cause me to support new contributors and support their work with careful code reviews, polite words, and specific invitations to participate in the larger community. My actions will cause the new contributor to have a better attitude about their own work and encourage them to stay involved through the initial learning hurdles as they learn the project and community. Their actions will be positive, and that in turn feeds into my own beliefs about the importance of new contributors. And the cycle repeats.

This cycle is even more important when considering one’s role as a community leader. Leaders’ beliefs and actions have an outsized impact on the rest of the community. Leaders set the tone for every community interaction, and this is why, as leaders, we must be even more careful about understanding our own beliefs and biases before we act. Our actions become a pattern for the entire community.

The Belief Action Cycle is nothing revolutionary, but it does help understand interactions in our daily life. As I remember both positive and negative actions in our OpenStack community, I can see how the BAC has played out, both positively and negatively.

We all want to encourage positive interactions and decrease negative ones, but how do we break the cycle if the relationship is stuck in a negative feedback loop? The BAC can be broken between our own beliefs and our own actions. We must examine our beliefs and understand how they impact our actions (and also remember that as community leaders our actions have outsized influence on others).

For example, I don’t like adding new dependencies to Swift, nor do I like large patches for cosmetic changes. But when these sorts of changes are proposed, I need to understand my own beliefs and identify any biases I have against the person who is proposing the change. It’s at this point where I can step back and temper my response to ensure it’s not feeding into a negative cycle. By examining myself (ie my belief), I can understand if my response (ie my action) is based on the actual thing being proposed or larger frustration about things outside of the proposer’s control. This is when the cycle is broken (and sometimes it’s really hard).

The Belief Action Cycle plays a big part in the second big thing I learned at the training. Zingermans Bottom Line Change (BLC) process is a system in which both large and small changes are rolled out within the Zingermans Community of Businesses. Succinctly summarized it has five basic steps:

  1. Why? What is the clear and compelling purpose for change?
  2. What? Create a vision for the future and get leadership agreement on it.
  3. Who? Figure out the communication plan for when the change is implemented.
  4. How? Officially present the vision and collectively create an action plan.
  5. Do! Implement the change.

Like the BAC, this process isn’t anything that’s revolutionary. Zingermans success with the process is based on two factors: (1) consistently going through the process in the right order and (2) a shared understanding of how to peacefully resolve differences. It’s the second part that is key, I think, and something that’s very hard to do as technologists.

Disagree and Commit
In OpenStack, we each have a strong sense of “right”, a sense that there is a good way to do things and a bad way to do things. We’re surrounded by binary decisions and logical processes all day long. When something new or different is proposed (from code changes to community processes), we tend to view it with a binary lens: it’s either good or bad, right or wrong. This binary bias then influences how we respond to the proposal. If it’s a proposed new process to improve some element of the community, then any opposition is seen as not wanting the community to succeed. If the proposal is coupled with explicit or implied threats for non-compliance, then it’s seen as dictatorial and taking away personal autonomy. In both cases, the biases can easily feed into a negative cycle. It’s the Belief Action Cycle.

Within Zingermans, there’s a shared understanding that conflicts are resolved by consensus. Even if one party isn’t completely supportive of a proposed change but generally likes it, then they commit to putting aside differences of opinion supporting the change. The change proposer’s job, then, is to ensure that all parties affected by the change see enough positive to support it.

This principle reminds me very much of a passage from Jeff Bezos’s recent letter to shareholders ( “Disagree and commit” is a way to express disagreement (and not simply exhaustion!) yet commit to supporting a decision before all the details can be known. Both Zingerman’s process and Besos’s principle rely on a high degree of mutual trust within a team.

Build a Vision
How does the change proposer convince people to support the idea? That’s where the vision comes in. The vision is simply the desired outcome at a future date with measurable results. When proposing a change, the vision becomes the shared understanding of both why we all want the change and how we know we’ve accomplished it. Writing a well-crafted vision takes practice, but it’s not difficult to do. Importantly, it must be big enough to be inspiring but also be grounded in reality. I’m happy to see that the OpenStack Technical Committee has written and proposed a vision and is actively soliciting feedback.

Once the vision is written and the change has been agreed to, then the BLC process says that the proposer needs to get feedback to understand the best communications plan with the affected parties. In OpenStack this is slightly difficult because often times the affected parties are in fact the proposers of the change. However, our changes often have wide-reaching impact across our community and to our users, so it’s important to not skip this step.

The Zingerman trainers confessed that the Bottom Line Change process is not fast and sometimes it can be frustratingly slow. In an industry where the cutting edge is rapidly moving, one would think this change process is not a good fit for OpenStack. Perhaps. But the important lessons that must be learned in our OpenStack community are how to communicate and how to resolve our differences of opinion. Zingermans experience with their BLC process can teach our community these valuable lessons.

I’m thankful to both the OpenStack Foundation and SwiftStack for sending me to this training last week. The lessons for our community are invaluable and applicable in my daily life.

About Author

John Dickinson

John Dickinson

John joined SwiftStack as Director of Technology coming from Rackspace where he worked on Rackspace Cloud Files and OpenStack Swift, the large-scale distributed object storage system which SwiftStack is built on. As the Project Technical Lead (PTL) for OpenStack Swift, John is also leading much of its community development efforts.