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.