BUILD

SUCCEED

David: [00:00:00] There's another engineering principle that is called like product ownership or end to end product ownership. That's like more than being, an engineer, you are a problem solver. Hi, I'm David. This is Build to Succeed from Very Good Ventures. Today we speak with Tiago Ghisi, Director of Engineering at NewBank. They run an app that serves over 100 million customers on multiple platforms in many countries. With a thousand screens and delivering updates every day. We're going to dig into how NewBank manages this complexity with Flutter and server driven UI, and stays at the cutting edge of mobile.

So let's get into it with Tiago. Okay, Tiago, welcome to Build to Succeed. Thrilled to have you here. Um, you've had just, uh, such an awesome career. I know you were at ThoughtWorks, Amex, Apple, now NewBank. All incredible companies, just amazing, uh, resume you've got. And so, um, I wanted to just get us started by maybe you could take a look back and kind of tell us a little bit about your career, all the places you've been, and maybe some themes of your career that you've [00:01:00] identified over time.

Thank you.

Thiago Ghisi: Amazing. 

So, thank you so much for the invite, David. It's a pleasure to be here. I think, like, you, you're doing an incredible job, like, by interviewing folks on the mobile slash Flutter community, and it's a pleasure to be here talking about what we are doing and my career in general. So, I think, like, my career, so I started Almost 20 years ago.

I would say I was the typical, started with like Java, then kind of like did web, then like did QA, did other things, and then eventually, maybe back, I don't know, it was 2009, 2010, started work even before Android with JavaME, right? Did some projects back in the day with that and then transitioning to Android and then like, After that, I did a lot of like full stack engineering, like migrations to the cloud.

I'm a very generalist person by heart. [00:02:00] And, over the last, I would say seven, eight years, I have been on the engineering management path, so. More on the managerial side of things, but still pretty much working with mobile all this time. So like, even though I, I'm not, and I'm generally against like people that only work in one platform.

I have been working a lot with mobile and a lot of fintech over the past like eight to 10 years. And like to, to talk a little bit about my career, I think like two general themes that I. That I have identified to myself, and I have written a lot about this. I think one is, is about kind of like being the glue person.

And like the other one is about being a full stack, engineer, or I strongly believe on the idea of being a full stack engineer. Not a [00:03:00] jack of all trades, but a jack of many trades, a master of some, right. And I try to apply that into my career, like moving from, let's say, mobile to infrastructure, to sales engineering, to consultancy, and like going back, you said ThoughtWorks, I think like have been a consultant myself.

That's also been a great background to me. Like, I think like. The idea that I had to work with clients in the past and have seen other very senior engineers acting in, like, more in a consultancy mode gave me skills, foundational skills, I would say, that prepare me to then be a, a good engineer and especially a good, manager and director, and on the other side, on, like, being the glue person, right, I think, like, I always try to be the person that was filling the gaps.

Even if they are not part of my job description, right? Like I think Tony Riley has this amazing talk called Being Blue, right? That's about, it's all [00:04:00] about, it's not about kind of like how you grow using that as a leverage, but it's more about how sometimes people like women or like diverse or like minorities in tech get exploited because they end up doing all those words that don't get recognized.

As the, they're trying to be promoted or all those things. Right. But I think like there is an upside of doing that because like you ship a lot of projects, you become essential and you can navigate across the end to end. I think like having that like end to end ownership of all the projects of everything and being able to do the 80, 20, like you're not expert by any means on everything that I did in my career, but I know the 80, 20, right.

I know, like. How to do many things and in some areas I can go very deep, not in all areas. So I think like, those are the things that I would say that allowed me to grow in my career and RCO kind of like teaching me lessons again 

and [00:05:00] again.

David: I love that. Yeah, I think a lot of young developers, we, you and I maybe came up through different times, and if you're a young developer coming up now, you might feel the pressure to specialize super early, and, yeah, I, I agree. I think you gotta get a nice rounded perspective. It's the only, like, if you're just doing mobile development, and you've never done any back end APIs, it's maybe hard to know what the peep that team is facing, you know?

yeah, yeah.

so you're kind of describing that like T shape idea, right? and I love that idea of like, maybe not jack of all trades, master of none, but maybe jack of many and, you know, maybe king or queen of a handful of them, you know, if you're going through the, for the card deck metaphor.

Thiago Ghisi: And David, I think the pressure to specialize was always there, at least in my career. I think I was always like, there was always more attractive to be the expert in one area, because there's always like super bright and shiny things coming up.

But I think you almost have to fight against that. in some ways, In a very assertive way, like try to fill the gaps almost like [00:06:00] if you see your career as like a skill blocks that you see almost like a Tetris game and you're trying to feel the the whole line, right?

You're not super narrow or one thing. But, anyways, I think that is like good. There is a good and bad of like specialization, but I'm always I try to avoid that even though like. If you stay a year or two years on a project, you get plenty of specialization just by going deep on whatever the 

project is.

David DeRemer: Yeah, it's the same thing. I was just talking to a, a dad who lives nearby. I mean, you're talking about sports these days, kids from a very early age specialize in one thing. If you want to play travel baseball, you got to. Do it all four seasons and he's like back in the day when people would do different sports every season.

You, you learn different, mental models, you develop different muscles physically and that ultimately it makes you better in the long run. And I think that metaphor kind of tracks to this. You need to kind of round yourself out a little bit to build those other muscles to be able to react when you get into some ambiguous, uh, moments or difficult challenges.

And maybe [00:07:00] that corresponds to that your ability to be that glue function as well because you feel comfortable and confident flexing into a lot of different situations. real, real quick, like to the point of you being a, you know, an engineer, into engineering manager, what was the hardest, thing for you to learn or adapt to switching more to the management side?

Thiago Ghisi: I, I would say 

it was definitely some aspects of people management. I think one thing, even though I was already doing a lot of what the engineering manager is supposed to do, even as a senior engineer. Helping to break down projects, talking to stakeholders, all those things, right?

are definitely lessons there, how to navigate in organizations, like when to escalate, when to Like, how do you avoid triangulation? All those things, right? But I think the hardest part was definitely to learn to give feedback effectively and to learn to delegate effectively. And I'm still learning those things, by the way.

I think, one mistake that a lot of [00:08:00] managers make, and myself included, uh, is, Either you are the manager that's shielding all the feedback from your people, right? Uh, or you being the pass through, right? You're the one that just passing whatever you receive without actually processing, without, without actually compiling the thing and actually asking yourself, do we agree with that?

Do I, do I see any that that person is that bad or is doing that? Did I? I think I made many mistakes in the past, kind of like by being more a pass through layer versus like actually digesting and compiling any and delivering something to the engineers or report to me that were kind of like more. more actionable in some way, right? and it is a skill that's very hard to manage. And on the delegation side, I think it's like, it's very easy to get to the point where you just break down tasks and give tasks to people. And don't let them actually [00:09:00] be the, the task master, let's say, and taking the ownership of the full project because people are going to ask, what should I do next?

And it's very easy for you to get into that aspect of like, Oh, my, my job as a manager is to, to break as many tasks as possible and to, to be the one that's gluing it all together. Right. I think like those were very challenging skills to me. And I think as you scale, as you get more people on your org and you have bigger projects and more managers reporting to managers, all that, there are other challenges, but I think at the beginning, those were the two that I remember.

David: So now you're at New Bank, right? and you've had a, this long, lengthy career. Tell us a little bit about NewBank, just for people who are, who are not familiar with it. Cause I know it's a Brazilian company. Um, you're in New York obviously, but you know, it's a Brazilian company. Why don't you just do a quick catch up of, of how you got here and tell us a little bit about NewBank.

Thiago Ghisi: Yeah. So [00:10:00] Nubank at this point is, I think the largest fintech outside China by number of active customers. I think like, so we are a financial service company. I mean, we cannot say we're a bank, and I think like the Nubank story is very interesting, especially to me because I'm Brazilian and the bank started in Brazil.

Thank you. Was that they went after, and they were at the right time to, to try to like pretty much revolutionize how banking was done in Brazil, right? By instead of like having branches and all those things, they went, what if we did something that's a hundred percent mobile? What if we actually try to like have a credit card that was like, uh, Like, no fee, right?

in the U. S., it it seems crazy to think that you don't have that option. But I think ten years ago in Brazil and many, many places, Out there, that [00:11:00] is a very hard, it's very hard to have access to credit, right? I think like Nubank was a pioneer, like, in Brazil with like doing so many things early on, and then like, I think we are, we are now not only in Brazil, but also in Colombia and Mexico and in growing like there.

And, I think at this point, more than 50 percent of the adult population in Brazil is a Nubank customer. So. Very, very big there. And I think another, like, there are many things about Nubank, but I think the other thing that was remarkable was when the Brazilian Central Bank decided to launch PIX, that is kind of like, uh, it's kind of like Zelle and other things that we have in the U.

S., but it was widely adopted and mandated by the government and like 100 percent of like no fees and like instantaneous transfer. Nubank was like the app that pioneered that and like today is responsible for a big, big amount of the transactions that go over PIX in Brazil. And [00:12:00] yeah, so I think, we did the IPO, I believe was end of 2021.

Uh, and since then we have been growing a lot and we just crossed this year, a hundred million customers. That's

David: Wow. hundred million customers. Wow. And a mobile first company, at that scale and, um, you know, coming out of Brazil. It's just such an incredible story. And of course the reason I know you and I know of NewBank is that, um, Flutter was a big part of that story. And obviously Flutter is a big part of BGB story and NewBank was an extremely early adopter of it as well.

So when you think about building something that big. And, you know, making a choice that is so important, if mobile's core to the strategy, how, how did that decision get made, you know, and, and sort of how, how does a big, bold, innovative decision like that, become a trusted, confident choice when you're betting your whole company on it?

Thiago Ghisi: So, I mean, first thing that I have to say is that that was before my time, but I have a lot of context and, uh, and I can give you all the details, [00:13:00] but I think, if I had to answer that was like. The answer would be by doing POCs, by trying out the different technologies, by seeing what's possible to do with the alternatives that were available out there.

But David, I think like the, the thing that's important to mention is that Nubank actually started as a native, with native apps, right? and we, we actually had like a, even a Windows phone app back in the day. So we started and for like more than five years, all the way to 2018 or so. It was mostly native and, Nubank, one of the product areas at Nubank had already started to play with some cross platform frameworks.

And I think with React Native and, uh, had been super successful, but it was only one product out of the whole app, but the core, the foundation was always native. And then 2019 came to a moment where. The mobile engineering team at the time was feeling completely [00:14:00] overloaded and not able to, to deliver everything that the business needed, right?

Everything that was on the pipeline. And at the time, I think like mobile was being a bottleneck to innovation, bottleneck delivering features and different areas, different engineering teams in the company were trying to innovate and As you know, it's pretty hard to, to staff engineering team when like among many things, not only back end like databases and all those things, because at the bank we have like full end to end ownership, every single product owns end to end the infrastructure, even though they leverage platforms, right?

So I think, like, the idea of Flutter came when, there was a moment that it was, the backlog was, six months to nine months of work. It was a central engineer, like, mobile engineer organization that had maybe 50, 60 people that were, like, overloaded with work. And we need to scale in some way. and then it [00:15:00] started with like a few folks doing POCs on that.

And then there is a very famous blog post. That's way before my time where Nubank actually published the rationale and all the dimensions that Nubank considered to, to make the decision. And I think like it was very. very tied between Flutter and React Native in many aspects.

But then I think developer experience and the, the community and the fact that it was decoupled, all the dependency issues with React Native, all the build problems it had and like, and the fact that you could keep the native side and the Flutter side working together for, for, for a while, while we migrate things, while you get more confidence.

Was also a big decision factor, but it was not an easy decision and it was very traumatic in some ways. I would say that the transition, when, when you do that, like when you transition platforms, and I think like you had a [00:16:00] podcast interview a couple of months ago about the Betterment story. And I think there's a lot of similarities in there.

It's like you, you get folks that are very passionate about iOS and Android, and the fact that you have additional layers, it's not. You're going to be kind of like at least a couple of months behind, right? Whatever Apple and Google announced to catch up. And like, there's a lot of trade offs, but I think I would say it was a decision made out of like, uh, frugality almost, right?

Because it was very hard to maintain every single feature paired across two, two platforms. And then. Once you have that, usually have like, sometimes one platform is, is ahead of the other in terms of features because you have like different people with your own species like specialization and sometimes they're not all available with the same thigh.

Sometimes you have crashes in platforms and all that. And I think Flutter filled the gap in so many ways because it made easier for folks that were not [00:17:00] necessarily, didn't have a mobile background to To understand things and to be able to contribute, right? And also it reduced the amount of code we had, because now like you no longer had like two different code bases and all the, all the drown backs you have with that, right?

So I think like the context was, was there, like it was the need to scale. It was like trying to, to find a platform we could leverage for the next, like many years. And, uh, it was like something we could. Get started, but not necessarily migrate everything at once. And I think that was, yeah, that was what happened at the time.

And we had our challenge because it was early on for Flutter, right. It was like, we, we created frameworks. We, we had a lot of like issues integrating between a native and like all the, the Flutter sandwich problems, all the, you know, [00:18:00] integrations with, with native SDKs and all that. But I think, uh, on the other side is a much, it was a much better path where we could have, instead of like, I don't know, 50 to 60 engineers to have hundreds of engineers working on the code base and delivering things independently.

And think like the modularization is also easier. The fact that we transitioned to a monorepo back even before we adopt Flutter actually helped with so many other aspects. So I think like. Yeah, like, a lot there.

David: Yeah, it's, it's interesting as I, we hear these stories and sort of the decisions and, and, um, it gets so wrapped up usually in like a technology choice, people start comparing the programming language, the framework, you know, how maintained is it, you know, what's the frame rate performance and all that sort of stuff, and, and I think the nuances, I've talked to more and more people about this is, Kind of like those things don't actually matter that much to the decision.

I mean, they do, but they're like table stakes, right? Like, of course the app has to achieve your performance [00:19:00] goals. It has to deliver a good experience to the end user. But what's been fascinating to me is that when people talk about these things, they're really talking about the human element. They're talking about developer experience.

They're talking about portability of people to be able to work on things. They're talking about getting out from that huge backlog and the stress that comes from that. It's actually like solving all these organizational problems and like the thing you said before about like you can't keep up with the business kind of, right?

Like the technology becoming this bottleneck. So I feel like, you know, in a way where the App Store came out in what, like 2008, 2007? and you know, Oh, we're in this like second or third era of it where I think people are like, all right. we no longer need to just have apps on these platforms.

We need to do, we need to do it in a way that we can move fast enough and keep up with the business. And so it's just really interesting to me that it's almost like more of a business and team sort of culture and human relationship choice than even like a, you know, programming language or some other technical choice.

But you guys are also, um, you're on the forefront [00:20:00] of so many things and, and, uh, being so early to, to a tool like this, like an ecosystem or a community, I think companies like NewBank are also at the forefront of sort of adopting some of these new technologies and solving sort of the, the leading edge of, of challenges.

And one thing I know you've been talking a lot about recently, um, is like the server driven UI that you're adopting at NewBank these days. And I was wondering, um, if you could, you know, dig into that a little bit. because I think server driven UI is something, for whatever reason, actually, in the last three months or so, I've been hearing about it everywhere.

Like, it seems like everybody I talk to is like, oh yeah, we're going down server driven UI. so maybe just start, like, can you just explain that concept for, for, as you understand it and, and how you're using it at Nubank?

Thiago Ghisi: So, I think, like, the idea of server driven UI, I think, is, is a very old idea, and it is, like, I think I, I remember hearing about variations of server driven UI, like, even, like, five years ago, even more. Is the whole idea of what if the [00:21:00] app could be driven by the backend, right? What if we had, I mean, it starts with like, what if we can have the whole content being like on the backend and then, Oh, what if I can actually drive different, different designs or different like variation of the same screen from the backend, but then like very quickly you get into the level of complexity that like, Oh, this is not going to scale forever, right? Like it's and people make a lot of mistakes, a lot of similar mistakes when they're, they try to go on the, let's say the backend driven, uh, content, in web app, in mobile apps. so the idea of like server driven UI is like, is expansion on that is like, what if you could like, not only have the content being dynamic, but what if the whole design system could be dynamic?

Right. And then, and then you get like, Oh, what if, like, instead of returning a JSON that I have to parse, and then I still have the whole UI on the client, what if, [00:22:00] instead of sending that, what if we have like a whole dynamic design system and I could also send functions and I could also send the whole like, UI structure from, from the server side.

And the app is basically an interpreter almost, right? The app can compose itself, uh, because everything is, is, is coming from the backend and the app has. The only intelligence that you have on app is the ability to get whatever the backend is sending in, like, and build a UI that follow your convention and, be able to interact with the user.

But then, like, there are many, many anti patterns. And I think at Bluebank, we are on, I believe, the fourth. Generational server driven UI. I think we have tried a lot of things. Like initially, I mean, even, even I would say before we migrate to Flutter, there was attempt to do like some server driven UI with like forms.

And I think like for, for flows that are more like wizards, you [00:23:00] can easily do. Like a variation of server UI where you can compose almost any kind of flow and like you can adapt that for almost any kind of like, basic form, right? And you can do that. And if you have a lot of those in the app, it can pay off very quickly and you have the ability to quickly change things.

 and do like, let's say, basic stuff in the app from, from the backend, especially if it is a not so sophisticated UI and not so like intense, uh, like you don't have very intense needs of interacting with native and all that is like very standard, right? And then the next variation after that is like, is to what if you actually have a full interpreter on the client.

That not only can, let's say, build screens, but can also have local functions, can also have, like, [00:24:00] the whole logic to handle not only one screen, but a whole flow, right? What if you have, like, a thing that you're able to send, not a particular screen, but the whole flow, like, all driven from the backend, and do that?

And what if, then, you could use the same language that you use on your backend service? to write the, the languages, what if they could live on the same repository that you have your BFF or like even your, your APIs, right? And, and you get to a lot of like different challenge and is more, Oh, now I need to have a way to send functions that are executed on the client, but I send in code that's pretty much, uh, that can be compiled or interpreted.

Like, in Dart or whatever language, I'm not like, because it's unpractical for a lot of things. Every single time you have a click. You have to send, like, a network request to then do something, right? You need, like, you need to build a lot of things to [00:25:00] be able to support that. Now you need stack trace. Now you, like, now you have, like, almost a full blown interpreter there.

Now you need, like, to send But then you get to a, like another trade off that is now you have very big payloads. Every time you open a flow, you have like a huge payload instead of I don't know, 30 kbytes, like a hundred kbytes of JSON. mean, even if you gzip and all that, now you have like, I don't know, 500 kbytes because you're not only sending the content, you're also sending the structure over the network, right?

And now you have also additional layer of like processing because you cannot render like all the optimizations that you have at build time. Now you don't have, because you might have different permutations of components that need to be loaded and they are not, let's say, like in memory already. So you get to a lot of those things, but the, at Nubank, so we have played a [00:26:00] lot with server driven UI.

And, uh, we, we have a very successful case of serverless UI, but it was not something we built overnight. It was not something we built over the last three months. It was something that took years and like many attempts and something that we were able to leverage, like the way that Flutter works, the way the material works.

That's kind of an almost big team on the SDK, right? And like build like a design system on top of that and be like, almost be able to be decoupled from what's on the client so that we can send everything like over the network. And like, there are many, many variations of that. Like we created DSL so you can code enclosure on the backend.

And then we have like some interpretation, like via. What is that? The protobuf that gets on the warrior. And then like, so we have a very strong contract between the backend and the client. So, and like, I think [00:27:00] like the high level, I think that's like server driven UI is the ability of like having any dependency on the release train or on your, your new build getting to the app.

Uh, but then there is different. Also styles of server driven UI, right? I think like that is, uh, the style that you check for the new, if there is a new version available at the startup and then you pull the, almost the binary and you have that kind of mechanism that the user is always one version behind.

So every time they open the app, we load the new version, the background, the next time they launch, we get the latest. But there is the server driven where you actually, you don't do that. You don't, like, you have a binary that's static, but it has interpreter. And every time you, you call the server side, you get the, the entire thing that we work on that version.

And you're not, Like checking once, Oh, do I have any updates? So there are different variations of that.[00:28:00] 

David: It's, uh, and so correct me if I'm wrong, the business case for why you'd want to do this is to get around the build train and the releases you have to put out to the app stores, essentially, is that the, like, what drives somebody to go down the server driven UI path?

Thiago Ghisi: There are many reasons. I think like the initial reason might be that you want to do continuous delivery. I would say like the, the biggest reason in my opinion is, is that it's almost impossible to. To do bug fixes or to, it's like, it's very hard for you. It's like impossible for you to to ship a new binary every time you have a new PR merge, right?

Like forget it. User is not going to be downloading a new binary every day, like multiple times a day. Then like there are some like business needs that's like if every time you need to like to do a bug fix you need to Wait all the users to catch up on the new [00:29:00] version and every time you need to launch a new feature, you need to make sure that the user base is lagging on a version, right?

So it's like very challenging. to coordinate launching of things because then you don't have like the code or that version. So users are not going to be able to see at the same time. the other thing is, so I think like I mentioned, yeah, the, the limitations release training, shipping the binary multiple times a day.

And like the hard thing about like bug fix. And the other thing is like, even though like Flutter is very good technology and very easy for, for engineers to learn, it's still not super high leverage or, or how can I say? It's like, there is still things you can do, especially if you are on a big company and you want to make as easy as possible and create platforms that abstract away the nuances in having Imagine that you have, like, as we have at Nubank, we have like a 2, 000 [00:30:00] engineers org, right? Like we have 2, 000 engineers that are, that like, not all those 2, 000 engineers are working in product facing squads, but like a good chunk of that. So he's like, imagine that every single one of those squads now, like they own like the product end to end.

And if you have, every time you need to build a new screen or build a new flow. You need to go and do the, the Flutter screens and then you need to go the server side and you need to know like database and all those things like Kafka, like, like Event Driven, like all those things is very hard, but if like, it's not very hard, but it's not very optimal.

Right? And then. Imagine if those engineers have like higher and higher level platforms that they can leverage that abstract away many of the nuances and they can do like, for example, like to the mobile flows along with the, the [00:31:00] service layer. And imagine if the same way that we deploy like microservice multiple times a day, you can also deploy the, the screens, the flows, like in, Imagine that now you don't have a new A.

P. I. you have to maintain, because if every time you have to do a new flow, you need to call A. P. I., like, do a POST, do a transaction, whatever, what if we could, like, have a framework that's able to handle that, and we push that, like, all, all those integrations, all those things to the backend? Now it's like, instead of having I don't know, like five engineers, you can do, have like two engineers doing the whole thing.

So I think it was more, there is a business demand. And then if you get into things like experimentation, it's like very hard to do experimentation in mobile. If you are operating under the constraints of shipping once a week and you buy an area and every time you need to do like, Oh, we want to do a new variation of this screen.

But if everything is server driven. And you can play along with that [00:32:00] and you can bug fix those things. It's like the case of server driven UI at Nubank was like, was a platform that was born to solve one project needs that had like something like, it was very bullish on this, that had some needs that were very particular.

And then like the moment that the different product areas start to hear about that, they start to adopt organically. Oh, we want to use this platform. We want to contribute. We want to make it better. We want to put engineers to, because they saw that as the next, like the next lever, if like native was here, Flutter was here.

I mean, severed UI was here. And, and like that, I cannot say how revolutionary this was for us.

David: Just moving up the abstraction stack, and the same, so if I'm hearing you correctly, the same sort of motivation behind, going something like Flutter, where you used to be maintaining two apps, now you're maintaining one, it makes it easier for those developers, now you've even squished it even more. And I think that maybe gets back to your point about being, um, a [00:33:00] developer that isn't so focused on one thing.

Cause that would maybe be a difficult way to develop if you were like hardcore only, you know, iOS developer. That's all you do. I only write Swift. and now it's sort of changing the notion of what you're doing to being like, I'm not a mobile developer or a backend developer. I'm a product developer.

You know, that's it. Like, what we're doing is we're working on making the product ship. It's very interesting. Has it, has it changed the way that like designers and back end engineers and front end engineers all work together? Because I would imagine the, the role of then the Flutter app is essentially to maintain that interpreter.

It's almost like you built your own little like, browser essentially, right? With it's own like, rendering rules and things that you put together. I would imagine how does that flow from design into back end development front end development and because it's the lines are blurred now a bit.

Thiago Ghisi: Yeah. Yeah. 

It is a great question. You know, I would say. And we still have a lot of native, uh, and like mobile complexion, [00:34:00] so we still have platform chains. I think like, there are maybe two things that are very important to mention, like Nubank Has like six engineering principles that are very strong in our culture, but there's two that I think are very relevant to this.

I think like one is called canonical platforms, canonical platforms widely applied. So it's like, We try to have canonical platforms that are applied widely across the stack. And that like started with like, for example, things like Clojure, Kafka, Kubernetes, right? Those are high level platforms that we try to apply across the stack to everything.

Like there is no exception of, Oh, I'm going to build a microservice in like, I don't know, in, in Python or. It was always like, no, the canonical platform disclosure, we, like, there might be some very particular case to build some in another language, but if you do that, you're going to lose all the kind of needs to write all the, the tooling [00:35:00] we have to like all the common libraries, all the things, right?

So I think like, this is very strong. There's another engineering principle that is called like product ownership or end to end product ownership. That's like more than being, let's say, uh, an engineer, like you are a problem solver. But more, more than this is you're not a mobile engineer. You are like an engineer.

So it's like you, you don't like. You solve problems. You don't like force solutions, right? Like what is the problem we're trying to solve? And you go after the problem. You don't go after, like, you don't get passion, like passion about different solutions. Right. So I think like, and then like, this is very important because the only way to achieve that, like the only way to have canonical platforms and, and to have like end to end product ownership is if you have high, super high level and highly effective.

[00:36:00] Platforms that are enabling those folks to, like, they're hiding the complexion, the chaos as much as possible to, to those folks that are maintaining the product side. And like, so it's not that we don't have front end engineers or mobile engineers is that almost everybody is a mobile engineer, right?

Like, is that, it's not that I don't, we don't have infrastructure engineers or backend engineers that. Like with all the, the platforms and the platform teams we have supporting that and all the documentation. And because we're doing everything in one way is super easy for folks to transition and navigate across and to, to find, to find examples and to kind of like, and to replicate patterns or to learn, right, because it is high level and is widely applied, right?

So, but it means that we push a lot of complexity to the bottom of the stack. Because in order to maintain like a server driven UI framework that's [00:37:00] hiding all the complexity, like to have a good performance is a huge challenge because now we have to deal with all the maybe inefficiencies that we have along the way to, to, to create that efficient, velocity, 

right?

Now you have a lot more, a lot bigger payloads. Now you have like an interpreter on the, you know, now you have like, Like things that if you're building native, you get optimization out of the box. Now you have like platform chains that are, their full job is to find needs and to kind of like pushing the, the level of abstraction even higher.

And also we need to provide documentation. We need to provide things so engineers can quickly onboard those platforms and they can quickly put something together that's going to solve their needs. And, and even like, if they have some very particular need and the platform team is busy with other things.

They can go in and do inner sourcing. They keep going and contribute to the, to the platform. And I think that was what happened with our [00:38:00] like, uh, internal case of like server driven ui because like everybody was like, this is revolutionary. Like now I, even though I cannot do what I want now, I go and contribute to the platform and then I do my future later because then I know next time I need, I'll have something that is gonna speed up things even, even more.

David: You said a word there that I think is interesting like revolutionary, right? Like, the people looked at them, they're like, Oh, this is revolutionary. So let's give it a try. Somehow, um, you guys have established this culture and an acceptance and sort of a momentum around doing these bold, innovative solutions that are hard.

Yeah. And that, you know, some teams may not bite off because it might be, well, what if we go down the server? Like you said, it took years and there are probably some teams that like tried it, did it a little bit. It was like, Oh, this is going to be really, really hard. And they probably backed off, but you did it with Flutter.

You, you, you know, you, you tried it, you, you, you got into it. You eventually did more and more and more of it. You got server driven UI in there. You've been working on that. What is it about NewBank you think that has, made that team, [00:39:00] um, more amenable, like more able to embrace these sort of bolder, more innovative technology choices.

Thiago Ghisi: I would say, like, is, I think the, the culture is a big thing, but I would say is, it's also the founders in some way that live and breathe that those values is like the, the early, like, The early joiners in the company that are very bullish on this approach was, it was the fact that we established those, those foundational components, those foundational principles early on, and we, we were very good at enforcing it company wide, right?

And I think, Ad, like Ad is the, one of the co founders and was the CTO for many years and. He was on the ground with people. He was like even when he was CTO, he was still very influential on like everything we did and like in [00:40:00] being super bullish on this idea of like canonical platforms of platform teams of like, you know, Like product ownership of like, like full product ownership, right.

And not letting the, whatever, every time that, every time a new engineer comes from a different company to corrupt the vision, to corrupt the, like the, the guidelines and being super, I think like strict is the wrong word, but like, is like the fact that we give time to everybody to learn and like, you know, But we, we try to keep the, the, the canonical approach canonical, I think, like, and by doing this, we have found ways to do things that would be so much easier to say, Oh, I need new, this, this library that's not available in, in closure, or I need to do something that's out of the box.

Let me, let me spin a new, a new microservice, or let me break out of the, [00:41:00] the canonical way. And like, And so I think like it was a combination of all those things. And also the kind of engineers that join NewBank, they're very passionate about the mission of the company, right? It's to fight the complexity that is to like, to serve like customers that have been unserved, right?

Like to give access to credit, to kind of like, to make their life easier. And I think like. is to challenge the state of the school in so many ways, and also in engineering, right? Like, we need to be frugal, like, we need to, with the scalability issues we had, like, we had to make those choices, otherwise it could, I mean, it could go sideways very quick.

David: So commitment to that path, I like that word canonical, you know, you make these canonical choices. It sounds like the founders respected those and pushed and made people adhere to those as the company grew. Because I could definitely see the company grows, you get new leadership. People change over and, uh, you know, Sam in, in the talk with Sam from Betterment, he talked about these like lava layers that come over [00:42:00] and like a new lava layer comes over and you just get these layers that are constantly eating the thing before it and before you know it, there's just all these little changes over time that became, make it, uh, unmaintainable.

Sounds like, uh, the founders there put, developed a culture that, Help people to stick to their guns while embracing innovative choices, right? Along the way. Um, cause certainly you've made a whole bunch of those. and to that end, I was wondering, like, um, given all the interesting innovative choices and challenges that you guys have overcome and doing, like as you look ahead with technology, um, what are some things that excite you?

Or even maybe, maybe frighten you a little bit when you look ahead and changes, like what are the challenges or opportunities that you think are coming for engineering teams?

Thiago Ghisi: Perfect. I, I will answer that, but I, I have to go back to add two more things that I was just thinking about, like, what made Newbank's culture so successful? I think, like, Being a bottom up culture and having full ownership and autonomy to do things quickly without actually, like, being super top [00:43:00] down, where, like, the values that were always there, they're still there, and those are, like, those are, so crucial, like, the fact Nubank was pushing to have like on the same squad, not only engineering product, but also customer service also like everything that was marketing, truly, truly like multi, multidisciplinary teams that they could propose the roadmap, they could propose the OCR, they could propose the path to get that product to market fit, allow the company to market.

scale very, very rapidly and with like many things at the same time. So I think like the, the level of autonomy and trust and like, and like, in the leverage on top of the platforms were like also another big thing. And another thing, David, and sorry for doing this, I think like for server driven UI, there is another thing that is huge is.

Governance, because like when you have everyone working on, even on a monorepo on a big, [00:44:00] native app, you have to all be like passing the same build and compiling on the same binary, right? But the moment that you're able to like do server drive UI, almost the idea of micro front ends, right?

Where you have the coupled chains moving different repositories and deploying different places and. This architecture of serverless UI is able to keep it up even with folks deploying different speed. And if one thing fails, you don't fail the whole app. You don't compromise the whole app, right? And you are able to create something that's robust enough to handle all those, those permutations.

And you have like a revolutionary, like almost, uh, modularity that is very hard to get in mobile. Like you're basically pushing mobile to be a distributed system. Instead of being like a client side 

thing.

David: It's a lot. There's a lot going on there. Um, no, I appreciate that insight. Thanks for, thanks for jumping back to us. And yeah, just, just to wrap us up, you know, as, we get into this, uh, [00:45:00] you know, go back to that question before around sort of opportunities and challenges ahead and maybe some insights you have from your experience from NewBank.

just, uh, wrap it like pulling it all back together, you know, what would you, uh, recommend to other people, to be successful with technology?

Thiago Ghisi: So 

I would go back to the two things that I said, uh, at the beginning that I think are the things that my opinion make you like, and I think this applies to companies and to also to individuals, but Is like this idea of like being the glue and this idea of like being a, specializing generalist or generalizing specialist and of course you need to like surf different waves and now we are on A.

I. Now they're like new technologies coming up. They're like, they're a challenge here and there, right? And I'm not saying that you shouldn't, go and invest in a new technology, I'm not saying that you should do everything, that is not on your job title and [00:46:00] your job description, I think there is a limit to that, but like, Having the idea of like full end to end ownership, and being able to navigate across the stack, going on the, all the layers of abstractions that are sitting below that technology you're using.

I think this, those things are going to be valuable again and again and again. And like now with JNI, with whatever, like whatever is coming up, right? Like quantum computing, like if you don't actually. Go, underneath the concepts and you're not going to be able to innovate in an effective way.

One, one reason why Nubank was able to innovate in a very effective way, especially on the server driven UI, was that you had folks with different, that had seen different things in different parts of the stack, and they were able to put a solution that leveraged all those ideas. And also had some elements of mobile, right?

If you had someone that was only doing mobile development, and they had now to do like a whole [00:47:00] distributed system architecture, you're not going to be able to do it because they don't understand what's going on, what's possible, what other areas have seen and failed, right? So I think that is the same thing.

And I think With technology, there is the law of leaky abstraction, right, that I think is, there's a famous, blog post from, uh, Joan Softer on that. And I think, like, you need to be careful when you're operating at too much high level and you don't know what's going on underneath, right?

And that applies, especially if you work on a company that has, like, Frameworks on top of frameworks, and you're working on something custom in house that does a bunch of things, but you don't know how to debug, you don't know how to go layer by layer, you, you don't understand concepts that are kind of like neighbor to your area, but they are like different languages top there.

So I think like, those are the things that I think made Nubank successful because a lot of those engineers. They didn't have like, Oh, I'm, I'm like, I don't know. I'm a Flutter engineer. I only work with [00:48:00] Flutter. It's like, no, Flutter is a tool and I leverage it as much as possible. But if it's not helping me to solve the problems of my customers, of the business, I'm going to drop it and I'm not going to regret it.

 and I'm not going to attach my identity to, to a technology. And it's easy to get into that thing where you see almost a technology or a new innovation as. I think it's your new kind of like, your new identity would say like those things, if you keep those principles in mind and you push yourself to try to take into ownership, navigate all the layers and being the glue there, I think you can be very successful.

Like anywhere in technology.

David: That's super well said. Very, very important concepts and increasingly more and more, I think, uh, as I see more, more companies talk to more people and see, uh, challenges and successes that people face, it really does boil down to, I think, the people you got and the culture you've established and so many people blame the technology for low performing, you know, you know.

products or [00:49:00] something like that. And a lot of times, it's not really the technology that's the problem. It's the, the team dynamics, the cultural setups, the organizational design, and all the other things that kind of come along with it. And like you said, I think it's, that's a really insightful thing. I think right now people probably are scared of A.

I. A lot of people. Are they going to take developer jobs? And to me, I just see it as an extent. It's like just something else like Flutter. It's just going to make developers more productive. And like you said, if you are the glue type person, who is that sort of generalist, specialist, specialist, generalist, Who can adapt to these things and be productive in a lot of different ways.

That's gonna make you and your team successful and adaptive. And it sounds like that's what's helped NewBank along the way. So I just want to thank you for coming here and, and sharing your journey and your stories with me and with, uh, everyone who will listen to the podcast. Um, what we'll do is, uh, we'll get some links from you and we'll put them in the bottom of the podcast.

So if anybody's, interested in learning more, you know, if you guys are hiring or I know you've got some articles on your server side driven UI approach and maybe some talks and other things. So. We'll put those, um, but I just want to thank you for taking time out of your busy day. I know you got a lot on your schedule and [00:50:00] these days everyone's working super hard, especially right now.

So, um, thank you so much for coming on and, um, we'll let you know how things go. So,

Thiago Ghisi: Thank you, David. Appreciate it, man. Thank you for inviting. 

‍