From Droid Days to DraftKings: Hemant Garg on Velocity with Guardrails

[00:00:00]

Matt Klein: All right, everyone. Welcome to Beyond the Noise: Signals, Stories, and Spicy takes the show where we dig into the stories of the people shaping the future of app-based computing with a special focus on mobile. I'm your host, Matt Klein, co-founder and CTO of bitdrift, as well as creator of Envoy. Each episode we'll talk with engineers, founders, and technical leaders who've transformed the way their companies build and understand what's happening inside their systems.

We'll dig into the challenges, the breakthroughs, the lessons learned, and wrap it all up with their hottest takes. So let's dive in.

Today I'm thrilled to have Hemant Garg, who is a Vice President of Engineering. Leading the front end platform and core user journeys across mobile and web at DraftKings, he [00:01:00] oversees teams of engineers, building scalable, high performing applications, and also leads full stack teams driving new product launches.

A hands-on leader, Hemant combines deep technical expertise with strategic vision, ensuring seamless customer experiences while accelerating innovation. His current focus includes exploring AI agent tools to enhance developer productivity and unlock new efficiencies across engineering. Welcome. Thank you for joining us.

Hemant Garg: Thank you, Matt. I'm so glad I'm here.

Matt Klein: Yeah. You have a very impressive background, obviously very appropriate to this podcast. you've been in the industry for a long time, working across a lot of different companies, so I think my first question is... can you, you know, with whatever you're willing to share, can you give us a breakdown, you know, of how you got into frontend and mobile development and just, you know, what [00:02:00] excites you about this space?

I think that's a great place to start.

Hemant Garg: So I've been in the mobile industry, my, all my professional life, which is almost 21 years. And I grew up back in India where there was, you know, my, I started my career way before Apple and Google were a thing. It used to be Nokia phones without much UI, just mostly buttons.

Flip phones. So flip phones. Yeah. Yes. Flip, flip phones or candy bar phones. Yeah. So I remember my, when I passed outta my college, I went for my first interview and they showed us a Sony Ericsson phone, which had like a full UI, a touch screen. And that got me so excited that this is the future I've never seen in my life a small device with a UI on it.

So at that point I knew I wanted to work on this UI things, which is very fascinating. How can you pack so much things in a small device?

Matt Klein: Yeah, for sure. I mean I also actually started my career [00:03:00] on mobile, which I think surprises most people because these days I'm mostly known as a systems engineer.

But I actually started my career working on Windows phone, actually, which pre pre-dated iPhone. So it is a, it is a very interesting space. So, yeah, I mean, so I guess tell us a little more, just in terms of, I don't know, would love to know... what, was your first project? What was your first app that you created?

And then, you know, tell us how you, wound up in the US and working for some of the largest companies.

Hemant Garg: Yes. So I started chasing my mobile dream the moment I saw that Sony Ericsson phone. The first company I worked for was a very small startup-y, kind of a company which was doing a mobile browser for Motorola phones.

Motorola was the biggest device at that point, so I - I, we were developing this mobile browser for Motorola and then soon I realized I want to go and play the [00:04:00] big roles at big companies. So I switched to Motorola, started working at Motorola in different, different departments, different teams. I worked on different tech, tech stack.

I worked in the OS, grew from OS to the applications. And then one day Motorola decided to consolidate all their best ingenious, or me. I'm glad they considered me the best. And moved us to US and said, we're gonna work on something new, something killer, which will change the game. And that turned out to be Android, so.

Oh wow.

Matt Klein: Okay. Cool. So I, is this, is this before Android launched or or was it at kind at the same time?

Hemant Garg: So I was part of the team which actually developed the first Droid phone for Motorola. Wow. I was picked into that team, 200 people team. I came to Silicon Valley. Became a part of a team, which was, tasked to make Android device, the Droid phone.

And, I started [00:05:00] writing the OS level. Then I did the camera application, the media gallery application, and bunch of applications. Ultimately, my hands were on them, not necessarily the only guy. And... it was so exciting to launch the Droid phone and see your fruits in action, which changed the whole game.

Like Android became a very solid answer to iPhone. And I was glad to be part of the team

Matt Klein: But at that point, I would imagine that you were working very closely with Google because they were effectively developing the operating system at the same time, right? Yes, yes. Yeah. So I, I mean, I would, I would love to hear some more stories about, I'm, I'm sure there were some awful bugs that you had to solve, you know, so I, I don't know.

Yeah. It's like, do you remember what's the, what's - what's the worst bug that you had to figure out?

Hemant Garg: Oh man. Going back in memory lane, there were many things, it was shaping up a lot, so it was very different from what Motorola used to be. So just to give [00:06:00] you a glimpse, the most popular device Razr had a team of around 15,000 engineers working on the whole device

Matt Klein: 15,000?

Hemant Garg: Motorola had its own hardware, its own OS, its own chips, right? It's own every single component, which goes into the mobile thing, right? And comparatively to that, the whole Android team was 200 to 300 people, right? Where the goal was, look, everything is coming from Google. All you do is package it up, test it, and release it.

The story, first of all was not very true. Like, hey, this is not a tested one. Motola was very high on quality. We were a digital Six Sigma company. That means there was... we, we can only afford to have like one or two bugs in a million of opportunities. So there was a very different ballgame. Motola wanted to ship everything, which is, is the best in class and Android, when we got the Android OS, it was nowhere close to that. There were tons of bugs. The camera cannot take more than five [00:07:00] pictures in a, in a row and crashes. So the challenges were how to take Android OS and bring it to the Motorola quality standard and then, you know, release it to T-Mobile was the first. Oh, Verizon was the first customer.

Matt Klein: Yeah, I, I actually, it's going back so far now, but I remember, I don't know if it was with HTC, it might have been Motorola. I'm not sure. It was early in my career when, when I was working on Windows phone. And just to follow up on what you said, I remember that... we would do builds and we would send them to Asia and overnight they would, I'm not joking, they would have hundreds of testers who would, you know, test stuff.

And it's exactly what you said. They would, you know, send back a report that said something like, one in 10,000 of this thing failed. You know, like it's not acceptable. Yes. So we had to debug these issues that at the time were, I actually think still some of the most complicated bugs that I had to figure out in my career were very early on, on [00:08:00] some of these early phones, just because of what you said, which is that the, these companies at that time, I don't know if it's still that way, but at that time they were very rigorous about what they would want out of, out of the devices, which I think is pretty cool.

Hemant Garg: Yeah. So going back to your question, right, I remember I was tasked to do this camera and the goal was the phone can take, I think, 500 pictures in a row without crashing, and it was almost impossible to do that. Like it would crash at 5, 6, 7. So, so much memory optimization went into this thing of like, how do we make sure that the speed versus the, the stability decision has to be made. So, it was very hard. That was the most hard bug at that point I had to fix.

Matt Klein: And at, at the time, I'm, I'm just curious because obviously people know that Android is mostly written in Java. Obviously the operating system is, you know, based at that time, is based on a fork of Linux and obviously there's a lot of native code. So I'm curious like was [00:09:00] it crashing in Java land or was it crashing in the native drivers?

I mean, it's like what? What was causing all of the instability at that time?

Hemant Garg: It was all over the place. Yeah. because OS was not stable. The - the chips and the layer above the chips were also not stable, so it would just crash randomly all over the place. Right? Yeah. There used to be like a tombstone crashes, the whole device restarts. And, and, and, and at that point there was not enough tools to go debug and see what happened. So you had to guess a lot that, oh, this might be happening. And you had to collaborate a lot with the full stack engineers all the way to the chip. I remember the chip was a third party chip, and we had to call those engineers also, like why this chip crashed.

Matt Klein: Yeah. Uh, it's, yeah, those, those types of debugging stories are so, are so fascinating to me. Yeah. So anyway, so from there, where did you go?

Hemant Garg: So, after Motorola, I spent almost five years there and I was in [00:10:00] Silicon Valley and then the famous quote, you know, "if you're in Valley, do the valley stuff." I went out of Motorola and found my first startup.

Evernote where, Evernote was in a very nascent stage. They had a very successful product on Mac, on Windows, and on iPhone, but it was zero on Android. So I joined them to start the whole Android team. I was the only guy, the one person team, and, like... I spent five years, close to five years at Evernote and developed the whole Android team from scratch and then multiple apps.

And fortunately all those apps turned out to be number one on app stores. We won Google Design Award. We were, we presented Google I/O a bunch of times. I presented Google I/O a bunch of times, so that was the most fruitful experience of my career, to develop an app from scratch, which was very different.

Like no OS involved. You can't change things in OS or anything, which is below OS you to purely work by the rules of the OS. Yeah, with the APIs that

Matt Klein: are [00:11:00] there. Yeah. So I - I guess, I mean that's obviously an amazing accomplishment. What... what do you think you did or learned back then that you think had the most impact of - of getting it to be number one on the app store with, with the highest review scores?

I - I guess what I'm asking is: I would imagine that's where you started to learn like what makes a really high quality app. Yes. So I would love to learn more about what, what do you think are the most important things that go into a very high quality app?

A lot of things,

Hemant Garg: right? A lot of things.

First of all... is the app something which the customer will use? Right? Since I was the only person I was wearing the hardware, product manager, a designer, an engineer, an architect, a customer support, everything. So the first thing is, is this the product which you want to really ship? Is this what people will use?

Does it have the best in class UX, UI? Is it intuitive enough? And once that is done, then now you to code the app in such a way that it never crashes. Especially... [00:12:00] evernote was a note taking application. It cannot crash while you're in middle of taking a note. We cannot lose your note while after you saved the note.

So stability and performance were paramount. And, one of the biggest things, which I feel, made everyone a class apart was how quickly we reacted to customer complaints. How quickly we see there is an issue happening, and how fast we can fix in days, not in months, not in, not in, quarters. Yeah. So that was the critical thing, and there's an interesting story while I was working on Evernote,

another app came out, which became very popular...

Instagram, and I remember the day when Instagram was launched and one day they had to make like seven or eight releases, like something crashed, and they fixed it very quickly, put it in the app store. So that actually taught me a lesson that in Evernote I was doing it in two or three days, but you know what? I have to do it faster than that. So [00:13:00] the key was how fast you listen to your customers and fix them.

Matt Klein: I think one thing I'd like to pick your brain on is - and, and this is a... this is kind of a pet peeve of mine in the app space, so I wanna, I wanna get your take on it - is that in a lot of high quality apps, you know, the, the actual crash free session rate is, is quite high, right?

I mean, it's like, crashes are not in the grand scheme - they're obviously very important when they happen - but in the grand scheme of things, they don't affect that many users. Obviously there can be all kinds of other things that do affect users. The app is slow to load or the, you know, the network connectivity doesn't work or it hangs, or something along those lines.

So... I just wanted to get, you know, your opinion on how do you think, at that time, you know, how do you start thinking about all of the different kinds of issues that might lead to people complaining or dropping off, or all of those things, and how do you prioritize, I would say like the more obvious problems, crash is [00:14:00] obviously super obvious versus the less obvious problems - it's slow or it doesn't load well, or your conversion rate on the screen sequence is bad, or something along those lines?

Hemant Garg: Yes, there are multiple things, actually. Crash is one of the most critical thing, yes, that people cannot use the app if it crashes. But other aspects are equally important. For example, this is how I put it, frustration free.

Yep. Is the customer experience frustration free? Are they having errors? Do they have a path to recover out of the errors? And then the performance of the app. The perception of the performance, and then they're two different things. Is it hanging a lot? So all those different criteria went into designing one of the best apps, right?

Even today, I feel like people only focus on crash free, but it has to be frustration free metric. Now, what is the frustration? It could be just the user experience and how do you measure that is, what are the top business critical OKRs KPIs you want to set for [00:15:00] yourself and are the customers able to meet them?

For example, at that point, are customers able to create notes quickly. Can they create a note within five minutes? Can they see all their notes very quickly? When they click on a note, can they see the note? Are we losing their notes, like when they create a note? And if there was no network, what will happen to the notes?

Matt Klein: Yeah.

Hemant Garg: So all those different business criteria along with this, non-functional requirements of speed and frustration comes into play.

Matt Klein: You know... and, and I was gonna say, I mean, at the time, because we're going back now a bunch in time, that I would imagine that you had to build a lot of infrastructure to actually measure these things, right? So, I mean, I, I... Yes. I'm actually curious about that as well, is that, as we were saying before, like crashes are important, they're are small percentage of issues, it's relatively easy to measure crashes in the sense that you get the crash dump and those kinds of things.

But for all these other issues, I would [00:16:00] imagine you had to build like a set of analytics or tooling or whatever else to actually understand that. So could you, I guess, talk a little more about how you think about, you know, how to measure and understand these non crashing issues?

Hemant Garg: So yeah, uh, we had to build a lot of tools to figure out how do we even measure things and how do we even, and once it is captured on the phone, where will it actually go, where we can go and see, analyze it? So there, there were not many good real time tools available at that point.

Yeah. So we had to build our own things, which goes to big... this Apache Kafka? No, no Kafka, sorry... big data systems, it'll go to, it'll churn the data overnight and then you'll go and see the result after a few hours. Yep. And it was always a challenge that it takes like seven, eight hours to go and see the result of what you just released.

Matt Klein: Yep.

Hemant Garg: So those tools were pretty hard and, uh, we were trying to figure out how do we make it more real time so we can watch this live in action and [00:17:00] react to it. There was no firebase at that time, right? So we actually figured out tools where we can keep recording these actions locally on the device and then whenever a problem - and we also made a problem detector, like whenever we think a problem happened, then we figure out all the different logs, which happened in past, and then uploaded via email. Email was the fastest way to get...

What you're talking about

Matt Klein: Sounds a lot like bitdrift, but yeah, so like a very, very early version of bitdrift.

That's awesome.

Hemant Garg: Yes. And then we keep recording everything and we say, tell the user, ask the user user, you tell me when you think there is a problem, press this button. And then I will get all the logs via email. And we used to get a lot of emails and there was no email automation at that point. So we like literally read all the emails and then we kept refining those emails and the data of the emails like, let's do some more analysis right on the device when the errors happen.

Yep. So that when I get the email, I have this pre-analyzed... fantastic... sense of the problem. Cool. [00:18:00]

Matt Klein: It's... it's fun for me because obviously we, believe that that's a really important area to help people debug these systems. It's fun to hear about, you know, people that have built similar things in the past.

So I, I guess take us, take us on from Evernote. Where did you, where did you go from there?

Hemant Garg: So, after Evernote, I actually got.. a good degree and sense of... I can do... boldness, that I can do much more things and, at a very early stages. So I joined a startup where I was an early founding engineer.

The startup name was Relcy. It was into mobile search space competing, hoping to compete against Google and Yahoo and, and Microsoft. So it was a very small company, four or five people company, based in San Francisco. Though the company didn't last longer, it got wrapped up in one and a half years.

But the thing which we built, uh, as [00:19:00] part of the company was outstanding. The company focused on mobile part of the search and more personalized search results. At that point, Google search was mostly about web-based. You know, whenever you type Google search, it used to go to web and people can see the web results, the standard web results, and we wanted to make that search more focused on the mobile.

Can the search result be based in terms of the apps on your device? Can it be influenced by the data which you have on the device? And then can the results be handled on the device? Say, for example, if we search for how do I go to a location? Then the result will be Uber and you can click on it and Uber will actually book a ride for you to go there.

Matt Klein: Yep.

Hemant Garg: The company didn't do very well. We had to wrap up in one and a half years. We ran out of money because search is a very costly problem to solve.

Matt Klein: It, it also sounds like it's a little ahead of its time. I mean, you think about what people are doing now with all of the AI... AI models and local AI models and how all of that works.

I mean, it, it seems like we're actually [00:20:00] heading back in that direction at this point. Yes.

Hemant Garg: It was a very bold move. I think it was ahead of the time.

Matt Klein: Yeah. Cool. All right, so then what was next after that?

Hemant Garg: So after Relcy ... I joined this, another company. I wanted to try something new and Bitcoin blockchain was pretty, you know, happening hip and stuff.

So I joined this company called Gyft, G-Y-F-D. It was into porting, gift cards balancing system onto the blockchain. So they wanted to do a lot of things in blockchain. I joined this company and, uh, the goal was how can we... leverage blockchain to do gift card management and then sell it to enterprises like big enterprises like Walmart and Best Buys of the world.

The company... I was there for a couple of years... but the moment I joined the company, within few months, it got acquired by a big financial company called First Data. And they really [00:21:00] loved the frontend part of the company. First Data was traditionally a backend side of the company. They were the biggest, they had the biggest payment processing company in US, which you have never heard of before.

So, they were always behind the scenes and they bought bunch of startups to work on the frontend side of the world, like make gift card processing to... they also own this company called Clover, which was a POS system.

Matt Klein: Yep, sure.

Hemant Garg: Right? So I joined. First Data as part of the acquisition, and I grew up over there very fast, owning all of the mobile for First Data, and I became a Vice President of Technology over there.

Matt Klein: And, uh, you know, I - I'm sure we'll talk about it more, but was that your first experience of doing apps in a more controlled environment with like financial controls and all of those things? And I would, I would love to learn a little more about, I don't know, you know, what, what it's like to go from, I don't know, you know, fast-paced startup world - I know how startups work - you, you know, to, an environment in which you [00:22:00] have financial regulations and all of those things. I don't know. Like tell us more about what that transition was like, of like learning to deal in this new world of financial regulations.

Hemant Garg: You are absolutely right. It was a very different world than startups world.

And, uh, and, and the audience was different and the, the goal was different. So it was a very different world. Ah, A. the... the goal was never to ship something out. The goal was ship the best in class, more... regulated and make sure it satisfies all... it was back to Motorola actually, in a way.

Like make sure you're shipping the best in class, right? And... and, and it was not just about financial regulation, it was also about small company vs. big company. The big company has a lot of STLC processes back to the app world. And to be honest, I never went to those processes before joining First Data because Motorola was more not an app developer, right?

So we used to ship once in [00:23:00] six months. Here we are shipping once in a month and need to follow all these processes within a month. So the challenge actually became very big, that how can you do a similar thing as digital Six Sigma in a month? How can you do all those processes in a month and ship something and monitor that very closely for a, for a few weeks before you decide, oh, this is good, and we move, move on to the next one.

Matt Klein: Yeah... I mean, do, do you find in that environment... Because the cost of mistakes are so high in that type of situation. Could you talk a little more about... where did you find the investment was most worth it in terms of keeping high quality, for example, you know, pre-release testing or automated UI testing, or maybe, you know, having the right analytic system so that when I went out in the [00:24:00] wild, you could understand if there was, there were issues. I'm just trying to understand, , what it meant to be able to, you know, quote, go fast in that type of environment. Like what tools

Hemant Garg: helped you do that? Yeah, a lot of them, right? Uh, you had to rethink the whole STLC process.

Me coming from startup, I had to rethink the whole STLC process. And one of the goals which I had was, this is a big financial company, it's releasing once in two months, how can we go back to, you know, once in a month release? So rethink the whole STLC and a lot of things was around... stability and consistency and predictability of what you're gonna release.

So for all those things, you need tools before you release, and you need tools after you release. As you said, before you release, you have to make sure you've covered all your business-critical, all your security concerns, all your performance issues, your crashes, your top business cases. All of them have to be tested.

And thoroughly tested, and you need to have, a log of [00:25:00] whatever you have tested because this is what you have to maintain logs of everything which you have done. Uh, which you have to submit to regulatory bodies to test... or review. Uh, and if we had to invest a lot of those in tools, and the suddenly in that company the focus change now we cannot really build all these tools.

So we had to go and look outside what are the best in class tools available? And again, the cost became a factor in these companies that we can't spend a lot of money. So to find the tools which is best in class and yet cheaper to go and own and use them. Uh, and the tools which are also... compliant.

Regulatory compliant, yep. And security compliant. Yep. So all these things becomes a challenge for me and to go and find out, for example, what is the best observability tool available in the market, which is SOC compliant.

Matt Klein: Yep. Yeah.

Hemant Garg: Right? And, and similarly then, after you release, what are the tools which follows?

PCI compliance. Yep. Of course, PII compliance and, uh, [00:26:00] follows the HIPAA law and all those things becomes a challenge to go and find such tools. And how do you maintain all the different layers of... obscurity from all the people who can access this... data?

Matt Klein: Yeah. Yeah. It, it's... very interesting to me that in certain ways the industry has come a long way in terms of those kinds of compliance.

I think a lot more companies are getting, you know, SOC 2 a bit earlier than they might have in the past. But at the same time, I think, you know, there's such a proliferation of apps and systems and all of these things, that I - I think the, the chance of making mistakes goes higher, right? Yes. And, and that's actually, I mean, we're, we're like, maybe jumping ahead, but one thing that I'm curious about, and since we're already on the topic, is, you know, now that we've moved into a world in which people are [00:27:00] creating a lot more code with artificial intelligence, you know, like vibe coding, and one thing that I've been wondering myself, especially in these more regulated industries is I, I just feel like... the chance of mistakes around data leakage or security issues or things - I mean that, there's already been lots of random stories that I've seen, so I, I don't know. I I'm just curious to get your take, right? Like, do, do you think that in these regulated environments that, that the tools are gonna take longer to like come in that people will use the tools in a more regulated way as well?

I'm talking about the AI tools, right? Just to, you know, like how do you, how do you keep the quality bar? And it's not to say the humans can't make the same mistakes, right? It's more just trying to understand in this new world, are there additional controls that are maybe needed, right? Like when we're dealing in these highly regulated areas?

Hemant Garg: [00:28:00] Yes. I think you are now talking about what I'm doing now, right? So one of the top things in my mind is, sure, we have seen Cursor AI and Windsurf, they can write code very fast, right? And the developers are getting less and less involved into line by line code reviews. Like so they are like relying in more and more on AI to develop giant lines... files of codes, right? So the focus is more on what tools should we build to, you know, to add checks in place? Checks at every part of the SDLC checks about the, the code which is developed by AI is the best. It is meeting all the requirements. Is it meeting all my quality gates? My crash rate gates? My, my non-functional requirement gates?

And then we also have to invest in tools, which is more about mitigation of the mistakes. Because it's one thing to do a mistake and catch it. There's another thing, how do I mitigate it very quickly? Because we know that AI will do mistakes. It hallucinates a lot. [00:29:00] We know that with the pace we are moving on, there will be more and more mistakes. To make those mistakes less costly,

how can we also invest in automated observation and automatic fixing of these problems?

Matt Klein: Could you say more about that? So like in terms of... do you mean that when the code gets released, observing like differences between versions or like how are you, I guess like how are you thinking about observing problems? And by automated fixes are you referring to, like a feedback cycle where, I don't know, like crash or issue reports would be fed back into the changes that went in into it and then may maybe looking for potential issues? I'm just trying to understand a little more detail what you're talking about.

Hemant Garg: Yeah, so there are a couple of... ideas which we are working on. The very bare simple idea is this, right? Whenever you release something, you also have a backup plan. And with AI the goal is we will be [00:30:00] shipping more frequently now than bi-weekly cycles. So if you're shipping fast, you also have a backup plan ready. And when you ship something, now your AI is observing your... tool wherever your observability data is going. Yep. And if it sees your business critical use cases, let's say you have... 50 business critical use cases, now you're very closely monitoring those 50 test ca- use cases.

And if you see a blip on those, your AI can automatically switch back your build to the previous version and say, look, there is something wrong, let's go back basically. Yep, yep. So you're relying... so that's the very simple use cases. Now two is, let's imagine now it's a big decision to go back... for one use case, which is not doing well, but other 49 are doing well.

Then you can, it make your AI more intelligent to take a decision on which one you should feature flag off to go back to the previous one. I see. But let the - the other ones continue to - to grow, basically continue to... adopt.

So the third one is basically like among these, [00:31:00] let's say a crash is happening, right? Then... now today, we bring human in the loop to figure out what percentage of users are crashing. What is a business opportunity loss because of those users? Are those users just opening the app or did it crash? And at a critical business test case? All those scenarios can be now, you know, analyzed by AI very fast and can take a decision. Okay, it's a very critical crash. Let's go and fix the crash. Make a... make a PR for it. Yeah. Put it for review and push a new build quickly. Yeah. That's another mitigation way.

Matt Klein: Yeah... it is very fascinating to me, you know, how these tools are evolving and how they're being rolled out and, you know, I think there's gonna be a lot of changes.

I, I think we'll talk about it more... we skipped some critical portion of your career history. So I just want to talk briefly, from First Data then you went where?

Hemant Garg: From First Data I went to JP [00:32:00] Morgan Chase, the Chase Bank.

Matt Klein: So you, so you upped your company size even larger? Yeah, to...

Hemant Garg: I upped my company size... but reduced my role.

So I went from, from management back to individual contributor. So, I went there as an IC, as a principal engineer. And the, the goal was Chase is one of the largest banks and... their CEO Jamie Dimon... famously said to all the bankers, Silicon Valley's coming. That means get ready. All... all the old traditional banking companies, financial companies, are going to face a very big challenge from the new world companies like Robinhood, Wealthfront, affirm, and all these companies.

So he wanted to invest heavily into tech and the modern tech... principles to make sure the bank is also scaling and adopting these modern technologies and get ready themself. So I was [00:33:00] part, I was hired as part of this initiative.

Matt Klein: Yeah, I mean, when I... when I first started interacting with JP Morgan through my work on Envoy, I was, honestly, I didn't understand how many software engineers JP Morgan employs. I mean, it is like a very large number, and I - I think I'm just curious, being in a principal engineering role, you know, in like the size of that organization - I, I don't know how many mobile engineers they have. Hundreds of thousands, I'm sure - And...

Hemant Garg: no, no, it was a very small team, but go ahead.

Matt Klein: Oh, really?

Oh, wow. Yeah. Okay. So I - I guess then tell me more then, because I, you know, I know that I don't think it's public, but I know that JP Morgan employs tens of thousands of engineers, like across all of their websites and all of these other things.

Yes. So then I guess, you know, what, what was it like, I guess? You know, to be trying to modernize like, some of the technology within such a large organization?

Hemant Garg: Yeah, so when I joined Chase, the mobile [00:34:00] team was not very big. It was, I think close to 50 people. And yet it was very distributed working on different aspects of the mobile app.

Uh, and before I go there, actually, right? We all should take a step back and understand... Chase is like Alphabet. It's like JP Morgan Chase, umbrella company.

Matt Klein: Yeah. Lots of different pieces. Yep.

Hemant Garg: And within that there is bank, credit card company, home loan, car loan, commercial, financial. There a lot of companies internally.

But the mobile app was one. The flagship app was one. And the app was very, the team was very small - 50. The goal... was they're like, how do we first scale this team of 50 to 200? Because we all know the company knew that mobile is where there to invest heavily and go compete with the Robinhoods of the world.

And... what will it take in terms of people, processes, and is our tech ready for that expansion, right? Are we adopting modern code principles... tools, architecture right now? So I had like three goals given to me. Improve the tech so that [00:35:00] we can go compete with these companies... get us ready, the developer productivity style so that we can scale the team of 50 to 200.

Matt Klein: But when, when you talk about improve the tech, like that's... you know, that's a very general goal. And I, I think what I'm trying to understand is, in such a large organization, what were you... like you personally, what were you trying to achieve? Meaning, I can imagine you wanted them to be able to release the app faster with higher quality, or maybe you wanted to crash less, or maybe you wanted there to be less rage quitting or rage tapping.

I'm just like trying to understand is what did it mean to JP Morgan, right? To like "be tech forward," like what did you feel you all had to do to compete with companies like Robinhood?

Hemant Garg: Yeah. So, and by the way, I mean, Robinhood is just an example, not necessarily competing of course, directly with Robinhood.

Sure, yeah. It was... so [00:36:00] the goal given to me was... number one goal was stability. We want to ship, uh, monthly. The company was shipping quarterly before I joined. We want to ship monthly with more predictability and... and more features into it. So the goal was instead of 10 big features, we want to ship 15 big features.

Matt Klein: Yeah

Hemant Garg: monthly with higher predictability. So there was a very broad business goal actually. And then to achieve that goal, the number one thing is, do we have the right tools to measure? Like, are we success or not? Uh, so we had to go revamp the tools. We have to... I have to go and define what does it mean to be successful?

I, I mean, as you said previously, crash rates are not the only success criteria.

Matt Klein: Sure.

Hemant Garg: But the company was watching only the crash rates. So we said, look, let's expand. What do we really want to measure to be called ourself a successful release?

Matt Klein: Yep.

Hemant Garg: Uh, and get the right tools in place. And then go back and look at the code, like how developers are coding every day.

What is their SDLC process? [00:37:00] How do they code, they test, and they verify and how the codes get merged into the main branch to get released to the... to the production. So every aspect of this was under a lens to go and see are we doing the best possible way, so we are all gelling together and releasing something?

And I can go into more details of... I have to go get there.

Matt Klein: I think it's interesting, I think people will be interested, you know, you come into a large organization like that, you're trying to bring more modern development principles.

I'm just curious, what, what do you, was there one big bang or like, was it many, many small things? You know, I'm just curious, like what did you feel were the biggest benefits that you were able to change? You know, that ultimately... because I think what we're saying is we'd like to increase velocity and increase quality.

I mean, that's obviously what we want.

Hemant Garg: Yeah, yeah.

Matt Klein: But - but you know, it's like, what - what, what do you feel, as part of that effort, was the [00:38:00] biggest bang for the buck in terms of meeting that goal? Or was there not one big thing and it was many small things?

Hemant Garg: Yes. There was no one big thing. It was many small things and... it was, it was like changing the wheels of the car while we are running in the race.

Matt Klein: Yeah.

Hemant Garg: Like literally on the road, we're changing the wheel every release cycle and circle. Now this has improved. Now that has improved. So I can go into, uh, from my memory, like what are the major things we achieved? The number one goal was actually, uh, build speed.

How much time it takes to build and what - how our build teams are structured. Build scripts are structured, uh, because if developers cannot put the code quickly, they will not be able to compile the code. A lot of things about developer productivity, the builds have to be stable all the time. Nobody can break the build and go home.

What are the tools available to make sure that happens? It's the whole CI/CD pipeline. How do we set standards for here is unit test coverage. How do we set standards for, what do we observe when we put a code? Yeah. And how do we [00:39:00] manage our observability? That means, uh, when we release a new feature, I want them to observe every single major, if else pipeline and also major error codes, exception handling.

But once we, a product is shipped and stable for a month or so, reduced observability, we don't really want to see every if else after that. Then how do we really structure our code? This, the code was uh, I think six or seven years into the making and with a giant blob of code, basically, and nobody really understood, like if I were to make one payment related code change, what are the different effects it has?

Like what, what should the testing really focus on?

Matt Klein: Yep.

Hemant Garg: At Chase there were... at least 2000 test cases to be tested before we make a release. And the chunk of the quarter was about testing because it was a regulated environment and a banking application which cannot afford to crash or which cannot afford, like let user cannot log in.

So a lot of focus was on testing. And then how do we reduce the time from a month of testing [00:40:00] by really figuring out, okay, let's figure out this change affects these test cases, so let's focus only on these test cases and how do we automate them a lot?

So, and how do we apply modern testing principles of testing pyramid?

How do we do unit testing is the major one. Then integration testing, and how do we do a lot of mocking so we can do testing faster?

Matt Klein: Yeah. I - I think, I think that's what I assumed. Is, is that in that kind of organization, there probably isn't one big thing, you know, but it is, uh, certainly an effort to bring all of those modern practices in.

Hemant Garg: Yeah.

Matt Klein: And then to continue on and, and take us to where you are now. You're at DraftKings now, obviously. Tell us a little bit about what - what led you there and, uh, you know, the kinds of things that you're working on now.

Hemant Garg: Yes. So at DraftKings... we have five apps. And all these five apps, uh, are very highly regulated [00:41:00] and the complexity has become multiplied by 18 because Chase app was regulated by one body.

DraftKings apps are regulated by different states, every different state

Matt Klein: that's right, yes. Per state...

Hemant Garg: has their own regulation. So the, the problem just multiplied by 18 times. So one single login has got 18 different variations. One for each state.

Matt Klein: Do you, do you actually ship, I, I don't know. I apologize. Do you ship different apps for each state or is it one app and then basically it changes its behavior based on the location that, that, that the user is in or something along those lines.

Hemant Garg: It's one app. So app stores allows us only to ship one app, uh, for the whole US. So we ship one app and then it... changes the behavior of the app depending on where the user is, the location of the user. And location is the name of the game here, because states... wants to make sure that nobody's spoofing their location.

Matt Klein: I, I was gonna say, and I'm sure this is [00:42:00] proprietary and you can't share that much, and that's fine, but it, it, it is a really interesting subject to me is that I was gonna ask that is that even with GPS or what people can do on the phone, or however you figure out location, VPNs and all of those things, it's not that difficult to change your location.

So, you know, I - I don't know, you know? It's like, is that a significant portion of effort or are you able to say, you know, if the OS tells me X, Y, or Z, like that is good enough for me, I guess.

Hemant Garg: Oh, no, no. So not just the OS, right? So again, when state defines the regulation of geolocation, they also define what things we have to check to make sure the geolocation is correct.

Matt Klein: Interesting.

Hemant Garg: And they also have vendors which are licensed by states to be the authority to tell that... to us, like, is it, what's the location? So we had to use one of those authorized licensed vendors with geolocation.

Matt Klein: I see. [00:43:00] So...

Hemant Garg: outside, outside what we do

Matt Klein: and, and that changes by state. So, so, so you have to actually switch the code dynamically to figure out which provider needs to be used or all of those things based on it?

Hemant Garg: Uh, yeah. It's not that big of a problem because there are vendors which are licensed in majority of the states.

Matt Klein: I see, okay. Got it.

Hemant Garg: Yes.

Matt Klein: Got it. Yeah.

Hemant Garg: Yeah. But, but the rule to apply for each state differs, right? So some states will say, this much stringent check is okay. Some state will say, we can be a little bit relaxed.

Matt Klein: Yeah. And then I - I guess, you know, coming from your experience, obviously at Chase, you know, and helping to modernize that stack, I would, I mean, DraftKings has been around for a while, but I would imagine it is a more modern organization. So when you join. I guess, were there particular goals that you were hired to achieve?

Or like what - what, what have been the biggest things that you've been working on since you joined there?

Hemant Garg: So I [00:44:00] was DraftKings first executive in the mobile space and there was no other executive before me. And now we are growing and we are hiring more and more people. So there were multiple goals assigned to me.

Now, one biggest goal was make the platform. We had a platform before I joined, but it was a very nascent stage conceptive platform. So I have to make this whole mature platform, which can be used by multiple apps. And the platform has to be designed in such a way that it's scalable, it is plug and play, and yet it is very... say, stringent, in what the apps can do, what apps cannot do.

So that was a goal given to me, scale this platform, uh, have a very clear sense of all these journeys, and then roll this out to all the verticals, all the apps, basically.

Matt Klein: And I guess I would ask the same question about your experience at, at Chase. I - I guess in the last few years that you've been there, what, what do you see now as like the biggest challenges that people are [00:45:00] facing in mobile and frontend development?

I mean, it's like, what I, I guess what has been, from an - from an executive perspective, what has been your biggest focus on, as we said, ultimately you want to increase velocity, increase quality... so I guess what - what do you see as the biggest challenges right now? What is your main focus?

Hemant Garg: Leaving the organizational challenges outside. Yeah, of course. Like to focus, to focus only on the, the mobile... principle stuff, right? I think there is still a lot of options available. Like there's, there's no, there's no real consistency in how to develop a best mobile application. So there is no real guidance from Apple and Google, "this is how you write an application. This would be the best in class." It is left to people to figure out. Every company went through this challenge. It's like, I've seen this challenge in First Data, then at Chase, and now a DraftKings what is platform, how to use the platform, how to do an interface-driven programming.[00:46:00]

So I think that remains the biggest challenge. And then the second biggest challenge is, how do you really structure your code for your teams to collaborate and go faster? How one team cannot depend on the other team, how can they reuse the... or not reuse the same code base to go - go fast? I think those two areas are still the biggest challenges of good mobile, good and fast mobile development.

Matt Klein: Do you - do you think that, that's because I would say like the platform APIs and frameworks that, Google and Apple provide are not rich enough, such that then people have all kinds of other things on top, you know, whether that be different open source libraries or React native or whatever else, you know, that's, that's like one side or, I don't know, do - do, do you think that some of the more popular open source frameworks and libraries that people are using, that they're not robust enough such that every company picks and chooses? I, I'm [00:47:00] just trying to understand. Yeah. Why do you think that after so many years that there still isn't more consistency?

Because I agree. I mean, we also see the same thing where... it is all over the place, what people are using in terms of how they do networking, how, whether they use React Native or not, or Flutter or something else. There's so much out there and it is interesting because after, you know, 20 years of mobile development, you would think that there'd be more consistency, but there isn't.

Hemant Garg: Yeah. So it leaving React Native and Flutter aside because those are... cross vertical, cross platform.

Matt Klein: Sure, yeah.

Hemant Garg: technologies, right? Google and Apple... sure, Google still invests in this, but Google and Apple doesn't have a vested interest in making sure the cross platform works properly.

Matt Klein: Of course. Yep.

Hemant Garg: So... I think both Google and Apples designs, like the app APIs they provide, they work flawlessly for small applications.

They are main focus in how do we get more and more young native developers, entrepreneurs to start applications, which is like four or five [00:48:00] screens. They really don't do a great job in figuring out what happens when they grow beyond five. What happens when they become twenty, fifty, a hundred? That's where the problem starts happening.

They don't have a good guidance on here is how you do compilation. Uh, Google doesn't have... Google doesn't own Gradle, for example.

Matt Klein: Yeah, right.

Hemant Garg: They don't have a good build system. Apple very recently invested in this SPM, but still I think a lot of companies are not using SPM Swift Package Manager. Similarly, a - a lot of things about observability.

Sure, Firebase invested some

Matt Klein: Yeah.

Hemant Garg: Over there, but Apple has nothing over there.

Matt Klein: Yep.

Hemant Garg: So both these companies have designed tools for small... company startups, but not for big organizations like Uber, Google, Facebook, themselves, and DraftKings, right? So this is where they leave this challenge for individual companies to go solve and everybody solves in a different way.

Matt Klein: Yeah

Hemant Garg: and in everybody's mind platform is a different thing. Actually. When I came to DraftKings, it took me a long time to explain to people, platform is not just our core use [00:49:00] cases, like core use cases of DraftKings is user management, financial, marketing, deep linking. Platform is much more than that.

Platform is all about your core building blocks, how to do observability, how to do crash reporting, how to even compile the code. How do you put your build scripts? How do you make sure you have a - a great CI/CD pipeline? So platform is all these things together to make it always productive.

Matt Klein: Do you do, do you think that it's just a fact of life that not that many companies achieve the kind of scale that you're talking about? And that's just the way it's - it will always be? Or, I don't know, I mean, do - do you think that there are things that the industry at large can do to actually improve this?

I mean, one example is to your build point. I think most large companies. End up using Bazel in some form, you know? And

Hemant Garg: yeah,

Matt Klein: and, and it usually ends up with a huge amount of complexity and it doesn't go well for a variety of reasons.

And it's like, I guess what I'm trying to [00:50:00] understand is, do you think that these problems just affect relatively few companies and that's why there hasn't been a, hasn't been a solution? Or do you think that things will continue to get better?

Hemant Garg: Uh, I think if you look at the ecosystem the last five years, or if you go back to 10 years, a lot of Fortune 500 companies have an app, and app has been their major source of revenue.

Matt Klein: Yep.

Hemant Garg: So the problem is increasing day by day. And... the problem will continue to increase with AI there because now AI can create code very fast.

Matt Klein: Sure.

Hemant Garg: So everybody will have their own apps very soon. If they're not thinking about it, they'll think now. So the problem space is increasing bigger and bigger.

And I, I have a suspicion of myself, right? I have my own theory that why Google Apple doesn't contribute too much over there because they, they have also limited mind capacity to go invest... should they invest in their OS features? Should they invest in their... developer features? Or should we invest in their, you know, their - their [00:51:00] paid services, right?

So if they have to invest billion dollars, they say, look, let me go invest billion dollars in the OS so it helps everybody.

Matt Klein: Yep. Makes sense.

Hemant Garg: Right? And, and, they are giving chance to these other companies like Gradle for example, right? Or... your company, for example. They're giving chance to these companies.

Like you go and in a way and figure out the best in class, go work with all these companies and figure out what they really need, because every company's need may be different.

Matt Klein: Yep.

Hemant Garg: Right? They're leaving, they're leaving this for you to go do it. If they have to go and talk to all the app developers to do it, they will have to talk to like so many and they don't have the mind capacity to do it.

Matt Klein: Yeah, well, we, we could talk about this forever. I think that's a, that's a, that, that's a good place to wrap it up.

Before we end, any final... you know, parting thoughts that you'd like to share? Any hot takes about the future, where you think things are heading?

Hemant Garg: Yeah. I would say... the next... [00:52:00] growth phase is about how to use AI agents in mobile development.

Now, we are hearing a lot of things about AI agent, you know, AI is, AI is gonna eat the SaaS world, but none of them is coming to mobile development yet. But I think that's where the next phase of growth is. What can AI agents do with the mobile development?

Matt Klein: Yeah

Hemant Garg: that's, that's the take I wanna give to everybody to think about.

Matt Klein: Yeah. I, I also wait to see the same thing. Well, anyway, thank you so much. This was a fantastic conversation. I think people are gonna be very interested to listen, so thank you for coming.

Hemant Garg: Thank you for having me. Yeah, my pleasure.

Matt Klein: Alright everyone, well that's a wrap for this episode of Beyond the Noise Signals, Stories and Spicy Takes.

Huge thanks for joining and sharing your story. And you can find this episode and all past ones on the bitdrift YouTube channel. If you had fun, drop us a review, tell your friends or yell your favorite hot take into the void. Just make sure to tag us. I'm Matt Klein and I'll see you next time.

[00:53:00]