guide
  • Introduction
  • Guiding Principles
    • Mission Statement
    • Conflict Resolution Process
  • Operating Model
    • Working Together
    • Holacracy
      • Meetings
      • Specific Roles
      • Terms and Definitions
      • Finer Points
      • Holacracy-Asana Key
    • Getting Things Done
      • Daily, Weekly, Monthly, and Annual Reviews
      • GTD-Asana Key
    • Transparency
    • Language
    • Budgeting
    • By Department
      • Engineering Operations
  • General Guidelines
  • Employment Policies
    • Equal Opportunity Employment
    • At-Will Employment
    • Code of Conduct in the Community
    • Complaint Policy
    • Drug and Alcohol Policy
    • Vacation, Holiday, and Paid Time Off (PTO) Policy
    • Supplemental Policies for Remote Employees and Contractors
    • Supplemental Policy for Bonus, Commissions, and other Performance-based Payments
    • Supplemental Policies for Hourly International Contractors or Workers
    • Supplemental Policies for Hourly International Contractors or Workers
    • Disputes and Arbitration
  • Benefits and Perks
    • Health Care
    • Vacation, Holiday and Paid Time Off (PTO) Policy
    • Holiday List
  • Hiring Documents
    • Acknowledgement of Receipt
    • Partner Proprietary Information and Inventions Agreement
  • Engineering Wiki
    • Code Snippets
      • Front End Code Snippets
    • Setup
      • 1: Overview of development using Audienti
      • 2: How to setup your dev environment on Docker
      • 2a: Setting up on our cloud your dev server
      • 3: Connect to Production using the VPN
      • 4: Import data into your development environment
    • Deployment
      • Docker based deployment of back end (manual)
    • Culture
      • How our development team works
      • Code Best Practices
    • Tips
      • Setting up a new development machine
      • Importing data to Development environment
      • GIT workflow and work tracking
      • Using Slack
      • Using Rubocop
      • Our Code Standards
      • General suggested best practices
      • Tracking your time
      • Naming Iterations
    • Migrations
      • Postgres
      • ElasticSearch
      • Redis
    • Database and System Maintenance
      • Redis Howtos
      • Elasticsearch HowTos
      • Postgres HowTos
      • Administration recipes
      • App maintenance crash course notes
    • Front End
      • 2016 Plan
      • Deploy
      • Assets
      • SearchLogic
      • How to create UI components
      • OMA Standard Tables
    • Monitoring and Alerting
      • Monitoring Systems
      • Monitoring individual controller actions
      • Get notified when a metric reaches a certain threshold
      • Instrumenting your models using Oma Stats
      • Configuring Graphite Charts
      • Tracking your results with StatsD
      • Logging Fields
      • Updating Kibana Filtering
    • Testing
      • Coverage
      • Elasticsearch mapping config synchronization
      • Testing Gotchas
      • Rspec Preloader
      • Test Best Practices
    • Models
      • Backlinks
    • Queueing and Worker System
      • Queueing and Job Overview
    • Processors
      • Rebuilding Spot Instances
      • Deploying processors
      • Running processors in development
      • Reverting to the previous build on a failed deployment
    • Processors / Opportunity Pipeline
      • Opportunity Pipeline
      • Diagram
    • Processors / Enrichment Pipeline
      • Diagram
      • Clustering
    • Processors / Backlink Pipeline
      • Diagram
      • Backlink Pipeline external APIs
      • Backlink pipeline logic
    • Processors / Automation Pipeline
      • Diagram
      • Automation Pipeline Overview
      • Agents
      • Running in development
    • Messaging and Social Accounts
      • Overview
    • API
      • Audienti API
    • Algorithms
    • Troubleshooting
      • Elasticsearch
    • Big Data Pipeline Stuff
      • Spark
    • Our Product
      • Feature synopsis of our product
    • Research
      • Backend framework comparison
      • Internet marketing Saas companies
    • Code snippets
      • Commonly Used
      • Not Used
    • Miscellaneous
      • Proxies and Bax
    • Legacy & Deprecated
      • Search criteria component
      • Classes list
      • Target Timeline
      • Twitter processor
      • Asset compilation
      • Test related information
      • Interface to EMR Hadoop jobs
      • Mongo Dex Indexes to be Built
      • Mongodb errors
      • Opportunity pipeline scoring
      • Graph Page
      • Lead scoring
      • Insights
      • Shard keys
      • Setting up OMA on local
      • Clone project to local machine
      • Getting around our servers in AWS
  • Acknowledgements
  • Documents That Receiving Your First Payment Triggers Acknowledgement and Acceptanace
Powered by GitBook
On this page
  • Accountability
  • Circle
  • Domain
  • Partner
  • Policy
  • Purpose
  • Role
  • Tension
  1. Operating Model
  2. Holacracy

Terms and Definitions

PreviousSpecific RolesNextFiner Points

Last updated 7 years ago

Terms:

Accountability

The Holacracy operating system distributes power throughout an organization, by defining roles with the accountability and authority to make various decisions and take action – authority no one else can “trump”.

Each circle/role has a series of accountabilities (they cannot be created without at least one) that all start with a "ing" ending verb. This signifies the ongoing work that this role is responsible for.

eg. Updating website with latest news or Interviewing students.

Circle

A Circle is a role that's grown larger and needs to break itself down into sub-Roles, so multiple people can work together to express the Circle’s overall Purpose and Accountabilities. So circles act as roles within their parent circles.

eg. Admissios could be a circle at OMALAB, with different roles inside of it, but in its parent circle, the GCC, Admissions acts as a role with accountabilities, domain, and purpose. And is represented by its Lead Link.

Domain

Domain basically says that an area cannot be edited or changed by any role/circle that doesn't have domain unless permission is first given by the domain holder.

You can think of a Domain as a “property right”, that leads to another simple rule-of-thumb for practicing Holacracy: You are free to do whatever you wish with your own property (your role’s Domain), but don’t exert control on your neighbor’s property without their permission. We can extend this one step further to include circles as well: If a circle has been granted a Domain to control, and hasn’t further delegated that Domain to one of its roles, then it’s considered “communal property” of all roles within that circle – any one of them can exert control within that Domain. But, if you fill a role which is not in that circle, you’ll need permission first.

eg. Our Facebook Group

Partner

Partner is the term we use for anyone who's working at OMALAB. A partner does not have any "titles" or "positions". They are free to energize the roles that interest them (with the agreement of the Lead Link of course) and also to resign any roles that they are not thriving in.

It is important to differentiate between a Partner and a Role. Generally partners are not supposed to bring up tensions in meetings or object to proposals as a Partner, rather they need to know which Role they are speaking from.

If someone is feeling a tension as a Partner, however, they are free to speak to whomever has an accountability concerning that tension. The health of the system depends on all of us speaking our minds and sharing what we see. But as a Partner I can only make observations and suggestions to relevant roles, if I want to propose or object I need to speak as a Role.

Policy

When filling a Role with a Domain, a Partner has the authority to control (authorize or restrict) how other Roles can impact this Domain through policies.

Policies are worded "when x happens, y is done"

eg. The Admissions circle is given domain over the Fluid Review site (our application portal). And the Prep circle uses that same portal as well. The Admissions circle then adds policies regarding this domain so that Prep knows how to use it in a way that doesn't disrupt operations.

An example of policies there would be:

  • When withdrawing students from their cohort, the student's cohort category should not be removed.

  • When sending emails to students, applications@ must be cc'd.

Purpose

The Holacracy governance process is not governance “of the people, by the people, and for the people” – it is governance of the organization, through the people, for the purpose. It enables the organization to find and express its deepest creative capacity.

For Holacracy to function well, all roles and circles in the organization are focused on purpose. Their own purpose in service of the larger organization's purpose as a whole. These purposes are the statements that we all individually and collectively come back to as a guide to what we do. It is always a great question to ask yourself "is this in service of my role's, circle's, and ultimately the Guild's purpose?"

eg. Creating exquisite livelihood for all.

Role

A role is not a job title, it is a collection of a purpose, domains, and accountabilities that make sense within one entity, or one role. Each partner at Learners Guild will fill more than one role, and a role can have more than one partner energizing it.

Tension

We speak of tensions often, they are the driving force behind any action.

A tension is what a role feels when they see a difference between how things are, and how things can be.

They are called tensions because that is how they literally manifest in our bodies, as tensions. I could feel a tension because I see an opportunity that we are not utilizing, or I could feel a tension because there is something in our structure or operation that is problematic and causes me tension in role.

What is asked of every partner around tensions is to honor your intuition – if you literally “feel a tension” then that is to be respected and listened to. Each of our roles’ tensions and processing them is what drives Learners Guild forward.They are an integral and necessary part of how we do work in Holacracy, they are not a problem.

about purpose driven organizations as an evolution from stake-holder driven organizations.

about the difference between Role and Soul.

Check out what the has to say about a Role: A “Role” is an organizational entity meant to be filled and energized by one or more duly-assigned Partners of the Organization, in order to:

Fulfill a : Express certain capacities or potentials, perform certain functions, and/or pursue certain results on behalf of the Organization

Control a : Control and regulate certain property, functions, processes, domains, or areas on behalf of the Organization

Perform : Perform or otherwise manage and effect the execution of certain ongoing activities for the Organization

Here’s a of how to think about/process tensions.

This is a blog post
This is a blog post
Holacracy Constitution
Purpose
Domain
Accountabilities
flow chart
Accountability
Circle
Domain
Objection
Partner
Policy
Purpose
Role
Tension