Mozilla’s Open Leadership Training can work for Open Austin projects

When I joined the Open Austin leadership team, one of my first goals was to identify specific problems in our project management that might impact members’ ability or motivation to contribute. Early on we defined that problem to be that most project ideas are never completed. However, recently we took a good look at what we are as a community and what we want to facilitate. In doing so, we realized that it’s okay for ideas to not be completed; they’re just ideas after all. Rather, it’s a problem when a project that has made commitments or set expectations never gets completed.

We have completed dozens of projects over the years, and there are many more actively worked on today. However, there are all together still more ideas that have been abandoned, shelved for later, or need leadership. We decided that it’s okay for ideas to be this way, in fact it’s great to have pages of unled or abandoned ideas that a newcomer could pick up and run with. However, it becomes a problem when that newcomer doesn’t have the initiative to start on a new project with no help or to continue working on a project that nobody else wants to participate in.

Project management issues

Another problem is when projects that have progressed past just an idea or that have commitments, funding, or external stakeholders are not satisfactorily completed. From some less than rigorous study and experience with this over some years, I’ve identified five causes that have prevented projects from being completed:

• Unmet technical requirements
• Lost client or target group
• Analysis paralysis
• Lost interest or commitment
• Dropped out of the community

Unmet technical requirements

This is the most clear problem that often has an easy to understand solution: you get the right technology, right person, or right information to move forward or pivot. For example, Rails (and thus Ruby) was a popular new language for web development around the time Code for America started up. This led to a lot of new projects in our communities being developed with Rails. But it didn’t last, and now as other languages and tools have usurped its trendiness, Rails projects may struggle a little harder than others as new members are less interested in contributing to them.

Having the right person with technical knowledge and techniques can be just as important as the project’s tools. It can mean the difference between a tech-debted prototype and a well-engineered project that requires less attention over time, which helps for volunteer projects like ours. Having the right person with the insider technical knowledge also falls under this category. For example, a project for a government body will likely move extremely slowly without the technical knowledge of its legal or procurement matters.

Lost client or target group

Many of our completed projects had at least one external stakeholder, including government workers, nonprofits, and community groups. Without dedicated support and communication affordances to maintain that relationship, a project can easily lose steam. Maintaining relationships is hard, but it affects nearly all aspects of a project for better or worse.

A client can provide direction, a target group can provide research, a stakeholder can provide technical resources, and it can be too hard to replace them before volunteers move on to something more fulfilling.

Analysis paralysis

A challenge to all agile teams is keeping track of their own time and project management. A team practicing waterfall might work well by seeking volunteers only for the near term objectives and then different volunteers for later objectives, but that requires strong leadership over a long time. An agile, iterative project requires shorter management terms but also means the team must know how and when to observe, reflect, make, and repeat over and over again.

Overcoming paralysis requires the agency to continue even if they lose the ability to seek clarification from a client or target group. Or if the client provides this but not strong direction, a team may spend too much time observing and reflecting. Then they risk never making anything. Having the discipline to prototype and potentially throw it all away after testing is critical to iterative work with less managerial overhead.

Lost interest or commitment

On a more personal level, it’s just hard to stay engaged in a project that loses its novelty. A new project idea to someone is a great motivator to learn, but depending on what they did or did not learn, that motivation can fizzle out. Time management is also critical here as we are a volunteer organization that is focused on personal projects over business-driven projects. Those who don’t align themselves accordingly may suffer from how they perceive the community and vice-versa. This can happen to regular members, leaders, and external stakeholders, each with their own repercussions to their project and the whole community.

Dropped out of the community

Finally, churn is the greatest enemy to any subscription-based endeavor. When people leave something, it’s extremely difficult to get them back, and sometimes they leave with something of great value to the community. That can be replaced in time usually, but in the meantime the consequences can cascade. If someone just ghosted, that also draws concern on a more personal level. As an intentional community based on personal projects, it can affect folks on a more emotional level that isn’t so replaceable. Maintaining a personable level of engagement is critical to a healthy community that significantly affects the other four issues I’ve described.

Learning from Mozilla

At Open Austin’s core are our values of open source work and open participation. We share a lot of that with Mozilla, who’s also a great example of getting things done themselves and by enabling others in their own efforts.

As a leader in open project leadership, they offer this as a sort of service via their open leadership training series (OLTS). I enrolled with my Mobile-Map-IO project in their third cohort, which included a couple dozen other participants from around the world. One of the first activities we did was align our values for our individual projects with the community’s values, particularly with Mozilla’s internet health report categories.

The training series overall is about learning the best practices for working in the open, specifically people who are starting up or leading a project. It’s a mix of a few things, mostly captured by a sort of multimedia readme.

We reference this readme at nearly every cohort check-in, where we all meet virtually via Vidyo and type on Etherpad, a real-time collaborative notepad, when we have questions or are responding to prompts provided by our lead Abby. Before we meet, she sends two options for the whole cohort to meet, giving us a chance to schedule one or the the other.

In the meantime, she prepares our cohort Etherpad with the meeting outline and spaces for us to respond to questions. This gives us chances to participate verbally as well as textually in the conversation, engaging individuals from what they type directly instead of relying on individuals who choose to speak.

As leaders, it’s important that we learn from and motivate each other. This live document editing is bolstered by more in-depth artifacts developed from these prompts and those listed on the readme.

For example, we crafted vision statements, articulated the problems we want to address, and more so that others in the community can better understand the motivation, expected outcomes, and progress without the leaders being present. My Mobile Map IO artifacts are all available on my project page.

Applying this with Open Austin

The artifacts are also something we can use to check ourselves, as this is generally only what we spend about 20% of our free time on. Keeping tabs on what commitments we can make in our 20% time is something I think we at Open Austin do well by using BASEDEF. Blogging, Applying, Suggesting, Extending, Documenting, Evangelizing, and Fixing are all ways folks can get involved in an idea for civic innovation. What I’m doing now for example is the B, for blogging, to share what I learned and how I could contribute to our process for improving the issues I’ve outlined. These artifacts we created are examples of the BASEDEF spec.

Another artifact we in OLTS used for maintaining a project is the Open Canvas, something similar to what Open Austin has iterated on with the Civic Tech Project Planning Canvas. The canvas can also inform a roadmap, which we started building from day one to guide our direction. In order to deliver (i.e. complete to a degree) a minimally viable experience to a stakeholder, the project team must align on some near- and long-term goals that are defined in a way that stakeholders would care about. Instead of defining technical requirements or jargon-laden statements, an experience-based roadmap should define what a stakeholder would be able to do or experience at each milestone. Defining this way may help with keeping them engaged and acting as good designers, not just good hackers. And this is important, because it’s hard as a stakeholder or user to wait for volunteer―often speculative―labor to yield a desirable experience.

Finally, one last OLTS artifact that I felt was important was understanding what we would find welcoming or helpful when first reading about a project. Community is at the center of leading an open project, and without a welcoming experience to that community, a project therein may fail to catch new members. This makes well-designed and welcoming documentation a very high priority.

A common way of providing this is with a readme, a pleasant way of greeting someone into your project’s home, like the OLTS website. Removing the jargon from our roadmap, readme, and other artifacts is especially important for us because Open Austin is designing for the 100%: everyone in our city. And like any house’s rules defined on their doormat, we could also define a code of conduct and contribution guidelines to entice folks to start making contributions in any BASEDEF way.

Finally, half of the experience of OLTS is having my mentor Minn who knows my name, knows my project, and wants to help me succeed. Even though I may start losing motivation, having someone asking me questions and injecting enthusiasm is hugely helpful to staying on point. Part of his goal is to get me ready for Mozilla’s Global Sprint. Knowing that my project’s going to be part of some big thing way in advance is a great motivator. Open Austin does something similar with ATX Hack for Change, but we don’t really talk it up until the weeks leading up to the event. With a more personal welcoming experience, a constant personal peer presence, and a long-term goal to set, we might see some improvements in membership retention and engagement levels.

Some suggestions

Overall, I have six big takeaways from Mozilla’s OLTS for Open Austin. These are the things I’d like to help lead in our organization:

• Motivation and alignment with shared community values

• Framework for starting a project from an idea

• Regular engagement with the whole community

• Ample community technology and resources

• Mentor who knows you and provides 1-on-1 experience

• High-exposure events to nudge long-term goal setting