MetaCurrency Status & Future

Over the last week, it has been my privilege to have been a part many fine conversations around the question of project management and team building (Katin Imes, Zack Moser, Sara Garrett, and Jay Standish in particular). For the sake of background, these conversations have been largely in service of The MetaCurrency Project. Basically, I have been trying to figure out how to catalyze some dynamism in that domain, as my experience has been of late that The MetaCurrency Project has lost a lot of its early momentum. There were of course way too many things to fully report on, but here are a few highlights from these conversations.

1) Group endeavors must be open systems. They need a constant input of resources to maintain their cohesion. These resources could be monetary, and/or they could be resources of participation, ideas, feedback etc. Projects that are overly insular do not tend to thrive, especially in the new economy. With that said, it is important to have a clearly defined membrane, but a membrane allows resources to move through. The last thing you want is a virtually impenetrable wall (which to be fair was largely accidental in our case).

2) Short redesign cycles trump long term planning. Rather than figure out everything that needs to be done over the next five years, open source projects tend to work better when they are comprised of short term goals that can be realistically achieved. Having a short time horizon on goals allows for constant adjustment to feedback received from the environment. Basically, you want to learn from lots of little experiments rather than throw all your marbles into the ONE master plan. Think survival of the fittingest. This also allows for much greater participation and openness.

3) A group operating on a short term basis in service of a small and achievable goal will be more likely to experiment with innovative social architectures around decision making, task management, etc. Since no one is committing themselves for the LONG haul, there is less to lose if mistakes get made. Social architectures don't have to be perfect out of the gate. Constant redesign and feedback are the key.

4) It is utterly PARAMOUNT to have clearly defined rules and roles for these short term teams to function effectively (thanks Katin for that insight). By rules I mean agreements on how to operate as a group. Without these agreements there is no way of knowing how to coordinate and cohere as a group. By roles I mean roles that the individuals in the group must self-define in service to the declared intention of the project. Roles are critical because they allow for constructive criticism. Without roles, it is very hard to know how to assess the quality of a fellow team member's contribution or indeed how to serve them being at their highest potential. Since roles are defined in service to a shared intention, individuals are more likely to be able to receive feedback in a positive way.

There will be lots more to say soon, but I am trying to keep blog posts short these days. I would love to hear feedback. Thanks!