Clarify and Develop Domains

A common practice in organizations is to distribute work and decision-making between people, to make good use of their limited time, energy and resources. In the process people are explicitly or implicitly defining and designing domains —distinct areas of responsibility and authority within the organization. Depending on the purpose it’s meant to achieve, a domain in an organization may be temporary (e.g for a project), or permanent (e.g. finance).

Responsibility for domains is taken on by individuals (role keepers), or by groups of people (teams, projects, platforms, micro-enterprises, departments, etc.) Each team or role keeper contributes toward fulfilling the overall purpose of the organization by taking care of a specific area of responsibility in the organization. In some cases, people might keep more than one role, or be part of more than one team.

In the process of delegating responsibility to others, or when existing responsibilities are misunderstood or people’s efforts to fulfill their responsibilities are impeded in some way, consider explicitly clarifying domains. A written description of significant domains helps to reduce misunderstanding and makes existing expectations and assumptions clear. It lays out the contract between delegator and delegatees, and describes how the domain’s design and the work done by the delegatees, can be monitored, evaluated and improved over time.

Why clarify and develop domains?

Clarifying domains makes expectations about the distribution of work transparent. It supports making the contract between delegator and delegatees explicit and helps everyone understand who is responsible for what. A clear and easy to understand description of the area of responsibility and scope of authority to influence that delegatees have, helps clarify the part that each team or role keeper plays in the overall value chain. It also supports effective organizational development by making expectations explicit. Regular evaluation of each domain’s design can reveal ways to improve them to enable greater efficiency, collaboration, and agility throughout the organization.

When domains are inadequately or insufficiently defined, stakeholders may have different assumptions about areas of responsibility and autonomy. As a consequence, both collaboration and distribution of work can suffer because of unnecessary or missed dependencies, double work, or work not done at all.

A clear domain description with adequate detail is a necessary prerequisite for people to successfully evaluate and continuously improve their work. Regular evaluation of each domain’s design supports learning about what works and what doesn’t. It helps people to identify ways to improve domain design over time, both locally regarding each individual domain and also regarding the overall structure of domains, the ways in which responsibilities are distributed between them, and the ways in which they are linked together to support the effective creation and delivery of value throughout the whole organization.

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:

• Purpose: What is the specific purpose the team (or role keeper) is responsible for fulfilling within the organization?
• Key Responsibilities: What is the essential work and decision-making being delegated to the team (or role keeper)?
• Customers and Deliverables: Whom does this team (or role keeper) deliver value to and what specifically do they provide?
• Dependencies: Who is the team (or role keeper) dependent on, from other parts of the organization or the outside world, and what deliverable(s) do these people provide?
• External Constraints: What are important external constraints to the delegatees’ autonomy and influence?
• Key Challenges: What are the most important known (or anticipated) challenges the delegatees might face?
• Key Resources: What essential resources can the team (or role keeper) make use of?
• Delegator Responsibilities: What responsibilities can delegatees rely on the delegator to take care of to support them to successfully account for this domain?
• Competencies, Qualities and Skills: What competencies, qualities and skills are required – or at least preferable – to successfully account for this domain?
• Key Metrics and Monitoring: What are the critical indicators of progress, performance, project health, etc, how frequently will they be measured and by whom?
• Evaluation Schedule: When and how will you evaluate the effectiveness of the domain’s design and the success of the team (or role keeper) in fulfilling the domain’s purpose?

On the S3 Canvas microsite you can find a template that you can use for (co-)designing new domains or for documenting existing domains, when clarifying them is worthwhile.

For a complete example of a domain description, see the Appendix: Example Domain Description: Marketing Department.

Considerations for designing domains

Free delegatees up to create and deliver value. Aim to design or develop domains in ways that enable them to fulfill the purpose of the domain as effectively as possible:

• Avoid, minimize or remove any unnecessary dependencies and constraints that otherwise impede the ability of the delegatees to successfully account for the domain.
• Enable delegatees to undertake whichever activities they consider to be valuable, unless such activity falls outside of the domain of the organization, is explicitly forbidden, they violate somebody else’s (explicit) domain, or if it impedes 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 delegatees need to keep, or legal and regulatory requirements.
• Aim to design simple metrics that help delegatees learn whether or not they focus on the right things
• Keep the design brief and to the point, and schedule regular evaluations to discover what is working, what’s missing, and what needs to be changed.

When to clarify domains

When delegating responsibility for a new domain: as a delegator, take the time to draft out a design of the domain you intend to delegate, before contracting with an individual or team to take responsibility for it. As part of the delegation process, It’s often worthwhile to review and perhaps develop some aspects of a new domain design, with input from the delegatees.

When existing domains are unclear: Consider clarifying existing domains whenever you identify that stakeholders have differing assumptions about the domain of an existing role, position, team, project, department, or even about the domain of the entire organization, if that unclarity leads to confusion, double work, work not being done, etc.

When retrospectively clarifying domains that have already been delegated to people, invite the delegatees to describe the domain from their perspective first. Then, in a dialogue between delegator and delegatees, add, remove or change things until you reach a common understanding and an agreement on the design of the domain.

When clarifying domains throughout an entire organization there is often merit in starting first with the domain(s) relating to governance and leadership of the overall organization. Identify and describe the responsibilities that those with responsibility for the overall organization have. Consider which of those responsibilities are essential for them to handle directly, which would benefit from, or are dependent on, input from others throughout the organization and in this case, clarify who. Consider which responsibilities would be better delegated down the system, closer to those doing the actual work, to remove any unnecessary decision-making hierarchy and position responsibility for decision-making as close as possible to where value is being created and delivered to customers.

Starting point

All sections are worth considering when clarifying a domain. However, if you’re tight on time, or if many aspects of the domain are currently unclear, start with defining the following, and then cover the rest as soon as you can:

• Purpose
• Key Responsibilities
• Customers and Deliverables
• Delegator Responsibilities
• An early date by when the design of the domain will be reviewed and improved.

Regularly evaluate and develop domains

People’s understanding of the organization is limited and the environment is always changing. Therefore it’s essential that delegator, delegatees and other relevant stakeholders regularly evaluate and when useful, improve the design of domains as their understanding of each domain and its contribution to a value chain deepens.

If the design of a domain is primitive or flawed, it will impede the team or role keeper’s ability to contribute effectively to the purpose of the organization, even if the delegatees are doing a great job of accounting for the domain in the way it is currently designed. Therefore it’s essential that a domain’s design is regularly evaluated so that a poor or out of date design can be improved incrementally as people learn over time.

If changes are made to one domain, consider if other domains are affected and make changes accordingly. Especially look to subdomains and dependent domains.

Clarify the overall domain of the organization

All domains in an organization are nested within the overall domain of the organization. This domain can either be deliberately designed and described in the early stages of the organization, or clarified retrospectively. An organization’s overall domain needs to be designed in a way that enables the members of the organization to contribute effectively toward fulfilling its purpose, and it too, typically needs to be evolved over time.

Consider reviewing the design of the organization’s overall domain and how it’s described if you discover that key stakeholders have differing understanding about it, or when its current design leads to missed opportunities or significant impediments. Review and adaptation of the organization’s overall domain is the responsibility of the overall delegator of the organization. In a typical organizational hierarchy, the overall delegator is either the owners (or shareholders), sometimes represented by a board of directors, the president/CEO or the executive team. In a bottom-archy (e.g. a cooperative, or a community), the overall delegator might be everyone.

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

An organization’s overall domain should be designed with the customers, partners, other stakeholders, and business model in mind. It also needs to factor in environmental conditions (e.g. legal, or economic constraints, market trends, competition).

Once clarified, regularly evaluate the overall domain of the organization to identify opportunities for improvement and adapt its design when helpful or necessary.

Useful aspects to clarify in a domain description

All of the following elements are important to consider when clarifying a domain. Depending on where you are in the lifecycle of the domain, you might be able to describe each of them more or less clearly. Remember to regularly evaluate each domain’s design, to test assumptions, clarify misconceptions and improve things, as you learn over time.

Purpose

What’s the primary driver and the associated requirement this team (or role keeper) is responsible for taking care of in the organization?

Describing the specific purpose the team (or role keeper) is responsible for fulfilling within the organization, clarifies why this domain exists, so that delegatees understand what’s expected of them and why their work is relevant for the organization.

You can describe the primary driver using the pattern Describe Organizational Drivers and look to the pattern Respond to Organizational Drivers for suggestions on how to describe the requirement.

Describe:

• Primary Driver: Describe the current situation, its (anticipated or current) effect, and if it’s not already obvious, the relevance of this effect for the organization (to clarify why it’s worthwhile or necessary to respond to the situation).
• Main Requirement: Describe what is required to respond to this situation, as well as what is the anticipated impact of fulfilling the requirement?

Recommended format: Primary Driver: (current situation) and (anticipated or current) effect, if useful, also describe (relevance). Main Requirement: (requirement) and (anticipated impact).

Examples:

1. Purpose of a Team Support domain:

   Primary Driver: (current situation) To resolve local issues, teams develop their work processes and meeting schedules in the way they see fit. (effect) This often leads to incoherence in how work and decision-making is handled between teams and (relevance) it impedes effective collaboration on handling dependencies between and across domains.

   Main Requirement: (requirement) We need to support teams to develop and maintain a coherent approach to how they collaborate on dependencies (anticipated impact) so that they are able to deal with them effectively while ensuring they are still able to resolve local issues as autonomously as possible.

2. Purpose of a Marketing domain:

   Primary Driver: (current situation) Despite its limited feature set, our product is already highly valuable to a lot of small businesses, yet we operate in a competitive market where others provide a similar product with a far wider feature set than ours, (effect) and despite our competitive pricing, they currently tend to opt for these other products due to their reputation, and a lack of familiarity with ours.

   Main Requirement: (requirement) We need to increase awareness and understanding of our product and its benefits among those businesses that would appreciate it and find our existing feature set adequate for their needs, (anticipated impact) so that we boost sales and avoid the overhead that comes from attracting customers that are dissatisfied with the features we provide.

Tips:

• Aim for two to three sentences as a maximum, so that the information is easy to remember and process.
• Besides the summary, more details about the driver and the associated requirement may be kept in a logbook.
• Ensure the description of the purpose clarifies why the work of delegatees is relevant for the organization.
• Whilst the purpose can sometimes be clarified only by describing the main requirement the domain desponds to, it’s helpful to describe the primary driver behind the requirement as well, as it helps to clarify context and supports monitoring and evaluating outcomes,
• Sometimes the Primary Driver is generic and obvious, for example, in the case of an HR or Marketing domain.

Key Responsibilities

What is the essential work and decision-making being delegated to the team (or role keeper)?

Key responsibilities are a summary of those areas of work and decision-making that the delegator and delegatees considers essential to take care of in relation to fulfilling the domain’s purpose effectively. They provide a high level overview of what’s expected from the delegatees.

Listall essential responsibilities that are being delegated by clarifying the requirement in each case, and the anticipated impact that responding to each requirement will bring.

Recommended format: (requirement) and (anticipated impact). If useful, describe the Driver as well: (current situation), (anticipated or current) effect, and (relevance).

Examples:

1. For a customer service team

   Requirement: (requirement) Ensure that customer inquiries are responded to in a timely manner (anticipated impact) so that we stay within the time-frame stipulated in our service level agreement.

   Driver: (current situation) The organization has observed an increasing volume of customer inquiries, with varied complexities, (effect) leading to delays in response times and customer dissatisfaction.

2. For an agile coaching domain:

   Requirement: (requirement) Support cross-team collaboration on dependencies, (anticipated impact) so that common objectives of product teams are effectively achieved.

   Driver: (current situation) Our product development process involves multiple interdependent teams, (effect) where lack of coordination can lead to bottlenecks and project delays, (relevance) emphasizing the need for effective cross-team collaboration to ensure efficient progress and successful delivery of product objectives.

3. For an organizational development training provider team:

   Requirement: (requirement) Develop and deliver bespoke learning interventions (anticipated impact) to fulfill customer learning needs.

   Driver: (current situation) Our customers operate in a dynamic business environment where employee skills and knowledge requirements are constantly evolving, (effect) which leads to critical gaps in workforce capabilities and adaptability, (relevance) underscoring the necessity for tailored learning interventions that ensure that employees are equipped to meet current and future challenges effectively.

4. For a marketing team:

   Requirement: (requirement) Execute and refine digital marketing campaigns, (anticipated impact) to improve engagement metrics and customer acquisition costs.

   Driver: (current situation) With digital ad spend increasing without proportional gains in engagement, (effect) current strategies are leading to diminishing returns.

Tips:

• Key Responsibilities inform, and are informed by, various other aspects of a domain’s design. Therefore, while describing those other aspects, you will often find things that need to be added or revised, in this section documenting Key Responsibilities.
• If the organizational driver behind a key responsibility is unclear, describe this as well to add context. Doing so helps to ensure that the reason for fulfilling each of these requirements is clear.
• Don’t describe the tasks that the delegatees are taking care of, but rather the requirements that those tasks are meant to fulfill.
• Describe the anticipated impact of fulfilling each requirement in a way that allows you to define specific metrics to assess whether or not that impact has been achieved. For example, say, “… so that customers return and recommend our products to others” rather than “… so that our customers are happy”.
• If you mention or imply specific deliverables in the description of certain Key Responsibilities, describe those deliverables explicitly in the section about Customers and Deliverables, as well.

Customers and Deliverables

Whom does this team (or role keeper) deliver value to, what specifically do they provide, and why?

The purpose of work done by the delegatees is to provide value to their customers. Customers can include those who are paying money for the deliverables provided, or others from inside of the organization who are dependent on these deliverables to do their work.

Deliverables are the products, services, components and materials that delegatees deliver to fulfill their customers’ requirements.

List the direct recipients of the value delivered by the team (or role keeper). In each case, describe the deliverables they receive with enough detail to clearly communicate what is being provided, and clarify the requirement that each deliverable is intended to fulfill.

Recommended format: Customer and Deliverable(s). And, unless it’s already clear, information about the Requirement: (requirement) and (anticipated impact).

Examples:

1. For a marketing department:
   • Customer: Current and Potential Customers
   • Deliverable: Regularly updated content such as blog posts, newsletters, and social media updates (requirement) to keep the customer base informed about the latest company news, product developments, and industry insights, (anticipated impact) to strengthen brand loyalty and attract potential customers.
2. For the delegator of a marketing department:
   • Customer: Executive Leadership
   • Deliverable: Marketing performance analytics reports (requirement) that measure campaign effectiveness, customer engagement, and ROI to inform strategic decisions and budget allocations, (anticipated impact) to inform leadership about marketing performance and guide budgeting and strategy development.
3. For a team that delivers consulting to clients:
   • Customer: Sales & marketing department
   • Deliverable: Success stories about our work with clients (requirement) that can be used as reference for future sales (anticipated impact) to enhance the sales team’s ability to demonstrate the value and effectiveness of the consulting services, ultimately aiding in closing more sales deals.
4. For a team that designs and develops websites for business clients:
   • Customer: Clients
   • Deliverable: Design and develop user-friendly and aesthetically pleasing websites company websites (requirement) that ensure a positive user experience and that the client’s customers engage with (anticipated impact) to support their business objectives for increased traffic, customer retention, and sales.
5. For a User Experience team:
   • Customer: development team
   • Deliverable: interaction design for new features - with detailed description for all edge cases and potential errors, complete with all graphical assets required for implementation without the need for further communication, (requirement) to facilitate the development team in efficiently building and implementing features that offer an optimal user experience, (anticipated impact) reducing the need for extensive revisions and ensuring a smoother product development process.

Tips:

• Sometimes the specific deliverables for fulfilling a customer requirement are currently undefined. In this case, describe the customer requirement instead.
• Remember: deliverables are products, services, etc, NOT outcomes.
• When identifying Customers and Key Deliverables, consider the Purpose, Key Responsibilities, and Key Challenges of the domain.
• List all relevant internal and external customers who depend on, or benefit from the value provided by this team (or role keeper).
• Include both customers and users (if there is a difference).
• When describing deliverables, use a sentence or two to describe each one. Link to a more detailed description if necessary.
• As a delegator: In the case of a new domain, consider carefully to what degree you will specify deliverables rather than leaving this decision up to the delegatees. Freeing them up to create value according to their expertise, strengths, and interests, and based on what they learn as their work proceeds can significantly improve their effectiveness.

Dependencies

Who is the team (or role keeper) dependent on, from other parts of the organization or the outside world, and what deliverable(s) do these people provide?

Dependencies refer to who and what the delegatees rely on, besides themselves and the key resources they have available, to be able to account for the domain successfully. Some dependencies are prerequisites for the daily work, others are only required occasionally.

Describe those deliverables that are essential to the work of the delegatees. Explicitly name who provides them in each case (either from within the organization or from the outside world), and clarify the requirement that each deliverable is intended to fulfill.

Recommended format: Provider and Deliverable(s). And, unless it’s already clear, add information about the Requirement: (requirement) and (anticipated impact).

Examples:

1. For a sales team:

   Provider: Legal team

   Deliverable: adaptation of standard contracts for specific customers (requirement) to ensure the customer’s contract is in line with the unique agreements and terms negotiated, (anticipated impact) aiding smooth business transactions and reducing the risk of contract disputes.

2. For a support team:

   Provider: development team

   Deliverable: help from developers (requirement) for technical assistance and resolution of complex issues, (anticipated impact) to enable the support team to address customer queries more effectively and improve overall customer satisfaction with prompt issue resolution.

3. For a development team:

   Provider: external consultancy Deliverable: designs for new features on demand, including the graphical assets (requirement) to support the development of innovative and user-centric design solutions, (anticipated impact) that enhance the functionality and user experience of the development team’s products, leading to more successful and marketable software solutions for our customers.

4. For a training department:

   Provider: IT department

   Deliverable: IT support for making certain online learning tools available (requirement) that ensure seamless integration and functionality of online learning platforms, (anticipated impact) to facilitate effective digital learning experiences, thereby improving the skills and competencies of employees across the organization.

5. For a research and development team:

   Provider: local university laboratory Deliverable: testing facility with advanced testing and research facilities, (requirement) to enable thorough experimentation and innovation, crucial for (anticipated impact) developing cutting-edge products and technologies in line with industry standards and market expectations.

Tips:

• Include information that communicates what requirement a deliverable is intended to fulfill.
• Describe any relevant expectations relating to delivery.
• When delegatees rely on a deliverable from another domain, ensure that they are explicitly listed as a customer of that other domain and include details about the deliverable in that other domain’s description.
• When describing deliverables, use a sentence or two to describe each one. Link to a more detailed description if necessary.
• For deliverables provided by external partners, ensure these are clearly described in a contractual agreement.

External Constraints

What are important external constraints to the delegatees’ autonomy and influence?

External constraints are anything that limits the delegatees’ freedom to decide and act. They may refer to customer requirements, the outside world, other essential stakeholders in the organization, overarching responsibilities the delegatees may have, or to the preference of the delegator.

Some constraints only affect a single domain, others – referred to as standard constraints – affect several domains (e.g. an entire branch, platform, or department), or even all domains of the organization (e.g. company-wide strategy, organization-wide rules, etc).

Some external constraints are fixed while others may be negotiable with stakeholders. They can include:

• deadlines
• specific decisions requiring authorization (from the delegator, a representative of another domain, etc.)
• specific legal or regulatory constraints
• time, or budget constraints
• audits
• expected reporting
• organizational strategy or values
• limitations when essential resources are shared.

Describe important constraints to the delegatees’ autonomy and influence and if necessary, offer some context to clarify why each constraint exists.

Recommended format: Constraint: (requirement) and (anticipated impact). If useful, describe the Driver to add context: (current situation)

Examples:

1. Constraint: (requirement) Ensure that we have clearance from the provider for training external consultants, (anticipated impact) so that we get the reduced rate for training. Driver: (current situation) We have an agreement with the external services provider that external consultants only receive 50% of their hourly fee for attending training provided by our company.
2. Constraint: (requirement) Prioritize work on projects with deadlines over time spent on training and development (anticipated impact) so that we can keep to delivery dates agreed upon with customers. (Driver is obvious in this case)
3. Constraint: (requirement) Monthly expenditure over $15k needs to be approved with the PM (anticipated impact) to ensure total expenditure for the project remains within the overall budget. (Driver is obvious in this case)
4. Constraint: (requirement) Consult with the Architecture Circle on decisions related to software architecture, (anticipated impact) to ensure architectural coherence throughout all software products. (Driver is obvious in this case)
5. Constraint: (requirement) Schedule all hands meetings between 15:00 - 18:00 CEST, (anticipated impact) so that team members from the various time-zones can work during typical working hours. (Driver is obvious in this case)
6. Constraint: (requirement) For projects larger than 3 person months, the team needs to have their project plan approved by the delegator, (anticipated impact) so that they can bring in their project management experience. Driver: (current situation) the team does not currently feel confident managing large projects, alone.
7. Constraint: (requirement) Deliver the finished product to the integration team by 01 Feb (anticipated impact) so that they have time to complete integration before then non-negotiable project deadline on 10 March. (Driver is obvious in this case)

Tips:

• For each constraint, clarify what is required and what the anticipated impact of fulfilling the requirement is expected to be. Add further information to clarify the context where useful.
• Describe in detail those constraints that are specific to this domain. Link to information about standard constraints that are also relevant to other domains as well, or to the whole organization.
• If the reason why the constraint exists is unclear, provide some context by describing (or referencing) the organizational driver (current situation) behind the constraint.
• Certain external constraints may lead to key challenges for the delegatees.
• Constraints within the company should enable organizational effectiveness overall. If an internal constraint impedes effectiveness, it’s worth reviewing if and how it can be changed. External constraints may or may not directly support organizational effectiveness but they need to be adhered to regardless (because the organization is powerless to change it).

Key Challenges

What are the most important known (or anticipated) challenges the delegatees might face?

Key challenges relate to situations that might significantly impede the delegatees’ ability to successfully account for the domain and where what’s required to deal with those situations is variable or not obvious. Explicitly describing key challenges enables delegatees to monitor and decide how to prepare for and respond to them, should they occur.

Key challenges include:

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

Describe the Driver, the situation that is (or might be) challenging and the (anticipated) effect this would have on the organization. Include information about how this might impede the ability of the delegatees to successfully account for this domain.

Recommended format: Driver: (current situation) and (anticipated or current) effect

Examples:

1. (current situation) Changing legal requirements that need to be included in our software are often only announced a few weeks before taking effect (anticipated effect) which can make it difficult to respond to the changes in time.
2. (current situation) Due to differing priorities, partners are sometimes unavailable when we need their services, (effect) making it difficult to meet project deadlines.
3. (current situation) Our codebase is old, incoherent and poorly maintained, and we lack the funds to clean up the code. (effect) Therefore it’s hard to estimate how long adding a new feature will take, and changes can lead to bugs and security issues.
4. (current situation) Customer purchases are highly weather dependent (effect) which makes it difficult to optimize perishable stock and staffing.
5. (current situation) We’re threatened by an economic crisis, (anticipated effect) which could significantly impact our ability to meet our sales target.
6. (current situation) Some team members have their main responsibilities in other domains, (anticipated effect) which can sometimes make it difficult for them to free up enough time for work in this domain
7. (current situation) Due to cultural differences, there is a diversity of norms and expectations across the different teams (effect) which has in the past led to miscommunication, conflict and ineffectiveness.

Tips:

• There are always some challenges that you need to address. Try to list at least three!
• Keep your descriptions objective.
• When identifying key challenges, consider customers, the outside world, the organization itself, the delegator and the specific delegatees.
• Managing a key challenge might become a key responsibility as well, e.g. “ongoingly manage risk X”.
• When deciding how to prepare or respond to key challenges, include the delegator if helpful.

Key Resources

What essential resources can the team (or role keeper) make use of?

Key resources are those resources provided by the organization to delegatees that are essential for them to use to be able to fulfill the requirements of the domain effectively.

Clarity regarding which resources are currently available helps with monitoring and evaluating over time which are of value, which are essential, what might be missing, and what might actually be unnecessary.

Key resources can include:

• time allocation
• supply of money
• privileges and permissions
• facilities, hardware, software, tools
• internal or external service providers
• components, materials, etc.

Describe the resources that are available for the delegatees to use.

Examples:

1. Time allocation for delegatee: 32 hrs per week
2. Budget for hardware, software licenses and external engineering service providers is provided on request
3. Budget for yearly training: 2000€ per person. Extension possible on request.
4. Company credit card to hire cars and mini buses for transporting casters to the casting locations.
5. A budget of €5000 per month for advertising
6. Administration privileges for systems X,Y and Z
7. Direct communication channel (Slack) with customer
8. Access to all machines, instruments and test-rigs whenever not in use
9. Access to research facility from 8:00-18:00, weekdays
10. By-weekly mentoring session with external marketing expert
11. Account with stationary provider

Tips:

• Only describe resources that are specifically allocated for use in this domain. For example, if everyone in the organization is provided with a computer, it’s unnecessary to list it here. However, if delegatees are provided with a laptop while everyone else gets a desktop computer, include the laptops in the list.
• Be specific about quantity or amount.

Delegator Responsibilities

What responsibilities can delegatees rely on the delegator to take care of to support them to successfully account for this domain?

When delegating responsibility for a domain to others, the delegator retains overall accountability for ensuring the purpose of the domain is fulfilled. In support of this, they often have a valuable contribution to make toward the delegatees success. Describing specific responsibilities relating to the domain that the delegator will keep or take on, clarifies what delegatees can rely on them for, and helps to keep expectations clear.

List any existing responsibilities related to this domain that the delegator had prior to delegation that they will keep, as well as information about new responsibilities that they take on to support the delegatees.

Recommended Format: Requirement: (requirement) and (anticipated impact). If useful, describe the Driver as well: (current situation), (anticipated or current) effect, and (relevance).

Examples:

1. Requirement: (requirement) Provide training for new team members when necessary, (anticipated impact) to ensure that they are familiar with the processes & tools the team works with.

   Driver: (current situation) The organization regularly integrates new members into existing teams, (effect) and lack of proper training can lead to inefficiencies and errors, (relevance) and an overall decrease in team productivity and quality of work.

2. Requirement: (requirement) Ensure that questions delegatees have throughout the project are answered within 24 hours (anticipated impact) to avoid bottlenecks while waiting for a reply.
3. Requirement: (requirement) Inform delegatees of any relevant news or changes and work with them to update the domain’s design when necessary or helpful.
4. Requirement: (requirement) Participate in scheduled Peer Review sessions with delegatees, (anticipated impact) to support them with ongoing development and maintaining high standards.

5. Requirement: (requirement) In case of API changes, prioritize process software development resources to do required modifications, (anticipated impact) to allow automation interfaces to adapt swiftly to changing requirements.

   Driver: (current situation) The technological landscape is rapidly evolving, (effect) and failure to promptly adapt to changes like API updates can lead to system incompatibilities or downtimes.

6. Requirement: (requirement) Proactively advocate for the work of delegatees with C-level and address concerns that they have (anticipated impact) to build credibility and support early on in the project.

   Driver: (current situation) Delegatees often face challenges in having their perspectives and needs understood and prioritized by top-level management, (effect) which can result in misalignment of goals and lack of support for critical projects.

Tips:

• Describe all responsibilities that the delegator keeps or takes on to support delegatees to successfully account for this domain. This includes responsibilities that may only require a small effort but that make the team’s or role keeper’s lives easier.
• When identifying delegator responsibilities, consider any opportunities for learning, development and support that are helpful for the delegatees.
• Often, delegator responsibilities can be adequately documented by describing the requirements. If the organizational driver behind a particular delegator key responsibility is unclear, describe this as well to add context. Doing so helps to ensure that the reason for fulfilling each of these requirements is clear.
• Don’t describe the tasks that the delegator is responsible for taking care of but rather the requirements that those tasks are meant to fulfill.
• Describe the anticipated impact of fulfilling each requirement in a way that allows you to define specific metrics to assess whether or not that impact has been achieved, so that the delegator’s work can be reviewed and developed when necessary.
• As a delegator, keep track of, and fulfill the responsibilities you have agreed to take on or keep.
• Delegator responsibilities might lead to a new deliverable that the delegator will provide to the delegatees. In this case, remember to list the deliverable in the dependencies section.

Competencies, qualities and skills

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

For selecting suitable delegatees, and for identifying important areas for training and development, it’s helpful to determine any attributes that are considered necessary or desirable for the role keeper or team members to have, to successfully account for this domain.

Record any information that helps people to understand the competencies, qualities or skills that delegatees need to have or develop, to account successfully for this domain. If not obvious, include an explanation of why a particular competence, quality of skill is relevant (which requirement it fulfills).

Examples:

1. Experience in coaching, mentoring and training with individuals and groups around the topics of collaboration, team and or organizational development.
2. General group facilitation skills
3. Ability to diagnose and resolve technical issues quickly
4. Have a good foundation of product and project management approaches
5. At least one year of project experience with Apache Cassandra, Apache Kafka and ClickHouse.
6. Working knowledge of software architecture principles, including microservices architecture and domain-driven design.
7. Effective communication skills, both verbal and written, to elicit product requirements from a diverse user-base.
8. Product knowledge on bookkeeping software and knowledge about the market
9. Minimum 4 years experience of working with Scrum in a team.
10. Bachelor’s or Master’s degree in clinical mental health counseling
11. 8-10 years of human resources experience within a multinational company

Tips:

• Consider the Primary Driver, Key Responsibilities, Key Deliverables and Key Challenges, and what you already know is useful or necessary to deal with these things effectively.
• It’s not always possible or worthwhile to find people with all of the necessary experience and expertise. When this is the case, ensure delegatees have opportunities to develop those competencies and skills or consider external providers and list them as dependencies instead.
• Include level of expertise or amount of experience if helpful.

Key Metrics and Monitoring

What are the critical indicators of progress, performance, project health, etc, how frequently will they be measured and by whom?

Key Metrics are statistics that help delegatees monitor the effectiveness of their work and identify when they need to correct course. Metrics need to be monitored frequently and serve as critical indicators of progress, project health or performance. They typically relate to the primary driver and main requirement, key responsibilities, customers, deliverables, key challenges, and the delegator responsibilities that have been defined for the domain.

Define simple and specific metrics that enable you to monitor progress and effectiveness, as well as to spot potential issues or opportunities as they arise. Specify when or how frequently key metrics will be checked, and by whom, and clarify the purpose that meeting this metric should help to fulfill (describe at least the requirement, and if helpful, the driver, too).

Recommended format: Title, Description, Rate, Responsibilities, Threshold, and Purpose (include information about the Driver (current situation and anticipated or current effect. And, Requirement ((requirement) and (anticipated impact)) as necessary.

Examples:

1. Interviews per hire
   • Description: The ratio of candidates hired to candidates interviewed by recruiter or channel (e.g. Website, LinkedIn)
   • Rate: monthly (first week of the month for last month)
   • Responsibilities: Jake compiles the monthly report in Confluence
   • Threshold: When a recruiter or channel rises above 15, the HR team compiles a detailed report about that partner or channel, and makes a decision how the ratio can be improved, or, if the ratio was below the threshold for at least 3 months, whether that partner or channel should be kept.
   • Purpose: (requirement) Identify which recruiters and channels (anticipated impact) provide the best return on time spent by senior staff in interviews.
2. Employee retention by recruiter
   • Description: For each recruiter, track the total number of employees provided that were employed at the beginning of a month (TE), and the number of employees who left during that month (EL), then calculate retention rate = (TE - TL) / TE * 100
   • Rate: monthly
   • Responsibilities: monitored by HR team
   • Threshold: if the rate for a recruiter is less than the average company retention rate, decide what to do about it in the next Planning Meeting
   • Purpose: (current situation) Onboarding new people carries a high cost (anticipated effect) and a misplaced candidate results in wasted time, effort and resources, and the fact that the vacancy will need to be filled again. (requirement) Identify which recruiters provide candidates with the highest retention rate, (anticipated impact) to minimize the risk of new employees leaving.
3. Disruptions - Rate
   • Description: Number of process disruptions because of problems attributed to control hardware/software (data source is the productive process execution system)
   • Rate: weekly
   • Responsibilities: Product Owner provides the metric, team monitors the metric
   • Threshold: an average of less than 1 per month over the last 12 months
   • Purpose: (current situation) Process disruptions are costly, (requirement) so we need to ensure the number of process disruptions remains low.

Tips:

• Aim to define simple and specific metrics that you can measure frequently (and if appropriate, daily).
• Decide on and keep to a schedule of monitoring and assessing Key Metrics frequently. They are relevant criteria for evaluating outcomes and success in scheduled evaluations.
• Consider using a table format to visualize key metrics and the details relating to them.
• 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 of tolerance).
• Define thresholds and appropriate response for when a metric crosses that threshold.
• Consider metrics that enable you to measure the overall ability to meet due dates and project milestones, and keep information about actual project milestones or due dates in a backlog or project plan. If unavoidable due dates are already known or even contractually fixed, describe them in the section External Constraints, and if meeting them is likely to be challenging, describe those challenges in the section on Key Challenges.

Evaluation Schedule

When and how will you evaluate the effectiveness of the domain’s design and the success of the team (or role keeper) in fulfilling the domain’s purpose?

Regularly evaluate the outcomes resulting from activity in this domain, as well as the domain’s design, and use what you learn to improve the creation and delivery of value.

Describe a schedule (or frequency) for evaluating the success of the team (or role keeper) in fulfilling the domain’s purpose. Include information about the activity to be used (procedure, process, etc), and who should participate in which parts of the evaluation. Include any evaluation criteria in addition to the key metrics, as well as any other relevant aspects to keep in mind for the evaluation.

Consider using the following processes for evaluation:

• Peer Review (led by the delegatee(s), with input from the delegator and selected representatives from customers and dependencies)
• Retrospective

Recommended format: Frequency, Activity, Duration and Participants

Example (for a team):

• Weekly: Review the key metrics together in the beginning of the weekly team meeting
  • 10 minutes
  • Participants: team members
• Monthly retrospective
  • Up to 2 hours
  • Participants: team members, delegator, team coach (as facilitator)
• Quarterly Peer Review for delegatees to identify opportunities to improve strategy, domain design, learning requirements and efficacy of approach.
  • Up to 2 hours
  • Participants: delegator, team members, team coach, facilitator and selected representatives from customers and dependencies
• Quarterly: Review strategy (following the Peer Review)
  • Up to 4 hours
  • Participants: team members, delegator, facilitator
• Yearly: complete review of the domain design
  • Up to 3 hours
  • Participants: team members, delegator

Tips:

• Ensure to record and monitor when a domain is due review and add these dates to your logbook.
• Consider including a limited term of appointment for a role (after which a new selection is made).
• Ensure that people know to flag obvious or significant problems or opportunities for improvement of the domain’s design as they encounter them, not only in the evaluation.
• For newly designed domains, consider reviewing the design more frequently, to integrate learning and improve the domain’s design quickly.
• See below for more guidance on how to review a domain’s design

Additional Information

Consider 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)
• Delegatees (if they are known at the time)
• Date of latest update to the domain description
• Author Name(s)

How to review a domain’s design

When designing a process for evaluation, ensure you consider the following aspects:

• The effectiveness of the work of delegatees in fulfilling the purpose of the domain
• The value the delegatees brought to the organization by accounting for the domain.
• The team’s or role keeper’s work processes, and their collaboration with each other, with the delegator, and with the rest of the organization.
• The design of the domain itself (and potentially the design of other related domains). E.g.:
  • Completeness and specificity of the key metrics, to identify if new ones are useful to add, or if existing metrics should be dropped or changed.
  • The team members’ or role keeper’s competencies and skills in relation to the domain.
  • How well the delegator takes care of their responsibilities.
• The strategy the delegatees follow to fulfill the main requirement of the domain.
• Whether fulfilling each requirement detailed in the domain description leads to the impact and whether achieving this impact results in a positive outcome in relation to the driver it’s intended to address.