Episode 256 ·
Hrishi Dixit - CTO at Yieldstreet
Today we are talking to Hrishi Dixit, the CTO at Yieldstreet. And we discuss their mission to democratize access to financial investments, thoughts on building architecture for a future that isn't clear yet, and how to pull yourself out of the weeds as a CTO when experiencing massive growth.
All of this, right here, right now, on the Modern CTO Podcast!
Check out their blog at distributed.yieldstreet.com!

About Hrishi:
Hrishi serves as the Chief Technology Officer for YieldStreet. He has been involved with YieldStreet since early 2015, helping build out the base technology platform for its April 2015 launch, and serving as a formal advisor for two years before coming on board as CTO.
Prior to this, Hrishi was the Founding CTO of LearnVest– a New York based financial planning startup acquired by Northwestern Mutual in 2015 for over $300mm. He also co-founded, and serves as an advisor for, Wellsbi, an early stage digital health startup.
He was also the co-founder of Gordian Labs, a boutique software development and consulting firm that specialized in financial systems and internet startups, where many successful startups like LearnVest and Twilio were “tech-incubated.” He continues to serve as an advisor and angel investor for many startups, particularly in FinTech and digital health. He has lived in the internet startup space for over 20 years, built and deployed large-scale applications in several domain verticals, with a specific focus on financial technology and data-driven transactional systems, and led distributed engineering teams across the globe.
Hrishi holds a Masters degree in Mechanical Engineering (with a Minor in Computer Science) from Cornell University, and hopes to retire within walking distance of Lagavulin Distillery in Scotland.
About Yieldstreet:
Yieldstreet is changing the way wealth is created, providing access to asset based investments historically unavailable to most investors. Yieldstreet allows you to effortlessly participate in opportunities with low market correlation and target yields of 8-15%, across litigation finance, real estate and other alternative asset classes. We believe our technology platform creates a unique experience for investors at every level and provides valuable diversification and strength to most portfolios.
Transcript
(Joel Beasley at 00:00:00) Hello, my friends. Today we are talking to Hrishi, the CTO at Yieldstreet, and we discuss their mission to democratize access to financial investments, thoughts on building architecture for a future that isn't clear yet, and how to pull yourself out of the weeds as a CTO when experiencing massive growth. All of this right here, right now on the Modern CTO Podcast. Here we go. This is the Modern CTO Podcast.
(Hrishi at 00:00:36) Hello, hello, Joel. How's it going? It's great. Good to meet you.
(Joel Beasley at 00:00:41) It's so good to meet you. I'm really excited. Where are you calling in from today?
(Hrishi at 00:00:45) Midtown Manhattan. That's our global headquarters of Yieldstreet.
(Joel Beasley at 00:00:51) Is it like a ghost town now there?
(Hrishi at 00:00:54) A little less so than it was about a couple of months ago, but yeah, it's weird. It's weird to look down on Park Avenue and see like a sixth of the number of cars that you typically see during rush hour. So it's weird, man. It's strange to be in the city. A little less so now, but May and June were like, what is going on? You know?
(Joel Beasley at 00:01:17) How are you feeling?
(Hrishi at 00:01:18) First time I walked through Times Square. I mean, you know, it's good. The city is kind of waking up a little bit, and it's always good to see. There's so much velocity in the town in general. So it was just bizarre. It was like half expecting zombies to come walking out in the middle of the day. But you know, luckily it's coming back. Hopefully it just continues that way.
(Joel Beasley at 00:01:40) Are you prepared for the zombie apocalypse?
(Hrishi at 00:01:44) When are we not?
(Joel Beasley at 00:01:45) I know, right?
(Hrishi at 00:01:45) No, it's just going to happen. No, but man, I'm telling you, walking through Times Square at 11 a.m. and not seeing more than two people is just weird.
(Joel Beasley at 00:01:54) I knew you were going to be a good person to talk to when I was reading your bio and it said that you want to retire within walking distance of the Lagavulin Distillery.
(Hrishi at 00:02:04) Yes. Work is underway for that.
(Joel Beasley at 00:02:08) Yep, yep.
(Hrishi at 00:02:09) Scoped out a little cottage and stuff. I take it you're a scotch person as well?
(Joel Beasley at 00:02:13) Our producer, Jake, is really into it. He's been over there to visit, and I learned about it through the show Parks and Recreation.
(Hrishi at 00:02:23) That's awesome. Yeah, no. Interesting that I discovered Lagavulin in a TV show as well. It was in an episode of The West Wing.
(Joel Beasley at 00:02:30) Oh. So I was just curious, like, what is your origin story? How did you get started with technology?
(Hrishi at 00:02:38) Oh, that's just fun. So my family owns a bookshop, or owned a bookshop, back in India where I grew up. And I used to work there in the summers. And one summer in 1986, I think I was 13 or 14 years old, and I saw this book and it was called You and the Computer. It was like, it was a kid's book, really. It was to get young adults and teenagers. And computers in the '80s in India especially were a fascinating new thing, right? You know, the world in general, but certainly back in India. So I started reading this and I was like, this is incredible. I want to do something with it. So there was an opportunity in my high school at the time where a gentleman came in and started teaching basic programming. And on weekends he would bring in a little keyboard and a monitor, and he would give these fun exercises, actual programming exercises to work on. And I wrote my first program when I was 14 to—it's a little program in Basic to try to convert Celsius to Fahrenheit or something like that. And I was hooked. You know? And especially once we learned loops and you're able to build patterns using ASCII characters. And hey, this is an interesting-looking carpet that you can build just with three lines of code. And that was it. That was the kicker. So that's kind of how I got fascinated with the idea of computers, right? You know? And they were nearly not as ubiquitous as they are now. And then as I went to college and stuff, I went to undergrad back in India, and computer science was not offered as a program in the school that I went to. But I'd have to move to a different city, one that I don't particularly enjoy living in—Bombay or Mumbai as it's called now. So I couldn't study computer science as a major in undergrad. So I did mechanical engineering. But when I came here for grad school, I got the opportunity to stay in mechanical engineering, but kind of branch out in computer science by using computer science to solve mechanical engineering problems. So my very first real programming experiences were solving these incredibly complex algorithmic problems in computational theory and design theory, which was kind of like a double whammy for me because all of that theoretical mechanical engineering was new to me, as well as the hardcore C programming, which I hadn't done a lot of. But, you know, it's one of those things where there is a click in your head. Like, you just realize, I get this, and I love this. And that was it. And from the early '90s to here where we are, early 2020s now, my whole life has been about computers, one way or another. It was, it's been a fascinating little journey. So I remember the first program I wrote, though. It's fun.
(Joel Beasley at 00:05:27) What was it?
(Hrishi at 00:05:28) Yeah, it was the Celsius to Fahrenheit thing. It's like, you know, it was a little thing where it would take a little input from standard in, take in a number, did error checking to see if it was a numerical value. It was pretty—I was pretty impressed with myself at 14 years old. You know? And then it would do a reverse conversion. Like, do you want to go back from Fahrenheit to Celsius? And you would do that. And then the second one was building a pattern using for loops. And I wish I still had access to that source code from back then. You know, it was so much fun.
(Joel Beasley at 00:05:58) Right? We didn't have GitHub back then.
(Hrishi at 00:06:01) No, no. I don't even think we had CVS or PVCS back then, you know.
(Joel Beasley at 00:06:07) So what was your first major job solving problems? Like, you talked a little bit about it. You were solving some algorithms, but can you give me more context?
(Hrishi at 00:06:17) Sure. So in a non-commercial capacity, my first big software endeavor was actually my master's thesis at Cornell, where the underlying domain was something called MEMS, microelectromechanical systems. Essentially, these are chip dimension, nano dimension devices that, unlike chips which are static in nature, they move. Like, you could vibrate a little silicon beam with voltage and with capacitance and stuff like that. So essentially, the fabrication technology was largely similar to what is used today to manufacture chips, but you had all these movable parts in there. So the failure rate was really high. And what we were trying to do at Cornell was actually a joint research project between professors at Cornell and students and Xerox, which was, as you know, one of the big pioneering institutions in the world, both in computer science and hardware technology, right? So with PARC and stuff like that. So I was actually working on a jointly funded—or Xerox-funded—project to build kind of a semi-automated environment to simulate the manufacture of these devices. The whole goal was to reduce the failure, increase the yield of these products, because, you know, we had a failure rate of 95% in the nanofabrication lab at Cornell. Like, you know, basically if you manufacture a hundred devices, 95 would fail. So we wanted to reduce that. And the way to do that was to simulate the conditions of fabrication through computer, through actual geometric modeling. So I built this massive 3D modeling, solid modeling application that took in requirements for the device that you wanted. You wanted it to vibrate at this frequency or deflect light at that angle. It would take in all of these parameters and would build up an optimized design for the device, and it would simulate the fabrication of it through the five to nine step process that would actually realize the device. And you would see, like, okay, if you build it like this, you have a—you know, which would kind of spit out a failure confidence level in terms of, like, hey, if you follow these parameters, this is what the device would look like. So it was a big solid modeling program written largely in C and actually a bit of it in Java because we threw a web interface on top of it. This is 1995, so it was JDK 0.92. It had just been released by Sun. Applets were all the rage at the time. So I built this big solid modeling program to simulate the fabrication of these devices, and I built a Java applet-based interface to actually trigger it. It was so much fun. You know? That was kind of my first large-scale programming effort, if you will, which, among other things, got me my master's degree. So that helped. And then from a commercial standpoint, my first job out of grad school was actually with an engineering company, Schlumberger. It's a big oilfield services company that made hardware and software tools for the Shells and the Chevrons of the world to basically find out where the oil is. So I worked there, again, largely building what they called interpretation engineering software. So these tools would spit out terabytes and petabytes of data from underneath the earth. And we would build programs to essentially do all kinds of geophysical modeling to tell the clients, is there any—what is the probability of finding oil? It's basically the core of it. So also a lot of pretty hardcore C and C++ and a bit of CORBA programming back then as well.
(Joel Beasley at 00:10:05) Did you get feedback from them? Like, if you had a high confidence rating of oil being here, did you ever hear them come back to you and give you insight?
(Hrishi at 00:10:16) Well, indirectly, yeah, they would. Because the way it worked was they would just hire the company, Schlumberger, to go out onto the oil fields with them with these giant trucks. And there was this massive data acquisition software called MAXIS that would actually—it was a meta software that was in the tool. So this was essentially firmware-level software, which would gather all of the subsurface data and send it back up to the truck, which is where then our software would take over and start crunching that data and give it all the—what they call them logs, these giant graphs essentially of, you know, what's underneath the surface. And then they would—and, yeah, of course, I mean, the technology was so advanced that, yeah, we managed to get quite a few home runs with some big oil companies in terms of finding oil. It was actually one of the most fascinating—now web development and Internet-based software is so—it's kind of like the most common kind of software that's built. And back then, it was so new. We felt—I felt like I was just doing some old, same more of the old engineering software. I wanted to do all the new stuff, the new cool stuff. I want to do Java. I want to do servlets and stuff. But now looking back, that's probably some of the most interesting software I've written. You know? It was like all the stuff you learn in theory that you learn in computer science, actually you get to deploy. I mean, these days, how many times do you actually write a sorting algorithm as part of building a web app, right? But back then, you would actually need to care about the computational complexities that, you know, your Big O notation actually played into day-to-day work, not just at an academic level. So it's kind of an interesting time, actually, back then to—looking back 20 years.
(Joel Beasley at 00:12:06) Did that prepare you well for this current project you're in at Yieldstreet with financial data?
(Hrishi at 00:12:14) Not really. It did in a way, because the underlying algorithms, like Monte Carlo simulations or any number of numerical methods that we use for modeling, they're—there is a substrate of mathematics that is common to a lot of domains. So to that extent, certainly. I think the difference is really in the volume of the data. And at the end of—so from a similarity standpoint, they're both kind of probabilistic slash stochastic analysis of, you know, what can happen or what may happen. Is there oil? What's the efficient frontier? That kind of stuff. But a lot of the stuff we write, the code we write now at Yieldstreet or elsewhere. I mean, obviously there is a lot of data science type of work we do here to model our portfolios and do underwriting and stuff like that. But a lot of the other end user-facing software is just—it's a basic web app, right? You know, there's not a lot of algorithmic stuff going on. And what there is, it's handled by your framework. So you're really doubling down on building the most engaging, attractive user interface and experience rather than actually going deeper into—so the complexity now is more on a scale and traffic standpoint rather than algorithmic. So it's a little bit of—they're both difficult and not easy problems to solve, but just slightly different areas of complexity.
(Joel Beasley at 00:13:44) Why did you decide to get involved with the Yieldstreet project?
(Hrishi at 00:13:47) So I've been doing fintech for a long time. So starting early 2000—2003 is when I started doing some serious work in fintech at a startup back in San Francisco where I lived at the time. And I just got fascinated by it because it's math. I'm not a very good mathematician, but, you know, I love dealing with numbers. Like, you know, dealing with algorithms, dealing with just, you know, solving complex problems. And there is nothing simple about fintech, at least from a modeling standpoint. So, and I just got very interested in the domain. It was a new domain for me because, again, like I said, I come from mechanical engineering, and I don't come from that world. But that first experience with a company called FinaPlex—it's actually Mike Cagney's. Mike Cagney is a pretty big name in fintech, you know, founder of SoFi and stuff. It kind of just hooked me in, like, in terms of, there's a lot of interesting problems to solve in this space. So I think I got into fintech that way. And then over the years since then, I've been working in some capacity on fintech projects. First as one of the principals of Guardian Labs, we do a lot of fintech projects, me and my cofounders and fellow partners in crime, if you will. And then the last 10 years, it's been basically just, you know, I moved to New York about 15 years ago, and this is kind of like ground zero for fintech, right? For obvious reasons. I mean, the industry is right here. So first at LearnVest and then now at Yieldstreet, it's just—it just kept going deeper and deeper and more and more interesting. And you would—it's funny that there are so many fintech startups out there. You would think that the space is saturated, but there's so much of a domain out there. Like, the footprint of the domain itself is so massive. There is always some unsolved problem, some area that is still a little obscure corner of the financial services world that can benefit from broader access, from broader democratization. So that's kind of like, from a—was the big attraction for me. Because in general, you get attracted to ideas, to products, to companies that are solving a problem that you personally are facing at some level, right? You know, LearnVest started the same way. Lack of access to financial planning for everyday people was why Alexa, the founder, started the company. Milind started Yieldstreet for exactly the same thing. We're coming off of 2008, all of us, and like, you're seeing our market portfolios take a massive 50% hit. And like, what are the choices? Right? What is available to everyday retail investors outside of the markets?
(Rishi at 00:16:39)
And you have the same basket of ETFs and mutual funds. So there's this whole world out there that's been untapped because it's been largely covered by big check writers, private equity, hedge funds, family offices, that sort of stuff. But there's a need to be that way. We can actually deploy technology to improve, to broaden the access to these income-generating products, which I could have used in 2008 and 2009. You could have, all of us could have used, but simply didn't exist.
(Rishi at 00:17:10)
So when you're trying to solve a problem like that, it's just a natural draw. So this kind of hits that triple whammy. It's a very interesting, useful problem to solve. The technology is fascinating. And at the end of the day, it's a solid business model. Right? You know, it's an AUM business. So it kind of hit that trifecta of things that I was looking for after LearnVest, when I was trying to look at what my next adventure was gonna be, and it just hit it. And I was kind of lucky to get introduced to the founders through a common friend and, well, here we are.
(Joel Beasley at 00:17:44)
Yeah. Because you founded LearnVest, right? You were one of the co-founders there?
(Rishi at 00:17:48)
I was not technically a co-founder, but I was brought there from the very beginning. So the MVP of LearnVest, if you will, we built out of Gordian Labs, which was kind of this boutique software firm that me and a couple of friends founded. So we did a lot of these what we call bench equity projects, where someone came to us with an idea but hadn't raised any money, but just wanted to get off the ground and launch with some minimal MVP. So we did the MVP for LearnVest.
(Rishi at 00:18:21)
And then at the end of that, I kind of just came on board full-time. So I was there from more or less the beginning, but I wish I'd been a founder. That would have been pretty sweet.
(Joel Beasley at 00:18:32)
So what big problems are you excited, or I guess either what big problems are you solving? Because I know you like big problems, so you must be doing something interesting at Yieldstreet, but often people can't talk about those.
(Rishi at 00:18:45)
Yeah. So I mean, obviously, without going into specifics, which I can't a lot, I think if you when you're building a consumer startup, which is what Yieldstreet is at the end of the day, which is what LearnVest was, the domain problems aside, and yeah, they have their own complexity and challenges to address, the kind of problems you're trying to solve, they have a lot of portability. They're very, they have a lot of commonality. You know, you're trying to figure out how to build a platform that can scale well if you're widely successful. How can you, and scale by scale? I don't just mean like traffic scale, although that's a big part. But also like, how do you build something where it becomes widely successful and popular that you need to scale your own internal team like 100x just to support that incoming mix?
So what we do is, we, at the end of the day, we're an investment platform. So we have people in-house who manage all of these investments for our investors. So certainly, we don't, if we go from x to 100x investors, we don't want to go from x to even 10x in terms of our team, which means it's a lot of operational scale that we need to build software for to automate, right? So there's that as well.
(Rishi at 00:20:06)
So and then there is the team scale itself. Again, that's one of the things that kind of, well, it was one of my learnings from LearnVest days, which kind of carried over into Yieldstreet, is when you're in the technology group at any startup, on day zero, day one, you're really focused on one constituency, right? Your user. Like, you know, how can you build the best possible product for a user? Now the importance of that constituency never dims. It stays as important as ever. In fact, even over time, if you pick up traction, it gets bigger and bigger.
(Rishi at 00:20:43)
But then as your own company grows, there's a lot of internal constituencies that become part of your stakeholder space. You know, it was just, let's say, me and one other engineer building the MVP, which is more or less what it was at Yieldstreet, and then we had the two founders. And that's like five people, right, you know, back in 2015. But now we have a marketing team. We have an investments team. We have an investor relations team, which is our customer support team. They all need to do their jobs effectively to make the company run smoothly, and they need technology to do that.
Now some of that, a lot of it in fact, can be bought. Like, you know, right, you need CRM. You can go with Salesforce. You need marketing automation. There's any number of platforms out there. But all of these involve work that falls onto the technology group. So you're, and then something stops working, the connection between Salesforce and Marketo or our platform and some analytics platform that we're using, it needs to work all the time. And if it doesn't, it falls upon the engineering team.
So the idea that your stakeholder space grows as the company grows is something that, you know, a lot of times is not planned for. And a lot of my learnings are from things that I wish I'd done in the early days, which is the best kind of learnings. So I wish I had collected all this data so that we would have these insights. I wish I had started data collection from day zero. I wish I had built in logging and telemetry into the core platform right from day zero, and we would have so much richer insights today than we do right now.
So we kinda went, I went through all of this process in previous experiences, and I was able to bring them into Yieldstreet. So some of those things are easier than they could have been, or less tricky than they could have been, had we not kind of taken some of these steps in the early days.
(Rishi at 00:22:53)
And then, it's really how do we, you know, we've been incredibly successful in attracting investors, especially in this kind of zero interest or low interest environment. People are looking for opportunities to earn yield, right? So we are always looking for new products to build. And by new product, you know, it's not just a new deal on the platform, but a new structure, because we want to continue expanding our audience. Even today, most of the Yieldstreet products are for what's called accredited investors, an SEC designation which requires a certain income slash net worth levels for investors. On securities, SEC has these restrictions. And obviously we stay within those for those kinds of products, but we want to expand our product base so that we can actually cover even a broader audience. And there are other legal structures and types of products that we can build for those.
Now each of those also comes with its own complexities on the tech side. So we spend a lot of time designing that, building that. And now the tricky part, and this is kind of like a slightly long-winded answer to your initial question of what big challenges is: How do we build an architecture that is abstracted enough to be able to support slight variations of underlying products without having to go back to the drawing board and introduce, and, you know, okay, well, we need to genericize this because otherwise we can't support that?
So a lot of the architectural complexity today, certainly at Yieldstreet, but I'm sure we're not the only ones, is about how do we design for a future? How do we architect for a future that is not clear yet? Because we don't know what direction we want to take the product in. We have a very good general idea, but the devil is in the details, right? Computers are very unforgiving. You gotta tell them exactly what to do.
(Rishi at 00:24:40)
So how do we design our data model? How do we design our microservices so that today they can support all of these debt-based deals? But tomorrow, if we get a really promising deal for our investors which involves a bit of debt and a bit of equity, can we just add equity support to our engine, or do we have to go back and build an equity engine? Like, you know, those kinds of problems, which we often don't have. And this is just one example. Like, different industries and spaces have their own version of these. Like, having to suddenly be hampered in going in a new direction because your tech doesn't support it right off the bat, or at least requires a lot of rework to support it. We never want technology to be the limiting factor to grow the business, quite the opposite. And that takes a lot of architectural design and complexity.
(Joel Beasley at 00:25:36)
So how do you stay on top of this? Because the organization's like this organism, and revenue is driving what you're able to invest in and things like that. So when you're making these design decisions or you're trying to wrap your mind around these things and working with your team, does that involve you being really close with the executive team and understanding the direction there?
(Rishi at 00:26:01)
Yeah. Actually, it's a bit of a lot of different things, and that's certainly one of them. Executive team, but also kind of like the line managers, if you will. Like, you know, we have on the, what we call the supply side, the investment side, we have experts in various asset classes that we have offerings in, like art finance or real estate. So kind of knowing what's out there, what direction they're thinking of going in, and kind of looking at the software that we built and seeing, like, okay, well, is there any commonality in there? Is there some common substrate?
Like, today, the Yieldstreet platform is completely agnostic to the asset class. Like, you know, the same engine that powers completely unrelated kind of asset classes, like art finance and commercial real estate. So there is that abstraction that's already built in. But in terms of how do we continue that, we have to kind of, this is where some of these very key bridge roles come in very handy, where people who are product people who have a very strong domain knowledge, who've been in financials or who've been in structured finance, who can actually, you know, because as you know, like, engineers are, first of all, let's say we are a weird bunch. You know, we have our own language. You know, I mean, we're going to, like, like that. But, you know, but in a sense, every specialized field has its own lingo, has its own vocabulary, right? And a lot can get lost in translation.
So I think aside from having the strategic vision coming from the executives, we also need, like, and we have some truly amazing people in that role who can bridge that gap, who speak product and tech, who can speak to an engineer, and who can also speak to a structured finance expert about what a mezzanine financing model looks like, and be able to make those connections and take it back to the engineering team, the technical architects, and tell them, like, this is what we're talking about. So if we make this configurable and we make that configurable, we can actually support both.
Like, so there is that translation layer which is very critical in companies like Yieldstreet, which are software slash technology on a very, very specific and complex domain. I wouldn't presume to say it's easier for abstractions-wise for ecommerce sites or whatever, but, you know, who knows? They, I'm sure they have their own complexities. But finance is a particularly interesting beast because it can get pretty intricate.
(Rishi at 00:28:21)
And at some level, it's just not possible to design for other things. So we have to do things like, okay, well, this covers 90%. There's this 10% long tail. We'll just have an escape hatch for it. You know, there's no configuration, set of configuration parameters that can satisfy this. So we'll give you a CSV upload thing. Just upload what the thing is, and we'll handle it. We'll just ignore the engine. So you always need to make those kinds of trade-offs because otherwise you'll be constantly building and never shipping, you know, which is the last place you want to be.
(Joel Beasley at 00:29:10)
Yeah. No, I personally have several years of experience in the financial data as an engineer. And as you're talking about all of this, I'm just like, yep, because I've done projects all over the place, right? A couple years here in real estate and contracts and financing and like CRM-type stuff, and then straight-up financial management and asset allocation and predicting withdrawal strategies, which is the most efficient withdrawal strategy given the 10 set of products. And then there could be 50 potential products, and then you add theirs, and then you enter in the variables for them, and they're all, and wrapping your mind around all of that, I found it, it was a little addicting because every time something came up, it was so intricate.
Because the way the financial world works, they just make a product. It's like they're sitting around, they're risk modeling, they just make it up and they're like, here's the 20 variables that help define this product, and here's the outcome of it, and here's the lifetime contract value, and like the payout, and like, here's all the, here's all the little, the early withdrawal fees or, you know, maturity dates. And there's just so many things.
It's, honestly, I went into it, built this incredible software for three years, and then my partner bought me out. And I can't tell you like a whole lot of details because there's so many different financial products you can buy, and they all operate in such a different way. And you want to use them for different things. And as you compose them for your portfolio, you'll, it's just, it's almost like making music. It's kind of beautiful.
(Rishi at 00:30:50)
Yeah, exactly. And that's like, don't you think the technical or architectural brainstorming that goes into distilling that to, okay, well, there's too much stuff here. If you keep whittling it down and simplifying it, what is the atomic piece that you bring it down to? So if you design for that, if you find the atomic LEGO block, in a way, or set of LEGO blocks, then you can then just combine in different ways. That's the dream, right? That's not always possible, but that's kind of like some of the most fascinating architectural discussions we have at Yieldstreet, where it's like, okay, well, we have like these four things that are kind of sort of similar. At the end of the day, we are generating yield for investors, so at least that's in common. But how, what do we distill it down to in a way that not only will it solve these four use cases, but the next six use cases that'll come along that are slight variations of these?
So I mean, and I think this is where past experiences come in very handy to teach you. Like, okay, well, don't do that. You know, remember what happened back then? Like, so the second go around is always, for me, I mean, you probably feel the same, but, you know, the second time, second go around when you see things, and you get the sense of déjà vu and you remember the pain that you felt because you didn't just fire that one event which would have helped you down the line. You know, it's like, it's such a cool feeling. I love it.
(Joel Beasley at 00:32:21)
The beautiful thing about getting older is understanding the value of experience and just genuinely appreciating it. It's something that's like impossible to do at a younger age, and you can't even really, it's like having kids. You don't know until you actually do it. But when you start to experience that, you're like, oh, we just saved six months by not going down that rabbit hole.
(Rishi at 00:32:44)
I know exactly what you're talking about. This is, um, yeah.
(Joel Beasley at 00:32:47)
So I have a theory. So I think in the financial space, I think it's the, you have so many opportunities to have moments, you know. It's those realizations from all the uniquenesses of trying to wrap your mind around specific products. And then you, because as you were speaking, what was running through my mind was the three years I spent where, like, all day I would be in a financial advisor's office, right?
(Joel Beasley at 00:33:14) And just learning about the products and watching them sell to customers and all of these things, and then going back at night and writing code. And then you did that for a year or two, and then built a team, and then finally grew it out.
(Rishi at 00:33:27) Yeah.
(Joel Beasley at 00:33:27) But yeah, those moments of just sitting there in frustration on the whiteboard for the tenth time having this guy explain to me how this product works. Yeah, that's — and then getting it though. The reward, that dopamine — I think it's dopamine — that dopamine hit you get when all the dots connect and your whole brain lights up like some LED Rubik's Cube. You know?
(Rishi at 00:33:51) Yeah. You just run this out of them. You see that line of numbers, and there's this Excel spreadsheet with the numbers that it's supposed to be getting, and they match up to two decimals. It's like, yes. Yes. I did it. We got it. Nailed it. We nailed it.
(Joel Beasley at 00:34:03) Yeah. Try writing a program without testing in financial services.
(Rishi at 00:34:10) Right? That's a scary thought.
(Joel Beasley at 00:34:13) What's the long-term mission? Is it making these investments more accessible to broader market?
(Rishi at 00:34:20) That has always been — and this is one of the things that I love about Yieldstreet. And having been at startups for a long time, it's actually surprisingly not as common — a truly well-defined and well-solidified True North right from day zero. I have the pitch deck from 2014 that Milind, our founder and CEO, showed me. It was this bar in the Lower East Side where he said, "Okay, well, we didn't even have a name then." It was just the new co deck, which I'm sure you're seeing thousands of. And there was this vision slide in there which laid out a five- to six-year roadmap for what eventually became Yieldstreet in terms of what are the products that we will build, and ultimately, what is our mission? And that mission, exactly to your point, has never changed. It's to democratize access to these kinds of funds, to build an avenue for everyday retail investors to diversify their investments and ultimately achieve their financial goals. So when you have more choice, when you have more options, when you don't feel pigeonholed — that's one thing. But it's this very specific gap where you have to choose between volatility or low yield. And that's just a very bad choice because you're really kind of playing this. And then you come up with these heuristic models of, "Okay, how much should be in cash and how much should be..." But there is this entire third option, which is still fixed income with a higher yield. There's no risk-free investments, of course — short of a CD or an FDIC-insured account. There's risk everywhere. But how do you diversify that risk? How do you balance out the volatility of the public markets and the low yield of the cash accounts with a third option which kind of combines the best of two, but with its own set of risk, of course. This is such an important thing for people to have access to, and that was the mission from day zero — to, over time, increasingly democratize this access and provide it to an ever — and not just democratize in terms of the number of people or investors. Certainly, that's a big part. Like, really, at what point in your financial life do you start getting access to these kinds of products? Historically, even today, you have to — you're in your fifties or sixties, and most of your debt's being paid down. And you have some fairly stable assets, like a home or whatever. And then you have some investable capital that you can now start deploying into these kinds of things because of the higher check sizes needed. We wanted to bring that down. You know, it's like people are — especially millennials. I'm sure you've seen any number of infographics that shows just the level of debt that millennials are inheriting or coming into the working world under. So just making sure, doing everything we can to make this access available to a broader audience at a lower age, at a younger age, so that they can start generating income much sooner than they — and passive income much sooner than they historically had been able to. So that mission has not changed. We kind of take a few turns in terms of whether this product is right or that product is right or this structure is right. But ultimately, that's the long play. Eventually, the vision is to provide not only the optionality, the channels to investment, but also a layer of services on top of it that says, "Okay, we'll help you figure out." So we have a product called the Yieldstreet Wallet, which is basically a bank account. Right? So today, largely, it's used to fund your investments in Yieldstreet, but it's a straight-up bank account. You can use it to pay bills. You can use it for direct deposit. You can use it for any number of things. And ultimately, if you can take the platform that we build and expand it out in a way that reduces financial friction in people's lives, that would be a huge win for us. And all of the bits and pieces are in place. This is one of the interesting things about fintech. Certainly, a lot of these building blocks have become commoditized now. The Betterments and Wealthfronts were amazing trailblazing companies. But now, what they provide is available through an API play. You know? So anyone can build a Betterment-like product on top of these APIs. Anyone can build a banking product on top of this API without needing to be a bank, and you see them all around — Robinhood, Chime, and Stash and all of these truly great companies. So the building blocks are being commoditized. So there is a big opportunity to ultimately simplify people's lives, financial lives, by giving them not only the access to all the different things that they could benefit from, but also giving them guidance on what is the best way to do it. So essentially bringing together the world of planning with the world of investing, with the world of — and we're certainly not the only people trying to do it, but I think we are very interestingly positioned because of the diversity of the products that we have the ability to provide today just on a single platform. Consolidation will always be a big friction reducer. Right? So if I don't have to go to five different places to do five things and can do at least four, if not all five of them on a single platform as a consumer, that's an attractive proposition for me.
(Joel Beasley at 00:40:11) Do you see yourself at all — you mentioned the infrastructure players, right, of building the bank account infrastructures and those types of things so you can use their services to build on top of. At the same time, it seems like what Yieldstreet's doing is making the higher-end investments, the accredited investor investments, more accessible at a younger age. So do you see yourself as laying the infrastructure for that type style of investment, and in the future, people will build on top of Yieldstreet?
(Rishi at 00:40:39) Strategically, I can't say what we plan to do, because, honestly, on this particular angle, even I don't know. It's well — it's one of the things. But I can tell you this: that from a pure technology and infrastructure standpoint, we are already set up to do it. You know? And it was always something that — another thing that was a learning from Learnvest is building in things like multi-tenancy and things like that right from the get-go. So we have the ability to do it. Whether we will — it's certainly something that we've considered, and we'll just see.
(Joel Beasley at 00:41:14) No, I like what you —
(Rishi at 00:41:15) We have legal — we have legal team on the call. Yeah. When you think about it, right, the way modern systems are built with the front end and the back end and the infrastructure, in effect, every company, every software platform is an API platform. It's just that the APIs are not public. You know? They're just used by themselves. But we're all API plays at some level. Right? You know? So that's what I meant. I know it's not a — whether that's a monetizable product, you know, who knows? I'm sure at at some level of adoption, it would be, you know. Betterment had been around for eight years, I think, before some company like DriveWealth came along, or maybe a little less, but, you know, which is basically — they might as well just have taken Betterment's APIs and made them just an API play. Essentially, what it is. It's very valuable. So it makes you wonder, actually.
(Joel Beasley at 00:42:13) Yeah. Go ahead.
(Rishi at 00:42:15) No. I was just saying, that makes you wonder about all of these disruptive companies, because a lot of the fintech disruption is quickly taking an old existing archaic space and bringing it into the digital age — insurance. You know? All of these are potential — mortgages and it's like Better, Lemonade, all of these. They're all API players. You know? They could be.
(Joel Beasley at 00:42:37) I love it because it's almost like they're using the technology as the excuse to give the people what they want. Right? You could normally not do mortgages this way if you were to just open up a building and say we're gonna do a mortgage company, we're gonna do it this way. But if you — yeah — think, like, Rocket Mortgage did something unique where, you know, you get to raise a bunch of money and get a bunch of people involved with this new future, and you realize how much you can do and how many resources are available and how much energy there is. And as you get more experience, you can understand how to put these parts together. Very Elon Musk-ish. Right? Where he's like, "Alright. What's the cost of this raw material? Let's overcome this hurdle of expensive batteries." You know?
(Rishi at 00:43:17) Exactly. It's a nice — it's a very — never thought of that that way, but you're absolutely right. That's a very good parallel.
(Joel Beasley at 00:43:26) So are you doing any angel investing right now?
(Rishi at 00:43:30) Little bit. Yeah. I don't have a — I wish I had more angel investable capital, but no. I do. There are two areas that are very close to my heart. One, obviously, it's fintech because I just know it. So I'm in a reasonably good position to evaluate the merits or lack thereof of a potential company. But I really care very deeply about health tech, digital health as well. In fact, for about a year between my Learnvest time and my Yieldstreet time, I actually teamed up with an old Learnvest friend of mine to start this digital health startup. Kind of on the shelf right now. I hope to get back to that someday, but it's a Mint or Personal Capital, but for your personal health insurance rather than your financial accounts. So same idea, you know, aggregate claims data and coverage data and actually provide a unified — it's like a fun thing to build. And we spent about a year working on it, but that's an area that I think is absolutely screaming for — I hate using the word disruption just because it's too heavily used, but just simplification. Like, you know, de-obfuscating it for everyday people. Health insurance in particular, but health in general. Health insurance is accessible because it's the intersection of health tech and fintech. But in these two areas, I'm very interested in doing small amounts of angel investments. I've done a few. Hopefully, I'll have a little bit more capital to do some more. But no, I do. I do a lot more advisory stuff than direct investing, and some are a bit of both. But yeah. And then a little bit just personal hobby-type investing. Like, I just invested in an indie motion picture. You know? I just — I always wanted to be on a set. So I think there's one way to do it. So I do a little bit.
(Joel Beasley at 00:45:41) Problem solved.
(Rishi at 00:45:41) Yeah.
(Joel Beasley at 00:45:42) Yeah. You wanna be on a set? Let's go invest in a movie. I wanna talk to great people. Let's start a podcast. You know?
(Rishi at 00:45:50) Hey. See, it works.
(Joel Beasley at 00:45:51) So what are you learning right now as as a leader? Because you lead the engineering team there, and you're always dealing with people, and you're growing.
(Rishi at 00:46:00) You know, of all the experiences that I learned from from the Learnvest days that I brought over into Yieldstreet, hopefully, largely in a positive, helpful way — one personal experience that I more or less forgot to bring over was the ability to — well, let's say I did bring it over, but not in enough measure — is the ability to step out of the weeds. Because one of the things about how a CTO role evolves over the life of a startup — if you're a founding CTO, your job on day zero or day one and the job post-Series B or whatever when you're scaled to a certain point is phenomenally different. And the toughest part is to let go. You know, to trust your people, to get the right people, get people that are way smarter than you. And I can safely say that we've done that at Yieldstreet. Like, you know, all of — and not just the leadership in tech. It's just every last engineer is, like, you know, I'm humbled by the quality of our team. But you're still a geek at the end of the day, and you want to look at the Kibana logs or you want to tail — run tail on some server log or just get in and look at a PR. And at this scale, I probably should stop doing that, but it's hard to extract myself away from it just to see — and for me, it's an educational experience because we went through this major rearchitecture. And I'm old school, man. Like, you know, when I was actively programming, it was the old days of CRUD and SQL databases. And you had to go through a lot of hoops to create a cluster. And, you know, if you remember the old EJB days. But now, the whole world is different. It's like — I'm almost envious of the people on my team who get to code in all these amazing things, like CQRS and event-sourced microservices. And Kafka is the source of truth. And like, man, I wish Kafka existed when I was actively programming. So I think the thing that I'm learning is how to be okay with the fact that you don't know everything. You're responsible for a whole bunch of software, a whole bunch of technology that you don't necessarily understand that well to the atomic level. Like, you know, I can look at a PR and roughly understand what's going on, but then I still try to find a little time to program here and there. But getting into that comfortable space — and this is typically true for people like us who are engineers, who become CTOs, who are just used to doing it. Right? So being responsible for something that you're not building yourself and having that trust in the team that you've put together, it's an adjustment period. And it was tough. It was a little tricky for me back in Learnvest, and it's certainly a lot easier here, in part because I brought some of my own Learnvest people over as well. But it's something I'm learning every day. And every time I get on a call with our head of infrastructure or some of our architects, I'm like, I just wanna sit there and listen to you guys because this is amazing. You know?
(Joel Beasley at 00:49:29) Hey, you wanna come in and see the team you've put together operate, you know, see your work happening.
(Rishi at 00:49:36) Yeah. And it was an interesting discovery that when you're a three or four person team, you're actively programming, you're designing, you're doing the deploys and shipping. There's no Ansible or Terraform. It's all manual in the first month. But when you're in a meeting, and this is also the thing that I had to—I'm still getting used to—is when you say something, and I was told this by some of the leaders on my team.
(Rishi at 00:50:05) It's like, okay, well, I know you were just voicing an opinion and a totally justified opinion. But when you say it, it comes across as, okay, stop doing what you're doing and do it this way. When I'm just wondering, hey, can it be done this way? So this kind of implicit megaphone that you get, which is simply not something that you're used to as a founding CTO because you're all huddled in a garage or this one coworking space, and you're just cranking out code with everyone else. And it's a completely level playing field. And at a certain scale, it stops being that. And you have to kind of tell yourself, like, okay, get out of the weeds. Get out of the weeds. You know? And be careful where you weigh in. And it's just a weird place to be for me anyway. You know? It's like because I always wanted to be in the weeds, hanging with the engineers and knowing what they're doing and contributing an idea or two. And I still do that, but it doesn't come across as just an opinion or an idea. It's a lot more than that. That's kind of one of my biggest adjustment areas, if you will.
(Joel Beasley at 00:51:11) Yeah. It's about what you want and where you're best suited in the company. So everyone always asks you, what's the responsibilities of a CTO? I'm like, oh, man. Here we go. So but, like, as you said, it changes drastically based on the business model, the stage of the business, all of these different things. But one of the interesting patterns I see is that the people who do like to be really hands on usually situate themselves in this office of the CTO model where they'll hire a great head of engineering to sort of perform the day to day of running the engineering org. And then they'll sit in this corner with eight people either solving problems for the engineering org from an outside perspective or doing moonshots, like new projects and testing new things out. So they'll still get to be in that small room with those few people, you know, in the weeds, but at the same time, they've made sure to cover for the responsibilities that they need for that VPE or whatever role you want to call it. But it doesn't matter what the label is. It's that there's the human performing that function of leading that side of the org, and then they have this little subset called office of the CTO. And I've found that really fascinating too.
(Rishi at 00:52:28) That is a great idea.
(Joel Beasley at 00:52:29) Yeah.
(Rishi at 00:52:30) Hey. Thanks. That's going to be on my 2021 strategic roadmap for—let me see. I'll run it by our CEO, see what he thinks. I love that. Like, we had some notion of it, but we always kind of struggle with this thing. Okay. Well, it was less of special projects, so it would be great to do that. But it was more kind of cross cutting. So we have a bunch of pods, scrum teams, basically. A bunch of different teams working on various parts of the platform. But there's always this foundational layer of things that needs to be built that is cross cutting. Right? You know, whether it's a caching infrastructure or a standard way to talk to Kafka, like, you know, any number of—document management. We always kind of struggled with what I used to call the two yard problem. We build all of this stuff with exactly the kind of team that you're talking about, like, you know, the SWAT team of two or three super senior people. And we would build all of that, and then we would bring it all the way to the 98 yard line. And then just kind of taking it from there to actually shipping it involved this knowledge transfer process, which we kind of always struggle with. So I think a straight up special projects kind of team would be actually a very interesting evolutionary step for the engineering org. Again, frankly, obviously us and any company would massively benefit from that. Because you need to. Right? I mean, the space was new when we started, but now it's getting quite crowded. Like, there's a lot of alternative investments platforms out there and, you know, and it's good. Like, you know, choice is always good for consumers, but we got to stay ahead of the curve, and those kinds of projects or teams are valuable for that.
(Joel Beasley at 00:54:06) Yeah. It's how you can step out of the day to day of the value you're bringing the market and look a little bit ahead. Because, like, right now, I bet, like, you know, we're looking ahead on nights and weekends when we have a spare moment or something and can do some research. But if it becomes—you know? And I think another important thing is, and I'm always reminded this by the VC firm that works with me, is they're always really focused on, like, am I doing the thing that lights me up? Obviously, disciplines apply, but I'm an overly disciplined person. So we're always trying to pull me into, like, the don't kill yourself. Like, relax a little bit or make sure you enjoy what you're doing. So pulling me back from that and making sure that I have a recurring event in my calendar that triggers every three months that's just like—it asks me three or four different questions about, like, you know, what's your energy level with your weeks and how you're doing? Are you excited about what you're working on? Is there an item on your plate that's taking up, you know, more than 30% of your time that you can delegate out, and just constantly reevaluating. It changes in every season. Right? But when you're excited, when you're pumped up, when you've got that energy and that spark in the morning, that's how you serve the company best.
(Rishi at 00:55:23) Yeah. And it's contagious too. Yeah. You know, it just kind of spreads out from there. But, no, I mean, it's a very interesting question. Like, you know, how do you—what's your job as the CTO? And I think, like, at this stage of the company, I would basically say that it's—it really is to get out of the way. Provide air coverage to the team and get out of the way. You're serving the team and the tech org best by just leaving them and just making sure they have the environment to do their best work and only running interference when they ask. So it's kind of like an interrupt based model where you're not just actively involving yourself on a day to day basis, but you're really coming in when someone needs some kind of conflict resolution, whether it's architecture or people or whatnot. But the rest of the time, just checking in to make sure everything is alright and making sure that should something happen, we got their back. So just feel free to be—you know, mistakes are always welcome as long as you learn from them. In fact, I encourage—like, I get suspicious when I interview people and they say I've never had a production crash. I was like, well, sorry, man. You're probably not the right fit, man, because that's the best kind of teacher you'll ever have. So but, really, it's providing the air cover and getting out of the way, and that is an adjustment, like I said. So but I'm actually coming around to it. It's fun. Yeah. It's fun to see the team that you built doing well.
(Joel Beasley at 00:56:46) For sure. I was so surprised if I look back on my past because I was so obsessed with engineering and best practices and learning and reading all the Martin Fowlers and all, like, every—you know, getting so interested in, oh, what's the new book? What's the new way of thinking and structuring and organizing? And then I started to, you know, grow teams and manage people. And what I realized is I can take those foundational concepts of organizing code and systems and processes and help apply that with a human element. And now we can orchestrate people together and then you feel like a gardener and then you realize what you can and can't do. You're like, alright. All I can really do is create a nice environment where great things can grow, but I can't necessarily always dictate—
(Rishi at 00:57:32) Over watering a plant, basically. Right? You know?
(Joel Beasley at 00:57:36) Right. That's micromanaging, over watering the plant.
(Rishi at 00:57:38) We're going to write a gardening management and gardening book together. It's so—it's crazy that there's so many parallels. Like, you know, you can describe programming or technology in terms of so many different things. Like, we just picked gardening. Like, wow. Like, there is a metaphor for programming and literally everything out there. It's amazing. Art of War, another great place.
(Joel Beasley at 00:58:03) Yeah. It's, like, everything's a system, and this is systems engineering. So it's the ultimate analogy.
(Rishi at 00:58:09) Yep. It's fun, though.
(Joel Beasley at 00:58:12) Oh, man. This is great. We made a podcast. How do you feel?
(Rishi at 00:58:15) I loved it. This is so—we should do it again. I had so much fun. Yeah.
(Joel Beasley at 00:58:19) Was there anything we didn't get out for Yieldstreet? Like, any call to action? You go to Yieldstreet and sign up? Or—
(Rishi at 00:58:26) Uh, no. I mean, I think the one thing that I would be useful to call out is we write about our experiences in the product and tech org. We have our tech blog, distributed.yieldstreet.com. So you should check it out too. It's new. So we don't have a ton of content on there, but we do try to keep a certain cadence of publishing on that, you know, and it's across our product team, our design team, our data team, and our engineering team. So—
(Joel Beasley at 00:58:53) That's pretty cool. So distributed.yieldstreet.com?
(Rishi at 00:58:58) Yeah. So it's kind of like a play on distributed—it's a distributed system. When we return money to investors, it's a distribution. So, you know, it's a little—
(Joel Beasley at 00:59:08) Boom. Geek humor. Fine. It's like financial tech geek humor.
(Rishi at 00:59:12) Yeah. I was, like, can never get away from the bad dad jokes.
(Joel Beasley at 00:59:16) I love it, though.
(Rishi at 00:59:18) Yeah. This was so much fun, Joel. Thanks for doing this.
(Joel Beasley at 00:59:21) Yeah. Thank you so much. Talk soon, buddy.
(Rishi at 00:59:23) Alright. Have a good one.
(Joel Beasley at 00:59:27) Thank you so much for listening. And if you found this episode useful, please share it with a friend or colleague who you think would get value from it. And if you have topics that you would like to hear discussed on the podcast—every time I get an email or LinkedIn message, it absolutely makes my day and inspires me to keep going.