#158 - Sustainable Engineering Lessons From Scaling Up Wise - Balazs Barna

[00:01:11] Episode Introduction

Henry Suryawirawan: Hello again, my friends and my listeners. You’re listening to the Tech Lead Journal podcast, a podcast on technical leadership and excellence. If you haven’t, please subscribe on your favorite podcast app to get notified for new episodes. Also subscribe to Tech Lead Journal’s bite-sized contents on LinkedIn, X, Instagram, YouTube, and TikTok. Please support me and this podcast by either buying me a coffee at techleadjournal.dev/tip or becoming a patron at techleadjournal.dev/patron.

My guest for today’s episode is Balazs Barna. Balazs is the Head of US Engineering at Wise. In this episode, we delved into his insights on building sustainable engineering from scaling up Wise. Balazs started by touching on the engineering management role and described the traits of good and bad engineering management. We then went to discuss two different aspects of sustainable engineering, which are sustainable tech and sustainable teams. Throughout the discussion, Balazs outlined several key practices, such as weak code ownership, microservice strategy, stable pace, and building a bench.

I hope you enjoy listening to this episode and learning insights on scaling up and building sustainable engineering. If you enjoy listening to this episode, please do share it with your colleagues, your friends, and communities, and leave a five-star rating and review on Apple Podcasts and Spotify. Your small help will help me a lot in getting more people to discover and listen to this podcast. And I really appreciate it. So let’s now go to my composition with Balazs after quick words from our sponsor.

[00:03:16] Introduction

Henry Suryawirawan: Hey, everyone. Welcome back to another new episode of the Tech Lead Journal podcast. Today, I have with me, Balazs Barna, I hope I pronounce your name correctly. So he’s the Head of Wise US engineering team. I’m so looking forward to learning from you, how do you actually build and grow and scale the US engineering team for Wise. And there will be a lot of super learning from your experience, I believe. So welcome to the show, Balazs.

Balazs Barna: Thank you. Thank you so much.

[00:03:42] Career Journey

Henry Suryawirawan: Right. So Balazs, I always love to ask my guests to first introduce themself. Maybe if you can share some highlights or turning points that you have in your career so that we can all learn from you.

Balazs Barna: Absolutely. I’ve been coding and, uh, I’ve been, you know, playing with computers since I was very little. I didn’t really have a choice in the matter. My father is a software engineer and he introduced me to all of it. I was building my own PC when I was six. And I started coding, first in Assembly, then C, C++, into object oriented programming, C#.

And in the last 10 years, I’ve been working mostly with the Java based systems. After university, I joined Morgan Stanley, the graduate program that they had. I went to London, New York for a short stint. Learned a lot throughout that program. Stayed with them for another four years. And then I moved to another company, which is a spinoff of Morgan Stanley. Pretty similar to what I did, what I’ve done, previously. I stayed there for three years. I was redesigning a system that is super important for the business. It was the corporate demand system.

And 6.5 ago, I’ve decided to join Wise in our Budapest office. I was one of the first engineers to join there. I joined as an IC. Then I became a lead within the first six months. I started to work in the European expansion teams, which was just one team, basically with two engineers at the time. I built it up to 17 engineers and three teams. And then I took on another challenge and I started to work with the US teams who are building our banking integrations and trying to find the product market within the US. As the US is now our biggest market and the biggest opportunity, I felt, like, that would be a challenge that is worth on taking on. I moved to Austin in 2022 from Budapest. And in Austin, we are building a new office, a new site, a new headquarters for our US based teams. And since 2022, we’ve hired 200 people, and roughly 10% of that is engineering.

[00:05:52] Building on Strengths

Henry Suryawirawan: Thank you so much for sharing your experience, your journey. I think that was quite a n interesting journey, because you started from an IC, went to become a tech lead, went to become an engineering manager of a few teams, and now you become the Head of Engineering at a large global team, right? Even though you’re based in the US. But, um, maybe from all these journey, for those people who are listening, who are aspiring to have the same journey as yours, because I believe so many engineers would want to aspire to have the same journey as yours. What would be your key advice for them in the first place, right? How should they take opportunity and also maybe build their profiles?

Balazs Barna: I think the key thing to this is building on your strengths. So you have to be aware of what your strengths are. And once you know them, you should find people who can help you move fast, give you advice. And also have a job where that job is going to allow you to build on those skills. I think that’s the first thing. I think engineering management is not for everyone. There are engineers where it’s much better if they stay on the IC track. If you see that what gives you energy is more the IC work, I think that the best course of action is just to stay there and see, like, where you can have the most impact.

[00:07:11] Traits of a Good Engineering Management

Henry Suryawirawan: I think, yeah, it’s very, very important, right? Like what you said, engineering management, I believe also is not for everyone, especially if you don’t like dealing with a lot of people’s challenges, right? So I think one of the key strengths of yours, which I believe you also mentioned to me, is actually dealing with engineering management, right? So maybe if you can give us some of your personal perspectives. What do you think are some of the key traits of a good engineering management?

Balazs Barna: So I think in terms of trying to understand this role, and how do we evaluate the job, how the job was done, I think the first thing is, can you and your team get things done? Most companies have KPIs or OKRs, whatever you wanna call them, the business goals, the outcome that you want. That’s the first thing, like, can you get your team there? And the second thing, which is the much harder one, is can you do this sustainably and over, you know, like, a longer period of time? And this can be broken down into multiple categories, like, are your technical decisions or system decisions sustainable? Do you have a team health, like, a learning team that keeps on growing? And the last part is can you build a bench? Can you build up someone in your team who can do what you do and maybe even do a better job so you can take on another challenge.

Henry Suryawirawan: Yeah. Getting things done I think is, like, a basic prerequisite, right, for all the manager or leaders, right? So I think getting things done sometimes is probably trickier in some places than the others. And I think maybe if you can elaborate from the organization point of view, how can they facilitate teams or managers to actually get things done much easier?

Balazs Barna: I think that the first thing that is really important in any team is to have a common understanding of what the goals are and what’s important, what’s not important. Can you distinguish between important and urgent? I think that’s definitely a key thing. And the other thing is, once you have that understanding, can you block out all the noise that comes to you? Can you make sure that you remain focused, you don’t take on too many things and you still build up this momentum of getting things done? You know, whatever you start, you should finish and you should, like, fully finish. And only then you should take on your newer challenges.

Henry Suryawirawan: Yeah. So you said something interesting that not taking too many things, right? I think in some organizations, or most organizations that I experience, is that the manager have too many things to do. So I think this is kind of like, I don’t know, systemic, habitual problems in the industry.

[00:09:51] Limiting Work in Progress

Henry Suryawirawan: So how do you actually, how can you advise managers to actually be able to focus more, a lot more on not taking too many things. Because sometimes it’s from the top, right, or we have so many goals. We have so many KPIs to chase. And they just leave it to the managers and middle managers to execute without knowing how much capacity that he or the team has.

Balazs Barna: I think, like, a very obvious, very simple rule that you can apply just the power of three. You know, like, pick the three most important things that you cannot drop and just, like, focus on them. If we think about the team, one thing that I like to do sometimes, is just to limit work in progress. So how you can do that is, you make a sort of, like, a guiding policy, that every task that takes more than two weeks should be worked on by two engineers. So then if you have a team of six or a team of eight, the longer running projects that you can have at the same time is going to be, like, three or four. So there you kind of limited the bandwidth. And a key thing there is that all your stakeholders outside understand why you’re doing this. And it makes sense to them and they accept that this is kind of the steady pace that the team is going to go with.

Henry Suryawirawan: Right. That I think is very precious tips because limiting work in progress, it’s part of the lean methodology as well, is something that I think everyone can use, right? But first of all, like, you should make it visible, right, what kind of things that you are working on, right? So I have an episode with Dominica DeGrandis previously as well, talking about making work visible. So I think that is also probably one of the good tips for managers, right? If you are swarmed with so many things, right, first is identify what are the things you’re working on. And probably limiting the work in progress, just like Balazs mentioned. Maybe put a limit, like, a big project assigned to engineers divided by the total number of engineers that kind of, like, the limit of how many things can be tackled by your team.

Balazs Barna: Sorry. Just one thing you reminded me of is, one thing that really helps me, I’ve only been doing this in the last three years, is writing my own personal OKRs. And I publish that and I send it out and I keep iterating on it. That’s also a super important thing of aligning with your product counterpart or lead, and being really transparent on, like, what are the things where you’re spending your time and how are you going to decide for yourself if you’ve done a good job or not.

Henry Suryawirawan: Right. I think that’s an interesting tips as well because some people just align with their manager, right? Their direct managers. But I think if you have something that you share among stakeholders, maybe someone can figure out if, let’s say, you are doing something that is not aligning with their priorities.

[00:12:33] Traits of a Bad Engineering Management

Henry Suryawirawan: Yeah. So you mentioned things, like, a good characteristics for EM, right. But have you identified maybe in your journey or from your people below, right, in engineering management. Are there engineering management bad traits that people should avoid? Like, if this is, like, a clear “no” signal.

Balazs Barna: I think if somebody, as you mentioned, doesn’t like to deal with people, that’s definitely, you know, like, a sign of you’re going to have to deal with problems that you don’t like in a lot of the cases. But I think if we, like, think about it as a framework of, you know, one is getting things done, the second is, can you do it sustainably. I think that if somebody doesn’t get things done in a organization that works well, that’s really easy to see, right? That you didn’t hit the KPIs, it wasn’t fast enough. You can go there and you can figure out what the problem is you can help.

When it becomes tricky is if somebody gets results, but doesn’t do it sustainably. So to me, getting things done is, can you go from A to B and sustainably means that, is there going to be a C where you can go from, like, B to C? And that’s a very tricky thing when there’s a leader who gets results, but under the hood, you know, the technical solution is maybe suboptimal. Maybe it’s not going to scale. Maybe the team is burning out. Or they’re a kind of leader where they don’t have a bench, they do everything in the team. These are the things that are much harder to identify and much harder to help with.

Henry Suryawirawan: Yeah. So I think the second aspect that you mentioned after the getting things done, right, is doing it sustainably. And there are few aspects you mentioned, like, the tech solution, the system, right? The design of the solution. And also the team health and the team bench, right? Building the bench.

[00:14:17] Sustainable Tech

Henry Suryawirawan: So maybe if you can walk us through one by one, right. Let’s start with the tech and system, right. So you’ve been, I don’t know, 6.5 years in Wise now, right? So you have grown them from, maybe, like, small team up to the expansion to the US. Now it becomes the one of the growing biggest market for Wise. So tell us, what does it mean to have a sustainable tech or sustainable system design?

Balazs Barna: That’s a really tricky question, because as, uh, you know, the teams change, the tech keeps on changing, you know? Maybe the best way is if I start with, like, what is the ecosystem that regional teams live in at Wise. So, um, with most startups that try to be global, we have core systems, and there is, you know, like, a regional application of that system. There are teams who are building the core, like, how should this feature work? Like, how do you hold money? How do you receive money? And then how do you send money, for example? And then there are teams who are building on this. So you can think of it as, like, there are teams who are building the operating system, and there are teams who are building the applications.

For the applications at Wise, these are the integrations that connect Wise to the financial world. So this is hundreds of banking integration with banks and partners throughout the world. And it was a really interesting journey that we went through. Wise was growing, when I joined, was growing by more than 100% year on year. Just to, like, for everyone to understand this growth, when I joined in 2017, we had 500 people working at Wise. Now, we have 4,500. So this was some crazy growth, like, operationally, the markets that we launched, and, and, and in every, every sense of the world.

So one of the challenges was, you build these core systems. There’s going to a bunch of teams who are going to write code and add code to those systems and implement that system in the region. For example, you know, in the European Union or Singapore or the US. And all of these things add a lot of complexity. And when you try to grow globally at the same time, you have a lot of conflicting things in the roadmap, right? Like, should we do, you know, like, the US first? Should we do Singapore first? What should we prioritize? And if you wait on a team, like, on a central team to build something for you, usually the problem is that that’s too late. You know, that’s not something that you can live with.

So what Wise does is we have this weak code ownership. My lead doesn’t like this term, weak code ownership, because there is still a team that owns the code base, like, has to do the review, but you can go there, you can understand how to contribute and you can submit a pull request and they’re going to review it. So that’s how regional teams at Wise do majority of their work. They go to the central teams, they contribute to the system, and the central team reviews it and then they release it. So that’s one of the key things that drove the architecture at Wise.

We went into long journey of Wise started with a monolithic service. Everything was in one application. It was super fast. It was very easy from an infrastructure point of view. But then the service, as you can imagine, grows very big. Seven years ago, it took roughly three hours to build the monolith. Now imagine you’re building it for three hours, and in the last second, there’s a task that is failing. And there are, like, maybe, like, 20 teams who are waiting for that release. You know, they all nurse their code in, like, something broke, something has to be rolled back. So it became very, very hard to go with the same pace.

So then we moved into this microservice architecture. And we started to carve out the most important domains out of this monolith. And then we created a system that communicates with, you know, like, messaging, and a system that can scale. But then, as you can imagine, the same thing started to happen. So with regional teams, we had these systems which are capable of processing statements or executing payouts or converting money from, like, one account to the other. And since we have hundreds of integrations and we are frequently adding them, these services also became big. Not as big as the monolith, but it went up to, like, 20 minutes to build the service.

I still remember when somebody made a change at the other part of the world. They added a library to the dependencies. And that library was a version that wasn’t compatible with an integration that we used, right. But since it was the same service, It just broke our integration in production. So because of these things, we reiterated on these microservices, and then came to a solution, which is going to be a partner-based, you know, like, small microservice that just does one job. And, that’s kind of, like, an overview of what regional teams went through in the last six years.

[00:19:25] Weak Code Ownership

Henry Suryawirawan: Wow, there are so many things that maybe if we can just go a few of them, right? So the first one is, well, you mentioned weak code ownership. So from my understanding, this is, uh, similar to probably in the open source world, right, where you have a few core committers. I think of it, like, the core teams, right? And you have the regional teams, people who volunteer and, you know, contribute to the open source. Is that the same? That’s the first thing.

And the second thing, how do you ensure that the people from the outside of the core team actually understand the domains, the kind of impact that they’re making to the core system? Because they might not know what is the rationale behind the code base, or will it impact the code for other regions?

Balazs Barna: Yeah, those are great questions. I think it’s very similar to that, yeah. So there is a core team who really owns the service, has the right to release the service, and the expectations vary among services. But usually, there is a read-me file that explains everything you have to do with the service, like. How you should contribute. And at Wise, I think we have reasonably clean services, like, a clean architecture. The architecture differs from service to service. But there are, like, really good foundations that if you understand, like, one service in the whole domain, you understand most of them. So that’s, very important.

Another important thing is, as an organization, even though we have 500 microservices, most of them are Java. Everything runs on the JVM. There are maybe a couple of services which are Kotlin. But it was a huge thing for Wise that most of our engineers can contribute to most of the services. And Java is a very simple language also compared to something, like, Scala. So I think these things really worked well for us.

In terms of, do you understand the domain? That’s a great point. What I advise to my teammates is just to make friends with the core teams and also to go to their plannings, understand where the whole team and that vision is going, because central teams are the ones who are usually shaping the technical vision. And do that extra work of, you know, like, don’t just look at “can this be released tomorrow?”, but try to think with their head, where is the architecture going?

So one thing that we do is we don’t just show up with a pull request that is a thousand lines long. What we do is before we try to talk to them and explain what is the problem that we are trying to solve. And really just seek that advice of how would you go about this? Is this a code that you’re not going to build on? Is this something that is going to be deprecated? Can we really do it this way? And usually, the central teams really welcome that. What they don’t like is if you show up with a thousand lines of code. And then you say, like, hey, I’d really like this to be released tomorrow. That’s something that doesn’t work usually.

Henry Suryawirawan: Right. Not to mention the kind of risk that if you just merge a thousand lines of code, right, what impact it’ll introduce. So maybe elaborate a little bit more on the core team, right? Are there a lot of people as part of these core committers that is, like, the gatekeeper, right, of all the PRs that are raised from regional team? How do they operate? Is there, like, specific committers who understand specific domains really well, or are they interchangeable? So maybe if for people who want to operate this way, they can get some hint as well.

Balazs Barna: So how they typically work is that they advise, domain-driven design is a very popular, methodology. We think of everything, as a customer problem. So if you go into our organization and you look at just the name of the teams, it’s going to be very clear to you, like, what are the customer problems that they’re solving? And these teams divide the ownership of that domain between themselves on a technical level as well. So, for example, if you have a team that deals with, like, liquidity or, you know, treasury, they’re going to own those services, which are going to track how much money we have on our bank accounts. How do we move money from one account to the other, and so on and so forth.

So every single person in that team will have, you know, like, committer rights and, reviewer rights, and release rights at Wise. It’s not just the leads who can deploy the service, it’s typically everyone in the service. We try to be really, really flat. The levels the different engineers have don’t make a difference in terms of what they can do with the code and in terms of impact.

[00:24:04] Transitioning to Weak Code Ownership

Henry Suryawirawan: I was in a organization before where we have almost similar problem. We have the main country, right? And you have regional teams as well. I think their approach back then was to create a centralized team. So yeah, I realized over the time that didn’t work because first it’s the prioritization problem, right?

Every country will shout and, hey, we have a priority, but there’s only a limited number of people who can serve the request, right? And if your country is deemed to generate lower revenue, probably, right, they’ll deprioritize you. So for companies that maybe are in this, model at the moment, right, how can they maybe transition into the weak code ownership, like you mentioned? Is there maybe some kind of journey that you went through that kickstart all this?

Balazs Barna: I think at Wise, it was always like this. It was always very pragmatic. How can we get from A to B in, you know, the fastest way? And this concept of enabling people and, you know, like, getting out the way if somebody wants to get something done that is going to be good for the customers, is just ingrained. I think trust and, you know, “no drama, good karma”, as we have it in one of our values, is really important. One thing that is, is also key is to understand if you have this problem at all. Or if you, if you really need to do something about it.

One thing that we look at really frequently is how much is the lead time when we release something. One thing that I noticed four years ago was that when my teams were contributing to certain domains, the merge time was a week. Because multiple reasons, right? Like, then you go into the reasons, like, hey, what’s going on? Uh, sometimes, the core team was just three people. And three people were owning a service. And there was an organization at the time which was, like, 60 people. And 60 people were writing applications and sending pull requests to them. So that was just the time that it took for them to get to everyone.

And that pain point led to this vision that in some cases we have to own our own services. So when I looked at, okay, we’ve modularized this domain and we own our own service. We have the right to release and merge and deploy and everything, it took us two hours on average to do a review and merge it in. That’s a huge advantage to a week, right? That’s more than 10x. So these are the things that kind of drove us to go into one direction to the other. We always, you know, start with the data and what is the problem that we’re trying to solve.

Henry Suryawirawan: Yep. I think lead time or the flow of the value, right, is key. So make sure maybe people to measure your lead time and take action, right? If you find the lead time is slow, then maybe you can try some of the tips that Balazs just mentioned.

[00:26:57] Microservice Per Integration

Henry Suryawirawan: The other thing that I picked interest is the journey from your monolith to microservice. And, you know, now it becomes, like, even more granular, right? Some people find it challenging to move to, like, hundreds of microservices, but in the end, you kind of, like, settle on this per integration microservice. Why do you think this is the most optimal design for your problem?

Balazs Barna: Let’s start with the problem. Like, what was the issue? We’ve built hundreds of these integrations. When you do this, you have to connect to an external system. You have to do authentication, authorization. There is a lot of boilerplate code that can be standardized. And then you also have to integrate with Wise. You have to integrate with the internal APIs that we have. And when we built an integration, it usually took us six weeks to do one from a technical perspective. But a lot of it was repetitive work. And we had some differences between, you know, how different teams did it.

When I and my team were working on this big integration, we were connecting Wise to the Hungarian payment scheme directly, to the Central Bank directly. COVID hit. So, um, we knew that that meant a delay. And then we were really thinking about, okay, now there is this delay, we still have to work on this. How can we build this integration in a way where it’s going to radically reduce time to market for the next one? Because we know this is not the last central integration that we are going to do. We knew that, you know, like, singapore was only, like, a couple months ago. So it made sense to, like, really invest. We also wanted to reduce the blast radius. And we also wanted to have this ability to frequently release if we have to make a change.

So what we came up with was a library that you can just pull into your service and this library will abstract away the core behavior of an integration. It’s going to have a database. It’s going to create a database for you. It’ll have a state machine inside that is going to track the different statuses of the payments that you have, which have different names in different countries or different integrations. But you can kind of come to a standardized way of storing them. And once you have this, it also knows how to talk to Wise, how to talk to the interfaces that govern Wise, how to execute a payout, how to report how much money has moved out, all these different things. So all you have to do is really to plug in the API calls that connect us to the partner.

One other thing that was key is that this library also came with a back office UI, which made it really easy for not just engineers but operations to find issues to look under the hood, like, what happened with this payment? What was the error code? How can I resolve this? We were able to do this in a generic way. And once we built this for Hungary, then our Asian team did it for Singapore. And we’ve replicated this solution now, I think over 20 integrations. And it’s not an exact measurement, but roughly, we save four weeks on one integration that we build.

[00:30:12] Managing Change Coupling

Henry Suryawirawan: Very interesting approach. Like, you build a library, like, an SDK kind of thing, where you kind of, like, abstract away all these core, maybe, core models, right? The state machine you mentioned. And maybe even some parts of the back office UI for maybe operations team to support the service. Some people may move away from this kind of model, but because of the, for example, the change coupling, right? So imagine you have hundreds of integrations, you change the core library and you distribute to all. How do you ensure that things will still work among all the integrations, because each partner can also evolve, right? They have new release, they have new data model, new attributes being introduced, or new way of authenticating, right? So how do you make sure all this doesn’t introduce, like, a dependency like, a tight dependency between the core library and also each integration service.

Balazs Barna: We try to be very cautious in changing this library and adding, like, new requirements. And once we add something, we try to make sure that it’s not going to be a breaking change, but more, like, an extension. You know, like, closed for modification, open for extension. But yes, you’re right. The problem is there, but the only changes we had to do so far were kind of these extensions that weren’t breaking changes for the rest of the integrations. And there is really strong ownership around this piece of code. And really strong code reviews are done. So this is how we are trying to make sure that this dependency is not going to backfire.

Henry Suryawirawan: Right, I think one of the key probably is also, like, you have kind of, like, nailed down the so-called design or the domain part of the core library, right, so it stays stable rather than keeps changing, right? Because if you keep changing, then others also will get affected.

Balazs Barna: Yeah, so when we designed it, we’ve already built twenty plus integrations in Europe. So we kind of knew what the standard is. And what we see with these integrations is that banks and partners are also moving to a standardized way of doing things. And if, yes, if you get the abstraction level right, then, you know, like, changes with the different integrations are much, much easier to live with.

Henry Suryawirawan: Let’s move on to the second aspect of your sustainability, right, which is about the sustainability of the team. Because not just the aspect of technical part, right, you also need to have a sustainable team. So tell us how we can build a more healthier teams. Because many teams that I’ve found in the tech industry, especially in startup, scale up is, you know, they are burnout. They have so many things to do, you know, the cultural change and things like that.

[00:32:46] Sustainable Team

Balazs Barna: I think, to me there are many things obviously that you can do, like, happy hours and things like that. But maybe the two most important aspect to me is, one, that the team is learning and the other is clarity and the pace that you go with. So, what I mean by the team is learning and growing, I don’t mean it as, like, growing in terms of headcount. That’s not the only kind of growth that you can have.

But one thing that was really a challenge with the regional teams that I’ve worked with is that your job is to find product market fit. And when you start with, you hire almost extensively backend engineers, because what you have to build is these integrations with the partners. And then what you do is you implement all the features in your own market that Wise has built, that the core team has built, right. I can give you a couple of examples. Be able to hold money in a currency and be able to give people bank details so they can share that bank details and receive money to that. You give people interest. You give them a debit card so they can spend the money, right?

So when you’ve done all of that and you built all the integrations that you had to build, you kind of run out of backend problems. So you have to be able to iterate on these products and that requires a different skillset. So one thing I look at as, like, a flag, if a team has to reach product market fit, but still has the same skillset, then my gut says that they are still iterating on the same problem, right? They’re not finding, like, new problems or they haven’t solved the ones that they started with.

And what was helpful for us is that, first, we had one North America team, and then we created teams with strong domain knowledge. So if you look at our North America teams, we have an onboarding team, we have send team, we have a Wise account team, we have a team that looks after payments. And this kind of mimics the same way the core teams organize themselves, right? So we have, like, a brother and sister team in the core teams everywhere. And this is how we ensure that we are not just hacking things in, but there is a deep understanding of the domain and the technical architecture that we are working on. So that’s really key that you can become an expert in a domain, even in a regional team over time. And there is that evolution of skill sets as well.

So one thing that we started this year was that we noticed that a lot of the time, we have to touch mobile, right? There’s just no way around it. And we didn’t have mobile engineers. So what we did, we hired an Android engineer. Now we’ve hired an iOS engineer as well. So this way, our teams also feel, like, they can do something about a mobile problem. It’s not that they have to ask another team, but they have ownership of that. And the mobile customers are just as important as the customers who are using us on the web. And so culturally and momentum wise, it’s really important that the domain knowledge keeps evolving and also the skillset in the team is not the same as a couple of years back.

[00:35:57] Dealing With Technical Debt

Henry Suryawirawan: Right. Another thing as part of the sustainable team pace, right, is something that deals with the tech debt, right? I think in most engineering teams they will have tech debt, right? Is there a way that you do systematically advise in order to deal with the tech debt such that it doesn’t impact the sustainability of the team’s pace?

Balazs Barna: Yes, there is different ways of dealing with this. Most of my teams, the leads are doing maintenance weeks or maintenance sprints. So they carve out a week or two, either at the beginning of the quarter or the end of the quarter, preferably, the beginning of the quarter, because then you make sure that you’re going to do it. And then on that week, they clean out the most important tech debt things that they wanna solve. That’s when they upgrade the services, upgrade the dependencies, and this is a way of making sure that things remain healthy.

What I also think is important is that… What is that? The Boy Scout principle? Like, when you go somewhere and you change something, you leave things better than you found them. So that’s something that I also try to do when I code. If I want to, like, fix something and I see that this code is outdated or deprecated, I take the time to remove that or refactor it, and not just, you know, like, add another line to add this feature. So that culture is really helpful and these small things add up at the end of the day.

Henry Suryawirawan: Right. So I think that’s very, very interesting, right? Maintenance week. Do it in the beginning of the quarter. It depends on your, you know, roadmap planning. But that probably helps to get things done, because if you put it at the back, most likely you, you will have the product roadmap that kind of, like, delays or maybe extend a little bit, right? And you will not get to do all this tech debt.

[00:37:41] Steady Pace

Henry Suryawirawan: Yeah, so I think dealing with tech debt is one thing, right? So you ensure that the team’s pace is still sustainable and stable, right? But also another important part is to have the steady pace, right? It’s not, like, up and down, up and down, where people get in a burst of pace, but then slows down, right. So how do you find a steady pace for your team as well? Is there any tips and tricks that you do differently?

Balazs Barna: It’s a really interesting question. I think a team has to be able to go fast if they have to. I think that’s also really good to do as a test sometimes. But you should always choose to go with a steady pace, most of the time. So I, I have a story about this. I was talking to one of my coworkers and we did a change that really needed to be done urgently. We just went into a room, you know, uh, 9:00 AM. I thought about the solution. We had a decision in two hours. During that day we iterated on the problem, like, two more times, and in two days we released it. We were on the team going out. And I was telling him, like, look, this was awesome. Like, the fact that we can make a decision in two hours and then we can iterate on it, and then we can release it. And it’s going to work, with a change like this, this is really, really cool. And then he looked at me and said, like, “Yeah, it’s cool, but we shouldn’t do this.” And he’s right. Because if everything is important, then nothing is important. Even if everything is urgent, you know, like, then nothing is urgent. So you always have to find the right balance between these things.

I think the value in this is that you see if your team is strong from time to time and if the systems that you have are strong. Because, like, when you have this things that are going to happen from time to time that you have to do something really fast. And then you’re going to find out if, you know, your systems are not scaling or if there’s a design problem that you cannot really solve. So from that perspective, it’s really good. But on the long run, what we really emphasize is for each team to find their own space and pace. Do things in the regular way. Do things on the ceremonies that they have. Respect that. And try to find that right balance.

Henry Suryawirawan: And I’m sure limiting work in progress that you mentioned in the beginning is also part of the trick, right? To ensure that you have a steady pace. It’s not, like, a burst of pace, up and down.

[00:39:59] Building a Bench

Henry Suryawirawan: So let’s go to the next aspect of sustainability that you mentioned, right, which is about building a bench. So maybe we can elaborate a little bit more about bench here. Is it more, like, a capacity planning or is it, like, a substitute for managers and leaders? So tell us what do you mean by bench?

Balazs Barna: So what I mean by bench is, most of us want to go on vacation sometime, right? So that’s kind of why, like, an immediate reason why this is important. What I mean by this is succession planning, mostly. So when you go on vacation and you’re not going to be available, as a leader, I think that’s kind of the test of what you’ve built, right? So the people and the processes that you have are the company, and the code or the product is merely the outcome of that, right? And if you hire good people, you onboarded them well, and you have the right processes in place, then you know you shouldn’t be needed all the time.

So I think at every lead’s life, there is going to be a time when you want to move on. You want to take on another challenge, and then it’s, like, really, really important. It’s much more important than your vacation that the team is going to survive without you. So a key aspect of this decision is who is going to be the person? Who is going to take your place? And we already talked about what is important in an engineering manager or any kind of leader, right? Do they have the clarity? Do they bring clarity? Do they have the energy?

One key thing to me is, do they have a strong tech background? So I think it’s really important that before you become a tech lead, you’re at least on, like, an IC five level, what most companies call IC five, so the senior engineer. You’ve seen bigger projects. You own bigger projects, you’ve done that. This is apart from the empathy and liking to work with people.

And then what I also like to look at is, like, what is the motivation? Like, why do you want to be a lead? Do you get positive energy out of, you know, dealing with people? Do you really enjoy those conversations that take place with between, like, product and engineering? Do you like these alignments that you have to have with multiple stakeholders? Are you strategic about things? Do you like to put structure around things? I think that’s, really, really key.

And one of the best examples that I’ve seen this, in my career was, um, a guy that I worked with in Europe. He was a junior engineer. When he joined, he only had one or two years of experience. And he was the kind of person who, you know, always said yes to anything. Like, you had a problem. You know, I’m on it. Without knowing, you know, whether he has a chance of solving the problem, he just jumped on it. And then we hired, as we built up the team, we hired more and more senior people. So we asked, like, who is going to onboard them? And he was the first one, I’ll do it. I was, like, okay, let’s see how it goes.

And then, um, as they were onboarding this person, what I noticed that even after the onboarding period, this person who had, like, 10 plus experience and was a lead before, was still coming to this guy who had two years of experience, but was an expert in the domain and, like, just loved to learn. And there was, like, a genuine relationship between them that, like, the more senior engineer was, like, coming to him for advice. So that made me think that the strengths here are really on, you know, like, becoming an engineering manager. So. we put him on a fast track to become a lead. And within, like, one and a half years, or, like, two years, he was, like, leading, a smaller team. So, that’s one of the best stories that I’ve seen, you know, of someone becoming a lead.

One thing, how I like to think about it is that there are people who are leads even without the title. How I would like to think about my job is, I want to put people in a position where they are leads without the title. And then my job is just really easy. I just have to convince my lead and the others to, you know, like, promote this person. But the core of it is, like, already there.

Henry Suryawirawan: Yeah, sometimes I think in your team, right, you could identify this kind of person, where they have a high agency, high ownership, they lead without having the title. And I think, as a leader, it’s an easier job, right? You just give them the title once they showcase and people also vouch for them, right? I think that’s really, really a good story for all of us to learn from, right? So it is not all the time that we have to wait for opportunity given to us. We can also create our own opportunity.

So I think another thing that I learned from what you’re sharing is that the key is also identifying the strengths of your team, right? So to build a proper bench. And also as the leader kind of, like, wants to move on, you’ll be able to build a succession plan within the team. So don’t forget about that for all the leaders who are listening because, sometimes, yeah, we want to move on, right? And the team should still be sustainable. I think that’s, again, the key theme of what Balazs has been mentioning since the beginning.

[00:44:51] 3 Tech Lead Wisdom

Henry Suryawirawan: So, Balazs I think it’s been a great conversation. Thank you so much for your sharing about, you know, growing Wise. Unfortunately we reach the end of our conversation, but I have one last question that I would like to ask you, which I call the three technical leadership wisdom. So you can think of it just like a summary of advice that you wanna give for all of us to learn from you.

Balazs Barna: Cool. Thanks so much for having me. I think the first thing that I would say is, I learned this from our product director in North America, is to think about your role literally consciously. Learn what gives you joy and energy, and make sure that you do those things regularly, like, in your work. Otherwise, you will burn out. I think that’s the, that’s the first one.

The second one is to block out the noise. Like, block out the market. Block out where other people are in their careers and just have an inner scoreboard. Building things takes time. Especially, as a leader, you work with people. So building an organization will take a longer time. It’s very hard to see results within a year. And all of the people that I know who made a big impact and were really successful, they put in long years in their life, you know, to solve that one problem. And these people typically have a lot of opportunities, right? So they’re really good at saying no to those opportunities and just, like, lock in on what they want to achieve.

And then the last thing is, so, you cannot learn if you think you already know. If you think that you possess some skill and you are great at it, you usually don’t see the things that could make you better. And usually, this drive to learn new things becomes, you know, like, much, much weaker. And whenever I, uh, felt, like, I stagnated in my career, it was because of this. Because I thought, okay, I did these things and I already know, and I stopped looking for, like, ways to improve. What helps you is if you can surround yourself or have people in your life who are still inspiring you and who can still, like, show you that there are levels to everything, right? So just because you can, you know, like, run fast, it doesn’t mean that you are Usain Bolt.

Those are kind of the three things that I would mention.

Henry Suryawirawan: Wow. Thank you so much. I think those are really deep, right? So if I can summarize, like, the first thing is be conscious on what things to focus on, right? What things that brings you energy. And don’t forget to do them because sometimes we know what we like, but we don’t do them for, you know, maybe we are busy, maybe we got tied up with so many different things in life, right? The second thing is about blocking out the noise and distractions and to focus on what we want to achieve in a longer time. And the third one is you can’t learn if you think you already know. So really beautiful.

So thank you so much, Balazs. If people want to connect with you, they wanna reach out and ask you questions, is there a place where they can find you online?

Balazs Barna: Yes, I’m on LinkedIn. Let’s connect and chat there. And we are hiring in Austin. We are hiring product managers and then engineers. So if you know someone, if you are someone who would like to work with us, then hit me up.

Henry Suryawirawan: So thank you so much for your time. Again, good luck with all the Wise growth, the next stage.

Balazs Barna: Thank you so much.

– End –