 Thank you. Thank you, Marisa just want to give a quick shout to the Linux Foundation always a pleasure to run webinars with with you all, and always love the turnout and the engagement from the crowd that we end up having at these webinars. All right, without further ado, let me just welcome you guys again to our webinar today, all about five feature flag use cases, you may not have thought of. For those of you who are more familiar with future flags, there are probably a number of things that you're using feature flags for every day, which may involve obstacles increasing velocity, doing more experiments with customers. Let's talk about the things that might help you do things like get other teams on board, get someone else excited maybe your boss, and how and also thinking about what are ways that you may be able to creatively use feature flags in your own applications and services that may add more benefit to your applications your business. Like Marisa said, just quick little bit about myself I'm on the product marketing team here at harness been here about a year, working on our feature flags product. And with me I have Ethan Jones, the director of product management for harness feature flags, and I will be your MC today, Ethan will be the primary share and presenter and arbiter of content. Without further ado, let me hand it over to even to bring you guys in. Thanks for appreciate it. Thanks Marissa and Linux Foundation and all of you all for joining. Like Bargo said if you have any questions feel free to drop them in. We will talk about some of the, you know the topic is use cases for feature flags you may not have thought of. We want to talk a little upfront amount kind of what are feature flags and set the expectations a little make sure they align with what you're doing right now. One of the things I think are kind of interesting surprising about working with feature flags every day is that a lot of folks know some of the stuff you can do with feature flags, and maybe not a bunch of the other stuff you can do. And depending on whatever problem brought you to feature flags initially, the piece of feature flags you know maybe a little bit different. If you're one to five people will hear one use case they know, and it might be a different use case for everyone. So starting here with just what are feature flags right as Bargov mentioned you might have heard them called app configs or feature toggles or just toggles, it might be database switches, some of it might be stuff you've been doing for years and never really thought about. So the more you can do with that kind of system when you pull it out from kind of bespoke internal logic to an actual service dedicated to it like harness feature flags. And fundamentally what it's about right as you see on the slide here it's about moving faster by being able to turn stuff on and off without the complexity of a full deployment and rollback cycle, or another way to say that is decouple your from your release. So I want to do my deployment move the code artifact in prod. That doesn't mean I want that feature live the second the deployment's done. I as the PM maybe want to turn that feature on for a few specific accounts, a few days after the deployment, or if there's an issue I want to turn the feature off and not have to do an entire rollback. So that's kind of commonly what you would think of as a feature flag. So, Ethan, can you share maybe a couple of examples of things in the real world that are controlled by feature flags right you you mentioned there are a bunch of different ways you might see it bunch of different ways it's called. But ultimately it sounds like what the end user would see or the end user would interact with tends to be the same, despite the variety of names it may have on the back end. That's a really good point right feature flags really became sort of famous for some of the work Facebook was doing about 10 years ago they got very public with it Netflix has used it a lot. You can think of a common scenario might be you want to test a feature. You want to see if it's worth investing more in as a V one you'll hear Facebook does this a lot. So they'll turn it on for 10% of users in maybe Argentina, and kind of measure how it does, and then maybe test it for 10% of users in a different cohort. And that's where you decide do we really want to ramp it up for everyone, or do we want to move our resources on. You might also see it in terms of a company like harness or other companies, you can give beta features to customers in a much easier way. So a very real world example right would be if we want to give you access to something we turn on the feature flag you have it on your account doesn't mean it's rolled out to everyone doesn't mean it's rolled out widely in production yet we can do that at a later point. I had to share one of one of my own examples. When I go on my Amazon app on my phone. If I have it up and my wife has it up. There are a bunch of times when we might see that we're actually getting different versions of the app. Most recently they made a change to where the menu bar is within the app itself. And so I had it open. And for me the menu bar was at the top where it used to be. And for my wife, the menu bar was actually at the bottom. And this is this is a perfect example of what Ethan was describing in terms of companies use this from this technology feature flags, all the time to serve up different variations of the product or the application or whatever it is to see how is it that our end users are using it, and is it achieving what we want to do for them. It might be a business case a business metric that they're trying to move. A lot of times it's just trying to make things easier to find for users or improving the user experience. So that that's my own that's my own personal anecdote for how I've seen feature flags used towards the end user right into to Ethan's point, right, it might be called app configs, you know, database switches. You might hear them as feature toggles feature flags whatever but ultimately if you think yourself as the audience about are there scenarios where you've done these things or you want to do these things. Well, those are your common feature flags use cases. And actually I think that's a perfect segue then into, you know, what are some of those common use cases that we see. Yeah, I think the Amazon example is such a good one right when we talk about where we see these commonly used with the things that maybe more people think about, which is the ability to test two versions of an experience. So I'm going to update my navigation I want to see if that drives more people to the checkout page sooner, right that's kind of a front end change. You can use a feature flag to do exactly what you just described with Amazon testing conversion or the business outcome. I think it's a very common use case a lot of folks are aware of usually through the front end. So where they come in when like I mentioned is going to be beta access. So making sure only certain customers get access to a feature before we give it to everyone, which kind of goes hand in hand with like testing the readiness of a feature. So I'm going to turn it on a little bit. I'm going to see how it performs for a while and then I'm going to expand it from there or if there are issues, turning it off. All of these are scenarios that if you're not familiar with feature flags at all today. Highly recommend digging more into them we've got a lots of content I think my next foundation does as well. They're really valuable scenarios. If you're familiar with feature flags or if you have some version of a system that's kind of like feature flags already. There's a good chance this is the context you think of it in, or these are the stories you've heard that feature flags is really good for so far. Even at this list, it almost sounds like you'd actually try to build this yourself to solve point problems and at some point without even realizing it, you've ended up with a homegrown feature flag solution. Is that right or maybe the better question is how do people usually solve for this. Yeah, it's a really good point right. I think a good analogy as well as maybe like see I 10 or 15 years ago if anyone was around back then. It usually does start off as you kind of build it yourself to solve a specific challenge right. A common thing you might see is it gets bolted into like an internal admin portal that's run internally. You say oh we don't really have the tools to turn it on for just specific users but we can go back in a couple days and you build a little UI. The problem is you get more and more needs for it that system gets bigger and bigger and more complex, or you just stop updating it because you really can't support an internal system to do the more complex things people are asking for. So that's when you get into migrating off of an internal solution to a commercial feature flag solution, like ours or like any of the other great vendors out there on the market doing good work in the space. Remember, we were to right before we officially decided to build harness feature flags, we were doing a lot of this in house, right, can you tell a little bit about our story there, maybe what caused us to build a full fledged solution. Yeah, and we've written about this a little bit as well I think it's a kind of funny meta problem where we had feature flags internally and this is going to be lowercase feature flags not capital letters harness feature flags the product. But what we found over time is that as we use feature flags more and more, it was really getting expensive to make our system do these more complex things we wanted. We're having to choose do we really want to invest engineering resources in our internal system. And then the tools on the market we're also getting more mature. So it became a build versus by decision. This also eventually happened in some other spaces again like I mentioned like CI, but the commercial tooling just began to outpace what you could do with an internal solution and that's exactly what we found as well. The difference is because we're a software delivery company, we decided we actually had something to offer in terms of building a really top notch feature flag product which is what we went ahead and did. Yeah, so it does sound then like it's really common to just you build this without even realizing it you've you've built an awesome system. And now you might run into the monstrosities of dealing with a homegrown system at scale that maybe wasn't designed for something like that, right to go across multiple teams to solve complex use cases and I following you right. Yeah, exactly. And again, I think these use cases you see up on the screen here whether you're using an internal system whether using one of the many great vendors out there right I don't want to claim we are the only one there's a lot of people that do good work in the space. Probably the use cases you see on screen are exactly the problems you were aiming to solve when you got into it. So, excuse me so let's get this into a little bit what we wanted to talk about today right, which is if you're starting to solve for those use cases that's great. So if you get excited is thinking about then what else you can do, because there's lots of other really cool things you can do with feature flags. Once you've kind of done those initial things that provide so much value out of the gate, but bringing it to more teams more people that's kind of what we want to talk about for the remainder of the session here today. The first use case. Oh, sorry go ahead. I mean, let's, yeah, let's let's jump right into it. Yeah, absolutely. So the first use case right I mentioned on that previous slide yourself at front end changes right what we find is a lot of people think of feature flags in terms of the user experience exclusively. You know, you can do all the back end things you can do with feature flags, you know us and all the other people who do this with a feature flag product have what you would call server side SDKs so Java dot that go lang. These are all SDKs you can install in back end code, and they let you do some things you might not be thinking about such as versioning an API or introducing API changes in a pretty slow way or step by step or with a test audience behind a flag. So tech deck is kind of infamously hard to quantify. It's kind of infamously hard to see exactly the payoff. If you put it behind a flag you have a pretty cool opportunity with tech debt, because you can actually run the new version with the refactor against the old version without the refactor and see side by side what's happening to your performance what's happening to your logging what's happening to your cost. So tech debt and refactoring is actually a really good opportunity to feature flags that a lot of folks don't think of. And then another one I'll say is migrating infrastructure, and you can't do all of this with feature flags right there again this is a use case by use case thing what we encourage folks to do is think about. Is there an opportunity here with feature flags, some stuff is very artifact heavy or it's really, really bespoke and that's going to be hard to do in this condition, but I want to give one example that's a real world example of migrating a logging service right migrating one for the other at a previous job that I worked at. We built a new logging subsystem we had to get off the old logging subsystem. Normally the way you would do that is with a sort of ops focused back and cut over date like a midnight release window sort of thing by using feature flags to control that what we were able to do is just Monday 9am someone would turn that flag on the new system would get the logs. We do that for about an hour and then we turn it off. And then we look at the logs look at our exception see what we needed to do the next day do it again do it again. If you think about how fast and easy that is with feature flags just go turn the flag on turn the flag off in a previous world right that kind of switching over from one system and other is really tough really expensive. You're talking about deployments and rollbacks and probably ops on call, and all kinds of things feature flags took all of that away and just made it a very casual tasks to do a pretty heavy infrastructure migration. It's a little too right like as a former dev myself even though I was on the software engineering said more than upside, like when you have that cut off date from ops like hey this is the day we're going live you need to be ready. Everything needs to be ready and better work, really stressful time as a developer. Yeah, I personally I personally liked the ability to be able to say hey you know this is, this is like mostly ready. Can we like get it out and I need a few days to like wrap it up and run some load tests. And then we can, we can, you know, get this out there fully. Yep, exactly. I think that the peace of mind should not be undervalued in terms of hard to quantify value but very very real value over time. Yeah. And so is this you know we were talking a little earlier about like, is this something you could do in house, like if you want to build this yourself this seems like something that might be a little on the harder side to do a little more abstract. Yeah, I think the reason it would be harder to do is kind of the same reason that maybe a lot of folks even who use feature flags don't think of these use cases all the time is when you're thinking about back end stuff and system stuff. And a lot of times there's kind of either default patterns or ways of working, or we tend to see those as very big expensive things and we're not going to kind of build glide paths or a lot of like, that's why we have these ops periods where we do hard cutovers and things like that right. So some of it is just kind of the nature of the work makes us disinclined to think about other things we can do like use feature flags. And it's also the case that the people doing this kind of work right. It's usually a low value use of their time to build an internal feature flag system for these kinds of tasks. It's usually not what you would like those folks doing with their time. Yeah, that makes sense. Okay, so let's talk about refactoring a little bit because you you just mentioned it to. Yeah, performance refactoring is kind of a pet one for me because I think it's often talked about right I don't know that anyone has worked anywhere where you're not occasionally trying to deal with how do we make this faster. How do we get the number of queries down how do we reduce the load. If you've ever gone through that cycle right one of the difficult things is knowing exactly how you judge it how you measure the success and how you do that no way that's not super expensive and time consuming. For instance, I've worked at places before we're really focused on improving our responsiveness of the UI let's say, but we can really only ever approximate the result, because the way the deployments work right is like it's kind of an all in one switch. And then you don't really get to do an apples to apples cohort comparison. So maybe it's a little bit faster but then also maybe the regions a little bit faster that day. There's a lot of things that can go in with feature flags. And a good practice to use feature flags for all of this type of work by people, because you can always put them side by side, and you can put them side by side right not just once, but in a bunch of different time windows tested on weekends test them and night. Test them at different load periods tested at different region, and really get a comprehensive look at what that performance refactoring, whether it's about speed whether it's about latency whether it's not simplifying the code on the back end, really give a comprehensive look at what that's doing. This is the example you see there on the slide. We've done this plenty of harness I've done this 20 at other jobs as well. The first time you build something, especially use a UI. It's probably not going to be the best way you're ever going to build the UI in terms of simplicity or knowing exactly how to design that front and back in communication. So oftentimes what you do is six months later you say now that we know what we're doing, we can greatly reduce the amount of calls this front end is making to the back end. I need to be able to justify that it's worth it. I need to be able to see the impact it's having otherwise it's just kind of invisible tech debt that we can't ever tell us it paid for itself. So feature flags go a long way to solving that problem. They do one of my favorite things which is always making the implicit explicit. There's an invisible ROI and now there's a visible ROI. It's, as I read this and as I listened to it almost sounds like there's a hidden use case in year about potentially even using this like test new algorithms, or testing multiple, multiple ways of trying to make things faster or more responsive. Is that part of refactoring or is that would you classify that differently. It could be right because I think a little bit what we're touching on is kind of a mindset as much as it is what specifically the type of work is. Because whether you're doing sort of back end or computational things that you want to test the outcome of like what you just mentioned, or a little more what I was talking about refactoring calls between a front end or a back end. You might say you just said one of the most common use cases was front end. And now you're saying the use case I haven't thought of is front end. So what's the deal there. But it's because internally when you say the word feature flag you would probably say oh no this doesn't feature flag because I'm not going to roll this out to beta customers. This isn't the kind of thing that is about the feature release so I don't use a feature flag for that. This is about thinking of the feature flag a little bit differently and more of a change management tool, and really is more of a quality gate and an assessment tool. Interesting. Okay. I do want to remind the audience real quick, in case anyone did have any questions we are trying to keep this conversational. So don't be shy about asking questions. In case they do pop up of course at the end we will have dedicated time for Q&A. Just want to give you a quick reminder in case you do have questions as we go through this content and feel free to drop it and we will address it as soon as we see it. Alright, watch now no questions will come in and I will have made a fool of myself. Alrighty then. Let's talk about ops toggles. Yeah, ops toggles is a another really interesting one right because any ops team, I've ever been close to they've got a big set of run books and play books and incident response practices. So to know what systems to tweak over time if you're running a SAS application, you know what systems might have load issues you have a ways to deal with them. The unfortunate truth more often than we might want to admit is that the way ops work is done is a little bit brute force surgery. So it involves getting into the cloud console directly, sometimes running queries. We're not going to say anyone ever might even connect to a database and production directly. If you have a security team no one's definitely doing that but I have worked at places where that happens. So the problem with this right is ops work, incident resolution work this kind of work. It tends to be very hard to audit over time. It's great when it happens you've got the incident closed, but where do you have a record of that where do you have the record of who made the changes who ran the playbook. Or what if the people who are the best at it run vacation and now you've got somebody who's never done it, trying to execute a run book or some kind of incident response playbook that they, in theory understand what they've never done it before. And they're connected to the AWS console and there's a lot of risk in that right. And then you really want to be pulling down cloud logs and various things anytime you want to have an audit or review what happened. So what we find is a lot of these systems you can put behind a feature flag, because I mentioned you can use backend flags you can use server side flags you can flag apis, you can do all that kind of stuff. So for instance, if you know that a system tends to be a risk at high load, a real world example I've seen is like a caching backup system that sometimes during really peak load would start to backup tasks and that could spill over to other scheduling systems. So what the ops team would do is they keep track and if anyone got paged on that system, they had a series of commands they could go in that they'd turn the caching system off. They do it manually, and then later on, they would turn it back on, and then they'd write up a little incident response issue. Eventually a real place I work where we did that right we move that to behind a feature flag. And that was a really huge relief because nobody had to run commands. We had a flag to turn off the caching system. It was fully audited. This was using an internal system. This is several years ago, the commercial tooling wasn't quite a strong back then, but even with an internal system it was night and day, especially when ops was maybe on vacation or not available, and any engineer knows if I go click that flag the caching system is going to turn off. And that's not as scary as shelling into AWS to run some commands you've never learned before. So I think it's a really, really powerful use case for folks to think of. And the reason it doesn't come up, I'll say, people always think about feature flags in terms of new work. We're starting a new feature, we're making a change, put it behind the flag. Here what we're talking about is a little different. We're saying, go take stuff you're already doing, go take stuff that exists in your confluence and your wikis and your jeers, and all these places. Think about putting that stuff behind a flag that's already there this is about retroactively adding flags, not putting new stuff behind flags. So I think it doesn't come up as much for that reason as well. How would you say this might impact the life of say an ops person or someone on the development side. I know you said a little bit about you know there's, if someone if there's a playbook and rather than going through you know the 20 steps through AWS. How do you summarize that or like sum it up like, how do you think this would impact even qualitatively just the lives of ops and dev teams. Yeah, I, I will say as somebody who has in a past life had to make some very last second it's an inopportune time of the year the right people are not available. I don't have to page people but do I really want to page someone who's on vacation in late December. I think I can give this a shot myself I see the instructions, but it is not fun, or easy to press enter in a terminal window on something you're not 100% sure of your only reference point is a document somebody else wrote, right that is a terrifying thing, but it's equally bad to have to page people it's equally bad to have to bring people in from their PTO. That's like a lot of stress it's a lot of interruption it's a lot of distraction. And it's also hours and hours back the time it takes to do interacting with your cloud systems directly can be very cumbersome time it takes to pull the data after if you want an audit record of who made those changes to give your security compliance folks take a whole lot of time feature flag one click. It's done. So we're talking about both the time savings and then also just a morale stress savings there. Yeah, talk about having an easy button for for ops problems. So obstacles are interesting. You know I can also actually see almost a branding plan some ways to the first example that pops into my mind is if you go to Google calm. If you have an internet connection, it will take you to the the offline dinosaur jumping game. And I can totally see ops teams or marketing teams to wanting to say like hey if something's wrong. Let's make it clear it's not our fault. And let's let's give them something alternative or something fun to latch on to to associate with with the brand. Is that something that you have seen or you think could work. 100%. So in the real world example I just gave at the previous place I worked ready to turn off the caching system we didn't do this. Well you just said makes me think I wish we had been smarter back then and had done this. And there's no reason that the same flag that turned off the caching system for ops purposes couldn't also be turning on an in app message that says hey we're going to upload. Please give your logs a little more time to cash they'll be available later today. That could have been fully automated doing that kind of experience without a flag is at least a two step process probably a much longer process where multiple people have to get involved. Now I'm sitting here thinking why didn't we do that I wish we had thought about that. That is a great idea that you can kind of couple the back end side of it with the front end or the user impact you want to correspond. Yeah, just hearing you talk about it makes me feel less stressed honestly, taking the work of a war room or pager or like you know someone who's on pager duty, and basically saying you know don't worry about that so much just hit the button. That's it. We're about in the morning. Yeah, exactly. Exactly. I do have a question that came into chat here as we were talking let me read it to you. I can imagine that over time we will accumulate feature flags to the point that it can be a nightmare to maintain. What are best practices with regards to managing feature flags. For example, we need to regularly delete feature flags corresponding to features that are already on in all environments. Yeah, so that's a really good question anyone who has ever dealt with feature flags at scale has definitely encountered that so that I don't know if the person asking the question has hands on experience or speculating but it's it's right on the money. It's a very difficult problem. I would say I think it's a problem all of us web pools in the market are working to get better at solving in a product sense. And there's two sides of it right there's process and product. I think for us building products we want to make the products better at doing that. We necessarily want to dwell on that here on the process side what we do encourage the team is to think about feature flags as part of your engineering process right the same way that if you have an incident, you're going to write an incident. You know response, or some sort of message out to the team into the company, the same way you might do post mortems at the end of a sprint. It's important to think of feature flags they are part of your engineering process. They're not some kind of thing that you just throw out there you use them, and it's done. So maybe you want to live for a very long time like these obstacles, but you want to separate those from the ones that you do want to get out of the system, like a feature that's been fully activated. So I would think about where they can live in your planning and cleanup process. Is there a tech that window you can fit them into. Can you assign owners. Can you keep track of them over time. Can you make them part of your release process. So for instance you don't close the epic for a new feature that's been launched until the flag is out of the system. So you start every new initiative with the remove feature flag story added to Jira or wherever, and it's the last story in every epic. So there's not kind of one silver bullet answer. It's a mixture of what the products need to help you do, as well as your team practices and hygiene. But again coming back to what I said earlier a little bit to that we're talking a bit about a mindset. It's really helpful to think of feature flags as a way of working, not just a way to change the UI, not just kind of a tool that helps you release, but it's really a way your team can work by default right it's a new way to work with a new type of change management mentality that does involve some new process such as cleanup as well. I do want to I do want to thank our attendee for asking a question, and not making me fall on my face asking you to ask questions live. So I appreciate that. I do want to add to that you're not alone in this problem. When we talk to customers when we just generally talk to the market. I think that this idea of how do we manage things when they scale up really heavily like how do we do life cycle management of flags essentially is really a growing, a really growing and significant pain point that everyone doing feature flags is trying to figure out right now. And so, in addition to adding those the processes that that Ethan suggested, you know, you can probably expect in the near future that if you are looking at tools tools will be looking to solve this issue for you in the near future to very very calm. Absolutely on that point if you have ideas for how you think tool should be helping you we would love to hear from you so don't answer has to reach out I think it's like bar gov said it's a pretty hot topic right now in the whole space. Yeah, and I'll tell you I'll tell you from my own personal experience, Ethan is awesome at listening and, you know, building really good solutions. So if you have, if you have ideas, even will definitely listen. Just, you know, shout out to my own co worker here. All right. Let's move along here then let's talk about compliance. Yeah, so compliance is another. I feel like I'm saying they're all pretty cool ones, but I think compliance is a pretty cool one. Right so you might have some real examples again like their logistics companies that deal with certain types of you could say freight, or maybe they're doing government services. If you're in the US those can vary quite a bit, state by state, right tax policy or how you weigh and measure things for cost or what you need to report out to the end user. There's a tremendously different state by state here, certainly different country by country. Maybe there's things you don't want to give to government customers if you have federal contracts, but it's fine for consumers. Maybe there's things you might want to show that you don't want to show you with different regulations. So the normal way to do those kinds of things. There's a couple ways it'll be done right one is pretty hefty conditional stuff in your code, where you're doing a lot of real heavy custom bespoke lifting to know what to do and not do, or you build these really aggressive abstractions in the product. Another way to do it is actually just to run different versions of your applications that can be even worse, and even more expensive feature fags are really great because you could just have one canonical version of your app. And you can turn stuff on and off against any of these things you need. So if you're running in our government cluster, we might turn off a certain data feature. If you're running in one of our EU targets, we might turn off a certain data feature. Or we might say hey Texas calculate shipping cost very different. If we're in a trucking product space. So for any of our customers in Texas, we're going to serve a different flag state than the ones in Ohio. So feature flags are really, really simple way to bring all of that out of your application. Don't run different things in parallel. Don't build this complex web of abstract and logic to figure this out just use feature flags. And then you've got a UI you've got auditing you've got governance you've got visibility, and they can be changed very, very quickly. So this is one that I think companies, especially in these regulated spaces, or that are serving federal or that are in really complex spaces where things are regionally different. So it's going to take a really hard look at how much kind of maybe invisible cost is in your code that could be moved to feature flags and would make a whole lot of things a lot easier. Yeah, one simple example I could think of that is you mentioned EU like GDPR. You know there, there may be data collection practices that you can do here in the United States, but if anyone's in Europe, you turn on your GDPR flag you're right with the new CCPA that passed, I think last year was it maybe two years ago, I must be getting old, very similar right, having a flag to show like, do I opt in do I opt out. Or can I just serve them a default experience. These are these are actually really common problems that that I see companies facing especially from the compliance side. Another good one to think about is if anyone here builds both a SAS and on prem version product. This is another one where making something that doesn't work in the on prem version not be in the on prem version can typically be sort of expensive, multiple release trains stuff in the code saying hey this is on prem turn this off, use this different networking logic if it's on prem right that's really really not a fun thing to do to ship a SAS product on prem if there are differences feature flags make it a very very trivial thing if you put that behind the flag, you target your on prem you turn it off with the flag, something that can legitimately take dozens or hundreds of hours to figure out maintain over time really becomes a process of a couple hours, maybe even less as you get good at it mature over time. Yeah, great thank you for sharing that. All right, we have one more use case free trials and this is what I'm excited to hear about because this is something that we do internally at harness I think even gave an example earlier of how we're so we're a software delivery platform we have multiple products. If you're on a free trial for a certain product, if you sign up for say harness continuous integration or continuous delivery or feature flags, all we do is we set an entitlement on the back end. And depending on what you signed up for we flip a flag, make you one of the people that's supposed to get that product and suddenly you have that available as your free trial. I hope I'm representing that well Ethan. Exactly I think anybody who's ever had to build this stuff right is one of the least pleasant things to build because it takes a lot of time there's a lot of corner cases. And it is not core, it's core to what you need to do as a business but it's not core to the value your product is providing at the end of the day. So this is something feature flags makes so easy and again it's, it's thinking about flags a little different, because if you're thinking about beta use cases or adding beta users, that's still a flag that's eventually going to be removed from the system. Once the beta is over. This is more thinking of flags as a permanent way to kind of control your free tier, at least control the elements in the UI maybe that need to be switched on or off depending on the plan. It's not going to solve everything you need to do for entitlements right because there's still some building reconciliation stuff, but there is a really strong use case of just saying hey, once you handle the billing side just turn the flag on or turn the flag off based on the system or if I'm a free user. Just give me an access to a subset of features. It can really be if you think of it one way a way to turn your entire UX into sort of a configurable atomic system that you can turn on and off based on different conditions. So how many flags. Do we have in our system today. Oh at harness. Yeah. So you know it changes. It changes very very quickly but several hundred and any given week is probably the average and every team kind of does it themselves what they need for their product here. The other thing I would note right is that the flags are not just for engineers the flags are not just for me as PM, our accounts and support teams that harness use flags, because we make it very easy for them to use doesn't require technical skills to provide once you've wired it up to the account experience. So if you're my customer I'm a support rep. I can say oh you want to try this new feature or you want to try upgrading to a higher tier. Cool I flip the flag you have it. I don't have a whole bunch of complex back and stuff I have to do. We don't have to maintain a really heavy internal system to do that. We can kind of give that power to everyone in the org and we do here at harness and we have gotten rid a ton of admin portal code that used to exist by migrating this all over the feature flags over time. So if you build on that that piece of it really allowing account teams to be involved. Imagine for all the developers on the call here. Imagine a world in which an account rep says hey I need to extend a trial, or I need this feature turned on in my product. Imagine that you as a developer didn't need to be involved in that anymore, make database changes, you know check a bunch of config files to make sure that all the right stuff is being turned on nothing is wonky, just being able to say like oh you need to do it. Well, we have our feature flag system, just change their 14 day trial to a 30 day trial, you know turn on this feature and you have the control to do that now for your accounts. It's not something that's always easy to do. It also saves the rather unpleasant feeling of being a PM or an account rep or a support rep, and knowing you're interrupting some poor engineer who's trying to work on saying hey I know I'm sorry but can you please stop what you're doing and go turn this on over here for me. Wait it didn't work, can you check again right that doesn't feel good for anyone involved so it's also a way to just sidestep that. Yeah it's it's almost similar to that that operational run book in a way right that with a single flag suddenly you're you're controlling like a series of basically trick you're basically triggering a waterfall of events that needs to happen in order to make it work. And it's just, you just hit the easy button it's done. So, and again it comes back to that kind of change in how you may see feature flags today which is going from oh it's a way to introduce a new feature oh it's a way to introduce a button. Change a button change a color to it's kind of a really, it's really a way of working. Right, all of our changes go about behind flags, different people are going to control those flags some of those flags live for a long time some of them get removed in a very short time. Some of them are about giving them to customers some of them are just so we can learn the impact. So it's the full spectrum usage, but if your changes behind a flag you have so much optionality on all those dimensions that you just won't have without flags. Awesome. So, for the audience here that does bring us to the end of our five core use cases. If you do want to learn more about other sorts of use cases, how you might be able to use flags for these common use cases as kill switches for obstacles. If you have a QR code on the screen here with the little Google dinosaur that I happened to refer to. I promise I didn't remember the dinosaur was in the QR code. Feel free to scan that and that will take you to a blog written by Ethan himself. That talks a little bit more about kill switches and some of these other sorts of use cases you might be interested in. With that, let me open up to anyone that may have additional questions on the webinar here. Give you guys a few seconds to start putting those together. And we already have someone with a question. The first question I have for you Ethan. When is the free and team tier of feature flags for harness. It's available. I love this question someone already went to our website. They looked at our pricing, and they want to start using it. Thank you I appreciate you checking us out. Yep, absolutely appreciate it harness we do have a free tier so you can go in there today sign up and start using it. Today it's a free trial so it is time limited. So that's going to switch to an unlimited long term free tier so forever free tiered certain levels of usage. Since we're almost in January if you sign up now, you might just be able to overlap to where your trial ends and the free tier has shipped. I think we're pretty close. I do want to be clear that the difference between that that free trial and the free forever plan that there is a difference one gives you access to all the features for a set amount of time. The other one, you can use feature flags for anything forever, you know, obviously there are limits. We are a business. But do I just do want to be clear that you will be able to use harness feature flags free forever. Once that's live shortly. I have another question for you, Ethan. This one is from George. I somehow missed one. I'm assuming this is one of these cases. George got performance refactoring obstacles compliance and free trials. Maybe let me just zoom back. API is in back and there you go. So, this is really about the idea that there are server SDKs and you can use feature flags to control parts of your system parts of your infrastructure, not just the user experience, or the things customers interact with. So I won't necessarily repeat everything we covered but it's really about thinking about system migration and other types of back end work. It's also heavily covered in those blogs that Vargov link to on those slides so if you want more details on that I would recommend reading those. Okay, that helps George. I see another question that came in. What are the best use cases to start with. It sounds like this might be a question about these. These, these use cases we've talked about today. It could also be a question about even the common use cases and where we should start, not entirely sure. Yeah, so I really like this question and we get asked it a lot in my answer. I don't want to seem evasive. But one of the things sometimes stops people from adopting feature flags is they're asking this question what is the right use case to start. And there's always the kind of like oh we can't really think of a perfect use case right now. We'll ask around maybe another team has a good use case. What I would say is the right place to start is just put a flag around whatever you're working on right now. You may not know exactly what you're going to do with the flag. You may not know exactly why you want the flag. But if you're building a new feature, if you're making some kind of change, just go ahead and put it behind a flag. And when you get to the end of the development process for that feature or that change, you may say, oh, this is great that we have a flag we can test it out. So if you're not there, we have the option, or you might say we don't need to chances are if you have the flag if you have the option, you're going to say let's test it a little bit first, we can do this now we couldn't before. So, again, what I would say is there may not be one perfect starting point. Very oftentimes kind of simple UI changes are the easiest to get your head around. But if you're making changes to your code, you've got an opportunity to go add a flag and then just figure out later exactly how you want to use it, instead of trying to wait for the perfect opportunity. Yeah, with so many different ways to use flags. It's really a green field opportunity to just start trying stuff in my opinion. You know, not that you wanted my opinion you probably wanted evens. Another question. Thank you audience you guys, you all are really engaged really appreciate these these questions coming in. Are there concerns about security or customer data with future files this is a good one. The answer in short is it's really good to ask that questions. It's always good to ask that question so be mindful. And broadly across what we built at harness as well as the other vendors with pools in the space. I think the answer is probably no. So I think everyone in the space is a pretty good player in terms of security and privacy. You install SDKs in your app to use feature flags, the harness SDK, most of the other ones, they're open source, you can always audit them your security teams can take a look, and we don't collect any data by default. You have to send us data, and we're working on some stuff as well that you can even obscure what you send us. But I think generally it's the right question to ask the space overall I think has done a good job of taking that question seriously and making it in a way that you're not going to find much privacy or data risk once you dig in. Yeah, awesome that's that's huge, especially when we start thinking about all of the new data privacy and security laws being passed around the world, making sure that it's easy to stay in compliance no matter where you are. Cool, and then one more question here for you Ethan, how can I get more people in my company to use flags. Yeah, that's another question we hear a lot it's a great question. Particularly if you are using flags and it's exciting it's making a difference, and you just want everyone to start using them because now you're seeing everything that could be possible if more of your company would do it. This is another one where there's probably no silver bullet answer. The more you're using flags first of all the better. So going back to what I was saying about not waiting for the perfect opportunity. If you can go to other people in your company with case studies, if you can go show the company kind of the art of the possible, what you've done on your team that they can't do on their team. And if you can start to show the leadership the cost of that right. Here's a change that we turned off in five seconds with the flag, instead of 25 minutes with a rollback. Here's the refactor that we were able to test and find out that it's five times faster, and we wouldn't know how much faster it was if we couldn't run it side by side in the future flag right collecting those data points to really start to make it seem like, of course you're going to use it. It would be a bad financial and economic and output decision not to use flags, but sometimes you have to do a little work to quantify it. The other thing you can do a little work on is maybe just showing people how easy it is. Because it's, there can be a starting or a momentum issue right. Once you get going it's easy but getting going can be hard. So you can sort of be an advocate for we did it it took this amount of time. We had a flag working with a couple hours, and sort of be that leader and putting that picture out to the rest of the company. Awesome. Thank you for fielding all those questions Ethan that does bring us to the end of our time with everyone today. Let me hand it back over to Marisa and the Linux foundation just want to thank everyone again for joining us today. Hopefully this was an informative and eventful session for all of you. Awesome. Thank you so much Ethan and bar gov that was wonderful and thank you everyone for joining us today. Just as a quick reminder this recording will be up on the Linux foundations YouTube page later today. We hope you guys will join us for future webinars have a wonderful day.