This update is dedicated to our recent in-person training for the Technical Committee and additional community leaders.

Reflections on our Leadership Training Workshop

In mid-July 2016, 20 members of the OpenStack community including Technical Committee members current and past, PTLs current and past, other Community members and additional supporting facilitators met for a 2 day training class at ZingTrain in Ann Arbor Michigan. The ZingTrain team, joined by founder Ari Weinzweig, inspirational IT manager Tim Root, and various members of the Zingerman’s servant leaders shared a unique approach to business that matches OpenStack’s quite well.

I’m not usually one to gush about a training workshop. But wow, please allow me to gush. To tell the truth, many of us went to this workshop despite thinking we might have to learn how to make sandwiches. Or talk about feelings instead of solving problems. Or even decide too much at once without enough input. And so on. But we got over our fears and had a great time and excellent food and service from Zingerman’s ZingTrain team. Many thanks to Ann Lofgren and Timo Anderson for facilitating the workshop, and much gratitude and admiration to Colette Alexander for recognizing a match and meeting a need.

What did we learn?

We learned about stewardship and put it in the context of OpenStack. I had to look up a definition for this term, even though I’m a word nerd. Stewardship is an “ethic that embodies the responsible planning and management of resources” and it matches so well with what we need to do as leaders in the OpenStack community. The group decided we needed to continue this sort of work after the training and so the stewardship working group has formed. We met for the first time this week and listed many items on a to-do list that we’ll cull and prioritize as we go.

We learned what servant leadership looks like, when instead of a top-down triangle to represent an organization’s hierarchy, you invert it and have all of your leaders serve their teams. The basic idea is that it is the role of a leader to serve the organization, and you aren’t promoted in order to have others serve you. In the article, A recipe for servant leadership, Ari Weinzweig explains servant leadership with: “To paraphrase John Kennedy’s magnificent 1961 inaugural speech; ‘ask not what your organization can do for you, ask what you can do for your organization.'” In an open source community like ours, this looks like PTLs who review code in order to teach and onboard more contributors instead of writing all the code herself, or generally supporting the needs of team so they can achieve their best.

We learned about consensus, where you first agree to how decisions are made. Consensus can also mean that 18 people who are business partners might not all completely agree on the solution, but are enough convinced by their peers to fully support the decision and make it happen. We are certainly provoked by this concept, considering that we use majority voting today, and TC members will abstain if they can’t agree with a resolution. We want to work on this aspect going forward.

Each of us took away important aspects of consensus-made decisions. At ZingTrain we learned that the original agreement between their partners was to “live with” and not simply “live by” group decisions, even when the decision wasn’t their personal first choice. In this way, the goal with consensus is not to reach a point where a majority opinion ensures people do what the decision indicates, but to ensure that everyone is as comfortable with the decision itself. This aspect felt especially important in the OpenStack context, where people may feel they are putting up with a decision that was made, but haven’t inherently agreed to live with it. We also learned that another component of this decision-making process was that any disagreements must include a counter-proposal.

We learned about visioning. Now, realize that vision training is an entire subset and workshop in itself. We needed to learn first and get introduced to the idea. What is an effective vision? How can we put what we’ve learned into an OpenStack context?

In a vision, you describe the future state you want as if it happened. A vision is:

• Inspiring to all that are involved in implementing it.
• Strategically sound, as in, we have a decent shot at making the vision reality.
• Documented. You must write it down to make it real and make it work.
• Communicated. You have to document it but not expect people only to read it, you have to tell your community about your vision.

What if a vision for OpenStack was as detailed as:

It’s a sunny day in fall 2025 in Vancouver, Canada, yet a lot of technologists are lined up to get their RFID wristbands that open doors to conference sessions at the OpenStack Summit. The autonomous vehicles donated by a large OpenStack deployer are emptying outside, bringing them together to plan for the next release of OpenStack. The past release was a huge success and the 100,000 deployments upgraded smoothly with no downtime to end users.

As one of the founders of Zingerman’s Ari Weinzweig notes in this Inc. magazine article, “To be clear, a vision is not a strategic plan. The vision articulates where we are going; the plan tells us how we’re actually going to get there.” A vision for OpenStack is not a strategic plan, yet without it, planning is difficult. Also, decision-making is difficult, and consensus can’t be reached, due to debates not only on, “Where are we going?” but multiplied by questions on, “How do we get there?” We definitely had wheels turning after thinking about this together, as a group, distraction-free, and face-to-face.

It was a great week. What we want to do next is become a more effective technical committee and leadership group. We want to apply the various aspects of servant leadership by becoming better examples of servant leaders ourselves. We’ve identified gaps in our current leadership implementation, and are working to close them so that we take action based on what we’ve learned. We’ve started the Stewardship Working Group. We are drafting documentation to write down our guiding principles, to write down release goals, and generally keep documenting and teaching. We were all challenged to teach two hours a week and learn at least one hour a week, and I think we all are ready to take on the challenge to lead by example by starting with ourselves. Please let us know how we are doing, give us feedback, and shape our community vision with us.