Feature Flags Shift The Balance Of Power Away From Designers


I’ve been using and loving Feature Flags for a long time. And, historically, I’ve embraced feature flags as a construct that makes product development faster, easier, and safer. But, last week, on the Deploy Friday podcast, I started to formulate some novel thoughts on what makes feature flags so exhilarating: they shift the balance of power away from Designers, which is probably a good thing.

EPD: Engineering, Product, Design as a stool, in harmonious balance.

Before we had feature flags, there wasn’t a great way to incrementally build parts of your product: code was either deployed to production or it wasn’t. Since the “deployment” of code to production was tantamount to the “release” of a feature, code couldn’t be deployed until it was “feature complete”.

So in a pre-feature-flag era, code was deployed to a staging or Quality Assurance (QA) server of some kind where it could be reviewed by your product team, your QA engineers, and various other stakeholders that had a keen interest in the product experience. This is historically where a lot of “fine tuning” and “polish” would be discussed:

  • Adjust the animation timing.
  • Move this up 3 pixels.
  • Change the language on that button.
  • Pull these two elements into better alignment.
  • Track that click-event.

And so the iteration would begin: deploy to staging, gather feedback, apply feedback, re-deploy to staging. And so on.

For engineers, this dance is the stuff of legend. Every engineer carries with them war stories from the trenches: the designer who refused to let anything be deployed; the executive who was prepared to die over the wording of a page title; the marketing director who needed every single interaction to be categorized and tracked and posted to several different analytics services.

In those days, since the new code was so far away from the customers, it all felt like part of the “design and development phase”; and, that all of this fine-tuning and hand-wringing was being done in an effort to create the best product experience possible.

In those days, designers were the gate-keepers of quality.

But, feature flags changed everything. Once we had feature flags, we no longer needed a staging server: incomplete code could be deployed to production without being released to the users. So all that iteration – all that polishing and fine-tuning and gathering of feedback – that’s all now done in production, behind a feature flag.

Now, the new code is collocated with the customers. In fact, the only thing that’s keeping the customers from accessing the new code is a toggle. A toggle that, when flipped, instantly synchronizes across all production environments and grants customers access to the new feature.

This change in the location of the code dramatically changes the conversation. Whereas in the past, when the code only ever lived locally or in Staging, everything felt “pre-production”. But, once the code is literally on the production servers, it takes on a new gravity. It put “value” at only an arm’s reach away from the customer.

And when you start to realize that the only thing between the customer and this new customer-value is a toggle, you start to seriously question, why we ain’t flipping that toggle on immediately?!

Because, isn’t “some value” now better than “all the value” later?

It turns out, yes. In almost every case, yes.

So now, people who don’t want to turn on the feature flag, they aren’t “gate-keeps of quality” like they used to be, they’re the people who don’t want to deliver value; they’re the people who have the power to improve the lives of our customers with a single click; but who choose not to.

Nobody wants to be “that person”.

And so, the power dynamic changes; and the perspective shifts; and your team begins to bias towards actions and embrace workflows around iterative product development. Which is – without a doubt – the key to successful product development.

Now, to be clear, Designers are critical to creating a quality product. I am in no way trying to diminish the role of design. In fact, I would kill to have unfettered access to a designer on my little product team. But, Engineering, Product, and Design (EPD) are three legs of a stool. And that stool is only structurally sound when everything is in balance – when the forces of each leg are properly tempered by the opposing forces of the other legs. And I believe that feature flags are key to restoring that balance.
















Source link

Latest articles

Related articles

Leave a reply

Please enter your comment!
Please enter your name here