Domains and Delegation

A domain is a distinct area of responsibility and authority within an organization.

To use their limited time, energy, and resources effectively, people in organizations distribute work between them by delegating responsibilities to individuals (who keep roles), or to teams (squads, units, departments, and so on. In the process, they are explicitly or implicitly defining domains — distinct areas of responsibility and autonomy. Domains may overlap with one another or be fully contained within other domains.

Most domains in an organization fall entirely within the overall domain of the organization. However, some domains relating to the organization might extend beyond the organization itself, like an advisory or shareholder board that may even have the authority to sell or dissolve the organization.

Any role or team’s purpose within an organization is to contribute toward the overall purpose of the organization by taking care of a specific area of responsibility. Inadequately defined domains typically lead to stakeholders having different assumptions about areas of responsibility and people’s level of authority to decide and act for themselves. As a consequence, both collaboration and distribution of work suffer because of missed dependencies, double work, or important work not being done at all.

Clarifying domains makes the contract between the delegator (who delegates responsibility for a domain) and the delegatee(s) (to whom the domain is delegated) explicit, which enables everyone to understand expectations and to reflect on what works and what doesn’t, so that a domain’s design can be improved over time. A clear domain description with a reasonable amount of detail is a necessary prerequisite for people to successfully evaluate and continuously improve their work.

Evaluate and Evolve Domains Regularly

People’s understanding of the organization is limited, and the environment, both inside and outside of the organization, is always changing. Therefore, it is essential that the delegator, delegatee(s), and other relevant stakeholders regularly take the time to evaluate and evolve both the design of the domain and how people account for it, as their understanding of the work required to fulfill the purpose of a domain deepens.

People might do a great job of accounting for a domain in the way it’s designed, but the design itself might still be primitive or flawed. On the other hand, even if the design of a domain is poor in the first iteration, through this process, it will improve over time.

Delegating Responsibility for Domains

Delegation is the grant of authority by one party (the delegator) to another (the delegatee) to attend to a domain (i.e., to do certain things or to make certain decisions), for which the delegator maintains overall accountability.

Responsibility for domains is delegated to groups or individuals, who then act within their defined constraints on their autonomy and influence.

When a domain is delegated to a group of people, they form a team. When a domain is delegated to an individual, they become a role keeper.

The delegatee(s) may do whatever they think will help them achieve their purpose, unless it is outside the domain of the organization, explicitly forbidden, they violate somebody else’s (explicit) domain, or impede other people’s contribution to the organization in some other way.

Note: Things that are forbidden include explicit constraints laid out in the domain description, any other agreements the delegatee(s) need to keep, and legal and regulatory requirements.

The delegator still retains overall accountability for that domain, allocates resources, and often defines:

• the purpose that the delegatees aim to fulfill
• key responsibilities: any essential work and decision-making being delegated to the team or role keeper keeper
• customers and deliverables
• critical risks to manage
• constraints to the autonomy and influence of the delegatee(s), usually related to the organization itself (dependencies, involvement of the delegator, etc.)

See Clarify and Develop Domains for more details.

Domains, Drivers, and Requirements

It’s also possible to understand a domain in the context of organizational drivers and their related requirements:

• Purpose:
  • the domain’s primary driver (the situation the domain was set up to address in the first place)
  • the main requirement the delegatee(s) are responsible for fulfilling with the intention to address the domain’s primary driver effectively
• the various sub-drivers delegatees are required to address in the course of responding to the domain’s primary driver and fulfilling its main requirement, which include:
  • Key responsibilities: requirements that the delegator and delegatee consider essential to take care of in relation to fulfilling the domain’s purpose effectively.
  • Customer requirements
  • Dependencies and constraints (requirements relating to other domains or to the environment beyond the organization) that constrain the delegatees’ autonomy