OrganizationBuilders

Soendastraat 6
2103 TZ Heemstede
Nederland

hello@organizationbuilders.com
+31 6 2083 5076

Naam
Naam
Als je liever belt, laat dan ook je telefoonnummer achter.
           

123 Street Avenue, City Town, 99999

(123) 555-6789

email@address.com

 

You can set your address, phone number, email and site description in the settings tab.
Link to read me page with more information.

Content

Content Items

Article | Hike One - Installing a new OS (part 2)

Anna Swinkels

HikeOne is practicing Holacracy. By Matthijs Collard: “This is the first of a series of posts about us installing this new OS. I will explain why we choose this path. Why I think it works for our company. What I learned from my conversations and visits to other companies in The Netherlands. And of course, I will share our experiences, best practices, and insights during the process.”

Read More

Article | Hike One - Installing a new OS (part 1)

Anna Swinkels

HikeOne is practicing Holacracy. By Matthijs Collard: “This is the first of a series of posts about us installing this new OS. I will explain why we choose this path. Why I think it works for our company. What I learned from my conversations and visits to other companies in The Netherlands. And of course, I will share our experiences, best practices, and insights during the process.”

Read More

Artikel | bol.com "Een spark als basis voor vooruitgang"

Anna Swinkels

Zoals een vonkje gebruikt kan worden om een vuur mee te laten ontvlammen of een motor mee te starten, zo zien we een spark ook als het eerste duwtje in de rug. Het duwtje dat we nodig hebben om in beweging te komen. Door aan te geven dat je “een spark hebt” start je in je team een gesprek en zet je de eerste stap naar een mogelijke verbetering of oplossing. Lees meer over hoe bol.com omgaat met het oplossen van spanningen.

Read More

Artikel | bol.com "De werkwijzen van bol.com"

Anna Swinkels

In de dynamische e-commerce omgeving waar bol.com in opereert, is voorlopen een blijvende uitdaging. Nieuwe manieren van werken om innovatiekracht te kunnen behouden, multidisciplinair samenwerken, efficiëntie en autonomie vormen het uitgangspunt van de nieuwe manier van werken binnen bol.com. Lees hier wat bol.com er zelf over verteld.

Read More

Artikel | bol.com "Werken volgens SCORE"

Anna Swinkels

SCORE is dè nieuwe manier van denken en werken binnen de winkels van bol.com. Momenteel pilot’en we met een tiental teams om SCORE te lanceren. Deze manier van werken daagt bol.commers op 1001 manieren uit om ondernemend te opereren en flexibele rollen op te pakken binnen zelforganiserende teams. Wat dit betekent? Deep dives met inspirerende collega’s. Een setting waarin trial & error een geaccepteerde werkwijze is. Een mix van autonomie en resultaatverantwoordelijkheid en een strategisch innovatieve omgeving.

Read More

Case | Fronteer

Erica Rasch

Fronteer, een innovatief strategiebureau uit Amsterdam, vroeg ons hun transitie naar een holacratische organisatie te begeleiden. Lees hier hoe we hen hebben geholpen.

Read More

Artikel | Bedrijfscultuur binnen Netflix

Anna Swinkels

Artikel geschreven door Alex van der Hulst (NRC) over de bedrijfscultuur binnen Netflix. Als je werk erop zit, dan vlieg je eruit en die promotie komt er ook niet. Over deze onconventionele cultuur schreef een oud-directeur van Netflix een boek.

Read More

Article | Better understanding how domains work in Holacracy

Anna Swinkels

Holacracy® Basics: Understanding Domains

Domains: The Basics

Domains are one of the three elements of a role/circle (the others are purpose and accountabilities). We use them to centralize control because by default, Holacracy gives everyone authority to take any action or make any decision to fulfill their role/circle’s purpose or accountabilities.

Domains are like a piece of property controlled exclusively by a role/circle. But they needn’t be physical property. They could be things like “the official mailing list,” “the hiring process,” or, “expense reporting and reimbursement standards.”

Domains are great for anything that needs centralized control. Too many people tweaking the website? A domain of “website” might be a good solution. When a role/circle owns a domain it means they can do what they want with it, while others have to ask them for permission.

Impacting Domains

We typically talk about impacting domains rather than controlling or using. We use impacting because it’s more generally applicable to the wide variety of possible domains and how one might interact with them. For instance, what is impacting your neighbor’s car? It’s up to interpretation. Is looking at it impacting? Probably not. How about standing next to it? Ok, how about touching it? Or trying to open the door? Getting in and driving around?

At some point the impacting threshold has been crossed. Everyone can use their own interpretation and should interpretations be misaligned, then the domain can be furthered clarified in governance. So, in some cases using the domain may be impacting (e.g. using my neighbor’s car), and in others it may not (e.g. using the hiring process owned by another role, which would be just fine).

Owning and Delegating a Domain

If your role owns a domain then it’s yours to control. No one else can impact your domain without your permission. However, others may request the right to impact the domain, and you need to consider their requests by allowing or withholding permission (and if you deny the request you have to provide a reason why it would cause more harm than good).

If your circle owns a domain, then it’s like family property; any role in the circle may impact it. However, this is only true as long as the domain hasn’t been further delegated down to a specific role. For example, if the Marketing circle had the domain “website,” then any role in the circle could make changes without asking anyone else for permission.

But if the circle had a governance meeting and delegated the website domain to a specific “Webmaster” role, then the Webmaster role would control it. When this happens, the domain is listed on BOTH the Marketing circle (so that those outside the circle will know who controls it) and the Webmaster role (so that those inside the circle will know who controls it).

Note: “Owning” a delegated domain means you have exclusive control over how it is constructed or used, but it doesn’t give you the authority to sell off or destroy any material assets of the company (i.e. You don’t want to hear, “Great news everyone! As Webmaster, I sold our website for a great price!!”).

Defining Policies

Since you have to consider requests to impact a domain you own, you may find it easier to publish policies, which are like rules or stipulations which make it easier for others to know what they can or can’t do within the domain (i.e. “I’ll let you use this thing, but you have to agree to do this...”).

So, imagine the Facilities & Equipment circle has the domain, “company car.” But every time you borrow the car, it’s low on gas. You’d like to expect everyone to fill the car up after they use it, but it doesn’t make sense to capture that as an accountability (what role would you put it on?), so instead, you can propose adding a policy on the circle, “Anyone who uses the company car must return it with a full tank of gas.”

No matter how sophisticated a policy may look (some could be several pages long), they are by definition always connected to a domain. Technically, policies are either; 1) grants of authority that allow outsiders to impact the domain; or 2) constraints or limitations on how insiders (i.e. those who already have the authority to impact the domain) may impact it.

If your role owns a domain, then you can publish policies yourself outside of governance since you own it exclusively and there is no one else to integrate with (these can be captured as role notes in Glassfrog). You can read more about policies here.

Implicit Domains

Since the broadest circle (i.e. the GCC or whatever your company calls it) automatically controls everything, it would be ridiculous for it to capture everything in Glassfrog as a domain (e.g. “Company logo,” “procurement process,” “coffee machine,” “coffee filters,” “coffee beans,” etc.). So, instead we think of these as implicit domains. Meaning they don’t need to be called out explicitly in governance because the constitution already says, essentially, “the company owns what it owns.”

This is why you will sometimes see policies listed on the domain, “All Company property & ordinary business affairs.” This means the policy is being placed on an implicit domain, which would be duplicative to call out.

For example, if the policy “Anyone using passwords to secure company-related accounts must ensure those passwords are strong,” was on the GCC, you wouldn’t need to also add the domain, “Company-related Accounts,” because that domain is implied.

Common Domain Mistakes

  • Once companies start to understand domains, we sometimes see “A land grab.” Meaning, everyone starts proposing domains for anything they might want control over — rather than proposing them based on real tensions. This is based on a misunderstanding of what domains are and how they work. In this instance domains are being used to define what the circle cares about when those functions are more accurately captured through an accountability (in this sense, “owning” a domain is misinterpreted to mean the sentiment, “own your work”). Having an unneeded domain doesn’t usually cause immediate harm except that it encourages the misunderstanding and can artificially add bottlenecks/red tape.
  • A variation of the first mistake, sometimes people propose domains over things no one else outside the circle would have any interest in. For example, an IT circle with domains like, “IT purchasing process,” or “IT tickets.” It’s very unlikely these domains would ever need to be impacted by any role outside the circle (Therefore, it’s unlikely they were based on real tensions). This doesn’t cause harm directly, as there’s no rule against it, but it does encourage a misunderstanding of what domains are and how to use them.
     
  • Proposing policies like, “Anyone may access the domain as long as you ask first,” when in fact, the domain automatically provides that option. Having a domain don’t necessarily even prevent others from impacting it, because you still have to consider requests. Having this policy is problematic because it encourages confusion over how domains work. Someone is likely to interpret from this policy that other domains are somehow inaccessible. Remember, domains are useful as a checkpoint not a roadblock.
     
  • Understanding the scope of authority for domains (and delegated domains) can be confusing at first. Sometimes a domain is captured in governance which is intended to apply to the whole organization, but doesn’t because the domain wasn’t delegated. For example, imagine the Sales Circle is inside the Marketing Circle, which is inside the GCC. The Sales Circle could propose to give itself a domain of, “Website” in the Marketing Circle governance meeting (and let’s imagine that no one in the Marketing Circle objected). But even though that domain is captured in governance it doesn’t apply outside of the Marketing Circle. This is because no one proposed delegating the “family property” (a domain owned by the GCC) to a specific “family member’s property” (a domain of Marketing), so from the GCC perspective and any sibling circles within it, the Website is still family property. It’s as if a child gave their friends permission to drive the family car (i.e. the Marketing Circle gave permission to Sales to control something it itself didn’t control). In these cases, the domain is listed as belonging to a sub-circle or a role, but it only applies within it’s own family (and not the neighborhood).

Read “Introducing the Holacracy Practitioner Guide” here.