We love hearing from LaunchDarkly customers, because we never know what great stories they're going to gift us—from the image of a monkey flipping feature flags to what professional kitchens have to do with the old "build vs. buy" chestnut.
First, meet our guests:
- John Hollow, Senior Principal Engineer at Optum
- Justin Duhatschek, Progressive Delivery Manager at KBX Technology Solutions
- Mark Eisner-Engebos, Director of Partner Strategy at KBX Technology Solutions
They were hosted by Karishma Irani, Head of Product, LaunchDarkly at a Galaxy session in Chicago. We've captured some highlights below, but be sure to watch the full discussion and the rest of the Galaxy talks when you have some time. And stick around to the end for a build vs. buy comparison that would make Gordon Ramsay proud.
What challenges was your organization solving for with LaunchDarkly?
Getting value to customers faster, minimizing risk
Justin Duhatschek's team at KBX was starting from scratch when they adopted LaunchDarkly. This was great on one hand, because they didn't have a monolith or legacy codebase to break down, but it did mean they had to build from the ground up.
"We did a lot of research into what are the best release styles to get our value out to our customers faster and minimize the risk," Justin said. "And through that we learned about progressive delivery and then LaunchDarkly and feature flags."
A top priority was ensuring that KBX developers were free to focus on what provides the most value. Justin explained, "I can turn the flag on and off. I mean my monkey can do that! So I can do that, and the developers can focus on the value."
Giving more control to stakeholders
Progressive delivery is all about giving the right people control of a feature at the right time. John Hollow (Optum) shared, "We introduced feature flagging to applications to give more control back to the stakeholders, the product owners. And honestly as an engineering team and an engineering lead, I want to give them more control. I want them to be able to manage their application and it takes less burden on us for deploying releases for every little tweak that they want to do, of course."
Enabling interconnected teams to move quickly and independently
How do you allow different groups to test independently while ensuring everything will work together in production? This was a concern for KBX : "Our teams are all interconnected. We have a lot of dependencies, we have a lot of teams that all need to work together to get a certain product out the door," Justin said.
"Something LaunchDarkly definitely provides for us," he continued, "is the ability to connect all those feature flags together, have them under a parent flag or various parent flags, and then allow us to say, 'Okay, these six teams can test their things independently, but we know they're going to be launched together in production.'
"So we have that control and it gives them that visibility … because our product teams aren't the only ones that care. We have our customer success team, our solution design team, our support team, all of them need to know what's going on as well."
Aligning on best practices
"Something that I'm very passionate about is making sure that all the code is in master … but there are teams that I've come across even at Optum that don't do trunk-based development," John said. "And the reason they do that is because they're trying to manage features in the way that they know how, which is 'Let's have different branches and a branch corresponding to each environment and let's make sure that the code that we want to go on each environment is in that branch.' It's chaos if you're an engineering lead trying to oversee all that code."
So, instead, John advocates for everything to live within the mainline branch. And he feels feature management is the best way to be able to turn things on or off.
What’s your favorite part of the LaunchDarkly product?
Maintainability
For John at Optum, LaunchDarkly’s tools make it easy for him "as a steward of the code" to find and remove stale feature flags, keeping the codebase clean.
Audit logging
John also called out the usefulness of logs that enable Optum to answer questions like, "When did this feature go live? When did we start piping all of our data to this API?" This is especially handy for regulatory compliance reasons, where they might need to go back and check when something was activated and report back to the governing body.
Making on-call less stressful
Coming from a support background, Justin is a fan of using feature flags to reduce or even eliminate the need to get people up at night to address an issue when on-call.
"One of the main integrations I am excited for is Datadog and being able to say, 'Okay, well something's awry,'" he said. "Rather than calling someone at three o'clock in the morning, we'll just shut the flag off. We'll figure it out in the morning, please stay asleep."
How do you measure the success of LaunchDarkly?
Our panel guests had three approaches to measuring whether LaunchDarkly is bringing value to their organization:
- Scorecard: Mark Eisner-Engebos (KBX) has a scorecard of ~50 different metrics, including cost and ROI, product roadmap and innovation, and SLA performance.
- Internal surveys: Justin surveys his teams to understand their pain points and how much time/energy they're spending on rollbacks or hotfixes. They also consider metrics like mean time to resolution and deployment frequency.
- Are things on fire or not? For John, it's as simple as that.
We'll leave you with a helpful analogy from John on the classic build vs. buy debate:
"Let's pretend that you're a chef at a restaurant and you just want to make good food—consistent, healthy, safe, warm food for all your customers … And your boss, the restaurant owner, he or she just wants his customers to be happy. So if you found a really, really nice oven that you wanted your boss to buy and you're like, 'Hey, this is going to help me make food so much better, would you mind purchasing this for me?'
Or maybe they're like, 'Well, you know how to make food. Can you just make your own oven or something?' And it's like, 'Well I kind of just want to focus on making good food for our customers.' And so that's really the argument that I make. I'm an engineer and I just argue for using the best tools available."
