Weekend Projects: An Introduction

An important part of what I hope to do with this blog is coordinate the creation of more Weekend Project teams. A Weekend Project has a few functions.

• they have the potential of producing either a workable product, or a tangential technological development which might yield some value
  
• they provide useful knowledge and experience in creating and maintaining cross functional product design/development and software implementation teams, which again, provide commercially valuable insights
• they are excellent opportunities to get to know and work with people in an informal setting which might or might not result in a serious project. Over the course of working on a weekend project, even one that does not succeed, participants gain a good sense of eachothers individual skills.
• they are fun! Fun projects are often good for quickly and inexpensively attracting groups of test users, developers, project leads, etc. boring projects are an exercise in futility
  

In order to facilitate the efficient operation of such a team, it is essential to consider first and foremost how the value created by the team can be captured. If the value cannot be captured, then everyone involved is just wasting their time. It is also important to remember that the value created does not necessarily have to be monetary. Someone gaining the experience of running a development team can be a form of value capture, as can the process of creating thought experiments, product design concepts and documentation, as well as tangential technological developments. Of course, the interpersonal and team connections made also have significant value. These are some of the weekend project axioms that I have come to believe in:

1. Document Early and Often. People working on weekend projects must look to document and share their thoughts and insights in a cooperative and constructive environment before they try to implement or test the ideas in software. Ideas are amazing in their flexibility, and tendency to multiply when given the proper conditions. Not only can more invention be fostered by focusing on documentation, but more of the insights can be captured and preserved as a part of the process. Our memories are all terrible, we should not depend on them nearly as much as we do.
2. Rapid Development. Weekend projects are by their very nature rapid development projects. The team is comprised of a group of passionate volunteers looking to get something valuable out of the project or experience. This individual objective can only be satisfied if the entire group works together in pursuit of their common selfish interests. If these types of projects lose even a little bit of momentum, they will crash and burn almost overnight. Therefore it is important to keep the pace of progress high, and keep people's individual ambitions in mind when planning out sprints.
   
3. Create Functional Self-Organizing Teams. Self organizing teams are not hard to find or form. The real challenge is preventing them from becoming social clubs rather than development teams. To keep this from happening everyone on the team must feel as though they have two things (1) a vested interest in the project's success and (2) the ability to make a unique contribution to the team. Simply put, people need to need eachother to work together efficiently as teammates. If this cycle fails, the team will fall apart.
4. Stress Individual Contributions and Leadership. Volunteer weekend project groups are "awesome" because everyone involved can exercise a passionate interest in something. It is typically very easy to find additional members to work on these types of teams once a project is underway (relative to hiring a full time employee) which means that there is rarely as much risk in putting someone in a leadership position as there can be in more traditional settings (so long as axiom 1 is followed). However, noone can feel as though they are being unnecisarrily restrained by a project that they are working on voluntarily, or they will quickly work on it no longer.
   
5. Build a Culture. Tiny teams often have big culture. Artifacts and processes are important, and will live and die at the drop of a hat within a tiny ecosystem. The culture at the ground level on volunteer projects is the glue that keeps everything stuck together when people's individual interests wane (no one is 100% for 100% of the time). This type of sticky stuff is absolutely essential to success.
6. One Leader per Project, One Project per Leader. In the end someone always has to 'own it.' You can never help the fact that there is always a single individual person who has more invested in a project's success than anyone else does. These people should lead whenever possible. It is also critical to ensure that the leaders do not get burned out through overcommitting to too many projects. Too many cooks may spoil the soup, but conversely too many soups may spoil the cook.
7. Be Critical of Others. These projects are first and foremost opportunities to learn and capture individual value. This purpose is not served well if everyone bites their tongues in order to save each others feelings. If you want to learn from your team, you have to communicate with them. Barriers to criticism should be torn down as early on in the project as possible, or they will quickly become impenetrable.
8. Know when to break the rules, and do so with confidence. No human endeavor has ever been so well understood that it could not be improved upon. These axioms are no exception. Knowing when to walk away from the plan can be as important as knowing when to do it by the book. The only thing worse than not recognizing when you should break the rules is realizing that you should and choosing not to.