Domains

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

To make better use of their limited time, energy, and resources, people in organizations distribute work between them by creating roles or forming teams, units, or departments. In the process they are explicitly or implicitly defining domains – distinct areas of responsibility and autonomy. All domains are within the overall domain of an organization and may overlap or be fully contained within other domains.

Any role or team’s purpose is to contribute towards the overall purpose of the organization by taking care of a specific organizational need. Inadequately defined domains typically lead to stakeholders having different assumptions about areas of responsibility and autonomy. As a consequence, both collaboration and distribution of work suffers because of missed dependencies, double work, or work not done at all.

Clarifying domains makes the contract between the delegator (who delegate responsibility for a domain) and the delegatee(s) (to whom the domain is delegated) explicit, which enables everyone to learn about what works and what doesn’t, and to understand who is responsible for what. 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 is always changing. Therefore it is essential that 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 domain deepens.

People might do a great job of accounting for a domain in the way it’s designed, but the design of the domain might 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 account for 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 its defined constraints on their autonomy and influence.

When a domain is delegated to a group of people, they become a team, when it’s 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 organizational need the domain is designed to respond to
• key responsibilities (key deliverables, any critical risks to manage, other essential work and decision-making being delegated)
• constraints to the autonomy and influence of the delegatee(s), usually related to the organization itself (dependencies, involvement of the delegator, reporting etc.)

Drivers and Domains

It’s also possible to understand a domain in relation to organizational drivers:

• the domain’s primary driver – the main driver the delegatee(s) respond to
• the set of subdrivers the organization may benefit from addressing when responding to the domain’s primary driver, which include:
  • key responsibilities (any driver following directly from the domain’s primary driver)
  • dependencies and external constraints (drivers relating to other domains or to the environment beyond the organization) that constrain the delegatees’ autonomy