If you do enough research on feature flags, you’ll see flags framed a lot of ways:

• Feature flags extend CI/CD.
• Feature flags are kill switches for ops teams.
• Feature flags remove deploy risk.
• And many others.

All of this is true! But there’s one thing that you won’t see talked about a lot, and we find it’s often the difference between teams that are able to use feature flags to truly unlock next-level velocity from those that find them useful, but not transformative.

That missing thing is seeing feature flags as a part of your software delivery team’s culture. Not just a tool, or an implementation detail. Feature flags are also a process and also a way your team works if you want to get the most out of them.

They can be useful as just another tool in your stack, but they will be gamechanging when you let them change the way your teams work.

Common Low Ceiling Usage

First, let’s take a look at ways we’ve seen teams adopt and use feature flags:

• A few engineers start using flags, eventually other teams in the org pick them up too. Some teams use them, some teams don’t.
• There’s no consistent way to use flags - some teams flag whole features, some teams flag incremental changes, most teams only flag user-facing changes.
• Feature flags are helpful, but a lot of features still roll out without them and usage is sporadic.

If this looks like the state of feature flagging in your organization, you are not alone. And, there are parallels: if you’ve been in this industry a long time, you might remember that test automation, and later deployment automation, often lingered in this sort of patchwork place too before their eventual industry-wide ramp-up as a standard engineering practice.

Feature Flags as Culture: Bringing Others Into it

To remedy the above situation, we have a few suggestions. To start, make sure everyone in your organization has access and knows what feature flags are. Invite your PMs, support team, sales engineers, and everyone in the eng org - including ops, DevOps, security, and anyone else. 

Put together training sessions if awareness is low. What are feature flags? What are they for? What can they do? Make sure everyone in your software delivery organization can answer those questions.

Feature Flags as Culture: Flags by Default

Once you have people in the tool and they are at least notionally aware of the feature flagging concept, a big change for execution teams to make is flagging by default. 

Oftentimes, teams wait until they find “the right use case” to get started with flags. Maybe you’re refactoring right now and so you don’t need flags, but once you do a new feature you’ll take a look. Or, maybe you have something already underway so you’ll look at flags next time. Or, maybe this feature is going to roll out to everyone, so it doesn’t need flags.

These are all the reasons we’ve heard why it’s hard to find the “right use case” to get started. That’s why we recommend not waiting for the right use case at all. Just add flags, now, to every change you’re making!

And while “every change” can sound like a lot, and obviously we can’t literally mean every single change, we do honestly mean most changes. Frontend, backend, APIs, user-facing, tech debt refactoring. You can put it all behind a flag. And, don’t worry whether or not you know what you’re going to use the flags for. You may not think you need the flag, but it’s an almost free level of optionality that you will very likely find you’re glad you have later.

If you’ve done a rollback or a hotfix in the last month, you had an opportunity to use a flag, because if that change was behind a flag, it could have been turned off instantly. If you’ve asked customers to give feedback on something recently, you had a chance to use a flag, because access could have been granted with a flag or new instructions sent to specific users via a flagged UI element. 

Even in listing these scenarios, I want to be careful, because you may not think of wanting to do these things until right before a change is released. Or, even after it’s released. That’s why the right time to add a flag is now, even if it seems unnecessary. Because having the option later is always better.

Feature Flags as Culture: Thinking in Terms of Flags

At the start of the post, I said feature flags were a way of changing your engineering organization’s culture.What that boils down to is fundamentally separating the idea of a release from the idea of a deployment. 

Just like CI permanently changed engineering culture (if you were here before CI) in terms of how teams managed quality and CD changed culture in terms of how teams coordinated releases, feature flags change how you think about risk and change management. 

If you adopt feature flags as a core part of your software delivery mindset, you will find some subtle but important changes in how you plan releases:

• Your concern for deployment risk, and the amount of time you spend on deployment complexity, almost disappears.
• You start thinking of what you want to learn to test a change, almost all the time. When is it safe, and how do you know?
• Ownership of a release is distributed. Some releases will be owned by engineering, some by PM, and some by support teams. Who’s impacted by the change determines the owner. It’s not all on engineering.
• Being able to resolve change-related incidents instantly becomes an expectation for both you and your customers. This means the way you incorporate bug fixing and planning changes, because you can turn the issue off - and prioritizing, rather than having to always interrupt to fix.

Conclusion

Together, these add up to an engineering team that thinks about what releasing changes means, who does it, and what the risks are in very different, more collaborative, more learning-focused and less stressful ways. When all of that happens and feature flags have really become part of your culture, you will find they’ve gone from a nice to have to a core part of how you think about delivering software.

Ready to get started with feature flags? Why not start your free trial and play around with making your first flag? If you’re not ready, keep educating yourself! Read our piece How Feature Flags Help With Trunk-Based Development.