BUILD

SUCCEED

Jorge: If you get that sweet spot that with a very few but critical ideas, everyone gets like that aha moment, then it's how you can get 300 people to get on board and drive value for the organization.

David: Jorge, welcome to the podcast. great to have you here. given your leadership and, uh, at VGB and in the Flutter community and just as a good friend of mine. So, welcome.

Jorge: Thank you, thank you for having me.

David: Let's get us started. I know some things about you that maybe some people don't know. such as, in the background here you have some guitars. I know you're an avid musician. I've been in a band and also are a big time chef. I love making paella and other [00:01:00] things. And so to get us started I was asked, I was wondering, do you find any parallels between cooking and coding or, or music and engineering?

Jorge: Yeah, actually, I think that, have to understand that, like, it's very, I mean, you can be very precise, right? And if you want to do those things right, you can understand kind of, like, the foundations, but then once you do, there's a lot of freedom to go and explore, right? So I kind of, find coding, the same thing.

It's once you understand the foundations, you can all of a sudden, like, Go and explore uncharted territories and try to innovate and all those things so in a way like those activities that can be very stressful sometimes once you feel comfortable in that space actually can be very very relaxing right so you know it's something that like there's a lot of similarities there

David: Yeah, very cool. I mean, cooking, you have recipes, music, you got your sheet music, but both of them, you can do a lot of improvisation. And same with

Jorge: absolutely yeah yeah like that's why you [00:02:00] can think almost like You know, like a jazz improv session, like a hackathon, right? yeah, there's a lot of parallels over there.

David: Very cool. So you've had a very impressive career journey, to your current position at BGB. I was wondering if you could kick us off by giving us a story of how you got here and maybe, highlight some highlights, from your career along the way.

Jorge: Oof, how I got here. First of all, like it's almost a coincidence, right? Because I'm living in the United States and I'm Spanish. I'm from Spain. So, That's like the first thing, like how did I jump, like the ocean? I was studying in, in Spain, engineering, and like in Spain or in Europe, we have this thing called the Erasmus program.

In the last year of college, like they give us like the opportunity of studying abroad and get still your degree from your home school. So I was exploring that opportunity. But actually,the person that I was dating back then, instead of like, wanting to, go to Europe, she [00:03:00] was like, what if we go to the United States?

That was a big leap for me, not only because the education in the United States, it's quite expensive, it's because like, I'm the first person in my family going to college. It was like something totally, you know, pushing me out of my comfort zone. but actually my family was very supportive. Uh, this was out of, right after the recession, 2008.

Money was short, but they were like, Hey, this is your education. This is your future. You got to fight for it. I thought that I was going to be here in the United States just for one year, building my resume, just like, Getting my degree, but turns out that I got lucky. I found, after finishing my education in engineering, like a job in an advertising agency.

And that's how everything started. I was, like, very into Ruby on Rails back in the day, even though, like, actually I didn't study computer science. But anything, my background [00:04:00] is in telecommunications engineering. So, in theory, I learned how to put rockets, in orbit. Don't trust me to do that, by the way.

I think that they would not,they would not land.but, in that journey, I took a couple of programming classes. And, fun fact, I actually failed my programming classes, too, at the first attempt.

David: We'll cut that part out. We'll edit that out.

Jorge: Yeah. But, um, it's because, to me, they were very abstract, those classes. But, once I started learning about user experiences, Like how to build websites and all that stuff.

There was something that clicked on me. Like, all of a sudden I understand, what a link does, or like what a button does. And everything, like, everything clicked. And so I started working for this advertising agency, and that's how I got even introduced to this idea of, like, how to work for clients. How to be part of, a creative studio.

And that was super interesting to me, because, you are exposed to a blank canvas. And you need either to design [00:05:00] like a campaign or try to solve like a problem that doesn't exist. So it wasn't very engineering focused. It was a little bit more creative, but that already started giving me hints of what being a consultant means.

From there I jump into a company called SPR here in Chicago that is like a very well known like local Kind of like consulting company, and that is kind of like where like the first place where I started being a little bit more like hardcore into engineering consulting. I started working with Expedia.

Before it was Expedia, actually they were Orbitz, the kind of like online travel agency. And I got super lucky because I started working with the Android team, and this is one of those in which like even though I was the consultant, I feel like I learned from them more than anything. Actually, I was able to help them, and I can say that with the past of the years, but that's the reality.

They were a super talented team, very talented individuals. Many of them are now like in Meta, Google, like all of these [00:06:00] places, right? And that's like my first exposure to mobile development. I spent there like about a year and a half, almost two years. Then I moved to a couple of fintech projects around Chicago, you know, so like high scale apps.

So that was super fun to me and that's where I started doing like, okay, engineering work at scale. But not only like at scale, many of those projects, not at Orbitz, but like many of those companies, they had rescue projects. They were like companies that they were trying to move really fast.

They were scaling fast. Many of them they were about to go like public IPOs and they were in distress because sometimes like maybe Those projects they were not going as smooth as they were to actually one of them was a big Financial risk because they were reporting data that was not accurate and if they wanted to go public Everything needed to be really accurate, right?

So that gave me a perspective into like how to solve a problem that is really [00:07:00] like Like there's a lot of pressure, but there's also a lot of ambiguity. So how do you use all your talent, all the information that you can have and all the levers that you can pull to solve that as fast as possible, but also providing a solution that it's gonna work for years long, right? I love that, but then one day I learned that BMW was in Chicago. What BMW was doing in Chicago? I didn't know at that time. I learned about it later. Turns out that When Microsoft bought Nokia, Nokia had a small group here in Chicago, and as part of that acquisition, Microsoft said, okay, we don't need this tech team in Chicago, and like one of the executives from Nokia that moved to BMW was like, Well, we're expanding our technology team.

We need footprint in the United States. So we're going to expand our technology team and kind of like transfer this technology [00:08:00] team to V& I. They started hiding. They were already like working on an IOS program for about like. A year and a half, almost two years, but they didn't have any Android talent.

They were about to put the iOS team, the iOS project on the market, but they had no Android app. So they started hiring and that's how I got introduced to BMW.so I was the first hire for Android my mission was like, we need to release in six months and you need to build a team. Wow, big shoes to fill.

especially because, I started, like, hiding the team, but I also need to, part of the mission was, like, you need to upskill the team that we have already internally, so many of them, they didn't know Android, but we needed to, to deliver. And just to give you a little bit of the perspective, they were already working on iOS for, almost two years.

It was about a hundred developers just in the U. S. Once they started expanding internationally, it was almost like three hundred. And our Android [00:09:00] team was like six, seven people.

And they wanted us to deliver the same value.

David: Yeah. Classic iOS, Android, right?

Jorge: Kinda. But you know, we pretty much did it. Granted, like a lot of the things were already in place. Like all the backend services and APIs were there. We already knew the product definitions and we were piggyback, piggybacking on a lot of those requirements.so we were already able to make a lot of assumptions, but it is impossible to catch up.

That's the reality. And what we realized after two years of development is okay, we have the privilege of knowing what works and what doesn't work from iOS, but we're letting down the Android customers. It is true that like, if you look at the numbers, There's 70 percent of BMW, Mini, and Rolls Royce drivers use iOS, and that other 3 percent they use Android.

But if you look at the feature set, it's [00:10:00] impossible to match up your investment like it's like 80 20%, right? I was very vocal about like, hey, this is not just a matter of putting more engineers or anything like that. Like our customers are complaining, but also like it's a problem for the company. Once we realized that, this application was, like, a source of revenue for BMW, MINI, Rolls Royce, but not only even for the brands, for the car dealers, for a lot of people, in that ecosystem, right? And you're, like, missing out on 30 percent of that revenue. There's a lot of people saying Hey, I want that piece of that pipe.

We even had our own internal efforts to do something custom with web frameworks and all the stuff, trying to see if we can help iOS and Android to ship at the same time. That experiment did not work that much. And that's how we start exploring what can we do.[00:11:00] 

David: And 

Jorge: to tell the story further?

David: Yeah, let's do it. Let's get into it. Cause that's why we're here. I mean, ultimately that, that, uh, is the critical, part of the story that, that ultimately leads you to VGV and the time that we've spent together and so, yeah, I think BMW is a extremely early adopter of Flutter. And I think that's something that a lot of people don't.

remember sometimes, or it's not as celebrated as much as it should be. There's a handful of firms out there, like BMW, Better, and a few of these that really took a risk on it very early. And so I think finding the people who took those risks, it's not only interesting around Flutter and like what is good about Flutter, but I think that there's some insight to be drawn from what was that situation like and how do you, Help a gigantic organization with the complexity and the scale of a company like BMW to embrace something that is Very transformative very risky at the time and we can look back now and be like well Yeah, now tons of companies use flutter.

It's a very it's a very safe choice now, but at the time It was not a [00:12:00] safe choice. I think there's something really important to unpack there Around how do you, that's innovation at its core. it's, innovation is not following because every, all of your competitors are doing it, right? Innovation is taking that bold risk when no one else.

So what was that situation like, and how did you get that through?

Jorge: Yeah, so let me set the context. This is 2017. So, almost 8 years ago.When we talk about BMW, as a technology company, or actually, like, what I was responsible for, is not just BMW. BMW owns BMW, Mini, Rolls Royce, Mercedes Benz. But also, sometimes these, car manufacturers, they do collaborations between brands.

So, for example, when I was working there, there was this collaboration with Toyota, that was the Toyota Supra. So, actually, the Toyota Supra, it's almost like a BMW C4. with a different body, right? So that was [00:13:00] another app that looks like a BMW app, but it's branded for Toyota. So why do I say this? It's because when we talk about the code base, it's not just one single code base.

It's actually a wide label structure that serves all these brands. But then on top of all those brands, we have to introduce regional variants. North America, Japan, Russia, China, Mexico, rest of the world. The applications in those countries, they look very different. Like here in the U. S., we can use Google services and you can partner with Amazon to deliver to your trunk.

But in China, there's no Google services. You have to partner with AutoNavi for navigation and you partner with Alibaba for like deliveries and all that stuff, right? So there's a lot of complexities, both in the backend and in the frontend. So when we talk about complexity, I can tell you that [00:14:00] with one single code base, we were actually creating, I think, 49 different applications . So let's put that in context. 49 different variants of the app with different themes, different brands, different regions in 2017, 2018.

David: then, because you gotta hit iOS and Android.

Jorge: There you go. Flutter in 2017 2018 wasn't even on beta.there was no null safety. There was no support for Google Maps or no maps at all. There was no state management. There was no Flutter blog. There was no RiverPod. There was no provider. Nothing like that. So, what was the challenge there? Like, we knew that the organization not only wasn't shipping features like fast enough.

We knew that we were not like servicing our customers. We were not only like servicing like even these platforms enough to make the revenue that we wanted to make. So our CTO at that [00:15:00] point said like, hey, we have a problem that not only our customers are realizing, even us internally, we realize that this is not happening.

So he appointed a few people from different disciplines, almost to start like a research and task force team with the mission of like, we need to figure out What's the next phase of digital development for BMW? And these are the constraints, or these are the goals. We need to ship iOS and Android both at the same time. We want to ship always at the same time. We want to be able to ship in every region, almost whenever we want, for every brand. And we don't want to lose that luxurious element that comes with the BMW, Mini, Rolls Royce brands. www. microsoft. com And you have between four to six months to determine what that [00:16:00] feature looks like. It was an open canvas. So within that team, like we had people from a web background. We had people in my case that was coming from the Android team, but like I also had iOS experience. And then we have folks from iOS and then some other, even from the backend teams as well. So we're like a multidisciplinary team.

And we just started like. Testing out everything. We wanted to be super open minded and just, be very data driven. We started collecting and testing out, every framework. Ionic, Cordova, Funga. Even, we challenged our own native strategy and tried to figure out what is the best way to ship and deliver.

And after all that research, we found our golden solution. And it wasn't flattered.

David: Cliffhanger.

Jorge: There you go. We actually did it. And I think it was out of fear.we found this framework [00:17:00] for Uber called Uber RIPs.Uber in 2016 did a huge rewrite of their application. like back in the day, like they did a big refactor, like also the UI UX experience was very different and they use these RIPs framework that is a cross architecture solution.

So they still build their, applications in, Swift and, Kotlin. But the architecture across platforms looks identical. But they still have their native talent build their applications with those languages. What happens is that, we knew that, from an engineering point of view, we wanted to avoid the mistakes that we made in the past with iOS and Android.

We used, heavily React, Reactive Programming, and that introduced a lot of problems. Because we knew that it was a very powerful tool, but it was very difficult for many junior engineers to use. And even for experienced engineers, not only to use it, even to teach it. It's okay, you can do a lot of [00:18:00] cool things, but it can be very difficult.

damaging for the code base. It was hard to scale. So when I look like, okay, we want to state management that looks like simple to use, small API footprint and things like that. And like Uber Rips gave us that ability. So we started like experimenting and we're like, okay, we can build like clean code.

We can do all those things. And we had a POC, it worked wonders and all the stuff. And when we were about to show that solution to our CTO, we were like, but wait a second, we're actually going to be in the same problem where we are today. That is like the business organization is going to invest more on iOS.

Then Android. So it's not a problem of code. It's a problem of investment. We cannot give them, even like the minimum option to invest more on one platform than the other. And at the same time, [00:19:00] I think that us, out of fear, we were native developers. Part of our identity and our success was attached to that platform.

I was going around the world doing talks like Android Cons and Android Summits and all the stuff. I didn't want to leave. That brand, to be honest, like I was almost famous. Like I was going to, someone asked me once to sign an autograph and I don't have a big ego, but that's pretty cool.

David: Totally,

Jorge: but like, we challenged that assumption and we went back to the board and we said okay, no, let's go back to the data because the reality is like with this solution, we're not going to ship faster and probably we're not going to ship better.

It's just like a refactor of what we have. We can re challenge the technology mistakes that we made, but we're not gonna fix the business mistakes that we made. And that's ultimately what got us here. This was not a technology problem. [00:20:00] It was a business and technology combined problem.

David: I think, if I can, that's a really insightful way to think about it, because I think when people talk about the challenges they face with their products, it's easy to look at the architecture, how they did it. And when you think about rebuilding, you know, people even like looking at a cross platform framework or some, whatever the newest, latest thing.

You can look at the technology and does the technology save the day? And the truth is, the technology is just a tool. You can get the benefits that you can get. By two native codebases, if you just do it right, and if you solve the business system around it, right, the communication structures, how you plan, how you collaborate.

I think it's just, generally speaking, when you move to these tools that are cross platform, it reduces a lot of the complexity just in terms of the communication pathways. But I do think people put a lot of pressure on the technology to solve the problem, when really it's the people and the business problem.

So that's really insightful. Sorry, keep going.

Jorge: Like, I know absolutely like [00:21:00] 100 percent and as part of VGB that sometimes We had to play that role of like how can we convince people that this technology versus the other might help them to achieve their goals. The biggest factor that we have to introduce is not like whether the technology is going to help or not.

It's like the fear that individuals might have to lose that identity, right? So that is something that you have to consider. But yeah, pretty much like we went back to the whiteboard and what we realized is okay, we need to fight a stigma that exists against cross platform. Because the reality is like cross platform solutions, PhoneGap, Cordova, Ionic, they were not great. We, my, BMW was a Microsoft shop,we're known for, being like a big, Azure, company. We did many workshops with Microsoft to explore, Xamarin. And [00:22:00] even they were, like, the ones telling us, Xamarin is not gonna scale with you. Which I really appreciate the honesty.

David: Mm.

Jorge: that was probably the best thing that they did for us. Because if they hadn't told us that directly. We would be like, B& W would be overriding today a Xamarin app.and that's kind of like when we were like deciding between Flutter and React Native, we were like, actually, they're both really good contendants. What's going to give us confidence here. And that's when we started like measuring developer experience, like the capabilities of the framework. Will it go beyond mobile? Because for BMW, actually the biggest amount of screens, they're not on your phone. They're on the vehicles.

so the biggest UI development is for the vehicle, not for the phone. And there was something about Flutter that just gave us, like, maybe we need to reevaluate how we were thinking about Flutter, [00:23:00] because all the things that we loved about Uber Eats.

It's like that ability to separate your UI code into smaller components, like the structure that it gave you as a tree, the way you perform dependency injection, all the stuff is something that actually Flutter and Dart were giving you. And that's something that like with React, which has a similar approach, JavaScript, TypeScript, even though it's probably like more widespread as a community.

It leads to like darker, more obscure patterns that it's probably like a little bit harder to just scale. Like we thought that Dart was very, very, very simple. Like we always say that if you know how to code congratulations, you'd know how to use Dart because it's that familiar already. So we expanded actually the research team.

that's how we actually integrated Felix on our team.Felix, who we actually tried to recruit for my Android team, joined us at that [00:24:00] point when we were already kind of like almost set with Flutter. And there was this time where the organization was like, Hey, you guys have been working on this for six months.

We need a go, no go. And we had compiled all this data that point after point said that Flutter is the right choice, but there was a lot of fear because still, wasn't on beta, there was no support for Maps and what if, this POC says that is right, but then three weeks from now, once we start scaling a little bit, let's not forget that we were talking that we're going to offer this to 300 plus developers, A.

What if at that point, it doesn't work? You don't want to have your name associated to that, right? Like when you're like six, yeah, it's a controlled environment. But once you open like the gates, it's a different story. That's the only time that I've been in a meeting with someone yelled. [00:25:00] And I was like, thank you.

David: hmm.

Jorge: it was a go, no go meeting. And of course, like developers, we have a lot of opinions. And we were incapable of just kind of like, Figure it out how to break that loop and one of our senior architects hit the table with his fist He said we are Technologists and if the data says that Flutter is the right choice, we gotta try and since that day including myself, we're Flutter engineers, we're Flutter advocates, including Felix, which he didn't want to do Flutter at the beginning.

He was like not really convinced that was the right choice, but that's what we needed. Like we needed a little bit like that. Let's give it a try. And actually our CTO was very supportive. He was like, Hey, you guys, let's go sprint by sprint. If after one sprint, this doesn't work, we'll figure it out. If after the second sprint, this doesn't [00:26:00] work, we'll figure it out.

Turns out that after the first release, It worked. Second release, it worked. Scaling to 2, 3, 20 countries, China, 7 years later, BMW has never had better reviews for their mobile apps than what they do now.

David: Yeah, I was just looking at it. on iOS alone, two hundred, about two hundred and eighty one thousand ratings, four point nine out of five. Not

Jorge: Exactly. And, I can say with confidence that making that decision, being part of that team, is one of the highlights of my career.

David: Well, you've highlighted a few things there that I think are important. one is you took a methodical approach to get data. Right, so to even be able to have that point where they can bang the fist on the table and say if the data supports this, we should make that call. So you guys were able to get the space to collect that data and have that data driven mindset to do it.

So I think that's maybe point number one for somebody looking to do something innovative or risky, is like, how do you collect the data? So that you can make the choice based on data and not just who likes what. [00:27:00] A lot of technology choices, whether we like it or not, I think are made by the senior people on the team or whatever's cool and new and whatever they like right now.

You know? so that's number one, data. I think the second thing is, like, firm decision making. Right? Like that, to get all in the room and have that go no go moment where you have to make a call. Yeah, otherwise it can just languish and you never take that next step. I think the other thing that I've heard from other people that we've talked to that, that you're describing there is the The space and the belief from the leadership. to let you explore and try it and have the, uh, the, the room to let it materialize and really prove its concept. I think, you know, sometimes people set really aggressive goals or deadlines or outrageous sort of objectives that are hard to know. And, and like that risk of failure, that sort of, the safety of, Hey, we're going to explore this.

And if it doesn't, Go right. That's okay. That's part of it. You know, fail and learn and, and to some extent with the Uber solution you guys had, you kind of had already gone through that process and that one didn't quite work out, you know, but you had, clearly, uh, [00:28:00] a leadership and team structure there and culture of experimentation.

And I think that's like really important that engineering leaders out there really evaluate their own culture. Like, do they have that culture of where failure is acceptable and because you want to learn from it, you know, and you have to take those risks and explore. 

Jorge: And then I think that though, that was a journey that to me, like those six months, they transformed me. I think that to me was so transformative because it's what made me almost start growing for the first time as just thinking from, oh, it's the code what's important, and start thinking more as this is how technology relates to the growth of a business, or this is how technology impacts.

like the opportunity for our business. And I think that moment for me was crucial just to connect the dots, right? Like, I think that level of maturity is something that was a game changer for me because leadership was talking to us straight with clarity. [00:29:00] And I think that it also set up a place in which like everyone felt that had a level of ownership and agency that was incredible.

We felt like we were, like, we had a. a say in that part of the process, right? But at the same time, we felt like, and probably they were feeling a lot of pressure too, but they were doing a great job, not hiding that pressure, but like, they were never pointing fingers or putting that pressure on top of us.

And I think that is something that I also take with me, hopefully, as a leader,

David: hmm, yeah, I mean, we gotta keep in mind, we gotta reiterate what you're saying. That was eight years ago, at the time, that was a very risky choice, and so first of all, if anybody out there is considering Flutter, you know, you got, BMW had this incredible outcome in a moment when, you know, You know, you were doing your own data.

You didn't have market data you could rely on, so the question would be, like, if you're a company out there doing, like, well, what are you waiting for, [00:30:00] you know? You got eight years of data that says this is a good thing to do. so, lots there to unpack, but. Since then, eight years have gone by.

You know, you continue to grow and scale that team at BMW. and, had the success that came out of the outputs of you guys going through that process of selecting it, setting it up, building it, deploying it, getting it all out there, and then ultimately landing on BGV and being here now for four years or so.

And, when, I'm curious, when you look back from like where you are today, It sounds, you know, you had some kind of key takeaways, like those formative years or that experience you went through, if you were to distill out how it influenced your engineering approach or your leadership approach, are there like some key things that when you reflect back, like that, those formative moments that change really, like what was the key pivot?

Jorge: Yeah, I think that, to me, there's two things where, BMW in those years, shaped, the way you think about these things, right? I think that the scale of BMW is something that not that many people get to experience. [00:31:00] And sometimes we think of companies like. Meta, Netflix, Uber, those companies that are like massive and complex. Actually, those companies, in a way, they might have it easier because they're technology focused, they're modern, and they've been born out of like a technology core. BMW is like more than 100 years old. And they're a hardware company, they don't know to build software as well as they do. Build vehicles. So you're trying to transform a company that is not moving at the speed of like those companies and you're still trying to innovate to transform something, right?

So to me, what I learned from that is you're going to work on something highly complex. So if you still provide a very complex solution, that's not going to scale. So you need to figure out how to provide a very, very simple solution. that is going to scale to a very [00:32:00] complex problem. If you get that sweet spot that with a very few but critical ideas, everyone gets like that aha moment, then it's how you can get 300 people to get on board and drive value for the organization. Now, if you get something very complicated for something that is already very complicated as a solution, Then it's when two years from whatever you decide to start that project, you're going to be already working on an application that is like 2. 5 stars, that doesn't scale, that your product organization is going to be like, hey, that rewrite, that refactor, that new product was a failure.

David: I've heard you talk about that a lot. So much of what we do is this core of scalability, right? And how do you, and simplicity. How would you define scale when it comes to a codebase? In terms, what does it mean for something to really be scalable? Because people [00:33:00] might think about code and it's like, well, I deploy this code and I can, you know, using cloud computing, scale up a bunch of instances.

And so I can get more users and concurrency and stuff like that. But I don't think that's how you tend to describe scalable code. And it's not like horizontal scale of more people using it. How would you describe it?

Jorge: I mean, you can think of it as like the scalability of the system. And that might have to be more with like how you are setting up the infrastructure. But when we're talking about the context of a mobile app, that actually doesn't apply. Because you're not going to be talking about how many cores, how many instances you need to deploy in order to, just respond to the request that you're going to be receiving, right?

a mobile application is a different beast. You're going to be working under one single executable. So to me, it's like, how can you help one [00:34:00] or a n number of developers? And that n number of developers is unknown. For a startup that is just about to start, it might be just one, it might be two, it might be three.

But for a company like, I don't know, American Airlines, depending on the product, it may be 25, 50, 100. So how can you build a foundation that without pain can help you to achieve those goals along the way? And I do think that there's a series of like steps and rules that without over engineering can help you to be prepared. Because I think that's when like people get oh, you're over engineering for something that is not going to happen. And I do agree there's like over engineering steps that like, it's too early. That wasn't necessary. But there's some other stuff that is you're almost getting the, like, if you apply this change, that is almost for free. You're just preparing your case in case of whether that's going to happen [00:35:00] or not. But like, it's not introducing either like pain points. It's not introducing like anything that is harm to your code base. And still, it's going to set you up for success. Whether the day you have one more developer to talk to.

One less developer is going to be contributing your code base, right? So to me, scalability, depending on the context is something different, but in the context of like user experiences is organizing your code base in such a way that everyone that is going to contribute looks at the code base in a relatively short amount of time.

And if you like, Oh yeah, my, they asked me to contribute in this particular feature and I don't need to have the whole context of the code base to be. Targeting to where I need to contribute.

David: Yeah, I read something recently. I don't know the actual number, so I'm not going to put it out there. Or certainly won't be held accountable to this number. But it was like, an engineer at a big company ends up spending like 10 20 percent of their time [00:36:00] actually writing code. And the rest of the time is like, understanding.

what to do and what's going on. So the more you can In your engineering, make it so that understanding is easier and more consistent. just even a 5 percent increase in developer productivity time.

Even just a small percentage across a very large team. That's like real business impact. so yeah.

so given the name of this podcast is Build to Succeed and obviously you're an engineer and you've built a lot of things, both through the experience here at BGV and in your history, what do you think, what does success look like when you're building something? as an engineer and as a leader of an engineering team, what is success really?

Jorge: It depends on the context. And, for example, for us as consultants, it depends on the context of the client. Right? And that is something that we have to understand. if we are working, let's say, with a [00:37:00] startup that is trying to make a dent in the world, It might be how to find market feed as soon as possible because they have runway and they don't want to have like infinite like expenditure or something like that.

But you might work with a different partner that they're in rescue mode. It's like, okay, how can we stop bleeding as soon as possible? Because we need to turn this around and start adding value for the business, right? So to me, like in the context of consulting is like, How can we help a client to identify not the symptoms but the true pain points and then orient, in this case, the technology group or product teams or whatever to truly solve that, right?

Now, if you're building, in that case, say, like a different product or something like that, it's trying to identify where do we hit that, that sweet spot. But, like, I think for technology teams, the way I try to coach our teams, what do we do with technology? that is going to help us to [00:38:00] ship faster and ship safer, right?

Ship faster because the sooner we can just go to the market, especially we can say with confidence in partnership with our product teams that we're adding value. Let's be honest, the more revenue, the more profit we can bring to our business. And that idea of like ship safer is that what can we add to the process without losing velocity.

At least maintaining velocity that is going to help us to release every single time with more confidence, right? Because what we don't want to do is to just put a release that may be detrimental to the business, to our customers, that all of a sudden gets us farther away for the particular goals that we might set up for that business.

So to me, that's what success looks like. Yeah.

David: You could look at that and say, well, we, one way we could ship faster is by adding more developers, right? Or we could ship safer by [00:39:00] having more testers or something like that, right? And we can solve it in a different, a bunch of different ways. I think that was the way that a lot of people solved problems for, For a lot of the last decade, especially with like, you know, more offshore developers and you can just, Oh, I'll just hire a hundred more developers and, you know, we'll just go faster that way.

And I'll hire a massive QA team that will feedback that way. But those are not sustainable solutions, right? Because they don't scale, they're expensive, people are almost always the most expensive part of a technology solution. So that's where the tools come in. Come in and making sure that the culture, the teams, the dynamics, and that's a theme sort of throughout your, your story today is, is not just the technology.

It's like how you use it, the teams around it, how you think about it, how you communicate this safe space you create for risk taking and for experimentation and use the technology. Not just for the outcome, but to make your team itself also better.

Jorge: Yeah, it's that how to balance that strike between. The talent, the tools that you use, like [00:40:00] using Flutter has been a game changer because all of the sudden you can, if you're building iOS and Android, you can target two products at once.

David: But the wrong talent might actually help you ruin two products at once, right?

Jorge: So it's a very twisted way of looking at the same thing, but that's the reality. But if you have talent that can help you even to move faster, the gains that might not be 50%, maybe even more 60, 70%, because you can move faster in targeting like a larger surface of platforms, right? Then like the tools that you incorporate to the process, right?

Like even with A. I. now we have assisted, coding tools, assisted like feedback on pull requests and like CI, CD and automation and all those things, right? So there's always like gains that we can add to the system that can help. engineers to focus on like how to solve those complex problems where like the technology itself in isolation doesn't [00:41:00] add that element of creativity and only like a human brain can add, right?

To me, I think that we're going in that direction, which like that's where let's solve the big, hairy, scary problem. That's where we're going. And I think that is not something that sometimes you just need like more talent. That's another variable that you have to scale. But if you always pull that lever, it breaks at some point.

David: Yeah. Let's wrap up on that note then and say, you know, you were on a team and you were a key contributor to a very risky choice, a bold choice, an innovative choice back in the day. And then that unlocked eight years of career growth and development and riding the wave. One of the, one of the early people to put a surfboard on the wave of Flutter and ride that.

And, you know, I think when you look back, Flutter definitely has disrupted how we do user experiences and what teams can do and, and, you know, yes, there's many ways to do it, but it's certainly a great way. And there's a huge amount of advantages to it that have really benefited both of us personally and the teams that we work with and the companies we've [00:42:00] consulted to and every, all the teams using Flutter.

When you think about now where we are, do you see any other Flutter like revolutions happening out there? like waiting in the wings that are gonna, you know, that is sort of a bold choice, maybe right now, that a company could be looking to do with their software and just generally are, is the world ready for these things?

Like,what's next and, and how do we use it? Yeah.

Jorge: it's time to dream, huh? I think that we're in a very interesting point, when it comes to, experiences. because I think that the two dimensional world, it's very mature at this point. everything that we see through a screen, like web experiences, mobile phones, they're quite mature at this point and actually that's where you see probably less innovation and that's why tools like Flutter can exist because now they can solve the productivity problem.

But now that's where you see like experiences like glasses, augmented reality popping up and [00:43:00] it's still not clear in which direction they're going. And that's why people are taking different alternatives, different risks. And we still don't know which one is gonna truly land. You see like Megra trying like their glasses and Snapchat trying something else.

Back in the day Google Glasses, right? And Apple Vision that it's like a complete different headset, right? So to me there's gonna be something about that direction, in which like that idea of like wearables might introduce like a new platform. That maybe Flutter can even complement or something Flutter like, but I think for now to the experiences like Flutter is checking the boxes.

If there's a competitor like React Native for like even something new, probably like it's going to be more like how tobuild on another abstraction layer, like better APIs, but as a concept I think that we're already kind of [00:44:00] like in that space where It's pretty strong. Now, to me, there's a space in here, especially with A.

I. that, I still think that is quite complicated, that it's cloud. if you look at, like, the different cloud providers and their catalog of services, you need almost a PhD to understand there. And maybe this is my own personal battle, but, the promise of cloud was, like, this is going to be easier than, owning your own servers. I don't know if it's easier anymore.just like, there's 20 different types of databases, and 20 different types of storage, and Kubernetes, and managed deployments, and all that stuff, I think that it's a beast that we're not, moving into a simpler problem, even though it's a complex problem, but I don't think we're offering necessarily a simpler solution.

So to me, 

David: are, those are not driving towards simplicity at all. They're [00:45:00] driving towards more options.

Jorge: and there are tools like Firebase, for example, like that, they offer like a lot of simplicity in that space, but it's not solving the complex problem. I think it's just because they're reducing just to a limited set of options. Oh, if you are like a, especially like they work really well in Hey, you're building your Greenfield project for the first time.

And. If you're this type of kind of like project, startup, and all that stuff, right? So to me, that is an area in which like I would love to see way more innovation. Just it feels like you can scale and do something that is still sophisticated without needing to deploy an army of tools and engineers and all that.

David: Well, that's awesome. thank you, Jorge. This has been such a insightful conversation. I think hearing the story, your experience at BMW is like an OG Flutter experience getting or very early on. And I think you and the team who did that are unsung heroes of unlocking, uh, this new technology for thousands, hundreds of [00:46:00] thousands of developers and teams all over the world.

Really appreciate you sharing that. I think a lot of people who are either invested in the Flutter community already or are thinking about it have a lot to learn from your story and your experience, and so that's what this is all about, is getting that out there and unpacking your insights. I know we didn't even talk about the last five years of your experience at VGV, so I think we're going to definitely have to do that again.

But I know people are going to take a lot away from this experience, and that's why I think it's really important we highlight it. Those early moments because so much of your philosophies, I think, and your approach that you've driven into the BGV team, really, the seeds and kernels of those were back in that experience and it really helped unlock it for a lot of people.

So thanks so much for spending a little bit of time and telling the story.

Jorge: Sounds great. Thank you for having me.