1 00:00:00,240 --> 00:00:04,480 A-Team has to be able to go fast if they have to. 2 00:00:04,480 --> 00:00:09,640 I think that's also really good to do as a test sometimes, but 3 00:00:09,640 --> 00:00:13,280 you should always choose to go with a steady pace most of the 4 00:00:13,280 --> 00:00:17,320 time, because if everything is important, then nothing is 5 00:00:17,320 --> 00:00:20,360 important, even if everything is urgent, You know, like the 6 00:00:20,360 --> 00:00:22,080 nothing is urgent on the long run. 7 00:00:22,240 --> 00:00:25,400 What we really emphasize is for each team to find their own 8 00:00:25,400 --> 00:00:29,840 space and pace, do things in the regular way, do things on the 9 00:00:29,840 --> 00:00:33,320 ceremonies that they have, respect that, and try to find 10 00:00:33,320 --> 00:00:41,320 that right balance. Hey everyone, my name is Henry 11 00:00:41,320 --> 00:00:45,480 Surya Virawan and you're listening to the Technically 12 00:00:45,480 --> 00:00:48,640 Journal Podcast, the show where I'll be bringing you the 13 00:00:48,640 --> 00:00:51,760 greatest technical leaders, practitioners and thought 14 00:00:51,760 --> 00:00:55,160 leaders in the industry to discuss about their journey, 15 00:00:55,440 --> 00:00:59,960 ideas and practices that we all can learn and apply to build a 16 00:00:59,960 --> 00:01:03,480 highly performing technical team and to make an impact in your 17 00:01:03,480 --> 00:01:06,720 personal work. So let's dive into our journal. 18 00:01:11,760 --> 00:01:13,680 Hello again, my friends and my listeners. 19 00:01:14,080 --> 00:01:17,120 You're listening to the Tech Legional Podcast, a podcast on 20 00:01:17,120 --> 00:01:18,960 technical leadership and excellence. 21 00:01:19,320 --> 00:01:22,440 If you haven't, please subscribe on your favorite podcast app to 22 00:01:22,440 --> 00:01:25,720 get notified for new episodes. Also, subscribe to Tech 23 00:01:25,720 --> 00:01:29,320 Legional's bite sized contents on LinkedIn, X, Instagram, 24 00:01:29,400 --> 00:01:32,360 YouTube, and TikTok. Please support me and this 25 00:01:32,360 --> 00:01:35,560 podcast by either buying me a coffee at Tech Legional dot Dev 26 00:01:35,560 --> 00:01:40,080 tip or becoming a patron at Tech Legional dot Dev Patron. 27 00:01:41,360 --> 00:01:43,920 My guest for today's episode is Balas Barna. 28 00:01:44,440 --> 00:01:47,120 Balas is the head of US Engineering at Wise. 29 00:01:47,680 --> 00:01:50,840 In this episode, we delved into his insights on building 30 00:01:50,840 --> 00:01:53,040 sustainable engineering from Scaling up. 31 00:01:53,040 --> 00:01:55,880 Wise. Balas started by touching on the 32 00:01:55,880 --> 00:01:59,280 engineering management role and described the traits of good and 33 00:01:59,280 --> 00:02:02,560 bad engineering management. We then went to discuss two 34 00:02:02,560 --> 00:02:05,520 different aspects of sustainable engineering which are 35 00:02:05,520 --> 00:02:08,120 sustainable tech and sustainable teams. 36 00:02:08,720 --> 00:02:12,160 Throughout the discussion, the last outline several key 37 00:02:12,160 --> 00:02:16,000 practices such as weak code ownership, microservice 38 00:02:16,040 --> 00:02:19,360 strategy, stable pace and building a bench. 39 00:02:20,320 --> 00:02:23,120 I hope you enjoy listening to this episode and learning 40 00:02:23,120 --> 00:02:25,680 insights on scaling up and building sustainable 41 00:02:25,680 --> 00:02:28,080 engineering. If you enjoy listening to this 42 00:02:28,080 --> 00:02:31,440 episode, please do share it with your colleagues, your friends 43 00:02:31,480 --> 00:02:35,320 and communities and leave a five star rating and review on Apple 44 00:02:35,320 --> 00:02:38,840 Podcast and Spotify. Your small help will help me a 45 00:02:38,840 --> 00:02:42,000 lot in getting more people to discover and listen to this 46 00:02:42,000 --> 00:02:44,080 podcast and I really appreciate it. 47 00:02:44,600 --> 00:02:47,680 So let's now go to my conversation with Balas after 48 00:02:47,680 --> 00:02:51,360 quick words from our sponsor. Hey, a quick message for those 49 00:02:51,360 --> 00:02:54,760 of you who are listening to this episode on Spotify, I have a 50 00:02:54,760 --> 00:02:58,720 small favor to ask. Spotify now allows mobile users 51 00:02:58,720 --> 00:03:01,800 to rate podcasts. I would really appreciate it if 52 00:03:01,800 --> 00:03:04,800 you can take a quick pause to go to the Tech Lead Journal podcast 53 00:03:04,800 --> 00:03:07,800 page and leave your favorite show your best rating on 54 00:03:07,800 --> 00:03:10,200 Spotify. It will help me a lot to get 55 00:03:10,200 --> 00:03:12,880 this podcast to reach more people on the platform. 56 00:03:13,280 --> 00:03:18,160 Thanks a lot. Hey everyone, welcome back to 57 00:03:18,160 --> 00:03:20,480 another new episode of the Tech Lead Journal Podcast. 58 00:03:20,480 --> 00:03:22,600 Today I have with me Balash Barna. 59 00:03:22,760 --> 00:03:24,520 I hope I pronounce your name correctly. 60 00:03:24,800 --> 00:03:27,520 So he is the head of WISE US engineering team. 61 00:03:28,040 --> 00:03:31,240 So looking forward to learning from you, how do you actually 62 00:03:31,320 --> 00:03:35,560 build and grow and scale the US engineering team for Wise And 63 00:03:35,560 --> 00:03:38,160 there will be a lot of super learning from your experience I 64 00:03:38,160 --> 00:03:40,080 believe. So welcome to the show, Ballas. 65 00:03:40,760 --> 00:03:42,240 Thank you. Thank you so much. 66 00:03:42,840 --> 00:03:43,720 Right. So ballas. 67 00:03:43,760 --> 00:03:47,120 I always love to ask my guests to first introduce themselves. 68 00:03:47,120 --> 00:03:49,520 Maybe if you can share some highlights or turning points 69 00:03:49,520 --> 00:03:52,280 that you have in your career so that we can all learn from you. 70 00:03:52,800 --> 00:03:56,120 Absolutely. I've been coding and I've been, 71 00:03:56,120 --> 00:03:58,280 you know playing with computers since I was very little. 72 00:03:58,480 --> 00:04:00,720 I didn't really have a choice in the matter. 73 00:04:00,720 --> 00:04:04,800 My father is a software engineer and he introduced me to all of 74 00:04:04,800 --> 00:04:07,280 it. I was building my own PC when I 75 00:04:07,280 --> 00:04:13,480 was 6 and I started coding first in assembly, then CC plus Plus 76 00:04:13,480 --> 00:04:17,959 into object oriented programming C# and in the last 10 years I've 77 00:04:17,959 --> 00:04:21,000 been working mostly with the Java based systems. 78 00:04:21,480 --> 00:04:24,920 After university I joined Morgan Stanley, the graduate program 79 00:04:24,920 --> 00:04:28,440 that they had. I went to London, New York for a 80 00:04:28,440 --> 00:04:30,880 short stint. I learned a lot throughout the 81 00:04:30,920 --> 00:04:34,400 program, stayed with them for another four years, and then I 82 00:04:34,400 --> 00:04:37,560 moved to another company which is a spin off of Morgan Stanley, 83 00:04:37,640 --> 00:04:41,280 pretty similar to what I've did what I've done previously. 84 00:04:41,760 --> 00:04:46,320 I stayed there for three years. I was redesigning the system 85 00:04:46,800 --> 00:04:49,360 that is super important for the business. 86 00:04:49,360 --> 00:04:54,160 It was the corporate demand system and 6 1/2 years ago I 87 00:04:54,160 --> 00:04:56,920 decided to join Wise in our Budapest office. 88 00:04:56,920 --> 00:04:59,440 I was one of the first engineers to join there. 89 00:04:59,800 --> 00:05:02,760 I joined as an IC. Then I became a lead. 90 00:05:03,000 --> 00:05:07,080 Within the first six months, I started to work in the European 91 00:05:07,080 --> 00:05:10,440 expansion teams, which was just one team basically with two 92 00:05:10,440 --> 00:05:14,560 engineers at the time. I built it up to 17 engineers 93 00:05:14,560 --> 00:05:19,440 and three teams and then I took on another challenge and I 94 00:05:19,440 --> 00:05:23,320 started to work with the US teams who are building our 95 00:05:23,320 --> 00:05:26,280 banking integrations and trying to find the product market 96 00:05:26,280 --> 00:05:30,880 within the US. the US is now our biggest market and the biggest 97 00:05:30,880 --> 00:05:33,240 opportunity. I felt like that would be a 98 00:05:33,240 --> 00:05:35,240 challenge that is worth on taking on. 99 00:05:35,680 --> 00:05:40,280 I moved to Austin in 2022 from Budapest and in Austin we're 100 00:05:40,280 --> 00:05:44,400 building a new office, a new site, a new headquarters for our 101 00:05:44,520 --> 00:05:48,080 US based teams. And since 2022, we've hired 200 102 00:05:48,080 --> 00:05:51,960 people and roughly 10% of that is engineering. 103 00:05:52,840 --> 00:05:55,840 Thank you so much for sharing your experience, your journey. 104 00:05:55,840 --> 00:05:59,080 I think that was quite a interesting journey because you 105 00:05:59,080 --> 00:06:02,520 started from an IC, when to become a tech lead, when to 106 00:06:02,520 --> 00:06:05,440 become an engineering manager, a few teams and now you become the 107 00:06:05,440 --> 00:06:08,560 head of engineering at a large global team, right? 108 00:06:08,800 --> 00:06:12,680 Even though you're based in US, but maybe from all these journey 109 00:06:12,680 --> 00:06:16,000 for those people who are listening who are aspiring to 110 00:06:16,000 --> 00:06:19,160 have the same journey as yours, because I believe so many 111 00:06:19,160 --> 00:06:21,920 engineers would want to aspire to have the same journey as 112 00:06:21,920 --> 00:06:25,200 yours, What will be your key advice for them in the 1st place 113 00:06:25,200 --> 00:06:27,000 right? How should they take opportunity 114 00:06:27,000 --> 00:06:28,920 and also maybe build their profiles? 115 00:06:29,480 --> 00:06:33,240 I think the key thing to this is building on your strength. 116 00:06:33,680 --> 00:06:37,800 So you have to be aware of what your strengths are, and once you 117 00:06:37,800 --> 00:06:42,280 know them, you should find people who can help you move 118 00:06:42,280 --> 00:06:47,480 fast, Give you advice, and also have a job where that job is 119 00:06:47,480 --> 00:06:49,720 going to allow you to build on those skills. 120 00:06:49,880 --> 00:06:54,000 I think that's the first thing. I think engine management is not 121 00:06:54,000 --> 00:06:57,680 for everyone. They're engineers where it's 122 00:06:57,680 --> 00:07:00,440 much better if they stay on the IC track. 123 00:07:00,720 --> 00:07:05,000 If you see that what gives you energy is more the IC Burke, I 124 00:07:05,000 --> 00:07:08,560 think that the best course of action is just to stay there and 125 00:07:08,560 --> 00:07:10,600 see like where you can have the most impact. 126 00:07:11,480 --> 00:07:13,000 I think, yeah, it's very, very important, right. 127 00:07:13,000 --> 00:07:15,560 Like what you said, engineering management I believe also is not 128 00:07:15,560 --> 00:07:18,480 for everyone, especially if you don't like dealing with a lot of 129 00:07:18,480 --> 00:07:22,040 people's challenges, right. So I think one of the key 130 00:07:22,040 --> 00:07:24,720 strengths of yours, which I believe you also mentioned to me 131 00:07:24,720 --> 00:07:27,560 is actually dealing with engineering management, right. 132 00:07:27,960 --> 00:07:31,920 So maybe if you can give us some of your personal perspectives. 133 00:07:32,160 --> 00:07:35,120 What do you think are some of the key traits of a good 134 00:07:35,120 --> 00:07:39,320 engineering management? So I think in terms of trying to 135 00:07:39,320 --> 00:07:43,800 understand this role and how do we evaluate the job or how the 136 00:07:43,800 --> 00:07:47,680 job was done, I think the first thing is, can you and your team 137 00:07:47,680 --> 00:07:51,440 get things done right? Most companies have KPIs or 138 00:07:51,440 --> 00:07:54,800 OKRS, whatever you want to call them, the business goals, the 139 00:07:54,800 --> 00:07:57,560 outcome that you want. That's the first thing, like can 140 00:07:57,560 --> 00:08:00,680 you get your team there? And the second thing, which is 141 00:08:00,680 --> 00:08:05,240 the much harder one, is can you do this sustainably and over, 142 00:08:05,280 --> 00:08:07,200 you know, like a long period of time? 143 00:08:07,600 --> 00:08:13,160 And this can be broken down into multiple categories, like are 144 00:08:13,160 --> 00:08:16,640 your technical decisions or system decisions sustainable? 145 00:08:17,000 --> 00:08:20,320 Do you have a team health, like a learning team that keeps on 146 00:08:20,320 --> 00:08:24,040 growing? And the last part is can you 147 00:08:24,040 --> 00:08:26,880 build a bench? Can you build up someone in your 148 00:08:26,880 --> 00:08:31,280 team who can do what you do and maybe even do a better job so 149 00:08:31,280 --> 00:08:34,159 you can take another challenge? Yeah, yeah. 150 00:08:34,159 --> 00:08:36,440 I think things done. I think it's like a basic 151 00:08:36,440 --> 00:08:39,360 prerequisite, right, for all the manager or leaders, right. 152 00:08:39,600 --> 00:08:42,760 So I think getting things done sometimes is probably trickier 153 00:08:42,760 --> 00:08:45,720 in some places than the others. And I think maybe if you can 154 00:08:45,800 --> 00:08:48,800 elaborate from the organization point of view, how can they 155 00:08:48,800 --> 00:08:53,400 facilitate teams or managers to actually get things done much 156 00:08:53,400 --> 00:08:56,680 easier? I think that the first thing 157 00:08:57,000 --> 00:08:59,960 that is really important in any team is to have a common 158 00:08:59,960 --> 00:09:03,480 understanding of what the goals are and what's important. 159 00:09:03,800 --> 00:09:07,280 What's not important? Can you distinguish between 160 00:09:07,520 --> 00:09:11,360 important and urgent? I think that's definitely a key 161 00:09:11,360 --> 00:09:14,040 thing. And the other thing is, once you 162 00:09:14,040 --> 00:09:18,240 have that understanding, can you block out all the noise that 163 00:09:18,240 --> 00:09:20,680 comes to you? Can you make sure that you 164 00:09:20,960 --> 00:09:23,840 remain focused? You don't take on too many 165 00:09:23,840 --> 00:09:28,640 things and you still build up this momentum of getting things 166 00:09:28,640 --> 00:09:30,880 done. You know, whatever you start, 167 00:09:30,880 --> 00:09:33,680 you should finish and you should, like, fully finish and 168 00:09:33,680 --> 00:09:36,480 only then you should take on your newer challenges. 169 00:09:37,280 --> 00:09:38,400 Yeah. So you said something 170 00:09:38,400 --> 00:09:40,680 interesting that not taking too many things right. 171 00:09:40,680 --> 00:09:43,920 I think in some organizations or most organizations that I 172 00:09:43,920 --> 00:09:46,800 experience is that the manager have too many things to do. 173 00:09:47,240 --> 00:09:49,920 So I think this is kind of like, I don't know, systemic habitual 174 00:09:49,920 --> 00:09:53,600 problems in the industry. So how do you actually, how can 175 00:09:53,600 --> 00:09:57,280 you advise managers to actually be able to focus more, a lot 176 00:09:57,280 --> 00:09:59,440 more on not taking too many things? 177 00:09:59,440 --> 00:10:02,800 Because sometimes it's from the top right or we have so many 178 00:10:02,800 --> 00:10:06,240 goals, we have so many KPI S to chase and they just leave it to 179 00:10:06,240 --> 00:10:09,400 the managers and middle managers to execute without knowing how 180 00:10:09,400 --> 00:10:11,800 much capacity that he or the team has. 181 00:10:12,400 --> 00:10:16,000 I think like a very obvious, very simple rule that you can 182 00:10:16,000 --> 00:10:20,160 apply just a power of three, you know, like pick the three most 183 00:10:20,160 --> 00:10:23,600 important things that you cannot drop and just like focus on 184 00:10:23,600 --> 00:10:26,160 them. If we think about the team, one 185 00:10:26,160 --> 00:10:29,280 thing that I like to do sometimes is just to limit work 186 00:10:29,280 --> 00:10:32,680 in progress. So how you can do that is you 187 00:10:32,680 --> 00:10:38,240 make a sort of like a guiding policy that every task that 188 00:10:38,240 --> 00:10:42,600 takes more than two weeks should be worked on by two engineers. 189 00:10:43,040 --> 00:10:47,280 So then if you have a team of six or a team of eight, the 190 00:10:47,280 --> 00:10:50,960 longer running projects that you can have at the same time is 191 00:10:50,960 --> 00:10:55,440 going to be like 3 or 4. So there you kind of limited the 192 00:10:55,440 --> 00:10:58,040 bandwidth. And a key thing there is that 193 00:10:58,200 --> 00:11:02,120 all your stakeholders outside understand why you're doing this 194 00:11:02,480 --> 00:11:05,680 and it makes sense to them and they accept that this is kind of 195 00:11:05,680 --> 00:11:08,320 the steady pace that the team is going to go with. 196 00:11:09,160 --> 00:11:12,200 Right, that thing is very precious tips because limiting 197 00:11:12,200 --> 00:11:14,880 work in progress is part of the Lean methodology as well. 198 00:11:15,240 --> 00:11:17,400 Is something that I think everyone can use, right? 199 00:11:17,480 --> 00:11:19,720 But first of all like you should make it visible right? 200 00:11:19,720 --> 00:11:21,520 What kind of things that you are working on, right? 201 00:11:21,800 --> 00:11:24,560 So I have an episode with Dominica de Grandis previously 202 00:11:24,560 --> 00:11:26,880 as well talking about making work visible. 203 00:11:27,120 --> 00:11:29,880 So I think that is also probably one of the good tips for 204 00:11:29,880 --> 00:11:31,800 managers, right? If you are swarmed with so many 205 00:11:31,800 --> 00:11:33,760 things right? First is identify what are the 206 00:11:33,760 --> 00:11:36,440 things you are working on and probably limiting the work in 207 00:11:36,440 --> 00:11:38,480 progress. Just like Balas mention, maybe 208 00:11:38,480 --> 00:11:41,320 put a limit like a big project assigned to engineers. 209 00:11:41,320 --> 00:11:43,280 Divide by the total number of engineers. 210 00:11:43,760 --> 00:11:46,600 That kind of like the limit of how many things can be tackled 211 00:11:46,600 --> 00:11:48,760 by your team. Sorry, just one thing that 212 00:11:48,760 --> 00:11:51,520 reminded me of is one thing that really helps me. 213 00:11:51,840 --> 00:11:55,560 I've only been doing this in the last three years is writing my 214 00:11:55,560 --> 00:11:59,800 own personal OK Rs and I published that and I send it out 215 00:12:00,040 --> 00:12:04,520 and I keep iterating on it. That's also a super important 216 00:12:04,520 --> 00:12:08,800 thing of aligning with your product counterpart or lead and 217 00:12:08,800 --> 00:12:12,040 be really transparent on like what are the things where you're 218 00:12:12,040 --> 00:12:16,520 spending your time and how are you going to decide for yourself 219 00:12:16,520 --> 00:12:17,880 if you've done a good job or not. 220 00:12:18,640 --> 00:12:20,960 Right. I think that's interesting tips 221 00:12:20,960 --> 00:12:23,640 as well, because some people just align with their manager, 222 00:12:23,640 --> 00:12:24,920 right? Their direct managers. 223 00:12:25,160 --> 00:12:27,640 But I think if you have something that you share among 224 00:12:27,640 --> 00:12:30,560 stakeholders, maybe someone can figure out if let's say you are 225 00:12:30,560 --> 00:12:33,240 doing something that is not aligning with their priorities. 226 00:12:33,800 --> 00:12:36,880 Yep, So you mentioned things like a good characteristics for 227 00:12:36,960 --> 00:12:39,440 EM, right? But have you identified maybe in 228 00:12:39,440 --> 00:12:42,720 your journey or from your people below right in engineering 229 00:12:42,720 --> 00:12:45,000 management? Are there engineering management 230 00:12:45,000 --> 00:12:46,720 bad traits that people should avoid? 231 00:12:46,720 --> 00:12:48,920 Like if this is like a clear no signal. 232 00:12:49,560 --> 00:12:53,800 I think if somebody, as you mentioned, doesn't like to deal 233 00:12:53,800 --> 00:12:57,600 with people, that's definitely, you know, like a sign of. 234 00:12:57,680 --> 00:13:00,560 You're going to have to deal with problems that you don't 235 00:13:00,560 --> 00:13:05,240 like in a lot of the cases, but I think if we like think about 236 00:13:05,320 --> 00:13:08,240 it as a framework of, you know, one is getting things done. 237 00:13:08,440 --> 00:13:10,440 The 2nd is can you do it sustainably. 238 00:13:10,920 --> 00:13:14,560 I think that if somebody doesn't get things done in an 239 00:13:14,800 --> 00:13:17,920 organization that works well, that's really easy to see, 240 00:13:17,960 --> 00:13:20,120 right? That you didn't hit the KPIs, it 241 00:13:20,120 --> 00:13:22,040 wasn't fast enough. You can go there and you can 242 00:13:22,040 --> 00:13:25,400 figure out what the problem is. You can help when it becomes 243 00:13:25,400 --> 00:13:30,200 tricky is if somebody gets results doesn't do it 244 00:13:30,280 --> 00:13:33,440 sustainably. So to me, getting things done is 245 00:13:33,520 --> 00:13:38,080 can you go from A to B? And sustainably means that is 246 00:13:38,080 --> 00:13:40,840 there going to be AC where you can go from like B to C? 247 00:13:41,360 --> 00:13:44,640 And that's a very tricky thing when there's a leader who gets 248 00:13:44,640 --> 00:13:47,280 results. But under the hood, you know, 249 00:13:47,280 --> 00:13:51,320 the technical solution is maybe suboptimal, maybe it's not going 250 00:13:51,320 --> 00:13:55,120 to scale, maybe the team is burning out or their kind of 251 00:13:55,120 --> 00:13:57,920 leader where they don't have a bench, they do everything in a 252 00:13:57,920 --> 00:13:59,240 team. These are the things that are 253 00:13:59,240 --> 00:14:02,320 much harder to identify and much harder to help with. 254 00:14:03,160 --> 00:14:04,840 Yeah. So I think the 2nd aspect that 255 00:14:04,840 --> 00:14:07,400 you mentioned after the getting things done right is doing it 256 00:14:07,400 --> 00:14:09,440 sustainably. And there are few aspects you 257 00:14:09,440 --> 00:14:11,960 mentioned like the tech solution, the system, right, the 258 00:14:11,960 --> 00:14:16,520 design of the solution and also the team health and the team 259 00:14:16,520 --> 00:14:17,920 bench, right, building the bench. 260 00:14:18,200 --> 00:14:20,800 So maybe if you can walk us through one by one, right, let's 261 00:14:20,800 --> 00:14:22,600 start with the tech and system, right. 262 00:14:22,840 --> 00:14:26,600 So you've been, I don't know, 6 1/2 years in wise now, right? 263 00:14:26,600 --> 00:14:30,280 So you have grown them from maybe like small team up to the 264 00:14:30,440 --> 00:14:33,640 expansion to the US now becomes the one of the growing biggest 265 00:14:33,640 --> 00:14:36,600 market for wise. So tell us, what does it mean to 266 00:14:36,600 --> 00:14:40,280 have a sustainable tech or sustainable system design? 267 00:14:41,080 --> 00:14:45,320 That's a really tricky question because as you know, the teams 268 00:14:45,320 --> 00:14:47,160 change, the tech keeps on changing. 269 00:14:47,200 --> 00:14:51,320 You know, maybe the best way is if I start with like what is the 270 00:14:51,800 --> 00:14:54,360 ecosystem that original teams live in otherwise? 271 00:14:54,840 --> 00:14:58,280 So with more startups, they try to be global. 272 00:14:58,640 --> 00:15:03,320 We have core systems and there is you know like a regional 273 00:15:03,360 --> 00:15:07,080 application of that system. There are teams who are building 274 00:15:07,080 --> 00:15:09,720 the core, like how should this feature work, like how do you 275 00:15:09,720 --> 00:15:13,720 hold money, how do you receive money and then how do you send 276 00:15:13,720 --> 00:15:16,120 money for example. And then there are teams who are 277 00:15:16,120 --> 00:15:19,040 building on this. So you can think of it as like 278 00:15:19,120 --> 00:15:21,880 there are teams who are building the operating system and there 279 00:15:21,880 --> 00:15:24,360 are teams who are building the applications for the 280 00:15:24,360 --> 00:15:28,160 applications at Wise. These are the integrations that 281 00:15:28,160 --> 00:15:29,960 connect Wise to the financial world. 282 00:15:30,360 --> 00:15:34,320 So this is hundreds of banking integration with banks and 283 00:15:34,320 --> 00:15:37,880 partners throughout the world and it was a really interesting 284 00:15:37,880 --> 00:15:41,520 journey that we went through. Wise was growing when I joined 285 00:15:41,720 --> 00:15:44,680 was growing by more than 100% year on year. 286 00:15:45,120 --> 00:15:48,600 Just to like for everyone to understand this growth, when I 287 00:15:48,600 --> 00:15:53,640 joined in 2017, we had 500 people working at WISE. 288 00:15:53,840 --> 00:15:58,320 Now we have 4500. So this was some crazy growth 289 00:15:58,320 --> 00:16:02,800 like operationally the markets that we launched and in every 290 00:16:02,800 --> 00:16:06,880 sense of the world. So one of the challenges was you 291 00:16:06,880 --> 00:16:09,920 build these core systems, there's going to a bunch of 292 00:16:09,920 --> 00:16:13,680 teams who are going to write code and add code to those 293 00:16:13,680 --> 00:16:17,640 systems and implement that system in the region, for 294 00:16:17,640 --> 00:16:22,080 example, you know, in the European Union or Singapore or 295 00:16:22,080 --> 00:16:25,480 the US And all of these things add a lot of complexity. 296 00:16:25,800 --> 00:16:29,000 And when you try to grow globally at the same time, you 297 00:16:29,000 --> 00:16:32,720 have a lot of conflicting things in the road map, right? 298 00:16:32,720 --> 00:16:35,920 Like should we do, you know, like the US first, Should we do 299 00:16:36,080 --> 00:16:38,480 Singapore first? What should we prioritize? 300 00:16:38,840 --> 00:16:42,480 And if you wait on a team, like on a central team, to build 301 00:16:42,480 --> 00:16:46,000 something for you, usually the problem is that that's too late. 302 00:16:46,080 --> 00:16:48,520 You know that's not something that you can live with. 303 00:16:48,960 --> 00:16:52,360 So what Wise does is we have this week code ownership. 304 00:16:52,600 --> 00:16:55,440 My lead doesn't like this term week code ownership because 305 00:16:55,680 --> 00:16:59,560 there is still a team that owns the code base, like it has to do 306 00:16:59,560 --> 00:17:02,400 the review. But you can go there, you can 307 00:17:02,640 --> 00:17:06,079 understand how to contribute and you can submit a pull request 308 00:17:06,079 --> 00:17:09,480 and they're going to review it. So that's how regional teams at 309 00:17:09,480 --> 00:17:13,760 Wise do majority of their work. They go to the central teams, 310 00:17:13,760 --> 00:17:17,560 they contribute to the system and the central team reviews it 311 00:17:17,839 --> 00:17:21,920 and then they release it. So that's one of the key things 312 00:17:21,920 --> 00:17:24,000 that drove the architecture at Wise. 313 00:17:24,280 --> 00:17:29,240 We went into a long journey of Wise started with a monolithic 314 00:17:29,240 --> 00:17:30,880 service. Everything was in one 315 00:17:30,880 --> 00:17:32,920 application. It was super fast. 316 00:17:32,920 --> 00:17:35,880 It was very easy from an infrastructure point of view. 317 00:17:36,200 --> 00:17:39,720 But then the service, as you can imagine, grows very big. 318 00:17:40,040 --> 00:17:44,840 Seven years ago, it took roughly 3 hours to build the monolith. 319 00:17:45,240 --> 00:17:49,480 Now imagine you're building it for three hours and in the last 320 00:17:49,480 --> 00:17:53,040 second there's a task that is failing and there are like maybe 321 00:17:53,040 --> 00:17:55,320 like 20 teams were waiting for that release. 322 00:17:55,320 --> 00:17:57,640 You know, they all nurse their code in like something broke, 323 00:17:57,640 --> 00:18:01,080 something has to be rolled back. So it became very, very hard to 324 00:18:01,080 --> 00:18:04,520 go with the same pace. So then we moved into this micro 325 00:18:04,520 --> 00:18:07,960 service architecture when we started to carve out the most 326 00:18:07,960 --> 00:18:10,120 important domains out of this monolith. 327 00:18:10,600 --> 00:18:13,240 And then we created a system that communicates with, you 328 00:18:13,240 --> 00:18:16,320 know, like messaging and the system that can scale. 329 00:18:16,680 --> 00:18:20,680 But then as you can imagine, the same thing started to happen. 330 00:18:21,000 --> 00:18:25,040 So with regional teams, we had these systems which are capable 331 00:18:25,040 --> 00:18:30,160 of processing statements or executing payouts or converting 332 00:18:30,280 --> 00:18:31,960 money from like one account to the other. 333 00:18:32,280 --> 00:18:36,000 And since we have hundreds of integrations and we are 334 00:18:36,000 --> 00:18:39,320 frequently adding them, these services also became big. 335 00:18:39,640 --> 00:18:43,320 Not as big as the monolith, but it went up to like 20 minutes to 336 00:18:43,360 --> 00:18:46,560 build the service. I still remember when somebody 337 00:18:46,640 --> 00:18:49,920 made a change at the other part of the world, they added a 338 00:18:49,920 --> 00:18:55,040 library to the dependencies and that library was a version that 339 00:18:55,040 --> 00:18:58,680 wasn't compatible with an integration that we used, right? 340 00:18:58,760 --> 00:19:01,440 But since it was the same service, it just broke our 341 00:19:01,440 --> 00:19:05,240 integration and production. So because of these things we 342 00:19:05,280 --> 00:19:09,120 reiterated on these macro services and then came to a 343 00:19:09,120 --> 00:19:13,840 solution which is going to be a partner based, you know like 344 00:19:13,840 --> 00:19:19,520 small micro service that just does one job and that's kind of 345 00:19:19,520 --> 00:19:22,960 like an overview of what regional teams went through in 346 00:19:22,960 --> 00:19:26,560 the last six years. Wow, there are so many things 347 00:19:26,560 --> 00:19:29,840 that maybe if we can just go a few of them, right? 348 00:19:29,840 --> 00:19:32,720 So the first one is what you mentioned, weak code ownership. 349 00:19:33,240 --> 00:19:36,520 So from my understanding this is similar to probably in the open 350 00:19:36,520 --> 00:19:39,760 source world, right, where you have a few core committers, 351 00:19:39,920 --> 00:19:41,680 think of it like the core teams, right? 352 00:19:42,040 --> 00:19:45,080 And you have the regional teams, people who volunteer and you 353 00:19:45,080 --> 00:19:46,480 know contribute to the open source. 354 00:19:46,480 --> 00:19:47,960 Is that the same? That's the first thing. 355 00:19:48,280 --> 00:19:51,320 And the second thing, how do you ensure that the people from the 356 00:19:51,320 --> 00:19:54,160 outside of the core team actually understand the domains, 357 00:19:54,360 --> 00:19:57,280 the kind of impact that they are making to the core system 358 00:19:57,280 --> 00:20:00,360 because they might not know what is the rationale behind the code 359 00:20:00,360 --> 00:20:03,600 base or will it impact? The code for other regions. 360 00:20:04,240 --> 00:20:08,040 Yeah, those are great questions. I think it's very similar to 361 00:20:08,040 --> 00:20:10,200 that. Yes, so there is a core team who 362 00:20:10,600 --> 00:20:15,560 really owns the service, has the right to release the service and 363 00:20:15,880 --> 00:20:18,480 the expectations vary among services. 364 00:20:18,760 --> 00:20:22,640 But usually there is a read me file that explains everything 365 00:20:22,640 --> 00:20:25,360 you have to do with the service, like how you should contribute 366 00:20:25,880 --> 00:20:29,920 and advise. I think we have reasonably clean 367 00:20:29,920 --> 00:20:31,880 services like a clean architecture. 368 00:20:32,120 --> 00:20:35,320 The architecture differed from service to service, but there 369 00:20:35,320 --> 00:20:39,320 are like really good foundations that if you understand like one 370 00:20:39,320 --> 00:20:42,360 service in the whole domain, you understand most of them. 371 00:20:42,760 --> 00:20:47,600 So that's very important. Another important thing is as an 372 00:20:47,600 --> 00:20:52,120 organization, even though we have 500 microservices, most of 373 00:20:52,120 --> 00:20:55,280 them are Java. Everything runs on the JVM. 374 00:20:55,280 --> 00:20:59,200 There may be a couple of services which are Kotlin, but 375 00:20:59,200 --> 00:21:03,120 it was a huge thing for Wise that most of our engineers can 376 00:21:03,120 --> 00:21:05,120 contribute to most of the services. 377 00:21:05,560 --> 00:21:08,200 And Java is a very simple language also compared to 378 00:21:08,200 --> 00:21:12,000 something like Scala. So I think these things really 379 00:21:12,000 --> 00:21:14,800 worked well for us. In terms of do you understand 380 00:21:14,800 --> 00:21:19,960 the domain that's a great point. What I advise to my teammates is 381 00:21:19,960 --> 00:21:24,280 just to make friends with the core teams and also to go to 382 00:21:24,280 --> 00:21:28,600 their plannings, understand where the whole team and that 383 00:21:28,600 --> 00:21:30,800 vision is going. Because central teams are the 384 00:21:30,800 --> 00:21:35,080 ones who are usually shaping the technical vision and do that 385 00:21:35,080 --> 00:21:39,960 extra work of you know, like don't just look at can this be 386 00:21:40,000 --> 00:21:43,800 released tomorrow, but try to think with their head where is 387 00:21:43,800 --> 00:21:47,760 the architecture going. So one thing that we do is we 388 00:21:47,760 --> 00:21:51,680 don't just show up with a pull request that is 1000 lines long. 389 00:21:51,960 --> 00:21:56,960 What we do is before we try to talk to them and explain what is 390 00:21:56,960 --> 00:21:59,880 the problem that we are trying to solve and really just seek 391 00:21:59,880 --> 00:22:02,680 that advice of how would you go about this? 392 00:22:02,920 --> 00:22:05,200 Is this a code that you're not going to build on? 393 00:22:05,200 --> 00:22:07,360 Is this something that is going to be deprecated? 394 00:22:07,520 --> 00:22:11,240 Can we really do it this way? And usually the central teams 395 00:22:11,240 --> 00:22:14,000 really welcome that. What they don't like is if you 396 00:22:14,000 --> 00:22:18,200 show up with 1000 lines of code and then you say like, hey, I'd 397 00:22:18,240 --> 00:22:21,120 really like this to be released tomorrow and that's something 398 00:22:21,120 --> 00:22:23,440 that doesn't work usually. Right. 399 00:22:23,480 --> 00:22:26,760 Not to mention the kind of risk that if you just merge 1000 400 00:22:26,760 --> 00:22:29,120 lines of code, right, what impact it will introduce. 401 00:22:29,600 --> 00:22:32,240 So maybe elaborate a little bit more on the core team, right? 402 00:22:32,280 --> 00:22:35,440 Are there a lot of people as part of this core committers 403 00:22:35,440 --> 00:22:37,080 that is like the gatekeeper, right? 404 00:22:37,080 --> 00:22:40,520 Of all the PRS that are raised from regional team, how do they 405 00:22:40,520 --> 00:22:42,600 operate? Is there like specific 406 00:22:42,600 --> 00:22:46,240 committers who understands specific domains really well or 407 00:22:46,240 --> 00:22:49,040 are they interchangeable? So maybe if for people who want 408 00:22:49,040 --> 00:22:51,200 to operate this way, they can get some hint as well. 409 00:22:52,080 --> 00:22:55,880 So how they typically work is that they advise Domain Driven 410 00:22:55,880 --> 00:22:59,360 Design is a very popular methodology. 411 00:22:59,720 --> 00:23:03,240 We think of everything as a customer problem. 412 00:23:03,560 --> 00:23:06,920 So if you go into our organization and you look at 413 00:23:06,960 --> 00:23:10,400 just the name of the teams, it's going to be very clear to you 414 00:23:10,400 --> 00:23:13,520 like what are the customer problems that they are solving. 415 00:23:14,080 --> 00:23:18,680 And these teams divide the ownership of that domain between 416 00:23:18,680 --> 00:23:20,960 themselves on a technical level as well. 417 00:23:21,360 --> 00:23:26,320 So for example, if you have a team that deals with like 418 00:23:26,320 --> 00:23:30,240 liquidity or you know treasury, they're going to own those 419 00:23:30,240 --> 00:23:34,120 services which are going to track how much money we have on 420 00:23:34,120 --> 00:23:37,760 our bank accounts, how do we move money from one account to 421 00:23:37,760 --> 00:23:39,760 the other and so on and so forth. 422 00:23:40,040 --> 00:23:44,800 So every single person in that team will have you know like 423 00:23:44,800 --> 00:23:49,160 committer rights and reviewer rights and release rights and 424 00:23:49,160 --> 00:23:52,320 wise, it's not just the leads who can deploy the service, it's 425 00:23:52,320 --> 00:23:53,840 typically everyone in the service. 426 00:23:53,840 --> 00:23:56,120 We try to be really, really flat. 427 00:23:56,280 --> 00:23:59,520 The levels the different engineers have don't make a 428 00:23:59,520 --> 00:24:02,720 difference in terms of what they can do with the code and in 429 00:24:02,720 --> 00:24:06,240 terms of impact. I was in an organization before 430 00:24:06,240 --> 00:24:08,120 where we have almost similar problem. 431 00:24:08,120 --> 00:24:11,680 We have the main country right and you have regional teams as 432 00:24:11,680 --> 00:24:13,400 well. I think their approach back then 433 00:24:13,400 --> 00:24:14,800 was to create a centralized team. 434 00:24:15,240 --> 00:24:17,760 So yeah, I realized over the time that didn't work because 435 00:24:17,760 --> 00:24:19,640 first, it's the prioritization problem, right? 436 00:24:19,640 --> 00:24:23,200 Every country will shout and hey, we have a priority, but 437 00:24:23,200 --> 00:24:25,840 there's only a limited number of people who can serve the 438 00:24:25,840 --> 00:24:29,560 request, right? And if your country is deemed to 439 00:24:29,600 --> 00:24:32,800 generate lower revenue probably right, they'll they prioritize 440 00:24:32,800 --> 00:24:34,840 you. So for companies that maybe are 441 00:24:34,840 --> 00:24:37,960 in this model at the moment, right, How can they maybe 442 00:24:37,960 --> 00:24:41,440 transition into the weak code ownership like you mentioned. 443 00:24:41,440 --> 00:24:44,360 Is there maybe some kind of journey that you went through 444 00:24:44,480 --> 00:24:47,720 that kick start all this? I think it was. 445 00:24:47,720 --> 00:24:51,600 It was always like this. It was always very problematic. 446 00:24:52,000 --> 00:24:57,320 How can we get from A to B in you know, the fastest way And 447 00:24:57,320 --> 00:25:02,280 this concept of enabling people and you know like getting out 448 00:25:02,280 --> 00:25:05,160 the way if somebody wants to get something done that is going to 449 00:25:05,160 --> 00:25:08,320 be good for the customers is just ingrained. 450 00:25:08,520 --> 00:25:13,760 I think trust and you know, no drama, good karma as we have it 451 00:25:13,800 --> 00:25:16,160 in one of our values is really important. 452 00:25:16,400 --> 00:25:22,320 One thing that is is also key is to understand if you have this 453 00:25:22,320 --> 00:25:25,640 problem at all or if you if you really need to do something 454 00:25:25,640 --> 00:25:28,280 about it. One thing that we look at really 455 00:25:28,280 --> 00:25:32,000 frequently is how much is the lead time when we release 456 00:25:32,000 --> 00:25:35,040 something. One thing that I noticed four 457 00:25:35,040 --> 00:25:39,600 years ago was that when my teams were contributing to certain 458 00:25:39,600 --> 00:25:44,080 domains, the merge time was a week because multiple reasons, 459 00:25:44,080 --> 00:25:45,320 right? Like then you go into the 460 00:25:45,320 --> 00:25:46,840 reasons like, hey, what's going on? 461 00:25:47,320 --> 00:25:51,200 Sometimes the core team was just three people and three people 462 00:25:51,200 --> 00:25:56,800 were owning a service and there was an organization at the time 463 00:25:56,800 --> 00:26:00,720 which was like 60 people and 60 people were writing applications 464 00:26:00,720 --> 00:26:04,280 and sending 2 requests to them. So that was just the time that 465 00:26:04,280 --> 00:26:05,880 it took for them to get to everyone. 466 00:26:06,240 --> 00:26:12,880 And that pain point led to this vision that in some cases we 467 00:26:12,880 --> 00:26:18,080 have to own our own services. So when I looked at, OK, we've 468 00:26:18,080 --> 00:26:21,360 modularized this domain and we own our own service. 469 00:26:21,360 --> 00:26:24,840 We have the right to release and merge and deploy and everything. 470 00:26:25,160 --> 00:26:29,320 It took us two hours on average to do a review and merge it in. 471 00:26:29,680 --> 00:26:31,880 That's a huge advantage to a week, right? 472 00:26:32,440 --> 00:26:35,840 It's more than 10X. So these are the things that 473 00:26:36,120 --> 00:26:39,400 kind of drove us to go into One Direction to the other. 474 00:26:39,400 --> 00:26:42,120 We always, you know, start with the data and what is the problem 475 00:26:42,160 --> 00:26:45,680 that we're trying to solve. Yeah, I think lead time or the 476 00:26:45,680 --> 00:26:47,560 flow of the value, right, is key. 477 00:26:47,560 --> 00:26:51,320 So make sure maybe people to measure your lead time and take 478 00:26:51,320 --> 00:26:52,920 action, right. If you find the lead time is 479 00:26:52,920 --> 00:26:57,000 slow, then maybe you can try some of the tips that Balas just 480 00:26:57,000 --> 00:26:58,920 mentioned. The other thing that I picked 481 00:26:58,920 --> 00:27:02,840 interest is the journey from your monolith to micro service 482 00:27:02,840 --> 00:27:05,440 and you know now becomes like even more granular, right. 483 00:27:05,720 --> 00:27:09,240 Some people find it challenging to move to like hundreds of 484 00:27:09,240 --> 00:27:11,960 micro services, but in the end you kind of like settle on this 485 00:27:11,960 --> 00:27:15,480 per integration microservice. Why do you think this is the 486 00:27:15,480 --> 00:27:18,360 most optimal design for your problem? 487 00:27:19,160 --> 00:27:21,360 Let's start with the problem. Like what was the issue? 488 00:27:21,560 --> 00:27:24,840 We've built hundreds of these integrations. 489 00:27:25,080 --> 00:27:28,000 When you do this, you have to connect to an external system 490 00:27:28,280 --> 00:27:30,800 that you have to do authentication, authorization. 491 00:27:31,160 --> 00:27:35,360 There is a lot of boilerplate code that can be standardized. 492 00:27:35,720 --> 00:27:38,800 And then you also have to integrate with Wise. 493 00:27:39,240 --> 00:27:42,680 You have to integrate with the internal APIs that we have, and 494 00:27:42,880 --> 00:27:48,000 when we built an integration, it usually took us six weeks to do 495 00:27:48,000 --> 00:27:49,760 one from a technical perspective. 496 00:27:50,320 --> 00:27:55,240 But a lot of it was repetitive work and we had some differences 497 00:27:55,240 --> 00:27:57,760 between, you know, how different teams did it. 498 00:27:58,160 --> 00:28:01,760 When I and my team was working on this big integration, we were 499 00:28:01,760 --> 00:28:04,920 connecting wise to the Hungarian payment scheme directly to the 500 00:28:04,920 --> 00:28:10,040 central bank directly COVID hit. So we knew that that meant to 501 00:28:10,040 --> 00:28:14,080 delay and then we were really thinking about, OK, now there is 502 00:28:14,080 --> 00:28:16,200 this delay, we still have to work on this. 503 00:28:16,600 --> 00:28:20,760 How can we build this integration in a way where it's 504 00:28:20,760 --> 00:28:24,440 going to radically reduce time to market for the next one, 505 00:28:24,560 --> 00:28:27,560 Because we know this is not the last central integration that 506 00:28:27,560 --> 00:28:29,640 we're going to do. We knew that you know like 507 00:28:29,640 --> 00:28:32,040 Singapore was only you know like a couple months ago. 508 00:28:32,040 --> 00:28:34,040 So it made sense to like really invest. 509 00:28:34,400 --> 00:28:38,240 We also wanted to reduce the blast radius, and we also wanted 510 00:28:38,320 --> 00:28:43,160 to have this ability to frequently release if we have to 511 00:28:43,160 --> 00:28:47,680 make a change. So what we came up with was a 512 00:28:47,680 --> 00:28:51,760 library that you can just pull into your service, and this 513 00:28:51,760 --> 00:28:57,040 library will abstract away the core behavior of an integration. 514 00:28:57,120 --> 00:28:59,800 It's going to have a database. It's going to create a database 515 00:28:59,800 --> 00:29:01,640 for you. If you have a state machine 516 00:29:01,640 --> 00:29:05,400 inside, that's going to track the different statuses of the 517 00:29:05,400 --> 00:29:08,160 payments that you have, which have different names in 518 00:29:08,160 --> 00:29:10,720 different countries or different integrations. 519 00:29:11,040 --> 00:29:14,520 But you can kind of come to a standardized way of storing 520 00:29:14,520 --> 00:29:17,160 them. And once you have this, it also 521 00:29:17,160 --> 00:29:21,200 knows how to talk to wise, how to talk to the interfaces that 522 00:29:21,200 --> 00:29:24,360 govern wise, how to execute the payout, how to report how much 523 00:29:24,360 --> 00:29:26,280 money has moved out, all these different things. 524 00:29:26,640 --> 00:29:31,320 So all you have to do is really to plug in the API codes that 525 00:29:31,320 --> 00:29:35,480 connect us to the partner. One other thing that was key is 526 00:29:35,480 --> 00:29:39,600 that this library also came with a back office UI which made it 527 00:29:39,600 --> 00:29:43,600 really easy for not just engineers but operations to find 528 00:29:43,600 --> 00:29:46,600 issues to look under the hood. Like what happened with this 529 00:29:46,600 --> 00:29:48,080 payment? What was the error code? 530 00:29:48,280 --> 00:29:51,080 How can I resolve this? We were able to do this in a 531 00:29:51,080 --> 00:29:56,560 generic way and once we built this for Hungary, then our Asia 532 00:29:56,560 --> 00:30:00,560 team did it for Singapore. And we've replicated this 533 00:30:00,560 --> 00:30:03,920 solution now I think over 20 integrations. 534 00:30:04,200 --> 00:30:08,880 And it's not an exact measurement, but roughly we save 535 00:30:09,000 --> 00:30:11,640 four weeks on one integration that we build. 536 00:30:12,320 --> 00:30:15,360 Very interesting approach like you build a library like an SDK 537 00:30:15,360 --> 00:30:19,200 kind of thing where you kind of like abstract way or this core 538 00:30:19,240 --> 00:30:22,320 maybe core models right, the state machine you mentioned and 539 00:30:22,320 --> 00:30:25,600 maybe even some parts of the back office UI for maybe 540 00:30:25,600 --> 00:30:27,680 operations team to support the service. 541 00:30:28,160 --> 00:30:31,240 Some people may move away from this kind of model, but because 542 00:30:31,240 --> 00:30:33,240 of the for example the change coupling, right? 543 00:30:33,240 --> 00:30:36,240 So imagine you have hundreds of integrations, you change the 544 00:30:36,240 --> 00:30:38,080 core library and you distribute to all. 545 00:30:38,320 --> 00:30:42,320 How do you ensure that things will still work among all the 546 00:30:42,320 --> 00:30:44,440 integrations? Because each partner can also 547 00:30:44,440 --> 00:30:46,680 evolve, right? They have new release, they have 548 00:30:46,680 --> 00:30:50,240 new data model, new attributes being introduced or new way of 549 00:30:50,360 --> 00:30:52,920 authenticating, right? So how do you make sure all this 550 00:30:52,920 --> 00:30:54,480 doesn't introduce like a dependency? 551 00:30:54,480 --> 00:30:58,720 Like a tight dependency between the core library and also each 552 00:30:58,920 --> 00:31:03,600 integration service. We try to be very cautious in 553 00:31:03,600 --> 00:31:08,320 changing this library and adding like new requirements. 554 00:31:08,600 --> 00:31:12,080 And once we add something, we try to make sure that it's not 555 00:31:12,080 --> 00:31:16,000 going to be a breaking change but more like an extension. 556 00:31:16,000 --> 00:31:18,800 You know, like close for modification, open for 557 00:31:18,800 --> 00:31:21,480 extension. But yes, you're right, the 558 00:31:21,480 --> 00:31:24,280 problem is there. But the only changes we had to 559 00:31:24,280 --> 00:31:28,040 do so far were kind of these extensions that weren't breaking 560 00:31:28,040 --> 00:31:30,040 changes for the rest of the integrations. 561 00:31:30,520 --> 00:31:34,040 And there is really strong ownership around this piece of 562 00:31:34,040 --> 00:31:36,880 code and really strong code reviews are done. 563 00:31:37,280 --> 00:31:40,960 So this is how we are trying to make sure that this dependency 564 00:31:40,960 --> 00:31:44,920 is not going to backfire right? And I think one of the key 565 00:31:44,920 --> 00:31:47,680 probably is also like you have kind of like nailed down the 566 00:31:47,920 --> 00:31:51,080 circle design or the domain part of the core library right? 567 00:31:51,080 --> 00:31:53,880 So it stays stable rather than keeps changing right? 568 00:31:53,880 --> 00:31:56,640 Because if you keep changing then others also will get 569 00:31:56,640 --> 00:31:57,960 affected. Yeah. 570 00:31:57,960 --> 00:32:01,560 So when we designed it, we've already built Plenty Plus 571 00:32:01,560 --> 00:32:05,240 integrations in Europe. So we kind of knew what the 572 00:32:05,280 --> 00:32:09,640 standard is and what we see with these integrations is that banks 573 00:32:09,640 --> 00:32:14,040 and partners are also moving to a standardized way of doing 574 00:32:14,040 --> 00:32:16,840 things. And if yes, if you get the 575 00:32:16,840 --> 00:32:20,280 abstraction level right, then you know like changes with the 576 00:32:20,280 --> 00:32:22,760 different integrations are much much easier to live with. 577 00:32:23,640 --> 00:32:26,520 Let's move on to the second aspect of your sustainability 578 00:32:26,520 --> 00:32:29,640 right, which is about the sustainability of the team. 579 00:32:29,680 --> 00:32:32,560 Because not just the aspect of technical part, right, you also 580 00:32:32,560 --> 00:32:35,760 need to have a sustainable team. So tell us how we can build a 581 00:32:35,760 --> 00:32:39,200 more healthier teams because many teams that I found in the 582 00:32:39,280 --> 00:32:41,840 tech industry especially in startup scale up is you know 583 00:32:41,840 --> 00:32:44,120 they are burnout. They have so many things to do. 584 00:32:44,120 --> 00:32:46,200 You know, the cultural change and things like that. 585 00:32:46,840 --> 00:32:50,480 I think to me there are many things obviously that you can do 586 00:32:50,520 --> 00:32:52,360 like happy hours and things like that. 587 00:32:52,640 --> 00:32:57,840 But maybe the two most important aspects to me is one that the 588 00:32:57,840 --> 00:33:03,560 team is learning and the other is clarity and the pace that you 589 00:33:03,560 --> 00:33:06,800 go with. So what I mean by the team is 590 00:33:06,800 --> 00:33:10,320 learning and growing. I don't mean it as like growing 591 00:33:10,320 --> 00:33:12,600 in terms of head count. That's not the only kind of 592 00:33:12,600 --> 00:33:16,920 growth that you can have. But one thing that was really a 593 00:33:16,920 --> 00:33:19,840 challenge with the regional teams that I've worked with is 594 00:33:19,840 --> 00:33:22,440 that your job is to find product market fit. 595 00:33:22,840 --> 00:33:27,520 And when you start with, you hire almost extensively back end 596 00:33:27,520 --> 00:33:30,640 engineers because what you have to build is these integrations 597 00:33:30,760 --> 00:33:34,440 with the partners. And then what you do is you 598 00:33:34,840 --> 00:33:38,920 implement all the features in your own market that Wise has 599 00:33:38,920 --> 00:33:40,440 built, that the core team has built, right. 600 00:33:40,480 --> 00:33:43,280 I can give you a couple of examples, be able to hold money 601 00:33:43,360 --> 00:33:46,880 in a currency and be able to give people bank details, so 602 00:33:46,880 --> 00:33:49,160 they can share the bank details and receive money to that. 603 00:33:49,440 --> 00:33:53,640 You give people interest, you give them a debit card so they 604 00:33:53,640 --> 00:33:57,720 can spend the money, right. So when you've done all of that 605 00:33:57,880 --> 00:33:59,640 and you build all the integrations that you have to 606 00:33:59,640 --> 00:34:03,120 build, you kind of run out of back end problems. 607 00:34:03,480 --> 00:34:08,520 So you have to be able to iterate on these products and 608 00:34:08,520 --> 00:34:10,239 that requires a different skill set. 609 00:34:10,480 --> 00:34:14,600 So one thing I look at as like a flag, if a team has to reach 610 00:34:14,600 --> 00:34:18,280 product, market fit but still has the same skill set, then my 611 00:34:18,280 --> 00:34:21,760 gut says that they are still iterating on the same problem, 612 00:34:21,840 --> 00:34:23,159 right? They're not finding the new 613 00:34:23,159 --> 00:34:25,639 problems or they haven't solved the ones that they started with. 614 00:34:26,199 --> 00:34:30,480 And what was helpful for us is that first we had One North 615 00:34:30,480 --> 00:34:36,280 America team and then we created teams with strong domain 616 00:34:36,360 --> 00:34:38,760 knowledge. So if you look at our North 617 00:34:38,760 --> 00:34:42,159 America teams, we have an onboarding team, we have a send 618 00:34:42,159 --> 00:34:44,159 team, We have a wise account team. 619 00:34:44,320 --> 00:34:47,199 We have a team that looks after pay insurance and this kind of 620 00:34:47,199 --> 00:34:51,159 mimics the same way the core teams organize themselves, 621 00:34:51,199 --> 00:34:52,719 right. So we have like a brother and 622 00:34:52,719 --> 00:34:55,560 sister team in the core teams everywhere. 623 00:34:55,920 --> 00:35:00,080 And this is how we ensure that we're not just hacking things 624 00:35:00,080 --> 00:35:03,320 in, but there is a deep understanding of the domain and 625 00:35:03,320 --> 00:35:05,920 the technical architecture that we're working on. 626 00:35:06,040 --> 00:35:09,760 So that's really key that you can become an expert in a domain 627 00:35:09,760 --> 00:35:11,960 even in a regional team over time. 628 00:35:11,960 --> 00:35:14,600 And there is an evolution of skill sets as well. 629 00:35:14,760 --> 00:35:17,960 So one thing that we started this year was that we noticed 630 00:35:17,960 --> 00:35:21,200 that a lot of the time we have to touch mobile, right? 631 00:35:21,480 --> 00:35:23,760 There's just no way around it. And we didn't have mobile 632 00:35:23,760 --> 00:35:26,800 engineers. So what we did, we hired an 633 00:35:26,800 --> 00:35:30,120 Android engineer and now we've hired an iOS engineer as well. 634 00:35:30,520 --> 00:35:35,520 So this way our teams also feel like they can do something about 635 00:35:35,520 --> 00:35:38,120 the mobile problem. It's not that they have to ask 636 00:35:38,120 --> 00:35:41,640 another team, but they have ownership of that and the mobile 637 00:35:41,640 --> 00:35:44,640 customers are just as important as the customers who are using 638 00:35:44,640 --> 00:35:48,400 US on the web. And so culturally and momentum 639 00:35:48,400 --> 00:35:52,080 wise, it's really important that the domain knowledge keeps 640 00:35:52,080 --> 00:35:55,400 evolving and also the skill set in the team is not the same as a 641 00:35:55,400 --> 00:35:57,440 couple of years back. Right. 642 00:35:57,680 --> 00:36:00,960 Another thing as part of the sustainable team pace, right, is 643 00:36:00,960 --> 00:36:04,120 something that deals with the tech debt, right? 644 00:36:04,160 --> 00:36:06,760 I think in most engineering teams they will have tech debt, 645 00:36:06,760 --> 00:36:08,720 right? Is there a way that you do 646 00:36:08,720 --> 00:36:12,000 systematically at Wise in order to deal with the tech debt such 647 00:36:12,000 --> 00:36:14,440 that it doesn't impact the sustainability of the team 648 00:36:14,440 --> 00:36:17,960 space? Yes, there is different ways of 649 00:36:17,960 --> 00:36:20,720 dealing with this. Most of my teams, the leads are 650 00:36:20,720 --> 00:36:23,640 doing maintenance weeks or maintenance sprints. 651 00:36:24,000 --> 00:36:28,680 So they carve out a week or two either at the beginning of the 652 00:36:28,680 --> 00:36:31,280 quarter or the end of the quarter, preferably the 653 00:36:31,280 --> 00:36:34,120 beginning of the quarter because then you make sure that you're 654 00:36:34,120 --> 00:36:37,960 going to do it. And then on that week they clean 655 00:36:37,960 --> 00:36:41,560 out the most important things that they want to solve. 656 00:36:41,640 --> 00:36:44,280 That's when they upgrade the services, upgrade the 657 00:36:44,280 --> 00:36:48,560 dependencies and this is a way of making sure that teen remain 658 00:36:48,560 --> 00:36:51,040 healthy. What I also think is important 659 00:36:51,240 --> 00:36:54,040 is that what is that the Boy Scout principle. 660 00:36:54,280 --> 00:36:58,240 Like when you go somewhere and you change something, you leave 661 00:36:58,240 --> 00:36:59,680 things better than you found them. 662 00:37:00,000 --> 00:37:02,960 So that's something that I also try to do when I code. 663 00:37:03,120 --> 00:37:06,760 If I want to like fix something and I see that this code is 664 00:37:06,760 --> 00:37:11,800 outdated or deprecated, I take the time to remove that or 665 00:37:11,800 --> 00:37:15,080 refactor it and not just, you know, like add another line to 666 00:37:15,080 --> 00:37:17,200 add this feature. So that culture is really 667 00:37:17,200 --> 00:37:20,520 helpful and these small things add up at the end of the day. 668 00:37:21,360 --> 00:37:23,000 Right. So I think that's very 669 00:37:23,000 --> 00:37:25,200 interesting, right. Maintenance, we do it in the 670 00:37:25,200 --> 00:37:27,560 beginning of the quarter. It depends on your, you know, 671 00:37:27,560 --> 00:37:30,080 road map planning, but that probably helps to get things 672 00:37:30,080 --> 00:37:33,560 done because if you put it at the back, most likely you, you 673 00:37:33,680 --> 00:37:36,600 will have the product road map that kind of like delays or 674 00:37:36,600 --> 00:37:38,200 maybe extend a little bit, right? 675 00:37:38,640 --> 00:37:40,200 And you will not get to do all this. 676 00:37:40,200 --> 00:37:41,440 Technet. Yeah. 677 00:37:41,440 --> 00:37:43,400 So I think dealing with Technet is one thing, right? 678 00:37:43,400 --> 00:37:46,800 So you ensure that the team's pace is still sustainable and 679 00:37:46,800 --> 00:37:49,640 stable, right? But also another important part 680 00:37:49,640 --> 00:37:51,600 is to have the steady pace, right? 681 00:37:51,600 --> 00:37:55,120 It's not like up and down, up and down where people get in a 682 00:37:55,120 --> 00:37:57,160 burst of pace but then slows down, right? 683 00:37:57,440 --> 00:38:00,440 So how do you find a steady pace for your team as well? 684 00:38:00,480 --> 00:38:03,040 Is there any tips and tricks that you do differently? 685 00:38:03,840 --> 00:38:05,560 It's a really interesting question. 686 00:38:05,560 --> 00:38:10,560 I think a team has to be able to go fast if they have to. 687 00:38:10,560 --> 00:38:15,720 I think that's also really good to do as a test sometimes, but 688 00:38:15,720 --> 00:38:19,360 you should always choose to go with a steady pace most of the 689 00:38:19,360 --> 00:38:22,280 time. So I I have a story about this, 690 00:38:22,600 --> 00:38:27,440 I was talking to one of my Co workers and we did a change that 691 00:38:27,440 --> 00:38:29,320 really needed to be done urgently. 692 00:38:29,520 --> 00:38:34,040 We just went into a room, you know 9:00 AM, talked about the 693 00:38:34,040 --> 00:38:37,200 solution. We had a decision in two hours 694 00:38:37,520 --> 00:38:39,920 during that day. We iterated on that problem like 695 00:38:39,920 --> 00:38:42,560 two more times, and in two days we released it. 696 00:38:42,960 --> 00:38:45,240 We were on the team going out and I was telling him, like, 697 00:38:45,640 --> 00:38:48,280 look, this was awesome. Like the fact that we can make a 698 00:38:48,280 --> 00:38:51,040 decision in two hours and then we can iterate on it and then we 699 00:38:51,040 --> 00:38:54,520 can release it. And if it's going to work with a 700 00:38:54,520 --> 00:38:56,440 change like this, this is really, really cool. 701 00:38:56,440 --> 00:38:59,400 And then he looked at me and said, like, yeah, it's cool, but 702 00:38:59,400 --> 00:39:01,080 we shouldn't do this. And he's right. 703 00:39:01,240 --> 00:39:04,960 Because if everything is important, then nothing is 704 00:39:04,960 --> 00:39:07,040 important. Even if everything is urgent, 705 00:39:07,440 --> 00:39:08,920 you know, like the nothing is urgent. 706 00:39:08,920 --> 00:39:11,720 So you always have to find the right balance between these 707 00:39:11,720 --> 00:39:13,760 things. I think the value in this is 708 00:39:13,760 --> 00:39:18,600 that you see if your team is strong from time to time and if 709 00:39:18,600 --> 00:39:20,440 the systems that you have are strong. 710 00:39:20,720 --> 00:39:23,560 Because like when you have this things that are going to happen 711 00:39:23,560 --> 00:39:26,640 from time to time that you have to do something, be really fast. 712 00:39:27,000 --> 00:39:30,920 And then you're going to find out if you know your systems are 713 00:39:30,920 --> 00:39:33,800 not scaling or if there's a design problem that you cannot 714 00:39:33,960 --> 00:39:36,280 really solve. So from that perspective it's 715 00:39:36,280 --> 00:39:38,680 really good. But on the long run, what we 716 00:39:38,680 --> 00:39:42,400 really emphasizes for each team to find their own space and 717 00:39:42,400 --> 00:39:46,800 pace, do things in the regular way, do things on the ceremonies 718 00:39:46,800 --> 00:39:50,200 that they have respect that and trying to find that right 719 00:39:50,200 --> 00:39:52,680 balance. And I'm sure limiting work in 720 00:39:52,680 --> 00:39:54,880 progress that you mentioned in the beginning is also part of 721 00:39:54,880 --> 00:39:57,480 the trick, right, to ensure that you have a steady pace. 722 00:39:57,480 --> 00:39:59,880 It's not like a burst of pace up and down. 723 00:40:00,320 --> 00:40:03,000 So let's go to the next aspect of sustainability that you 724 00:40:03,000 --> 00:40:05,240 mentioned, right, which is about building a bench. 725 00:40:05,680 --> 00:40:08,120 So maybe you can elaborate a little bit more about bench 726 00:40:08,120 --> 00:40:09,960 here. Is it more like a capacity 727 00:40:09,960 --> 00:40:12,600 planning or is it like a substitute for managers and 728 00:40:12,600 --> 00:40:14,480 leaders? So tell us, what do you mean by 729 00:40:14,480 --> 00:40:17,280 bench? So what I mean by bench is that 730 00:40:17,280 --> 00:40:20,680 most of us want to go on vacation sometime, right? 731 00:40:20,680 --> 00:40:24,560 So that's kind of why, like an immediate reason why this is 732 00:40:24,560 --> 00:40:26,720 important. What I mean by this is 733 00:40:26,720 --> 00:40:31,320 succession planning mostly. So when you go on a vacation and 734 00:40:31,320 --> 00:40:34,880 you're not going to be available as a leader, I think that's kind 735 00:40:34,880 --> 00:40:38,120 of the test of what you've built, right? 736 00:40:38,120 --> 00:40:42,240 So the people and the processes that you have are the company 737 00:40:42,440 --> 00:40:45,600 and the code or the product is merely the outcome of that, 738 00:40:45,960 --> 00:40:48,040 right. And if you're hired good people, 739 00:40:48,120 --> 00:40:50,720 you onboarding them well, and you have the right processes in 740 00:40:50,720 --> 00:40:54,080 place, then you know you shouldn't be needed all the 741 00:40:54,080 --> 00:40:57,840 time. So I think at every lead's life 742 00:40:57,840 --> 00:41:00,440 there is going to be a time when you want to move on, you want to 743 00:41:00,720 --> 00:41:03,240 take on another challenge. And then it's like really, 744 00:41:03,240 --> 00:41:05,640 really important is much more important than your occasion 745 00:41:05,920 --> 00:41:08,120 that the team is going to survive without you. 746 00:41:08,520 --> 00:41:12,960 So a key aspect of this decision is who is going to be the person 747 00:41:13,200 --> 00:41:17,040 who is going to take your place. And we already talked about what 748 00:41:17,040 --> 00:41:20,600 is important in an engineering manager or any kind of leader. 749 00:41:21,040 --> 00:41:23,280 Do they have the clarity, Do they bring clarity? 750 00:41:23,560 --> 00:41:28,040 Do they have the energy? One key thing to me is do they 751 00:41:28,040 --> 00:41:31,520 have a strong tech background. So I think it's really important 752 00:41:31,520 --> 00:41:35,440 that before you become a tech lead, you're at least like an 753 00:41:35,440 --> 00:41:38,160 IC5 level, but most companies call IC Five. 754 00:41:38,160 --> 00:41:41,960 So the senior engineer, you've seen bigger projects, you own 755 00:41:41,960 --> 00:41:43,680 bigger projects, you've done that. 756 00:41:44,120 --> 00:41:47,240 This is apart from the empathy and liking to work with people. 757 00:41:47,760 --> 00:41:50,280 And then what I also like to look at is like, what is the 758 00:41:50,280 --> 00:41:52,560 motivation? Like why do you want to be a 759 00:41:52,560 --> 00:41:55,920 lead? Do you get positive energy out 760 00:41:55,920 --> 00:41:57,440 of, you know, dealing with people? 761 00:41:57,680 --> 00:42:01,000 Do you really enjoy those conversations that take place 762 00:42:01,000 --> 00:42:02,760 with between like product and engineering? 763 00:42:02,960 --> 00:42:05,400 Do you like these alignments that you have to have with 764 00:42:05,400 --> 00:42:08,680 multiple stakeholders? Are you strategic about things? 765 00:42:08,840 --> 00:42:10,680 Do you like to put structure on things? 766 00:42:10,720 --> 00:42:15,840 I think that's really, really key and one of the best examples 767 00:42:15,960 --> 00:42:20,080 that I've seen this. My career was a guy that I 768 00:42:20,080 --> 00:42:23,840 worked with in Europe. He was a junior engineer when he 769 00:42:23,840 --> 00:42:26,120 joined. He only had one or two years of 770 00:42:26,120 --> 00:42:30,320 experience and he was the kind of person who, you know, always 771 00:42:30,320 --> 00:42:32,920 said yes to anything. Like you had a problem, you 772 00:42:32,920 --> 00:42:36,800 know, I'm on it without knowing, you know, whether he has a 773 00:42:36,800 --> 00:42:40,000 chance of solving the problem. He just jumped on it and then we 774 00:42:40,000 --> 00:42:41,600 hired. As we built up the team, we 775 00:42:41,600 --> 00:42:43,080 hired more and more senior people. 776 00:42:43,120 --> 00:42:46,240 So we asked like who is going to on board them and he was the 777 00:42:46,240 --> 00:42:47,240 first one. I'll do it. 778 00:42:47,640 --> 00:42:50,240 I was like OK, let's see how it goes. 779 00:42:50,560 --> 00:42:55,000 And then as they were onboarding this person, when I noticed that 780 00:42:55,200 --> 00:42:59,080 even after the onboarding period, this person who had like 781 00:42:59,080 --> 00:43:03,080 10 plus experience and was a lead before was still coming to 782 00:43:03,080 --> 00:43:07,880 this guy who had two years of experience but was an expert in 783 00:43:07,880 --> 00:43:11,000 the domain and like just love to learn. 784 00:43:11,240 --> 00:43:13,920 And there was like a genuine relationship between them that 785 00:43:13,960 --> 00:43:16,600 like the more senior engineer was like coming to him for 786 00:43:16,600 --> 00:43:19,760 advice. So that made me think that the 787 00:43:19,760 --> 00:43:23,840 strengths here are really on, you know, like becoming an 788 00:43:23,840 --> 00:43:27,080 engineer manager. So we put him on a fast track to 789 00:43:27,080 --> 00:43:30,200 become a lead and within like 1 1/2 years or like 2 years, he 790 00:43:30,200 --> 00:43:34,120 was like leading a smaller team. So that's one of the best 791 00:43:34,120 --> 00:43:36,440 stories that I've seen. You know, someone becoming a 792 00:43:36,440 --> 00:43:38,920 lead. One thing how I like to think 793 00:43:38,920 --> 00:43:43,720 about it is that there are people who are leads even 794 00:43:43,720 --> 00:43:46,120 without the title. Well, how I like to think about 795 00:43:46,120 --> 00:43:51,200 my job is I want to put people in a position where their leads 796 00:43:51,200 --> 00:43:53,480 without the title. And then my job is just really 797 00:43:53,480 --> 00:43:55,440 easy. I just have to convince my lead 798 00:43:55,440 --> 00:43:57,640 and others to, you know, like promote this person. 799 00:43:57,880 --> 00:43:59,960 But the core of it is like already there. 800 00:44:00,880 --> 00:44:03,600 Yeah, sometimes I think in your team, right, you could identify 801 00:44:03,600 --> 00:44:06,640 this kind of person where they have a high agency, high 802 00:44:06,640 --> 00:44:09,160 ownership, they lead without having the title. 803 00:44:09,520 --> 00:44:11,600 And I think as a leader, it's an easier job, right? 804 00:44:11,600 --> 00:44:14,080 You just give them the title once they showcase and people 805 00:44:14,080 --> 00:44:16,520 also vouch for them, right? So I think that's really, really 806 00:44:16,520 --> 00:44:18,920 a good story for all of us to learn from, right? 807 00:44:18,920 --> 00:44:21,800 So it's not all the time that we have to wait for opportunity 808 00:44:21,800 --> 00:44:23,840 given to us. We can also create our own 809 00:44:23,840 --> 00:44:26,680 opportunity. So I think another thing that I 810 00:44:26,680 --> 00:44:28,960 learned from what you're sharing is that the key is also 811 00:44:28,960 --> 00:44:30,960 identifying the strengths of your team, right. 812 00:44:30,960 --> 00:44:34,960 So to build a proper bench and also as the leader kind of like 813 00:44:34,960 --> 00:44:37,920 wants to move on, you'll be able to build a succession plan 814 00:44:37,920 --> 00:44:40,080 within the team. So don't forget about that for 815 00:44:40,080 --> 00:44:42,480 all the leaders who are listening because sometimes, 816 00:44:42,480 --> 00:44:44,120 yeah, we we want to move on, right. 817 00:44:44,120 --> 00:44:46,200 And the team should still be sustainable. 818 00:44:46,400 --> 00:44:49,160 I think that's again the key theme of what Balas has been 819 00:44:49,160 --> 00:44:52,200 mentioning since the beginning. So Balas, I think it's been a 820 00:44:52,200 --> 00:44:54,040 great conversation. Thank you so much for your 821 00:44:54,040 --> 00:44:55,760 sharing about, you know, growing wise. 822 00:44:55,920 --> 00:44:58,280 Unfortunately we reached the end of our conversation. 823 00:44:58,640 --> 00:45:01,400 But I have one last question that I would like to ask you, 824 00:45:01,560 --> 00:45:04,080 which I call the three technical leadership wisdom. 825 00:45:04,400 --> 00:45:06,840 So you can think of it just like a summary of advice that you 826 00:45:06,840 --> 00:45:09,160 want to give for all of us to learn from you. 827 00:45:09,760 --> 00:45:12,280 Cool. Thanks so much for having me. 828 00:45:12,320 --> 00:45:17,440 I think the first thing that I would say is I learned this from 829 00:45:17,440 --> 00:45:21,800 our Product Director in North America is to think about your 830 00:45:21,800 --> 00:45:25,880 role literally, consciously learn what gives you joy and 831 00:45:25,880 --> 00:45:29,880 energy and make sure that you do those things regularly like in 832 00:45:29,880 --> 00:45:31,920 your work, otherwise you will burn out. 833 00:45:32,360 --> 00:45:33,960 I think that's the that's the first one. 834 00:45:34,480 --> 00:45:38,960 The second one is to block out the noise. 835 00:45:39,280 --> 00:45:42,960 Like block out the market. Block out where other people are 836 00:45:43,080 --> 00:45:45,960 in their careers and just have an inner scoreboard. 837 00:45:46,480 --> 00:45:50,680 Building things takes time, especially as a leader. 838 00:45:51,120 --> 00:45:53,880 You work with people, so building an organization will 839 00:45:53,880 --> 00:45:57,200 take a longer time. It's very hard to see results 840 00:45:57,200 --> 00:46:00,120 within a year. And all of the people that I 841 00:46:00,120 --> 00:46:03,800 know who made a big impact and were really successful, they put 842 00:46:03,800 --> 00:46:07,440 in long years in their life, you know, to solve that one problem. 843 00:46:07,720 --> 00:46:11,000 And these people typically have a lot of opportunities, right? 844 00:46:11,440 --> 00:46:15,320 So they're really good at saying no to those opportunities and 845 00:46:15,320 --> 00:46:17,400 just like locking on what they want to achieve. 846 00:46:17,840 --> 00:46:21,640 And then the last thing is so you cannot learn if you think 847 00:46:21,640 --> 00:46:25,800 you already know, if you think that you possess some skill and 848 00:46:25,800 --> 00:46:29,720 you're great at it, you usually don't see the things that could 849 00:46:29,720 --> 00:46:33,800 make you better. And usually this drive to learn 850 00:46:33,800 --> 00:46:37,040 new things becomes, you know, like much, much weaker. 851 00:46:37,400 --> 00:46:42,120 And whenever I felt like I stagnated in my career, it was 852 00:46:42,120 --> 00:46:44,680 because of this. Because I thought, OK, I did 853 00:46:44,680 --> 00:46:48,440 these things and I already know. And I stopped looking for, like, 854 00:46:48,440 --> 00:46:52,000 ways to improve. What helps you is if you can 855 00:46:52,160 --> 00:46:57,240 surround yourself or to have people in your life who are 856 00:46:57,240 --> 00:47:01,960 still inspiring you and who can still, like, show you that there 857 00:47:01,960 --> 00:47:06,240 are levels to everything, right? So just because you can like, 858 00:47:06,240 --> 00:47:08,880 run fast, it doesn't mean that you're using Bolt. 859 00:47:09,080 --> 00:47:11,240 Those are kind of the three things that I will mention. 860 00:47:12,040 --> 00:47:14,040 Wow, thank you so much. I think those are really deep, 861 00:47:14,040 --> 00:47:15,640 right? So if I can summarize, like the 862 00:47:15,640 --> 00:47:18,560 first thing is be conscious on what things to focus on, right? 863 00:47:18,560 --> 00:47:20,360 What things that brings you energy. 864 00:47:20,360 --> 00:47:23,200 And don't forget to do them because sometimes we know what 865 00:47:23,200 --> 00:47:26,360 we like, but we don't do them for, you know, maybe we are 866 00:47:26,360 --> 00:47:29,120 busy, maybe we got tied up with so many different things in 867 00:47:29,120 --> 00:47:30,920 life, right? And the second thing is about 868 00:47:30,920 --> 00:47:33,440 blocking out the noise and distractions and to focus on 869 00:47:33,440 --> 00:47:36,000 what we want to achieve in a longer time. 870 00:47:36,440 --> 00:47:39,160 And the third one is you can't learn if you think you already 871 00:47:39,160 --> 00:47:40,720 know. So really beautiful. 872 00:47:41,360 --> 00:47:43,800 So thank you so much Balas. If people want to connect with 873 00:47:43,800 --> 00:47:46,000 you, they want to reach out and ask you questions. 874 00:47:46,000 --> 00:47:48,000 Is there a place where they can find you online? 875 00:47:48,560 --> 00:47:52,040 Yes, I'm on LinkedIn. Let's connect and chat there. 876 00:47:52,360 --> 00:47:55,680 And we are hiring in Austin. We are hiring product managers 877 00:47:55,680 --> 00:47:58,320 and then engineers. So if you know someone or you 878 00:47:58,320 --> 00:48:00,760 are someone who would like to work with us, then hit me up. 879 00:48:01,680 --> 00:48:04,040 So thank you so much for your time again, good luck with all 880 00:48:04,040 --> 00:48:07,320 the wise growth the next stage. Thank you so much. 881 00:48:10,200 --> 00:48:13,320 Thank you for listening to this episode and for staying right 882 00:48:13,360 --> 00:48:16,040 until the end. If you highly enjoyed it, I 883 00:48:16,040 --> 00:48:18,800 would appreciate if you share it with your friends and colleagues 884 00:48:19,040 --> 00:48:22,040 who you think would also benefit from listening to this episode. 885 00:48:22,440 --> 00:48:25,200 And if you're new to the podcast, make sure to subscribe 886 00:48:25,240 --> 00:48:27,600 and leave me your valuable review and feedback. 887 00:48:27,960 --> 00:48:30,840 It helps me a lot in order to grow this podcast better. 888 00:48:31,360 --> 00:48:34,240 You can also find the full show notes of this conversation on 889 00:48:34,240 --> 00:48:37,200 the episode page at Techni journal dot dev website, 890 00:48:37,520 --> 00:48:41,120 including the full transcript, interesting quotes, and links to 891 00:48:41,120 --> 00:48:43,520 the resources mentioned from the conversation. 892 00:48:43,920 --> 00:48:47,000 And lastly, make sure to subscribe to the Shells mailing 893 00:48:47,000 --> 00:48:50,800 list on Techly journal dot dev to get notified for any future 894 00:48:50,800 --> 00:48:53,400 episodes. Stay tuned for the next Techly 895 00:48:53,400 --> 00:48:56,280 Journal episode, and until then, goodbye.