Explicitly clarify, and then regularly evaluate and develop the design of domains throughout the organization, based on learning, to enable those with responsibility for each domain to deliver value as effectively as possible to the customers they serve.

Table of Contents

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 it 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 to support stakeholders in developing a 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 attend to 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 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.

Visit the section about distributing governance throughout the organization for more guidance on how to do that in an effective way.

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, and which are dependent on (or might benefit from) 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 by 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 which 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 understandings 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.

Template for a domain description
Template for a domain description

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 conditions, the (anticipated or current) effect these conditions lead to, 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 the intended outcome of addressing the driver, as well as the enabling conditions that will lead to achieving that outcome.

Examples:

  1. Purpose of a Team Support domain:

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

    Main Requirement: We need to support teams to develop and maintain a coherent approach to how they collaborate on dependencies 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: 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, 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: 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, 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 responds 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 consider 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.

List all essential responsibilities that are being delegated by clarifying the requirement in each case.

Recommended format: Describe Key Responsibilities as requirements, if useful, include a description of the driver as well.

Examples:

  1. For a customer service team

    Requirement: Ensure that customer inquiries are responded to in a timely manner, so that we stay within the time frame stipulated in our service level agreement.

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

  2. For an agile coaching domain:

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

    Driver: Our product development process involves multiple interdependent teams, where lack of coordination can lead to bottlenecks and project delays, 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: Develop and deliver bespoke learning interventions to fulfill customer learning needs.

    Driver: Our customers operate in a dynamic business environment where employee skills and knowledge requirements are constantly evolving, which leads to critical gaps in workforce capabilities and adaptability, 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: Execute and refine digital marketing campaigns, to improve engagement metrics and customer acquisition costs.

    Driver: With digital ad spending increasing without proportional gains in engagement, 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 intended outcome(s) of fulfilling each requirement in a way that allows you to define specific metrics to assess whether or not an outcome 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

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

The purpose of the 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 the organization who are dependent on these deliverables to do their work.

Deliverables are the products, services, components, and materials that delegatees deliver in the context of fulfilling 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), include a description of the requirement unless it’s already clear.

Examples:

  1. For a marketing department:

    Customer: Current and potential customers

    Deliverable: Regularly updated content such as blog posts, newsletters, and social media updates to inform the customer base about the latest company news, product developments, and industry insights, to strengthen brand loyalty and attract potential customers.

  2. For the delegator of a marketing department:

    Customer: Executive leadership

    Deliverable: Marketing performance analytics reports that measure campaign effectiveness, customer engagement, and ROI, 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 that can be used as a reference for future sales 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 company websites that ensure a positive user experience and that the client’s customers engage with 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, to facilitate the development team in efficiently building and implementing features that offer an optimal user experience, 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 attend to 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), include a description of the requirement if it is not apparent.

Examples:

  1. For a sales team:

    Provider: Legal team

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

  2. For a support team:

    Provider: Development team

    Deliverable: help from developers for technical assistance and resolution of complex issues, (intended outcome(s)) 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 to support the development of innovative and user-centric design solutions, 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 that ensure seamless integration and functionality of online learning platforms, 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, to enable thorough experimentation and innovation, crucial for 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: Describe constraints as requirements, if useful, describe the driver to add context.

Examples:

  1. Constraint: Ensure that we have clearance from the provider for training external consultants, so that we get the reduced rate for training.

    Driver: 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: Prioritize work on projects with deadlines over time spent on training and development, so that we can keep to delivery dates agreed upon with customers.

    (Driver is obvious in this case)

  3. Constraint: Monthly expenditure over $15k needs to be approved with the PM to ensure total expenditure for the project remains within the overall budget.

    (Driver is obvious in this case)

  4. Constraint: Consult with the Architecture Circle on decisions related to software architecture, to ensure architectural coherence throughout all software products.

    (Driver is obvious in this case)

  5. Constraint: Schedule all hands meetings between 15:00 — 18:00 CEST, so that team members from the various time zones can work during typical working hours.

    (Driver is obvious in this case)

  6. Constraint: For projects larger than 3 person months, the team needs to have their project plan approved by the delegator, so that they can bring in their project management experience.

    Driver: the team does not currently feel confident managing large projects alone.

  7. Constraint: Deliver the finished product to the integration team by 01 Feb so that they have time to complete integration before the non-negotiable project deadline on 10 March.

    (Driver is obvious in this case)

Tips:

  • For each constraint, clarify the requirement, and add further 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 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 them).

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 attend to 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 attend to this domain.

Examples:

  1. Changing legal requirements that need to be included in our software are often only announced a few weeks before taking effect, which can make it difficult to respond to the changes in time.
  2. Due to differing priorities, partners are sometimes unavailable when we need their services, making it difficult to meet project deadlines.
  3. Our codebase is old, incoherent, and poorly maintained, and we lack the funds to clean up the code. Therefore, it’s hard to estimate how long adding a new feature will take, and changes can lead to bugs and security issues.
  4. Customer purchases are highly weather-dependent, which makes it difficult to optimize perishable stock and staffing.
  5. We’re threatened by an economic crisis, which could significantly impact our ability to meet our sales target.
  6. Some team members have their main responsibilities in other domains, which can sometimes make it difficult for them to free up enough time for work in this domain.
  7. Due to cultural differences, there is a diversity of norms and expectations across the different teams, 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. “continuously 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 the customer
  8. Access to all machines, instruments, and test rigs whenever not in use
  9. Access to the research facility from 8:00-18:00, weekdays
  10. By-weekly mentoring session with an external marketing expert
  11. Account with a 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 attend to 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: Describe Delegator Responsibilities as requirements, if useful describe the driver as well.

Examples:

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

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

  2. Requirement: Ensure that questions delegatees have throughout the project are answered within 24 hours to avoid bottlenecks while waiting for a reply.

  3. 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: Participate in scheduled Peer Review sessions with delegatees, to support them with ongoing development and maintain high standards.

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

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

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

    Driver: Delegatees often face challenges in having their perspectives and needs understood and prioritized by top-level management, 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 attend to 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, and in a way that allows you to define specific metrics to assess whether or not that requirement has been fulfilled, 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 attend to 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 attend to 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 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 of experience 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’s 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, Baseline, Target and Triggers. Include Purpose if helpful. See Define and Monitor Metrics for more guidance on metrics.

Examples:

  1. Interviewed candidates per hire
    • Description: The ratio of candidates hired to candidates interviewed, measured for each 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
    • Target: 10
    • Triggers: 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 stays above that threshold for at least 3 months, whether that partner or channel should be kept.
    • Purpose: Identify which recruiters and channels 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
    • Triggers: 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: Onboarding new people carries a high cost and a misplaced candidate results in wasted time, effort, and resources, and the fact that the vacancy will need to be filled again. Identify which recruiters provide candidates with the highest retention rate, to minimize the risk of new employees leaving.
  3. Disruption-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
    • Triggers: an average of less than 1 per month over the last 12 months
    • Purpose: Process disruptions are costly, 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 an 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 strategy review (following the Peer Review)
    • Up to 4 hours
    • Participants: team members, delegator, facilitator
  • Yearly review of domain design
    • Up to 3 hours
    • Participants: team members, delegator

Tips:

  • Ensure to record and monitor when a domain is due for 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 in 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 the 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.
  • The suitability of each requirement detailed in the domain description for addressing its related driver.