Getting From No to Yes

It's not enough; but not enough is better than nothing.

— Phillip Atiba Goff

In an organization where features must be fully completed before being deployed, the people who say "No" to a deployment might characterize themselves as "protecting" the customer and the customer experience. By holding back until a feature is "perfect", "lovable", and beyond reproach, these gatekeepers might even position themselves as being the true champions of the customer; and, the ones keeping the rest of the organization under control.

But, saying "No" starts to feel very different when you're using feature flags to incrementally deploy a feature to production. Unlike a feature deployment, which represents a potentially large amount of coordinated work, a feature release—using feature flags—is nothing more than a flip of the switch. This alters the social dynamic within the organization.

When a feature is implemented in production behind a feature flag, its proximity to the customer changes the perception of its value. It's no longer theoretical—it's real and material and has already been demonstrated to the team. At this point, it's a challenge to keep seeing the gatekeepers as "protecting" the customer. Instead, these gatekeepers appear to be withholding value.

This puts the gatekeepers in a contentious position. It forces them to justify why no value is better for the customer when some value is one configuration change away. This is a good thing. It makes saying "No" seem much more subversive. Which, should—hopefully—start to bias the organization towards action.

This is true for both sanctioned and unsanctioned work. Ideally, all work is pre-approved by the business. But—sometimes—there's a disconnect between the leadership vision and the value of a feature. And, it becomes near impossible to get certain features approved.

In some of these cases, it's easier to build the feature first, behind a feature flag; and then, ask for approval—not to build it, but to release it. At that point, the same reversal of power occurs: the organization is forced to justify why no value is better for the customer considering that the feature in question has already been built, deployed, and is just waiting to be released.

This kind of guerrilla development is safe to do because the feature flag targeting keeps the in-progress code hidden from the customers (and, even, from the rest of the team). Which means, the engineer(s) doing the work can dribble in effort when they have spare time; and, can do so without negatively impacting the rest of their work responsibilities.

Sometimes, you have to ask for forgiveness, not permission. As an organization grows in size, it must figure out how to scale both its process and its communication. This evolution often involves the pendulum swinging way too hard from one side to the other, with far too much process being put in place.

This can lead to an EPD organization that argues about everything and then does nothing. And, unfortunately, this kind of behavioral pattern can only be broken by external forces. That is, people acting upon their best judgement and then asking for forgiveness.

I often think back to something Stephen Gates said about his role in the head of design:

.... for most companies, right now, because of the way their processes are—because of how afraid they are of so many things—the innovation that they need will probably not be authorized.... When I look back at all the work that was innovative, it was only innovative in hindsight—it almost got me fired on the way there.

— Stephen Gates (design evangelist)

This mentality is not for everyone. And, to be clear, it does come with some risk. But, if you hold the customer at the center of your decision making process and you act with the best intentions, you'll often be surprised to see what you can get done independently; and, how far you can move the organization forward.

Have questions? Let's discuss this chapter: https://bennadel.com/go/4566