Design Philosophies for the GECO Project's facilitation app

Productive Group Dynamics

Susan Wheelan's Integrated Model of Group Development (IMGD) proposes the (simplifying it)

• Form
• Storm
• Norm
• Perform

stages any group goes through when working towards a shared vision. Have you ever been in a team that constantly wanted to "kill each other"? It sucks! Unfortunately (or, arguably, luckily), every team has to go through these stages to become productive. I am sorry to disappoint you if you think your team doesn't. You have a storm brewing (and might not know about it).

Every product, feature, and design decision should, first and foremost, help inexperienced teams prepare for and help navigate the stages of group development.

Pareto principle / 80-20 Rule

We want to leverage the Pareto principle to help any team be more successful at establishing and maintaining productive group dynamics. Giving teams 20% of the knowledge and skill of an experienced facilitator can get them 80% of the outcome of having such a person support them.

The joke book

Being a facilitator is a lot like being a stand-up comedian. As the facilitator, you don't have the luxury of saying, "Let me get back to you on that."

• If you are a programmer, engineer, or archeologist and someone presents you with a question you don't know the answer to, you can say, "I don't know the answer, but I'll find out and tell you once I have done so!"
• If you are a facilitator and a conflict is happening in your team, you can't say, "Stop fighting. I need to figure out how to mediate this. Let's fight tomorrow instead once I know how to deal with this."

Our app should:

• Be like a joke book a stand-up might take with them on stage when performing jokes (is it better to perform without a joke book? Sure! But it's better to have a joke book and get laughs than to bomb on stage.)
• Ensure the facilitator is prepared when going into a meeting with their team
• Whenever possible, remove "performance pressure" from the facilitator by "being prepared" or giving clear instructions

Questions you cannot answer are usually far better for you than answers you cannot question

I just like this quote. The pillar it represents is more about asking questions than questioning answers.

We should structure our features, designs, and development efforts as "safe-to-try" experiments that are approved using consent-based decision making. What does that mean in English?

Proposed features or changes should have a:

• clear hypothesis they address
• tightly defined scope to ensure we are building an MVP, allowing us to test the specific hypothesis
• way to measure whether the MVP confirms the hypothesis
• forum to learn from the lessons gathered by deploying the MVP to users.

Once a feature is proposed (answering the points above), the core team discusses it until it is safe to try, and everyone consents to work on it.

• Will building this feature ruin the project? (Safe to try?)
• How does the proposal need to look so I can consent to work on it, even if I wouldn't necessarily do it this way? (Consent is not consensus)

This process involves the following steps for each proposal:

1. Reading the proposal
2. Asking clarifying questions (by the team to the author of the proposal)
3. Providing suggestions (by the team, to be implemented at the author's discretion)
4. Voting on whether it is safe to try.