“Nobody's going to drive as fast on the straightaway if they don't have good brakes because if that's not available, then you can't go fast confidently.”

John Mileham is the CTO of Betterment, and he’s also a race car driving instructor. Though they seem like vastly different roles, he has the same focus in both: going fast but doing so safely. Betterment is a digital financial advisor that builds software that can automate your finances… so safety is key. In this episode, John describes how he empowers teams and creates conditions that foster creativity, speed, and security. 

In this episode, John breaks down how his experience on the racetrack has influenced his approach to innovation, drawing on the recent improvements to Betterment’s Cash Reserve product, the difficult transition to implementing GraphQL in the organization, and how performance envelopes are expanded with the confidence of safety.

Listen and subscribe to Crafted: Apple Podcasts | Spotify | All Podcast Apps

Full Transcript:

John - 00:00:00: Nobody's going to drive as fast on the straightaway if they don't have good brakes because if they're wondering if that's not available to them, if this lap the brakes are going to have faded and you're going to not decelerate as much as you need to, then you can't go fast confidently. 

Dan - 00:00:12: That's John Mileham. He's the CTO of Betterment and he's also a race car driving instructor. In both contexts, he's focused on how you can go fast and do so safely.

John - 00:00:23: I have always had this drive to go faster and be better, and race car driving perfectly encapsulates that. I also really love teaching and I love passing on that passion to other people. And I find that as a technologist, that actually deeply influences the way that I think about building.

Dan - 00:00:42: At Betterment, John's teams build software that can automate your finances. So having a great safety harness is key. And one way he helps teams innovate safely is by encouraging them to focus on those important, but not yet urgent improvements.

John - 00:00:57: Like, yes, we should fix this, but is it urgent? Maybe not, because we can continue doing it indefinitely. But what it manifests is as a huge friction tax for your team.

Dan - 00:01:08: On this episode, John takes us behind the wheel at Betterment, including how the team recently unlocked huge improvements in their high interest cash saving product. Welcome to Crafted, a show about great products and the people who make them. I'm your host Dan Blumberg, I'm a Product and Engagement Leader at Artium, where my colleagues and I help companies build incredible products, recruit high performing teams, and help you achieve the culture of craft you need to build great software long after we're gone. So John, before we dig into what you do at Betterment as CTO, I wanted to ask you about a passion of yours. You teach race car driving. And I understand it influences how you think about software engineering. And I'd love if you could share more.

John - 00:01:52: Absolutely. I think at the heart of it, I have always had this drive to go faster and be better. And race car driving perfectly encapsulates that. I also really love teaching. And I love passing on that passion to other people. And I find that as a technologist, that actually deeply influences the way that I think about building, building teams, building tools in order to unlock the potential in people.

Dan - 00:02:18: And what are... I'm not a race car driver, but like, what are like a few things that I should think about if I want to perform better? If I'm out driving the kids around.

John - 00:02:28: Look where you want to go. It seems like a very, very simple insight, but it's especially important. Those moments when things are going sideways, maybe quite literally, but the idea that you actually have a ton of control over the outcome based on where your eyes are, both in terms of how you achieve it and whether you feel like you're just walked in on some inevitable off or something like that. Often just looking where you want to go will help you solve it.

Dan - 00:02:55: That's fascinating, actually. So I work my moonlighting job on the weekends. I guide kayak tourists and teach people how to kayak better. And we teach people the exact same thing. Like look where you want to go. And it's amazing that your boat will go there without you even really knowing you're moving it in that direction. You've said that your approach to going fast and going fast safely influences how you drive teams, how you help them improve their performance and do so in ways that drive the product and the business forward. Can you explain how these two worlds intersect and how you lead software teams?

John - 00:03:23: The realization for me, when I first started doing performance driving stuff was, “Oh my God, there's so much more performance envelope available than I thought there was”. Like I thought that I was already able to ring out a car when I first showed up as a student at one of these events. And then suddenly I was having my doors blown off by cars with 150 fewer horsepower and somebody was just driving the wheels off of this thing. So I think both the acknowledgement that if you can figure out how to improve somebody's craft to the point that they can really fully occupy that performance envelope, the ability to deliver great things faster, that's step one. But like that needs to come in conjunction with understanding that certain outcomes can't happen depending on what kind of software that you're trying to build. So in my world, that often distills down to shared principles and understanding of how we build software and often also boiled down into tools and constraints that expose the wide open parts of the performance envelope while strongly containing the bad outcomes that you don't want to have happen, right? So like, obviously as somebody who works in financial services, the financial correctness outcomes are super critical. So how do we put that stuff into the fabric of the culture and of the tool chain and the approaches that we use so that that's not a consistent part of people's day-to-day and they can spend their time innovating and blowing out this performance envelope of what is the software that we can ship?

Dan - 00:04:56: I used to work with an engineering leader at LinkedIn and he would use the analogy of a race car all the time actually, and he would always quiz people. He loved to do this. He would quiz people and say like, “what is it about the race car that makes you go really fast?” And people would volunteer, you know, “the engine, the tires”. He's like, “no, it's the brakes”. It's like, if you didn't have great brakes, you couldn't possibly go that fast. So I've heard his version of this analogy many times. Is that something that rings true as well?

John - 00:05:20: Yeah, that a hundred percent resonates, right? And the qualities that you're looking for in a great brake system is that it has this immediate and consistent effect when you're approaching the limits, right? Nobody's going to drive as fast on the straightaway if they don't have good brakes, because if they're wondering if that's not available to them, if this lap, the brakes are going to have faded and you're going to not decelerate as much as you need to, then you can't go fast confidently. So this is very much about expanding that performance envelope by having the confidence that comes from safety.

Dan - 00:05:51: So let's get to some of what you're working on at Betterment and how you've built in performance and safety as you've gone. So you just celebrated your 10 year anniversary at Betterment. Congratulations. That's really remarkable and not that common these days. So I'm curious, what drew you to Betterment in the first place and what keeps you there?

John - 00:06:06: I actually made a bit of a pivot into the financial services space. With the tiny startup that I co-founded before I came to Betterment. And the reason that I did that was because I saw an opportunity and a need honestly in the software industry for a better way of building software that upholds the needs of the customer in a way that I was not seeing in all of the areas of large software development so far. And my hypothesis was that, while we've seen a ton of financial software that's built in a way that contorts the process to the expected demands of compliance and risk management, that's not the actual global maximum that we can achieve. Is there an opportunity to take the real constraints behind some of these compliance regimes and reproject what's possible, expand that performance envelope and then build the right tools, systems and approaches in order to enable that safety at high speed. So I had the opportunity to prototype some techniques within ImpulseSave and then take some of the techniques and approaches that I developed there and begin to bring them to bear on the problems of Betterment. And it's been a really rewarding experience to be able to innovate in that space and hopefully bring better outcomes for our customers at higher speed from us and enabling us to be now the largest independent digital financial advisor. I think not coincidentally because we have this ability to run fast safely.

Dan - 00:07:43: Can we just take actually a moment for anyone that's not intimately familiar? What is Betterment? Who are your customers and what is the core offering?

John - 00:07:50: Yeah, Betterment is a digital financial advisor and we deliver our financial advice through three different products effectively. One is the direct to consumer investing platform. Another, we offer the Betterment investing platform to employees through the 401k software that we sell to companies. That's called Betterment at Work. And then finally, we offer our advice platform to advisors in order to manage the assets of their customers, enabling them to do high value financial planning interactions with their customers and delivering the automation that we provide in order to make that easy and a great experience for their advisees.

Dan - 00:08:31: Betterment recently launched big improvements to its cash reserve product.

John - 00:08:35: And one of the one of the cool things about this product is that we didn't immediately build it right in this high rate moment that we're experiencing in the marketplace right now, where like some of the capabilities that we have are really crucial. But the story actually goes back to the foundations that we laid when we first released the cash product several years ago. When we built it, we knew that we needed a solid foundation built to expand and meet the future needs of the system. And among those core innovations were the ability to take advantage of different rates offered by different partner banks effectively, right? So we want to be able to offer all of our customers the same high rate, but behind the scenes, what we're actually doing is we're receiving different high rates from different banks and we're trying to achieve the same blended rate so that they can have the best return that they can. And it turns out that this is a really interesting and difficult math problem. And a lot of companies might've approached this with the idea that they would just delegate it to a broker who's going to be able to solve this problem for them. But we recognized pretty early on that this was actually a real opportunity to differentiate and do this work better. So as we went from a prototype version of this that actually used a linear solver in order to allocate all of customers' funds every day, we realized that we were hitting a scale knee as we started to onboard more customers. So what we ended up doing actually was rebuilding the core of that engine with an innovative algorithm that basically entails every account being treated like a virtual trader, trying to achieve the level of fan out and FDIC insurance that it needs in order to be individually satisfied as well as the blended rate that we're targeting. And we found that this algorithm with all of these virtual traders operating on their own behalf led to a much more efficient solve and enables us to scale the product arbitrarily effectively and still get all the people what they need. So this was a really cool core innovation. And then rates went to almost zero for a while and the product was very maintainable. It didn't cost us much to operate, but it also wasn't a huge focus for consumers. But then this year rates have been on the rise as well as we had a micro banking wobble where we were like people were concerned about is my bank at risk? And so the idea of not putting all of your eggs in one basket felt really important. And by virtue of the way that we built this thing, we were able to onboard new banks and bring them into the program very easily with their different rates under the hood. And we were also able to just as quickly decide that we wanted to increase the amount of fan out that we were doing on an individual customer account and have a production market with higher FDIC Insurance almost immediately. So I think this is a really great example of that build for the performance envelope that you want to have to be wide open and safe to operate in. We didn't have to re-architect anything when the time came. We already had the flexibility inherently in the system and we were able to run fast at that business problem.

Dan - 00:11:46: That's awesome that you were ready to go as soon as cash and spreading out your cash among lots of different banks, you know, became something people were really actively talking about and thinking about this year. How did you come to the technical solution that you talked about? Like how did you identify this new way of solving the problem? How did you roll it out and know that it was the right approach?

John - 00:12:05: This is one of those many examples of when you have a great team and you unlock them to strategically own the business outcome that you want them to have, they will continuously surprise and amaze you with out of the box solutions. Our approach here is that we really try to give our product and engineering folks the business context that they need to be able to decide what challenges need solving, how to solve them in order to come up with an optimal path. So it was just one of those moments of invention that turned out to work and like any innovation, I think it also started small with a prototype. There was a hypothesis that an approach like this might work well and an engineer prototyped it, checked it out, tested it with a large scale of dummy data, well beyond the number of customers that we had at the time in order to validate that in fact, even in exotic situations, the whole thing held up well and the performance characteristics in the real world would be in line with what we'd expect. So, you know, I think that also goes to like investing and having a team that cares deeply about the craft and experimentation and knows the kinds of iterative development that they need to apply in order to solve those problems.

Dan - 00:13:20: I love that. I love, you know, giving folks problems to solve and not solutions to implement. Is there a specific way that you do that well at Betterment that you give folks the right business context and let them have the freedom to explore?

John - 00:13:33: It's a socio-technical problem, right? Like it's a culture problem. And we try to reinforce that through several different mechanisms. On the organizational side, we have agreed as a principle that we would organize ourselves around squads of ownership and not around squads of execution. The idea is that at the local level, you are the biggest expert at the company about how your product ought to work and what it's trying to achieve and how it's trying to achieve it. There's not some centralized command and control infrastructure deciding how that product should be implemented or what it should look like. And we also, from a software side, have tried to set up a software architecture that supports that organizational structure. And not only do the teams reflect that, but the services that they own and build also very directly reflect the squad shapes that we have. So that also informed our software architectural approach of what we've often called Macro Services, where we've tried to make sure that we're not overly dissecting our domain into too many discrete services that go beyond the ownership particles that we have as a business. Ideally in our world, a squad owns a business domain, and that ladders up to part of one of our major macro services. And that has served us really well.

Dan - 00:14:55: John and his team recently made significant changes to Betterman's infrastructure by implementing GraphQL. Doing so sped things up quite a bit, but it was a difficult transition.

John - 00:15:06: Change is hard. No matter what the change is, somebody is going to feel like they're losing something in the process. And I think GraphQL in particular has a lot of baggage associated with it in the industry. And the reason for that, I think, is that it was part of a hype cycle. It came out of big tech, but then the libraries became open-source and were available to early stage tech. And it's not necessarily the right tool for an early stage tech company. So we had some out of folks who had experiences, lived experiences in those environments where they were not properly supported, where it might not have been the right tool for them at all, that led to some worse outcomes than simpler solutions. So we addressed that stuff by talking about it head on, right, like there's a reason why we didn't do GraphQL five, ten years ago, because we weren't ready, the technology wasn't ready, and these were the qualities that we thought were missing, and these are the qualities that we think that we now have to make this the right decision. We also addressed all of the concerns that naturally come up with any new solution, and made sure to just be really open to feedback about what the problems were that we felt that we needed to address in order to make this the right choice. And then finally, we didn't just go all in on GraphQL without thinking about it, right, like all of the major technology platform changes that we've made, we introduced it as a pilot program with a clearly defined scope, pre-identified the value that we were seeking from it, the risks, and then checkpoints to see that things were on track. So I think being accountable to our teams for concerns that they will have about change that we want to make, managing the change really thoughtfully, and not necessarily making it incumbent on every single person's strong belief that this is the right thing to do, but I'm a big fan of the school of thought around consensus that is the consensus that you need to reach is the shared belief that this decision if made will not destroy our community. And if you can get to that level, then you can move forward with, you know, do care and all those things. So yeah, I think that was the key unlock for us is reaching that stage.

Dan - 00:17:18: That's great. Do you have any other advice for those, whether it's tech debt or different type of migration that someone, an engineering manager may be considering, but is having trouble getting prioritized because it's not immediately obvious what the user benefit or even the business outcome will be apart from some which I think is a big win, which is it will help us iterate more quickly, but that's sometimes too vague to get prioritized.

John - 00:17:39: Yeah, so I come from an IC background. I lead the engineering organization at Betterment, but my heart is very much in creating an environment where engineers who want to do it right have the ability to do it right. And so, this is a subject very close to my heart. And one of the things that we've baked into the way that we organize, obviously it's not uncommon to have a separate manager in IC discipline, but we also have an IC leadership track that doesn't just come with being better at the work, but also comes with accountability to the team to ensure that we're enabling and expecting our teams to follow through on those important, non-urgent qualities of the software that they build. So we have a range of IC levels from software engineer, staff software engineer, senior staff up to principal engineer. And we've also got a VP of architecture overseeing the principals that allows us to surface those sorts of tensions. When it becomes difficult for like a manager to make a case to their product partner about what we need to do here, we can also escalate through our IC leadership and decide if there's a conversation to have strategically about how we need to enable this kind of work better. But ultimately the accountability needs to flow back out to the strategic local ownership of each feature. So what we're really trying to do is not create this ivory tower tops down, like you must do this, but rather the culture that enables those local squads to have the standing and to be able to have the conversation that they need to have to deliver the safety, the debt reduction that they need in order to operate at high velocity.

Dan - 00:19:28: I love that you're putting it in this importance versus urgency matrix and focusing on the non-urgent, but important things. And if you focus on those things, they generally do not become urgent, which is great. Are there particular things that are in that non-urgent but important bucket that you think too often get ignored? 

John - 00:19:46: One of the lenses that I like to use for identifying some of those is when engineers are operating the business. I think we are very bought into the DevOps philosophy that engineers should operate their software, right? Like, they should be responsible for all the externalities that their software creates. But I think an interesting sheer line to make in that ownership is if you are spending your time operating the business through consoles, SQL access, other things that cover over for underbuilt software, then that's a hard no. And that feels like one of those things that will typically be treated as important, right? Like, “yes, we should fix this, but is it urgent? Maybe not, because we can continue doing it indefinitely”. But what it manifests is as a huge friction tax for your team. So for us, it's been very clarifying to think about this. Are you operating the business? And if so, you need to stop because the payback interval on figuring out how to make engineers not operate the business is probably much shorter than you think it is. And the tax that you're carrying in terms of not doing that is probably much higher than you think it is.

Dan - 00:20:57: I love that. How do you hire? What do you look for in engineers when you're bringing them on board?

John - 00:21:01: Intellectual curiosity, that's one of the keys. We've had a long history of hiring people from non-traditional backgrounds and or no experience on the platform upon which they might be coding. We've definitely had great success with people who don't necessarily come from a traditional tech background. I personally, you know, I'm a music school dropout who ended up coding for a living, so I have a lot of appreciation for the different paths that you can take to mastering this craft. So yeah, honestly, it has to do with understanding what the needs of the role are in enough detail that you don't have to default to these preconceived notions of exactly the shape of the candidate who's going to fill that responsibility with you, which is honestly some pretty tough interviewing to do. You have to have a very cohesive view with your interview team of what that means. And you need to have a lot of communication about like, it's not just a matter of like collecting some scorecards, taking the average and being thumbs up, thumbs down, but rather coming together as a group, understanding the meaning behind some of those ratings, establishing whether the things that you need for the role that you have are in fact that particular resume line item or that particular experience that might or might not indicate the capability, which is what you actually need.

Dan - 00:22:19: Is there a particular way you've found to get at that ability to grow and that intellectual curiosity you're looking for? 

John - 00:22:26: Just being deeply collaborative, right? The interview team is a team and treating them as a team with the opportunity to mentor one another, provide feedback to one another, align on what's important and continue to grow throughout the process of recruiting and growing the team is crucial. So there's a magic bullet. I think it's just using your human superpowers with each other.

Dan - 00:22:47: Yeah. And what's the closing pitch for someone who's considering coming on on board at Betterment?

John - 00:22:52: Betterment has the great fortune of having been built around a customer-centered business model, which enables us to continue to make the best decisions for our product that are also the best decisions for our customers. So that right off of the bat set us off on a really good start for being able to build great software. From there, we've been really intentional about creating an environment and autonomy for everybody on the team so that they can make a huge impact in people's lives in this very important space, right? People's retirements are at stake. People's savings are at stake. And 201, regardless of whether somebody is a deep finance wonk all the way to they think Betterment is valuable because they're scared about managing their own finances. We're all unified in this opportunity to bring something better to people and just make this thing work for more Americans. So that's that's my pitch.

Dan - 00:23:49: Right on. John, thanks so much. I love everything that you're building. I love the way you're doing it. Thank you.

John - 00:23:54: Awesome. Thanks so much for having me.

Dan - 00:23:58: That's John Mileham, and this is Crafted from Artium. If you're looking to go fast and not break things, let's talk. At Artium, we love partnering with visionaries to help them build incredible products, recruit high-performing teams, and achieve the culture of craft you need to build great software long after we're gone. You can learn more about us at thisisartium.com and start a conversation by emailing hello@thisisartium.com. If you liked today's episode, please subscribe and spread the word because everyone should know about Crafted. It's a socio-technical problem, right? Like it's a culture problem.