BUS603: Managing People

Clarify and Develop Domains

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

A clear understanding of people's area of responsibility and autonomy enables greater efficiency, effective collaboration, and agility throughout an organization.

To make better use of their limited time, energy, and resources, people in organizations distribute work between them by creating roles or forming teams, units, or departments. In the process they are explicitly or implicitly designing domains - distinct areas of responsibility and autonomy.

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

Clarifying domains makes the contract between delegator and delegatee(s) explicit, which enables everyone to learn about what works and what doesn't, because everyone understands who is responsible for what. A clear domain description with a reasonable amount of detail is a necessary prerequisite for people to successfully evaluate and continuously improve their work.

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

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

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

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

The delegatee(s) may do whatever they think will help them achieve their purpose, unless it is outside the domain of the organization, explicitly forbidden, they violate somebody else's (explicit) domain, or impede other people's contribution to the organization in some other way. Things that are forbidden may include explicit constraints laid out in the domain description, any other agreements the delegatee(s) needs to keep, or legal and regulatory requirements.

When to clarify domains

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

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

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

Regularly evaluate and evolve domains

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

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

Clarify the domain of the whole organization

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

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

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

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

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

Useful aspects to clarify in a domain description

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

Primary Driver

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

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

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

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

Key Responsibilities

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

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

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

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

Dependencies

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

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

External Constraints

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

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

Some examples:

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

Key Challenges

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

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

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

Key Deliverables

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

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

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

Competencies, qualities and skills

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

Key Resources

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

Delegator Responsibilities

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

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

Consider:

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

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

Key Metrics

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

Key Metrics are monitored and assessed frequently. They are relevant criteria for evaluating outcomes and success in scheduled evaluations.

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

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

Monitoring and Evaluation

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

In the evaluation, ensure you consider the following aspects:

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

Define:

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

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

Additional Information

Consider also including the following information to the domain description

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

Delegate Influence

Distribute the power to influence, to enable people to decide and act for themselves within defined constraints.

A delegator can support delegatees to deliver value by:

• Clearly defining domains of autonomy and responsibility
• Ensuring there are opportunities for learning and development
• Providing support if required
  

Adjust constraints incrementally, considering capabilities, reliability and outcome.

Decentralize as much as possible, and retain as much influence as necessary.

Clarify and Develop Strategy

A strategy is a high level approach for how people will create value to successfully account for a domain.

It is usually more effective if a team or role keeper lead in developing their own strategy.

A strategy often includes a description of the intended outcome of implementing that strategy.

As the delegator shares accountability for domains they delegate, it's valuable they review a delegatee's strategy, to check for potential impediments and suggest ways it could be improved.

A strategy is a shared agreement between delegator(s) and delegatee(s) that is regularly reviewed and updated as necessary (pivot or persevere)

Strategies are validated and refined through experimentation and learning.

Align Flow

In support of continuous flow of value, move decision-making close to where value is created, and align the flow of information accordingly.

Flow of value: Deliverables traveling through an organization towards customers or other stakeholders.

Achieve and maintain alignment of flow through the continuous evolution of an organization's body of agreements:

• ensure all decisions affecting the flow of value actually support the flow of value
• enable people with relevant skills and knowledge to influence decisions
• make available any helpful information
• aim for shorter feedback loops to amplify learning.
  

When decision-making is conducted close to where value is created, and the flow of information supports the continuous and steady flow of value, the potential for accumulation of waste is reduced.

Create a Pull-System For Organizational Change

Create an environment that invites and enables members of the organization to drive change.

Change things when there is value in doing so:

• Bring in patterns that help to solve current and important problems.
• Don't break what's already working!
• Meet everyone where they are …
• … and support everyone to make necessary changes at a manageable pace.

Driver Mapping

A workshop format for large groups to co-create and organize themselves in response to a complex situation of significant scope and scale.

You can use Driver Mapping to:

• organize start-ups,
• kick-off projects,
• tackle major impediments or opportunities,
• implement strategy
• develop organizational structure to better enable the flow of value.

The outcome of a driver mapping workshop is typically:

• a distribution of work, categorized in a number of domains, centered around the needs of stakeholders.
• a bespoke organizational structure that brings it all together, including interlinking domains for managing dependencies.
• a first draft of prioritized governance and operations backlogs for each identified subdomain.
• delegation of influence and the distribution of people to the subdomains through self-selection and nomination.
  

Although Driver Mapping is often used for identifying and defining new domains, there are also applications for identifying and distributing governance and operational drivers among existing domains in an organization, e.g. when an initiative will be dealt with by existing teams in an organization, or if a group feels they're stuck in their current structure and are looking for inspiration for how to incrementally adapt it. The group can decide if they would map to existing domains and figure out which new ones they'd need to create, or even create a new structure from scratch.
In a small team or circle (max. 6-8 people), when it's not a priority to distribute work, the team might only use steps 1-5, to understand the scope and fill the operations and governance backlog, and then use proposal forming or some other approach for identifying strategy and/or next steps.
In preparation:

• Invite people that can make a relevant contribution to this project. Send out the agenda for the workshop ahead of time.
• Send out the primary you'll work with, and in case of an existing domain, the domain description for the project/initiative in advance so people can familiarize themselves with it. Aim to resolve any objections before the workshop.
• Attendees may already prepare by thinking through and recording ideas of actors and relating needs.
• Prepare a poster with the domain description to present in the first step. You will also need A5 and rectangular sticky notes, pens and a wide wall to work.
  

The Driver Mapping Process:

These are the steps to follow:

1. Why are we here?

Present and consent to the primary driver

• Present the primary driver to the group
• Consent to the driver – Is this a clear enough description of the driver? Is it relevant for us to respond to?
• Clarify any existing constraints from the delegator, e.g. budget, due date, expectations, etc. In the case of an existing domain, present the domain description.Invite further questions that help deepen understanding about what's happening and what's needed.
• Make explicit the level of commitment expected from the participants. E.g. people are expected to be here for the duration of the workshop only, or for the duration of the initiative, etc.
• Record any relevant information that comes up.
  

2. Who will be impacted?

Who will be impacted as we respond to the primary driver? Consider who can help / stand in the way / benefit / lose or be harmed.

• List actors on sticky notes and display them on a board
• Focus on actual people that will be impacted by this initiative (groups or individuals), and avoid making assumptions about future roles (such as Project Manager) or other domains (e.g. Marketing) at this stage.
  

3. What is needed?

Consider the various actors and describe what is needed: what do they need in context of the primary driver, and what do we need from them?

• Write each suggestion on a separate sticky note (need card)
• Describe the need as well as the anticipated impact of responding to that need
• Use the format "We/they need … so that …"
• Add the name of the actor in the top left corner of the card
• Add your name in the top right corner of the card

4. Identify experience and expertise

Identify who has experience or expertise in responding to these needs, so that later, when people respond to a specific need, they know who might have valuable input.

• Take time to familiarize yourself with the various need cards.
• Add your name to those need cards you have experience with, or ideas how to address, so that later in the process people can consult with you if helpful.
• Consider adding names of people who are not present if you think they would have a valuable contribution to make.
• Write the name(s) of these people at the bottom of the need card.
• Adding your name to a card in this step, doesn't mean you're taking responsibility for the need, only that you're able and willing to contribute to finding a solution if that's helpful later.
  

5. Identify Domains

Cluster actors and/or needs according to relevance, into coherent domains as a starting point to sorting and prioritizing needs. Consider how to optimize end-to-end delivery of value to the various actors that you identified in step 2.
Ways to identify domains:

• Cluster groups of similar actors (actor-centric)
• Cluster groups of similar needs (needs-centric)
• A combination of both (of the above) is common

Consider this step complete, as soon as you've agreed on a first iteration of a meaningful distribution of work. Remember, you can make changes to the domains you defined at any time (later during the workshop or afterward), so you only need to aim for something that's good enough to start.
As a facilitator, gently support the group in self-organizing, and be mindful of people dropping out of the conversation. This process often includes a phase that appears chaotic to some participants, which might make them feel uncomfortable. To test if a result is achieved, ask for objections to the domains being good enough for now.

7. Refine the Backlogs

Organize the work that lies ahead in each domain, ensure things are prioritized and described clearly.

• For each domain, copy the template below to a flip chart
• Sort all remaining needs into the two backlogs on the flip chart:
• operations backlog: needs that can be acted
• governance backlog: needs that would benefit from or necessitate a decision
• Combine and rephrase cards as necessary, so that description on each card is clear. Consult the author of the card when in doubt.
• Prioritize the cards in each board.
• Archive any "needs" cards that appear superfluous.
• Consider the domain and describe and prioritize other needs that may not have been identified.
• Pass on cards that appear to be the accountability of another domain to address.
• Add cards concerning multiple domains to a dedicated backlog to address later.
  

_As a facilitator of the driver mapping process, provide a space to collect cards concerning multiple domains so that they can be addressed later. _
Regularly pause to share reports between the various domains. Note: Some domains might dissolve, change or merge with others.

8. Connect Domains

Create structure to manage dependencies and deal with matters that extend beyond the scope of one domain or concern the wider organization

• For a new organization or project, consider Delegate Circles, Service Circles or Double-linking between domains.
• For an existing organization, also consider connecting to existing domains in the organization.
  

9. What else?

Take a moment to check if anything's missing.
What else do we need to consider…

• …to run safely?
• …to address the primary driver?

10. Celebrate!

Take a moment to celebrate your achievements in getting your organization or initiative started!

Open Systems

Intentionally communicate with and learn from others outside of your system.

Individuals, teams and entire organizations can acknowledge interdependence and intentionally invite people from outside their system to bring in knowledge, experience and influence to assist with decision-making and support collective learning.

• External experts can offer an outside perspective and bring knowledge, understanding and skills
• Representatives of affected parties can inform and influence decision-making in ways that benefit overall objectives