Christine Ryu, Engineering Lead at fintech platform Flourish, joins the home team to talk about how technology is transforming finance for everyone from big banks to individual consumers. Christine explains what it’s like to move from Goldman Sachs to a tiny startup, how legacy tech stacks lead to Frankencode, and what an acquisition taught her about build vs. buy and good vs. perfect.
Flourish is a fintech platform for registered investment advisers (RIAs) that was recently acquired by MassMutual.
After studying computer science at Carnegie Mellon, Christine spent almost 12 years at Goldman Sachs, where she was VP of fixed systematic marketing making, responsible for automating electronic trades of interest-rate products like US Treasury bonds and interest rate swaps.
Christine’s time at the world’s second-largest investment bank gave her a healthy wariness of Frankencode, the scourge of legacy stacks everywhere.
Find Christine on LinkedIn.
Shoutout to Lifeboat badge winner amirali for their answer to I can't set up JDK on Visual Studio Code.
[intro music plays]
Ben Popper Intuit developers are using the power of AI, data, and open source to unlock financial opportunities for millions of consumers and small businesses. Find out how you can power prosperity around the world at intuit.com/stackoverflow. Make sure to use that link and let them know the podcast sent you.
BP Hello, everybody. Welcome back to the Stack Overflow Podcast, a place to talk all things software and technology. I am your host, Ben Popper, joined as I often am by my wonderful colleagues and collaborators, Ryan Donovan and Cassidy Williams. What's up, y'all?
Cassidy Williams Hello!
Ryan Donovan Hey.
BP So today we are going to be chatting a bit about what it's like to be an early employee at a startup, to build something kind of from scratch, and then also what it means to transition later on within that sort of same organization to trying to build stuff at a more established and old school organization. We're going to speak a bit with Christine Ryu, who is one of the first employees at Flourish. It's a wealthtech company that now operates as an independent subsidiary of MassMutual. So I'm excited for the conversation. Christine, welcome to the Stack Overflow Podcast.
Christine Ryu Hi. Thank you, everybody. Just to introduce myself, my name is Christine Ryu. I'm an Engineering Lead here at Flourish. It's a FinTech that provides innovative access to financial products that registered investment advisors, aka RIAs or wealth managers, can't easily access today for their clients.
CW How did you get into software and tech in the first place and how did you end up at Flourish?
CR Yeah, absolutely. So I've always been interested in the application of coding. I’m really excited about what code allows us to do. I wrote my first line of code in a high school programming class. I went to Carnegie Mellon University and majored in computer science, and from there I spent nearly 12 years at Goldman Sachs. I was a VP of Fixed Systematic Market Making, really automating the electronic trading of interest rate products like US Treasury bonds and interest rate swaps. And that was a really valuable experience for me because I learned how code makes money for the business and learned how to be super commercial in my thinking. So I learned to frame things like, “Well, if I automate the pricing of this product, it'll save human traders x amount of hours and y dollars a year,” so really learning to think in a very commercial way. And then from there I moved from Goldman Sachs to Flourish. I’ve been one of the first employees here and have been here for about five years.
CW That's amazing. And I feel like FinTech is something that you can deep dive and there's so many different small little corners of the internet that power so much financial movement and wealth management and trading and everything, and so it's definitely a cool space to be in and you have so many years under your belt under it. That's awesome.
CR Yeah, I mean, it's been great. I do think finance is a place where technology has a huge impact on everything from big bank finance even into more consumer finance, which is what Flourish really focuses on. It's a very different area of finance, but technology is huge in both areas.
CW Yeah.
RD I'm interested; we get a lot of folks talking about code efficiency, but when you're talking about actually the dollars and cents of it, how do you come around to thinking about your code in terms of the commercial impact?
CR Yeah, I think a lot of it comes down to prioritization. So I think as an engineer, my first instinct is to kind of make everything work as perfectly as possible and automated as much as we can. But if you think in a bit of a more commercial way, you start to think more about the impact of your code rather than trying to handle every single edge case and the most elegant solution. So maybe sometimes if you're focusing on trying to get a product live sooner, you're okay with some manual solutions. Maybe you have a runbook to make sure you can handle it, but you don't necessarily need to invest in an automated solution to go live with the product. So really thinking about what are the products you’re trying to get live, how much money can it make, and prioritizing the code that you write in that mindset.
BP If you're allowed to say, what was the tech stack like at a big financial institution like Goldman Sachs and how does that differ from what you might use at a startup where you moved after that?
CR Yeah, I mean, I will say being able to be an early employee at a startup like Flourish is a very enviable place to be. We started from day zero, we didn't have a legacy code stack and were able to choose our tools and design things in a way from modern technology from day one. I think what happens sometimes is when you're at an existing organization with code that's been around for a long time and you want to add new features, it turns a little bit into a Frankenstein piece of code that gets hard to support. You add more features, you don't fully understand what's there. One of the nice things about Flourish is we were able to start from ground zero and we were initially pre-launch when we built the product so we had a lot of comfort in refactoring. I said, “Hey, this thing is a little bit different than what we thought.” We felt very comfortable tearing it down and rebuilding it.
BP I won't ask if you had to learn COBOL or not.
CR No, no. We were not in COBOL. I think most of my code is in Java.
CW Well I think that's one of those opportunity costs that a lot of startups have to deal with where they're just like, “Do we completely rebuild this to save us a headache later, or do we ship because we have to ship faster? Do we refactor? Do we build something completely new?” It's important to be able to figure out which will be the best for you, and there's really no silver bullet or correct answer for it, but it's something that I feel like a lot of companies have to do but startups especially, because you're trying to get your names out there and launch the best thing you can.
CR Yeah, absolutely. I think one of the things we really prioritized early on was speed of delivery. So there were a lot of things that we said, “Hey, we're a very lean startup.” One of the things that we focused on was something like build versus buy for example. We said, “We don't have the team, the size of the team, or the experience working with ledger technology or payment systems, so maybe there are some things that we're just going to have to go to vetted vendors that we trust to provide some of this functionality so we can get live faster.” So obviously that gets us live faster. There's a few trade offs we made. One example I'll make is that our ledger vendor that we used couldn't represent negative balances, and we had to be able to represent that we went negative for a while so we had this workaround where we said, “Okay, we'll have one ledger for positive numbers, one ledger for negative numbers.” So if you add $100 and subtract $200, that represents -100. So obviously not the most beautiful solution, but it's something that we made work with a vendor to get life faster and that's a decision that we had to make.
BP I would've preferred just no negative numbers. If my bank did that for me that'd be great. It just can't go negative no matter what I do.
CW “Oh, no. It’s positive.”
RD Just moving it from assets to liabilities, right?
BP Hey, as long as the number stays positive when I pull up the app, it looks good to me.
RD There's a lot of folks out there starting businesses or with entrepreneurial spirits. What was the experience building something from scratch and taking it to an acquisition?
CR I mean, it was super exciting. I do think I kind of mentioned a little bit in terms of some of the build versus buy decisions that we had to make, but it was really a very different culture, I think, in terms of trying to launch quickly. So things like prioritizing a product that was good enough rather than perfect was really important. I think I mentioned before, we were comfortable making some manual decisions because we knew that our core product was going to handle most of the use cases that we need, or we had some kind of workarounds to handle other edge cases. And one of the amazing things that we had in terms of team culture is we had this concept of sort of a launch mode where we had this team where everyone was really focused on building a product, not so much that, “Hey, my code ultimately made it out to production.” There wasn't really any ego about that. It was saying, “Hey, let's get the best product out there.” So if we had to rebuild it, if we had to refactor it, we were totally comfortable with that. That was the goal– to get the product live.
RD When people start up a small company, they're very personally invested in it. This is your baby. How do you not get attached and feel a little bit personal about every code change?
CR I think a lot of that does come to our team culture and the success that we've had in hiring and some of the culture that we've had. The people that we started with was very personal. When you're in a startup, it's not just a typical nine to five. People are very invested in the product that they're building. But it was more focused on the product rather than your own code. So it was very much about, “Hey, we want to be able to deliver a product for our customer base.” Not so much, “Hey, I feel very strongly that it should work this way because this is the idea that I came up with.” So we had a group of people that had that mentality and we all kind of meshed together to work towards that product launch goal rather than having to deliver it a certain way.
BP So you mentioned working at two different organizations, and a large institution then a startup, then a startup within a large institution. What's your approach to engineering management? I know one of the things you wanted to chat a little bit about was how to retain engineers, which we all know is a super valuable thing. Is that something that you feel like you've learned over time? Something where you had great founding principles from the beginning? What are the tips and tricks you would give folks who are listening?
CR Yeah, so I'm really proud of the retention we've had at Flourish. We're something around 90% retention for our engineering team here which has really been amazing.
CW Wow, that is really good.
CR And I think that the two ways that we've really focused on that is, number one, hiring the people that fit the best. So hiring the right people, identifying them well and making sure that they're going to be a good fit. Because if they're a good fit from the start, it's much more likely they're going to stick around. And then number two, really empowering our developers by providing them ownership and independence and freedom on how they build the product, because that's much more likely that they'll want to continue to work here. I'll say one kind of unique thing that we have in our interviewing process is something we call a hackathon. Hiring a person that doesn't fit is hugely detrimental for such a small lean team so we have an intense focus on making sure that people are going to be happy here and we're happy with them. So what we do as one of the last stages of our interview process is something called a hackathon, and it's a full day hackathon with a candidate and three to four engineers on the team, and the candidate is actually coding with the people that they're working on and who are working with them. And it's sort of a full two-way interview. We get to know them, they get to know us, and it's a nice way to see if we're going to fit together and if it's pretty likely that they're going to be happy and stick around. And we've gotten really great feedback from it. Even from candidates who may not have made it past that stage, they've had really positive feedback and a really great experience from that. And then once they're in the door, the second piece is really empowering our developers. We really give them a lot of ownership and independence in how they build a product. We're not a big company that has huge tech biases. We don't tell people, “Hey, you need to use this version of Python. You have to use this language.” So one example I'll give is our first product, Flourish Cash, was built in Java, but when we started thinking about our next product, we had an engineer that said, “Hey, it's pretty verbose. What do you think about Kotlin?” So they presented to the teams, people were pretty intrigued, and we said, “Okay, let’s try it out as a proof of concept on a new product.” And developers kind of naturally ended up loving it. It was very good interoperability with Java, people love working with it, and it became more of a developer-led process to now build most of our JVM-based services in Kotlin rather than a top down sort of approach from senior management there.
RD Yeah, I've heard a lot of enthusiasm for Kotlin, so that's interesting to hear kind of a real world implementation of it.
CW It feels like a really growing ecosystem. My husband's team, their backend is all in Kotlin as well, and I thought that it was just an Android thing, and this is getting off a tangent, but it's really cool to see all of these languages and technologies building off of the JVM and thriving and doing really well on engineering teams.
CR Yeah, it's been great. I think Kotlin in particular is a really easy language to adopt because it's not quite an all or nothing switch. You kind of have the option to leave a bit of Java communication back and forth, so it's a very low-risk way to try something out there.
CW We like low risk.
BP You mentioned giving engineers independence and autonomy and a sense of ownership over things. That certainly sounds right. How do you manage that as things scale or as you interact with a really large organization like MassMutual? I know you said that it's an independent subsidiary, so maybe there's a division there sort of firewalled in a way that lets you do that?
CR Yeah, I will say, Flourish so far, even after acquisition, has really still felt and retained a lot of its startup culture. I think we have gotten a lot of benefits from being owned by MassMutual, but from an engineering and technical perspective, we've continued to have a lot of independence in terms of how we wanted to design our tech stack.
CW Being at a startup that is owned by a large company is kind of cool to have because you get the big company resources but you still get to maintain your smaller team, at least until more stuff is absorbed. How big is the Flourish team overall?
CR Flourish employees engineering team is about 30 folks.
CW Oh, that's a great size.
RD Have you had to do anything to kind of protect the culture since the acquisition?
CR I'm probably not in the best place to speak about that, mostly from my engineering team. I think most of our senior management team in Flourish has been kind of involved a lot in communicating with our MassMutual leadership. All I can really say is that they've been super supportive of the things that we're building here at Flourish.
CW Yeah. I mean, I think that statement alone is a good one because that means that you don't have to worry about it and you're shielded from above. That's always nice when you don't have to worry about the politics of those kinds of conversations.
CR Yeah, I mean, we've been able to retain a lot of the small company culture here at Flourish on our engineering team.
BP So talk to me a little bit about where you see things going in FinTech. That could be in terms of the technologies that's used or languages –it’s interesting about Kotlin– or it could be more about what folks are interested in from the user perspective. I know we went through a really intense up and down hype cycle around crypto and coins during the pandemic. What are you hoping to focus on in the year to come?
CR Yeah, so in terms of Flourish and different roadmaps, I can't talk too much in terms of specifics of what we're working on, other than that we are working on a brand new product to allow financial advisors to access yet another product that's been a bit difficult to offer to their end clients. On a smaller scale, we've continued to invest in our Flourish Cash product. Things like leader cash transfer cutoffs, recurring transfers, things like that. But in terms of the wider FinTech space, what I get really excited about is more how we can use technology to provide access to products and services or really greatly reduce the cost of these offerings to more and more people. I do think with finance in particular there's a lot of space to innovate and automate. It's highly regulated. There's a high barrier to entry. There's a lot of established players with a lot of manual, older, expensive processes. That really translates into people getting less access to the financial products they might need, or maybe they have to pay more for them than they really should be. So I get more excited about using technology to make financial products more accessible and lower cost for more of the population.
CW I feel like FinTech is one of those kind of intimidating fields in general because it can be kind of intense and sometimes you do need to have some kind of financial knowledge or background. But it varies from company to company and stuff, and if you can find a good team that can support your learning as you are using your tech stack and then going into this finance space, then you can learn so much that is really, really practical and benefits a lot of people.
RD I mean, I feel like it's also a big wide space. It goes between people transferring money on their phones with a chat app up to high frequency trading or managing billions of dollars in assets. Where do you feel like you all fit in?
CR Yeah, so at my previous roles at Goldman Sachs I have worked a lot in finance in terms of high frequency trading. And it's funny, when I came over to Flourish a lot of that was very different. We were working in different ACH payment systems about how people actually transfer money from one bank to another, and a lot of that was very different from things like high frequency trading, so I do think there's a lot of different areas where technology can contribute. One thing that's a little bit interesting about Flourish is where you see a lot of beautiful consumer banking applications and UIs and things like that. And at Flourish, we're really targeted more towards the registered investment advisor market, and their technology is a bit fragmented and traditionally hasn't really had beautiful technology to work with, or beautiful and easy to use technology. So that's one place where I think we're really providing a lot of innovation in terms of making it easy for wealth managers to be able to use beautiful technology like consumers are today.
BP Do you have to have nerves of steel to work at a place where billions of dollars are being traded on the code that you write, maybe, as Ryan said, at high frequency? I feel stressed out just thinking about that.
CR It sure does build a bit of a thick skin when you're working in that kind of environment. But a lot of the values that I've taken from that experience have been quite relevant, maybe not so much in the tech stack, but in terms of how I approach a lot of the problems here at Flourish. Because we are working in a very highly regulated industry and you're working with people's savings so it's not a ‘build fast and break things’ kind of place. This is a highly regulated, use very vetted vendors, making sure that we're able to keep track of clients' money, but still trying to move as fast as possible. So you always have that in the back of your mind.
[music plays]
BP All right, everybody. Thanks so much for listening. As always, I'm Ben Popper, and I want to shout out a member of our community who came on and helped save a little knowledge from the dustbin of history. Awarded February 10th to amirali, “I can't set up JDK on Visual Studio Code.” Well if you've been having this issue, there is an answer for you. You've helped 60,000 people and been given out a lifeboat badge, so thanks, amirali. All right, y'all. If you want to find me, I'm always @BenPopper on Twitter. You can always shoot us an email, podcast@stackoverflow.com. And if you like what you hear, leave us a rating and a review. It really helps.
RD I'm Ryan Donovan. I edit the blog here at Stack Overflow. You can find it at stackoverflow.blog. And if you want to reach out to me on Twitter, I'm @RThorDonovan.
CW And I've been Cassidy. You can find me @Cassidoo on most things, and I'm the CTO over at Contenda.
CR I'm Christine Ryu. I'm Engineering Lead at Flourish. You can find out about us at www.flourish.com or reach us at LinkedIn.
BP Sweet. All right, everyone. Thanks for listening, and we'll talk to you soon.
[outro music plays]