Directly Responsible Individual vs Single Threaded Leader

Reflection on the DRI model vs STL model on projects.

TL;DR — the STL model is a great framework to scale decision making across organization and help the leaders focus. In comparison, DRI only ensures a problem has a decider, but it doesn’t speed up decision making or ensure a high quality decision.

The velocity & quality of decision making usually defines the scale & success of an organiztion. Organizations explore ways to optimize efficiency in the decision making chain.

Personally I have seen a few ways:

RAPIDS

RAPIDS is short for Recommend, Approve, Perform, Inform, and Decide. Each role is responsible for one of the functions: R recommends the solution; A is the individuals who must agree with the recommendation, P is the team/individuals to perform the action, I refers to folks who need to beaware of the change, last and the most important one is D, who ultimate decides on the next step. RAPIDS usually comes with a time constraints, it is 5 days for us. Whenever there is disagreement between teams, we require the R & D to make decisions within 5 days.

This approach is a fairly reactive process to address disagreements across organizations. When a project is incubated, there is no designated D for this project in case of disagreements. Then when disagreement emerges, the teams need to find a list of individuals to make a decision — those individuals might not have the necessary context or bandwidth to make quality decisions, since they have not been deeply engaged with the project.

In the end, I observed most of the decisions could not conclude within 5 days since the D in the framework didn’t have enough context or bandwidth to make a call. This oftens ends in either hasty decisions or deadlock.

DRI

DRI is short for Directly Responsible Individual — a person that is responsible for making the decision for an initiative. Compared with a reactive process like RAPIDS to address disagreement, setting DRI upfront for an initiative facilitates the decision making process as the person who was established at the beginning can make a call. This is a powerful framework to eliminate unnecesary escalations…until it is not correctly executed.

The scenarios I saw this going wrong are:

1. Multi-threaded DRI. The DRI is responsible for multiple top initiatives. Proactive leaders tend to wear multiple hats and being the DRI for multiple initiatives, and have very limited bandwidth for any individual initiative. The leader can still work hard to digest all the details of all the initiatives, but it is impossible for them to provide insightful long term vision for every initiative.
2. DRI of yourself. The DRI is responsible for projects in their own org. Another problem I observed is that sometimes we announce a DRI that is responsible for a project inside their own org. For example, a leader X is already managing the org Y, and if we assign the X to the be the DRI for a project that is fully contained to the org Y, it doesn’t create any addition value — X already manages the org, there is no value to reiterate that person owns the decision of their orgs.

STL

STL is short for Single Threaded Leader. Different from previous approach, this makes clear tradeoff:

It makes the leader exclusively dedicated to a project. The individual ONLY works on this single top level initiative. Note this doesn’t prevent this leader from performing daily work leading/coordinating their organizations. But this person is only responsible for a single top level initiatives.

STL usually (if not all cases) doesn’t have the authority over all the resources required to deliver the initiative. The leader has to coordinate with multiple organization, and reach consensus with other leaders. Since the leader is solely focused on this project, in most corporations, the person would have the most context and knowledge (both technical and organizational) to push things through. Pushing a top level initiative forward is a full time job for any leader.

How to build the muscle of STL inside an org?

1. The org needs to have a culture to focus and strive for do fewer things better.
2. It is generally better to have leaders to be the STL of projects that the scope is their level +1. For example, we are building a platform for GAI across training & serving inside the AI Platform organization. You don’t want the leader of the AI Platform to be the STL here, you get either the leader of the training or serving org to be the STL here. This scales up and grows the organizations.