Phil Rabin, SoFi—Enterprise-Scale Flutter: Modernizing Architecture for a 2-Million-Line Flutter Codebase

David DeRemer:

Hi, I am David and this is Build to Succeed from Very Good Ventures. Today we meet with Phil Rabin, 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.
‍

Phil Rabin:

Hi. Thanks for having me.
‍

David DeRemer:

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

Phil Rabin:

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 doing dishes or working out or riding my bike or something I love, having a constant stream of information and keeping up to date what's happening in industry. I've got a bunch of favourite podcasts I like to listen to. I love kind of the more techie business podcasts like Lex Fridman, Scott Galloway, Diary Of A CEO, Tim Ferriss. If there's something to learn, I'm all over it. That's awesome.
‍

David DeRemer:

Yeah. Well, you're in a good spot for that then. So, we, you'll get to listen to us talking pretty soon. Why don't you kick us off by 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're today.
‍

Phil Rabin:

Sure. I mean, I'm originally from Canada. I was living in Vancouver. Well, I actually started coding when I was about 15 years old back in the nineties. I was kind of an early adopter of web technology. Surprisingly, I was probably 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. So, after college started 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 an early taste of building things that people actually like. We built a pretty popular digital music streaming service called CBC Radio 3. It was kind the backbone of indie music in Canada. It was really exciting. We were kind of SoundCloud before SoundCloud. We were peer-to-peer social music streaming platform.
‍

I remember even the SoundCloud came out after us. We actually worked innovating on a lot of the live-streaming interactive stuff early on and then I worked at another tech company after that and then did my way to San Francisco and worked at a startup, went under. Classic story. And then very shortly after that joined Uber and I was one of the first engineers, the first 75 and one of the first mobile engineers at Uber as well. So, I joined as a web developer and then learned a mobile pretty much on the job. So, it was a pretty exciting time to be there. As it was one of the hottest startups 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.
‍

It's like being in a band that has a hit song and then it grew with the company. Rapid growth, staying in place took a lot of effort and to actually grow the company is just, was nonstop. You're eating, breathing, living coding, working all the time. That was kind of the culture at the time, but I really got a taste of having the scale. Everything was about scale there, grow, grow, grow, grow, grow. Code bases 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 and then as time went on I actually switched over and worked on mobility, which those jump bikes and scooters.
‍

Then after that and went started the Eats platform team and moved all in eventually I was there for about 10 years in total and so we saw it from about a 300 person company where I joined to like 30,000. I had to grow through all the phases of it from startup to large corporate multinational. So, that's pretty cool to go through all the different phases. Usually people turn over after a few years you get different types of people that come through the door, but I had learned those different phases and it was awesome and then ended up at SoFi after that.
‍

David DeRemer:

What an incredible moment in time to be part of 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 scooters and stuff and Eats, which probably if you went back to the first couple of years you were there, it probably would've been wild to think about where you would end up. And I think Uber for me always was a classic example of somebody who was really doing mobile. One of the things I always loved about Uber was so many companies want to keep you in the app, how much time spent in the app and I always loved the Uber design aesthetic of no, open the app, let me do the thing and actually get me in the car. I don't want to be glued to this thing. I wanted to be super efficient and I always really respected Uber's design, UX and technology from that perspective.
‍

Phil Rabin:

We cared a lot about that, about compressing the time, it's time to cap, time to ride. Everything was about speed and efficiency. How fast can we get the app to launch, how quickly can we get you the ride? Can we keep shortening that and making the network more efficient, making everything more efficient and because it just drove more rides. But yeah, it's definitely an app first experience.
‍

David DeRemer:

Awesome. And through, as you were saying in that story, you went through this journey of being a member of the team into a more engineering leadership and management 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 helped you grow into becoming the engineering leader you are today?
‍

Phil Rabin:

Yeah, I actually was a manager before when I was living in Vancouver, so I did get some training and I got a taste it. I think generally I had a natural inclination to leading the team. I recognised that early on and it offered for me to grow a new team and I was just in my late twenties. I thought it was a little bit early at the time. I wasn't ready to get off the keyboard and just be in meetings all day. So, I actually went back to IC, moved to San Francisco, kind of retooled out of 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 and encouraging anyone who's looking for management. It's okay to be in IC for a while, sit and not build that respect of your peers, really learn your stuff, ship products, learn how 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 the first three years it was a little chaotic that managers were coming and going so much and it was unstable. So, in that period I just kind of took over the team. I just started running scrum, running our process, running planning, and a manager would pop in and maybe last for a few months and then we wanted 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 what ended up happening is that management was like, "Hey, it seems like you're already doing the job. Why don't you just start this team?" Because I've been proposing that we probably need a platform team.
‍

We need someone who's just going to be dealing with the overall app architecture and a lot of the tooling and bringing in new libraries, working with our central, we had a mobile platform team that was central but no real platform team was dedicated to our app because Rider app is just an operating system. It's just so huge hundreds of engineers working on it, but you needed a team that's coordinating all that and so they offered for me to start that team. And so it was just kind of slipped right into it. I pulled over a bunch of my peers and I'd already been growing the respect of the team and working a lot of on the foundations of the app. I was working on architecture and foundational pieces anyway, so it was just a continuation what I was doing.
‍

David DeRemer:

Nice. That's awesome. Now let's talk about SoFi, right? When did you move to SoFi and I know you've undergone a similar massive scale effort there, a stepping up and sounds like more scale in the future. What got you over to SoFi? What was the work like when you started and how has it evolved?

‍

Phil Rabin:

Yeah, so after Uber I took some time off. I think it was well deserved 10 years of grinding it out. I think I was ready for a break, so I took about five months off and discovered something about myself that I actually got bored pretty quick and I wasn't really ready to retire and I was just seeing the AI boom starting to happen. I was like, "I got to get back on the field. It is too exciting. There's too much stuff happening. I'm not meant to be just a stay home guy on my phone or just even just going and playing outside." 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. The Rides organisation for example was a thousand people and we've probably had about a hundred mobile engineers and I was leading platform work for that, so I was looking for something maybe similar size or bigger or something that would become bigger and it just kind of threw myself out there and it was interviewing and networking and then the SoFi opportunity came around and it just checked all the boxes for me. It was like I had a laundry list of things that I was like to help me eliminate opportunities, too small of a company. I didn't really want to go back to startup. 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 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. Let's go from that intermediate size where getting out of the startup phase to big company, big code bases, large teams, I'd done that a couple of times at Uber on the Ride side and the Eat side, so I think I had to cut my teeth and understood some things about scale teams and so when SoFi came around, the growth story was really compelling. It's consumer brand, it's mobile first. The mobile first bank. We had kind of a nice product and then just as we were talking, I was talking to my director Kevin, or senior director, and he was talking about some of the needs to scale the team and scale the code base and that we really want to be a top 10 financial institution and build a financial super app. And I was like, this seems really exciting. This is a cool opportunity. So, I took it and I've been very happy.
‍

David DeRemer:

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

Phil Rabin:

Yeah, so when I think about scale, what worked for you as a small shop or a small code base starts to break down, that's typically what happens, right? You can build a product and a Ruby on Rails back end, for example, one database, one server and a web app on top. Great. That gets you started. What happens though when you have a million users or 10 million users, all those assumptions that you made about how many connections you can maintain or how big your database is getting, right? You start having to start your database, start producing microservices, those concepts, although mobile apps are a little bit different, but so those ideas you need to apply different types of thinking. So, what happens when you have a hundred or 200 people working at one code base at the same time? All those assumptions about your module structure and your build start to break down.
‍

Even things like indexing the code base start to fail. Your CI, right? Maybe you ran a couple nodes on your CI, now you've got potentially hundreds and hundreds of merge requests coming in a day, maybe 500,000. Your test runs starts slowing down and now you're starting getting a lot of engineers, I call them busy intersections start forming where you have potentially, you have your one big file that had 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. 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 we have to address those as we go through and start planning and making assumptions like, hey, we're at 110 engineers right now.
‍

We're probably going to have 200 by next year. What does that look like? You have to keep capacity planning and start looking at all of your pipelines and planning to try to speed up development time, speed up onboarding, speed up your CI runs and you're looking for efficiencies across your entire pipeline because really you're generating a giant code factory and that code has to go out every single week. So, the automation across every part of your stack was even just pushing code out becomes a big effort. Getting everything tested is a big effort. So, all those things need to scale up.
‍

David DeRemer:

So, that's super interesting because when you talk about problems of scale, and I know SoFi now is one of the largest 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 Flutter code base, which is a relatively new technology, maybe not as many engineers, maybe not as many best practises and standards and tools and things? Tell us a little bit about that experience.
‍

Phil Rabin:

So, when first of all, the decision to use Flutter was made before my 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 especially seeing at Uber, just the Herculean effort to get two apps out constantly and just the pipelines and just dealing with the feature set and trying to keep the feature set in sync with each other, having to hire, constantly be trying to keep our levels of engineers balanced because sometimes someone quits or leaves the company or whatever. We over hire in one area and now we've got three iOS and one Android or vice versa on a team, and now suddenly the iOS roadmap starts to accelerate ahead and the Android roadmap falls behind. What we saw also was an Android development usually just took longer.
‍

You just had the more devices to test against, there's more fragmentation, getting UI to be really look perfect. It was really, really difficult when you're supporting old versions of Android, newer things. Where on Flutter, I mean it's pixel perfect. I mean across all the devices we rarely have a device specific rendering issue. It's almost never. It's just not what happens because the render engine ships with the binary. So, we can have a lot of fine control over how layout works. And then coming into SoFi though, I mean we really were just a few years ago kind of like a startup. Most of the hirings happened in the past couple of years, and so the team maybe wasn't totally prepared for how quickly we grew. And so there really were the foundations in place for what I call an institution. We had a bunch of engineers writing code pretty much converting from Android and iOS engineering to Flutter engineering learning on the go.
‍

So, really didn't have a lot of training, so not really consistent practises and the information about how to do things the right way, it really wasn't published anywhere. So, as you start to scale, you really can't have a bottleneck. You don't want to have your team bottleneck on single engineers. When I first joined, I'm like, where do you get your information? I just surveyed people. I started talking around the organisation and they all pointed to one guy, they're like, that guy's got all the information in his head. So, it was kind of like a six-month effort to try to dump what was in his head into documentation. We had hundreds of pages of archive or out of date information that had to archive because it was confusing people.
‍

So, you got to think about really, really keeping your written documentation and what you want out of your engineers and your values and your principles, your coding guidelines and practises and process. All of that needs to be written. That's just like 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 word all the time. People are leaving, even if your head count's flat, you have to assume that maybe 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 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 in general, I'm thinking about creating a really resilient culture. So, it's kind of steering the culture away from just only moving fast, but towards quality, towards changing the values of the organisation, the mobile organisation as a whole, really focusing on testing, really focusing on good architecture, solid code reviewing, those things that you take for granted. Maybe some people care about it but other people don't. Some teams really aren't enforcing the practises. We all have to live in one code base, which is different than maybe backend services. You have these little microservices and you 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 practises because one code, one line of code can basically take down grep.
‍

So, we're really trying to enforce feature flagging. We've been having test coverage requirements and now bringing in new design systems, trying to get consistent UI. So, all those things you start bringing to the organisation, you don't get it for free. You got to build that stuff out and it's a lot of work to ramp up. And then once you invest in it though, then it's basically repeatable. You get consistent outcomes on every team. You should be able to go to every single part of the code base and it should look relatively the same. That's the long-term goal here that I shouldn't have one team doing really, really high quality work and the other team maybe slurring on the go and not necessarily knowing what they should be doing.
‍

David DeRemer:

I love that. Because I think so many people focus on the tools or the frameworks and they get these sort of religious wars around what type of framework to use or language or state management package or whatever it is. And I think so much of it is, yeah, 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?
‍

Phil Rabin:

Yeah, and I think that's why having it written in a central place means if 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, that's good, but at least we have a rule and we have some process and that anyone can point to. And what I found over time is one of my rules for my team was don't respond to a Slack message without a Wiki link. And that rule is really good, because it means am I responding with documentation or am I just kind of responding to this question? And if you respond with documentation, totally changes your posture. You'd be like, well, 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 300 line message, 300 messages in a row of people all arguing and talking about something. We 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 get answered again.
‍

David DeRemer:

And a big thing here has been scalability, this big part of your career, the things that you've learned and grown, and again, kind of putting the emphasis in places where we as people doing these things, we kind of focus on these false things to look at, which is like, oh, how fast did it compile? Or the API response was 50 milliseconds instead of 500 or whatever. But you've talked a lot about teams and I think so much of scale 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.
‍

Phil Rabin:

Absolutely. I'll 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? Is it understandable? Are we all on the same page? Are we working well together? Is the energy good? I think about just negative energy can really just suck, take the wind out of someone's sails, they become less productive, they don't want to come to work. It's a drag. So, it's really making sure that the morale continues to be high, that people stay focused, that they work well together, that there's even personal conflicts are weeded out early and that's usually improved with good clarity, with good process and systems and clear lines of ownership. You make sure that if you're the tech lead, that you're the final decision maker. So, I'm going to create a structure and make sure that hey, you're the director, responsible individual on this.
‍

I'm going to go to you for questions and if there's maybe an engineer or two working under you, I'm not going to undermine you and go to the person who's, call it, reporting to kind 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 is give people more confidence that they're doing the right thing, that they know who to talk to, that if there's a disagreement we can have a really clear chain of escalation. I think that's the stuff that can sink an engineering organisation. Again, the code, anyone can write code, you can go to a bootcamp and learn how to write code, especially the AI tools, just where we are cranking out code, that's usually not the bottleneck now.
‍

David DeRemer:

I know you're scaling and modernising a very large code base with a lot of people. You mentioned that you'll be hiring growing that team quite a bit, and I think your number of lines of code in one of our early conversations you're talking about that's growing on an increasingly accelerated path. Can you dig into that a little bit? Maybe give us how big is this at SoFi? How big is this application?
‍

Phil Rabin:

Yeah, so 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 and then we added about 500,000 lines just in the last quarter. So, we're looking at a pretty steep curve, AI tools and just the growth of the engineering team combined is starting to really make a steep increase. So, the current rate, if nothing changes, just our current rate will be around probably another doubling next year, but 400,000 lines of code, so just the weight of the code is starting to get heavy.
‍

You're dealing with even just switching branches and dealing with Codejet and dealing with indexing and builds are returning to we're trying to feel that drag and it's not going to get better unless you really invest in it. We've been throwing hardware at the problem just temporarily and I mean every single person in the entire company got brand new like M4 Maxs just because we were able to show some data that we can compile faster, we can just generally work faster. So, that was a no-brainer, but hardware can only take you so far before you start having to really start restructuring your code and doing more incremental builds, parallelization and being a little smarter with your resources.
‍

David DeRemer:

With all those lines of code, is that humans? Is that AI? What's driving that acceleration?
‍

Phil Rabin:

Yeah, I mean code is code, right? Some of it is code gen. A lot of it's unit tests. You think about unit test are probably like four or five or six to one of unit test code to application code, and then just your Cursor and Claude are cranking out a lot of code and it's not even that much code. If you think about 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, 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, that was over the course of a couple months. So, yeah, it's adding a lot of code faster, so that's something to deal with.
‍

David DeRemer:

Do you think that when you think about the scaling of code, both people and AI enablement that comes with that and the operational, has Flutter helped or hurt or just neutral relative to your past experience or other platforms?
‍

Phil Rabin:

For sure helped. I mean just having one language that we, one language, one framework, one code base to deal with means that we don't have to split our effort, be like, okay, here's all of our AI rules for iOS, here's all of our AI rules for Android. We get to really just as a new organisation, invest in one set of tools, one code base, one set of training, one best practise, everything. So, Flutter has made it just dead easy comparatively. I kind of cringe at now the thought of having to maintain two independent platform teams and two sets of code bases, everything, and then try to keep those in balance. Just be way more of a headache these days.
‍

David DeRemer:

And yet so many people are still doing it.
‍

Phil Rabin:

That's right. Yeah, yeah, they're invested, they're deep into it, but I think rewriting with AI tools now is also much easier.
‍

David DeRemer:

And do you have any concerns about scalability in terms of third party tools or anything about the engine or the framework that could keep up with that as you go forward?
‍

Phil Rabin:

I think what's hard with AI tools is just getting it to do the right thing, the hallucinations, just the correctness. We put a lot of effort into building up a lot of our markdown files with dos and don'ts, best practises to coax the agents to do the right thing. As your code-based scales Cursor, really you think about it, what the secret sauce of Cursor is [inaudible 00:27:04] 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 in the context window for an agent.
‍

So, you have to try to reduce the context window as much as possible and operate on small chunks of code. We've looked at some vendors that they claim they can work on much, much larger code bases, so there's some opportunity there for us, I think with the tool set to try to index the entire code base, there's some vendors out there, but generally that's the hard part with AI, it's just getting it to do the right thing. Really great at the function scope, but I seen say refactor all of my code base, you just can't do it. Not today at least.
‍

David DeRemer:

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

Phil Rabin:

For us next year ... The way that the app was set up was it followed Flutter best practises for the time and was probably a good layout. If you're dealing with a small app, you probably would've been fine. I mean I'm sure lots of small companies would never outgrow that, but most of the code is in one package. It's well organised within the directory structure itself into features, libraries, that kind of stuff. But it just means that that one package keeps growing and growing and growing and growing. So, we've actually started an effort, we call it internally, call it Project Athens, but it's a move to modularize the code base.
‍

So, extracting features, extracting libraries, having service packages and networking packages, trying to organise this app and then bringing in Riverpod. So, we did an analysis of all sorts of different architectures. We had a working group that was 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 real dependency management. I think we wanted to use the providers, we wanted to have scopes and actual structures and we wanted to be able to do dependency inversion for the packages and then actually have 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, 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 really big code base.
‍

So, we end up with things like flaky unit tests. Unit shouldn't be flaky, they're only flaky if you're mixing state globally. And we try to shard our test runs across a lot of different instances because they're starting to slow down. And what happens is that when you're running your test and you made some assumptions about global state and you run it on your machine, sure it works. Then suddenly when you start sharding and that global state actually gets mutated or you have synchronisation issues, now you've got tests that are doing weird behaviours. So, we're trying to get away from that and move towards a 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 here, haven't you vended from the call it components or DI graph?
‍

David DeRemer:

That's super cool. Hopefully as you guys land on that and get some best practise 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 some point in Flutter's evolution, we're starting to see companies achieve that or get to that need, and I think that's sort of this uncharted territory of best practises and opportunities.
‍

Phil Rabin:

Yeah, we did it at Uber in the early days. The first version of the app suffer the exact same fate. I mean I've seen this and say we've been around the block a few times where we had one package and the builds and we had a similar growth story, but we're plugging up more engineers working on one app than we did even at Uber on the Rides app and we saw the packages in the build times just to try to explode and grow and then we ended up trying to do it while we were running the app. That was quite difficult.
‍

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 a couple hundred modules per app, so no stranger to large architectures. I mean you can get to a certain size and that becomes a problem unto itself. Your tool chain starts to break down even at certain scale. I don't think we're going to hit that scaling problem for a while if we start modularizing the app correctly, I would assume we'd probably end up with probably 20 or 30 packages by next year, which just totally maintainable.
‍

David DeRemer:

Right. One of the things, there's this idea of Conway's Law, which is the shape of your product starts to mimic the shape of your team. I'm curious how your team is organised and how you deploy people within the organisation, especially since you are doing Flutter, where the most natural first cut is like iOS or Android, you don't really have that problem and potentially as you have multiple apps running Flutter, people become pretty fungible. What is the sort of organisational structure you guys are pursuing or might look to move to in the future?
‍

Phil Rabin:

We follow a matrix organisation, much like a lot of bigger companies, business units or business verticals and all those business verticals are going to be building their own features and then committing code to the one trunk essentially of the code base. We use feature flagging a lot to enable that so that we don't necessarily have teams breaking other teams code as they're rolling out these features. Then we have a big platform team I think right now with contractors and probably you had 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 them. So, I think 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 [inaudible 00:33:24], onboard new users, I mean, you should be experimental.
‍

You should be able to slap together a UI quickly like Legos, get it out there, try it out, doesn't work, shut it down, we'll try again. That's what we want to see out of product teams, but you've got to provide the tooling to unlock that. So, you really absolute need to have really talented, usually far more senior level. I've got a lot of staff engineers. I work with principal engineer, so I try to skew the seniority of the platform teams to far more senior people have worked on big apps, worked in big teams and understand how to scale stuff.
‍

David DeRemer:

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

Phil Rabin:

Yeah, I mean generally I really like the principle of radical candour where you're, you care deeply, you're giving them a lot of feedback and I like to be 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're kind of out of your comfort zone. You're kind of in that state of flow where you're not pushed so far off the deep end. You don't know how to swim. Maybe the waves come crashing down on you. We'd rather have you do this on that edge where you're learning, you're growing, you're working towards the next level or constantly checking in, making sure that you are moving in the right direction.
‍

I really don't want to have people be stagnant just hanging out in their level for 10 years, whatever. I'd rather have people always be working towards the next level, strong encouragement that we're working towards that next promotion, figuring out 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 to really, they think that, "Hey, this person believes in me, there's a path to move forward. I'm given those opportunities. I can step up and grow into that opportunity." I think that's motivating and exciting for people and they get motivated to come work. Because they know that there's a path for them to grow, and I think every single person on the team should be given that opportunity.
‍

David DeRemer:

That's amazing. That's wonderful. That's great, great leadership advice. One final question about Flutter specifically. Obviously given our role in BGV and being 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, native seems the pure way to do it?" Given that you've seen both, I mean you have I think a very credible and 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 evaluating that decision?
‍

Phil Rabin:

I mean, it's never been easy to learn new stuff. Even most engineers that we hire are Android and iOS because it's actually very hard to find 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, 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. You'd be surprised, even web developers because Dart is pretty much JavaScript anyway, and the documentation out there is great, but also Cursor in the agent is conversational. You can be like, teach me stuff. So, I feel like a lot of engineers with Cursor have been learning.
‍

There's a back and forth with the agents, kind like a coach. We're hoping to invest in that more. We'd like to see more coaching come out of the agents, but for anyone who's interested, I mean, pick it up. Just get your hands on it. Get your hands dirty. Try to get an app out there. If your friends have a business or a band or something, you try to build something. That's how it always happens. And then maybe build up a portfolio, but also assume that we tend to hire folks with mobile experience, not necessarily Flutter experience. So, don't be shy to apply if you don't have Flutter experience, because we'll give you the time that you can learn, and we've got an awesome community of support, lots of support to help people out.
‍

David DeRemer:

Super important insight. We hear from a lot of enterprise companies sort of this concern about can I hire senior level expert Flutter engineers? Well, it's really only been around for seven years 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 harder I think to 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.
‍

Phil Rabin:

And I think also you have to consider 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 pick a new framework, you could pick up a new language, you could learn a new language in a week or two. It's usually not that hard once you've been coding for a while. The skills that are hard to acquire are things like organisational skills, good communication, teamwork, project management, deeper understanding of architecture of people who can interview other engineers, those types of skills.
‍

Can you grow, can you mentor others? All those soft skills are actually what are probably the most valuable, and that the coding part, yeah, people can learn how to code, but for a staff level engineer, principal engineer, we're talking 10, 15 years of experience of working in software. And for most engineers, software is going to come and go. Different frameworks are coming and going constantly. So, usually you have to retool every 3, 4, 5 years anyway. So, I think it's just part of the course for anyone who's been in the biz a long time.
‍

David DeRemer:

That's great. One more question for you just to wrap us up.
‍

Phil Rabin:

Sure.
‍

David DeRemer:

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

Phil Rabin:

Yeah, I think I wrote this down just in preparation. This is one of my mantras, and I think this would be if I was writing a book on leadership or business, it would be just called Treating People Right, and then How to Motivate Teams without Burning Out. 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 harder things where you're not aligned that burn you out. You're not really excited about the work, you're grinding. This is just day in, day out of doing things you don't want to do. But if it's exciting, you've 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 you're having fun and you're shipping things and 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 come to work and want to work harder for you.
‍

David DeRemer:

I love that. Well, thanks so much, Phil. Really appreciate you taking some time out of your busy day. I know you got a lot of people that you're accountable to and not to mention customers and leadership, so I really appreciate this. I mean, the SoFi app has been, I think, a real inspiration to a lot of people out there just seeing what you guys have accomplished, hearing those stats about how many engineers, number of lines of code, and the rapidly accelerating pace of that 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. And so it's just been great to see your story, and I just really appreciate you coming on here today.
‍

Phil Rabin:

Cool. Pleasure was all mine. Thank you so much for having me.
‍

David DeRemer:

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

Phil Rabin:

Absolutely, sofi.com and yeah, we've got a jobs page. We're definitely hiring, and we'd love to have folks who have Flutter experience or just mobile experience in general.
‍

David DeRemer:

Amazing. Well, thanks so much. Really appreciate your time.
‍

Phil Rabin:

Thank you.
‍

David DeRemer:

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 and see you next time.

‍