DevSummit07:Hierarchy on the Fly: Making Collaborative Projects Work Without Predefined Structures

From DevSummit
Jump to: navigation, search

Facilitated by Amanda Hickman, NOSI, and Mark Libkuman, Openflows

Amanda and Mark will share their perspectives and experiences on distributed, collaborative projects, including:

  • Working on volunteer projects spread out over geographic regions
    • Use case: USSF Information and Communication Technology Committee* Collaborations on Open Source projects for the benefit of one entire sector
    • Use case: PEG Space project (PEG is Public, Educational, and Government Television, i.e. community access television) led by MNN (Manhatan Neighborhood Access)
  • Outreach and utilization of non techies in technology dependent projects: how to pull in people for non tech roles in projects that may seem like tech only projects

Bring your nonprofit software collaboration challenges to this discussion and find peer support!

Notes from the Session : Hierarchy on the Fly

Starting Points from the group

No one holding the whole. Don't want an unintentional hierarchy to take over because of time limitations or other external pressures.

Sometimes there is an inherent hierarchy because of the nature of the project or project client relationship.

Task management software/application.

Phone conference calls are not good because of the lack of rich notes or documentation. Language limitations.

Acknowledgment and transparency of existing power structures is necessary.

Remote Decision Making

Process

  • Banished meetings
  • Moving from discussion to task - happens in meetings, notetaker, task juggler and ? shepherd this.
  • If there is no project manager, how deal with accountability and reprioritization needs...who holds the whole? - People have to be good about communication and have the resources they need.
  • How negotiate what's a group decision vs. a decision an individual can make?
  • Roles when there is no project manager: Gatekeeper, notetaker, task juggler,
  • Agenda setting
  • Identify situations where there are differences of power and OK/good differences and use that authority. Car analogy. Sometimes people misuse that particular authority in realms that aren't others. One misuse is not being willing to teach in your authority or being willing to learn in the authorities of others. Have buddy/mentoring systems.
  • How deal with situations and conflicts when they have already arisen without rules/expectations? Be explicit about the issues. have folks call out for themselves what the issues are/is and possible mechanisms for addressing/solving; agree on rules about the mechanisms.
  • Hold "Honesty groups/meetings."
  • Using a meeting parking lot.


Tools

  • IRC
  • SILC
  • Second Life
  • Goby
  • Wikis
  • BaseCamp
  • Active Collab
  • Synchroedit
  • Quality Phone System + Gobby
  • Too many tools sometimes because constantly trying to find/build the "right" tool.
  • Set of working agreements and enforcement or enforcement mechanisms

Resources

  • Game theory article in NYT. Studies about openness in the presence of exploiters.
  • Pegspace.com
  • deb.riseup.net

General Themes

  • There are no technical solutions to social problems.
  • Hierarchy is not always an inherently bad thing. Formal and STATIC hierarchy that is not explicit, not transparent and not healthy (using power in appropriate positive ways) is the problem.
  • Create a culture of ownership.
  • "TRUST" most important factor
  • GTD - getting things done: Best way to get things done is to be an environment where things are getting done.
  • Good and up-to-date documentation absolutely vital.

Conversation Keywords & Key Concepts

  • Transparency
  • Technical hierarchy not social hierarchy
  • Trust
  • Communication
  • Documentation
  • Acknowledgment of Power & power dynamics
  • In role of teacher, when the authority in a particular skill or situation, and learner when not.