BUILD

SUCCEED

David DeRemer: [00:00:00] Alright. Hi, Sam. How's it going? Thanks for joining you today.

Sam Moore: Hi, David. I'm doing great. How are you?

David DeRemer: I'm doing terrific. Uh, yeah. Thanks again for, for coming on the show. And, um, I wanted to start with just a general, I, I know you've a recent dad, moved to the suburbs. Um, just curious how that's been going. Uh, how, how's it being a dad and how's it changed things for you?

Sam Moore: Oh, yeah. Yeah. Uh, it's, uh, it's been great. I mean, it's, it's fun. It's, uh, it's challenging. It puts things in perspective. Um, I, I think, Making it through the early stages of being a parent has definitely put, uh, put like what difficulty is into perspective. Um, which is actually, you know, it's kind of great because we face a lot of challenges in the work that we do and it's, it's, it's easy to get lost and like, Oh my God, how am I ever going to figure this out?

And, you know, when you face those challenges with like taking care of a new loved one, it's, uh, it's, uh, it's a totally different ball game. So it's fun though. Love it.

David DeRemer: Totally agree. I think it definitely, uh, impacts how you are a [00:01:00] manager and how you show up at work. Not only cause you're tired,

but, 

Sam Moore: never been more tired in my life.

David DeRemer: Yeah, yeah, absolutely. Um, has it changed, uh, how you've been a manager, like as a leader?

Sam Moore: Yeah, I would say it has. I mean, uh, I think You know, once my brain started working again after not getting sleep for, for a long time, as is often people's experience, you know, my, my background processes and, and started, started crunching the information I was collecting and immediately seeing the relationship between, like, just like the psychology of, of children, infants, uh, toddlers, uh, and, and, you know, full grown, uh, you know, adult humans, uh, and just, like, It's so hard not to see the similarities in the work that I'm doing.

I think a lot, I've always, I've always had a strong Affinity for kind of coaching and like asking questions and like trying to be a sounding board for people. Um, and I've always appreciated that kind of interaction with [00:02:00] other people and it ends up, you know, my, my daughter's two and a half years old now, so she's firmly in the toddler stage and, uh, there is just so much overlap there, right?

It's like, you can't just tell them what to do. You have to like, get them to think about what's going on. And kind of guide them through things by asking questions and leading them. There's, you know, things about learning about setting boundaries and like what boundaries actually are. And they're like not things that you tell people not to do, but rather like won't let them do.

Um, and so yeah, there's, there's a lot of overlap. There's definitely a lot of overlap to how it, how it comes into the workplace.

David DeRemer: Totally. In my, in my experience as a parent, it's been one of the cool things is to, um, learn things again,

right. To like, um, see, uh, somebody learn something new that I think as we grow, right, our, our. Our minds get these layers of learning and we just kind of jump ahead to all these conclusions. And, um, it's just so fun to watch like a kid growing and learning to like learn something brand new that like literally their brain has never learned before.

And [00:03:00] then you see it like when you do something cool and new and different, like at work or as an adult, and you're like, Oh, beneath all these layers I built over my life, there's still that like very raw, like, Just learn something new and that like what enthusiasm you get from that is super cool. I think just kids like really distill some of those basic like human mentality, uh, aspects.

It's pretty cool.

Sam Moore: Yeah. Yeah. It definitely just sort of like boils things down to their essence, right? You just see things for like what they are from, from first principles, right? Like as a human learning a thing. Um, it's, it's pretty fascinating. Um, it also, uh, as you know, having, having kids, like, uh, just having a reminder of, You know, how much patience it takes to, to sort of collaborate with somebody, or cooperate, or get them to cooperate, uhm, and, uh, how, having, being a parent, it's like a good reminder of, uh, you know, how to, how to maintain that, and how to know, like, when you're at the extent of your, of your patience, and, and [00:04:00] processing your own feelings.

Right. I think that's, that's like a reminder that's, that's actually been really rewarding for me is like, it's been easier to think about like, okay, I'm feeling frustrated in work right now. Right. Or I'm feeling really excited about this thing. Um, because there are things I'm trying to teach my kid.

Right. And I'm trying to be like, oh yeah, that's what that feeling is. Okay. Let me help myself process that. Um, which is, it's fascinating just like being a, uh, I don't know, a stronger human on like the, on the, you know, emotional and cognitive

David DeRemer: yeah, that's really true. Like we spent so much time teaching our kids to like be in touch with their feelings,

but then as adults, it's like, no, no, no, no. Ignore those, ignore 

Sam Moore: Right, exactly, exactly.

David DeRemer: Yeah. Well, I mean, we've established that you're a parent and it sounds like a pretty good one. Um, so why don't we take a step back and do you want to just introduce yourself and tell us a little bit about, um, who you are and your, your experience and, uh, kind of kick us off maybe why we're here today.

Sam Moore: Yeah, yeah. So I'm Sam Moore, VP of Architecture at Betterment. I've worked at Betterment for a little over 11 years at this point. I work [00:05:00] as an engineer. I, I spent most of my career and most of my time at Betterment as an individual contributor, working on Primarily sort of full stack, sort of front end to back end to the database, um, uh, product functionality.

Uh, I've worked sort of in the background on our trading systems, uh, our, our, uh, our, you know, front end, uh, infrastructure, our, uh, AWS cloud infrastructure, um, and, you know, the way that I came to meet you, uh, was a, was a jaunt that I did into working on our mobile, uh, platform. But before Betterment, I worked a few different places doing similar work in engineering, web development, I kind of came up into software through the, the, you know, web development age.

And so I lived through a lot of the bad old days of web development, saw the early emergence of mobile development, and have, you know, tried to [00:06:00] find interesting ways to bring that experience and that knowledge to bear on the problems that we're trying to solve in our business.

David DeRemer: That's awesome. And sorry if you saw that weird facial expression. It's the first time I've ever had to like sneeze, uh, in the middle of the podcast. And I was like, ah, and then it didn't even happen. It was very weird,

but at any 

Sam Moore: was thinking about that before. I was like, I need to figure out how to

David DeRemer: know. Like a dump button, you know? Yeah. Um, well that's what I was doing.

It didn't work. And then like, I was so busy messing with the mic mute that the sneeze didn't

Sam Moore: You scared the sneeze away. You're like, get out of 

David DeRemer: Yeah. My brain muted it automatically. Um, yeah, no. And, and you're right. Like, I think, um, you mentioned that how we got to know each other was the, the mobile project and replatforming to Flutter and.

Um, that was a big undertaking and also quite early in that. And I think you, you specifically and leading this for Betterment, Betterment, of course, uh, as part of it was kind of pioneers, I think, of, of Flutter in the ecosystem. Uh, you guys got into it really, really early and embarked on a very large undertaking, I think.

Um, so I was just curious if maybe like, you know, [00:07:00] tell us some of that, like, how did that happen and, you know, what have we learned? And I think that's going to be the bulk of our conversation today is like, How do we, how do we effectively transform technology? But to take us back, do you want to kind of over give it over you maybe of Betterment's technology stack or like what kind of led you to that moment?

Hmm.

Sam Moore: Like I'll say a quick thing about Betterment. So Betterment is the largest independent digital financial advisor. Um, we operate in the United States, uh, exclusively. Um, Our product is sort of an advice, an advice and investing platform that's offered in three different flavors.

Uh, we do like a direct to consumer thing, that's kind of what OG, original Betterment was, sort of on Betterment. com, uh, and our mobile app. Uh, the second piece of it is, uh, What's called Betterment at Work. It's a product that we sell to employers to provide benefits to their employees. So it's like a 401k and other sort of suite of benefits that they can use through our same sort of great mobile experience [00:08:00] that the consumer product delivers.

And the last is this like advisor platform that we offer to financial advisors to be able to manage their clients using our software. And it's like a full custodial platform for them. So, you know, that's, that's kind of how Betterment exists in the world. It's a, like a, you know, U. S. centered, uh, financial services company.

Uh, and as I said, we have, uh, a web platform and a mobile platform and multiple different web presences. Uh, so that has informed, you know, a lot of our technology strategy, how we pick technology, how we. You know, scale our team, uh, and we've always put a heavy focus on, uh, I guess I'd call it like consensus, but also like alignment and trying to sort of, uh, leveraged shared technology in all the things that we build, uh, to the extent that it makes sense.

So having like fewer different ways to do the same thing is like a, is a value or a principle that [00:09:00] we have. Um, and so, you know, when I started at Betterment, our technology stack was, well, we didn't have a mobile app at the time, and our technology stack was Java, uh, written mostly by our CEO, who wasn't an engineer, uh, and, uh, a bunch of JavaScript for our web experience.

Uh, and, and, you know, in the time that I've been here, we've then evolved that and grown, grown the team from, you know, five engineers to 150 engineers. And that's sort of necessitated, uh, taking new approaches to the different technology and has really demanded that we figure out how to adopt technology that works.

Well for us and the needs of our company as those needs have changed. One of the biggest ones that we undertook was actually transitioning from our monolithic java backend system to a Ruby on Rails set of applications. Which is like, sometimes we joke about it's like the the anti Twitter like Twitter's infamously moved from Ruby on Rails to like Java and Scala.

And we kind of like, did the reverse. [00:10:00] Um, we might actually be moving in the other direction again now, but, you know, years ago the priorities were very much clear that, like, we need to be able to build stuff and throw it away, right? And, like, doing that with, like, rigid strategies and, like, kind of crusty old techniques wasn't working well for us.

So we, uh, You know, pioneered an adoption strategy there. We also got rid of our cruddy JavaScript strategy and, you know, eventually started embracing a new one. So we have this, like, uh, in our DNA, right? Like, finding the way to adopt technology that's sort of, like, the minimum amount of, of technology to, to be able to deliver great products for our customers.

Um, and transitioning from one technology strategy to another,

David DeRemer: And I

think crucially for you guys specifically, I mean, I think what you're just describing there in that counterpoint to Java to Ruby or back or whatever, you know, different things. There's no one way different companies have different, uh, uh, benefits, requirements, things that they want to do. And I think that's just an important part of it.

And I think that [00:11:00] as you and I've talked and learned about your approach, it's not just about which technology is better. It's really like for our culture, for our team, for our unique objectives, not like what I read on Reddit as the top post of the thing I should be using. Um, it's really thoughtful, mindful approach to what works for you and your team.

Sam Moore: Yeah, absolutely. Like decisions are made in context and like, uh, we, we can't pretend like Facebook, Meta, uh, Google, Amazon. VGV, Betterment, like we're all the same context, right? Like we're not, we, we have different needs, right? Like I was at a conference recently talking to somebody and they were like, how do I get my team to work on more platform investments or something?

I was like, I can't answer that question abstractly, right? Like what is your business? What stage is your business at? What's your current technology strategy? Like, how does it work, right? Those are all the things that factor in. Cause yeah, the right answer for one person or one group of people is not going to be the same for everyone else.

David DeRemer: Totally.

Sam Moore: That doesn't mean we can't learn from each [00:12:00] other. Uh, it just means that like, learning isn't about just reapplying the same strategy, right? It's about like, well, what, why did it work and why didn't it work?

David DeRemer: right, right. And, and part of it is evolving. You know, I think most of the product stories that you read on the internet or that people celebrate, they tend to be like some bright, new, shiny company or thing that was built. But the real situation for most engineering teams out there, especially if a company has been around for a reasonable amount of time, is you're maintaining a lot of stuff that have been built over time, and you're trying to pivot your technology strategy and update things as you go.

And I think that that's a lot of the stories that you and I have talked about over the years are really interesting, right? Um, so many companies have these like impediments to their organization. And technology gets in the way. Technology debt is a very common phrase for that. Um, and rebuilding or adjusting or adapting is really, really hard.

It's really hard to get like the executive buy in, the motivation. Um, and one of the things that I think has just been really cool about the Betterment story [00:13:00] and the things that you've told me about Is that you guys have been pretty successful, I would say, at pulling off these migrations, like moving from one thing to another and just this really mindful approach.

And the one that I know best is the migration from two native apps, iOS and Android to a Flutter app and all of the complexity around that. And how do you do that without pausing your business for a year or two while you're doing that right. . Um, so how, how did you do that? You know, getting into that, like, like maybe, maybe double clicking on that one specifically and then I know we can expand that to some o of the other projects you guys have been working on.

You know, where was Betterment at the time? What problems were you facing and what led you to sort of embark on that path and feel like we have to do something to change something for our team.

Sam Moore: Yeah. Uh, I love the setup. I mean, I think it's, it's really, uh, the context for us is like, we, it was like late 2019 and we were thinking about 2020 strategy. Uh, if only we knew there was a pandemic coming. That's like a fun thing that we could also talk [00:14:00] about what we did when that happened. Because it was also right when we were really getting into it with you guys.

David DeRemer: Right. Right.

Sam Moore: But it was late 2019 and we were thinking about 2020 strategy and we really wanted to figure out how to make like mobile first feature development and product delivery like our focus for our consumer product line. And the reason for that was that. We, uh, to that, to that point, we had mobile apps, native Android and iOS apps.

They were 20, let's say 2020, like, I think we built them in 2013 originally, so they were like seven year old codebases, um, which, you know, not that that means that they're bad, but they had seen a lot of, uh, they'd seen a lot of years and had a bunch of road miles on them. Um, they weren't the best, in the best state, um, and even so, the, the applications themselves on mobile weren't doing as much as we wanted them to do.

They were, we kind of categorized them as like a companion app. Like, we never really wanted it to be that way, but that was really what [00:15:00] materialized in terms of like how much we ended up investing in them. They could do the basics of what our product wanted to do. They could sign people up and, and you know, they could do what they needed to do for the most part.

But every time we built new, really cool, groundbreaking features in our space, that was like mostly on web. Right. Um, and, uh, a lot of that. Kind of, it was, it was almost like a self fulfilling, like we weren't investing in it as much, uh, on mobile, uh, and then when we wanted to, it was like, well, You're going to need to invest a lot to get a little because the codebases had kind of developed these warts, right?

We kind of had, somebody introduced me on the team to this concept they'd coined for it or heard called lava layers. Where like, you kind of have this eruption of an interesting idea that you kind of like start to push through the codebase to how to do things differently and presumably better in the way that you build your features.

And like, but you don't quite get there. And so it just kind of like, pardons on top [00:16:00] of the other ways that you were doing things previously. And you have like several of these eruptions over time and now your codebase is this like smattering of layers of different strategies of doing things that like no consistency exists really between building features and it makes everything go slower.

So anyway, that's more of where we were and where we wanted to be, right? Uh, and so we looked at the code bases and we kind of asked ourselves, like, how will we move as fast as our business wants us to move? Uh, Next year, uh, if we don't do something drastic. And so, like, naturally we have a bunch, uh, uh, a decent, you know, sized team of, of mobile people doing native Android and native iOS, uh, and they all have super strong opinions about, like, how they would do it differently now if they could start over.

And then we started to grapple with, like, well, big bang rewrites are bad. Um, There's a lot of, like, business cases and technical cases for where they usually don't pan out. Um, And usually the better [00:17:00] strategy that, that, that we've also learned internally from our transformations has been one of, like, an iterative, sort of, like, wrap the thing that you've got in something new.

And, like, gradually transition your functionality so that you can, like, new stuff is, you know, is new, and old stuff is old, and like, you can, you can find the transitionary path there. Uh, and, uh, that then had us say, like, well, what about cross platform? Like, that's a thing that's growing. Like, React Native had been through, like, many hype cycles at the time, uh, and, and was sort of on an upswing.

Flutter had, had been emerging as, like, This isn't like a toy idea. This is like a real thing that people are using to do stuff. BMW had started using it. There were tons of international companies that were using it extensively to build like their entire mobile strategy. So, in wanting to meet customers where they're at and recognizing our technology was, was, uh, Behind where we wanted it to be.

We opened the door and said like, okay, what [00:18:00] are the cross platform options? If we're going to do an iterative rebuild, like, can we do an iterative rebuild that doesn't require us to build two new things? Can we build one new thing? Uh, and you know, that's, that's what opened the door. We looked at Kotlin multi platform.

We looked at React Native. Um, we looked at Flutter, uh, and. We decided we needed, we wanted to do one of them. Uh, and we ended up picking Flutter for a lot of reasons. Uh, we had kind of put together some evaluation criteria, Um, really early, rough, like kind of exploratory stuff. Uh, and, and one of the key things that made Flutter stand out was that it, had the ability, I think it was like, other than React Native, a Kotlin multi platform didn't do this at the time.

It had the ability to be like an integrated thing. So you were going to build not just like the business logic of your user experience and, uh, you know, the core interesting stuff, but also the UI. And that was all going to be done like once for both or multiple platforms. Whereas like Kotlin multi platform, it was like, hey, share, [00:19:00] Share the business logic, but like build the UIs yourselves, which isn't, isn't a bad strategy for some.

It was just not a good fit for us. And, you know, we had tried React Native a few years before and kind of had a bad taste in our mouths. And so we were apprehensive about going in that direction again. And then we started using Flutter a little bit more and like the Bye. Bye. IDE experience was really good.

It worked with like tools people are already familiar with. Um, it was easy to install and get started. It's like hard to under value how important those things are when you're making like a monumental decision to just like change your engines out of your plane while you're flying. Uh, like the, the foundational bits need to be really good and they, they were with Flutter.

So that's a lot of our stuff. And I, you know, I think, uh, we'll talk about more of it in detail.

David DeRemer: yeah. I remember early on, um, you guys were just very methodical around evaluating the things that would matter to your team. You know, and I think a [00:20:00] lot of these new technologies, there's a lot of hype around them and there's plenty of people that will like, tell you they're awesome. Oh, you're going to love it.

And then there's plenty of people that are like, no serious engineering team would ever use that, you know? Um, and so that sort of like discussion that's out there in the world is like, you, you have to really evaluate it yourself and really define the criteria, um, and the process for how you're going to go about doing that.

And I just thought that. I remember observing that in real time as, as you guys were thinking it through. It wasn't like, this is like, Nope, we're gonna do this and we're gonna go to trial. I was like, what is a sequential process we're gonna go through to really clarify what we wanna learn and validate that?

Like, is that hype true? Like, okay, like, like, um, hot re hot reload for flutter. Like, is that actually really a big, like productivity boost or is it just something that's cool that everyone talks about, you know? Yeah. So

Sam Moore: Because if I was going to sell it, I would definitely talk about that. Uh, but if I'm using it, is that a thing that actually makes a difference to me? And like, yeah, in reality, that was the, those were the [00:21:00] things that stood out to us. It's like, wow, that works really well. That does make a big difference in our development experience.

David DeRemer: In terms of, like, I know it was a long time ago now, it's kind of wild to think about, right? Um, you're more than halfway from how old that app was when you decided to redo the native ones. Um, were there some, just, you know, kind of getting back to that moment, were there some things you saw in that codebase, uh, that were, like, really clear signs to you?

Or, like, what were the symptoms for you, besides the sort of strategy of becoming more mobile first? That like something was just like, not something was wrong that merits this sort of investment. Right. Cause I think you guys saw that. You're like, okay, we need to be more mobile first. We're lagging behind on features, but, you know, doing this is not a, it's a non trivial investment and it requires a lot of alignment where there are like some really obvious, like things that were just like failing the smell test that you guys were like, Oh, this is just not going to be scalable long run.

Like, how do you make that call? Hmm.

Sam Moore: well, it's really interesting. I wasn't [00:22:00] working on mobile at the time when I was asked to sort of get involved in this. I think my role was like principal engineer. I was maybe like one of two principal engineers at the company and having specialized a lot in like front end and full stack development. I had a lot of familiarity with our mobile stuff, but hadn't really worked in it.

And. So when I was getting involved in, in kind of the, the, from the business and technology angle at like wanting to do more mobile stuff, I needed to close my knowledge gaps as best I could. And so I went and interviewed like the, there were like 20 engineers on our team doing mobile stuff at the time.

I think I went in like one on one for like 45 minutes with every single one of them and just kind of talked about like, Hey, we want to do this. Like, here's what the business wants to do. Like, How? Like, what do you think? Can we do that? Like, what's gonna slow us down? Like, what do we need to fix? Um, how long do you think that's gonna take?

Right? And like, just asking those kind of questions and like, engaging people in that process of recognizing that like, [00:23:00] People outside of just, like, the grunts on the ground doing the work recognize that, like, things aren't the way that they need to be for people to be successful, um, and we will need to fix some of that, um, and, like, that, those conversations produced, like, so much information, right?

It was just, like, going to the people and being, like, what would you fix if you could do it, right? What would you not do the same way? And they were just, like Laundry lists of things. Um, that's where I got, I learned about that concept of lava layers and that, that kind of impression of the code base. Uh, so things that stood out, like on Android, we were using like the MV, uh, VM pattern, the MVP pattern, uh, two different versions of a different MVP pattern and, you know, those like architecture strategies and those are like, pretty clear signs that like the application is not holistically designed, right?

And like, it doesn't have to be. You could be a successful company with a successful product that's like a mess on the inside of the software. Um, [00:24:00] but like, you certainly don't want to be that way. Uh, I mean, you want to be successful, uh, but, but you don't want your code base to be in that state because it, it does slow you down.

It keeps you from, from onboarding new people because they don't know which way to do a thing. They gotta ask somebody, right? So there are a lot of those things. There was a lot of, like, tribal knowledge where, like, you would have to ask somebody to say, like, I'm building a new feature. Which of these four different strategies should I be using to do that?

So, you know, things like that that really immediately are, like, red flags to me with when I think about architecture and, like, an architecture of software is, like, ability to keep you at pace, right? Um, They don't always have to be like bending curves as much as that just needs to be like this architecture is like ready to evolve.

It has space for new functionality to be introduced. It is like tolerant to change that needs to be made to the, to the code base, to the product. Um, and there were just a lot of those flags that were, that were not, uh, not in a good [00:25:00] spot.

David DeRemer: Yeah, it almost sounds like, um, there's more efforts to figure out how to architect and implement a feature than to actually do it, than like, what does the feature do, you know?

Sam Moore: exactly. Yeah. And, you know, you contrast that to, to good things that you have experience with and it's like very obvious, right. But what we're saying.

David DeRemer: No, I was just gonna say, I think someone on the team told me that like one of the apps had a local database, one of them didn't, something like that. You were doing like,

so 

Sam Moore: yeah, Android had a local database. iOS didn't. Yeah.

David DeRemer: Yeah, and any new thing, you gotta like, not only figure out how does the feature work and define it, but you then have to like, put it through its paces of understanding like, okay, how do we actually like, make it work for this one?

And, you know, mobile in particular, I think why there's always been this push for cross or multi platform solutions is because, you know, You know, you're trying to get the same product into your user's pocket. It's just that there's two of them. There's Android and there's iOS. And you gotta be on both, you know?

Thank God Windows Phone failed, because imagine if we had three, you know?

Sam Moore: Yeah. Yeah. Yeah, totally. Uh, Windows Phone and, and Palm [00:26:00] WebOS and all the other ones that have floated out there for, for the years. But yeah, it's, it's been. It's been great. It's been wild to see those things come and go and see what's stuck around. And yeah, then having to build and support them, it's tough because usually it's not the same people either, right?

People specialize across the industry. There's, you know, there are plenty of people who like can hack it on multiple mobile development platforms, but certainly most people don't make their bread and butter on both platforms. They work on one. Um, and they, they have, you know, those platforms, even when they're done well, don't, always agree on the way to build things architecturally.

They, the platforms don't even agree in their, their concepts or semantics on exactly how things should work, which makes cross platform things challenging too sometimes. Uh, but certainly like when you're doing native, you got two lead engineers on, on the project, right? Because you got to figure out how you're going to build it on Android and then you can build it on iOS and they got to talk to each other and as.

Divergent as those architectures are, um, the strategies look different. The [00:27:00] asks look different. Like, oh, well, we want this A. P. I. We want that A. P. I. It's like, well, it starts to multiply the amount of effort. Um, however, you need like extra specialized people. Like you need to hire people who know how to do both, which is even harder.

David DeRemer: And it's not just limited to the engineering team. It's the product management team, the marketing team. Cause things are different. The QA team, the build trains, like everything that like all that complexity scales, like I've often thought about there's this, um, graphic, right. Of like the complexity of communication chains.

Like if you have two nodes, it's one line. If you have three, it's a triangle. If you had four, you know, all of a sudden it's a box with an X in the middle and like when it's just those lines just get out of control. And I often think about that as like. Team as you add more people to your team. But then what happens when every single one of those dots on that thing is actually a, a team of people as well.

Right. And now you've got like 64 teams. Hey, um, it's just, uh, it gets real. So I, I have often thought like part of this is just reduction of complexity of people collaborating [00:28:00] is a huge benefit, you know,

of, of all 

Sam Moore: Yeah, And speak in the same language, right? It's the same I was saying earlier, right? Like we think about how do we have fewer technology stacks to build our stuff, right? Uh, if we had Java and Scala and NET and Ruby and Python, like we got to be good at all those things. And then those people need to work with each other and they don't necessarily use the same terms, right?

So the, the, the fewer of those things you can have, It's the same thing. The communication overhead goes down. Um, The more transferable people are, the more they can like move from one space to the other. The bigger business impact an individual or a team can have because they can maybe move around a little bit more through the, through the things that they're working on.

David DeRemer: Yeah.

Sam Moore: So there's a lot of advantages.

David DeRemer: So you identify these opportunities and, um, just want to highlight what you said before, too, I think, which is just super brilliant that some people should take away is, is when you identify these things that are kind of smelling funny and you're heading these impediments and you're frustrated, why don't we ship faster?

Or, you know, why does it take six [00:29:00] months to change a logo or something like that? To actually go down and like, do the, do the research to like, talk to the team, like just go down and do that to generate insight. Um, I think that's probably something that a lot of people higher up in chains probably aren't doing as much, like going down and actually talking to the people who are living it every day, cause that's where you're getting those insights, those level layer problems.

And you might see the symptoms like, or the problems in the organization, but getting lower level. I mean, insight and doing that, uh, sort of user research of the team is super, super valuable. So how, how did you then, like once you sort of identified that there was this problem and maybe this opportunity, how did you get organizational buy in?

Right. I mean, obviously it's, you can point to these problems, but I think sometimes they're very, um, vague, right. In scope or scale, it's hard to quantify like, okay, how much productivity are we losing every year? To teams just coordinating, right? Or, um, those sorts of impacts, but what probably you can look at very closely [00:30:00] is, well, we're going to need.

To train the team. We're going to need to invest in this new thing. We're going to have to like hire new engineers. Like those are things that I think most businesses are much better at planning is like into the future. Like, what is this going to cost in terms of headcount time and everything else? Um, so how did you like go about getting the organizational buy in to embark on something as significant of this as

Sam Moore: Yeah, well, it certainly helped that the business saw this sort of, this desire to be building features mobile first, like meeting our customers where they were, right? They had, I don't have the exact numbers off on the top of my head, but, um, we, we found that like the vast majority of our customers were using our mobile product for their, their majority of their interactions with us.

And it was like a vastly you know, narrower experience than what you could do on web. And, you know, many things in our mobile product would sort of say like, hey, go do this on web. And that worked for people, right? I mean, like, I think [00:31:00] finance was always kind of this thing that people were, um, more inclined to do on a, on a computer, a full computer, you know, big screens for big problems or something like that.

Uh, but, um, but because so many more people were using it on mobile, like the business had an appetite for a solution. That was going to be better than when they could, we could look backward, right? And say like, well, how long did it take us to do feature X on mobile? And like, that was a good, we, that was, that's when we said it was going really well, right?

And like, that took, three months. And like, we want to do like 10 of those features next year, and there aren't 30 months in a year, so we're going to have a bad time. Uh, how can we do something differently? And like, what would it cost us? Right? And so then it becomes like a, a, a, you know, a kind of classic business case of like return on investment.

Like, what's the investment? Uh, how quickly will we get the return? Um, and you know, [00:32:00] will, you know, how risky is this, right? Are we going to be successful or is this going to be, uh, an investment that flops or something like that? Uh, so we were able to draw on like past experiences. So I, I think I mentioned we, we had kind of a heritage of doing some transformational changes on our technology and, and kind of seeing the benefits, um, and had like some You know, rough guidance for how long various things would take.

Um, and we had started to develop, uh, at the time, like, uh, a framework for thinking about these things. Um, now we kind of refer to it as like the life cycle of a tech investment. We got to come up with like a cute name for it. Um, but, you know, maybe expect that if I ever write a blog post about it. Um, but, you know, we say like the life cycle of tech investment or of a tech investment and sort of framing it up to the business, uh, And the people working on it as like, there's four phases.

There's like exploration, uh, and between each phase there's like a decision, right? So there's like exploration, and then you decide, are we going to go to the next phase, or are we done? [00:33:00] Uh, then there's like a pilot, uh, then there's an adoption phase, and then there's like a cleanup phase. And sort of along the way, you're, you're like getting more information.

Um, I have this like poorly formed expression that I, or adage that I've, I've coined and people I work with of like, well, you, you never know less than when you start your project. Like, as soon as you work on anything on a project, like whatever the first step is, you learn something new. Uh, sometimes it's like, oh.

Oh, well, this project is not, not going to be successful, right? Or sometimes it's like this project is going to take longer than we thought. Sometimes it's going to take less time. Uh, it's going to have different steps, whatever it is. Um, and so that's why exploration is at the front of the, or the top of the funnel.

It's kind of like, we're always looking for challenges. Uh, we're always looking for, uh, opportunities to, to solve for the, the pains of those challenges. And looking at, you know, the big challenge, like, how can we do mobile faster was out there, and cross [00:34:00] platform was an opportunity, and we said, how would we know if we should do that?

And we went and did what I referred to before, like, looking at the technologies that were out there, seeing what their adoption looked like, talking to people in our network, and all that was in the interest of, like, is there a there there? And, uh, mitigating the risk, reducing the risk before we make a case for the business to say, like, let's do this thing.

Uh, and we got to the point where we were like, look, we think, based on these companies, uh, that are using this, these network, you know, stories that we have about people's success, that, like, we should try putting, A team of people, maybe four people, and some, and you know, some consulting resources on piloting, building a feature a different way for mobile.

Uh, we would like to give it this sort of time, you know, box. Uh, you know, the resources I mentioned, and like this is the thing that we want to deliver. If we can deliver it in that time and we like what we got, we'll learn something about whether we should go to the [00:35:00] next phase of an investment. Um, and so that sort of strategy is really often appealing.

You know, to the business minded people because it gives them the opportunity to sort of think about, like, you know, funding something like, you know, like, okay, I'll put this much in. And if I like where it's headed, I can decide to make further investment or I can not, right? Like, even if we loved it, piloting Flutter, the business could still choose to say, like, that's great.

Maybe we'll invest in it later. Um, and it kind of gives you this opportunity to kind of like stage and like mitigate the risk, uh, incrementally. And that was like, I would say that's sort of like the biggest trick to it, right? Is just figuring out how to make space to do the exploration and how to advocate enough for a legitimate resource pilot, um, to determine whether you should go further.

David DeRemer: Those stages also help to minimize the, uh, perceived investment in cost, right? So, cause if you come to them and you're like, okay, there's going to be a multi year project for this many millions of dollars. It's very easy for [00:36:00] finance or, or anyone, an executive to be like, eh, I don't, I don't know about that right now, but if you prove it along in like bite sized chunks that you can kind of start to get a taste for it and evaluate it, uh, the sequential investments are more palatable and you can invest in that and decide and then move forward.

And I think sometimes, um, I know we see this, right, companies wait until it's a major burning serious issue. And then they go through a complex process because it's so hard to get buy in and decision making where you kind of have to paint this giant picture and it's this huge multi year transformation project.

Um, and those tend also not to go super great sometimes. So,

Sam Moore: And sometimes even if you get them done, they, you don't feel great afterward, right? There's such a slog, such a journey that like, You know, you just, you just wonder what you could have spent the time on otherwise, right? Like, was it actually worth it in the end?

David DeRemer: And if you're not validating along the way, I think one of the fears, even in like a, uh, uh, you know, especially in a Flutter migration or something like this, it's like, well, how do I know? [00:37:00] I'm not going to end up with a new thing that has the same problems, you know? Um, but this gives you a way to sort of validate that too.

Like, are we actually like resolving some of the problems that we identified in our evaluation criteria and our exploration and validating that we're continuing to improve on those problems along the way?

Sam Moore: Yeah. Yeah. Yeah. That's a big piece of it. Yeah. So that's a, that's a lot of it. And then, and then once you get past, once you go to a pilot, right, you need to go into that pilot with like structure, right? Um, so that you can come out of it with something to say other than like, my gut says do it. I mean, sometimes that's all you've got, but like, That's actually less often the case than people would like to pretend it is.

Uhm, so.

David DeRemer: Well, and with that pilot, I think, uh, if I recall correctly, you guys wanted to build out like a checking feature. Is that right? Was that the first pilot or was that not really the pilot? No, the pilot was

Sam Moore: We, We had just finished building a bunch of stuff. Uh, we, so 2019 we built like a new line of business for like a checking product. Uh, [00:38:00] and, uh, we We wanted to do, we had built like individual account setup, so you could sign up for a checking account as a person, like one person, and we had the plan to do joint checking sign up, so multiple people could sign up for an account together, um, and that was like the big, one of the big features we wanted to build in the, the first half of, of the, the, Of 2020, um, to kind of like continue to build on the success of that product line, uh, and be able to target more, more customer use cases.

Um, but in order to do that, we also like were looking at our signup experience and saying like, okay, so like we should rebuild that in order to be more presentable, correct? Modular was like kind of like a long like 20 step sign up process, um, and it needed to change. Um, and so what we decided to do a pilot in, uh, well, we decided to do a pilot with Flutter, and we decided to say like, well, we're not going to do the new stuff, but what we will build is a, modernized version that's modular of our [00:39:00] signup experience, and we'll build it with Flutter, and we'll use their add to app functionality, um, to integrate it into our existing app.

And like, we'll give ourselves, I think we said like 10 weeks, like just less than the first quarter of the year, um, to build the pilot, uh, and get it released to our customers. Um, which was ambitious, because there was like a lot of stuff to figure out. Enough stuff to figure out, we learned just building a Flutter app.

From, from scratch, but then using add to app and then also like, uh, integrating it into our app, which was like a non trivial app with like a lot of weird stuff going on.

David DeRemer: Yeah.

Sam Moore: Um, but yeah, that was the first app and that was a lot of the strategy.

David DeRemer: That side, the add to app side. I mean, that's definitely, um, uh, a key feature I think of, of Flutter. And it's an interesting dynamic. Like I remember these conversations around BlueSky, Greenfield, Brownfield, like, how do you go about doing this? I think most engineers want to be like, yeah, let's start fresh, you know, brand new, and that's just not really the reality [00:40:00] for most businesses to be able to do that.

And also like, you might make a lot of mistakes. There's a lot of things built into the existing app. That are really hard to make sure you get brand new in the new one. Um, you know, and, uh, but that ad app experience, I know that it's not necessarily the cleanest way to get an exposure to Flutter. So how did you guys manage that?

Given that, like, now you're kind of introducing this like new technology into these two apps that we just established had kind of these architectural problems and some issues, like, how did you kind of like insulate the team around that and make sure that, um, people still saw the, the value, not added complexity of what we were doing.

Sam Moore: Yeah, it was really interesting. So the pilot process involved like building evaluation criteria and like the fundamental thing we wanted to say was like, is building Flutter as good as, or better on average than building with. both or either of our existing strategies. Because like, if it's as good as, and it's, uh, and it's like, less total work that needs to be done, [00:41:00] and like, fewer different things that need to be thought through how to build, like, that's actually better intrinsically, right?

Um, it's a better state to be in. It would be a better set of trade offs to take on. Um, so then that was like an important part that we had to establish sort of early with our team too, right? It's like, we want to keep the people here. We don't want to lose all of our engineers because they don't want to do a cross platform or like they feel like they're, this is forced on them or something like that.

So we had to bring everybody into the process and that was kind of like how, what's important? Let's talk about what the criteria are that we care about that define what goodness looks like for building the software. Because it's, it's bigger than like a language or a platform, right? It's, these are qualities of the software that like exist in multiple platforms.

And you know, and back in the day, you didn't have any choice and now you have some choice. So let's see if this one's worth picking. Um, so that was like sort of key for both knowing that we were building something that was good and [00:42:00] being able to get people to be aligned with the decision to adopt it if we wanted to go forward.

Um, and then add to app was, as you kind of mentioned, like it was a very interesting challenge. We wanted to get like that really great, what does it actually feel like to do Flutter, the Flutter way experience. And so we took this approach where we basically built a Flutter experience, like Flutter create with the add to app strategy, but like in a in a separate thing and like a with like a dummy runner flutter app and just built the flutter experience like built the signup did all the software development so it was like really fast development pace like exactly what like the demos of building a brand new flutter app are and that was what our development experience was building that feature along the way so we could kind of know like this is what it's going to really feel like when we get to the to the promised land of this thing. And then as we got nearer to the end of the project, like maybe sort of the midway, we [00:43:00] started actually doing the work to say like, well, how will we integrate this add to app thing into our real app? And then, you know, that was where we were, we were very strategic in picking like an experience in our product that where you weren't like authenticated yet.

So you don't have to like deal with like secure storage and like being logged in and all this stuff. And like proxying that through all the craziness of our, of our existing stack. Uh, and so really what we needed to do is be like, how do we get like a view controller or a presenter or something that can like launch the Flutter experience at the right time based on a button click and like make sure it all works integrated and that the right thing happens when you're done.

Uh, and, and that was like all we had to do in terms of like the complexity of managing add to app in the pilot. And it was just enough to know like. Is this possible? And how hard will it be to do more? And as well as, what does it look like when you're like really just doing Flutter development? And, and you know, both of those things was like, it's not that bad on the ad app side, like it's complicated, but like it's doable.

And we can [00:44:00] like, maybe framework away where the pain existed. And like the Flutter experience was like, top notch. It was great. It was better than our current native development experiences because we weren't able to use like the latest and greatest experiences at the time and SwiftUI wasn't even really a thing much yet and all that.

So

David DeRemer: Nice. And you mentioned the team in there a little bit, right? Um, that's a big aspect of these types of changes, especially when you're changing a stack or adding some new technology. Um, what did you do? Uh, you mentioned you kind of brought them into the story, but like, how did you bring them along for the ride?

Like, how did you get them to, uh, to, uh, skill up, but also wrangle some of the feelings around identity, right? That comes along with some of this stuff. Um, because obviously you need the team on board. Like you said, you don't want to lose people because of this choice, but at the same time, their lives are probably a little painful dealing with these things.

Um, so how did you balance them and bring them along? 

Sam Moore: it's really interesting to navigate these things because you kind of need, like, [00:45:00] we go back to the business case part of the discussion. Like when you want to do something like this. You need to provide like enough of like a glimpse of what the future looks like and what the migration path is. Even though at the same time, you know, holding your head like this is like a hypothesis, right?

It might never come to pass, but you really need to think out into the future in order to be able to talk to like the non technical, non nerd people about this, or at least the people that nerd out on maybe the finance or the business cases and not this stuff. Um, but, but it turns out that like, doing that thinking is also really great for talking to the nerds when they're nervous about what it means for them, right?

Like, am I going to get, are we going to fire everybody? And it's like, well, Well, no, like we put together like an FAQ, right? For people of like, what does this mean? Like, what will, if we do the pilot, what is that going to look like? And like, what happens if the pilot is like green lit to go, you know, to adoption, right?

And like, that means, like, we're going to do [00:46:00] training. So we actually had to factor that into, like, the pitch and, like, the, the plan before we even started a pilot. So we had, like, it also creates this tension of sort of, like, it's like fait accompli, right? It's like, it's, it's, it's, uh, destined to happen.

Like, you did all this work. We're definitely going to do it. And you spend a decent amount of time reminding people that, like, This could not be what we want to do. Um, but if it is, we need to be ready. Um, and I think that kind of just like preparedness and carrying that the right way in your team and your conversations about it help a lot.

Like you have to believe that like this is a pilot and we will explore it and we know where we go next, uh, at least approximately and we're going to go together and that's the journey that we're on. And like being able to talk to the team about that and like. Communicate what we're learning as we go, um, and, and reassure them that like part of this is like there's a training plan.

Um, so I mentioned that before and I think you maybe referred to it as like we said like, well, in going into a pilot, let me rewind. [00:47:00] We said we don't know Flutter, we could figure this out on our own, um, but like that's yet another risk and another layer of stuff that we have to do. What would we do to, to mitigate that?

And we connected with you at VGV to say like, Hey, you're experts in Flutter. You probably haven't really done much with add to app. You fortunately had. Just enough experience in it to be extra helpful on that front too, but we wanted to bring you all in as experts to say, like, we're also going to know that, like, for the time investment that we get in this, that we're spending it focused on our problems and not, like, Flutter problems or, like, generic problems that, somebody solves and we just have to find them on the internet or figure out for ourselves.

Like, let's talk about the betterment business problems that we're trying to solve with this software. Um, so like you're going to kind of layer these things together, right? You say like, okay, we're going to do a pilot. We're going to bring some expertise in to help us to like, move fast and avoid the pitfalls that are obvious to somebody who's used this before.

We're going to [00:48:00] put together evaluation criteria. We're going to provide updates to the team as we go of what we're learning, what we like, what we don't like. We're going to make a final decision once we get to the end. If we are able to actually deliver the thing, because there's a risk, maybe we might fail, might fully fail and just like not get it done on time.

What are we going to do if we're not done? Are we going to keep going? Um, so, you know, having answers to those questions are really important. And then it's like, okay, so when we're done, we're putting it in production. We also need to be like, What do we do if we put it in production? It's fine, but we decide we don't want to keep it.

Now it's like another lava layer, right? Um, so like we had to have some commitment to like, we're going to unwind it then, right? Um, and, and we'll have to go forward with a new strategy and like figure out what that investment looks like. Um, you know, so anyway, that, those are like a bunch of the pieces that fit into it.

And then like somewhere along the way it was like, okay, well then once we pick it, we need to say like, when will we agree to like pause for like two weeks? Train the team, build something together, useful, uh, get everybody to learn how the fundamentals and get like some [00:49:00] experience. And then how will we like do adoption?

Formulating like an iterative adoption plan was like a big piece of success for this project, as well as other adoptions we've done, which is, uh, which is like a huge piece of just like, you have a bunch of experts that, that worked on this thing or like piloted the technology. It's a bad move to say, okay, now everyone use it for everything new.

You have to sort of train everybody. Sure. You can do that up front and say like, okay, now sit on everything you learned. There's four teams. We're going to stack them up. The first team we're going to bring the experts in and we're going to work with you to build a thing. the new way. And like, we're going to learn stuff.

We're going to make improvements to the technology stack that everybody else will subsequently benefit from. And like, you know, it's not entirely different from like consulting, right? We were doing sort of like internal consulting and contract work to like help them build the thing, get the skill, get the affinity for it, and then move on to the next project.

Because we didn't have the capacity to [00:50:00] help six people or four teams at the same time. Uh, and then, you know, that team is now living the future, and the rest of the teams keep doing it the old way. And, uh, That tension is also a fun one to observe. It's like, Oh, wait, but like, we want to do a new thing. But for some period of time, we're still going to like build new features because we can't stop building features and we're going to do it the old crusty way.

Right. And like, you have to live in that duality. Like, like that's how the business continues to be successful. And, and you don't like stop all the things, uh, and, and, you know, Ultimately, often, I think if you do try to do that, you usually fail because you can't support everybody. You can't do it all at the same time.

David DeRemer: I remember those trainings too. I remember, um, You guys explaining that or, or kind of having this vibe that it was this kind of cool cultural moment for everybody to, cause it's not that often in our careers where we as a team take like a break, do something all new, learn something new together. Maybe going back to what we were talking about kids, like, like sort of learning something new and how exciting it is to learn something new for the first time.

And I remember [00:51:00] after that, that training, there was this like, kind of interesting, like, um, at least my recollection of it, there was a positive culture bump of people being like, Oh, cool. Like. We did this together. We had this almost team building exercise where we're learning some new technology and wrapping our heads around what our future will look like together.

Um, and I thought that was just a, a really interesting strategy. Of course you have to do the training, but also to kind of like really embrace it as like, this is kind of like a good moment to rally the team around what we're doing, if we're going to go forward with this,

Sam Moore: Yeah, yeah, exactly. It's like that. It's like, yeah, classic sort of team building stuff, but like If, you know, in your hands on and like really feel like you're producing something and we kind of found like a hack, which was like, we did like a week of like workshops and like throwaway training material content.

And then a second week where we're like, now we're going to take everything we learned and we're going to everybody together that is going to build components for our design system. Cause we tried to follow the design system [00:52:00] and like, it was like, great. It's for people to build something real. That we're gonna use in Flutter, and they all get a taste, and then they all go back to working on whatever they were working on before.

And like, eventually they'll all come back to Flutter. Uh, and, and it, yeah, it just made such a huge difference of people being like, like almost it created the demand, right? They were like, it was able to dispel people's concerns. Validate, you know, concerns that were founded and, like, figure out how we would mitigate those and, like, create a desire to, like, there's somewhere better than, like, I'm going to go back to some of the stuff that's crusty, but, like, the future is coming and it's good, actually.

And that psychology is really important to consider, right?

David DeRemer: totally. Yeah. No one wants to work on the old and crusty. You want to work on the new and hot,

Sam Moore: yeah, yeah, like it, you just learn over time that people like, you know, they want to be upskilled, right? They want to learn new things, like there's this fear that people are curmudgeonly and just stuck in their ways and like, I always felt like that was very strongly pronounced in the [00:53:00] The mobile world, just like everybody was in their camps, like nativist camps, uh, uh, but then like, you know, I, I talked to people and like the reality was that people are very open minded, um, they just held strong opinions, right?

And like, they had fear for change in the ways that everybody does, like change management is like a skill, uh, that, you know, Individuals and organizations, both giving and receiving and making change, all need to practice to get good at. Um, and so, yeah, you, you, it's hard to, uh, it's hard to over invest in, in that kind of stuff.

David DeRemer: Totally. Yeah, there's so much identity trapped in that, and I think it's really dangerous, right? And I think you see the natural progression of this, where I think Flutter engineers can really just be considered as, like, product engineers, because it's like, oh, you want me to build for, you know, the web now, or Linux, or whatever else, and you have this, like, power in that technology, and I think it's even a danger to call it technology.

A Flutter engineer. Um, cause also like with all the talk about A. I. and what happens when one day you just go in and you enter a prompt, you know, and it's like spits out a code or [00:54:00] something, right? Um, or an app. Um, I see Flutter as like a natural progression of just like how do we make it easier for engineers to accomplish their objectives, right?

And not be so dogmatic about the tool, right? Um, so, um, just what about the sort of like, so fast forward, you know, and then I know there was a big process to kind of You know, continue to implement and follow through and do cleanup and stuff. But like, like as you went through that process and now you've got, you know, is the app fully flutter now at this point?

Or, or where did you get to?

Sam Moore: Yeah, so I think that's the other fun part, right, is an crucial piece of this like tech investment life cycle is that it doesn't stop once you pilot and it definitely doesn't stop once you start adoption. You need to actually get everybody adopting it, sure. That's the easy part. The hard part is the cleanup.

The hard part is like, uh, you know, we have this framework, the, the, the life cycle of tech investment that, that kind of talks about the. the return on investment at each stage, right? [00:55:00] And we talked about mitigating risk and like, the return on the investment is, is nothing until you get to like the end of a pilot at which like maybe you did something quickly or something, but even then it's usually negative, right?

You're still just investing. And then when adoption starts, you start to get some benefits, but, uh, With these sort of like, you know, uh, incremental rewrite things, you're not getting the full benefit. You know, we call it like, until when we're full flutter, like this will be better, that will be better, this other thing will be better.

You get the isolated benefits, but like certain things still have a cost that's painful. You know, we still had to test things in add to app mode where everything was integrated. When we, you know, we would build new features, we, we devised like a strategy for being able to build like in a standalone app that was like a Flutter dummy app that we would like launch and log into with like a dummy login feature because we hadn't migrated our login experience yet.

And so you'd like login, and it would get you an auth token. And then we'd like launch features with like a little buttons that we [00:56:00] built. And then you'd build all the things out, Flutter. First, and then you'd integrate them in the add to app experience and like test it and like that was painful and stinky.

It was not a good experience. It worked. It was totally doable. Um, but it was like the contrast was constantly there, which was also a good reminder and incentive to like, keep going and do the cleanup work. But you really do need to prioritize the cleanup work because it's not until you get to like, you don't do it two ways anymore.

You just do it one way, the new way that you fully manifest all the benefits.

So cleanup is a huge part of it. It's the easiest part to give up and not, not like power through. And we've learned those lessons too of like spending years, not, not being done. Now we are full flutter with the exception of, uh, one feature or something.

That's like a web view based experience or one or two features in a handful of features. Um, but just like, don't, they're not frequently used. [00:57:00] Uh, and so. We're getting all the benefits, right? Like even that WebView feature, like it's not foundational infrastructural pieces that are in the way anymore. It's just like, now it's like the legacy thing, but it's like nicely isolated and nobody, it doesn't, doesn't get in anybody's way.

Um, and the benefits are there. Like we get to do all sorts of interesting things. Like we recently built, uh, a new fancier test runner for doing like parallel test execution in Dart. And like, we just need to run Dart tests now. We don't need to run iOS tests and Android tests and Dart tests. And so it streamlines so many things for you where, like, you don't need to support multiple platforms.

You can make optimizations. You can embrace the choices that you've made. So, you know, on the impact of the engineering team, it's really great. But, uh, You know, there's, there was, that was a journey. I think it took us like, until like 2022 or something, like, you know, a full, like, almost two full years from like, Idea to being full Flutter, right?

And you can accelerate that if you can choose to [00:58:00] invest more. Um, but, uh, You kind of continuously get more benefit as you go.

David DeRemer: So there's all these benefits on the engineering team. Um, now that you've got that process behind you and a couple of years now of like living in the future, um, what have been the impacts on the overall like business of Betterment beyond the engineering team?

Sam Moore: I mean, there's tons of customer win to it, right? Like the customer value is like, we got it. We, we, you know, it's like, it's hard to, uh, it's, I mean, it's, it's easy to sound like it's hyperbolic, but like, it takes less time to build stuff, right? Like we, we love that. Like we did a hackathon last year. We do like an annual hackathon.

And, uh, you know, one of the teams was like a mobile parody team. And they like, they just wanted to see if they could build like a bunch of missing features into the mobile app. They're still on web, that we just haven't gotten to building on mobile yet. They built like five features in like, like a week.

You know, like, like, and then, you know, they're, they're not like, the most complicated features, [00:59:00] but they're more, you know, it's not just like adding a button to a screen or a, uh, it's like a screen. You click a button, you open it, it goes through a flow and talks to some APIs. Like they were able to do that with like three, four people, uh, in, in a week, right?

And that's like, it used to take us multiple weeks just to build one feature. Um, and so the, the, the massive improvement to, to that is, is great for. Everybody. It's great for customers. It's more stuff we can deliver. More features can be built on mobile. The quality of the user experience is higher. It's more consistency across Android and iOS.

You know, there were always these, we would have to design for two platforms. And usually, like, the designer would build iOS or something because they used iOS. And then we would just be like, what, what should Android do here or something? And like, now it's mostly the same. We have a design system. It doesn't take very long to just, like, add ideas and prototypes.

Which are again, all really good things for the customer. It's not really a companion app anymore. [01:00:00] It's not at full parity with our web experience, but that's, that's just like a matter of time. Whereas before it was like, We might never get there. Um, and that, that really speaks to it. And we do deliver features on mobile first.

Uh, you know, not every one, um, but, but tons of them, right? Uh, which is, which is really cool. And then, yeah, the business has been able to target the customers where they are. Um, we have the ability to say, we want to build this mobile, uh, First, or even only mobile, like a feature just for mobile. We have like remote check deposit for our checking thing, uh, checking product.

And that's like a mobile only feature. That stuff is really cool.

David DeRemer: That's awesome. Um, so many good, good benefits, you know, and I think it's, uh, you so many focus on the buy one, get one free of flutter sometimes and sort of the cost savings, but it's all these other organizational benefits. And I think it's important. We don't lose sight of the goal of what we're trying to accomplish with these products.

Like what we're not trying to do is like save money on engineering resources or time. That's [01:01:00] not the goal. The goal is to like deliver a better product to our customers faster. You know, like that's the goal. Um, it's just that technology is what we need. And sometimes managing our technology gets in the way of that.

And sometimes it's like so much emphasis focused on how do we do it? Or the, um, barriers and obstacles to getting things done. We lose sight of like why we're doing it in the first place, you know, which is making our customers happy.

Sam Moore: Yeah, yeah. And, and, you know, we, as a business, we also got the experience of like how to do this, right? Like, again, like this was maybe one of the, another one of the really big transformations we've done, but like now you, we, we have, we're doing more transformational stuff now. We're adopting React and like rich single page app experiences for web.

Uh, we've been adopting GraphQL for our, for API services and like. I get product and design people talking to other people, but when we did Flutter, we kind of did this and that worked really well. Right? And so like, you know, there's a, there's a part of our business like [01:02:00] fabric where like we, we can refer back to these experiences, um, you know, for people who are around for them, as well as people who kind of, kind of came along as they were happening, uh, to, to kind of create these like, uh, for them.

There's these cultural elements of like how to think about stuff, um, and, and so it's, it's sort of like an accelerant in that front too.

David DeRemer: Yeah, it gives you confidence, right? I mean, I think confidence is such an important attribute of just an individual, but also a company, right? And so if you start getting into the situation where you're like, Eh, it's too hard. It's gonna take too long. I don't think we can actually do that. That's like. The death of, of like your progress of companies.

Right. So, I mean, it sounds like not only do you have confidence now in your technology that you built, um, both Flutter and other stacks you've built and maintained, but the organization has confidence to like navigate through those changes and those transformations. Right. Which I think is probably the most, even the stronger value in the [01:03:00] long run, because things are going to keep changing.

You're going to have to keep evolving and migrating and moving forward. So that's great that it's kind of giving you that organizational strength.

Sam Moore: Yeah. You gotta be willing to take risks, right? Like, like, and you gotta be able to sort of see like how big a risk really is, right?

one of the engineers I worked with He, he has sort of a phrase of like, he'll just say like, well, how hard could it be? Right. Um, it's, and it's just a reminder that like, you gotta take that first step. Um, you gotta, you gotta trust that like, maybe it's not as hard as it seems like it could be. And, and doing it is one of the best, you know, recipes for, uh, for being able to know that you could do another thing or a bigger thing.

So,

David DeRemer: So take us home. What are some sort of key advice or kind of, do you have summary learnings that when you talk about this and these things that you've done, the framework you've come up with, your life cycle of, of, of what was it? Technology, uh, tech investment, life cycle of a [01:04:00] tech investment. What are some of the key takeaways or things you guys talk about internally, um, that you could share?

Sam Moore: Yeah, well, I mean, I think there's a whole bunch that I could rattle off. I mean, I think, like, having alignment between the technology part of the org and the business part of the org is really important, and that, like, uh, you want to focus on doing right for the customer. Right. Um, and if you, if you center the customer along the way, you kind of have this product mindset.

Um, then it, it gives you this like shared space to talk about, uh, you know, well, how is, how is doing this or not doing this going to make a difference in that area? And it helps you kind of understand that like, that's, that's where your shared values are. Um, like it turns out that like the organizational parts of this are harder than the technical parts.

Um, the technical parts are hard, but like, They're also, like, structured. They're, like, tangible, right? You, you, they, they hit you in the [01:05:00] face, whereas the organizational parts, like, They, they sneak up behind you, right, if you're not, if you're not looking out for them. So it's like really important to come in with a plan, right.

You got to get your commitment from the business that you're going to make this kind of investment. You can't begin exploring things that you're not going to be able to afford to resource. And you don't want to pilot a thing that you're not going to follow through on. Like all this sort of things that are in this life cycle of a tech investment, right?

Exploration, piloting, adoption and cleanup. Like you don't want to adopt a thing if you can't see a path to, to investing and cleaning it up. And they sort of just all stack together. Um, those are, those are big things for me. Um, you know, on the cleanup front, uh, Somebody I work with likes the, the, you know, everyone wants to go to the party, but nobody wants to stay and clean up, and I think that's real, like, that's a cultural thing.

that exists in our, in [01:06:00] our world that's part of our collective psyche. Uh, and so you, you really have to like formulate this into the plan. Like we gotta do it. It's gonna happen. It's gonna be annoying, but like, you don't get to have the party if you don't clean up the, the space, right? Um, and I think the other big piece of it that's, that was a learning for us is like, the work is never done.

Uh, so like, as you're going through it, like, you gotta really find a way to embrace the journey of it and recognize that like, once you Climb this hill or realize, you know, this mountain is actually just a hill and you see the next peaks like You got to go there too, right? Like for us, adopting Flutter helped shed light on the other problems that we had, the other challenges that we needed to solve, the next layer of, of, of, uh, things that were going to slow us down.

You know, for us, it was like web versus mobile dichotomy of how we built software. Um, and not building APIs meant it didn't matter if we had the best front end, uh, mobile tech stack, if we couldn't get the [01:07:00] data or, or, you know, create data, then like we were going nowhere. Um, and so. You know, those are other learnings to just recognize these are all steps in the journey, and it's all part of some, uh, some, 

David DeRemer: So like, clearing, cleaning up sort of the, the mobile process helps to clear the, clear the view for getting after the other problems that are deeper in the stack or other things inhibiting the growth of the,

of the 

Sam Moore: Right. Yeah. 

Yeah. And from a technical perspective, like, I like to start with the customer, and I also like to start with. the thing the customer sees, which is the U. I., and just like work toward the back of the system from there. Um, because sometimes, you know, the other way is, is fraught. Both ways are fraught, but the other way is often more fraught in that, like, you go and build, like, the best A.

P. I. and, like, there's no one there to consume it, right? Like, you can't rely on, like, if you build it, they will come, right? Like, the field of dreams is not how these things work, right? Like, you need to, like, create the adoption. You need to recruit the people to do the work. You need to, like, Sell them what they're actually looking for.

Um, [01:08:00] So, it's all really important. And, and starting with the customer is, is usually the best way to, uh, to kind of center that, that right part of the narrative. And, and focus on, like, the right things first. Um, It doesn't mean that you, you have to ignore that other problems exist. Um, But certainly it helps to be like a guiding, guiding strategy for, for, you know, how to pick where to start.

David DeRemer: Very insightful. Well, Sam, um, this has been awesome. I think your story and not only the Flutter experience, but what you guys have done as a businessman, managing all these tech transformations. It's, um, I've always been very keen to help you and collaborate with you to get these stories out. Because when I, when I get to hear about them and talk to you about the things you're doing, I'm like, Whoa, like.

More people need to be aware of this because so many companies are facing these technical challenges and they blame the tools or the technology or the market or whatever. And sometimes it's like, well, no, we just need a mindful process to go through this, to continually improve and get better. And you've been a great collaborator of us, so thank you for having this conversation.

I know we've worked on, there's [01:09:00] a webinar people can find that we've done together. Um, we've created some, some guides around migrating to Flutter in the past and collaborated on that. And, um, just really appreciate you continuing to share these thoughts. And I, I personally love to hear that sort of, that next step.

That it's like this Flutter migration you did, this process you went through. Like, that process becomes repeatable and you're doing it for other things. So it's not just this like one time skill. That you like, it's like you're training to do the Olympics one time and then like it's over and you're ever going to do it again.

It's like, no, actually like going through that process. Yes, you're creating an improvement to your mobile stack, but also you're creating this organizational capability and comfort and confidence to do more of it on other stacks and other parts of the business. And that's just really cool. So, um, yeah, just wanted to for coming and telling the story and hopefully we get a chance to do more of it.

Sam Moore: Yeah, I mean, I want to thank you for, for, you know, inviting me on to, to tell the story, uh, and, and being such a, a wonderful host, uh, asking great questions and, uh, and giving me a lot to think about. So, [01:10:00] uh, appreciate the, uh, the opportunity.

David DeRemer: Awesome. Well, thanks, Sam. Appreciate it very much. Talk to you, 

soon. Cool. Alright, we'll just hang out here and Luke, you out there? Hey Luke. Alright,

so. 

Sam Moore: Okay.

David DeRemer: some of those cards, like Sam you and I can follow up on this around sort of like for, cause that was about an hour ten or more. So FlutterCon thing, but. So I think that's good because we can find some things just like we can really contain it, I think, to the Flutter stuff. Um, cause that's what the dev crowd will really be into. And, but I think that was awesome. I think you have so many like snackable quotes to pull out of there and stuff. So it's going to be

Sam Moore: That's great. That's great. Yeah. I mean, I like, I mean, you know this, but it's easy to have these conversations with you, right? You, you've got a, you've got a good, uh, uh, you know, an active mind asking really great questions and it's so easy to pull on threads and, you know, throw things out there [01:11:00] for you to, to, to sort of gnaw on.

It's, it's, it's good.

David DeRemer: Well, don't give me too much credit. You're the, you're the star of this. I mean, I've always felt, just for what it's worth, I mean, you're, you're, um, you should be doing more talking and stuff, I think, like, as you grow your career, because I think your insights and your ability to deliver the message, just for what it's worth, is, like, really, really on point and solid, and, uh, I've always found you to be, like, really, the way you communicate and deliver the insight is just, like, something I think people can really connect with, um, and it's genuine.

I think so many people are out there giving this advice. Thanks. Thanks. And it's like, you know, uh, cause you want to be a LinkedIn influence or something, but like everything you're describing is just like lived experience,

which is really 

Sam Moore: yeah. Well, happy to do it. I appreciate the, uh, the vote of confidence. I think that's the thing that I'm, I'm aiming to spend more time doing, which was sort of why I wanted to, you know, do this with you and, and also, um, to, you know, figure out that talk and, uh, even on short notice,

David DeRemer: yeah, well, we'll follow up on that. I think, um, my goal is if we can get like three, four or five slides, you [01:12:00] know,

and just keep us oriented, you know, and just get us on point. Um, so even, even just those header discussions.

‍