Explicitly clarify, and then regularly evaluate and develop a domain's design based on learning, to enable those with responsibility for the domain to account for it as effectively as possible.

A clear understanding of people’s area of responsibility and autonomy enables greater efficiency, effective collaboration, and agility throughout 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 designing domains - distinct areas of responsibility and autonomy.

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 delegator and delegatee(s) explicit, which enables everyone to learn about what works and what doesn’t, because everyone understands 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.

A simple way for supporting stakeholders in developing shared understanding about the various aspects of a domain is by creating a domain description that contains information about:

  • Primary Driver (and/or Purpose)
  • Key Responsibilities
  • Dependencies
  • External Constraints
  • Key Challenges
  • Key Deliverables
  • Competencies, Qualities and Skills
  • Key Resources
  • Delegator Responsibilities
  • Key Metrics
  • Evaluation

On the S3 Canvas microsite you can find a variety of templates you can use for (co-)creating and documenting domain descriptions.

Consider designing domains with the minimal constraints necessary and always choose constraints that enable people to maximally create value.

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. Things that are forbidden may include explicit constraints laid out in the domain description, any other agreements the delegatee(s) needs to keep, or legal and regulatory requirements.

When to clarify domains

Consider clarifying domains whenever you identify that stakeholders have differing assumptions about the domain of an existing role, position, team, department, or unit, or even about the domain of the organization as a whole.

As a delegator, clarify any new domains that you intend to delegate.

When retrospectively clarifying domains that have already been delegated to people, a delegator can gain valuable insights by inviting the delegatee(s) to describe the domain from their perspective first.

Regularly evaluate and evolve domains

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.

Clarify the domain of the whole organization

All domains in an organization are nested within the overall domain of the organization, which can be designed deliberately in the early stages of the organization, or clarified retrospectively. An organization’s domain needs to enable the members of the organization to effectively fulfill its purpose and typically needs to be evolved over time.

Consider explicitly clarifying the organization’s overall domain if you discover that key stakeholders have differing understanding about it, or when changes to that domain need to be made. In order to do this it’s necessary to identify the overall delegator of the organization.

An organization’s domain should be designed with the customer and business model in mind, and needs to factor in environmental constraints (e.g. legal, economic, market, competition, etc.)

Regularly evaluate the organization’s domain to support those responsible for the organization to quickly learn and adapt.

One way of clarifying an organization’s domain is by filling out an S3 Organization Canvas.

Useful aspects to clarify in a domain description

All of the following elements are important to consider when clarifying a domain. Depending on your situation and where you are in the lifecycle of the domain, you might be able to describe each of them more or less clearly. Regularly evaluate, test assumptions and make things clearer as you learn.

Template for a domain description

Primary Driver

Explain how the delegatee(s) will contribute to the overall purpose of the organization, by clarifying the specific organizational need they (will) take care of.

Describe the main organizational driver the delegatee(s) (will) respond to, for example using the pattern Describe Organizational Drivers.

Aim for one or two sentences, so that the information is easy to remember and process.

Besides the summary, more details about the driver may be kept in the logbook.

Key Responsibilities

List all essential work and decision-making being delegated, in a way that enables measuring success.

Key responsibilities are those responsibilities that stakeholders consider essential to take care of for the delegatee(s) to successfully account for the domain.

Describe explicitly why each of these responsibilities matter for the organization and the value that taking care of them brings to the organization.

Responsibilities should be specific and measurable, so they can be reviewed and developed as required.


Make explicit the essential dependencies between this domain and other parts of the organization, so that the delegatee(s) can collaborate on managing those dependencies with the other stakeholders.


  • Internal and external customers (those who consume the team’s output)
  • Providers of products or services essential to the work of the delegatee(s).
  • Shared resources

External Constraints

Describe important constraints to the autonomy and influence of the delegatee(s).

External constraints might be fixed or negotiable. They may refer to customer requirements, to the outside world, to other essential stakeholders in the organization, to overarching responsibilities the delegatee(s) may have, or to the preference of the delegator.

Some examples:

  • Specific decisions requiring authorization
  • Legal, time, or budget constraints
  • Audits and or expected reporting
  • Strategy of the delegator and the whole organization
  • Organizational values

Key Challenges

What are the known or anticipated challenges that the delegatee(s) might face when accounting for this domain: relating to the outside world, the rest of the organization and sometimes to a specific delegatee?

  • risks and vulnerabilities
  • variables (e.g. weather)
  • uncertainty and complexity
  • lack of skills or resources.

Note: there are always some risks that you need to manage. Try to list at least 3!

Key Deliverables

What does the team or role provide to respond to its primary driver, the key responsibilities and the key challenges faced?

As a delegator, consider carefully to what degree you will leave the design of deliverables to the delegatee(s), who can then define deliverables and add them to the domain description later. Letting the delegatee(s) lead on the design of deliverables often frees them up to deliver value according to their strengths and interest.

Describe each deliverable with a reasonable amount of detail and ensure that deliverables are valuable to the stakeholders that receive them. You can start with a sentence or two about each deliverable but eventually you might need to describe them in more detail.

Competencies, qualities and skills

What competencies, qualities and skills are required – or at least preferable – to successfully account for this domain?

Key Resources

Essential resources the delegatee(s) can make use of in accounting for their domain, e.g. time allocation, budget, privileges, facilities, hardware, software, etc.

Delegator Responsibilities

When delegating a domain to others, the delegator still retains overall accountability for the domain and often has a valuable contribution to make toward accounting for that domain.

List the exact responsibilities the delegator takes on in support of the delegatee(s) accounting for this domain.


  • Opportunities for learning and development and support offered to the delegatee(s).
  • Things essential for successfully accounting for the domain that only the delegator can do.
  • Things that make the delegatees’ life easier and are worthwhile including.

Describe the delegator’s responsibilities in specific and measurable terms, so that they can be reviewed and developed as required.

Key Metrics

Key Metrics are statistics that serve as critical indicators of progress, project health or performance. They relate to the primary driver (and/or purpose), key responsibilities, challenges, deliverables, and delegator responsibilities defined for this domain.

Key Metrics are monitored and assessed frequently. They are relevant criteria for evaluating outcomes and success in scheduled evaluations (see “Monitoring and Evaluation” below).

For each metric, consider the actual numbers that are monitored, as well as the meaning of those numbers in relation to the domain (targets, acceptable range, or tolerance).

Aim to define simple and specific metrics that you can take regularly (preferably daily).

Monitoring and Evaluation

Regularly evaluate the outcome resulting from activity in this domain and use what you learn to improve creation of value.

In the evaluation, ensure you consider the following aspects:

  • The value the delegatee(s) brought to the organization by accounting for the domain.
  • The delegatees’ work processes, and their collaboration with each other, with the delegator, and with the rest of the organization.
  • How well the delegator takes care of their responsibilities.
  • The design of the domain itself (and potentially the design of other related domains).
  • The delegatees’ competencies and skills in relation to the domain.
  • The strategy the delegatee(s) follows to account for this domain.


  • A schedule or frequency for evaluations.
  • Other helpful evaluation criteria in addition to the key metrics.
  • Any other relevant aspects to consider for the evaluation.
  • Who should take part in the evaluation.
  • A process for evaluation (e.g. Peer Review).
  • Consider including a term (for a role).

Make sure to record and monitor when a domain is due review and add these dates to your logbook.

Additional Information

Consider also including the following information to the domain description

  • Domain Name
  • Delegator (name of the circle or role; e.g. R&D, Project Manager, CEO, etc)
  • Delegatee(s) (if they are known at the time)
  • Date of latest update to the domain description
  • Author’s Names
  • Term (for a role)