Feature Flag Ownership Models: Which one is right for you?

As with any feature you build, the individuals and teams that originally built the feature flag or A/B test are not going to be around forever. As a best practice, your engineering organization should agree on who is responsible for owning and maintaining a feature flag or A/B test in advance. This is particularly important for when you need to remove or clean up old feature flags or A/B test.

In my experience as an engineer and an engineering manager, I’ve seen a few governance models work well. Below, I’ll walk through the examples from my free e-book Ship Confidently with Progressive Delivery and Experimentation as well as share the pros and cons of each so you can make an informed decision about what will work best at your organization. Let’s dive in!

01. Individual Ownership

Individual developers are labeled as owners of a feature or an experiment. At a regular cadence, for example every two quarters, ownership is reevaluated and transferred if necessary. Ownership can be tracked in your feature flagging system, ticket tracking tools, in the codebase, or in on-call systems. Simple and understandable.
Pros: Simple and understandable.
Cons: Hard to maintain if engineers frequently move between projects or code areas.

This model works well if you have a small team managing a lot of feature flags and people stay on a given team for many quarters. This model is especially good for small companies and startups with less than 50 engineers.

02. Feature Team Ownership

The team responsible for building the feature takes ownership of the feature flag and/or A/B test. Resilient to individual contributor changes.

Pros: Resilient to individual contributor changes.
Cons: Hard to maintain if teams are constantly changing or are unbalanced and have uneven distribution of ownership.

This model works well if your teams are stable and align to product features that are also stable across many quarters, but individuals tend to float between different teams.

Sometimes, feature teams can inherit old legacy systems or a mountain of previous features making the distribution of ownership feel uneven, but this may be more of a signal to re-organize your team structure in general.

This model works well for both medium (100+ engineers) and large engineering teams (1000+ engineers) that have stable and solid structure.

03. Centralized Ownership (Center of Excellence)

This ownership falls under a dedicated experimentation, growth, or release team with experts who set up, run, and remove feature flags and experiments. The downside is that it severely limits the scale of your progressive delivery and experimentation program to the size of this central team. The upside is that this centralized team can be the experts at your company and help ensure experiments and feature flags are always implemented with high quality. They also own the processes and best practices, and evangelize them to the rest of the organization.

Pros: Resilient to many changes and simplest to reason about.
Cons: Central teams aren’t going to be the experts where the feature flags and experiments are actually implemented and may require a lot of help from other teams. The size of this team will eventually limit the number of experiments and feature flags that your company can handle.

This method can be especially helpful when getting started for companies of any size, and it’s useful to have one team prove the best practices before fanning them out to other parts of the organization.

04. Hybrid

As with most organizations, there is likely not one perfect setup. It’s important to realize that the above models are flexible and not mutually exclusive.

At medium and large organizations especially, it may be important to have different teams operating with different ownership models. As long as you are mindful of the organization setup you are using, why you are using it, and the potential drawbacks of that model, then you are on your way to a successful setup.

At Optimizely (~100 engineers), we use individual ownership of features tracked in JIRA tickets while also having a centralized QA team that ensures that tickets are accurately tracking feature flags, feature flags have owners and individuals are following best practices for setup and removal.

Let me know what you think

What feature flag ownership models does your organization use? Message me in our Slack community or find me on Twitter at @asametrical.

This is part of a series of best practices to help your company successfully implement progressive delivery and experimentation to ship faster with confidence.

If you like this content, check out my free e-book: Ship Confidently with Progressive Delivery and Experimentation which offers more best practices from just getting started to scaling these technologies organization-wide.