Tag: Radical Delegation

In Progressive Delivery we use the term “Radical Delegation” to describe one of its core tenets. In the spirit of enabling folks to successfully engage in this practice, we need to provide a clear definition and a process, or framework, for implementation, assessment, and improvement.

Origin

In the early iterations of Progressive Delivery we just used the word delegation. It was not until hearing Admiral John Richardson speak* at the DevOps Enterprise Summit we decided to improve the term to radical delegation. Progressive delivery is not about passing the buck. The primary motivation for this change was the frequent challenge with leaders conflating the word delegation with abdication. By adding ‘radical’ to the term, we were able to garner greater attention from practitioners. People stopped assuming they already understood delegation and took the time to learn explicitly what we were articulating.

Definitions

delegation

del·​e·​ga·​tion | \ ˌde-li-ˈgā-shən \

abdication

ab·​di·​ca·​tion | \ ˌab-di-ˈkā-shən \

The key distinction being the ability for a person that is responsible to successfully enable another person to have authority to accomplish a task, while recognizing that transferring authority does not equate to the transfer of responsibility. Admiral Richardson spoke about radical delegation in the context of the Navy by quoting the US Navy Regulations:

“The responsibility of the Commanding Officer for his or her command is absolute, except when, and to the extent to which, he or she has been relieved therefrom by competent authority, or as provided otherwise in these regulations. The authority of the Commanding Officer is commensurate with his or her responsibility. While the Commanding Officer may, at his or her discretion, and when not contrary to law or regulations, delegate authority to subordinates for the execution of details, such delegation of authority shall in no way relieve the commanding officer of continued responsibility for the safety, well-being and efficiency of the entire command.” 

— US Navy Regulations 1990 (Paragraph 0802)

Radical Delegation

Radical delegation encapsulates both the task and the owner of the authority for the outcome. An important distinction is that this does not transfer the responsibility for the outcome. The separation of authority and responsibility provides greater accountability and control. This separation is increasingly important as the authority is shifted closer and closer to the end user. 

Two examples:

Ships at sea— In the context of the Navy, radical delegation allowed a Commander to delegate an objective to a Captain, eg. meet at these coordinates at this time. The authority on the ship belongs with the Captain, but the responsibility for the ship’s arrival still resides with the Commander. 

Feature Foo — In the context of software delivery, radical delegation allows a Customer Success manager to turn on a new feature for a specific customer when the customer is ready. The authority to determine readiness belongs to the resource that is closest to the customer, but the responsibility for the feature working still resides with the engineers who build it and the operators that support the service.

In both cases the delegation not only includes the ‘task’ but an explicit identification of the individual with authority. Both of these aspects are required for Radical Delegation.

Progressive Delivery 

The two core tenets of Progressive Delivery are:

• Release progression — progressively increasing the number of users that are able to see (and are impacted by) new features
• Radical delegation — progressively delegating the control of access to a feature to the owner that is closest to the outcome

To gain the benefits of this new software delivery model we need to define the stages of software availability (which user can see which features and when) and the owner (who can make the changes to the system providing the desired experience for the user) of the progression from one stage to the next. 

Radical delegation is a framework for defining:

• The owner of control
• The feature/component to be controlled (or task to be accomplished)
• The constraints or limits of the control

Tossing things over the fence, is an anti-pattern. Following DevOps principle of clear ownership and well communicated handoffs is the goal.

At the same time, having the responsibility remain with the developers who built the feature and the operations team that runs the infrastructure encourages shared investment in the outcome for the user.

*Resources:

Leadership Development and Balancing Creativity and Control with Admiral John Richardson (Part I)