In my introductory article discussing The Decision Tree model by Susan Scott, I explained how you can make decision structures in a complex environment more transparent and straightforward. But how does it work in practice? That is precisely what I'd like to talk about today using the development of our social intranet suit Linchpin as an example.

We are currently using The Decision Tree model in our Linchpin development universe. The question now is how we use this analogy to our advantage for Linchpin and what that means for our stakeholders and other interested parties.

Why use a model to make decisions?

The answer: To make decision-making in the Linchpin universe easier and create a clear visualization of responsibilities and supports. We are undergoing a transition towards becoming a product vendor, which requires different structures than a service provider. Additionally, continuous growth has made our work in the Linchpin universe increasingly complex.

There are several product owners working on Linchpin and 40 employees involved. Not all of them are familiar with all of the processes and methods used in our collaboration. Furthermore, as an overall solution, Linchpin is more than the sum of its individual apps. This results in a greater need for communication between the teams and stakeholders – so it's only going to get even more complex.

Our adaptation of the Decision Tree model aims to reduce this complexity and clearly communicate responsibilities.

Here is a theoretic overview of the concept. There are different decision levels, whose effects differ based on their gravity and importance:

• Decisions range from leaf decisions (minimal effect on the tree's "survival") to root decisions (essential for the tree's "survival").
• Different groups of people (boards) make decisions on different decision levels, and in some cases, other people or boards should be consulted.
• Additionally, as communication channels become more concrete, there are responsibilities to communicate such decisions.
• Details of the implementation and other concrete examples from our daily routine are added gradually, so that the model or the 'tree' can grow organically.

So let's take a look at how this works in a real, on-going project – in the Linchpin universe.

We have defined a total of six instances or groups of decision-makers for the Linchpin universe. They are:

• The current five Linchpin teams
• The product owners (POs) of the respective teams
• The new product board
• Technical lead
• Stakeholders
• Additionally, our scrum masters and agile coaches

Most of these groups should be self explanatory, but I would like at least to say a few words about the product board. The idea for this was born of out the experience that decisions that go beyond individual, functional components (that is, the Linchpin apps) often have an effect on the overall Linchpin solution. In the past, we were unable to process such decisions adequately or promptly. For this reason, we started by forming a product board.

The board is made up of representatives from different specialist groups within the Linchpin universe. So we have someone from tech, a team member from UX/design and another from  our customer/partner/consulting team. Another colleague looks at things from the perspective of product strategy, and a scrum master focuses on the overarching collaborative process.

I explain more about the role the product board will play in future Linchpin universe decisions below.

Sorting decisions by type

The table below represents our adaptation of the Decision Tree model in its most current form. Firstly, we distinguish between the four decision categories – leaf, branch, trunk, and root. Based on this, we then analyze who is responsible for a decision, who makes the decision and who should be consulted on a decision.

When it comes to the responsibility for a decision, it's about who assumes any subsequent communication and acts as the contact person for the topic. This should only ever be one person or group. The decision itself can be made by several boards collaboratively.

Communicating decisions

Did you look closely? 😉 Then you might have noticed that something is missing from the table: who communicates the decisions. Communicating which decisions have been made and how they have been made in a transparent way is a necessary step to reduce complexity.

We have created a specially-designed internal review just for this purpose. It shows in which group or in which of our established meetings a decision should be communicated, who is the target audience and who holds the responsibility within the respective platform. These regular meetings include our so-called weeklies, which we have for product owners, UX specialists, developers and scrum masters, the Linchpin jour fixe, the roadmap meeting, the portfolio meeting, and the product marketing monthly.

Of course, the plethora of decisions that come up cannot always be assigned to any specific category or platform. But the process described should help to reduce complexity for the majority of decisions.

The DACI framework as a blueprint

Now, the question is how does the model work in practice. Whereby the next question follows swiftly: How do you decide which category a decision belongs to? First of all, we looked at decisions made over the past few months (such as the examples in the table above). We can now use the examples to orient ourselves in the future or – if that is not possible or entirely clear – take it to the product board.

To help, we have introduced a so-called DACI framework, which includes a list of all the decisions that are currently waiting to be made. What does DACI stand for?

• D = Driver (a person with responsibility for the implementation). This person is responsible for getting those responsible on board, bringing together all the necessary information and reaching a final decision by an agreed deadline. This could be the project manager or someone else, depending on the decision at hand.
• A = Approver (a person who approves decisions). This person ultimately makes the decision.
• C = Contributors. These people have knowledge or experience that is relevant to the decision. They can express their opinion but don't have "voting rights."
• I = Informed (recipient of information). These people are informed about final decisions.

We have taken the current terminology from the Atlassian Team Playbook, but we may customize it in the future for our own internal use.

Firstly, we (the product board) determine the decision category. Then we allocate roles as necessary based on the DACI framework.

Looking forward

To summarize, in the Linchpin universe our approach points to us using a decision-making process in the future that is based on a two-part procedure:

1. Has this type of decision been made before in the same or a similar way? Then, I'll use the process used last time as a guide.
2. Has a decision like this never made before, or are there differences in opinion? Then pass it on to the product board, where they can determine who should make and communicate the decision based on the DACI framework.

Ultimately, this is a kind of advisory group or custom decision-making process whereby it is obligatory to consult stakeholders and communicate transparently. This way of making decisions has emerged in our team over the past few years and proved to have a very positive impact in many areas.

In light of this, the adapted Decision Tree model is an even better way of visualizing the boundaries of decision-making freedoms to reduce complexity in our everyday work, as well as avoid unnecessary meetings. In the future, the challenge will be to anchor this model within the teams, making it a natural process, and continually assessing whether we really are making faster and (hopefully) better decisions than we used to.

Lesen Sie diese Seite auf Deutsch

Further information

Agile organization at //SEIBERT/MEDIA – from brainstorming to realization
Scrum meetings: Goals, team activities, and customer benefits
The differences between Scrum and Agile