# Feature Ops: Strategic Safety Nets for AI-Driven Software

**Podcast:** Tech Lead Journal
**Published:** 2026-04-27

## Transcript

Our slogan when we started Unleash was, Baddest developer release on Fridays.
And we think that it's just a stupid thing to not do.
Today's guest is Egil Ostas, co-founder and CEO of Unleash, the world's leading open source feature management platform.
Trusted by Lloyd's banking group, Wayfair, Prudential, and Visa.
Egil's mission is to help technology leaders and businesses move beyond traditional DevOps by embracing feature ops.
What do you see the ability of having this feature ops thing with the trend of AI?
The Dora report from 2025 was sort of indicating that the number of issues because of the AI adoption is increased by 7%.
The feature ops 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 a software?
How do you kind of have the surgical rollback?
We are seeing a steady increase on the number of feature flags.
We will see an even steeper increase in the numbers as we are seeing more AI-agentic developments coming to the industry.
A lot of people now doing vibe coding.
So far, there are less people talking about building those safety nets.
Everybody's amazed at how much you can get done in a very short period of time to get it up and running.
And this is very heavily focused on the day one.
But the day two is...
So we've talked about what happens when you are in production, when you are getting into scale.
AI will eventually be responsible for making a lot of micro decisions within the software.
You as a software developer, you're further and further away because you're not in a day-to-day writing the software yourself anymore by hand.
So the challenge we are facing is that we need to understand what is happening among all of those AI agents that is operating on my behalf, making the decisions on its own.
Hey, quick pause.
My goal with Techly Journal is simple.
Learn from the best in tech so we can all grow together.
If this resonates with you, hit subscribe to follow the channel.
It's the biggest way for you to support the show and help us keep bringing great guests and insights to you.
Thanks for being here and let's get back to it.
Hello, welcome to another new episode of the Tech Lead Journal podcast.
Today I have with me the CEO of Unleashed, Egil Ostes.
If you haven't heard about it.
Unleash is basically like a feature flex systems, feature flex platform that is open source.
Today, as you know, we're going to talk a lot about the feature flex, feature ops, those kind of stuff, and especially how to use feature flex for AI-based software system.
So, Egil, welcome to the show.
Looking forward for this conversation.
Thank you for having me.
I'm very excited to be on your show.
Yeah, so maybe in the first place...
You mentioned Unleash is actually like a feature flag, feature ops kind of a platform, right?
So I think feature flags have 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?
Yeah, I would say, and then 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 we as professionals know this is happening or this is something we want to do.
But I would say the adoption is a big spread in the adoption rate.
I think what we are seeing is there is a lot of organizations that don't do anything, honestly.
I think there is a lot of organizations that do something.
I mean, config file type of configuration sits next to your software.
Is that a feature flag or is it not?
They sort of do solve some of the use cases that you 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 are very early type of maturity type of things.
And of course, we also see organizations very mature engineering-wise already operating according to this best practice.
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 organizations 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 this sort of more as an enabler or a strategic enabler for the organization.
So we are coming in with a different point of view saying, okay, you need to think with this as a more strategic point of view and less of do 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 laggers that is sort of Still getting up to speed on this.
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 chatbot.
Try it out today at mailtrap.io.
And now let's get back to our episode.
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 CICD thing, right?
The trend that is going on.
um 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 um take so hard for people to adopt Yeah, that's a great question.
I think, and 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 by 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 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 way of operating.
So let me explain this and sort of go a bit on what does this mean.
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 typically kind of scope type of focus.
Deliver a certain given, pre-given scope and get that into production at a predefined timeline.
So you have a time box period of time.
It's really important to get in production.
And to put that scope or that sort of those levels, that type of feature, whatever, into production in itself is the meaningful event.
That's what you celebrate, you go live, 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 you have a scope and that scope, think of that as a feature or multiple features, written, tested.
put in production go live it's 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 or at least well i would argue are you existing 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 are we solving the pain that the end user is looking to solve?
And I'm not necessarily stating 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 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?
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 philosophy.
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.
uh in a lot of organizations yeah i think it makes sense right because if you define your work with a specific scope uh if you don't actually define like for example you want a 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 um you know chance for people to have these feature flags because they think, OK, I will release on this date.
I'll make sure everything will be released by that time.
Which brings me to the discussion.
You mentioned about this term called feature ops.
And in the industry, there are terms like CICD, progressive delivery, A-B testing, those kind of things.
Are they all kind of similar, interchangeable, or how do you define each differently?
So CRCD is a very important aspect of the DevOps.
I mean, I'm not suggesting and we're not suggesting by future that DevOps doesn't really make sense because they make a lot of sense, right?
It's absolutely what you'd expect and what you would look for is making sure that your developer is also taking care of the operations of this other, right?
you are accountable for what you build is sold, what you are accountable for.
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 part 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 CICD and all of the automation, 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.
And this is where the feature-ups come into play.
And basically what we're saying is that, so maybe break down the feature-ups, it's about the gradual rollout.
So this is something you can do with feature-ups.
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 A-B testing and that type of conversion rate focus.
It's 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 world that is consuming software.
So to develop...
uh software that is consumed and easy to operate or kind of be i mean how you how you use your your end users is still being super valuable so that's typically the net promoter score and customer satisfaction score that type of 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 software is 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 as an enterprise level where we operate, you need to have 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, whether your financial or other parts.
And on top of that, also what we refer to as a feature management or feature ops control plane, sort of the life cycle of everything.
And I think you alluded to it in the earlier conversation, sort of how do you make sure also that you keep this on the control that you keep cleaning it up because by the end of the day it's an if statement in a 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 call feature ops and it's sort of allowing this.
transformational shift within the organization to happen.
Yeah.
So I think definitely makes sense for people who have experience having system that enables this kind of like feature flex 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 it's 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 switch, it could be as instant as possible, right?
So I think I was kind of like taken into curiosity when you said in the beginning, some people still treat this kind of feature flex thing as a tactical thing rather than a strategic thing.
So tell us, how can we start shifting our perception or thinking to making feature flex more like a strategic thing?
Yeah.
It's a great question.
I think, 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 I'm not able to kind of, or I'm going to spoil here, I'm not going to give you like, this is the solar bullet on how to operate this independently of organization.
So that is always, but it's sort of, there are some key patterns here, right?
So when you think about this, this is basically about change management, right?
So change management is all about how 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 start.
So if there is an external factor, there is like a massive, 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 want to push ourselves.
We are a tech leader.
I want to kind of move my team towards something that makes sense.
And it's the thing to do.
So basically 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 themselves, 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 find those supporters, start it small, and also make sure that early success is your biggest.
champion in your organization because everybody wants to join a winning team.
So what you will face is that we are getting this, let's assume I'm a tag leader, I want to 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 want to start in an area where If they fail, it doesn't really have a dramatic impact.
And soon as these team or teams 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 your organization.
Because then what you will see happen is that you're turning those sort of skeptical people or kind of blockers or pushback individuals coming back saying, oh, this sounds to be interesting.
They're doing something smarter.
And they start to be 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.
You don't need to tell the story, but let them tell the story.
Let others tell the story.
Let people be...
be successful.
And, you know, there is another organizational hike because the more executive support you can get, the better.
And typically everybody in a 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 market.
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 the organization and you will 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.
yeah thank you for 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 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 you can just put 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 want to 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 want to do experimentation.
Maybe you want to 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 want to, you know, roll out this feature as part of the roadmap.
So tell us, you know, this aspect of, importance of culture rather than technical for implementing feature flag.
Yeah, you are spot on and you definitely nailed it there.
So yes, I would say in an organization, there is 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 the real thing.
The product management is typically more concerned about, is it feature complete enough for my end users?
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 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 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 uh 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 the customer is exactly solving all of those needs.
Because you can allow the developer obviously to keep putting their 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 role at the very kind of cohort based role of saying, OK, let's do this enablement for a very selective use of a number of customers.
Where the marketing team is, is having a different point of view.
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'd 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 and maturity of the organization.
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?
So I think maybe let's go to the like kind of 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 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 some best practice or maybe some variance of it like how how do you see the practical thing how these features are being defined So you're absolutely right.
It starts very early and typically it would start in the product management level, I would say.
So this is where you start putting together some release strategy.
So in my context there, just kind of give some insight there.
My product management focus or kind of definition is a very commercial role.
So it spans also into product marketing management.
and sits very close to the product marketing team, but also obviously very close to the engineering team.
So what we are seeing, I would say the best practices out there is when you start building new features, start thinking about how do you want to test, roll out the release strategy very early.
One of the beauties 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 three, four, five 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 uh this is maybe i'm doing a greater rollout i'm rolling it first out to my vip customers maybe i'm having a close relationship with this five seven close customers then i'm doing this and i'm doing that type of thing and uh and that is sort of repeatedly we we had and and and applied to the um to the development process 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 want to 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 release strategy, you know, I think that will be very useful.
So I think...
One other thing 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?
It does.
Actually, our slogan when we started Unleash was baddest developer release on Fridays because you don't release on Fridays and we think that is just a stupid thing to not do so well.
But then again, I understand where it comes from because I think we have all been burned on working late hours on a Friday and into the weekend.
And that's not a fun thing to do.
But yeah, it's definitely, I would say there should not be any reason to not release on a Friday.
But then again, it depends.
If you are kind of very, this is a fresh idea, you already kind of all play.
you have just finished your automation of the CRCD or kind of just getting up and running on these and you maybe releasing on Fridays is not the first thing you do but basically if you do this in a proper way I mean you know pretty 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 it's very, very much a core case.
You don't control them anyways, but most of the time when you have and you need to do a post-release fix or deploy post-release, it's typically happening quite quickly after the release.
So if you are wrapping your changes in a feature of flags and really make that adoption into sort of a great robot and or kind of a kill switch type of scenario.
you know quite wholly if this is working or not.
And if it doesn't, you can always, you have the measures and the safety net to go back to a last known stable deploy of your code.
So, I mean, yes, I get your joke in saying this is not what you want to do.
But then again, I would say, well, this is actually what you want to do and strive for, because I think that jokes exist because of all of the good reasons of why not doing this.
And then again, that speaks to you don't have the safety net in place in order to make this happen.
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 it'll make changes fast.
So I think that's a very key important aspect of a good software development team.
So maybe now it's a good segue to talk about Unleash.
So tell us more what is Unleash and what kind of features does it have to help us?
So Unleash is the largest open source feature platform that is available in the market today.
So all of the use cases, all of those scenarios, all of those kind of capabilities that we talked about is...
is available and of course much more.
It's also 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.
And because it's an open source platform, it can really be twisted to any need.
And we have been very focused on building a platform that really, really scales to 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 Lloyd Banking Group.
I think they are 25% of the UK GDP is going to a Lloyd system.
So that is a massive operation.
Wayfair is one of the biggest e-commerce players in the US.
So again, Black Friday and the Black Week is a massive, massive event for Wafer and we have worked very close with them in order to make sure that Unleash is supporting them through that very, very 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 large organization.
I mean, as an end user or kind of an end developer, 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 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 not complicating the process.
Because I think that is often 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 something happens or that's just the world I'm operating in.
I cannot.
I cannot sacrifice, I cannot go compromise there.
So a lot of the customers we are working with in particular 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're allowed to operate as the smaller digital first startup type of organization at the same time staying highly complied 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, 2015 or so.
And we have been developing this as an open source for for many, many years and now we are sort of working with those large organizations in order to support them in making feature ops as a strategic enabler for how they operate through software development operations.
Yeah, having open source that can really scale with all this enterprise capability like 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 want to subscribe with you know millions of billions of uh you know kind of like events evaluations those kind of things 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 and what kind of risks that people are not seeing if they want to roll it out on their own.
Yeah, so we have done quite some research here.
And I think the challenge in 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, it sort of is eventually some, again, it's curious form is an if statement.
And that if statement triggered, it needs to be triggered by some input fields, obviously.
So it's an easy problem to understand.
And, you know, the beauty with the engineers, but that is maybe also sometimes the cure is we are builders, like 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 are so many reasons why this is like not something.
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 the budget approval for my management.
It's like, that just does.
I've never seen it.
Maybe there it exists, but I haven't met them that often.
So basically it's 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, all of those, it's resilient, it's always happening or very optimistic.
So the complexity is in the scale on the size, it's not on the purest form.
So what we are seeing when we are up 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, doesn't really work or even worse.
It caused 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 home built feature management, whatever, or feature flag system.
It created issues.
We lost revenue like big time.
How quickly can we migrate over to 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 need and at any time.
We are there also to make sure they have all of that needs for rollback access control, all of that security measures that you need to have in place in order to operate in a...
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 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 fly.
So then again, Is this your core business?
Is this where you want to invest your resources of getting a competitive edge?
Or is this where you want to go out in the market to unleash or to one of our competitors to say, this is too important for us to spend our best engineer heads to spend the time building where it already exists.
Yeah, so I think definitely what you said makes sense, right?
It sounds simple as a concept to understand, right?
Click 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.
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?
Yeah, so the local evaluation, and also if you go to our webpage, we, some time back, we published what we call Basically, a sort of high level, what do you need to think about when you build a large scale feature management platform?
So one of the key concepts is you need to make the evaluation happen as close to your application as possible.
So one of the things that we have 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 flags or kind of our capabilities, all of those strategies that we can we can provide you uh that doesn't really impact the execution speed of your code because we know that um uh the or at least i've seen when net promoter score is dropping that is typically because uh if if the application is not responsive if it doesn't uh operate on a consistent way that is having a massive impact of uh of your network scores you don't want to make sure we want to 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 that's close to the execution of the code as possible.
So that's sort of a local evaluation.
And also the privacy of things there.
I mean, when we started to build this, we were, you know, Europe were in this GDPR kind of validation of the GDPR.
So we need to be compliant with that.
We come up with another Europe.
And I think that also with 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 the data flow and then 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 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, and 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.
Trust is something that is starting to 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 truth.
So what you would be able to do is basically saying, yes, I are 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 yourself that what is happening is real.
And I think that is something that the SaaS vendor is out there is not capable of doing.
And I would say the last part that you didn't mention, but you were briefly stating, is also this nature of our flexibility when it comes to deployment scenarios.
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 this 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.
Sadly, I would say, but still, that's a fact.
So working in this type of environment, having like 100% full control of where is the deployment happening and who is in control and have access to this.
It's a massive differentiator.
So that is also one of those areas where we are unique in the market.
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.
It won't be...
you know, sent to the control plane, right?
The feature ops plane management itself.
So I think that definitely is a key thing, especially if you want to adopt, you know, the SaaS model where you don't want data to leak out to the vendor.
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 feature ops 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 irrelevant?
Yeah.
So I think that's sort of, it's obviously, it's 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 is 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.
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 where 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 N, obviously that's getting into a significant change.
That is currently what we're seeing.
So the feature of 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 the surgical rollback, and also how do you measure those 360 full-stack 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, again, forward, running ahead of everybody else, and it's more complicated in this usage of this.
But you have also seen, we have seen this ourselves and also part of that, the stories of the AI hello initiation.
Starting to write something, do something that it 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 tech engineer 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 talked to industry leaders and we talked about it 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 so basically what they may mean is if the hits the fan i'm not sure if i'm allowed to say so in your show but if you know when when when something goes wrong What is the blast radius of that issue?
Is that a big, massive kind of impact on all of my end users or is it a small thing?
So that is important.
That is top of mind.
That is not necessarily written by AI or a human being, because if that happens, independently of who to claim, so to speak, or who was sort of causing that issue, you are still responsible for making sure that data 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 into today.
So if we start looking a few years ahead, because I'm seeing this, I mean, we all feel the speed of the AI and we are soon to get again AI and sort of having that AGI type of thing at our disposal or having available to us.
So I think the interesting part here 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 not all, a very high percentage of those that will decrease.
So what happens in this scenario is that AI will eventually be responsible for making a lot of micro decisions within the software.
So AI autonomous.
will make decisions that impact the code.
So you as a software developer or kind of a system engineer, whatever you want to call that, you're 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 some of the challenges 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 and i think the the first one that is uh one of the first that was sort of talking about was jack clark one of the co-founders of claude What we're about to see is this introduction or 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 development being a human being, decides.
And I think also the part of this picture is also the shift of software engineers is more understanding what is the guardrails, what is the context of how to develop software on behalf of my organization, my company, and obviously not writing software by hand anymore.
So I think that this is a shift that we are going to see.
And how I see it unleashes 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 is 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.
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 getting smarter and smarter, bigger and bigger, right?
And I have seen many blogs, maybe tweets, all those kind of things where people write code in multiple agents, sometimes even not looking at the code.
So I think we can definitely foresee a lot of 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?
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?
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 to keep developing Unleash into this and being that authoritative voice.
So I would say today we are very much adapted.
We are very focused on delivering what our customers need today and we are evolving into this future state.
We also are building in a type of AI driven capabilities of cleaning up and making kind of independent releases or decisions.
And yeah, 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 call to us in the forums that we talked about in this conversation for sure.
Yeah.
And do you actually see after having all these 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?
The trend that we are seeing is that it's definitely increasing.
So we are seeing a steady increase on the number of feature flags and we counted as feature flags per developer allowance.
I think that is a metric that we need to redefine because of the emergence of AI agents.
But the absolute number of feature flags is definitely moving up.
I think that is a bit of a sad news because we want the clean code for our customers.
So we also need to take away those feature flags that are 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.
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 a 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 a short time?
Yeah.
Now, this is something that we partly, I would say we support this already and we keep investing in this as part of our AI 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...
I want to trust my AI agent to do this, or is this something where I kind of want to be, you know, having a human in the loop because of, by the end of the day, I'm still responsible for the blast radios that is happening there, but this is already available on our platform.
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 flex, 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 it to production.
I think the aspect of, you know, I don't know, like feature management, those kind of stuff are probably lacking.
So what kind of advice do you want to give to, you know, those Vibe coders, especially in regards to this feature ops feature management?
Yeah, it's a big question because why coders is so, I mean, there's so many different things, right?
It's everything from the hobby developer that is wanting 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 piece job doesn't go away.
I think the...
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 off and running and build your, I mean, I've been talking to Invis building like a CRM system in a week and then sort of these things, which is probably true, but it also definitely is not a fall through.
So basically what we're seeing is that this is very heavily focused on the 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 to 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, if you are kind of building a larger project based out of a vibe coding environment, you also want to 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 it's still important to have in mind that you need some guardrails in place in order to make sure you are compliant, that you are in a position to make sense of what is happening there.
So I think that's my best advice in this area.
Yeah, so I think definitely, also it depends on the context, right?
If you just want to build a one-shot application that is for small needs, probably you don't need it.
But if you are building some software that is evolving, so I think having this foundation in place will be very, very useful, especially you're talking about day two operations.
Who knows, right?
When you turn out more and more code, when there's an issue happening, you want to be able to roll back fast or turn off certain features really fast.
So, Ijil, I think we have covered a lot of things, you know, is there any other things really important that you want to talk about, maybe from Feature Ops, maybe from Unleash, or maybe this agentic AI trend that is happening?
Yeah, no, 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, yeah.
We are living in the kind of emerge of what to come.
It's a destructive point in time for sure.
But I would say I'm seeing this as a massive opportunity for engineers and for the tech people.
It's almost frightening how important technology starts to be in our world.
it's a great spot to be in and it's a great opportunity to be an engineer for sure.
Yeah, very exciting indeed.
Although sometimes it's scary given the pace of the changes that is introduced by AI.
So Ejiel, 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 want to give to the listeners.
Maybe if you can share some today, that would be great.
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, make 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 has the opportunity to keep growing.
And sometimes you'll face that they are 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 on calling to is sort of always building a team with no ego.
I think that there is And what I mean by that is, I think that is a very, very naughty 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 the 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 a 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 almost every time outperforms that individual.
And of course, if you have that individual and that individual gets sick, hit by the bus, good forbid or...
want to 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 MVP of engineering, whatever it doesn't really matter.
It's more of how you think about your role as a leader more than anything.
Yep.
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 are not turning our ego, you know.
That is true.
That is maybe I need to think through that one more time.
All right.
So, Ijil, if people love this conversation, they want to, you know, talk to you more maybe about feature ops or find out about Unleash.
Is there a place where they can find you online?
Yeah, so they can find everything about Unleash on getunleash.io.
That's getunleash.io.
Or they can connect with me on LinkedIn.
I'm there and I'm very active on LinkedIn.
So feel free to connect directly also with my LinkedIn, with me on LinkedIn.
Yeah, lovely.
We'll put that all in the show notes.
So thank you so much again for today's conversation, Egil.
I think we all learned a lot about feature ops, you know, where the trend is growing with the AI and agentic development.
So I think thank you so much for sharing this.
Thank you for having me.
It was exciting to be here.