Decision fatigue is real. On a personal as well as corporate level. When working with leadership teams, we often realize that taking decisions can stretch out over multiple weeks, if not months. Topics get re-discussed repeatedly and a lack of ownership or skill for preparing a decision basis that is substantial enough leads to more waiting time to reach a decision. Frustration starts to build up on the team and their delegates. Initiatives and projects slow down or get stuck. The lack of transparency on where the decision is stuck is comparable to a production site waiting for a supply item to arrive.

I felt that being the agile coach of a multi-workstream development team. After a couple of months, the team itself had figured out a good handle around working with their tasks and issues, but the leadership team of the big transformational program struggled to make small and big decisions because of the sheer amount of them. Awaiting decisions kept the team from progressing and we had to find a way to help the leadership team decide.

To address the issue, we implemented a simple looking tool – the leadership decision board. As a KANBAN board with specifically designed swim lanes and a set of working principles it fits perfectly into an organization that is in the process of transforming or already applying agile practices, frameworks, and mindsets. OKR, Lean Portfolio, SAFE; Large Scale Scrum, Scrum and -name-another-agile-method are suggesting the use of KANBAN. Whilst it appears to be simple, let’s highlight a few principles and pitfalls using KANBAN as a leadership team decision board.

What makes this different from a normal KANBAN used to track actions?

KANBAN is commonly known as the Japanese tool to visualize, optimize and unblock workflow in production areas. It can also be applied to management, by visualizing one of the key areas in their responsibility and putting it at the center of attention: decisions. As with all KANBAN board the devil is in the detail of the purpose it is used for, and the work principles applied to it.

To emphasize, the board is used to foster decision making. This means the central element should be the “decision” and the expected result or business outcome. That will shape the nature of every item as well as the formulation. In this board we track progress on the decision, NOT the execution of the decision. This enables the team to focus on leadership topics amidst the buzz of operational work.

For example, the following decisions could be part of the decision board:

1. Proceed to expand production of Product X in country Z
2. Unblock development of Software Product A by deciding a Service Vendor for A
3. Establish Chief Operating Officer Role for country U
4. Revise employee bonus system based on feedback and to include new KPIs
5. Buy Artificial Intelligence capability from Startup O to extend service portfolio

As you recognize, these decisions have a big strategic impact and should therefore be in focus of the team when it comes to long-term success of the company.

More tactical items derived from the employees or product teams directly will also fill the backlog of the team and will take up space and mental capacity. It is crucial to track all decisions in this board, from strategic to tactical. There is a tendency to forget and input those decisions and become oblivious to real work- or in this case “decision” load. The team needs to decide when to “let go” of the specific decision and hence stop tracking it.

Below you see a sketch of the Leadership Decision Board. The proposed swim lanes are designed for the decision-making process. Whilst not fixed in stone, we suggest to use those for a couple of months before adapting to your needs.

Kanban Swimlanes

Before diving into the swim lanes, it is important to point out that item granularity Item granularity depends on the nature of the board’s user community. For leadership decisions, the flight level is typically higher than your usual project level, which is why the yellow stickies in your leadership team board are resembling „Epics“ or „Themes“ in Agile Terms. We call them „Decision Cards“.

A decision card may look like this:

Decision Card

You may recognize similarities to the Epic Hypothesis template in SAFe. This is on purpose and gives you the opportunity to integrate it into the framework.

As we know from experience, creating too many entry fields in advance can hinder innovation and keeping track of all items. See the suggested fields as a suggestion, not a must, as we have been asked to point out in customer workshops. Most important is that you capture the item for transparency.

Let’s look at the structure of the swim lanes:

1. INBOX: Every item relevant and resulting in a decision needs to land in the inbox. This can be opportunities, threats from outside as well as ideas and suggestions from within the company. It is possible to align this with an idea management process and filter only selected items relevant for this specific leadership team.
2. ASSIGN DRIVER/OWNER: The team pulls an item and defines a driver within the leadership team preparing the decision. Some teams prefer the word “owner,” but in a few organizations this is associated to passive sponsorship. The person assigned needs to actively drive the whole process until the decision has been made.
3. PREPARE DECISION: In this lane the driver aims to create a decision basis for the leadership team which she attaches to the item before she moves it into the decide column. The aim is not to make a picture-perfect business plan or project statement but to get all the information needed to take the decision or revert to collect more information or advise.
4. DECIDE: The team sits together and takes a decision on how to move forward with this item.
5. DOING: The leadership team decides to do the decision and how to monitor the respective implementation plan with the owners of the execution. The column can be organized with a review date to filter out elements and enable the team to focus on where to monitor next. This is only relevant for items the team wants to keep track of. They can decide that the decision is “done” by moving it to the other column.
6. NOT DOING: There is an option not “to-do” or to open another decision. This list and its archived item serve as a decision log for the team.
7. DONE: The decision is made, no further tracking required.

Principles to make the leadership team board work

Besides the strict focus around the question “On this item, which decision is required by us?” the principles applied to KANBAN are extended to this leadership board:

1. Pull-principle: Decision Cards must be pulled by the team and individual team members. Even the inbox and ideas which might be brought proactively are pulled by the leadership team. Not accepting the idea into the inbox is like deciding not to do it and requires communication to the “ideator”.
2. Limit the Work-in-Progress (WIP): The team must decide their capacity for each swim lane and define how much “decisions in progress” they can take on with their current workload. Usually, the WIP limits are most effective on the Prepare Decision and Review swim lane.
3. Define your priorities: Regularly order the items by highest priority for the company. That doesn’t mean other decisions, like low hanging fruits, should not be made because otherwise parts of the company become stuck.
4. Show dependencies: The most underrated value of the Kanban is to show dependencies between your decisions.
5. Stop starting, start finishing: A very simple yet powerful agile principle. Apply it especially in the decision context, where mind-power is limited and re-iterating old items can be draining.

Principles unique to the leadership team board:

1. The initiator or “ideator” is not the driver: Just because someone is raising an idea or improvement, they don’t automatically become the driver. Otherwise, this may result in less ideas brought forward.
2. Strategical/Tactical/Operational decision balance: It would be illusional to think that the leadership team can only focus on high-value strategic topics. It is relevant for them to act in all areas to help the flow of the company. Like agile product backlogs we suggest the team defines a percentage and time allocation of the “In Review” items (could be 60% strategic, 30% tactical, 10% unblock and emergencies).

This should give you a decent overview of the tool. We hope can benefit from it and apply this to your team.