BUS603: Managing People

S3 promotes a hypothesis-driven approach to decision making.

Record Agreements

Record the details of agreements you make, so you can recall them later, evaluate the outcome and evolve the agreement over time.

An agreement is an agreed upon guideline, process, protocol or policy designed to guide the flow of value.

Note: In S3, guidelines, processes or protocols created by individuals in roles are also treated as agreements.

Keep records of agreements up to date, e.g. in a logbook.
What to record?

Record agreements with adequate detail so that important information can be recalled later.

At the very least include a summary of the driver, a description of what's been agreed, who is responsible for what, evaluation criteria and a review date.

Depending on the scope and significance of the agreement, consider including all of the following:

• A title for the agreement
• Description of the driver
• Date of creation (and/or version)
• Date of expiry or due date (if relevant)
• Review date (or frequency)
• Who is responsible for what?
• A description of the agreement, including:
• Any relevant requirements and expectations
• Action items
• Resources
• Constraints
• Intended outcomes
• Deliverables
• Rationale
• Evaluation criteria (and potentially concerns)
• Appendix (if helpful)
• Background information
• Previous versions of the agreements
• References
  

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.

Clarify and Develop Domains

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 defining 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
  

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

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 it's 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 critical indicators of progress. 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 reviews (see "Evaluation" below).

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

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

Evaluation

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

Describe when and how evaluations take place and who should be involved.

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 reviews.
• Additional helpful evaluation criteria in addition 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)

Clarify Intended Outcome

Be explicit about the expected results of agreements, activities, projects and strategies.

Agree on and record a concise description of the intended outcome.

The intended outcome can be used to define Evaluation Criteria and metrics for reviewing actual outcome.

Describe Deliverables

Clearly describe any deliverables related to an agreement to support shared understanding of expectations.

A deliverable is a product, service, component or material provided in response to an organizational driver.

When describing deliverables:

• include the necessary amount of detail
• reference other documents when helpful or necessary
  

Explicitly describing deliverables can be useful for improving communication and collaboration within the organization, with customer and with external partners.

Example: A popular way to describe deliverables in software-engineering are so-called user stories, which focus on the need of users in relation to a software system. User stories are developed in dialogue between a customer (or their representative, the product manager or "product owner"), and the software developer(s). What is written down is usually one sentence to remind the team of the user need, and acceptance criteria, a list of requirements for the new feature, which the customer will then use in a review meeting to decide whether or not they accept the new feature as delivered.

Evaluation Criteria

Develop well-defined evaluation criteria to determine if acting on an agreement had the desired effect.

• go for simple and unambiguous criteria and document them (to avoid discussion or unnecessary dialogue when reviewing your agreements)
• define actionable metrics to continuously track effects and spot deviations from intended outcome
• consider adding criteria which make it explicit when the outcome of an agreement would be considered unsuccessful
• when reviewing an agreement, consider evolving the evaluation criteria based on what you have learned

Logbook

Maintain a coherent and accessible system that stores all information required for collaboration.

A logbook is a (digital) system to store all information relevant for running an organization and its teams. The logbook is accessible to all members of an organization, and information is kept confidential only when there is good reason to do so.

Common platforms for logbooks are Wikis (e.g. DokuWiki, MediaWiki, Confluence), Content Management Systems (e.g. Wordpress), G Suite, Evernote or even Trello.

Logbook Contents

Content relating to the whole organization:

• primary driver, strategy and organizational values
• organizational structure (domains and the connections between them)
• agreements
  

Content relating to a specific team or role:

• the domain description and strategy
• agreements (including delegatees' domain descriptions, strategies and development plans)
• backlogs and other information relating to work and governance

Logbook Keeper

Select a member of your team to be specifically accountable for keeping up to date records of all information the team requires.

The logbook keeper is accountable for maintaining a team's logbook by:

• recording details of agreements, domain descriptions, selections, evaluation dates, minutes of meetings etc.
• organizing relevant information and improving the system when valuable
• keeping records up to date
• ensuring accessibility to everyone in the team (and in the wider organization as agreed)
• attending to all technical aspects of logbook keeping