Author: az

Adam is a start-up Advisor providing guidance on leadership, product roadmap, and GTM strategy. He has over 20 years of experience working in a variety of roles from software engineering to technical sales. He has worked in both enterprise and consumer companies such as VMware, EMC, GitHub, and LaunchDarkly. Adam is driven by a passion for inclusive leadership and solving problems with technology. As an Advisor he works with a number of startups and nonprofits. His perspective on life has been shaped by a background in Physics and Visual Art, an ongoing adventure as a husband and father, and a childhood career as a fire juggler.

Categories
Uncategorized

Positive Control

Photo by Pixabay on Pexels.com

The word ‘control’ often has an immediate connotation for folks. For some there is the idea of ownership, enablement, or success. While for others the word conjures images of restriction, repression, or failure. In the context of Progressive Delivery we talk about control in the context of release progression and radical delegation. In both cases we view control as a benefit to both the provider AND the consumer of software.

Release progression — 

progressively increasing the number of users that are able to see (and are impacted by) new features

Controlling the cadence of software release is a requirement for most businesses. The reasons may vary, but the options for control are typically similar. Let’s consider a couple examples:

Productivity SaaS platform – When a new feature is being developed there is an immediate need to begin testing this on the production environment. The reason for this is that for platforms operating at scale, the time and resources required to simulate the production environment are far more expensive and inadequate compared to using feature flags, canary’s, blue green deployments, or some combination of these techniques. As the feature gains stability and completeness it can be released to a larger audience. This control on the provider side limits the blast radius of any potential outage or bug. Microsoft refers to this practice as ring deployments. This control on the consumer side allows the selection of one’s risk profile. The provider can allow folks to opt-in to new features or even explicitly opt-out. 

Financial service platform – For certain verticals the cadence of change can have a significant impact. Often consumers in the finance space need maximum efficiency during seasonal peaks (e.g. tax season, quarter-end, payroll, etc.). These peaks vary by customer, but it is critical that the platform doesn’t release changes that would cause changes if workflows or worse break existing functionality. Control for the provider in this use case enables them to continue innovating and forward development. The consumer is provided the ability to control the timing of when updates are applied to their account and in most cases allowed to delay changes until a peak has passed. 

Radical delegation — 

progressively delegating the control of access to a feature to the owner that is closest to the outcome

In the context of delegation there are multiple vectors of control. 

  • Control of what can be changed
  • Control of what changes are possible
  • Control of who can make a change
  • Control of when a change can be made
  • Control of all the above options in combination or negation

Here is an example to help show how this benefits both the provider and the consumer:

Trying out the premium version – In this scenario a consumer is looking to try out the premium offering form a provider. The consumer is a current satisfied customer and wants to try the advanced feature before committing to pay the higher rate. Using feature flags and a radical delegation approach, the provider can enable a Customer Support Representative (CSR)  to turn on the premium functionality for the customer for a trial period. At the end of the trial the CSR could then upgrade the account to the premium offering or turn off the trial and have the customer account revert to the standard offering. 

In this example the radical delegation of control was a benefit to multiple folks. The developer that built the control point benefited by setting the parameters of what would change on the account and what would remain the same. This aspect of control allowed for a trial experience that had predictable outcomes. The variations were defined as part of the control options. For the operations team, this control point was of benefit because the service level agreements for the premium offering were able to be incorporated into the control point as well. This meant that during the trial the customer was automatically provided a premium experience. If the customer decided to revert to the standard offering the SLAs were automatically adjusted. The CSR was able to benefit from the direct control of the customer experience. And the customer benefited from the ability to try a premium experience before having to commit.

Let it go

When control is given to the individual closest to the outcome it is often a benefit. A key consideration is that the control point needs to be well defined. There needs to be clear articulation of what changes are possible and the outcomes that will result. A well designed platform will allow for changes to be reverted. Changes that are delegated and not recoverable but the person that has the authority to make the change is an antipattern. In the case where a change is not recoverable, this is an indication that the change is not ready for delegation.

When a system is architected with delegation in mind, all sorts of changes are possible. One of my favorite examples is using feature flags for live database migration. This is an extreme example of what is possible when you recognize the value of delegating control.

Categories
Uncategorized

Delegation vs. Abdication

Photo by Flickr on Pexels.com

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 \

  1. the act of empowering to act for another
  2. a group of persons chosen to represent others

abdication

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

  1. an act of giving up sovereign power or high office
  2. an act of abandoning or discarding a right, responsibility, etc.

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)

Categories
Uncategorized

Introducing Progressive Delivery

To be clear, Progressive Delivery has been introduced before… numerous… times.

Progressive Delivery is the next iteration of the software development lifecycle. We’ve moved through several phases, which mapped to our infrastructures, business models and constraints — from waterfall to agile to Continuous Delivery, and now into Progressive Delivery.

This is an iteration, not throwing out what we’ve learned. We’re building on top of Continuous Delivery practices and we’re making explicit some things that are important and have been neglected. We want to focus on and add to the Continuous Delivery model because we think the world has changed profoundly since its introduction. Software has eaten the world, and software delivery must evolve accordingly. The cloud changes everything, and it has profoundly changed how we build software and deliver experiences. That’s what we’re capturing with Progressive Delivery. 

We’re no longer about constraints but cloud infrastructure abundance. Everything is distributed, software is running everywhere, new endpoints are emerging all the time, enabled by cloud computing. The network is the computer, and we should take advantage of that network in delivering services. We can route network traffic, route users, route cohorts, and replicate and clone everything. Production is the new staging, but we’re in control of when and how that production is released to cohorts of users. Manage the blast radius, test in production, dark launches. We now live in a world of infrastructure as code and software defined networking- Progressive Delivery takes advantage of that. Observability, shifting testing left, but testing in production, that’s the world we’re describing and defining.   

This explosion of endpoints (from mobile to IoT) has led to the incorporation of a digital component into all experiences. Every aspect of our lives has a SaaS correlation and requires a new level of collaboration and feedback with the builders and providers of these services. Even impacting the most basic needs like housing, food production and delivery, as well as transportation — our lives are intertwined with software. It’s time that we adapt the way that software is built and delivered to leverage the innovation in tooling and rapidly incorporate the expectations of users. 

We’re here to document and drive an industry change, a better way of building and delivering software with profound implications for business, product management, and IT. 

Adam Zimman, James Governor, and Kimberly Harrison.