Domains (Roles & Teams)

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 to be made, or products to be 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, or to individuals to form a role.

In its most basic form, a domain description needs to articulate the team’s or role’s purpose. Ideally, responsibilities (not to be confused with a task list) and deliverables for the most important stakeholders are defined to ensure clarity.

Creating and Delegating Domains

Whenever someone (or a group of people) takes care of things in an organization, it is a domain, even if only temporarily. For many activities and required outcomes, it must be clear how things are organized and who is responsible. This is when we explicitly create a domain and delegate it to one or more individuals (a role) or to a group of people as their primary purpose (a team).

The common purpose, shared responsibilities, and goals are what make a group of people a team.

Delegation means that a domain is officially assigned to people, usually following company strategy for value-creating teams, or arising from another higher organizational need (which is represented by someone).

Domain Descriptions

The level of detail to describe and document a domain depends on what is required to create a shared understanding and to enable review. However, there is essential information that we consider necessary to make a domain description useful.

Content Requirements

A domain (role or team) at VSHN requires at least the following:

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

  • Purpose: What purpose does this domain serve? Why does it exist? Use the four-part, two-paragraph S3 Driver Summary format.

  • Key Responsibilities: Brief, but clear enough. They must be written in a way that allows inspection during reviews. Do not write what you do; write what you take care of.

    • Good example: Ensure our office plants are green, healthy, and grow well.

    • Bad example: Water the plants once a week.

Format Requirements

  • Be as brief as possible, as comprehensive as needed: The level of detail depends on who needs clarity. If it is clear to the role keepers or team, the delegator, and the stakeholders, it is likely sufficient.

  • Prefer bullet-point lists over long-form text.

  • Favor searchable text over diagrams and images.

Template

The following serves as a template. We acknowledge that most domains are unique, and what needs to be documented depends on what needs to be agreed on (see above). The domain format is defined to provide a consistent reading experience in our handbook, but it may vary from domain to domain and change over time as we learn how to define domains more effectively. That is fine. We do not rework domains solely to comply with the format unless it is required for clarity.

== Name of the Domain (Role Example: Solution Architect, Team Example: Managed OpenShift & APPUiO)
:description: Brief description of the domain and why it exists.
:keywords: keyword1, keyword2

[cols="h,1"]
|===
|Delegator|<link to delegating domain (role, team, delegate circle)>
|Accountable Team|_TEAMNAME_ xref:vshn_teams.adoc[Team] # if Team
|Role Keepers|<List of names> # if Role
|Contact|usually link to Rocket.Chat channel
|===

== Purpose

// tag::driver[]
Driver summary – In which situation or under what strategy does VSHN (and its stakeholders) need what? This should describe why this role or team domain exists.
// end::driver[]

== Key Responsibilities
_List the essential responsibilities assigned to this role._

* One thing this role or team is responsible for. Avoid listing tasks or duties; use a generic, higher-level description and leave details and the “how” to the role or team.
* Another thing this role or team is responsible for
* ...

== Stakeholders and Key Deliverables
_Whom does this role deliver value to, and what do they need from it?_

<Link to role or team>, external stakeholder::
* Deliverable 1 – What do they get from this role or team?
* Deliverable 2
* Deliverable 3

<Link to role or team>, external stakeholder::
* Deliverable 1 – What do they get from this role or team?
* Deliverable 2
* Deliverable 3

== Dependencies

<Link to role or team>, external party, etc.::
* What 1 – What does this role need from them?
* What 2
* What 3

== <Other Section>

Any other section that helps create clarity, drawing from https://patterns.sociocracy30.org/clarify-and-develop-domains.html[Clarify and Develop Domains] or other relevant sources.