Konrad Niemiec lives in San Francisco. He is very close to his family, of which his parents are polish immigrants. He started coding when he was 11, while working for his Dad. His core values are curiosity and community, which drives a lot of what he does outside of tech. He likes to learn things, and his current hobby set includes surfing and spike ball, of which he is working on perfecting his spin serve.Konrad worked at Uber, on the self driving team. After a few years, he wanted to be less of a cog in the machine and joined a small startup. He introduced a feature flagging platform, and realized how quickly configuration bloat appeared on the platform. He also realized how dynamic configuration could take the platform beyond the limits of feature flags.This is the creation story of Lekko.SponsorsCacheFlyClearQueryKiteworksLinkshttps://www.lekko.com/https://www.linkedin.com/in/konrad-niemiec/Our Sponsors:* Check out Vanta and use my code CODESTORY for a great deal: https://www.vanta.comSupport this podcast at — https://redcircle.com/code-story/donationsAdvertising Inquiries: https://redcircle.com/brandsPrivacy & Opt-Out: https://redcircle.com/privacy
We were just really focused on, oh, what is the best parts of these solutions that we can take and put together into a product most easily and deliver it to customers? But what we didn't have a great understanding about was what problems are we solving? Are we solving the problem of getting untested code out to production and being able to roll that back quickly?
Are we solving the problem of a product manager or a customer success person or a sales person or an ops person making a change to software safely? Like what problems are we actually solving with this tool and who needs this the most? And who is that initial user base? My name is Konrad Niemietz. I'm the founder and CEO of Lecko.
This is Code Story, a podcast bringing you interviews with tech visionaries who share what it takes to change an industry, who built the teams that have their back, keeping scalability top of mind. All that infrastructure was a pain. Yes, we've been fighting it as we grow. Total waste of time. The stories you don't read in the headlines. It's not an easy thing to achieve, mind you.
Took it off the shelf and dusted it off and tried to begin. To ride the ups and downs of the startup life.
You need to really want it. It's not just about technology.
All this and more on Code Story. I'm your host, Noah Lappart. And today, how Conrad Nimitz built you a way to ship faster. with no redeploys and no mistakes. This episode is sponsored by KiteWorks. Legacy managed file transfer tools lack proper security, putting sensitive data at risk. With KiteWorks MFT, companies can send automated or ad hoc files in a fully integrated, highly secure manner.
The solution is FedRAMP moderate authorized by the Department of Defense and has been so since 2017. Step into the future of secure managed file transfer with KiteWorks. Visit KiteWorks.com to get started. This episode is sponsored by ClearQuery. ClearQuery is the analytics for humans platform. With their full suite of features, you can go from data ingestion to automated insights seamlessly.
With Ask ClearQuery, you can find valuable insights into your data using plain English. Don't miss the opportunity to simplify your data analytics with ClearQuery. Get started today at clearquery.io slash code story. Konrad Nibiec lives in San Francisco. He's very close to his family, of which his parents are Polish immigrants. He started coding when he was 11 while working for his dad.
His core values are curiosity and community, which drives a lot of what he does outside of tech. He likes to learn other things, and his current hobby set includes surfing and spikeball, of which he's working on perfecting his spin serve. Conrad worked at Uber on the self-driving team. After a few years, he wanted to be less of a cog in the machine and joined a small startup.
He introduced a feature flagging platform and quickly realized how fast configuration bloat appeared in the platform. He also realized how dynamic configuration could take the platform beyond the limits of feature flags. This is the creation story of Lekko.
So Leko is a different take on the problems that feature flagging tools are trying to solve. And we're basing a lot of what we're doing on some implementations at big tech companies. Those systems are called dynamic configuration systems. And we're hoping to apply that to let engineers and teams that build software build their features in a way that gets out to customers as fast as possible.
without the complexity and the risk these downsides that traditional feature flagging tools do and frankly let engineers ship features in an imperfect world where things are changing all the time deadlines are shifting requirements are shifting you don't have the right test data you don't have the right integration tests we really hope that engineers can ship these features as correctly and safely but also as quickly as possible
So I was at Uber for a few years working on the self-driving team. We were trying to figure out how do we connect self-driving cars to Uber's network. And that was really exciting. But after a few years, I learned a lot and I wanted to be less of a cog in the machine and really make some impact. So I joined a small startup called Sisu. There, I was the 18th engineer.
And when I arrived, I was super surprised at how little of what I had at Uber was actually available to me as a regular software engineer. At Uber, I could click a button and things would just deploy. I didn't have to learn about Kubernetes or anything like that. But the one big thing that really jumped out to me was around feature flagging tooling, around dynamic configuration tooling.
At Uber, we had the system called Flipper. Engineers used this tooling to feature flag, but we used it for pretty much anything we needed to get out there because we needed things to be really safe at Uber. But we also wanted to hand off the definition of Uber the product to individual operations teams in each city. Uber scaled to, at this point, over 10,000 cities.
And if you think about it, if Uber needs to be slightly different in all those different cities, there's no way engineers can field all the different change requests. Oh, I need to change the surge zones. I need to change the pricing.
This tooling was a way to let other folks in the business who are making decisions around how the product looks, around what the business needs, and actually apply that directly to the software. And I think that's where Flipper really shined. When I came to Sisu, we had nothing like it at first. And we had these really terrible deploys that took a long time.
We were fielding requests from products left and right. And so we introduced a feature flagging tool, one of the leading ones on the market. And after implementing it, I realized that it both didn't solve all the problems I wanted it to, but also came with its own problems. After six months or so, a team of 20 engineers had over 100 flags. We had no clue what any of them did.
And the reality was we were just trying to move fast. And in doing our job, we ended up creating a very risky situation. We ended up taking down the system for some of our biggest customers. And we also had our teammates across the aisle in product and customer success and solutions architects also causing issues, which is not something we really wanted to.
So I was looking back at the tooling at Uber and I was thinking, why don't I have something like that? Like, why don't I have a dynamic configuration system like we had at Uber? And it turns out also is at Google and Facebook and DoorDash and a few of these other really large tech companies with a lot of engineering resources. So that was the kernel of the idea for Leko.
And that's how I got started. A little over two years ago, decided to venture out on my own at the time and try to solve this problem.
Let's dive into the MVP of Leko, that first version of the product you built. How long did it take to build and what sort of tools were you using to bring it to life?
So we actually built two MVPs. So the thing we're launching right now, our free forever plan is actually the second iteration of their product. So first I'll talk about the first one. It took us around maybe six to nine months to build the initial iteration of the product. And we hosted most of the things on AWS. We used GitHub, of course.
And we were focused on a bunch of different problems and trying to figure out which frameworks should we focus on, which languages should people use. We first started with Go because that's what we were doing locally. But then we also wanted some front-end SDKs because we had a full-stack app. So we were really trying to figure out the breadth of things.
We ended up writing a component in Rust that helps users deploy things in their own infrastructure if they want some additional backup, which users can use now. And it took us around six to nine months for that first iteration of the product.
Let's stay on that version or that MVP, the first one. Those decisions and trade-offs you had to make when you were building those, right? They're hard. You gotta really dig in and figure out what you're gonna focus on, how you're gonna approach the problem and all those sorts of things. So tell me about some of those you had to work through in this first version and how you coped with them.
Yeah, so at first we were really trying to figure out, hey, how do we build a really scalable and usable system? Trying to unlock what is a good developer experience and what is something that appears simple, appears very intuitive, but is also obviously very difficult to build yourself and contains a lot of complexity under the hood was I think the biggest thing that we were struggling with.
How do you make something that checks all the boxes, has the features that a user expects, especially since we're coming in adjacent to an existing space?
Feature flagging tools and experimentation tools out there exist, so we needed to figure out which one of those existing requirements to pull into our current system, but then really focusing on how do we make this system simple and really easy to use for engineers.
This episode is sponsored by Cashfly. The web is a competitive place, and if your site delivers its content pixelated slow or not at all, well, then you lose. But that's where Cashfly comes in. Cashfly delivers rich media content up to 159% faster than other major CDNs.
Through ultra-low latency streaming, lightning-fast gaming, and optimized mobile content, the company offers a variety of benefits. For over 20 years, CatchFly has held a track record for high-performing, ultra-reliable content delivery.
While competitors call themselves fast or use cute animal names, only CashFly holds the record of being the fastest and serves customers like Adobe, the NFL, or Roblox, where content is created by users and must be delivered in real time. For the first time ever, CodeStory listeners can get a 5TB CDN for free. Yep, you heard that right. Free. Learn more at CashFly.com slash CodeStory.
That's C-A-C-H-E-F-L-Y dot com slash CodeStory. This episode is sponsored by KiteWorks. Legacy managed file transfer tools are dated and lack the security that today's remote workforce demands. Companies that continue relying on outdated technology put their sensitive data at risk. And that's where Kiteworks comes in. Kiteworks MFT is absolutely the most secure MFT on the market today.
It has been FedRAMP moderate authorized by the Department of Defense since 2017. Through FedRAMP, Kiteworks' level of security compliance provides a fast route to CMMC compliance, saving customers time, effort, and money. Kiteworks MFT makes it easy for users to send automated or ad hoc files via fully integrated shared folders and email.
Administrators can manage policies in a unified console and create custom integrations using their API. Did we mention it's secure? The level of security with KiteWorks solution is rare to find. Step into the future of secure managed file transfer with KiteWorks. Visit KiteWorks.com to get started. That's K-I-T-E-W-O-R-K-S dot com. So then from that point, right, you start to progress forward.
And I think this is where the next MVP sort of introduces itself. And I think that's part of the progression of the product. So tell me about that MVP version two and also how you went about deciding that this was the most appropriate thing to do next. And, you know, to wrap in a box a little bit, kind of roadmap building.
How do you go about deciding as a company that this is the next most important thing to build or to address for Lecko?
I think the thing we were trying to do is how can we figure out the minimum thing that we can get users to use and to actually solve problems with. And I think that is the toughest piece, especially coming from large tech companies to a small organization. I was coming from Uber. We have one of the tech leads of Configurator, Facebook's dynamic configuration system on the team.
We have an angel investor, Tom, who was the creator of Flipper at Uber. And if you take a big tech mindset of a roadmap, you're just thinking about lists of requirements and what you might like in the system.
But really how we thought about it was what is the minimum thing that is going to solve the problems for our users and trying to be as ruthless as possible when it comes to the prioritization. Christina Noren, who's our product advisor, famously says there's no such thing as roadmaps.
So I won't exactly use that as my answer to your question, but I do think that we need to be just constantly reprioritizing and trying to figure out what problems are we solving? How can we get the simplest thing into users' hands as possible? And then once you have users...
then you can triage okay are we actually solving those problems and what are they telling us they need what problems are is that solving are those feature requests solving and then trying to prioritize there so at this point we have a forward-looking idea of a roadmap where we have a vision of the company we really think leko
It's going to change the way people build software and it's going to be much more dynamic and much safer. And it's going to be integrated across the business, taking into account the business needs and defining the product at a high level. But that there's some medium level of a roadmap that I think doesn't really exist for us right now, just because we're constantly reprioritizing.
You know, I hear I hear you talking about or I hear you saying we write. Tell me about how you built your team and what do you look for in those people to indicate that they are the winning horses to join you?
Getting people who had actually experienced this and have both either felt the problems of missing this kind of tool or folks who have built this kind of thing and solved these problems internally at big tech companies was great. Like relevant experience, I think was important, but that's not the entire team.
So I think the two things that I really focus on, especially when interviewing and looking for team members is motivation is the first piece. You can tell by talking to somebody and asking them what they're proud about, how they're motivated. And if someone is motivated by really solving problems and building something that's really helpful for people, that's a huge part of what I look for.
And then the second thing is something that I think is not usually looked at a ton in early stage startups, but how people work interpersonally, like how they interact with each other. And when it comes to Interviewing, that's obviously tough.
One thing we do is we've instituted a trial system, which you've heard, I think, Linear and a few other smaller startups also institute this, where someone comes in for a week or a few days and tries to ship a feature and you can really get a sense of how they are to work with. But even when you ask about past conflicts, you can tell, does somebody have some nuance?
Are they trying to consider other people's opinions or do they have a very black and white opinion of things and they bucket you into either right or wrong? Unfortunately, you see that a lot with software engineers. Sometimes we try to reduce humans into a program.
And so trying to find folks who are really thinking about what effect do I have on the other people on the team, I think is very important for me as a leader and to cultivate that kind of culture on the team.
This episode is sponsored by CashFly. The web is a competitive place, and if your site delivers its content pixelated slow or not at all, well, then you lose. But that's where CashFly comes in. CashFly delivers rich media content up to 159% faster than other major CDNs.
Through ultra-low latency streaming, lightning-fast gaming, and optimized mobile content, the company offers a variety of benefits. For over 20 years, Catchfly has held a track record for high-performing, ultra-reliable content delivery.
While competitors call themselves fast or use cute animal names, only CashFly holds the record of being the fastest and serves customers like Adobe, the NFL, or Roblox, where content is created by users and must be delivered in real time. For the first time ever, CodeStory listeners can get a 5 terabyte CDN for free. Yep, you heard that right, free. Learn more at CashFly.com slash CodeStory.
That's C-A-C-H-E-F-L-Y dot com slash CodeStory. Hello? Welcome to the Data Analytics Club. Do you know the password? No, didn't know there was one. Do you know how to code? Uh, no. Do you know how to query data? Like, ask a question? I guess not. Hmm, I see. Then you can't be in this club. Sorry. Goodbye. Don't be left out of the analytics club. ClearQuery is the analytics for humans platform.
With their full suite of features, you can go from data ingestion to automated insights seamlessly. ClearQuery provides you with the information you need without requiring you to do the heavy lifting. Their Ask ClearQuery feature allows you to ask questions in plain English, helping you find relationships and connections in your data that may have previously gone unnoticed.
You can even visualize your data with presentation mode, taking your data storytelling to the next level. Pricing is based on storage, not licenses, and that ensures that you get the most bang for your buck. Don't miss the opportunity to simplify data analytics, your data analytics, with ClearQuery. Get started today at clearquery.io slash codestory. So this will be super interesting.
Given what you've built and who you're building it for, I'm curious about scalability, right? You know, obviously you build for scale the best you can in the beginning with abstractions and things. And I'm curious, did you approach it that way from day one or have there been interesting areas where you've had to fight it as you've grown?
So I think this is actually one of the mistakes we made where we were a little too worried about scalability at first. I think we were trying to get something out there that we thought was going to be the best system possible from day one, which I think frankly is pretty much almost never going to happen. Like you're going to have to iterate, you're going to have to put a first version out there.
So I think initially we focused a little too much on scalability and I think that may have slowed us down a little bit in the long run. You never really expect everything. You can't anticipate everything once you get out there and launch. So I do think that there are things we've learned that we didn't quite anticipate for in terms of certain aspects of scale.
But I think in general, an engineer has to, especially an engineer who has worked at a big tech company, who has been taught to build for scale. I think you actually need to fight that if you're at an early stage startup and try to say, we don't actually need to make this super rounded because users might not even want that. Or this might not even be what we end up building on in the future.
We might rewrite this in a few months anyways. So I think fighting that has actually been a priority of mine and something that we're trying to push with the team.
So as you step out on the balcony, you look across all that you've built thus far. What are you most proud of?
So I'm most proud of the fact that I think we're approaching this problem, which I think has been solved in a very similar way. If you look out across the ecosystem, I think in a fairly novel way, and I'm very excited about that. And I'm hoping that listeners of this podcast will get a chance to look at our website and try out our free forever tier that's launching this week.
and we can see that instead of having an external source of truth and some system which is difficult to debug we've really met engineers where they are and given them a novel editing experience and interaction experience with a dynamic configuration or a feature flagging tool and that's what i'm really proud of is i think we've found something that our initial users are really excited about and even i think similar ideas popping up in surrounding spaces which i'm really excited about
Let's flip the script a little bit. Tell me about a mistake you made and how you and your team responded to it. I know you mentioned the scalability mistake, and maybe it's that one and you want to dig in more, or maybe it's a different one.
So I think one of the biggest mistakes we made from our first MVP to the second was we weren't really focused on what problems we're solving through our tool. Everyone on the team had seen dynamic configuration tools work really well internally at big tech companies.
And we were just really focused on, oh, what is the best parts of these solutions that we can take and put together into a product most easily and deliver it to customers? But what we didn't have a great understanding about was what problems are we solving? Are we solving the problem of getting untested code out to production and being able to roll that back quickly?
Are we solving the problem of a product manager or a customer success person or a sales person or an ops person making a change to software safely? Like what problems are we actually solving with this tool and who needs this the most? And who is that initial user base? That was our biggest mistake was we were really focused on the solution instead of the problems that we were solving.
I think frankly, the feature flagging space solves a ton of different problems and even just listing them out takes a while. But once we made that shift, I think that was when we were really focused on our second version of the product.
We focused on simplicity and easy to debug and great developer experience, which we were focused on the whole time, but really through the lens of simplicity, because one thing we realized is we built a product that was a great solution, but it was actually very complicated and hard to get started. I think that was our biggest mistake with the first MVP.
An approach in general, I think, which led to a very complicated product that was tough to onboard to and tough to use. So we're really excited to hopefully have people see that it's very straightforward to get started with Leko and they can feel that benefit right away.
So this will be fun, Conrad. What does the future look like for the product and for your team?
The future, maybe in the medium term, I'm super excited about. After we launch our free forever tier, we're looking forward to launching our team plan later this year. And with that, we're going to take a bunch of our learnings from some of our early guide customers and really help businesses organize the configuration of their product at a high level.
So right now with this launch, we're focused on the developer tool and obviously handing off control of software to other teammates across the business. But how can we actually use this to define the high level configuration of our product? What are the allowable configurations? Is it having these five features and a limit of 10,000 reads a month? Is that the team plan?
And then the enterprise plan has a scalable one. You can basically use Lecko to define that at a high level. And what that lets you do is it lets teams understand avoid untested code slipping to customers. You can really scope down what you can test and integration test. And we think it'll really have benefits across the business all the way to kind of retention and revenue and things like that.
And we're also going to be launching more AI features that we're working on currently, which I think will help engineers interact with the tool and help folks outside of the engineering organization as well, who will be able to understand, hey, when I'm making a change, what is the estimated impact of my change? What is this actually going to do in my code? Can I preview that?
Can I easily reproduce that? Can I capture this intent of what I'm trying to do, what change I'm trying to make? So we're really excited about both the high-level product configuration that we're launching, as well as more AI features that are going to come soon.
Let's switch to you, Conrad. Who influences the way that you work? Name a person or many persons or something you look up to and why.
So I have a few folks that I was thinking of, one of which is one of my mentors, Peter Edge. He's the founder of a company called Buff, and he's been a mentor of mine for many years. Initially, when we met at Uber before he left to start Buff, and I really look up to him in terms of
taking a tool that he's very excited about and very passionate about and has delivered value internally and being able to deliver that in the market and really find a place where developers are excited about it, teams are excited about it, but also able to build a community around this open source project that he's done a great job with Buff. I really look up to him.
My founder coach, John Zimmerman, is a great influence on me. And I think the introduction to the conscious leadership framework and the way that he approaches things, you know, not trying to approach every situation from fear and wanting to be right, but actually from growth and curiosity, which are fantastic. two of my biggest values, I think has been a huge influence on me.
And then also somebody like Tom Chen, who originally wrote this tooling at Uber, and I think has been a great help for me over the last few years as an angel investor in our company, but also a mentor to me.
Last question, Conrad. So you're getting on a plane and you're sitting next to a young entrepreneur who's built the next big thing. They're jazzed about it. They can't wait to show it off to the world. And can we show it off to you right there on the plane? What advice do you give that person having gone down this road a bit?
really focus on your user and their problems. If you fall in love with the problem that you're trying to solve and really know it in and out, then you will obviously be more likely to solve that for your user, but you'll also be able to approach everything with a clear lens because you're just trying to help. And I think for a lot of technical founders like myself,
like resisting that urge to build, resisting that urge to build for scale and instead just truly understand that problem. I think that is the biggest advice I would give to that young entrepreneur. And I think I would give to myself to really just focus on that problem and make sure that you're approaching everything with just trying to solve that problem for your current or future customers.
I think that's fantastic advice. Well, Conrad, thank you for being on the show today. And thank you for telling the creation story of Lecko.
Thank you.
And this concludes another chapter of Code Story. Code Story is hosted and produced by Noah Laphart. Be sure to subscribe on Apple Podcasts, Spotify, or the podcasting app of your choice. And when you get a chance, leave us a review. Both things help us out tremendously. And thanks again for listening.