ProcessesSimpleisSustainable

Processes: Simple is Sustainable

The inverse of simplification is complexity, and we don’t like complexity around these parts. Complex processes are ugly beasts, and their effect is to merely build bureaucracy. You need to avoid this 11-letter word at all costs. Bureaucracy is the enemy in this chapter: it is the vitriol that breaks down the opportunity, potential, and belief that we celebrated so strongly earlier in this book. Great processes blend into the background, functioning as required and as expected. Great processes let people get on with doing real, human, interesting things. Bad processes serve as nothing more than a dartboard for your contributors to throw their frustration at.

Processes are everywhere in communities, determining how:

  • New people join.
  • People submit contributions.
  • People collaborate together.
  • People deal with conflict, and so on.

It is no coincidence that the word “people” is in each of those examples: people are the foundation of community, and for us to ensure these people can work well together, we need to focus on people at the foundation of our processes.

When we (a) know which processes we need to create, and (b) make them delightfully simple, our community members can get on with enjoying the community that they signed up for.

Keeping Things in Perspective

Here is the crux of how we frame this perspective: processes are useful when they become a means to an end.

I raise this distinction for an important reason: building processes is a core activity in governing a group of people. Unfortunately, all too often the act of governing can overtake the goals of the governance. Always bear this in mind when building your processes, and always ensure you are not building processes for the sake of building processes. Not all problems can be solved with documentation and rules.

Building Great Processes

Processes are everywhere. There is a process to withdraw money from your bank account. There is a process to get the oil changed in your car. And of course, any interaction with the government...well, I am sure you can end that sentence for yourself. Unfortunately, many people who interact with processes experience little reward for a lot of frustration.

Processes are like television news: we only ever hear the negative stories.

When we take a laissez-faire approach to processes, we put confidence in our community at risk. Processes are the conceptual buttons that your community members push to make things happen, and when those buttons don’t work as expected, people get bored and frustrated and move on. On the other hand, if we craft smooth, efficient, and effective processes, our community feels nimble, responsive, and a pleasure to be part of.

Breaking Up the Puzzle

Building a quality process is like taking a road trip. You know where you want to go. You want to take the shortest route, and you want to avoid as many bottlenecks and problems as possible. When you plan your perfect route, you are careful to take the fewest number of roads, take advantage of available freeways/motorways, avoid rush hour, regularly check on current road conditions, and ensure that an In-N-Out Burger restaurant is on the route at regular points (that’s just my personal criterion...).

You should take the same approach to efficiency with your processes. How can you achieve what you want as quickly and efficiently as possible? How can you communicate the journey as easily as possible to new members? How can you ensure your processes are always amenable to current conditions?

Great processes are beautiful creatures, but they need care and feeding to thrive. Our goal in this chapter is to identify these needs and produce processes that exhibit the following criteria:

  • The goal of the process is achieved as quickly as possible
    • The quicker a process ends, the quicker your community can get on with more interesting

things.

  • The fewest possible steps can achieve the goal
    • Redundant steps merely make the process feel long and drawn out; let’s avoid that.
  • Each step is simple, well documented, and clearly communicated
    • Each step should be absolutely necessary, and performing it should be simple. A quick technical example: if you need someone to type something in, don’t demand case-sensitivity; it only complicates that step.
  • The process is as friction-free as possible
    • We want to avoid confusion and annoyance, not only with each step in the process, butin the process as a whole.
  • Quality is maintained at every step
    • We need to identify and maintain the different types of quality involved in a process: its accuracy at achieving the outcome, how efficient it is, how well documented it is, how current it is, and how open to change and improvement it is.

Building A Process

When you need to build a process for something (such as how members join your community), note down the following criteria:

  • Goal
    • What is the goal of the process? What does it seek to achieve? What is the outcome when the process has been followed?
  • Target participants
    • Who is the process designed for? Is it intended for a particular kind of contributor, such as a developer, documentation writer, translator, or advocate?
  • Requirements
    • What tools, knowledge, and experience must the contributor have in order to follow through with the process? If she does not possess these requirements, how can she obtain them easily? Are these requirements a barrier to entry (such as costing money or limited availability)?
  • Steps involved
    • What are the chronological steps involved in achieving the goal? What could go wrong? Is it possible for people to accidentally ruin a step? How is feedback provided about each step? Who provides the feedback?
  • Verification
    • Who makes the decision about the successful completion of the process? Also, how is it communicated that the contributor has achieved the process?

Avoiding bureaucracy

The most important ingredient when building processes is an understanding of people and their expectations. And this understanding requires you to solicit feedback, along with a culture devoted to always improving and refining your processes. When we understand and react to participants’ expectations, processes behave as they expect. Part of the reason why feedback is so important is that it prevents bureaucracy: rules that are maintained because “they are the rules.”

Spread the message in your community that tomorrow may always bring a better way to carry out a current process. Processes provide an excellent opportunity to simplify tasks, tend to needs, and help your community focus on innovating more easily.

Encourage and enthuse your community to question your processes. This feedback will keep your processes on their toes and protected from the dreaded B-word.

Transparency

All volunteer communities thrive on a sense of openness, because they are associative. These communities are built by people who choose to live their lives there. Everyone who participates in a volunteer community does so because they enjoy it: it is not a job or a requirement. As such, to keep them involved, there needs to be a sense that their input is valuable, and this absolutely applies to their input on how well community processes are working. Ask yourself this question: would you rather live in a community where you can have an impact on the governing rules, or a community in which other people decide?

These risks with transparency can happen to any volunteer community. The solution to this is simple: involve your community at every step of your community growth. Involve them in the strategy, the processes, the governance, the execution of these decisions, and more. Have public communications channels and public meetings, and instead of questioning whether something should be public, question whether it should be private. When we work together, the world feels a very open place.

Accessing Needs

Effective environments are built on effective processes. As a community leader, your goal is to build an environment that offers rich opportunities and is simple to engage with. So you need to figure out which processes you need in your community and apply your recipe and best- practice concepts from earlier in the chapter.

Processes can be broadly divided into three primary categories:

  • Environment and strategy
    • This is a continuation of the strategy that we built earlier: the general concepts that apply to everyone in your community, such as milestones, direction, processes that define how people collaborate, and external feedback.
  • Infrastructure
    • The technical nuts and bolts and tools of your community: the day-to-day facilities that your community members require to get things done.
  • Governance
    • The governing bodies, legislation, rules of engagement, and other more political components required to organize and govern your community.

Each of these three areas is of significant importance in building a strong community.

The Gates of Your Community

Attracting new contributors is an essential part of any community. Earlier we used this item as an example in fleshing out a description of our process. I want to now explore this important item in more detail.

In attracting contributors, our goal is not merely getting the word out; it is about getting the word out to the right people and ensuring that they can join us in achieving our goals.

In this work we have two primary outcomes that we want to achieve:

  • To ensure that the on-ramp from consumer of buzz to full-fledged community member is as smooth as possible.
  • To attract community members who will demonstrate commitment and a willingness to work toward the goals of the community.

The first point may seem obvious, but the second is more subtle. What we want to avoid are drive-by contributors. These are people who join a community for a few weeks, you help them get up and running, and they then get bored and move on.

Drive-by contributors are expensive, not necessarily financially, but in terms of time. Contributors often require a certain level of (wo)manpower. The community responds to their questions and provides the help, guidance, training, and mentorship needed to get them on their feet. If these contributors receive this assistance and fail to deliver anything of value, they become expensive propositions.

Every community is strained by push and pull forces that will affect your ability to retain volunteers. This will apply equally in your community. For the SPCA, euthanasia is clearly a blocker for many to get involved. What is your equivalent blocker? This could be difficult personalities, suboptimal working conditions, hugely complex processes and technical procedures, or anything else.

You should identify these blockers and ensure you have resources to help people over the hump. Importantly, you should not downplay or cover up the difficulties in your community, but until you can fix the problems (which you should seek to do as a matter of priority), it is entirely reasonable to make those difficulties as pleasant to navigate as possible.

Assessing Contributors

Many collaborative projects embody some kind of access control. In a typical open source project, those who can contribute code are restricted, and developers are assigned a username and password to contribute code to the repository. The reason is simple: you don’t want just anyone changing the project. The integrity of the code base is essential. You always want your code to run, be as error-free as possible, and maintain consistent coding guidelines. If access were entirely open, those with malicious intentions or error-prone (in)abilities could introduce bugs, defects, and security flaws to your project. Having a vetting process is important to ensure that your developers can be trusted and will demonstrate this level of quality.

As we briefly discussed earlier in this chapter, it is important for us to figure out how new potential developers can gain access to the project. If I want to contribute to an open source project and am unknown, how do I prove my abilities?

The first task is assessing what your expectations of quality are. For many open source projects, they are relatively simple:

  • A reasonable knowledge of programming; the contributor should not be making the obvious mistakes that new developers make.
  • A familiarity with the code base and coding conventions.
  • A regularity of contribution.

Although the implementation of these expectations involves infrastructure technology (bug trackers, source control systems, etc.), which we defer discussion of until later in this book, we can take a high-level view of how some of these processes work.

Managing Feedback

Gathering feedback from the outside world is an often-overlooked but important facet of a strong and healthy community. Feedback is important for providing you with others’ perspectives, and these perspectives can help identify opportunities, problems, and areas that need renewed focus. It is this feedback that tells you what people outside your community think of your goals, ambitions, and progress. As such, feedback is a positive double-edged sword: not only does it provide pleasant confirmation of things we’re doing right, but it also reveals and focuses our minds on areas to improve. Finally, a good process for handling feedback can improve all your other processes.

Gathering Feedback

Feedback can be collected in many ways. The simplest and often most effective way is to set up an email address that forwards email to a number of core community members. A simplification of this approach is to set up an account with a free email service and give each of your core members access to the account. This approach is excellent for gathering general thoughts, concerns, and opinions about the community that often reflect on processes.

Another alternative is to set up a public mailing list that people can submit feedback to. This solution is not the most suitable for single-shot chunks of feedback from someone. Mailing lists are designed for discussion, so you should really use mailing lists only if you want people to submit feedback and have a discussion afterward. Another downside of mailing lists is that they require people to sign up, and these members will also receive all email to the list. Someone who just wants to give you a quick chunk of feedback likely won’t want to see what everyone else is submitting to the list.

Another possibility is to use a blog. You could post entries to the blog to request feedback and allow readers to provide their feedback in the comments. Remember that all feedback here will be public. You may not want to have everyone and their dog see this feedback (although it is an impressive message of transparency if you do). What’s more, remember that search engines will index this potentially negative feedback, showing it to everyone who searches on your project name, even if you’ve since addressed the problems.

The most productive approaches I’ve used for gathering feedback have been surveys and one-on-one discussions.

One final note about feedback is related to expectations. You should prepare yourself to receive more criticism than praise. This is simply the nature of community and human interaction: we often feel compelled to write an email to criticize, but we rarely get an urge to send email to praise. As such, if you receive what appears to be a large amount of criticism, it may not be reflective of your community. It is likely that there are a lot of silent yet happy members out there.

Getting Buy-In for Your Processes

Document Them

The first step in making a process work for your community is to ensure it is documented. The goal here is efficiency. Sure, anyone can write a detailed list of steps outlining how a process works, but who wants to read paragraphs and paragraphs of text? The documentation behind a process should be as close as possible to a cooking recipe: do this...do that...get this result. The emphasis here is on quick, clear, straight-to-the-point directions.

Processes are fundamentally a collection of steps with an outcome.

To get you started, let’s get introspective for a while and document your own steps for writing a process:

  1. First, write down the end goal of your process. What does it achieve?
  2. Now, in numerical and chronological order, write down each step in your process, using a single word to describe each step.
  3. Finally, for each word, write a single sentence that clearly explains what is involved in the step.

When following through with this approach, always read and reread each step, and assess how easy it is to understand. Is it written concisely? Does it use too much jargon? Would it be suitable as an elevator pitch?

Make Them Easy to Find

Processes don’t have any value when no one knows that they exist. In addition to ensuring that your processes are clearly written, you should work hard to ensure that they are discoverable. Our goal here is to ensure that community members can find our documented processes easily.

This is a two-step approach:

  1. You need to put your documentation somewhere online that people can refer to.
  2. You need to inform your community about additions and changes to the documentation when they happen.

Using Your Processes

With the process documented and announced, the final step is to encourage your community to make use of it. Documentation and announcements are no guarantee your community will make use of a process. In my experience, every process needs a certain amount of manual pushing and poking to become the norm.

Communities generally follow by example: members look toward other people to engage with processes before they do it themselves. You need to put a few examples of successful use of each process in place as a head start to get the community to accept the processes.

A useful approach is to pick four or five key community members and ensure that they are fully behind the process that you have announced. You should regularly check in with these members to ensure that they are making use of the process, and when they are not, you should check why and remind them where needed. You should also encourage these key members to spread their best practices throughout the community.

You should also identify incidents that act as opportunities to reaffirm the purpose of the process. This could be handled in two ways. On one hand, you should find success stories: examples that used the process with very positive results. These examples are always fantastic to show off. On the other hand, when someone doesn’t follow the process and things go wrong, you can use it as a chance to remind your community about the purpose of the process. Do tread this line with caution: you should absolutely not show up your community members in front of others, and you should try not to climb up on your high horse and send out an “I told you so!” message.

Process Reassessment

Processes are living, breathing organisms. They are typically based around current conditions: the current level of contribution, demand, expectations, and goals. They are the clear plastic film that wraps around the assets and members of your community. As the assets and members adjust, so should the processes.

Process reassessment has become a staple part of each Ubuntu release. The Ubuntu community has a huge range of processes, initiatives, governance structures, and more. Each of these facilities was developed to serve a specific purpose, but as the community has grown and changed, these purposes and processes have needed to change, too.

Building Regularity

With your community, you should schedule regular process reassessments. You should schedule a time in which your community can come together to determine how to improve on these underlying structures and processes.

However you choose to organize this reassessment, you should ensure the following:

  • The events should be accessible to your community members. They should preferably incur as little cost as possible, and be within reasonable reach. Organizing a reassessment in Jamaica when your community is based in Northern England is not practical.
  • The events should be open to all of your community members, and you should explicitly state this when promoting them. You should clearly communicate that everyone is welcome to join in and provide feedback about how to improve how the community runs.
  • Ensure a sensible level of representation. Feedback sessions with 2 or 200 people are not valuable. Sessions with 10–30 people offer real opportunity to achieve some conclusions.
  • Ensure that you begin organizing these sessions with plenty of notice, particularly for physical meetings.

When advertising these sessions, you should make them as attractive and practical as possible for your members. Don’t describe it as a “governance and process review” but instead as “how to improve our community.” Make sure that your announcement welcomes everyone, and ensure it underlines how everyone can have an impact.

Pendulum/ProcessesSimpleisSustainable (last edited 2010-09-05 20:33:58 by ip98-182-50-39)