What was the first amazing hire that you made? And what about them was so amazing? got lucky with hiring because

the thing that I was building was just something that I worked on for like almost two decades as a professional engineer. So my first hire was literally my boss from Qualcomm that was like my principal engineer that like taught me almost everything I know about how to design operating systems and stuff like that. I was able to like, you know, he was on his way to retirement. And I was like, you got to do this. We're putting the band back together. You've got like a few more years of like pushing code left idea and like was able to get some really really good folks uh out of qualcomm to go build this with me um i i think another like lucky thing raj is not a hire he's a co-founder was just meeting raj from a mutual friend um And so like, when I quit my job, I already have kids, my wife had an awesome job, she was working and was able to support us. And I was in the Bay Area, and I kind of gave myself six months, either you raise money, and you get a team together and you this thing gets going, or you go back to, you know, fulltime work, because you have to support your family and stuff. Being in the Bay Area gives you that opportunity, because there's so many companies that if you're a good engineer, you can always find work as an IC. So having a spouse that has a tech job, that gives you that flexibility too. Because I had the six-month gap, I was just like, I'm going to pull in everybody I know, everyone that would say yes, get joined. So like, I was lucky enough that my closest friends were like, trusted me enough to go do this. And like, we're compiler, like expert GPU expert, like folks like that. And like I randomly met Raj through a mutual friend. And he seemed awesome. And I was like, dude, you got to like go build this thing with me. And he said, okay, I'll give you six months to go help you raise. And we'll see what happens. The thing is, there was no interview process. There wasn't like a way to vet a co-founder. You just kind of have to trust somebody. And because I had time was such a constraint for me and family and all this other stuff that it was just like, I was like throwing darts at a board and I just happened to get lucky with a really, really good co-founder. I don't know how to like right

how

do you manufacture that like i think why

do you and raj work so well together what strengths do does he have that you don't and vice versa um this is like a the people have talked about

founder mode what founder mode meant to me was that it's easier with engineering because things tend to get logical but like when you have a lot of options and you don't know what to do you can argue them to the point where you whittle down to the options that are Pareto efficient like I can argue with Raj and if he's willing to argue back with me we're having a healthy discussion and we get to the point where like we've exhausted the arguments like and it doesn't matter what you pick like the two options are left yeah right like they're both like okay we've eliminated every possible way like every every alternative these two things whether you do it or you don't do it it makes no difference and that process is exhausting and he was willing to go do this with me that's what made him a good co-founder so he was willing to grind through the really really hard decisions and like through all of the stuff until we got to like a kernel of truth where like okay it doesn't matter like if we do a or b but like we at least know that these are good enough.

And

only any last bits of

advice for the aspiring young potential founder out there uh should they even do it at all uh what bits of advice do you have? Um like

I had a side project that always wanted to like start a company and raise money and stuff it is an awesome experience and amazing and like exhausting so i would definitely recommend doing it and like as if you're an engineer and i see like that codes um you're kind of in a blessed position to be able to do this because the reason to do it is when you know you can build the whole thing and the only reason you're raising is that you're just trying to speed it up and hand off work to people that can help you get it done. If you have that idea and you know you can just build the whole thing and you love this product and it's just everything is like obsessive, you're pressing with it and you're really trying to push it through, it's definitely worthwhile to go try it and give it a shot. So it's exhausting, but, you know, like I think the world moves in spurts driven by people with that kind of energy, just like pushing stuff forward. So you got to do it.

Anatoly, thank you so much. For

sure.

Cheers. Cheers. Bankless Station I'm here with Stani Kulikov, the creator of Aave and Lens. After pivoting ETH Lend into Aave in 2018, Aave now has over $12 billion in TVL and is perhaps Ethereum's largest application. And if that wasn't enough, Stani has also been leading the effort behind on-chain social networks with Lens, making him a two-time successful entrepreneur in crypto, which also makes him a verified crazy person. Stani, welcome to Bankless. Thanks,

David, for having me here and such an honor to be again. And we're quite old friends. Yeah.

Yeah. Stani, tell me about the moment that you knew that you wanted to become a builder. Was that before crypto, entering crypto from a very young age? How did you know that building was in your DNA? I

started very early. Essentially, my brother used to program on more of like a Linux operation system level. And I picked up essentially because we shared the computer. I was very young. I started to write in PHP and down the line later in Ruby on Rails and getting more excited about web applications during kind of like a web 2.0 boom. So it was in early teen years. I just liked the idea of creating something technically useful and seeing other people to use it and also like doing it globally. So being able to like internet enabled building for everyone across the world as long as people have an internet connection. So I think it was very early in my teen years that I wanted to create something. But

creating something and building a product and leading a team are also different things. There's a lot of solo hackers out there who love creating software, but the difference between a hacker and a unicorn is also very different. When did you decide to build a product? Was there a spark? Was there a moment? And how did that go?

Yeah, regarding building an actual product, so to build a product, it's important to understand what products essentially mean. it's something that you build something that has demand, either utility or either some sort of other factor why people want to use it. And it actually has a quality factor that makes it to stand out for people to actually pay for that. And that's essentially what a product is. So realizing that that helps you actually get there um i realized first time that i wanted to create product where uh during needland i realized that you know this is something that people actually see as useful being able to earn yield uh on on the blockchain um being able to um against your cryptographic assets, and also being able to build interesting things and expand the whole ecosystem. And I think at that point, when I realized that people actually don't see this as a only as a toy or a tool, but something they actually spend a lot of and invest a lot of time into using, I realized that this is actually becoming a more product to me. And then I, with our team, we started to actually build towards direction, what could be the best possible experience and the best possible outcome for the user, and doing it as highest quality as possible. And DeFi, the quality essentially means doing things securely, having smooth experience, and being available to as many users as possible. And I actually, David, think that product is never finished. I think we, at Aave, for example, we satisfied the needs of people who are early in DeFi, are experimenting with the technology and using DeFi. But there is actually like a way, way more bigger pie of users that don't really know that DeFi exists. So we have a product, but we don't have a good enough product to actually attract more users outside of the existing space. And that's where we're actually focusing on. I

think, Sani, when you started off your journey building Aave, you started off more on the hacker, developer, engineer side of things, and over time, like, had to lean into product skills. Did you learn that products came naturally to you was that

a hard thing to learn how did you learn how to be a product person i find uh being good at product uh incredible difficult um because essentially you have to do a couple of things um and and spend a lot of time on on those things. So one is talking to the people that are constantly using your product, or even like not constantly, but even like frequently, and also talking to people that are not using your product. And important there is to actually understand reasons why and why not, and things they like and don't like, and actually understand their user stories, their backgrounds, and then putting that into a bigger set of data and then analyzing and trying to build upon features or directing the product to that way that it actually captures a lot of these points. So that's basically what is important. And I think doing that organically is really difficult because first of all, it's very hard to hear feedback, whatever it is on the product side. And what really helps, especially in case of like Aave or Lens, is that I use these products myself ongoing basis. So I essentially think also about products in a way that I build them for myself. So when I master the product itself, and I know what's best for me, it might be best for a few other people. And then I try to go outside of that kind of like own bubble and try to understand how other people are using with different profiles, our products, and also how we can reach the audiences that we don't have as customers at the moment. So it doesn't necessarily come organically, but the fact that you're using your products yourself actually helps to get there at the first steps. And the next steps is to reach out to people that have different backgrounds and they use the product for different reasons than you might be using it. So

Stani, you've been a builder, a leader for like eight years now. What advice would you like to go back to young Stani with and tell him back at year zero and year one? What's the advice that you would like to have learned all the way back then? Yeah,

probably the most biggest one is that it really takes time to build something really useful and getting it to a quality that is something that you can distribute. So I, naively, when I started building, you know, I was always thinking that, you know, I'm going to try something and build something for now and see like if it gets traction for the next few months. And if not, maybe I will build something else. But what I've realized over the years is that if you have something really useful and there is that demand, actually building and scaling that product will take time. So mastering the art of product is a really long game and it requires pretty much a full of your investment. Sometimes it actually means that you have to sacrifice maybe some other parts of your life for that moment that you want to really get a product right. And then the second thing is that I will guide that a product is never finished. So whenever essentially it feels that we have something really good and we have traction, that doesn't necessarily mean that your work might stop there because end of the day, that's just getting to a next chapter of that product development. So it's important to constantly trying to understand how to make your product better and how to get a better distribution to new audiences. I think those are the things. And obviously, last thing I would say to myself and everyone else is that taking risks and bets is a really healthy thing to do. So just like if you have a gut feeling that some new thing might work, betting on that might be very interesting in your product. Not necessarily jumping from one product to another, but actually thinking like you might have a conviction of something you want to try. You should try it because that helps you to understand what people might feel about it and calibrate what you're building. What

about when it comes to team management? I don't know how large the Aave companies are now, but I would imagine it grew past Dunbar's number or at least past like 40 or 50, like a long time ago. When did you learn about delegation? How did that go for you? And what did you learn about yourself as you were going through that process?

Yeah, delegation is really hard. And organizational design especially is really a difficult area, and it's something that also I struggle as well. It's not something that is really easy to manage, but I would say that most important is that, especially when you're starting up keeping it as clean as possible and trying not to hire too many people in fact this usually happens through different kinds of like events like fundraisings and and so forth and I think especially in our space we tend to kind of like have an approach where you want to hire leadership and you want to hire teams, dedicated teams to different sectors from like growth, engineering, growth and whatnot. But it's all in most cases very premature in my opinion because end of the day, before you have actually a revenue-recurring business, maybe you don't need yet, for example, anyone on the growth side. Maybe you don't need any marketing at that point. Maybe you just need to be pretty much product engineering driven until actually you hit a point where your product has good usage and it can actually build revenue. And I think that's the biggest mistake everyone does, and including me, and getting away from that. Avara itself is quite lean. I mean, we're 70 team members across multiple products. So it's quite lean if you look at all the things we do at the moment. And I personally, I work with every single person in the company, and that's why I want to keep it clean, because at that point I can go to an engineer and talk about, for example, a new interest rate strategy that we are implementing, or new liquidation strategy or engine that we're implementing, or on, for example, on Lens side, a new feature we're essentially building or it might be something related to back office as well so that's why like that's kind of like a my type of working so i i want to be as not i would not even call it flat but just working directly with the talent and i try to also invest in. So that's one of the important things I learned is that the more you invest in people and culture, the more it actually pays off. And the more you can delegate because you have more trust in people doing certain things, certain way, and you can ensure that it's done with the culture that you've established. So I think that's the kind of like basis I have for delegation. As

Aave has grown, what are some of the activities or behaviors that you've spent time on unexpectedly? Things that you didn't know that you were going to have to do, but then ultimately became like pretty important to your job and to the effort. I

think talking to maybe different stakeholders or different people inside of the community, outside, that aren't necessarily related to your product, and you kind of feel that you don't really want to spend time on because everything that every second you spend on the product gets you into a better place. But I think Aave is also building not just a product, but technology. And what I mean about that is that it's something new that you can actually build upon. But as a technology, it also means that there's uncertainty whether the technology itself gets adopted or accepted publicly. So I do spend some amount of time, for example, talking to different governmental agencies. I talk to institutions that are looking into, for example, DeFi, but aren't really doing anything yet, but could be potentially using in the future something like Aave as a protocol and integrating that to their own backend. And why I think it's important is that you kind of like have to also participate in those and contribute in those discussions without sacrificing what's the most important for you, which is essentially the product and the users and being able to get better at things.