How to Onboard Feature Flag Management Tools

There’s a big step between managing simple booleans in-house and getting teams up and running with feature flag management tools.

Once you’ve made the decision to move, it’s no secret that configuring and onboarding a new tool can be a headache. We’ve put together some steps we’ve seen help teams. Production might break a few times. Wild segments might happen at first. But with the right systems and strategies, teams get used to purposefully using feature flags and releasing confidently. 

Here are five things to do when onboarding a new feature flagging software. 

1. Identification and assessment

Identify the challenge

The first step is getting clear on the challenge(s) you want to solve. This comes down to one main question: Why do you need a feature flag tool in the first place? Are you:

• Managing coordinated releases with multiple teams developing a single website? 
• Trying to manage growth (and get ahead of a scaling development team and increasing complexities)? 
• Looking for a way to ship more without overwhelming the system?

If you’re on the fence, this article runs through the steps to finding out when it’s time to move to feature flag software.

Assess what’s working (and what isn’t)

Next, assess what is and isn’t working for your releases. This will help identify what you need from the tool. Look at things like: 

• The developer experience and bottlenecks - Look at how releases feel for developers, particularly when multiple teams try to ship together.
  e.g. Engineers may be feeling the strain of supporting the product team by going into config files to turn features on and off. This causes new deployments and drains valuable development time.
• Release cycles - Look at how long cycles are, what release nights feel like, and whether moving towards continuous deployment feels achievable/beneficial.
• Forced rollbacks - Deploying releases may affect other system flows. Without a dynamic way to disable new functionality, you're forced to roll back to avoid further system failures. Depending on where this new functionality has been introduced, a failure in the system can lead to a significant loss of money (say, if the critical flow is a banking transaction), a lot of time consumption and a recovery system needing to be implemented. 
• A/B Testing - Look at your A/B tests. You may need feature flag management tools if you:
  - Notice that you have to write a lot of code to implement tests.
  - Can't vary measurement groups dynamically without a new deployment. 
  - Quickly see that one option converts much more (or less) and you want to move 100% of the traffic to another option but can't without a deployment.
  - Need to segment your audience in a more granular way. 

Identification and assessment will show you where feature flags can help and how they need to be configured. 

2. Feature flag setup and configuration

Once you’ve identified your needs, you can configure the tool for your teams. Here are some main steps to consider:

1. Integrate the app into your workflows - Get everything configured and tied together with your existing tools and workflows. Set up webhooks, out-of-the-box integrations, etc. 
2. Define feature flag best practices and guidelines - Set up feature flag management. Create flag naming conventions based on your configuration (making sure naming conventions are descriptive and easy to understand/search). Organise flags logically for your teams. 
   E.g. Add tags by team name, owner, domain, etc. This can be great for flag management—and to show things like who the flags belong to.

‍

3. Think about best practices for your team specifically - e.g. Are you in a data-sensitive industry? If so, you may need to set up traits in a certain way to avoid leaking sensitive information. Consider:
   - Trait mechanisms and identities
   - Feature flag segment definitions and segmenting best practices 

3. Establish testing procedures and QA - Feature flags can make automated testing difficult. Say you have 10 different flags; you need to know which ones could be enabled at the same time and test all the different combinations. You’ll need to set up testing procedures, troubleshooting processes and QA.‍
4. Create cleanup processes for removing/archiving old flags - Create processes for archiving/cleaning up old flags to avoid feature flag debt.
   → See this interesting Twitter/X thread by Pete Hodgson on feature flag debt.‍
5. Establish monitoring/management processes - Set up processes for tracking flag usage, performance, and changes. Make sure you have everything in place for security and access management, and to track who made changes when.  ‍
6. Iterate - Be prepared to iterate on your processes as you go. 

3. Onboard your teams to the feature flag tool

When the feature flag management tool is technically configured, it’s time to onboard teams so everything doesn’t go haywire. A few things can help:

Team training 

Set your teams up for success with onboarding and training:  

• Train the teams on technical best practices and your configuration
  Educate your teams on labelling standards, setting up A/B tests, debugging, and how to segment without creating massive segments that break things.   
• Train different teams
  Feature flagging systems help different teams coordinate more efficiently. For example, now Product don’t have to rely on engineering each time they want to roll out a feature to select users. Set up a technical demo to train engineers on how to implement or configure feature flags (or the custom library) into your code and a different one for business people (product manager, growth team, etc).

• Find a tool that will help you with training
  Some companies (like Flagsmith) will help you train your teams on things like best practices and how to get the most out of their tool. These trainings can help your teams understand how to use feature flags effectively. 

Documentation

Get solid internal documentation around feature flags, and get that going early. Feature flags are not immune from code disasters, and outlining best practices and standards in documentation keeps teams aligned. 

Start small

This might mean starting with just one team to iron out the creases before multiple teams get onboarded. It might mean identifying a shovel-ready use case for feature flags that is more cut-and-dry and starting with that before onboarding the team to more complex feature flag management use cases. 

4. Shift the culture and mindset around release practices 

Bringing on a feature flagging tool often goes hand in hand with modernising release processes (e.g. decoupling deploy and release). If so, the developer mindset needs to shift. 

Say you’re moving to continuous deployment. Your team may be used to deploying to production at the end of every second sprint. Developers are writing code, merging it, and not worrying about the state of the code as often, since the worry only sets in when it’s time to deploy. 

The mindset needs to shift to only merging when they’re 100% confident. When the mindset shifts, teams will get ready to deploy when the work is ready. A few things can help:

• Figure out integrating - Make sure code changes are integrated and deployed frequently 
• Figure out environments - For example, maintain a staging or pre-production environment that closely resembles the production environment. Get teams used to doing their final testing there before deploying to production 
• Implement release planning - Plan releases in advance and determine dependency timelines. Make sure that releases become coordinated. 
• Create a cyclical process - Establish a rhythm so that your team knows that when you create a feature behind a flag, they can just test it and ship the feature 

5. Continuous improvement

Keep an eye on metrics and be prepared to iterate. Constantly assess the developer experience and the product experience. Monitoring metrics lets you identify pain points and keep improving.  

Conclusion

A lot goes into changing processes and adopting a new tool. The potential rewards are massive, and the confidence that developers can gain from releasing with well-managed feature flags is well worth the effort. But it’s a big step from in-house booleans to managed feature flags, and it helps to break down the onboarding process into actionable steps. 

If you have questions about onboarding feature flag management—or simply moving away from managing them in-house—contact us and we’d be happy to help. 

More Reading/Info

• When is it time to move to feature flag software?  
• The Flagsmith Docs cover everything from managing segments to setting up integrations and from A/B testing to scheduled feature flags  
• Martin Fowler’s article on feature toggles is the OG feature flag article. It covers feature toggling, feature flag categories, and things to consider

‍