#256 - FeatureOps: The Safety Net You Need When Shipping with AI - Egil Osthus

[00:02:03] Introduction

Henry Suryawirawan: Hello. Welcome to another new episode of the Tech Lead Journal podcast. Today I have with me, the CEO of Unleash, Egil Østhus. If you haven’t heard about Unleash, Unleash is basically like a feature flag systems, feature flag platform that is open source. Today, as you know, we’re gonna be talking a lot about the feature flags, FeatureOps, those kind of stuff. And especially how to use feature flags for AI based software system. So Egil, welcome to the show. Looking forward for this conversation.

Egil Østhus: Thank you for having me. I’m very excited to be on your show.

[00:02:36] What Is the Current State of Feature Flag Adoption Across the Industry?

Henry Suryawirawan: Yeah, so maybe in the first place, you mentioned Unleash is actually like a feature flag, FeatureOps kind of a platform, right? So I think feature flags has been around for quite some time. But I’m not sure how much adoption in the industry currently. Maybe from your view, from your customers or maybe from talking to a lot of people, what do you think is the adoption rate for feature flags?

Egil Østhus: Yeah, I would say, and you’re right, of course. The feature flag or the concept of feature flag has been around for quite some years. And when we talk to customers and we talk to professionals in the industry, I think it’s a concept that is quite well understood and so that we as a professionals know this is happening or this is something we want to do. But I would say the adoption is sort of very, it’s a big spread in variation, right, in the adoption, right. So I think what we are seeing is there is a lot of organization that don’t do anything, honestly. I think there is a lot of organization that do something. I mean, config file type of configuration sits next to your software. Is that a feature flag or is it not? It’s sort of, do solve some of the use cases that we can get from a feature flag but it doesn’t really solve them all. So we see a lot of those more simpler use cases or kind of the static config files that have early, very early type of maturity type of things.

And of course we also see organization very much mature engineering wise, so already operating according to this best practice. And so I would say it’s a big spread. I think one of the things we are seeing is, I would say a lot of organization are using this more as a tactical approach. Meaning it’s very much up to the individual developer or the individual team where we see it this sort of more as an enabler for kind of the strat, or a strategic enabler for the organization. So we are coming in with a different point of view, saying, okay, you need to think as, treat this as a more strategic point of view and less of you have this capability as a config file or do you have this sort of simplistic view? So I would say it’s a long answer to say there’s a big variation. And you have everything from the front runners that has done this for many, many years, all the way back to the laggards that is sort of still getting up to speed on this.

[00:05:00] Mailtrap Sponsorship

Henry Suryawirawan: This episode is sponsored by Mailtrap, a modern email delivery for developers. It offers straightforward integration into your code using their native SDKs, along with the security compliant API and SMTP support. Plus, you get 4,000 emails a month completely on their free tier. And the best part, they have 24/7 support where you actually talk to real people, not an AI chat bot. Try it out today at mailtrap.io.

And now let’s get back to our episode.

[00:05:32] Why Is Feature Flag Adoption So Challenging Despite Its Apparent Simplicity?

Henry Suryawirawan: Yeah, so I think it’s still quite amazing, you know, even though the practice has been advocated for quite some time. Especially with the, you know, like the CI/CD thing, right, the trend that is going on. So what do you think is the biggest challenge for people not adopting feature flag? Because conceptually it seems like a very simple thing, right? You define like maybe like a variable or a conditional kind of thing, and then you have kind of like a if statement in your code simply said, right? Like to actually evaluate whether you do something or not. But why does it take so hard for people to adopt?

Egil Østhus: Yeah, that’s a great question. I think, and you, of course, you’re right. I mean, in its, simplest form, it’s about the if statement in code and sort of, do you do this or do you do that? And what are the cohort that is having this or the other? I think the biggest challenges that we are facing is, it’s a lot about maturity and also willingness to operate differently than typically what you’ve seen or at least what has been in the industry for quite some time. I think one of the phrases I’m hearing quite often in, but when talking to senior leadership and executives is sort of this change of moving from a project mindset to a product mindset. And I think also the project mindset is sort of parts of what I do read or get from sort of the DevOps type of a way of operating. So let me explain this and sort of go a bit on what does this mean.

So to put it a bit, simplify a bit, I would say a project mindset is where the team, the organization is very focused around getting a very given scope. So project is a typically kind of scope type of focus. Deliver a certain given, pre-given scope and get that into production at a pre-defined timeline. So you have a time blocked, a period of time. It’s really important to get in production. And to put that scope or that sort of, those level, that type of feature, whatever into production in itself is the meaningful event. That’s what you celebrate or go live. It’s sort of you are super happy. So I think we can recognize this, either we used to work this way and now we are shifting towards something different or this is still how we operate. So we sort of, you have a scope, and that scope take, think of that as a feature on multiple features — written, tested, put in production. Go live is a very specific date. That is an important event.

The problem with this, I would say, is that you are forgetting the key purpose of what, why do you exist as a developer? I would at least, well, I would argue why you existed as a developer. Your job as a developer is to deliver business value or develop and deliver value outcome for your end users, right? So the product mindset, it’s less focused around getting that particular scope available in a production environment at a given date. It’s much more focused around are we providing the use case? Are we providing the business outcome, the value, or the, are we solving the pain that the end users is looking to solve? And I’m not necessarily stating as a, with a product mindset, you are not sort of saying, I’m also looking to understand and talk to my end users, get the feedback from my end users to iterate and improve. So I would say what we are seeing, and I think this is a fundamentally different way of operating your organization.

So if you are a tech leader out there, focusing on how do you define the scope, how do you work together with your stakeholders, your end users in understanding what are you trying to solve versus committing to, this is my scope. I will deliver this at this specific timeline at a specific date. That’s a fundamental difference. And I would say if you’re not having this mindset, if you’re not able, willing to allow your engineers to work according to this way of operating, I don’t believe that buying a tool will make a ton of difference. So it’s all around do you allow this to happen? How do you facilitate this? How do you commit to your end users, customers in your, we are operating a B2B type of environment. So that’s like very individual contracts. In a B2C environment, obviously that’s slightly different, but it’s the same type of of philosophy. It’s are you committed to solve the business outcome or are you committed to put a scope into production at a very specific timeline? And that is a fundamental blocker that I see in a lot of organizations.

Henry Suryawirawan: Yeah, I think it makes sense, right? Because if you define your work with a specific scope, if you don’t actually define like for example, if you wanna feature flag for something, right, you tend not to actually do it. And I think one of the main maybe difference as well in terms of operating is like if you don’t do frequent releases, I guess it will take lesser, you know, chance for people to, you know, have this feature flags because they think, okay, I will release on this date. I’ll make sure everything will be released by that time, right?

[00:10:44] How Does FeatureOps Differ From CI/CD and Progressive Delivery?

Henry Suryawirawan: Which brings me to the discussion, you know, you mentioned about this term called FeatureOps. And in the industry, there are terms like CI/CD, progressive delivery, you know, A/B testing, those kind of things. Are they all kind of like similar, interchangeable, or like how do you define each differently?

Egil Østhus: Yeah, so, CI/CD is a very important aspect of the DevOps. I mean, I’m not suggesting, and we are not suggesting by feature flags that DevOps doesn’t really make sense because they make- that a lot of, make a lot of sense, right? It’s absolutely what you expect and what you would look for is making sure that your developer is also taking care of the operations of the software, right? It’s, you are accountable for what you, what you build is so what you are accountable for and, and eventually either yourself or eventually the AI agent is getting the notification when there is an issue, and you need to make sure that that issue is sort of solved within as quickly as possible.

So the fundamental of DevOps doesn’t go away. But again, as I referred to in my past parts or the other part of the conversation, the DevOps in itself is very much super-focused and laser focused on how do you get software from the developer into production. What we are saying is that that is critical for operating an efficient software development lifecycle pipeline. And of course the CI/CD and all of the automation that, that’s part of the tactics that you need to have in play. But when you are getting into that level, what you need to think about is how do you get your developers closer to your end user, and how do you get into this continuous delivery of business outcome.

[00:12:26] What Are the Four Core Pillars of FeatureOps?

Egil Østhus: And this is where the FeatureOps come into play. And basically what we’re saying is that, so maybe break down the FeatureOps. It’s about the gradual rollout. So this is something you can do with feature flag. Sure. I get that. It’s also about full stack experimentation. And what we talk about with full stack experimentation is that we have seen AB testing and that type of conversion rate focus. You know, it’s a well known in the industry, but we are looking at this as a holistic, a 360 point of view, saying when you build software, it’s about the engineering best practices and engineering optimization. There is also about the business outcome. This is the typical A/B testing, right? And by the end of the day, you also have end users. We believe that there is still end users, a human beings, even the AI a lot that is consuming software. So to develop software that is consumed and easy to operate or kind of be, I mean how used (by) your end users is still being super valuable. So that’s typically the end net promoter score, customer satisfaction score, that type of a measurement. So all of these three together is coming and educating how well is your software operating. So that’s the 360 point of view, which we refer to as a full stack experimentation.

And the last pillar that is important for us is what we refer to as the surgical rollback. Fact is that we’re seeing even in the AI-driven development, issues are put in production and issues have real impact on businesses. We all remember the Cloudflare outage that was a few months back now and Google outage back last summer. And we will still see those, right? So having issues in production even though it’s quite quick to redeploy your image into production. The nature of the distributed softwares out there in the world is still makes a ton of time to really come back from such an outage. So the surgical rollout is basically to allow and make sure you have the kill switches in your software to very rapidly turn off parts of the application in case there are these type of challenges. And of course, also if you look at this at a, as an enterprise level where where we operate, you need to have a, like a fully solid governance and privacy capability in place. You need to make sure that it’s all kind of tied back to your requirements for your industry, if it’s whether you’re a financial or other parts.

And on top of that, also what we referred to as the feature management or FeatureOps control plane, sort of the life cycle of everything. And I think you alluded to it, the earlier conversation, sort of how do you make sure also that you keep this under control, that you’ll keep cleaning it up. Because by the end of the day, it’s like if statement, you know. Code if statement is great because it’s simple, but at the same time it creates unnecessary complexity. And I still believe that clean code is what we are striving for. So having support in the platform to make sure you are cleaning up after yourself is still important. And all of these concepts is coming together, what we feel called FeatureOps and, and, and it’s sort of, allowing this transformational shift within the organization to happen.

Henry Suryawirawan: Yeah, so I think definitely makes sense. So for people who have experienced having system that enables this kind of like feature flags kind of capability, definitely you can do gradual rollout easier, you can do a lot experimentation like A/B testing. And also like the rollback, I think this is probably is a bit underrated, right? Because when issues happen, if there are issues like errors or whatever that is, right, you can actually switch back to the, you know, previous version easily. Just like when you mentioned about kill switcher, it could be as an instant as possible, right?

[00:16:11] How Can Teams Shift the Perception of Feature Flags From Tactical to Strategic?

Henry Suryawirawan: So I think I was kind of like taken into curiosity when you said in the beginning, some people still treat these kind of feature flags thing as a tactical thing rather than a strategic thing. So tell us how can we start shifting our, you know, perception or thinking to making feature flags more like a strategic thing.

Egil Østhus: Yeah. It’s a great question. I think there, it, again, these type of questions usually have the best answer saying, it depends, right? It sort of depends on the organization. It depends on who you are and how you operate. So it’s, I’m not able to kind of or I’m going to spoil you. I’m not going to give you like, this is the silver bullet and how they operate this independently of organizations. So that is obvious. But it’s sort of, there are some some key patterns there, right? So when you think about this, this is basically about change management, right? So change management is all about how do you move individuals, organizations, teams from this is how we work now into something, we’re doing something different, right? And there are some models, some kind of key takeaways there. You need to stall if — so if there is an external factor, there is like a massive like, I don’t know, we had a massive outage, we need to rapidly change in order for making sure this doesn’t happen again.

So the crisis is the best enabler for a change. But let’s assume that is not the case. Let’s assume that we are sort of in this sort of status quo. We are evaluating, we want to push ourself. We are, I’m a tech leader. I want to kind of move my team towards something that makes sense and it, it’s the the thing to do. So basically what you, what I’m seeing working the best is you need to identify, okay, where do you have your supporters? Because there are always somebody in the organization that is sort of hungry to do something different, hungry to learn, hungry to challenge themself, really kind of always want to do something new, allowing them to be successful. And of course, start small. Don’t try to make this sort of into a big, massive, everything is changing, at a given date. But sort of start small.

And and, find those supporters, start it small, and also make sure that you are very — It’s… Early success is your biggest champion in your organization because everybody wanna join a winning team, right? So what you will face is that we are getting this, okay, I am, let’s assume I’m a tech leader. I want to kind of get my organization to move from this to the other. I want to get this to work. So I’m identifying some of my champions. I’m allowing them to get to start small. Maybe you wanna start in an area where if they fail, it doesn’t really have a dramatic impact. And soon as these team or teams or or whatever are starting to gain those or have those wins, make sure to celebrate. Tell that story. Tell that story, and make that easy shareable within the organization. Because then what you will see happen is that you are turning those sort of skeptical people or kind of blockers or pushback individuals coming back saying, oh, this is sounds to be interesting. They’re doing something smarter. And they start kind of be in intrigued and interested, and then you start having this positive impact mechanism that is happening in the organization. So I think that is my best advice. Start small. Identify a champion that is willing to run with you and make sure that you do whatever it takes to make them successful. And tell the story and not, don’t, you don’t need to tell the story, but let them tell a story, let others tell a story. Let people be successful.

And, you know, there is another organizational hike, because the more executive support you can get, the better. And typically everybody in the corporate is sort of super focused on delivering on their KPI, you know, there is a performance review coming up. There is a certain level, so the better you understand what gets somebody promoted or gets somebody kind of in that high level, high edge performer type of bucket, you can speak to that. Hey Henry, what about if I supported you on being very visible on delivering on this KPI that is important for our organization or in our company? What if we try this? I think that will allow you to really share that with your team and with your organization and you’ll be kind of really good fit for a promotion and I’m pretty sure you will be super happy to work with me on this project because that’s basically what the organization is set up for doing right.

[00:20:46] How Do Feature Flags Align the Needs of Developers, Product Managers, and Marketing?

Henry Suryawirawan: Yeah, thank you for the such tips, right? So for people who want to adopt this kind of like, ability, right? So I think start small, you know. And it’s so much, I mean, hearing what you say, right? It’s so much a cultural thing rather than, you know, just technical thing. Because many people might assume that, you know, implementing feature flag is kind of like, okay, it’s a technical thing, right? You can just put it in your code, you know, and all that. But I think we all know as practitioners, that’s not true because, even if you just wanna put a feature flag, right, sometimes it involves, you know, like first, product manager to decide, okay, which part that we can put as a feature flag. Maybe you wanna do experimentation, maybe you wanna do gradual rollout, those kind of stuff.

And sometimes also it’s about the, you know, the organization level, right? Because there’s this thing called, you know, decoupling release from deployment. You know, maybe the organization decide when we wanna, you know, roll out this feature as part of the roadmap. So maybe tell us, you know, this aspect of importance of culture rather than technical for implementing feature flag.

Egil Østhus: Yeah, you are, you’re spot on and you’ve definitely nailed it there. So yes, I would say in the organization there’s multiple points of view, right? There’s multiple needs. So the engineering team, the developers, they need to get this in production as soon as possible, because basically what is important to them is to get it in the real production environment because this is where the real fun starts, right? This is where the real, this is the real thing. The product management is typically more concerned about is it feature complete enough for my end users? Is it sort of, does it deliver on the promise? So it’s sort of in between and usually I find also the marketing team is sort of the last type of thing, is sort of, oh, there is so many changes. How can I keep up with everything? How do How do I organize my marketing spend, my marketing events, all of my sort of what I care about into a stream of very small changes that even maybe the customer doesn’t really, really understand. So all of those are different points of view. And maybe also you have a customer success organization even that is sort of saying, okay, this customer is really upset about this, what happened in the past or this is where we have a really good relationship. I want to kind of keep building on that relationship. So different points of view.

And I think exactly what you’re saying there to decoupling release to production to release to the customer is exactly solving all of those needs. Because you can allow the developer obviously to put, keep putting there in production to really make sure that I’m getting the feedback that all of those, whatever I need to get to be super efficient and what I need in order to be a successful developer. Where a product manager can say, okay, let’s work with a very small cohort of customers, where I know we have a good relationship. Maybe that is the overlap with the customer success team or maybe not. Again, it depends on organization. And so the product manager can start doing a great rollout or very kind of cohort based role of saying, okay, let’s do this enablement for a very selective use of a number of customers. Where the marketing team is having a different point of view where when do I go live? Maybe I need to kind of go live to everybody at a specific point in time because of, you know, I’m at this event, I need to do an announcement or whatever.

So all of this is coming together and sort of saying, this is an organizational need. It’s not a developer need. And I think this is also where, when we started I was saying I see this in a very many organization is considered to be a very tactical capability primarily for the developers. And I think this is also pointing to the fact that, I think the organization hasn’t really been trained enough or maybe aware that this is actually an opportunity that they can leverage from. And I think we see the front runners in the industry, of course, is already leveraging this and it’s already operating according to this way. So, again, it really comes back to the engineering maturity of the organization.

Henry Suryawirawan: Yeah. So I think definitely makes sense, right? So when you say it’s a strategic thing, right? Now we can understand why exactly. Because you would involve PM, you would involve marketing, you would involve organization to make the decision how do you roll a feature? How do you turn off feature and all that, right?

[00:25:09] How Do Organizations Effectively Define Responsibilities for Strategic Feature Flags?

Henry Suryawirawan: So I think maybe let’s go to the like kind like practice point of view. I don’t know what’s the best practice out there. Maybe you have seen it in your, with your customers. So how do you actually define the responsibilities for defining a feature, right? Is, because if you said it’s not just a developer thing, does it mean like a PM decided or does it mean someone else? And how does also the decision in terms of like turning it on, right? Or turning it off. So maybe some best practice or maybe some variance of it. Like how do you see the practical thing, how these features are being defined?

Egil Østhus: So you’re absolutely right. It starts very early and typically it would start in the product management level, I would say. Sort of this is where we start putting together some release strategy. So the in my context there, just kind of gives some insight there, my product management focus or kind of definition is a very commercial role. So it spans also into product marketing, marketing management. So, and, and sits very close to the product team, sorry, the marketing team, the product marketing team. But also obviously very close to the engineering team. So what we are seeing, I would say the best sort of best practices out there is when you start building new features, like start thinking about how do you wanna test roll out kind of the release strategy very early.

One of the beauties whether that we have defined in our product is also to create templates of how you roll out those features. So basically saying in your playbook of working with software, you have maybe 3, 4, 5 very specific release patterns that you’re applying again and again and again. So that’s something that also we are seeing being adopted more and more. Which basically means that when you start thinking about, okay, what I’m building, this is maybe I’m doing a gradual rollout, I’m rolling it first out to my VIP customers. Maybe I’m having a close relationship with this five to seven close customers, then I’m doing this, then I’m doing that type of thing. And that is sort of repeatedly we handled and apply to the development process.

Henry Suryawirawan: Yeah. So I think definitely, you know, if possible we plan it as part of the feature, right? So maybe PM could define it. And also what you mentioned, the important thing is like you have to define how do you wanna test the rollout of this feature, right? So having templates maybe is something that is useful, right? If you know that, you know, all the time you have like a really strategy, you know, I think that will be very useful.

[00:28:03] Does Using Feature Flags Enable Your Team to Deploy on Fridays?

Henry Suryawirawan: So I think one other things that I think, I mean jokingly this kind of use case, right? Because many, many development teams always avoid releasing on Friday. Does having feature flag actually enable you to have more releases on Friday?

Egil Østhus: It does. Actually, our slogan when we started Unleash was “Badass developers release on Fridays”. Because you don’t release on Fridays and we think that it’s just a stupid thing to not do so well. But then again, it’s, I understand where the joke comes from because I think we have all been burned on working late, late hours on a Friday and into the weekend. And, you know, that’s not a fun thing to do. So, but yeah, it’s definitely, I would say there should not be any reason to not release on a Friday, right? But then again, it depends, right? If you are kind of very, this is a fresh idea, you already kind of all like you have just finished your automation of the CI/CD or you kind of just getting up and running on these and you may be releasing on Friday is not the first thing you do.

But basically if you do this in a proper way, I mean, you know pretty quick if you’ve made some mistakes. I mean, yes, we are seeing that the issue is sort of hidden very well deep and, and it’s a very, very much a corner case. You don’t control them anyways, but most of the time when you have an, you need to do a post-release fix or deploy post, post-release, it’s typically happening quite quickly after the release. So in your, if you are wrapping your changes in the feature flags and really make that adoption into sort of a gradual rollout and/or kind of a kill switch type of scenario, you know quite early if this is working or not, then if it doesn’t, you can always, you have the measures and the safety net to, to go back to a last known stable deploy of your code.

So, I mean, yes, I get your, your joke in saying this is not what you wanna do. But then again, I would say, well, this is actually what you wanna do and strive for because I think that’s, that joke exists because of all of the good reasons of why am I doing this. And then again, that speaks to you don’t have the safety net in place in order to make this happen.

Henry Suryawirawan: Yeah, I was saying like safety net definitely is like the keyword here, right? So if your development team is scared of deploying on Fridays, especially before people going home, I think you don’t have safety net to actually kind of like roll back maybe or make changes fast, right? So I think that’s a very key, important aspect of a good software development team.

[00:30:41] What Is Unleash and How Does It Scale for Enterprise Needs?

Henry Suryawirawan: So maybe now it’s a good segue to talk about Unleash. So tell us more, what is Unleash? And you know, what does, you know, what kind of features does it have to help us?

Egil Østhus: So Unleash is the largest open source FeatureOps platform that is available in market today. So all of the use cases, all of those scenarios, all of those kind of capabilities that we talked about is available and of course much more. I, it’s also the, it’s the platform for the large enterprise needs. So what does that mean? It means that we are highly flexible adapting to any type of tech stack, any type of scenario. So, and because it’s an open source platform, it can really be twisted to any needs. And we have been very focused on building a platform that really, really scales to the, like the millions and billions of end users. So we are working with some of the biggest and most interesting companies on the globe. We are working with companies such as Lloyds Banking Group. I think they are 25% of the U.K. GDP is going through a Lloyds system, so that is a massive operation. Wayfair is one of the biggest e-commerce players in the U.S. So again, Black Friday and the Black Week is a massive, massive event for Wayfair and we have worked very close with them in order to make sure that Unleash is supporting them through that very, very speci- important time of year where they make a ton of money per minute.

All of this is what is Unleash. And also, we are very well-integrated into all of those audit logs and audit trails and all of those kind of legislation capabilities that is needed in this larger organization. I mean, as an end user or kind of an end dev or a software engineer, you may or may not be super well aware or maybe you are, or maybe you have an organization that is good to sort of allow you to be operating without being super detail-focused around all of the compliance requirements, but we also are working with comp, like a massive organization such as Prudential which has a high, high number of requirements that are similar with Visa. Again, a large organization where there’s security measures and all of those resiliency and compliance parts is really, really important for them.

So the beauty here is that we are able to do all of those capabilities and integrate into those compliance processes or needs at the same time that not complicate the process. Because I think that is often what is, what you’re seeing or what you’re facing, or at least what you are afraid of happening, is that you are saying I need to stay compliant. I need to be able to have the audit trail. I need to be able to have all of those proofs in case, in case something happens. Or, you know, that’s just the world I’m operating in. I cannot sacrifice. I cannot go compromise there. So a lot of the customers we are working with, in particularly in the financial industry, are saying I need to make sure that I don’t compromise here or they are expecting that we are saying you need to compromise some of that. And by doing this, the beauty here is that we are able to connect those together in order to make sure that this is happening and you are allowed to operate as, you know, the smaller digital-first startup type of organization, at the same time staying highly compliant or has staying compliant according to your needs.

So that is what Unleash is. It’s been around for many, many, many years. I think the first line of code was written back in 2014, ‘15 or so. And we have been developing this as an open source for many, many years. And now we are sort of working with those large organization in order to support them in making FeatureOps as a strategic enabler for how they operate their software development or operations.

[00:34:54] What Are the Hidden Dangers of Building Your Own Feature Flag Solution?

Henry Suryawirawan: Yeah, having open source that can really scale with all this enterprise capability like, you know, audit logs, compliance, all those things definitely sounds great. Because I think in the market, I mean looking at the other alternatives, many, many other solutions are actually quite expensive, especially if you wanna subscribe with, you know, millions or billions of, you know, kinda like events, evaluations, those kind of thing. And at the same time, because of that, some team actually prefer rolling it out on their own, you know, building a custom in-house solution because they think simple, right? ‘if else’ kind of thing, like a config file, maybe we do it in runtime, those kind of thing. I can just simply create a backend service for that. So tell us the danger of doing this, what kind of risk that people are not seeing if they wanna roll it out on their own?

Egil Østhus: Yeah, so it, we have done quite some research here. And I think the challenge in this, this area of this category is sort of that it’s a very simple problem to understand, right? As we talked about earlier in this conversation, sort of it’s eventually, it’s an, again, its purest form is an if statement. And that if statement triggered by, it needs to be triggered by some input fields, obviously. So it’s an easy problem to understand and, you know, beauty with the engineers, but that is maybe also sometimes the curse is we are builders, right? Developers are builders. We love to build. And when we need something, if we find it either too expensive or it’s too complicated to get the budget approval or, you know, there’s so many reasons why this is like not something…

I don’t, I haven’t really met a very, like any developer that is saying, oh, I’m super excited to go through this sales process and get their budget approval for my management. It’s like, that just does not, I’ve never seen that. Maybe they exist, but I haven’t met them that often. So basically sort of, ah, it’s too tedious. I can build this. And they can. They can get started. The problem is basically that, yes, it’s easy to get started, but the complexity lays into getting it right, getting it right every time, making sure the audit, the all of those… It’s resilient. It’s always happening or very like the determenistic piece. So the complexity is in a scale on the size. It’s not on the purest form.

So what we are seeing when we are out in the market is that there is a lot of, engineering organization that has started to build this. And typically they come to us when it’s getting too expensive, too complicated, it doesn’t really work. Or even worse, it cost outage. I don’t want to drop names here but we have had customers coming to us saying, we need to get out of my homebrew build, feature management, whatever, or feature flag system. It created issues. We lost revenue like big time. How quickly can we migrate over to your, you guys? And that’s what they’re buying, coming to us. They know that we are resilient. They know that we are able to operate at scale. They know that we are highly capable of doing all of that privacy, compliance pieces. We are there 24/7 to support them at any needs and at any time. We are there also to make sure they have all of that needs for rollback access control or that security measures that you need to have in place in order to operate in a corporate environment.

So and this is also what we’re seeing, that when you are starting with a very tactical approach, I just need like a simplest, purest form, you start with something simple, you build for yourself. And then you, when you start looking at this from a more strategic point of view, you start seeing, okay, this is too important to go and build for yourself. And also frankly, we are seeing pretty big teams supporting their implementation of a feature flag. So then again, is this your core business? Is this where you wanna invest your resources of getting a competitive edge? Or is this where you want to go out in the market to our one of, to Unleash or to one of our competitors to say this is is too important for us to spend our best engineer heads to spend the time building when it already exists.

Henry Suryawirawan: Yeah. So I think definitely what you said makes sense, right? It sounds simple as a concept to understand, right? The developers, we can all build something like this, right? But I think the problem comes with complexity, the kind of scale, right? And especially if it becomes like a very core thing. Because if you imagine every request that comes in, it has to be evaluated by the system, it becomes like a very critical piece. And if there’s any issue with this component, right, definitely you will kind of like, you know, make things suffer for all the other components as well.

[00:39:32] Why Are Local Evaluation and Privacy Core to Unleash’s Design?

Henry Suryawirawan: So I think in Unleash you have these two unique features that I think worth to call out, right? One is actually local evaluation and the other one is actually maintaining privacy. So tell us why these two features are kind of like, you know, main features or core features that Unleash provide. Like what are the importance of these two?

Egil Østhus: Yeah, so the local evaluation, and also if you go to our webpage we, sometime back, we published what we call, basically a sort of a high level what you need to think about when you, when you build a large scale the feature management platform? So one of the key con, key concept is sort of you need to make the evaluation happen as close to your application as possible. So one of the things that we have bit spent a lot of time thinking about is sort of saying, okay, we are putting an SDK into your application, right? So what is important for us is that when you start building and using feature, feature flags or kind of our capabilities, all of those strategies that we can provide you, that doesn’t really impact the execution speed of a code. Because we know that the, or at least I’ve seen when net promoter score is dropping, that is typically because if the application is not responsive, if it doesn’t operate on a consistent way, that is having a massive impact of your net promoter scores, so you don’t wanna make sure, we wanna make sure that it doesn’t happen. So local evaluation is basically making sure that you make the decision of what type of experiment or what type of feature strategy are you applying to this individual cycle. And you need to make that as close to the execution of the code as possible. So that’s sort of local evaluation.

And also the privacy of things. I mean, when we started to build this, we were, you know, Europe were in this GDPR, kind of early days of the GDPR. So we need to be compliant with that. We come, we are born out of Europe. And I think that also with the AI coming into this world, I think there has been an increased awareness of, okay, data actually make a difference. Data is an asset, data is important. We need to be very careful of where does that data flow, and where, and who has access to that data. So for us, it was very important to design a system where data didn’t flow back to these, to the backend engine. It’s sort of happening locally with the application, because from the security point of view, from a scalable point of view, but also from the privacy point of view, that makes it very simple for the end users, for the customers of Unleash to make sure that they stay in control, that they are in control.

And I think that is also the beauty of being an open source vendor, because I think that these days, with the latest events that is developing globally, trust is really put at risk. Like trust is something that is starting to, you know, be challenged first. Open source is the ultimate trust. It’s sort of you, I can tell you my story, I can tell you how I design my system and you can take my source code and inspect if what I’m saying is true or if I’m not telling the full truth. So what you would be able to do is basically saying, yes, I am in control of the data, I am in control of where the execution happens. And also I can go and inspect and build trust in you as my vendor to understand and really believe that what you’re saying is true. Because I can really inspect. So you can listen to what I’m saying, but you can also inspect with itself that what is happening is real. And I think that is something that SaaS vendors out there is not capable of doing.

And I would say the last part that you did mention, but you were briefly stating, is also this nature of our flexibility when it comes to deployment scenarios. So back in the early days of SaaS, everybody was moving to a public cloud. That was sort of everybody needs to go there. Unleash, because of the nature of how it’s been built, is sort of saying you can basically deploy this on your cloud, in your private cloud, in your hybrid cloud, in your public cloud even. Or of course we also have the SaaS offering for you if you want to go and consume it as a traditional SaaS play. But by the end of the day, it’s sort of allowing you to stay in control on the privacy side of things, where do you need to make sure it’s being deployed? And we have definitely customers saying, I mean, in particular now lately, the military industry is booming of — sadly, I would say — but still, that’s the fact. So working in this type of environment, having like a 100% full control, where is the deployment happening and who is in control and have access to this is a massive differentiator. So that is also one of those areas where we are unique in the markets.

Henry Suryawirawan: Yeah, I think definitely it’s unique, right? So having the ability of having low latency, you know, to decide whether a certain thing, you know, is on or off, right? And also like the privacy thing, right? So if I understand correctly, that means your data only operates in the data plane itself, right? It won’t be, you know, sent to the control plane, right? The FeatureOps plane management itself. So I think that definitely is a key thing, especially if you wanna adopt, you know, the SaaS model where you don’t want data to leak out to the vendor.

[00:44:48] How Does the Rise of AI Impact the Evolution of FeatureOps?

Henry Suryawirawan: So I think the other thing that is happening in this world lately is definitely AI, right? So what do you see the ability of having this FeatureOps thing with, you know, the trend of AI increasingly, right? So is it something that is helping or is this something that is just, you know, like, you know, like irrelevant?

Egil Østhus: Yeah. So I think, I think that’s sort of, it’s, obviously this is an obvious topic. Everybody’s doing or starting to do agentic development these days, right? So what we’re seeing on the short term here is what happens with agentic development, basically that the SDLC is speeding up. You are creating more software quicker and deploying more frequent because of this. But you still need the guardrails. You still need sort of to, the issues, the possible issues and the impact of issues doesn’t go away go away. So, we are seeing that for us, this is a massive opportunity actually. Because when you are putting more through your SDLC pipeline or kind of putting more software to production and there are either an equal or even what we’re seeing some studies, I think the DORA Report from 2025 was sort of indicating that the number of issues because of the AI adoption is slightly increased. I think it’s increased by 7%, which is when you increase the end, obviously that’s getting into a significant change. That is currently what we’re seeing.

So the FeatureOps story is even more important in the AI world than ever before. Because what you need to make sure is that you have really strong, solid foundations of how do you release the software, how do you kind of have that surgical rollback. And also how do you me measure those 360 full stack and experiments in your environment. And also we are seeing that, and of course this is also a risk that comes with AI. I mean, everybody has tested the AI prompts. Some is very, very, again, forward running it behind — sorry, ahead of everybody else. And it’s more complicated in this, usage of this. But you’ve also seen, we have seen this ourselves. And also part of that the stories of the AI hallucination, starting to write something, do something that is, doesn’t really see, feels right or isn’t really even accurate. That also happens in the source code development. So this is also for you as a software engineer, as an engine tech engineer and, and a tech lead to make sure that you have your AI guardrails in place. Because you are eventually still responsible for what happens even. And I think also what we talk to industry leaders, and we talked about to senior executive members, what they’re saying is that AI is important, but what really makes my kind of judgment is sort of the blast radius independent of is written by AI or a human being. When So basically what they may mean is if the shit hits the fan — when I’m not sure if I’m allowed to say so in your show — but if, you know, when something goes wrong, what is the blast radius of that issue? Is that a big, massive kind of impact in all of my end users, or is a small thing? So that is important that is top of mind. That is not necessarily, is it written by AI or a human being. Because if that happens, independently of who to blame, sort of speak, or who was sort of causing that issue, you are still responsible of making sure that that is having as least blast radius as absolutely possible.

So that’s sort of what we are moving into and what the organization is looking in today. So if we start looking a few years ahead, because you, I’m seeing this. I mean, we all feel this speed of the AI and we are stewing to get the, again, AI and sort of having that AGI type of thing in at our disposal or having available to us. So I think the interesting part there is sort of what is happening in the software development industry when this starts to be through the — I mean, today we are afraid of security issues being introduced or kind of like simpler issues being introduced. Eventually AI will be smart enough to take away, if all, a very high percentage of those that will decrease. So what happens in this scenario is that AI will be eventually be responsible for making a lot of micro decisions within the software. So AI autonomous will make decisions that impact your code. So you as a software developer or kind of a soft, system engineer, whatever you want to call that, you are further and further away because you’re not in a day-to-day writing the software yourself anymore by hand. You are more kind of doing this on a second level.

And I would say that the, some of the challenges that we — the challenge that we as human beings, part of the software industry, I believe that human beings will still be around in the software industry a few years from now. So the challenge we are facing is that we need to make sense of all of those micro changes that has happened out there, right? We need to understand what is going on behind the scenes, what is happening among all of those AI agents that is operating on my behalf. So what we are going to see, and I think the, the first one that is, one of the first that I was sort of talking about was Jack Clark, one of the co-founders of Claude would sort of, what we’re about to see is this introduction of the, or kind of the emerging of the oversight layer, the layer of understanding what happens in my software development process when all of the agents are autonomous making the decisions on its own, given the guardrails that I as a software human being, software developer being a human being decides. I think also the part of this picture is also the shift of software engineers is more understanding what is the guardrails, what this sort of, what is the context of how to develop software on behalf of my organization, my company. And not, obviously not the writing software by hand anymore. So I think that this is a shift that we are going to see. And how I see it, Unleash is a perfect spot of being that authoritative voice of what happens within the software releases. Because we sit exactly in that point. We are that tool that has that capability to allow it to happen. And again, I think this is where we are currently heading. So I’m very excited about the future of the industry.

Henry Suryawirawan: Yeah, very exciting the way you explain it, right? Because I think we all know how capable this AI and this AI model is. Every day seems to be, you know, getting smarter and smarter, bigger and bigger, right? And I have seen, you know, many, you know, blogs, maybe tweets or those kind of things where people, you know, write code in multiple agents, you know, sometimes even not looking at the code. So I think we can definitely foresee a lot of, you know, changes being rolled out more, even more to a software, right? And I think having like a FeatureOps platform as like a safety net to prevent, you know, that blast radius is actually very, very important, right?

[00:52:02] What Specific Guardrails Does FeatureOps Provide to Improve Safety?

Henry Suryawirawan: So you mentioned about guardrails. Is there any specific thing that the FeatureOps provide you to improve the guardrails? Or is this something that totally, you know, different altogether?

Egil Østhus: I would say this is where we are. So in our platform today, we have all of those guardrails in place when it comes to leveraging sort of different signals, different data, different whatever. But obviously also as we are moving into this sort of the future to be, which is probably earlier than we believe, we have keep developing Unleash into this and being that authoritative voice. So I would say we, today, we are very much adaptive. We are very focused on delivering what our customers needs today, and we are evolving into this future state. We also are building in type of AI driven capabilities of cleaning up and making kind of independent release — sorry, decisions. And so it’s all there and it’s sort of, it’s an important investment area for us in the future. But we already sort of support this guardrails on the, in the forum that we talked about in this conversation for sure.

Henry Suryawirawan: Yeah. And do you actually see, after having all this agentic coding capability, right, that the number of feature flags actually will be increasing? Or is it stay the same? Or even less because people just don’t care about feature flags anymore?

Egil Østhus: The trend that we are seeing is that it’s definitely increasing. So we are seeing a steady increase on on the number of feature flags and we count it as feature flag per developer. I don’t, I think that is a metric that we need to redefine because of the emerge of AI agents. But it’s the number of, the absolute number of feature flag is definitely moving up. I think that is a bit of a sad news because we want a clean code for our customers, so we also need to take away those, cause feature flags that is less or not relevant anymore. But it’s definitely increasing and I think we will see an even steeper increase in the numbers as we are seeing more AI development or AI agentic development coming to the industry.

[00:54:21] Can FeatureOps Platforms Use AI to Autonomously Manage Feature Rollouts?

Henry Suryawirawan: Yeah, I think speaking about agentic capability, right? I also foresee that, you know, the FeatureOps platform itself can have this agentic capability as well. Like for example, like seeing, you know, after release being rolled out, you know, the AI can actually see the traffic, look at observability, look at the different metrics and make decisions whether to enable or increase the rollout, those kind of things. Is this something that you also foresee happening and what’s the trend, the likeliest trend that this will happen in the short time?

Egil Østhus: Yeah, no, this is something that we partly, I would say we support this already and we are keep investing in this as part of our AI’s narrative. So this is already here. I don’t see this being — We are starting to see customer really adapting this. But then again, this is, my read is more about, okay, do you trust this? Do you kind of, is this sort of consistent behavior, is this something where I wanna trust my AI agent to do this? Or is this something where I kind of wanna be, you know, having a human in the loop? Because of by the end of the day, I’m still responsible for the blast radius that is happening there. But this is already available on our platform.

[00:55:33] What Essential FeatureOps Advice Should Every Vibe Coder Follow?

Henry Suryawirawan: Yeah. So one other aspect that I would like to maybe seek your opinion, right? Because a lot of people now doing vibe coding, right? So you know, all non-tech, maybe also developers, right? They can all do vibe coding. I think so far that I can see there are less people talking about vibe coding and also building like feature flags, you know, building those safety nets. You know, everyone just optimized for speed, you know, being able to deliver code really fast and just deploy to production. I think the aspect of, you know, I don’t know, like feature management, those kind of stuff, probably lacking. So what kind of advice do you want to give to, you know, those vibe coders, especially in regards to this FeatureOps, feature management?

Egil Østhus: Yeah, it’s a big question because vibe coders is so, I mean it’s so many different things, right? It’s everything from the hobby developer that is want to test some great ideas and see the possibility there to sort of enter large enterprises, product management, different, and so what have you. I would say the needs of the FeatureOps doesn’t go away. I think the latest trend or the latest wave of vibe coders has been very much like everybody’s amazed on how much you can get done in a very short period of time to get kind of, you know, get up and running and, and build your — I mean, I’ve been talking to in this building like CRM system in a week and sort of these things. Which is probably true, but it also definitely is not the full truth. So basically what we’re seeing is that this is very heavily focused on a day one, meaning getting up and running and getting off the starting blocks. But the day two is less so talked about what happens when you are in production, when you are getting into scale, when you are getting kind of into the core system.

I think eventually as we discussed, AI will also be able to disrupt a lot of those areas. But the guardrails, this sort of need for make the sense out of what happens doesn’t really go away. I don’t think that is happening. So I would say it’s super exciting to see all of that vibe coding happening. But also then again, you, if you are kind of building a large project based out of a vibe coding environment, you also wanna make sure you have some of this in place when you get to the day two, day three type of situation when there starts to be serious business around this. And I’m not suggesting that you cannot build a serious business around this because I think that has been proven again and again that there is a lot of opportunities there. But that’s still important to have in mind that you need some guardrails in place in order to make sure you are in compliant, that you are sort of, in a, position to make sense of what is happening there. So I think that’s my best advice in this area.

Henry Suryawirawan: Yeah. So I think definitely — also it depends on the context, right? If you just wanna build a one shot application that is for a small needs, probably don’t, you don’t need it. But if you are building some software that is, you know, evolving, so I think having this, you know, foundation in place will be very, very useful. Especially you’re talking about day two operations. If, who knows right when you churn out more and more code that when there’s an issue happening, you wanna be able to roll back fast or turn off of certain features really fast.

So Egil, I think we have covered a lot of things, you know, is there any other things really important that you wanna talk about? Maybe from FeatureOps, maybe from Unleash or maybe this agentic AI trend that is happening.

Egil Østhus: Yeah, no, what I think we have covered a ton here. And I think there’s a lot of information to digest anyways, but it’s definitely, it’s a very exciting moment of our history. We are definitely moving and we are living in the kind of emergence of what to come. It’s a disruptive point in time for sure. But I would say I’m seeing, I mean, there, I’m seeing this as a massive opportunity for engineers and for the tech people. I mean it’s almost frightening how important technology starts to be in our world. So it’s a great spot to be in and it’s a great opportunity to be an engineer for sure.

[00:59:53] 3 Tech Lead Wisdom

Henry Suryawirawan: Yeah, very exciting indeed. Although sometimes it’s scary, given the pace of the changes, that is introduced by AI. So Egil, as a tradition in my podcast, I would like to end by, you know, asking you this question called the three technical leadership wisdom. You can think of it just like an advice you wanna give to the listeners. Maybe if you can share some today, that would be great.

Egil Østhus: Sure. So I spend my fair share of time in tech leadership roles. And I think that more and more, it’s sort of tech or leadership, I keep coming back to leadership more than anything. So obviously the most obvious one, makes sure that you always, I’m always and I think this is a good advice for everybody, trying to be the dumbest person in the room. Make sure that you have a circle of really, really smart people. Never ever be afraid of hiring somebody into your team or to give opportunities to those talents around you. I think, karma is real. So if you have a very smart person, make sure that person have the opportunity to keep growing. And sometimes you’ll face that they are overgrow quick, growing quicker than you in your career. But then again, that’s what I’m saying. Karma is real. So number one, make sure to circle, to keep smart people around you and always hire smarter than yourself. Make sure to always support and coach your direct reports to be even better than yourself and be more successful than yourself. Karma is real.

And one of the key things that I’m working according to is sort of always building team with no ego. I think that there is — and what I mean by that is sort of, I think that is a very, very not a thing, maybe, at least. Probably also certain other parts of the world as well. But sort of saying, build a team where the team is more important than individual. And this comes from sports, this comes from sort of making sure that maybe you have the best, if the best developer on the team is, you know, it’s — I don’t want to say that word, but sort of, and very difficult person to work with, doesn’t really make everybody else kind of leveling up. Yes, he can — or she — may very well be really good at solving some very specific problems. But when you can get the entire team to operate at a different level, that’s almost every time outperforms that individual. And of course, if you have that individual and that individual gets sick, hit by a bus, God forbid, or wanna join a different team or leave the company, you are in a big shit, right? So build team with no ego.

I think that is some of my keep coming back to advices. And I try to always follow them in my daily practice as a CEO, but also as a team lead and VP of Engineering, whatever. It doesn’t really matter. It’s more of how you think about your role as a leader more than anything.

Henry Suryawirawan: Yeah. Thank you for sharing such a lovely thing, right? So I think no ego definitely is in any software team. Although I would say like maybe the team size of software development now is getting smaller and smaller. Now it’s like one ego of a developer versus AI. So I hope we we’re not turning our ego in a worse manner.

Egil Østhus: That is true, maybe I need to think through that, one more time.

Henry Suryawirawan: All right. So Egil, if people love this conversation, they wanna, you know, talk to you more maybe about FeatureOps or find out about Unleash, is there a place where they can find you online?

Egil Østhus: Yeah, so they can find everything about Unleash on getunleash.io, that’s Get Unleash Dot IO. Or they can connect with me on LinkedIn. I’m there and very active on LinkedIn, so feel free to connect directly also with my LinkedIn, with me on LinkedIn.

Henry Suryawirawan: Yeah. Lovely. Will put that all in the show notes. So thank you so much again for today’s conversation, Egil. I think we all learn a lot about FeatureOps, you know, where the trend is growing with the AI and agentic development. So I think, thank you so much for sharing this.

Egil Østhus: Thank you for having me. It was exciting to be here.

– End –