Domains

Domain: A distinct area of influence, activity, and decision-making within an organization.

What is a Domain

A team within an organization is formed because the organization requires specific tasks to be accomplished, decisions made, or products developed and delivered. This specific area of influence is defined by the organization through a domain description, which is then delegated to a group of people to form a team.

When this team identifies specific responsibilities that need to be explicitly addressed, they define a sub-domain and delegate it to a team member, creating a role.

In its most basic form, a domain description needs to articulate the team’s or role’s purpose. This purpose usually aligns with an organizational need that is essential for the organization’s functioning and business success.

It’s important to note that a team doesn’t simply exist because people group together. There needs to be a common purpose. If they have this shared purpose, they are already a team, even without a documented domain description. See What is a Team. However, documenting the delegation agreement makes it explicit, creates clarity and shared understanding, and enables us to evaluate and evolve a domain by reviewing its effectiveness.

Domains are not solely an invention of S3 or VSHN. They represent naming conventions and definitions. Essentially, it’s one of many ways to specify 'an area of influence'. What makes it special is that we make it explicit through the act of delegation and use it as the base to create, evaluate, and develop our teams and roles - making explicit what exists or should exist anyway.

This defines the concept of domains at VSHN, it doesn’t replace (self) education on the topic of domains. For that, please read Clarify and Develop Domains from the S3 Guide.

Creating and Delegating Domains

  1. Understand why you want to define a domain - understand the Driver for it.

  2. To brainstorm a domain, you can use a delegation canvas on a miro board. For example: this.

  3. We create a VIP for every domain in Jira. In Jira, there is only the purpose - the reason we need to define and delegate a domain. The VIP links to miro boards, wiki pages, etc., where you prepare everything, and finally to the domain description.

  4. Once an initial agreement is reached on the domain and to whom we delegate it, we create a page in our handbook as a sub-page of Organizational Structure. See the Template you should use, but be aware that what exactly you need to document varies.

Do not expect a role or team to simply function after the scope is defined. A team needs to be built, technically, but more importantly in terms of "Storming - Forming - Norming - Performing": working methods, working arrangements, standards, social aspects, group dynamics, planning and review rhythm, governance, continuous improvement, etc. Depending on the characters in the team, much of this can happen automatically over time, but it usually requires conscious effort.

The Delegator and Delegatee(s)

The Delegator is is the team or role that delegates ("assigns") a domain to an individual or a group of people, the Delegatees. Both are not a role on their own, both roles are implicitly there as long as the domain is delegated. There is no role or team without a Delegator.

Examples of Delegators:

  • The overall Domain of VSHN is delegated by the Board to VSHN, represented by the Management.

  • A Team’s Domain is delegated by the Management.

  • The Team Facilitator role in a Team is delegated to that person by the Team.

A Work Group or cross-team relevant role can also be created by people from different teams, because they need something, then they together could also be the Delegator (buttom-up delegation).

Reviewing Domains

A Domain is an area within the overall organization. What is done and produced in that domain, and the value delivered, needs to serve the purpose of the overall organization. People’s understanding of the organization is limited, and the environment is always changing. Therefore, it’s essential for the delegator of a domain and other relevant stakeholders to regularly check in with the delegatee(s). They should take the time to evaluate and evolve both the design of the domain and how people account for it as their understanding of the domain deepens. People might do a great job of accounting for a domain the way it’s designed, but the design of the domain might be primitive or flawed. Conversely, even if the design of a domain is poor in the first iteration, it will improve over time through this process.

Over time, we discovered that simply talking together isn’t enough. Aside from how clear and relevant the purpose of the domain still is, we need to closely examine certain aspects of a domain and team or role:

  • Assess the Key Deliverables: Are they being delivered as agreed? If not, why? What’s preventing them?

  • Examine the Key Responsibilities: Are they being adequately addressed? If not, why? What’s preventing them?

  • Evaluate the Team Level OKRs and their progress: Is progress in line with their OKRs? What is hindering progress?

  • Review the Fundamental Responsibilities: Are they being addressed good enough for now? If not, what changes are needed? What support does the team need from the organization? This includes the personnel situation of the team - do they have the people with the required mindsets and skills?

In the above, they refers to either the Team or the Rolekeeper, the Delegatee(s).

More on How we do Domain Reviews, here.

Domain Descriptions

The details we need to document are dependent on our agreements. The level of detail depends on what is needed to have a common understanding and to be able to review it. However, there is essential information that we see as needed to make a domain description useful.

Content Requirements

  • Delegator and the Delegatees: Who delegated it to whom.

  • Purpose: What purpose does this domain serve, why does it exist? Please use the 4 parts, 2 paragraph S3 Driver Summary format.

  • Key responsibilities: brief but clear enough. They have to be written in a way, the wording, that can be inspected during reviews. Don’t write what you do; write what you produce, what you deliver to your stakeholders, so that we can ask the stakeholders if that is the case, how well you do that, and what we should improve. This is not optional. If it proves ineffective during reviews, we will need to reword it.

  • Other points are optional, like: decision-making domains, roles, teams, processes, standards, documents, etc. What and how much to document depends on what the delegatees and delegators agree on.

Format Requirements

  • Be as brief as possible, as comprehensive as needed: The level of detail depends on who it needs to be clear for. This document is not an educational resource; it’s a definition. Education might be necessary in addition, and common understanding is typically fostered during the decision-making process when we delegate the domain or review it.

  • Link to VIP: Include a link at the bottom of the page to the VIP where we track the governance of this domain delegation.

  • Prefer bullet point lists over long-form text.

  • Favor searchable text over diagrams and pictures.

Template

While the following serves as a template we acknowledge that most domains are unique, what we need to document depends on what we need to agree on (see above). The format of domains is defined to give a unique reader experience in our handbook, but it might differ from domain to domain and over time, as we learn more how to better define domains. That’s fine, we don’t rework domains just to keep up with the format, until it is needed for clarity.

== Name of the Domain (for example: Domain Customer Support)
:description: brief description of the domain, why it does what.
:keywords: keyword1, keyword2

[cols="h,1"]
|===
|<<Accountable Team,Accountable>>|_TEAMNAME_ xref:vshn_teams.adoc[Team]
|Delegator|xref:domain_business_operations.adoc[Business Operations] (Management)
|Lead|Name of Person (xref:link_to_domain_of_role.adoc[Role Name])
|===

== Purpose

// tag::driver[]
Driver summary - this can be directly the driver from the VIP. But often it makes sense to write it in a more general, opportunity based way vs. writing it from a problem standpoint.
// end::driver[]

== Stakeholders

// tag::stakeholders[]
* *Stakeholder 1:* What they need.
* *Customer Segment 1:*  What they need.
* *The Delegator* of the Team: What they need.
// end::stakeholders[]

== Key Responsibilities

List 1::

* Do X to produce outcome Y
* ...

List 2::

* Do X to produce outcome Y
* ...

== Key Deliverables

* Product 1, definition or link to definition
* Service 1, description what we deliver
* Special kind of or what documentation
* ...

== Dependencies

* List of dependencies, add what they need from whom.
* ...

== Monitoring and Evaluation

* In which interval do we proactively review the domain.
* How do we review the domain periodically.
** Evaluation criteria.

== Other Section

Any other section that is helpful to create clarity, from the https://patterns.sociocracy30.org/clarify-and-develop-domains.html[Clarify and Develop Domains] or anything else.

== Accountable Team

NOTE: Optionally, a note on special agreements for who accounts for this domain.

Aldebaran::

include::vshn_teams.adoc[tag=section_tag_in_team_list]