Ep. #8, Sounds Like Alignment with Melinda Fekete

Adam Zimman: Excellent. Well, we're excited for yet another episode of Third Loop. And today we have a wonderful guest. Melinda, why don't you introduce yourself?

Melinda Fekete: I'm a developer and a technical writer at Unleash, and one of the things that I focus on the most is documentation, so I take care of our documentation website. But we're also a dev tooling company, so developer experience in general is one of the things I care about a lot, and that's primarily through developer education. So things like workshops or webinars or podcasts sometimes, and being active in the community and bringing the feedback back from the developers to our product team and the like.

Adam: Well, so glad that you could join us today. One of the things that led us to inviting you on the show today was that we absolutely loved the article that you wrote and book review of Progressive Delivery. And we were very excited to further that conversation with you.

It sounds like you've obviously had a lot of the same kind of experiences and ideas that we talk about in the book. And one of the purposes that we've got this podcast is because we want to have that be the start of a conversation. Right?

And so we wanted to kind of talk to you about what you're seeing and hearing from customers, what you're seeing and hearing at Unleash itself and how you're actually kind of doing and working towards Progressive Delivery. So why don't you tell us a little bit about your experience with Progressive Delivery and maybe share a story or two of what you've seen where someone is actually doing it well, or maybe someone that is not doing it well, if it so pleases you.

Melinda: Yeah. So, yeah, big fan of the book. Just want to put that out there. Our whole team loved it. And I don't often read nonfiction, I just love reading too much. So my reading list is full of fiction recommendations from friends. But one of my colleagues recommended the book and I actually listened to the audiobook and immediately felt like a lot of the ideas that we've been talking about just felt validated and the frameworks that you propose or how you frame these different problems just really like instantly resonated with me.

And then now we're going to buy it for the whole team and hope that everyone reads it. And yeah, for me personally, I've been a big fan of feature flags for a long time. I first started using them in like 2018, I think it was, I had a very stressful job at the time. I was a developer at this fintech startup. It was kind of like Credit Karma in the US, like credits building your credit score type company.

And so I worked in a lot of integrations with banks or financial services. And it was the kind of setup where even like a few minutes of downtime would mean potentially huge revenue losses for the company. So it was really stressful. And we of course had 24/7 on-call and after a few like, stressful incidents where I thought I was being funny leaving some log messages in the comments, but then when it was actually like the incident and we were struggling to figure out what was going on-- You know, after those experiences, we started exploring some options and feature flags was one of them.

And back then we just did like config files, like true or false and a config file. It was super basic, but it already, that thing like blew my mind. Like having the ability to make changes to your software at runtime without having to redeploy. It was like a big win.

Adam: Game changer. Yeah, absolutely.

Melinda: And like, compared, like I never worked in that environment, but I hear so many of my colleagues who worked at banks or some of these more legacy tech companies where they're releasing software like once every six months, if they're lucky. So they were really far removed from the user.

Sometimes they weren't even sure what problems they were solving. And kind of the frequency of those releases really also delayed the learning opportunity for them. They couldn't really see if what they were building was working. And life is a lot different now for most of these companies.

Even the banks that we speak to want to get into a more efficient way where they're able to iterate on their solutions a lot faster. And so that's how I ended up working at Unleash, because I see them as like a key player in making that happen. And I guess that is how we ended up talking as well.

Heidi Waterhouse: Yeah.

Adam: Awesome.

Heidi: So you all are talking about this thing called FeatureOps, and I'd love to get a definition from you of what FeatureOps is.

Melinda: Yeah, it's a way of life.

Adam: Haha!

Melinda: Yeah. So I guess the analogy came from DevOps. And we're seeing DevOps as like one of the major changes that happened to how we deliver software over the last like 10 years. And it really revolutionized, for lack of a better word, of like, how we deliver software.

So now most teams are shipping in smaller increments and getting code to production is no longer the hard part. I feel like we've really optimized that piece, but we're still seeing that that's not always enough because DevOps gets your code out to production, but it doesn't necessarily allow you to change what happens after it's in production.

And a lot of the incidents that we've seen, all the way from Google to Cloudflare to GitHub and all these big companies have all pointed to the fact that they're still missing this other layer of what we call runtime control over how their software behaves. And a lot of the times these changes are super minor, like a backend configuration change or a policy update or something thought to be quite small, but it can still bring their entire system down.

And because of how interconnected everything is, if you are relying only on your CI/CD pipeline to roll back, it can still take hours. And so that's just kind of the background to FeatureOps. But we wanted to draw the analogy between DevOps and FeatureOps.

So if, you know, DevOps has cool things like infrastructure as code or CI CD pipelines, like those are the components of DevOps, and DevOps in general is a practice, then we're seeing feature flags as a tool. And then FeatureOps is a practice that's built around it.

So it's treating feature flags and combining that with the engineering practices that allow you to treat every single release in your company as this controlled, measurable and repeatable process. And we think it's something that deserves its own operational discipline. It's on and it's something that everyone in the company should care about.

Heidi: So when you say it's a lifestyle, who is it a lifestyle for? Like the thing that DevOps did was pull operations and it into the development umbrella. But what does FeatureOps-- like, who's it for?

Melinda: We think that it's for everyone who cares about what the user experience is like. So obviously starting with engineers who rely on FeatureOps to be able to deploy something maybe only for themselves and their internal team in production and really test and make sure it works. Or it's for a product manager who wants to do an experiment or customer success team.

Like the radical delegation part of your book where you're talking about pushing the authority down to the person that's responsible for the outcome, like for us, that's a really important piece. Like having the customer success manager being able to turn on a piece of functionality for our customers when they are ready.

Or it could be anyone in the infrastructure team relying on a kill switch to bypass a shared dependency that's failed or using a progressive rollout of migrating from one service to the next. So I really see it as-- but at Unleash, even the marketing team is using it. So it's really the whole company.

Heidi: So how far can that extend? Do you ever envision FeatureOps including the user getting to affect features?

Melinda: Yeah, I love that part of the book. And actually like when I think about my experience and you know, the Gmail piece or even I remember this piece in Jira where you could change which user experience you wanted.

I love that as a user, like I really do. I love to be in charge of my own experience and as an engineer or as a product team I can see how that can quickly get out of hand. And as long as you have a couple of options to maintain, it's probably manageable.

But you I guess don't want it to get too convoluted because then you're not sure. It's just probably a little bit difficult to manage at some point. I don't know what your thoughts are on that.

Adam: No, I mean I, I think that you're right. You need to be mindful of the balance between flexibility and the management overhead that that can induce. I think that there are ways that you can organize information and there are ways that you can kind of look at usage trends over time to be able to deprecate choices that--

If you've got greater than 97% of your, that has chose one option, it's probably reasonable to say, okay, well let's make that the default. And you know, maybe you keep it around for the last 3% as a kind of corner case because that keeps them happy. But maybe you don't, maybe you kind of push everyone to the kind of default workflow.

I think that ultimately what, in my mind, is really impactful, with if you're going to do this and have some type of feature management platform is, do you have the ability to quickly and easily identify what is the experience of any given user at any given time?

And so like, how do you know which flags they've got in which options they've chose? You know, this is helpful from a support perspective, but this is also helpful from an engineering perspective, in the context of what are the things that you should be prioritizing next? Right?

What are the things that you should be continuing to work on and develop? What are the things that maybe are most utilized by your users that, you know, if you were to provide some additional automation that made it easier for them to be able to get through their workflow would be beneficial.

So like, I think that there's a lot of things there to, you know, kind of weigh. But yeah, I think presenting every user with all of the options all the time is definitely going to alienate the user just as much as it would saying you can have any color you want, as long as it's black.

Melinda: Haha. Yeah.

You never know if something's going to work until it's actually out there and adopted by people.

Heidi: And that's sort of an interesting thing that we also talked about is how can you tell who's adopting what? Like what kind of feedback are you getting from flag activation? Even if it's not users, even if it's support. Is someone keeping track of what's getting turned on or turned off?

Melinda: Yeah.

We like to think about this as we call them the three voices. So we want to build features that satisfy the three voices. And the three voices are the voice of engineering, the voice of the business and the voice of the customer.

So on the one hand, we want the engineering team to be happy and they care about their platform performance or latency or infrastructure cost. And we want to obviously make money and we want the customer to be happy. And so I think that last piece is the hardest to measure.

We do like PNPs or NPS or other customer satisfaction scores. We're also the kind of company where we have a few big customers rather than many small customers. And I think that maybe makes it a little bit easier because we can actually talk to them every week and get qualitative feedback from them.

Heidi: Mhm.

Melinda: But yeah, it's hard to align all those three voices. For sure.

Adam: Yeah. I think one of the things that we've talked about and we've looked at and explored is also looking at how do you set up observability and monitoring for your product service that gives you insights and gives you a little bit of quantitative feedback and an understanding of you know, like the feature usage or another way of looking at it is like are you measuring dropout rates on a particular workflow or bounce rates of a particular page of your application?

You know, how are you actually starting to evaluate that kind of user experience from the perspective of when somebody starts something, do they actually successfully finish it? And I think that's one mechanism.

I think then the other part of it is just, frankly, you look at churn rate of your customer base. And for high volume products with a lot of customers that can be really helpful for you know, like you talk about having just a few like larger customers, that becomes a little bit more of a painful learning experience.

Melinda: Yeah, for sure. I don't exactly know the details of what went into this metric, but we had a customer who was in, they had a subscription based app and they were kind of careful about looking at sign up, like the subscription numbers because typically if someone subscribes for one month, it's not the same value as if they've been subscribing for a year.

So they come up with this metric that they call the lifetime value of a customer. I don't know if it's unique to them, but they, they're doing experiments with us based on this lifetime value metric, which I thought was really interesting.

Heidi: Oh, interesting. Like if you have a sticky customer, do they behave differently than a not sticky customer? Can you make the not sticky customer into a sticky customer?

Melinda: Exactly.

Adam: Yeah. A lot of times lifetime value you can also look at, that behavior can translate either to you know, like frequency of use. So like number of times that they actually come to the product or platform as, as looking at it from a perspective of what features they use. Right?

So like, are there specific features that you offer that result in stickier customers because they're getting value in a different way, which can be really impactful.

Kim Harrison: I'm kind of curious. You mentioned FeatureOps as sort of a way of life. You've also mentioned that your team has extended control of feature flags to various team members. Like what does that look like in practice when you think about putting flags into place, including these different team members? Like, how do you think about that?

Melinda: Well, I think there is still at the core, engineering is still always involved, but prior to having kind of this runtime control mechanism in place, I think engineering was always a blocker for getting code into production. And now we've kind of removed that blocker and so they're no longer like kind of a single point of failure for everything that goes wrong or all the incidents or kind of customer complaints.

So yes, they are still responsible for making sure that whatever functionality we build continues working as expected, but they're not necessarily the ones who decide when the customer is ready or when that user experience is going to go live for someone. And I think you just need a really good operational surface for that.

So you're able to say, if this is our production environment, maybe we need at least two people to look at this thing before we enable it, or having events that tell you who enabled what for what customer and kind of having this data around it and then it's pretty straightforward.

But again, we're a small team, so I'd love for you to have someone on the podcast soon who's like from a big bank or with thousands of developers and see how they do it. Because I imagine it's a very, entirely, very different set of challenges.

Heidi: So that sort of leads me into a question: What do you think the ideal flag life cycle is? Because we spent a lot of time talking to people who always considered feature flags as technical debt. But FeatureOps doesn't really work that way. Like some of them must be, but some of them aren't. So how do you figure that out?

Melinda: So we classify them into I think five different types of feature flags. So most of them we think should be short lived and there are a few exceptions. So kill switches is something we'd consider a long lived flag.

So let's say you have a payment provider who's like kind of frequently misbehaving. Maybe you want to put them behind a kill switch or an authentication provider. Let's say you want to be able to disable SSO if it's not working, but still allow password based login or something like that.

Maybe you want to have those permanently or like for a longer period of time. But for the most use cases, if it's for a feature rollout or an experiment, we typically think about flags as in the 30 to 90 days window.

Heidi: So what are the five types?

Melinda: We have a release which is, you know, just for releasing a feature. We have an experiment which typically has different variants. So you maybe want to show a green button and a blue button at the same time and decide which one's better. Then you have what we call an operational flag which is also on the longer lift side.

So maybe you're doing a database migration or something like that. And then it's less user facing, more of a backend change. Then we have kill switches, which is what we talked about, and then we have a permission flag as well.

And that is something you'd be able to-- Let's say you have a free tier and a premium tier and you maybe want to show different functionality to them, you'd use a permission flag. But this one in particular is a bit of a contentious one because we're always advocating for the fact that if something is permanently part of your business logic, then it should not be behind feature flags.

You should just make a dedicated service that manages those permissions. So we provide it because sometimes people just want to have it. But if it would be us making the recommendations and the best practices then like 90% of feature flags would be living in under a few months basically.

Heidi: Mhm.

Melinda: What are your thoughts on that?

Heidi: We did an interesting survey on how people were actually using feature flags at LaunchDarkly and we were shocked to find out how many of them were operational. And that's entitlements and that's -- Some of them were routing flags like people were doing real time routing analysis. And that's a permanent flag. You want to know all the time that that's there.

And it was a real shock to how we had originally conceptualized feature flags which were this temporary thing. I think the idea of maintaining a separate service to do something that you could do with a feature management service, people get a little allergic to it because if they're paying for a service they can do it, they just want to use it for everything.

It's sort of like Amazon Prime. Haha. If they will bring you all of the things that you need, then you're like, yeah, sure, why not groceries too? That seems great because it's less friction.

Adam: Yeah, I mean, I think the other value proposition you get from using feature flags and a feature management service for some of your business logic is that you-- Again, it's one of the things where if you're dependent upon a code change to be able to change your business logic, then you are immediately putting more pressure on your engineering team in terms of responsibilities.

And secondarily you're eliminating the individuals that are closer to that decision from being able to impart change. Right? So if you have the ability for a product manager or for even like a marketing team to be able to make changes to your feature tiering or pricing and packaging without having to involve engineering, that sometimes can be a significant benefit for being able to move your business forward.

Melinda: Yeah, I think as long as you know which ones are the ones that are long lived, you're flat. And I think a lot of platforms today are good at like telling you like, hey, this one, you should be looking, you should look at this and see if you still need it because we've not received like metrics for it in 30 days or something like that.

Adam: Absolutely. Yeah. And I mean, I think that this is why, you know, I think platforms like Unleash and LaunchDarkly or others exist in the sense that like this gives users the ability to be able to like have that data around the feature flag. So it's not just the config file that you mentioned, you know, kind of starting with where you all of a sudden you're just like, I got no idea when the last time someone touched this was.

Heidi: Yeah, is this important? Is it load bearing? Who knows?

Adam: Yeah. Let's just remove it and find out.

Heidi: Yeah.

Adam: Yeah. I think that the other kind of type of flag that we have talked a lot about and have talked with a lot of customers about that is extraordinarily valuable to the folks that use it this way is thinking about it from a perspective of not only feature rollout, but feature sunsetting. So this is the idea of using flags to be able to encapsulate code that you want to remove.

And then all of a sudden, you know, as we've you know, stated more than once as Charity Majors likes to say, you know, "test in production or live a lie."

I think you don't know what's going to happen when you're dealing with production systems and services. The reality is that the Internet is a spooky place. But you know, this gives you the ability to have that same level of control and ability to impart action in your runtime environment, just like you would when you roll something new out but when you're taking something away.

Melinda: Yeah.

Heidi: And one of the very early descriptions I read of feature flagging was Martin Fowler's Strangler Fig pattern. And I think that that's such an interesting way to think of like how do you wrap something that you're getting rid of? And it's much more important to sort of larger older organizations. This is not something that we encounter in small, fast-moving startups because they don't have enough code base to need to sunset things.

Melinda: Yeah.

Adam: Although I would say that even fast-moving startups, like there's a lot of organizations that, you know, especially folks that are moving quickly, they oftentimes will do code refactoring for optimization and things like that that does involve diffs that are often quite red.

Heidi: Mhm.

Melinda: Yeah. I think a lot of teams still think about feature flags as these UI, like cosmetic things essentially. So like being able to test different versions of the UI and that is one of the main use cases and that's obviously great but I feel like that's like maybe only 30% of all the cool stuff you can do with feature flags.

And there are a ton more operationally interesting use cases for feature flags. Like my favorite one is using it for chaos engineering, like injecting chaos into your system deliberately and then being able to do that at a regular interval and taking your resiliency practices from a place where maybe you're doing it once a year and it's this big expensive event that needs like a 10 page plan to something that any engineer can do from their desk in like an hour maybe once a month.

And then you're keeping your resiliency logic up to date and you don't risk it going stale or rotting because no one's exercising those fallback paths. Or we're using it for things like scope debugging. If we want to increase the log levels for one particular customer or tenant, we can do that at runtime with feature flags instead of having a super custom admin endpoint or paying an observability vendor a ton of money for being able to do that.

Or recently we migrated from Parameter Store to Vault for our secret management and that's a very backend infrastructure use case. But feature flags are perfect for that.

Adam: Yeah.

Heidi: So when Unleash talks about FeatureOps, where are you going to talk about it next? Like who are you trying to sell on this concept? I mean everybody, obviously, but who are you focusing on right now?

Melinda: So we're working with a lot of the legacy tech companies, so big banks, insurance providers, because I think they're, they're the ones who are really starting to see the benefit of deploying in smaller increments and iterating on their problems and they're seeing how feature flags are allowing them to do that.

So they're definitely the main target also it's something that you can run in your own environment and if you're kind of sensitive about customer data and stuff then it's good that you can self host in an open source platform. And yeah, I'd say that's the bigger group for us.

Heidi: Makes sense. I think that the point about self hosting is really interesting because it's always a trade off. Like the cloud gives us abundance and reach but self hosting gives us safety and control and it depends on what people need.

Melinda: Exactly.

Adam: Yeah. I think that that aspect of control also, it's one of those things where you think about some of these legacy or long standing enterprise organizations, I think a lot of this comes down to they're looking to regain control from the perspective of their own organizations and their own organizational practices and less so, from my experience, are they looking for being able to do this kind of radical delegation that would go down to user control.

And so it's just an interesting set of requirements that are a little bit different for those organizations where they're just trying to say, hey, how do we actually increase our rate of change and our ability to ship more quickly without introducing a significant amount of new risk?

And I think that the interesting part there is that like you look at trends within AI currently and suddenly everyone's like, hey, look how fast I can write code. And it's becoming more evident that the need for this control mechanism needs to be there. Otherwise things go off the rails pretty quick.

Heidi: We had been doing so well, Adam.

Melinda: Haha.

Adam: Sorry, I didn't mean to use the other A word.

Melinda: Haha. I was just talking about this with my team, how--

I feel so conflicted about AI in general because obviously I use it every day and I don't think that I could go back to a time when I wasn't using it. But at the same time, if I compare my day to day now with what it was three years ago, I don't think I'm happier and I don't think that I'm doing better.

I get frustrated so many times a day talking to Claude and it's not doing what I want it to do. And there's just so much context switching every single day. You're doing so many different things. And I am finding that I-- Because there's so many things that I'm doing that there's not level of quality that I want to see in everything that I output.

And I think that's kind of showing in the numbers as well. Like on an individual level, sometimes things are looking good, like I'm writing more code or it's even better quality or code reviews are faster and documentation is definitely, quality has gone up.

But when we zoom out and look at things at the team level, those numbers aren't the same. Like system stability or delivery stability is still going down. Especially like the more AI a team adopts, the more the stability goes down. So I was wondering--

Your book talks a lot about alignment and it feels like with AI we're getting this new kind of misalignment where individuals are potentially going faster and maybe more productive, but teams as a whole aren't.

So how do you think about that?

Adam: I was having an interesting conversation that kind of goes along with this recently. And I think one of the things that somebody pointed out was, especially since December, January of this past year 2026, the increased usage of agents in terms of generative code and things like that.

And you've got people that are doing like multi agent work where they're like, especially when you're talking about these people that are increasing their code output, 5x, 10x, you know, 100x, whatever it is. Oftentimes it's almost like they're working with a team of agents.

Heidi: Uh-huh.

Adam: And so, interestingly, this would be a very similar challenge to if you were to suddenly 10x or 100x the size of your engineering organization, you know, overnight. Right? All of a sudden, you know, those same alignment issues-- If you think about it, if you were to grow your engineering team from 100 to a thousand people. Right?

Think about what challenges that would introduce in terms of being able to align you know, what things people were working on, what direction the product's going in. All of those aspects would be extraordinarily challenging. Right? And I think that this is, you know, we've seen this just in some of the news that's come out with regards to GitHub outages.

They're basically experiencing you know, extended denial of service attack through legitimate usage. Right? It's just like they've all of a sudden seen this like kind of overnight step function--

Heidi: Scale explosion.

Adam: Yeah. This step function increase in their utilization. And I think this is where you know when we talk about alignment, like the value and importance of it is the idea that if you don't have the wherewithal and the focus on alignment, the work that you're doing, it looks a lot like motion but not a lot like progress.

So the idea is that you can run in a circle really fast, but if you're not pointed in the right direction, you're not going to actually move in the direction that's going to be providing value to your customers.

So I think that this is the thing about as organizations are adopting AI more, there needs to be something that is providing that level of alignment across the individuals on the team, the humans on the team, as well as, how are you starting to make sure that there's some type of connectivity, some connection point between the agents that those humans are using. Right?

Whether that's being kind of direct to where the agents are actually communicating in some type of pooled system. There are organizations working on that. Whether you've got some type of control plane that you've got them kind of reporting back into or updating or you have better controls of your humans that are actually doing a better job of more frequently aligning to what everybody's working on.

But yeah, this is the next big challenge for being able to scale with AI.

Melinda: Yeah and I'm wondering how we're going to solve that because-- Yeah, I completely agree with you. Like at the end of the day I think you're not actually going faster if you have to spend five hours like recovering from an outage because you don't understand how to fix it.

Heidi: And you're certainly not the only ones experiencing that. The DORA report very clearly said, like, individuals are going faster, stability is dropping like a rock.

Adam: Yeah. And I think that this is something that I have seen here in Silicon Valley. This is something that a lot of startups and teams are definitely trying to address and recognizing as a problem. You know, they're going about it in different ways. So I think that there will be more to come.

I know that large organizations are also experiencing this and like trying to figure it out. But yeah, it's definitely, for larger organizations it has definitely been a little bit of a kind of pump the brake scenario where they've been like, okay, well wait a second, maybe we actually don't want to continue to accelerate our adoption quite as fast because it's actually going to exacerbate some of these problems.

Melinda: I think you need to get Anthropic or OpenAI on the podcast and ask them what the plan is because a lot of these companies have been buying up feature flag platforms and I'd love to know, is it because they're just going to use it internally for making their product better, or is it somehow going to become an integral part of how agents work and how agents code?

Are they automatically going to wrap everything in feature flags or what is the plan?

Adam: Yeah, I don't know if you saw the recent news because there was the Statsig acquisition by OpenAI.

Melinda: Yeah.

Adam: But apparently I guess it was two weeks ago, I think, they made an announcement that they're actually licensing the Statsig code and product to Amplify, who's going to maintain and like continue to work on it. But all of the developers from Statsig and resources are still now going to work on OpenAI.

Heidi: Oh, it was acquihire.

Adam: Well, acquihire, but they're not, they didn't sell the IP.

Heidi: Mhm.

Adam: So it's some very weird partnership relationship that, you know, to your question, Melinda, like it is going to be weird how that it's like obvious that they're like, no, we use this service and we're going to continue doing this because we don't want to pay for it, but we're going to have somebody else-- It reminds me of like having like a contract development firm that's going to do the maintenance work on this service.

It just happens that contract development firm is a reasonably sized company in its own right. But it'll be interesting. I think that it's always interesting when you bring in a whole new set of engineers to work on a pre existing code base that they have no context for. So we'll see.

But I do think we definitely should look at getting someone from either OpenAI or Anthropic, you know, to kind of talk about how they're thinking about these things. I mean we know that they use the feature flags internally at both those organizations and have used them extensively to be able to help roll out new models and other aspects of their product.

But it's definitely something that you know, someone's going to figure it out and I think that time will tell, to see what kind of solutions evolve.

Heidi: I think what we need is for the agents to be able to share context windows.

Adam: Yeah.

Heidi: That sounds like alignment.

Adam: Yeah, it sounds like alignment. It also sounds like security challenges.

Heidi: Yeah, look, I didn't think we were thinking about that anymore. Ha!

Adam: Then again, if we actually had a sharing of context windows on purpose, maybe then the accidental sharing of context windows wouldn't happen as frequently.

Heidi: Could be. So Melinda, it's been really interesting to us not only how much you connected with the book, but how much what you're saying about feature flags is what we have believed. And I'd be interested to know where you have been getting ideas and where you've been developing this because it's exciting to see these ideas in the zeitgeist.

Melinda: Yeah, I think a lot of it is through pain and suffering. And a lot of the engineers who actually pretty much everyone who works at Unleash was an engineer at some point. So they bring a lot of their firsthand sweat and tears into the game.

But the person who started the company also started it because they really needed to solve this very specific problem in their team. Ivar is from Norway and he worked at one of the marketplace apps in Norway and had a big engineering team and really was struggling with these infrequent releases and just needed to make the situation better and initially just wrote Unleash for his team internally and open sourced it and then they grew into this thing.

And the community now lives today and we just work with engineers day to day and listen to their problems and try and use FeatureOps to make the product better. And I think because we're all engineers, we use Unleash every day. We can test out a lot of features internally and see if they're really useful to us as developers before we start giving it into other developers hands.

Heidi: That is so cool because it's so validating to know that you're actually solving things that people experience.

Adam: Yeah.

This is one of the things that I absolutely love about working in developer tools and infrastructure is that it is such a natural thing for you to be able to build the things that you've always wanted and test them in real time because you're finding them useful.

Well, thank you so much for joining us on our podcast. We really appreciate you taking the time.

Melinda: Thank you for having me. And I just want to say that I hope you don't start doing anything else because the book and the podcast, I feel like it's like a full time job for me to just keep up with all the good stuff that you guys produce. It's been awesome getting to know your work and I will continue following along for sure.

Adam: Awesome.

Heidi: Well, thank you so much. It is great to get a chance to talk to you and yeah, we're going to keep putting out good work hopefully.

Melinda: Thank you.