Structures for Self-Managed Orgs

Image credit:
Zappys Technology Solutions
License: CC BY 2.0
Image has been modified.

As I've recently been discussing with some colleagues at Google, some self-managed team frameworks are too structured and some are not structured enough. Some are littered with jargon. Some seemed better suited for dysfunctional organizations (which Google, in general, is not). But all, it seems, share some key elements, a skeleton, a scaffolding upon which any organization might build a self-managed framework that suits them, their culture, and their existing effective practices.

In this post, I'm going to be thinking out loud. I'm NOT going to describe a well-formed idea that has been thought through and tested. This my current thinking. So be ready for things that don't work out in the end.

*     *     *

Most of my experience is with Holacracy, so I'll start with that and strip away its flesh to get to the bare bones that it is built upon.

First, Holacracy is divided into two major segments: operations and governance.

(I'm not going to use the Title Case capitalization that the Holacracy documentation favors. I'll try to speak normal English, not Holacracese.)

Operations

The fundamental element of the organization or the team is the role. Holacracy defines a role as a purpose, expectation ("Accountabiity" in Holacracese), or scope of authority ("Domain") that is given a name. For example, a role called Coffee Curator might be expected to stock the break room cupboards with coffee when it runs low and periodically (quarterly?) consult with the rest of the team to learn what their coffee preferences are.

That role has a name, Coffee Curator, and a couple of expectations, restocking and consultations.

Governance

Where operations are getting work done, governance is how the organization gets work done. Who is responsible for what? How are decisions made? What processes are in place to handle edge conditions?

There's a need for someone to seize a new opportunity? Modify or create a role. It's unclear how to use a resource that is under another role's authority? Propose a policy. And existing process wastes time and makes you less effective? Ask the process owner to change it. The process has no owner? Change it yourself.

In a traditional management hierarchy, these solutions would require you to make a proposal to a manager who is likely too busy to bother with such trivial issues. Managers are bottlenecks in the evolution of the organization. They hold it back.

Under Holacracy and other team self-management models, team members don't need to play Mother May I. They can act in the best interests of the team's purpose until a role is created or modified to take that action or exercise that authority in the future.

Roles Without Purpose

Moving on to my next rant...

I don't like roles without an explicitly stated purpose. Holacracy lets you do it anyway. The assumption is that, if a role doesn't have an explicitly stated purpose, you can infer a purpose from the name of the role. In the case of the Coffee Curator, you might expect that its purpose is to curate coffee. But that's kinda ambiguous. Do they curate bad coffee? Do they curate local coffee? Do they merely publish a list of local coffee shops with their opinions of the quality of their coffee?

OK. I would expect Brian Robertson to say that the purpose is vague by intent. It lets the person who fills that role interpret the role as they see fit. The explicit expectations of the role illuminate what it was meant for the role to do.

That can be done with an explicitly stated purpose to. The explicit purpose can be phrased to leave room for interpretation where room for interpretation is intended.

For example, an explicit purpose might be, "to keep the break room well-stocked with good coffee." That leaves a lot of room for interpreting what "well-stocked" and "good" mean. But NOT giving an explicit purpose leaves even more room that might not have been the intent behind creating the role in the first place.

I take it as a foregone conclusion that clarity demands that every team should articulate who does what, or what is expected of whom. Given that, the Holacracy framework does a great job of clarifying what roles should look like, as long as you avoid the Holacracese jargon.

What's Ahead

In coming posts, I'm going to explore other facets of this skeleton, this scaffolding upon which we then might construct a custom self-management frameworks. We'll need to delve into:

• Productivity: mapping larger goals and strategies into personal objectives and projects


• Team norms and common expectations: communication, transparency, and prioritizing projects


• Operational processes: illuminating progress toward shared objectives and expecting colleagues to take on new work


• The many faces of management at various levels of the organization and how to perform those functions in a self-managed organization:
  
  
  
  • Establishing vision, mission, and overall strategies
  
  
  • At middle and lower levels, devising more detailed strategies to implement the larger strategies
  
  
  • Job creation, deletion, hiring, firing, personnel performance assessments, promotions, and compensation
  
  
  • Team building, career coaching, learning, and development
  
  
  • Budgeting, resource allocation, and expense approval
  
  
  • Contracting and vendor relationship management
  
  
  • Maintaining communication and relationships with other teams in the organization

We'll explore a bit of how your organization might implement these functions under Holacracy, but we'll really zoom in on the functions themselves and expand on different ways to do it under any self-managed framework.

If a self-managed organization can perform all of these functions without a manager, what's left for a former manager to do?

*     *     *

How can I help your organization implement self-management? Let's chat: bkh@briankhaney.com.

*     *     *

Image credit: Freepik