Deciding & Delegating
Deciding & Delegating

Deciding & Delegating

This page is a work in progress, part of a multi-year effort to capture and share learnings, frameworks, tools, and processes to run organizations. See Running Organizations for more.

Decision-Making

Deciding how decisions will be made is a critical consideration for running a successful operation. Decision-making practices say a lot about the nature of power and authority, and, ultimately the culture within an organization. Lack of alignment, poor internal communication, and disconnects between leadership and staff are often symptoms of a poor decision-making process.

Steps to Decide-How-to-Decide

There are three steps to designing decision-making: sorting decisions, using a decision-making framework, and creating principles for decision-makers.

Decide How to Sort Decisions

Get clear on what kinds of decisions will be made at what levels of the organization and who will be the directly responsible individuals (DRIs) in the common decision areas.

This process can be formal or informal and can be expressed as a visual or as a principle or set of operating principles.

Commit to a Decision-Making Framework

Adopting an organization-wide framework for the big decisions is the critical step in creating clarity, delegating decisions to the appropriate level, and building trust across the organization.

Create Principles for Decisions

Documenting the principles by which people should make decisions borrow from, but ultimately goes beyond the definitions of your core values.

Sorting Decisions

When the CEO is at the hub of all decision-making, a small organization can run smoothly without needing to address decision-making in any formal way. As new functional leaders are added, they take over responsibility for decisions in their functions, and the leadership team and CEO can make decisions that cut across functions or impact multiple departments. Once a middle management layer is added, decision-making becomes more complex.

Being clear with the entire management group about who makes what types of decisions gives clarity and autonomy to managers to move fast and make decisions with confidence.

Here are a few options for sorting and categorizing decisions.

Decision Tree Model

Susan Scott's "Decision Tree Model," from the book Fierce Conversations, categorizes four types of decisions and practices for each type. I've found this visual metaphor to be helpful for communicating with clarity, and a good training tool for new managers.

🔨
The Decision Tree
  • Leaf Decisions: Make the decision. Act on it. Do not report the action you took.
  • Branch Decisions: Make the decision. Act on it. Report the action you took daily, weekly, or monthly, as appropriate.
  • Trunk Decisions: Make the decision. Report your decision before you take action.
  • Root Decisions: Make the decision jointly, with input from many people. These are the decisions that, if poorly made and implemented, could cause major harm to the organization.

The goal is to categorize common decisions in the business and choose who the decider is for each. This model can be used at all levels, and doesn't have to be created from scratch by the leadership team - it can be a collaborative exercise with staff.

For Leaf and Branch-level decisions, staff members should be the deciders. Depending on your culture, Root Decisions can be made by staff, Leadership, or just the CEO.

The Eisenhower Matrix

The Eisenhower Matrix differentiates urgent and important in everyone's favorite model, the two-by-two. Gokul Rajaram used the Eisenhower Matrix at Square. They referred to the Not Important + Not Urgent quadrant as the "Kombucha scale" - as in, deciding about what kind of kombucha to buy for the office. He explains in this First Round article:

"Once you do a quick assessment of the importance of your choice and start using the decision-making framework over and over, something happens. You realize that making decisions doesn’t take days. It can be done in an hour or two. In that time, you can quickly make a high-quality choice with this framework." - Gokul Rajaram

The Eisenhower Matrix is a quick heuristic for leaders and managers rather than a formal tool for deciding who makes what types of decisions.

🧰
For a leader, the Matrix might look like:
  • Important + Urgent = Decide
  • Important + Not Urgent = Schedule OR Delegate
  • Not Important + Urgent = Delegate
  • Not Important + Not Urgent = Delete or Delegate

Type 1 & Type 2 Decisions

Jeff Bezos and Amazon sorted decisions into two types: Type 1 and Type 2 Decisions. A Type 2 decision is reversible, whereas Type 1 decisions are difficult and costly to roll back. Bezos explained in Amazon's 2015 Shareholder Letter that most decisions are Type 2, but we treat them like Type 1 decisions:

“Type 2 decisions can and should be made quickly by high judgment individuals or small groups. As organizations get larger, there seems to be a tendency to use the heavy-weight Type 1 decision-making process on most decisions, including many Type 2 decisions. The end result of this is slowness, unthoughtful risk aversion, failure to experiment sufficiently, and consequently diminished invention.” - Jeff Bezos

Finding a way to differentiate Type 1 from Type 2 decisions enables you to decide what kind of decision-making framework to use.

Type 1 Decisions might require a heavier process-oriented framework like SPADE or RAPID. Type 2 decisions might be better handled by RACI, DACI, or no formal process at all.

Decision Stack From Brave New Work

The "Decision Stack" from the book Brave New Work lays out five areas for determining decisions in an organization. I'm fond of defining roles and waterlines clearly and then leaning on an Advice Process and Consent Process.

A form of Advice and Consent is used in each of the three decision-making frameworks covered below. Laying out a doc or visual that explains Waterlines to everyone in the organization can provide an additional level of clarity.

🔨
The Decision Stack
  • Roles: What are the roles that we each hold? Think beyond job titles.
  • Waterlines. What decisions can any of us make without advice or permission?
  • Advice Process. When should we seek advice? define an advice process that will work in your culture and context. specify expectations for advice seekers and advice givers. generate a list of the kind of decisions you'd expect to see engaging the advice process.
  • Consent Process. What decisions should be made only by consent? Major changes to policy and structure are good places to start.
  • Rights by Role. What decisions should be made exclusively by one of our roles? Identify decisions that should be entrusted to specific roles with expertise, experience, or other qualifications. Map these decision rights to your roles in a format that will be accessible and editable.
  • Optimize. Can we make this simpler? Gather consent for the whole proposal.

Decision-Making Frameworks

SPADE

SPADE is a process used for big decisions (i.e. Type 1), and for the organizations that make a lot of them. SPADE works well for organizational and culture-shaping decisions, like strategy around new products/services, M&A, and key resourcing decisions.

SPADE is inefficient for decisions that impact few people (i.e. small organizations), for anything "non-Important" (Eisenhower Matrix), or for Leaf, Brand, or Trunk Decisions (Decision Tree).

The framework is covered in significant detail in Gokul Rajaram's toolkit.

🔨
The SPADE template
  • Setting
    • What: What is the decision to be made (be as precise as possible)?
    • Why: Why does this decision matter? Why are we making it?
    • When: By when does the decision need to get made?
  • People
    • Responsible: Should be responsible for the decision and the execution of the decision
    • Approver: Can veto the decision, but should be used sparingly
    • Consulted: Try to include as many people as possible; people like their voices to be heard!
  • Alternatives
    • Brainstorm openly and publicly to generate alternatives.
    • Note: Alternatives should be:
      • Feasible
      • Different from each other
      • Comprehensive: Maximally cover the problem space.
  • Decide
    • Everyone votes in private
    • Decision maker takes their inputs into consideration, as well as the pros and cons of each alternative, and then decide (+ explanation behind the decision)
  • Explain
    • Typically an email to the team / company linking to the S.P.A.D.E. doc
    • Would be great to link to a repository of other S.P.A.D.E.s

This process can built as a Google Docs template, but Gokul recommends using CODA when operating at scale, and logging all SPADE decisions in a template like this.

SPADE requires meeting time, perspective gathering, following a strict process and building commitment.

Another great resource explaining the detail of how to use this process is here.

RACI & DACI

RACI is a common framework found in many organizations. It defines Responsible, Accountable, Consulted, and Informed parties. The Responsible person is responsible for making the decision, the Accountable person is accountable for the implementation of the decision, the Consulted people have a say in the decision, and the Informed people are told about it once the decision has been made.

Here's an example of a RACI chart (Source: Monday):

image

Atlassian uses a framework they call DACI, which stands for Driver, Approver, Contributors, and Informed. One of the criticisms of RACI is the trouble in differentiating Responsible from Accountable. The Driver, in DACI, is both responsible and accountable in driving the decision and implementing it. The Approver has the final say and can veto the decision if it's not well thought through. Contributors and Informed parties are the same as in the RACI framework.

🔨
My summary of the DACI process (from Atlassian's article DACI Decision-Making Framework):
  • 1. Prep (15 min)
    • Start by creating a collaboration document, like a Trello board or Confluence page. Title it using the format “DACI: [Question we’re trying to answer]?’
    • Send the document to meeting attendees in advance to complete as much information as possible before the session.
  • 2. Set the stage (5 min)
    • Start the meeting by:
      • Recapping the decision that needs to be made and its impact on customers
      • Letting the team know that the goal of the session is to create a plan for getting all of the information needed to make the right decision
  • 3. Decide Who's The Driver (5 min)
    • Meeting attendees agree on a Driver. The Driver is responsible for making sure all stakeholders are aware of what’s happening, gathering information, getting questions answered and action items completed.
    • Write the Driver's name in the collaboration document.
  • 4. Decide Who's The Approver (5 min)
    • Assign an Approver. This is the one person who has the final say in approving the decision.
  • 5. Decide Who Are The Contributors (5 min)
    • Contributors are people who have knowledge that will inform the decision-making process
  • 6. Informed (5 min)
    • Name anyone affected by the decision who isn’t directly involved in making the decision. These are people and teams who may need to change their work as a result of the decision made and will need to know the outcome.
  • 7. Create a plan (30 min)
    • Consider all the information that will need to be collected to make the decision. Here a few things that may be useful to consider:
      • Due date – the deadline for making the decision.
      • Background – the reason this decision is required.
      • Supporting data – metrics to help support your decision.
      • Options considered – a brief explanation of each option for the decision, including feedback from a wide variety of sources grouped by theme, or a rating based on factors of importance for your project, such as scope, cost, and time.

Here's Atlassian's kanban template for the DACI process.

RAPID

The RAPID framework, created by Bain, is a great all-purpose framework, though it has some heft for small organizations. RAPID works for Root & Branch and Type 1 decisions. RAPID stands for: Recommend, Agree, Perform, Input, Decide.

  • Recommend a decision or action
  • Agree to a decision
  • Perform, once the decision has been made
  • Input collected from appropriate parties
  • Decide how to commit to action

Matt Mochary explains RAPID in The Great CEO Within.

🔨
My summary of Matt Mochary’s RAPID process
  • Someone, the "R" (Recommender) identifies an Issue and writes up:
    • The Issue
    • The Proposed Solution
    • A section on the page for each person needed to make and implement the decision
  • R sends the doc to all A's, P's and I's to get their input. Once feedback is given within the doc, the doc is reviewed by "D"
  • R schedules a Decision Meeting and invites A's, P's, I's and the D.
  • Decision Meeting: D reads through the document and asks questions as necessary. D decides OR asks for another round of feedback and decides at the next team meeting after reviewing that round of feedback.
  • D writes up the decision and communicates next actions, with relevant Directly Responsible Individuals and due dates. D publishes this to the whole organization.

The important parts of RAPID are a well-articulated definition of the problem, a proposal for a solution, and then seeking Input from others. Here's an example of RAPID.

Track past and present RAPID docs somewhere central, and be sure to separate those that are in progress from those that are completed/archived.

Delegation

Why We Need to Delegate

Delegation Empowers Others & Prevents Burnout

The better you perform, the more people expect from you. Jobs tend to expand in scope over time, which puts more pressure on high-performers and increases the risk of burnout over time. I've seen this happen to new managers and directors who have viewed their roles as one of "doers" instead of people who ensure the work is done.

The best tool to firefight this issue is to ensure that management delegates. Delegation firefights burnout in high performers, but it also empowers staff to stretch themselves, take responsibility for outcomes, and grow.

How to Create Delegators

Why We Don't Delegate

Delegation is unnatural. Pushing our problems, challenges, and tasks onto others doesn't feel right. It probably isn't what we think made us successful in individual contributor or manager roles in the past. The common objections to delegation sound like:

  • "I want to make sure it's done right."
  • "It's faster to do it myself."
  • "This task sucks. I'll protect them by doing it myself."

Behind the content of those statements is usually a message about how we identify at work - about what our roles are "supposed" to be about, and what we're "supposed" to be doing.

"Practical tips don't address the essence of why David, an exceptionally bright and motivated new leader, does not delegate. As he goes on to observe himself further, David (and we) learns just how central not delegating is to his self-image and self-esteem. He realizes that he gets enormous benefits from feeling 'important and valuable by doing individual tasks myself. It connects me to people. And I'm doing a kick-ass job. I feel good about being a star." (Source: Immunity to Change)

Individual contributors and high-output performers identify as "rockstars," "developers" or "marketers" - the type of people who don't push their work onto others.

Individual contributors can benefit from a view of themselves as part of a broader team who's accomplishing a specific mission or goal. Managers can benefit from viewing themselves as architects, organizers, or coaches.

"As an 'architect,' David now spends the majority of his time building the business, having redefined the "right" work as focusing on strategy, people, and resources." (Source: Immunity to Change)

Overcome All-or-Nothing Thinking

Delegation is not an all-or-nothing proposition. Delegation is not a matter of letting someone else do everything, or doing everything oneself. You can think about delegation in terms of “levels,” and ramp up or down the type and amount of work that is delegated depending on the expertise and experience of the people involved.

Designing Delegation

Detailing decision and task areas on a team-by-team basis gives people the confidence to make decisions, and avoids relationship damage and rework along the way. This can be done in a "team charter" or on a department-by-department basis.

Levels of Delegation

CEO Tools 2.0 breaks down five levels of delegation. When work can be broken down into clean Tasks, those tasks can be delegated depending on the skills and knowledge of the people around you.

🔨
Level 1—I do it all: I seek alternatives (task 1), evaluate options (task 2), make a choice (task 3), and execute the choice (task 4).
🔨
Level 2—I do the four Level 1 tasks while training someone else to be responsible for the decision in the future.
🔨
Level 3—The employee performs task 1; I perform tasks 2-4.
🔨
Level 4—The employee performs tasks 1-2 and makes a recommendation for task 3; I evaluate the task 3 recommendation and perform task 4.
🔨
Level 5—The employee performs tasks 1-4 and reports the results to me.

A Delegation Board

A Delegation Board is a visual way of representing what items will be delegated and which will not. This can give clarity to everyone on a team or in a department. Jurgen Appelo has a full explanation of the process here.

🔨
The Delegation Board
  • Fill out Rows for every area to be delegated
  • Fill out Columns for 7 different types of delegation:
    • 1) Tell
    • 2) Sell
    • 3) Consult
    • 4) Agree
    • 5) Advise
    • 6) Inquire
    • 7) Delegate

A completed delegation board looks like this:

image

This process can be used across an entire small organization, or within a single team in a large organization.

Delegating Tasks With 360 Delegation

When delegating specific tasks, a framework like 360 Delegation is fantastic for training Managers on how to delegate in a way that limits failure and re-work. The framework breaks down into Vision, Resources, and Definition of Done.

🔨
360 Delegation
  • Vision is expressed with a few bullet points answering questions like these:
    • What do you want done?
    • What’s your vision for completion? Is there an image/example you can use to show?
    • Why are we doing this?
    • When are we starting this task/project?
    • What are the milestones along the way?
    • What’s the ultimate, final, drop-dead deadline?
  • Resources is a list of resources the person might need. Things like:
    • Software/websites & passwords
    • Budget and credit card needed
    • Knowledge/expertise
    • Possible help from others
    • Relevant SOPs/checklists
    • Approvals/authority
  • Definition of Done tells the person what the finished product should look like. This might include:
    • Specifications of finished project; e.g.) image exported to JPG, 300 x 300 pixels
    • Sign-offs required from management or client
    • Storage of files after completion; e.g.) store both working file and exported files to Dropbox folder: Clients > ABC Corp > Graphic Design > Banner Ads
    • Double-check against related contracts
    • Quality-Assurance Checklists created/completed/checked
    • Important Dates highlighted
    • Schedule created