Pattern for Agile Organizations

Read this text to see the idea of sociocracy as a form of organizational design. This is a way for organizations to transcend the traditional approach to organizational change. While the model is primarily applied to software organizations, it can be used by other organizations that want to be sure that information flows to and from the appropriate parties and ensure that experts can participate in the decisions that affect them. The text considers governance, teams, and collaboration internally and externally. The graphics make the complexity of the linkages easy to understand as the author presents consent decision-making, double linking, and governance in iterations.

The Patterns

Peer Development

Ask For Help

A simple protocol for learning, skill sharing, and building connections, with respect for people's agency.

Ask someone, "would you be willing to help me with …?" The person asked accepts or declines with a simple "yes" or "no".

  • if the request is declined, the person asking accepts the answer without negotiation or inquiry
  • if the request is unclear, inquire for more information
  • if you accept a request for help, support your peer in the best way you can


Peer Feedback

Invite any member of your organization to give you some constructive feedback on your performance in a role or in a team, about your general participation and contribution, or about any other area you wish to develop.

Before the invitation, consider who might be able and willing to provide the feedback you seek, and decide on an appropriate duration – 15 or 30 minutes is usually enough.

Schedule the session in advance, so that your peer can prepare for your meeting, and schedule some time for yourself after the session to decide how you will act on the feedback you received.

In the invitation, clarify the topic you want feedback on, and explain that you are looking for both appreciations and actionable improvement suggestions.

During the session itself, consider:

  • taking notes to ensure you can remember the details
  • repeating back, feedback you receive in your own words to check for the accuracy of your understanding
  • asking clarifying question to better understand feedback if the intended meaning is unclear for you

Avoid discussing or judging the feedback you receive and remember to thank your peer for taking the time to give you their feedback.

After the session, review your notes and decide for yourself what you will do with the feedback you received. It's your choice if you want to share your decision with your peer.


Peer Review

Support each other to learn and grow in the roles and teams you serve in.

The role keeper - or team - leads the peer review by setting up the process, and by speaking first in each step.

Peer review process


Ensure you invite people with complementary perspectives to contribute to the review, and a facilitator.

For both appreciations and improvement suggestions, ensure you consider the following aspects:

  • The value the delegatee brought to the organization by accounting for the domain.
  • The role keeper's or team's work processes, and their collaboration with the delegator and with other relevant stakeholders, and – in the case of a team - with each other.
  • How well the delegator takes care of their responsibilities.
  • The design of the domain itself (and potentially the design of other related domains).
  • The role keeper's or team's competencies and skills in relation to the domain.
  • The strategy the role keeper or team follows to account for this domain.

Continuous improvement of people's ability to effectively keep roles or collaborate in teams


Development Plan

A plan for how to develop more effective ways of accounting for a domain, agreed between delegator and delegatee.

The development plan may be created for a person in a role, or for a team (e.g. a department, circle or open domain).

Development may happen in the form of refining the description of the driver and the domain, making amendments to strategy, or new or updated agreements and specific actions to be taken, either within the domain of the delegator, or the domain of the delegatee.

A development plan (and any accompanying recommendations for changes to the descriptions of the domain and the driver) requires consent from both the delegatee and the delegator.

A development plan (and any accompanying recommendations for changes to the descriptions of the domain and the driver)