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, because if everything is important, then nothing is important, even if everything is urgent, You know, like the nothing is urgent 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. Hey everyone, my name is Henry Surya Virawan and you're listening to the Technically Journal Podcast, the show where I'll be bringing you the greatest technical leaders, practitioners and thought leaders in the industry to discuss about their journey, ideas and practices that we all can learn and apply to build a highly performing technical team and to make an impact in your personal work. So let's dive into our journal. Hello again, my friends and my listeners.
You're listening to the Tech Legional 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 Legional's bite sized contents on LinkedIn, X, Instagram, YouTube, and TikTok. Please support me and this podcast by either buying me a coffee at Tech Legional dot Dev tip or becoming a patron at Tech Legional dot Dev Patron. My guest for today's episode is Balas Barna.
Balas is the head of US Engineering at Wise. In this episode, we delved into his insights on building sustainable engineering from Scaling up. Wise. Balas 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, the last outline 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 Podcast 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 conversation with Balas after quick words from our sponsor. Hey, a quick message for those of you who are listening to this episode on Spotify, I have a
small favor to ask. Spotify now allows mobile users to rate podcasts. I would really appreciate it if you can take a quick pause to go to the Tech Lead Journal podcast page and leave your favorite show your best rating on Spotify. It will help me a lot to get this podcast to reach more people on the platform. Thanks a lot. Hey everyone, welcome back to another new episode of the Tech Lead Journal Podcast. Today I have with me Balash Barna. I hope I pronounce your name correctly.
So he is the head of WISE US engineering team. 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, Ballas. Thank you. Thank you so much. Right. So ballas. I always love to ask my guests to first introduce themselves.
Maybe if you can share some highlights or turning points that you have in your career so that we can all learn from you. Absolutely. I've been coding and 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 6 and I started coding first in assembly, then CC plus Plus 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. I learned a lot throughout the program, stayed with them for another four years, and then I moved to another company which is a spin off of Morgan Stanley, pretty similar to what I've did what I've done previously. I stayed there for three years. I was redesigning the system that is super important for the business. It was the corporate demand system and 6 1/2 years ago I 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. 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're 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. Thank you so much for sharing your experience, your journey.
I think that was quite a interesting journey because you started from an IC, when to become a tech lead, when to become an engineering manager, a few teams and now you become the head of engineering at a large global team, right?
Even though you're based in US, but 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 will be your key advice for them in the 1st place right? How should they take opportunity and also maybe build their profiles? I think the key thing to this is building on your strength.
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 engine management is not for everyone. They're 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 Burke, I think that the best course of action is just to stay there and see like where you can have the most impact. 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? So I think in terms of trying to understand this role and how do we evaluate the job or how the job was done, I think the first thing is, can you and your team
get things done right? Most companies have KPIs or OKRS, whatever you want to 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 long 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 another challenge? Yeah, yeah. I think things done. I think it's 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? 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. 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. 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 KPI S 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. I think like a very obvious, very simple rule that you can apply just a 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 3 or 4. 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. Right, that thing is very precious tips because limiting work in progress is 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 de Grandis 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 are working on and probably limiting the work in progress. Just like Balas mention, maybe put a limit like a big project assigned to engineers. Divide by the total number of engineers.
That kind of like the limit of how many things can be tackled by your team. Sorry, just one thing that 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 OK Rs and I published 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 be 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.
Right. I think that's 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. Yep, 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. 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 2nd is can you do it sustainably.
I think that if somebody doesn't get things done in an 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 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 AC 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 their kind of leader where they don't have a bench, they do everything in a team. These are the things that are much harder to identify and much harder to help with. Yeah. So I think the 2nd 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. 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 1/2 years in wise now, right? So you have grown them from maybe like small team up to the expansion to the US now 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? That's a really tricky question because as 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 original teams live in otherwise? So with more startups, they 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 4500. So this was some crazy growth like operationally the markets that we launched and in 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 road map, 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 week code ownership. My lead doesn't like this term week code ownership because there is still a team that owns the code base, like it 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 a 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 3 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 were 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 micro service architecture when 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 the 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 and production. So because of these things we reiterated on these macro services and then came to a solution which is going to be a partner based, you know like small micro service that just does one job and that's kind of like an overview of what regional teams went through in the last six years. Wow, there are so many things that maybe if we can just go a few of them, right? So the first one is what you mentioned, weak code ownership.
So from my understanding this is similar to probably in the open source world, right, where you have a few core committers, 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 are 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. Yeah, those are great questions. I think it's very similar to
that. Yes, 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 advise. I think we have reasonably clean services like a clean architecture.
The architecture differed 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 may be 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 1000 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 1000 lines of code and then you say like, hey, I'd really like this to be released tomorrow and that's something that doesn't work usually. Right. Not to mention the kind of risk that if you just merge 1000 lines of code, right, what impact it will introduce. So maybe elaborate a little bit more on the core team, right? Are there a lot of people as part of this 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 understands 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. 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 are 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 and 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. I was in an 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 they prioritize 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 kick start all this? I think it was.
It was always like this. It was always very problematic. 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?
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 2 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, OK, 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? It'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. Yeah, 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 Balas just mentioned. The other thing that I picked interest is the journey from your monolith to micro service and you know now becomes like even more granular, right. Some people find it challenging to move to like hundreds of micro services, 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? 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 that 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 was working on this big integration, we were connecting wise to the Hungarian payment scheme directly to the
central bank directly COVID hit. So we knew that that meant to delay and then we were really thinking about, OK, 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're going to do. We knew that you know like Singapore was only you know 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. If you have a state machine inside, that's 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 the 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 codes 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 Asia 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.
Very interesting approach like you build a library like an SDK kind of thing where you kind of like abstract way or this 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. 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 close 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 right? And I think one of the key probably is also like you have kind of like nailed down the circle 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. Yeah. So when we designed it, we've already built Plenty 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.
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 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.
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 aspects 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 head count. 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 back end 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 the 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 build all the integrations that you have to build, you kind of run out of back end problems. So you have to be able to iterate on these products and that requires a different skill set.
So one thing I look at as like a flag, if a team has to reach product, market fit but still has the same skill set, then my gut says that they are still iterating on the same problem, right? They're not finding the 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 a send team, We have a wise account team. We have a team that looks after pay insurance 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're not just hacking things in, but there is a deep understanding of the domain and the technical architecture that we're 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 an 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 and now we've hired an iOS engineer as well. So this way our teams also feel like they can do something about the 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 skill set in the team is not the same as a couple of years back. 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 at Wise in order to deal with the tech debt such that it doesn't impact the sustainability of the team space? 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 things that they want to solve. That's when they upgrade the services, upgrade the dependencies and this is a way of making sure that teen 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. Right. So I think that's very
interesting, right. Maintenance, we do it in the beginning of the quarter. It depends on your, you know, road map 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 road map that kind of like delays or maybe extend a little bit, right? And you will not get to do all this. Technet. Yeah. So I think dealing with Technet 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? 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 Co workers and we did a change that really needed to be done urgently. We just went into a room, you know 9:00 AM, talked about the solution. We had a decision in two hours during that day. We iterated on that 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 if 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 the 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, be 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 emphasizes 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 trying to find that right
balance. 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. So let's go to the next aspect of sustainability that you mentioned, right, which is about building a bench. So maybe you 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? So what I mean by bench is that 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 a 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're hired good people, you onboarding 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 is much more important than your occasion 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. 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 like an IC5 level, but 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 on things? I think that's really, really key and one of the best examples that I've seen this. My career was 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 on board them and he was the first one. I'll do it. I was like OK, let's see how it goes.
And then as they were onboarding this person, when 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 love 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 engineer manager. So we put him on a fast track to become a lead and within like 1 1/2 years or like 2 years, he was like leading a smaller team. So that's one of the best stories that I've seen. You know, 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. Well, how I like to think about my job is I want to put people in a position where their leads without the title. And then my job is just really easy. I just have to convince my lead and others to, you know, like promote this person. But the core of it is like already there. 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? So I think that's really, really a good story for all of us to learn from, right? So it's 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 we want to move on, right. And the team should still be sustainable. I think that's again the key theme of what Balas has been mentioning since the beginning. So Balas, I think it's been a
great conversation. Thank you so much for your sharing about, you know, growing wise. Unfortunately we reached 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 want to give for all of us to learn from you. 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 locking 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're 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 felt like I stagnated in my career, it was
because of this. Because I thought, OK, 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 to 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 like, run fast, it doesn't mean that you're using Bolt. Those are kind of the three things that I will mention.
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? And 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 Balas. If people want to connect with you, they want to reach out and ask you questions. Is there a place where they can find you online? 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 or you are someone who would like to work with us, then hit me up. So thank you so much for your time again, good luck with all the wise growth the next stage. Thank you so much. Thank you for listening to this episode and for staying right
until the end. If you highly enjoyed it, I would appreciate if you share it with your friends and colleagues who you think would also benefit from listening to this episode. And if you're new to the podcast, make sure to subscribe and leave me your valuable review and feedback. It helps me a lot in order to grow this podcast better.
You can also find the full show notes of this conversation on the episode page at Techni journal dot dev website, including the full transcript, interesting quotes, and links to the resources mentioned from the conversation. And lastly, make sure to subscribe to the Shells mailing list on Techly journal dot dev to get notified for any future episodes. Stay tuned for the next Techly Journal episode, and until then, goodbye.