Phil Rabin, SoFi - Enterprise-Scale Flutter

Speaker A: Uh, hi, I'm David, and this is Build to Succeed from Very Good Ventures. Today we meet with Phil Raden, director of mobile engineering at SoFi. We discuss what it's like to lead a very large flutter team, navigate complexity and platform engineering, and how to leverage AI and automation for better developer productivity. It's a great conversation and I hope you enjoy it. So here's Phil. Phil, welcome to the podcast.

Speaker B: Hi. Thanks for having me.

Speaker A: Thank you for spending some time with us. Um, I thought maybe to get us started, I wanted to ask you a question, um, maybe about something that you do outside of work that helps you be a better leader at work.

Speaker B: Absolutely. Yeah. So I am a podcast fiend. I listen to a lot of podcasts. I pretty much always have a podcast on if I'm, you know, doing dishes or, you know, working out or riding my bike or something. I love, uh, kind of having a constant stream of information and keeping up to date what's happening in this tree. Yeah, I've got a bunch of favorite podcasts I like to listen to. I mean, I love kind of the more techy kind of business podcast like Lex Friedman Scott, uh, Galloway Diary of CEO Tim Ferriss. You know, there's something to learn. I'm all over it.

Speaker A: That's, that's awesome. Yeah. Well, you're in a good spot for that then. Um, so we'll, you'll get to listen to, uh, to us talking pretty soon.

Speaker B: Why don't you kick us off by,

Speaker A: um, telling us a little bit about your journey. I know you're at SoFi now. You've worked at Uber. Catch people up to where you started to how you got to where you are today.

Speaker B: Sure. I mean, I'm originally from Canada. I was living in Vancouver. Uh, well, I actually started coding when I was about 15 years old back in the 90s. It was kind of an early adopter of, ah, web technology. Surprisingly, I was probably, uh, one of the first, probably the only people in the entire high school that was really into computers at the time. And not just computer games, but actually building websites. Um, uh, so after college started, uh, at the cbc, which is the Canadian Broadcasting Corporation, always like to say it's the BBC for Canada, for people who don't know what it is. And I got, uh, an early taste of building things that, you know, people actually like. Um, we built a pretty popular digital music music streaming service called CBC Radio 3. It was kind of the backbone of indie music in Canada. It was really exciting. We were kind of soundcloud before soundcloud. We were you know peer, uh, to peer social music, uh, streaming platform. I remember even the soundcloud came out after us. We, we actually were innovating on a lot of the live streaming, interactive stuff early on. And then uh, I worked at another tech company after that and then did my way to San Francisco and worked at a startup, kind of went under classic story. And then very shortly after that joined Uber and I was one of the first engineers, um, kind of like the first 75 and one of the first mobile engineers at Uber as well. So joined as a web developer and then learned uh, a mobile pretty much on the job. So it was a pretty exciting time to be there. As you know it's one of the hottest startups uh, at the time we were growing like crazy mobile first and again I really got a taste for building products that people like to use and I thought that's kind of cool. You know it's like being in a band that has a hit song. Uh, and then uh, it can grew with the company. Rapid growth, just staying in place took a lot of effort and to actually grow the company is just kind of uh, it was non stop. You know, you're eating, breathing, living, coding, uh, working all the time. It's just, you know that was kind of the culture at the time. But I really got a, got a taste of having the scale. Everything was about scale there. Grow, grow, grow, grow, grow. Code base is growing, engineering teams growing. After about three years I moved into management and started the what's called the Rider platform team, which is a mobile platform team for the Rides app and grew that group. I had three teams in three different cities. Um, and then as time went on I actually switched over and worked on E Mobility which those jump bikes and scooters. Then after that I went and started the Eats, uh, platform team and moved on. Uh, eventually I was there for about 10 years in total. Um, and so we saw it from like about a 300 person company when I joined to like 30,000. I had to kind of grow through all the phases of it from startup to large, corporate, multinational, um, so that's pretty cool to go through all the different phases. Usually people kind of turn over after a few years. You know you get different types of people to come through the door. But I had kind of, you know, learned those different phases and uh, it was awesome. And then ended up at SoFi after that.

Speaker A: What an incredible moment in time to be part of like front end user experience for a company like Uber. I mean if you think about where you started relative. All of a sudden you're doing like scooters and stuff and eats, um, which probably if you went back to the first couple of years you were there, it probably would have been like wild to think about where you would end up. And I think Uber for me always was a classic example of like somebody who was really doing mobile.

Speaker B: Right.

Speaker A: One of the things I always loved about Uber was like, so many, um, so many companies want to like keep you in the app, like how much time spent in app. And I always loved the Uber design aesthetic of like, no, open the app, let me do the thing and actually get me in the car. You know, you actually, I don't want to be glued to this thing. I wanted to be like super efficient. And I always really respected Ubers, uh, design, UX and technology from that perspective.

Speaker B: Yeah, we cared a lot about that, about compressing the time. You know, it's pretty much time to tap, time to ride. Everything was about speed and efficiency. How fast can we get the app to launch, how quickly can we get you, uh, the ride? You know, can we keep shortening that, making the network more efficient, making everything more efficient? Because it just drove more rides. But yeah, it's definitely an app first experience.

Speaker A: Awesome. And, uh, you went through, as you're saying in that story, you went through this journey of kind of being a member of the team into a more engineering, leadership and management, uh, role over time. How did that happen for you and what were some of the kind of key, pivotal moments or key lessons learned that uh, helped you grow into becoming the engineering leader you are today?

Speaker B: Yeah, so my, I actually was, uh, a manager before when I was living in Vancouver. So I did get some training and I got a taste of it. And you know, I think generally I had a kind of a natural inclination to kind of leading the team. I mean, you kind of recognized that early on and it offered for me to, you know, grow a new team. And I was just kind of in my late 20s. I thought it was a little bit early at the time I wasn't ready to kind of like get off the keyboard and just be in meetings all day. So I, uh, actually went back to ic, moved to San Francisco, kind of like, you know, retooled out of like the dot net world and into more of the open source stuff. And I think that was good. I think I needed more maturity before moving into management. Um, you know, I'd encourage anyone who's looking for management, like, it's okay to be an IC for a while. Like, sit in that, like, you know, build that respect of your peers, really learn your stuff, ship products, learn how the kind of the workflow works. And then at Uber, what was interesting is that there was so much growth and turnover in my first few years that I ended up having about six different managers. In, uh, the first three years it was so a little chaotic that, you know, managers were coming and going so much and it was kind of like unstable. So in that period, I just kind of took over the team. I just started like running Scrum, running, you know, running our process, running planning. And a manager would pop in and, you know, maybe last for a few months and then move on to the next thing. And so I was kind of like that stable person in the team that was just tech leading and mentoring people because we just needed it. And so when it ended up happening is that management was like, hey, seems like you're already doing the job. Why don't you just, you know, start this team? Because I've been proposing that, like, we probably need a platform team. We need, you know, someone who's just going to be like, dealing with the overall app architecture and a lot of the tooling and, you know, bringing in new libraries, working with our kind of like central. We have, we had a mobile platform team that was central, but no real platform team that was dedicated to like our app. Because rider app is just like an operating system. It's just so huge, you know, hundreds of engineers working on it, but you need a team that's coordinating all that. And so they offered for me to start that team. Ah. And so it just kind of like slipped right into it. And, you know, I pulled over a bunch of my peers and I'd already been kind of like, you know, garnering the respect of the team and working a lot of the on the foundations of the app, as well as working on app architecture and foundational pieces. Anyway, so it's just a continuation of what I was doing.

Speaker A: Uh, that's awesome. Now, let's talk about Sofi, right? When did you move to Sofi? And I know you're, you've undergone a similar massive scale effort there, like a stepping up and sounds like more scale in the future. Um, what got you over to sofi?

Speaker B: What was the.

Speaker A: Org like when you started and how has it evolved?

Speaker B: Yeah, so after Uber, I took some time off. I mean, I think it was well deserved. You know, 10 years of grinding it out. I think I was ready for a break. So I took about five months off, um, and discovered something about myself That I actually, you know, got bored pretty quick and I wasn't really ready to retire and uh, I was just seeing the AI boom starting to happen. I was like, I got to get back on the field. This is, you know, it's too exciting. There's too much stuff happening. I am not meant to be just a kind of a stay home kind of guy on my phone or just even just going and playing outside. And that kind of runs out of excitement pretty quick. So I was looking around for different opportunities. I was definitely looking for that director scope. I've been essentially doing that level of work at Uber. Like the rides organization for example was like a thousand people and we probably had about a hundred mobile engineers and I was leading platform work for that. So I was looking, you know, for something maybe similar size or bigger or something that would become bigger. And you know, I was just kind of like threw myself out there and was interviewing and you know, networking. And then the SoFi opportunity came around and um, it just checked all the boxes. You know, for me it was like I had a kind of a laundry list of things that it was like, you know, to help me eliminate opportunities like you know, too small of a company. I didn't really want to go back to a startup. You know, I didn't want to go work at a company about Google size or a meta or something. So I was looking for that sweet spot of a growth company that was, you know, maybe struggling on the scaling phase. And so that felt like that's where my skills could be best applied was the actual scaling part. Like let's go from you know, uh, that intermediate size. We're kind of like getting out of the startup phase to like big company, big code bases, large teams. You know, I'd done that a couple times at Uber on the ride side and the E side. So I think I had to kind of cut my teeth and understood some things about scaling teams. And so when sofi came around, you know, like the, the, the growth story was really compelling. It's consumer brand, it's mobile first, the Mobile first bank. We had a kind of a nice product. And then just as we were talking, you know, I was talking to, to my director, Kevin, uh, your senior director and he was talking about some of the needs and to, to scale the team, scale the scale the code base and that really want to be a top 10 financial institution and build like a financial super app. And I was like, this seems really exciting. This is a cool opportunity. So I took it. Yeah. And I've been Very happy.

Speaker A: Yeah, that's. I'm curious about the scaling side of it. Right. I think, um, you know, a lot of engineers are out there in a lot of different spots, small startups, big companies, where they've maybe already scaled. What are some of the, like, when you talk about scaling, like, what are the unique things that you're really focused on? You mentioned team, you mentioned kind of code base, I assume things like architecture, like when you think about scaling up a system or maybe when you came into SoFi, like, what were the top three or four or five areas of focus you really put energy into?

Speaker B: Yeah, so when I think about scale, like what, what, what worked for you as a small shop or a small code base starts to break down. That's typically what happens, right? I mean, you can build a product and like a Ruby on Rails backend, for example, you like one database, one server and like a web app on top. Like, great. I mean that, that gets you started. What happens though, when you have like a million users or 10 million users, right? Like all those, uh, assumptions that you made about like, how many connections you can maintain or, you know, like how big your database is getting, right. You start having discharge your database, start introducing microservices and those concepts, like, although mobile apps are a little bit different, but so those ideas, um, start to, you need to apply different types of thinking, right? So what happens when you have 100 or 200 people working in one code base at the same time? All those assumptions about like, your module structure and your build start to break down. Even things like indexing the code base start to fail. Um, your CI, right? Maybe you ran a couple nodes in your CI. Now you've got, you know, potentially hundreds and hundreds of merge requests coming in a day, maybe 500,000. Your test runs start slowing down. Um, and now you're starting getting a lot of engineers. You're, you know, I call them kind of like busy intersections start forming where you have potentially you had like your one big file that had, you know, maybe a couple thousand lines of code. Now it's reaching 5, 6, 7, 8, 9,000 lines of code. And the complexity is starting to bog the teams down. Um, you don't have a design system, so now your app looks different everywhere and you start having to have struggle managing that. So those are types of scaling challenges that you start to see. And, you know, we have to address those as we go through and start planning and making assumptions like, hey, we're at 110 engineers right now. Like, we're probably going to have 200 by next year. Like what does that look like? You have to do capacity planning, um, and start looking at all of your pipelines and planning to try to speed up development time, speed um, up onboarding, speed up um, your CI runs and you're looking for efficiencies across your entire pipeline because really you, you're generating like a giant code factory and that code has to go out every single week. So the automation across every part of your stack because even just you know, pushing code out becomes a, ah, big effort. Getting everything tested is a big effort. So all those things need to scale up.

Speaker A: So that, that's super interesting because um, when you talk about problems of scale, And I know SoFi now is one of the largest like Flutter companies out there in terms of number of Flutter engineers and complexity of the code base, number of lines of code. How have you brought that sort of scaling mentality to a uh, Flutter code base which is a relatively new technology. Maybe not as many engineers, maybe not as many best practices and standards and tools and things. Tell us a little bit about that experience.

Speaker B: Yeah, so when I, first of all the, the decision to use Flutter was made before my uh, entry into the company. I think it's an awesome decision. I mean truly, now that I've been working with it, I'm like ecstatic. I would promote it to more companies. I think they, you know, especially seeing it uber, just the, the Herculean effort to get like two apps out constantly and just the pipelines and just dealing with the feature set and trying to keep the uh, the feature set in, in sync with each other. Having to hire, you know, constantly trying to keep our, our, our levels of engineers balance because sometimes someone quits, leaves a company or whatever, we overhire in one area and now we've got you know, three iOS and one Android or Vice versa on a team. And now suddenly, you know, the iOS roadmap starts to accelerate ahead and the Android roadmap kind of falls behind. You know what we saw also is an Android development usually just took longer. Like you just had the, you know, more devices to test against, there's more fragmentation. Um, getting UI to be really, you know, look perfect, uh, was really, really difficult when supporting old versions of Android. Newer things where uh, on Flutter, I mean it's pixel perfect. I mean across all the devices, we rarely have a device specific rendering issue. I mean it's almost never, it's just not what happens because the, you know, the, the rendering engine ships with the binary so we can have a lot of fine control over, uh, you know, how, how the, how the layout works. Um, and then um, coming into SoFi though, I mean we really were just like, you know, a few years ago kind of like a startup. I mean like most of the hiring's happened in the past couple years and so the team kind of like maybe wasn't totally prepared for how quickly we grew and so there really weren't the foundations in place for what I call uh, an institution. We had a bunch of engineers writing code, pretty much converting From Android and iOS engineering to flutter engineering, kind of learning on the go. So really didn't have a lot of training so not really consistent practices. Um, and the information about how to do things the right way really wasn't published anywhere. So as you start to scale you really can't have like, you know, bottlenecked. Uh, you don't have your team bottlenecked on single engineers. Um, so I've got, you know, I, I, when I first joined I'm like, where do you get your information? I just surveyed people and like, you know, started talking around or the organization and they all pointed to one guy. You know, they're like one, that guy's got, you know, all the information in his head. So it was like kind of like a six month effort to try to like dump what was in his head into documentation. We had, you know, hundreds of pages of archive or out of date information that had to archive. Um, you know, because it was confusing people. So you got to think about really, really kind of like, you know, keeping your written documentation and what you want out of your engineers and your values and your principles, your coding guidelines and practices and process, all of that needs to be written. That's just like ah, the first thing you have to do if you're going to scale any organization and I think even small teams should be doing it because something that's almost a constant is that new people are going to be coming in at your org all the time. People are leaving. Even if your head count's flat, you have to assume that like maybe you know, 10 to 20% of your workforce is going to be turning over every single year. And those are new people you've got to train over and over again. You and you might get different outcomes depending on what team they land on. If you don't have anything written, you don't have good training in place. So that's absolutely critical. And then you know, in general I'm thinking about like, you know, creating a really resilient culture. So it's Kind of steering the culture away from just only moving fast but towards quality, towards you know, like changing the values of the organization, um, the mobile organization as a whole, uh, you know, like really focusing on testing, really focusing on good architecture, you know, solid code reviewing. Um, you know those things that you kind of take for granted. You know, maybe some people care about, about it but other people don't. Some teams really are enforcing the practices. We all have to live in one code base which is different than like, you know, maybe backend services. You could have these little microservices and you kind of get to federate. But in mobile everyone's living in the same soup. So you've got to make sure that everybody's following best practices because one code, one line of code can basically take down graph. So we're really trying to enforce feature flagging. Um, you know, we've been, you know, having test coverage requirements and now bringing in like you know, new design systems, trying to get consistent ui. So uh, you know, all those things you have to start bringing to the, to the, to the organization and you don't get it for free, you got to build that stuff out. Um, and it's a lot of work to kind of like ramp up. And then once you invest in it though, then it's basically repeatable. Right. You get uh, you know, consistent outcomes on every team. You should be able to go to every single, you know, part of the code base and it should look relatively the same. That's the kind of the long term goal here that I shouldn't have like one team doing really, really high quality work and the other team kind of like maybe just learning on the go and uh, not necessarily knowing what they should be doing.

Speaker A: I love that because I think so many people focus on the tools or the frameworks and they get these sort of like religious wars around what type of uh, framework to use or language or state, uh, management package or whatever it is. Right. And I think so much of it is, yeah, like are we aligned on values? Are we going to do things consistently and have consistent standards that we're going to all hold ourselves accountable to?

Speaker B: Yeah. And I think that's why having it written in a central place means that people can argue over the written outcome. You can say we're going to change the policy or we're going to change the process, we're going to change that rule. Fine, that's great. But at least we have a rule, we have some process and that anyone can point to. And what I found over time is as you know, one of, one of my rules for, for my team was don't respond to a Slack message without a wiki link. And that rule is really good because it means like, am I responding with documentation or am I just kind of like responding to this question? And if you respond with documentation, totally changes your posture. Be like, well, what, what is the right way to do things and where are we going to put it? How are we going to format it? And then the next time the question comes up, you don't have to answer that question again because here's the documentation, here's documentation. And so that's something I saw over time too, is that as we started really investing in the process and policies and documentation that engineers were sharing those links and short circuiting discussions in Slack. So it's actually more efficient because you don't have, you know, 300 line messages, like 300 messages in a row, people all arguing and talking about something. We like get out of that Slack message and get into the wiki. So then we can all just coalesce around that and then share the link and then next time share the link. And then that question, never asked, answered again.

Speaker A: And a big theme here has been scalability, like this big part of your career, the things that you've learned and grown and um, uh, you know, again, kind of putting the emphasis in places where we as people doing these things, we kind of focus on sort of these false things to look at, which is like, oh, how fast did it compile? Or this, the API response was 50 milliseconds instead of 500 or whatever. But you've said you've talked a lot about teams and I think so much of scale is like, is the team itself high performing? And that's a lot of times not even a technology influenced thing at all. It's like, do we have the right standards? How do we operate? So it sounds like really investing in teams and structures has been a key part of your management philosophy.

Speaker B: Absolutely. I would say code, anyone can write code. And in fact code is becoming free to write. It's like, what do we do? How do we do it? Um, is it understandable? Are we all on the same page? Are we working well together? Are, is the energy good? Like just, you know, I think about just negative energy can really just suck the, you know, take the wind out of someone's sails, they become less productive, they don't want to come to work. Um, you know, it's a drag. So just really making sure that the morale continues to be high, that people Stay focused, that, you know, works well together, that there's, you know, even like, personal conflicts are weeded out early and, you know, that's usually improved. With good clarity, with good process and systems and clear lines of ownership, you make sure that, you know, if, if you're the tech lead that like the, you're the final decision maker. Right. So I'm gonna, I'm gonna create a structure to make sure that like, hey, you're the directly responsible individual on this. I'm gonna go to you for questions. And if there's, you know, maybe an engineer or two working under you, I'm, um, not gonna undermine you and go to the person who's, you know, kind of, uh, like, you know, called reporting to you for the, for the, for the, the duration of the project, I'm going to go always to the tech lead to make sure that the decision making flows in one direction. And so I think those types of things give people more confidence that they're doing the right thing, that they know, you know, who to talk to, that if there's a disagreement, we can kind of like have a really clear chain of escalation. M. I think that's the stuff that can sink in an engineering organization. Again, the code, anyone can write code. You know, you can go to a boot camp and learn how to write code. And especially the AI tools, which is where we are cranking out code. That's usually not the bottleneck now.

Speaker A: Right. I know you're scaling and modernizing a very large code base with a lot of people. You mentioned that you're, you'll be hiring, growing that team quite a bit. And I think your number of lines of code in, in one of our early conversations you're talking about that's growing like on an increasingly accelerated path. Can you kind of, um, dig into that a little bit and maybe, maybe

Speaker B: give us a sale?

Speaker A: Like how, how big is this set so far? Like how. How big is this application?

Speaker B: Yeah, so we, in the first couple years of rewriting the Flutter app, we added probably about a million lines of code. And then just last year alone we added another million. So we, and then most. But we added about 500,000 lines just in the last quarter. So we're looking at a pretty steep curve. You know, AI tools and just the growth of the engineering team combined is starting to kind of like really make a, uh, uh, steep increase. So we, the, ah, current rate, if nothing changes, just our current rate will be around, you know, probably another doubling next year. About 400,000 lines of code. So just the weight of the code is starting to kind of get heavy. Right. We have, you're dealing with like even just switching branches and um, you know, dealing with code gen, dealing with, you know, indexing and builds are turning to, you know, we're starting to feel that drag and it's not going to get better unless you really invest in it. You know, we've been throwing hardware at the problem, um, just temporarily and we got, I mean every single person in the entire company got brand new like M4 Max just because we were able to show some data that, you know, we can compile faster, we can, you know, we can just generally work faster. So that was a no brainer. But you know, hardware can only take you so far before you start having to like really start restructuring your code and doing more incremental builds. Parallelization. Parallelization and being a little smarter with your resources and with all those lines.

Speaker A: So all those lines, is that humans? Is that AI? What's uh, what's driving that acceleration?

Speaker B: Yeah, I mean code is code, right? I mean some of it is code gen. A lot of it's unit tests. You know, you think about unit tests are probably like, you know, four or five or six to one of, you know, unit test code to um, application code. Um, yeah. And then just your cursor and Claude are cranking out a lot of code. So you know, we're. And it's not even that much code. Right. If you think about, you know, adding 120,000 lines of code per month, that's only a thousand lines per engineer. 250 a week. I mean cursor can generate you 500 lines of code in a second. And especially test code. I mean we just put out a new product called SOFI Pay and just a small team was able to write a thousand lines, sorry, a thousand tests for that product and did. So you know, that was, that was over the course of a couple months, you know, so yeah, it's adding a lot of code faster. So that's something to deal with.

Speaker A: Do you think that when you think about the scaling of code, both people and AI enablement that comes with that and sort of the operational. Has flutter helped or hurt or just neutral relative to your past experience or

Speaker B: other, other platforms for sure helped. I mean, uh, just having one language that we, you know, one language, one framework, one code base to deal with means that we don't have to like split our effort, be like, okay, here's you know, all of our AI rules for iOS. Here's all of our AI rules for Android, we get to like really just as an organization, invest in one set of tools, one code base, one. One set of training, one best practice, everything. So um, Flutter has made it just dead easy. Um, comparatively I kind of cringe at now the thought of having to maintain M2 independent platform teams and two sets of code bases, everything and then trying to keep those in balance just be uh, way more of a headache these days.

Speaker A: Yeah. And yet so many people are still doing it.

Speaker B: That's right, yeah, yeah, they're investing, you know, they're deep into it and so. But you know, I think rewriting um, with AI tools now is, is also much easier. I mean you can you.

Speaker A: Yeah. And do you have any concerns about scalability in terms of uh, third party tools or anything about the engine or the framework that could keep up with that as you go forward?

Speaker B: I mean, I think, I think what's hard with AI tools is just getting it to do the right thing. Know the hallucinations, just the correctness. You know, we put a lot of effort into building up a lot of our markdown files with you know, do's and don'ts. Best practices to coax the agent to do the right thing. As your code base scales like cursor, really you think about it, uh, what the secret sauce of cursor is and a coordination layer across your code base to try to reduce the context window so it can actually talk to agents. Because you can't actually put your whole code base uh, in the context window for an agent. So you have to try to, you know, reduce the context window as much as possible and operate on small chunks of code. You know, we've looked at some vendors that you know, claim they can work on like much, much larger code bases. So there's, there's some opportunity there for us I think, you know, with the tool set to try to index the entire code base. There's, there's some vendors out there, but generally that's the hard part with AI is just getting it do the right thing. It's really great at the function scope, but I've seen say like Refactor all of my code base and uh, you just can't do it right. Not today at least.

Speaker A: Yeah. When you think about the next level of scale for you guys, um, what are the kind of major hot items you're thinking about? Is it um, like architectural, testing, automation? What are the main things you're, you're focused on?

Speaker B: Yeah, for us next year. So, you know, we've got the way that the, the app was set up was, yeah, followed by clutter best practices for the time and was probably a good, a good layout. If you're dealing with a small app, you probably would have been fine. I mean, I'm sure lots of small companies would never outgrow that. Um, but most of the code is in one package. It's well organized within the directory structure itself, um, you know, into features, libraries, that kind of stuff. But it just means that that one package keeps growing and growing and growing, growing. So we've actually started an effort, we call it internally called it Project Athens. But it's a move to modularize the code base. So extracting features, extracting libraries, um, having kind of service packages and networking packages, trying to like, you know, organize this app, um, and then bringing in riverbot. So we did an analysis of all sorts of different architectures. We had a working group that was kind of building prototypes, looking at all the frameworks out there. And then we landed on RiverPod after we thought was some really, really good demos. And it did everything we wanted. So we wanted, you know, real dependency management. You know, I think we wanted to use the providers. Um, we wanted to have scopes and actual like structures. And then we wanted to be able to, uh, do dependency inversion for the packages and then actually have, you know, better unit tests. So I think one of the big things would be maybe a miss on the early architecture was bringing in service locator, which is get it. Um, it's fine when you're small, but having singletons of singletons of singletons throughout, the entire code base actually starts to break down as you have a really big code base. So we end up with things like flaky unit tests. Unit tests shouldn't be flaky. They're only flaky if you're mixing state globally. Um, and we try to short our test runs across a lot of different instances because they're starting to slow down. And what happens is that, is that you know, when you're running your test, uh, and you made some assumptions about global state, can you run it on your machine? Sure, it works. Then suddenly when you start sharding and that global state actually gets mutated or this m, you have synchronization issues now you've got tests that are doing weird behaviors. So we're trying to get away from that and move towards real dependency injection, construction, injection, and then start breaking down these packages. So that's going to be a big effort, lifting and shifting and then moving our dependencies out of the Service like or haven't from the components or di. Graph.

Speaker A: Yeah, that's super cool. Um, hopefully as you guys land on that and get some, uh, uh, best practices in place, I'm sure a lot of people will be interested to see where you land that modularization of such a large, complicated code base. We're getting to this point in Flutter's evolution where we're starting to see companies achieve that or get to that need. And I think that's like sort of this, uh, uncharted, uh, territory of best practices and opportunities.

Speaker B: So, yeah, we did it. You know, Uber, we, in the early days, the first version of the app suffered the exact same fate. I mean, I've seen this and, you know, say we've been around the block a few times where we had kind of one package and we just. The builds, we had a similar growth story, same. But we're probably gonna have more engineers working on one app than we did, even at Uber. And the rides app, and we saw the, the packages and the build times just start to explode and grow. And then we ended up trying to do it kind of like while we were running the app. That was quite difficult, you know. Um, and then we ended up just doing a whole rewrite, and that gave us the kind of a clean slate to bring modules and package structures and all that stuff. We ended up with about, you know, a couple hundred modules, uh, per app. So, you know, no stranger to, like, large architectures. I mean, you can get to a certain size and that becomes a problem, uh, unto itself. You know, your, Your tool chain starts to break down even at certain scales. I don't think we're going to hit that, you know, scaling problem for a while. If we start monetarizing the app correctly, you know, for it, you know, I would. I would assume we'd probably end up with probably like 20 or 30 packages by next year. Just totally, you know, maintainable. Right.

Speaker A: One of the things, um, you know, there's this idea of, like, Conway's Law, right, Which is like the shape of your, um, your product starts to mimic the shape of your team. I'm, um, curious how your team is organized and how you kind of deploy people within the organization. Especially since you are doing Flutterware, the most natural first cut is like iOS or Android. You know, you don't really have that, uh, problem. And potentially, as you have multiple apps running Flutter, people become pretty fungible. What is the sort of organizational structure you guys are pursuing or might look to move to in the future?

Speaker B: We follow a kind of Matrix organization, um, much like a lot of bigger companies, you know, business units or business verticals. And um, all those business verticals are going to be building their own features and then uh, committing code to the one trunk essentially of the code base. Um, we use feature flagging a lot to enable that so that we don't necessarily have teams breaking other teams code, uh, as they're rolling out new features. Then we have a big platform team I think right now with contractors and probably got about 23 people. And so I think as you start to scale and you have vertical teams and you've got platform teams, you really have to invest in platforms. I think it's, it's, you really can't get to this scale without having a really strong platform team. And the goal there is to make product engineering fast and easy. You want the product teams to be able to crank out new features, get products to market really fast, iterate on UIs, find the product market, you know, onboard new users, try. I mean you should be experimental and you should, you should be able to you know, slap together a UI quickly like Legos. Get it out there, try it out. If there's a work, shut it down. We'll try again. You know, that's what we want to see out of product teams. But you've got to provide the tooling to make to unlock that. So you really need to have like real, really talented, usually far more senior, um, level. I've got a lot of staff engineers I work with principal engineer, um, so I try to skew the seniority of the platform team to far more senior. You know, people have worked on big apps, worked in big teams and understand how to scale stuff.

Speaker A: That's awesome. As uh, you clearly uh, have seen quite ah, a number of amazing experience in terms of building teams both at Uber and going through that whole journey. And so far you're on this incredible upward trajectory. Is there like a leadership principle or two you've learned along the lines or along the way that you would share with ah, either up and coming person or someone in your shoes. Like what is the takeaway that you have discovered that has really helped you lead?

Speaker B: Yeah, I mean generally, you know, I really like the principle of radical candor right where you're, you know, you care deeply, you're giving them a lot of feedback. Um, and you know you're, I like to be like deeply involved in people's careers and make sure that they're growing. I really want people to be right on that edge of comfort. You know, you're Kind of like out of your comfort zone. You're, you know, kind of in that state of flow where you're not, you know, pushed so far off the deep end you don't know how to swim. Maybe the waves come crashing down on you. Rather have you just on that edge where you're learning, you're growing, um, you're working towards the next level or constantly checking in, making sure that you're, uh, you know, that we're, you are moving in the right direction. I really don't want to have people be stagnant, just kind of like hanging out in their level for, you know, 10 years, whatever. I'd rather have people always be working towards the next level. Strong encouragement that we're, you know, working towards that next promotion, figuring out, you know, working our way backwards. Well, what do it take to get there? And I think when you provide that for engineers to get really motivated, they really, they think that, like, hey, this person believes in me. There's, there's a path to move forward. I'm given those opportunities, I, I can step up and grow into that opportunity. Um, I think that's motivating and exciting for people and you know, they get motivated to come to work because they know that they're there, that there's, there's a path for them to grow. And I think every single person on the team, you know, should be given that opportunity.

Speaker A: That's, that's amazing. That's wonderful. That's great, great leadership advice. Um, one final question about Flutter specifically, obviously given, uh, our, our role in BGB and being in, deeply in the Flutter ecosystem, what advice or comments would you have for somebody who's kind of out there sitting on the sidelines looking at Flutter and being like, I don't know, uh, native seems the pure way to do it. Given that you've seen both, I mean, you have, uh, I think are very credible in that you've led very large teams both at Uber, which is one of the arguably most complicated mobile apps or teams that are out there. And now sofi, what kind of guidance or advice would you give to someone who's, who's evaluating that decision?

Speaker B: I mean, it's never been easier to learn new stuff. Like even, you know, most engineers that we hire are Android and iOS because it's actually very hard to find, uh, you know, staff level or senior level Flutter engineers. Because it's so new. Most folks have either been tinkering with it or worked on small apps, you know, maybe as a hobbyist or something. So we have to train people, we have to teach them. And so most people pick it up pretty easily. Like you'd be surprised. There's uh, you know, even web developers because Dart is pretty much JavaScript anyway and the documentation out there is great. But also, I mean, cursor in the agent, it's conversational. You can be like, teach me stuff. And so I feel like a lot of, a lot of engineers with cursor have been learning. You know, there's kind of a back and forth of the agents, kind of like a coach. We're hoping to invest in that more. You know, we'd like to see more coaching come out of the agents. But you know, for anyone who's interested, I mean like pick it up. I mean just get your hands on it, get your hands dirty. Try to get an app out there. You know, if your friends have a business or a band or something, you don't try to build something. Um, you know, that's how it always happens. And then, uh, you know, maybe build up a portfolio. Um, but also assume that like, you know, we tend to hire folks with mobile experience, not necessarily Flutter experience, so you can, you know, don't be shy to apply if uh, if you don't have Flutter experience because we'll, we'll, we'll give you the time that you can learn. And we've got an awesome community with support, you know, lots of support to help people out.

Speaker A: Super important insight. We hear from a lot of enterprise companies sort of this concern, uh, about can I hire like, you know, senior level expert flutter engineers? Well, it's really only been around for seven years, like in production in major ways. So maybe there are some people out there that have seven years of super high end complicated experience, but there's so few opportunities for that. But I think exactly what you're saying. It's, it's harder I think to uh, get the senior engineer skill set more generally and then you can learn Flutter. Like let's get that versus requiring people to achieve that level of expertise. Only using Flutter this time is probably.

Speaker B: And I think also you have to consider like, what are skills that are easy to acquire versus skills that are hard to acquire. Learning a new technology is actually pretty easy to acquire. You can acquire new. And um, you know, you can pick up a new framework, you can pick up a new language. You know, you can learn a new language in a week or two. Right? I mean it's, it's usually not that hard once you've like been coding for a while. The skills that are hard to acquire are things like organizational skills, good communication, teamwork, project management, you know, deeper understanding of architecture, you know, people who can interview other engineers. Those types of skills, like, can you grow, can you, can you mentor others like those. All those soft skills are actually what are probably the most valuable. And that. The coding part, like, yeah, people can learn how to code it. You know, it may, but for, uh, like a staff level engineer, principal engineer, you know, we're talking 10, 15 years of experience of working in software. And you know, for most engineers that, you know, software is going to come and go. Different frameworks are coming and going constantly. So usually you have to retool every three, four, five years anyway. So I think it's just par for the course for anyone who's been in the biz a long time, that's great.

Speaker A: Um, one more question for you just to kind of wrap us up.

Speaker B: Sure.

Speaker A: You know, you've been through so many experiences already. You went through Uber and even your prior roles that you had now. So if I probably, uh. A lot more ahead. Right. A lot more experiences ahead. If, uh, if you could look into the future and think about, like one day you write a book or something about your professional experience, what do you think you would title it and what would it be about?

Speaker B: Yeah, so, I mean, I think I wrote this down just in preparation. Um, so I. This is kind of one of my mantras. And I think this would be a, you know, if I was writing a book on leadership or business be just called Treating people right, you know, and then how to motivate teams without burning out. You know, I, I really think that if people are aligned and that you create good opportunities, they love working hard, people love doing hard things. It's usually hard things when you're not aligned that burn you out. You're. You're not really excited about the work, you're grinding. This is just like day in, day out of doing things you don't want to do. But if it's, you know, exciting, you got good opportunities, you like your team, you want to show up to work, you want to put in those extra hours because you're passionate about it and, and you're having fun and you're shipping things and you're, you know, you're growing as an individual. So I think that if you find the right way to motivate people, they won't burn out and they'll actually, you know, come to work and want to work harder for you. I love that.

Speaker A: Well, thanks so much, Phil. Um, really appreciate you taking some time out of your busy day. Um, so I really appreciate this. I mean, the SoFi app has been a, I think a real inspiration to a lot of people out there. Just seeing what you guys have accomplished, uh, hearing those stats about how many engineers, number of lines of code and they're rapidly accelerating Pace of that, you know, as we're still building, I think we're still in the early phases of Flutter. And personally, I think flutter is the perfect language and tool for AI enabled development too. Um, and so it's just been great to see your story and I just really, uh, appreciate you coming on here today.

Speaker B: Cool. Pleasure is all mine. Thank you so much for having me.

Speaker A: And if people want to learn about SoFi, or if you guys are hiring, where can they find out more?

Speaker B: Absolutely. Sofi.com and, uh, yeah, we've got a jobs page. We're definitely hiring. And, uh, we'd love to have folks who have Flutter experience or, you know, just mobile experience in general.

Speaker A: Amazing. Well, thanks so much. Really appreciate your time.

Speaker B: Thank you.

Speaker A: Thank you for joining us on Build to Succeed, a very good ventures podcast. We hope you enjoy exploring the experiences and insights of leaders that have built successful digital products. Please take a moment to leave us a review. And if you want to get our latest episodes, don't forget to subscribe. Thanks again. See you next time.