Hi everyone, My name is Patrick Akil and for today's episode, we
go inside the mind of an engineering manager.
One of my favorite topics, especially in a landscape where
software skills to millions of users.
Joining me today is Anna Salman, Senior Engineering Manager over
at Uber. And he has done this many, many
times. So enjoy.
I've started working at ING as an assignment since January and
I never imagine myself working at a bank.
And they're, the processes are very much there for risk
management. So they're all in place with
regards to minimising risk because that puts ING at at a
danger. And then the processes make
sense to me, even though I might not like them, I don't have to
like them. It makes sense from a company
perspective because it's in good interest for the company.
Exactly. And you, maybe you'll not like
them, but lately I started appreciate them.
There was a need for these processes to be in place and to
be implemented to be there. So that's why when I see a
process and it's very strict, I try to understand why the
process is there. Yeah.
What's the purpose of this process?
And what's the value of this process?
And when you learn this, you'll appreciate it.
Yes, some processes are annoying by nature, but yeah, that's
there's a need behind it. How do you communicate that to
your team then? Because I've been in positions
where I don't agree with the process, but then I still have
to convey to other people that we have to stick to this
process. You, though, I don't agree.
It's like I, I, yeah, it's a bit of a hard position.
I totally agree. A lot of processes, especially
when you do promotions, when you do performance evaluation, when
you do some design documents, we have to go through all these
processes. I have to just highlight the
value of the process, what is the outcome of this process and
why we are doing this process for the team.
What I notice the team will understand over the time and as
a manager, I have to repeat this message again and again.
Over the time the message will stay.
Some people will raise valid concerns, by the way, about for
example, let's say promotion process.
They raise why this, not that and as a manager, if this is
coming from multiple engineers from the team, I should take
this feedback seriously and bring it up to upper management
and have a discussion. This will be an opportunity for
me and for the team and for the company.
Is that also one of the points of seniority when we're talking
about engineering management? Because I did some research and
you have different brackets, but I feel like skills like
communication and getting by and those you can go really deep on,
but I don't know if that actually makes someone senior in
that role specifically. I agree with your point.
And on top of that, seniority is how you see things and how you
feel against things. So I can give an example.
When I started my career as an engineer manager with a big
company, I started a promotion case for one of my engineers.
I was pushing hard. Yeah, I want to get this
through. I got emotionally attached with
the case, not approaching the case systematically and
objectively. So I put a lot of emotions
there. The promotion didn't go through.
I was feeling bad at that time. It affected you.
It affected me deeply. But over the time, you'll
understand the framework of the promotion process or the
performance process. So OK, this is my case.
What are the key points I'm trying to advocate within this
case in software engineering, system design, collaboration,
leadership, all these kind of aspects?
Do I have all the data points? If yes and I have the
confidence, then we can go to the promotion process or the
promotion cycle we call it. If the case is solid enough, the
committee will get back to you with a strong convention that
this is a good case for promotion.
If there are some gaps, I have to give them understand where
are the gaps and as a manager I have to communicate this to the
engineer. This is one, The second thing,
this will create an opportunity for me and for the engineer
where are the opportunities in terms of projects and terms of
processes where he can or she can influence the company and
then get this data point done and get to the next level.
Yeah, that process frightens me because I, I look at myself, I'm
now software engineer, Xevia or consultant.
I do product management because I think that's interesting.
I don't know if I'm going to do that full time, but I always
thought that engineering management and developer
advocacy are really interesting career paths with engineering
management. I love being friends with my
colleagues as well. And like you, I think I would
really get emotionally attached to someone's success within my
team, especially throughout that promotion process.
And then if it wouldn't actually happen, it would also affect me.
Like, I can genuinely see that happening.
And you've managed to objectify kind of this process and keep
yourself out of it emotionally. But does that also distance you
from the people you're managing in that way?
Or how do you handle that? My preference is to keep the
connection with the engine. I always say I should have this
kind of two way communication channel and build a trust from
day one. When I'm looking to an engineer
growth, I'm not looking for a promotion as a goal.
I'm looking forward for the promotion as a side effect.
When I'm working with an engineer, I, I start with
identifying the strength point and where are some areas of
opportunities or gaps, and I highlight these areas clearly to
the engineer so we can double down on the strength areas we
can find some opportunity with where they can improve on the
areas of opportunities. For example, if they don't have
a project where they can work across multiple teams, I'll
start trying to find the right project for that engineer so
they can work across multiple teams.
Within this process, they learn a lot of things, how they want
to communicate, how we want to build alignment, how they want
to build execution, all this kind of stuff.
The next step after that, see where are the gaps on their
experience or let's say areas of weakness on their experience and
highlight this. Some areas we should acknowledge
them. They are there will not change.
Different people, they have different personalities.
But if I'm able to fix it and work with the engineer, then
we'll work on it. The out of this process will
lead to a promotion, but the promotion is not the goal is not
the goal. If we were able to get the
promotion within this cycle, that's great, but we should make
sure that all data points are in place so the engineers and the
engineers are operating in the next level so we can go to the
promotion. If they didn't go through, we'll
try in the next cycle after getting the feedback of the
committee. Yeah, Yeah.
That makes a lot of sense in in looking at that growth path for
each individual. You mentioned personalities are
different, so strengths and weaknesses will be different.
Is there still a baseline that you would want to see in
engineers with regards to certain set of skills that you
always focus on? Great question.
There are the foundation, I call them and there are the skills no
one teach you in the college or in the in general how to
approach them. Let's say the foundation which
is software engineering, coding, problem solving, data structure,
algorithms, all these kind of stuff, system design, how you
are approaching the design problems, these are the
foundation. They should be there
understanding all the technology concepts.
And if there is a gap on these ones, I think some people were
able to bridge them. But yeah, that would be a flag
on the on their skills. But that can be bridged as well.
The second part, which is communication, especially right
now, communication is becoming more and more crucial.
How you want to approach multiple discussions from
requirement gathering with product manager, with
engineering manager, with stake all stakeholders.
How you want to manage all these discussions.
The second one, how you want to manage the execution within your
scope within other engineers and how you want to manage
communication with other teams, especially with more seniority
and your career growth. Why is that right now more an
important point than it used to be?
Be first with AI. Yeah, I start building a feeling
that coding will not be the biggest problem, OK, How you
want to articulate the problem will be the skill that we,
everyone will need. So we you can leverage the tools
in hand right now. Gotcha.
So this is one, the second thing, if you want to grow on
your career, you have to work on a high scale.
What I mean by high scale, working with a lot of teams in a
startup, you're working with a couple of engineers, you are
able to communicate easily. But if you are going within your
career, you are working in a big tech company, you have to work
with a massive number of teams. How you want to build this
alignment? How you want to build a buy in
from other teams within about your solution, This will require
a lot of communication. Writing skills is crucial as
well and managing meetings, managing the discussions within
that meeting is another important skill.
Interesting. So this is the communication.
The third one, which is ownership, how the NGS are
approaching their area. Some NGS, they're not proactive,
they're waiting for towns, they're waiting for assignments.
Other NGS, when they go to area, for example, let's say check
out, they'll try to understand this area inside out in the
first, let's say six months. So they will build the depth and
how they build this kind of thing by taking ownership.
What I mean by this, for example, if there's a bug,
they'll volunteer. Yeah, this isn't the checkout.
I'll take it, I'll handle it. For example, in the 1st 234
bugs, they'll not, it will not be easy.
But after doing this iteration multiple times, they, when they
see the bug, OK, this is in that area.
This is the problem. Even without seeing the code,
the ownership will reflect on their accelerated carrier growth
so they can move faster and they can own their ownership over the
time. So this is 1 aspect from the
business side. They will build the strength on
their area so they can provide strong opinions on that area.
How do you build or stimulate ownership?
Because I've I'm now partially my responsibilities also being a
team lead. So I oversee consultants and
they do different assignments. So my setting is a bit
differently. But when people really don't
have a passion for it, it's really hard to take ownership of
something. Even though it might be good for
them, their growth or their career.
I have a really hard time than stimulating it.
I can give advice or give my perspective, but at the end it's
their decision that's the hard part for me.
I agree. The first thing I have to
understand the people motivation, what motivates them?
Is it the technical aspect? Is it the product aspect?
And what is the main motivation? Is it the growth or promotion or
whatever? So this is one, the second thing
on my area, where are the opportunities and where I need
real help on that area. And I'll start to match between
the people needs and the business needs.
As a manager, I see my job as as a glue between the business
needs, growth plans and between the people needs and growth
plans and how we make the right plans so each one of these
parties get their goals. When I try to match this with
their goals, this will over the time, over multiple discussions,
we'll try to find what is motivating them.
This is one. The second thing, which is
awareness. How can I build this awareness?
This is this area or this project or this thing will be
beneficial for your carrier growth so they can optimize on
getting that right. The last thing, I want to just
expand the process. For example, how you want to
handle projects end to end with full ownership.
As an engineer, I do this in the first same boarding sessions.
I do it over each project. The second part, which is how
you want to own the area itself, beside the project, there's an
operational work in any area. Some people complain about it,
but I see part of our core job how unhandled operation on that
area. And I also highlight this to the
engineers so they can have the full awareness of their
responsibilities. Yeah.
So it's the fundamentals of technical skills, communication
and ownership that's like the baseline.
Exactly. It's everyone.
Exactly. Yeah, I love that.
For me, I think you have excellent communication skills
and I I love this conversation so far to a point where I could
see people loving being in your team as well.
You have a calm, clear demeanor, and I love people that can
provide clarity. I have noticed that when things
are unclear, you get frustration, you get rumors,
people act in a weird way if there's no clarity.
And people that provide clarity, I start to appreciate more and
more. How did you get to a point where
you have this clarity, you're able to communicate it clearly?
Was this a goal for you or was this more of a side effect by
the things you were doing? It's a matter of time for
learning through the experiences that you are going through.
This is one. So the second thing I prefer
transparency as as you mentioned and clarity.
I noticed that even you if you share the goal one time, it will
not be enough. You have to keep reiterating the
goal for yourself in the beginning as as a manager and
for your team, and over the time people will align on that goal.
If there's this alignment, they will share it.
They will not agree with you. They'll have a discussion and
welcoming these kind of discussions will be beneficial
as well. Then when you have the alignment
with the team about the shared goal, everyone will work
automatically against that goal. And naturally they'll approach
it and start executing on the projects on hand.
This is 1, and they'll start coming up with new ideas that
will make it make us go against that goal faster.
So clarity and transparency. Sometimes, yeah, you have to
make hard decisions, but you have to approach it with full
transparency. For example, during COVID, you
had to do a lot of hard decisions, deprotizing some
projects, deprotizing other projects, moving a lot of stuff
here and there, a lot of urgent asks.
You have to approach it with full transparency, explaining
why we need this, why the business is needing this, why we
have to pivot at this time. And people will have a
discussion will challenge you for sure.
But by the end of that exercise, everyone should get a buy in and
we can move to the same goal and same target.
That's probably the hardest part, right?
If things are going well, then it's easier to align people
needs and the business needs because you have time, you
probably have more resources, things are going well.
If things are not well, then that's the most crucial part and
that's where I see organizations either make it or really break
also with regards to the strain they put on people and the
people that are not getting by and actually being frustrated.
Better than leaving at the end, yeah?
I really like this point because if you ask me about when you can
differentiate managers or people in general, it will be the
difficult situations. Yeah, if I have a stable team,
everything is doing well, things are going great for me as a
manager. I'll OK, What should I do?
That's it. It's like no role.
For me as a manager, I'm trying to see where are the
opportunities and if there's a problem, how to debug it and
understand the root cause of it. And if there's a difficult
situation, how when approach it with the full team, what are our
plans and what are our alternatives.
So I think these are great opportunities.
Some people complain about them, but I see them as a great
learning for each manager or for each engineer within the team.
And usually I highlight this. Challenges are not usually bad
things. In most of cases, I see them as
gifts where we can learn. Maybe we'll do good, That would
be great. We'll do a lot of mistakes that
would be even awesome because you'll learn out of them.
And I keep saying mistakes will be the major, let's say,
accelerator, accelerator for your career growth.
So we should appreciate this kind of situations that will
give you this ability to learn from them.
I'll try to leverage the minds of my team so we can land on the
solutions. For example, if there's a
difficult situation, there is a change on the business needs,
there's COVID or whatever, I tried to leverage the minds of
my team. How we want to approach that
situation. Yeah.
Can we land on a plan then? As a manager, my role is to make
the final decision and align the team on the execution how I want
to approach it in general. Did you also find yourself then
with people that, for example, looking at an individual and
their plans and aspirations, did not find themselves in that
company anymore as a position or for their own career?
Because that's the hard part for me.
That's natural. By the way, at some point, maybe
the company, the company will not be fit for your goals.
Yeah, or the team will not be fit for your goals.
I can give you so many examples. For example, if I'm working in
an area, it is not that complex, it will not require a lot of
cross team collaboration. And one of my engineers reached
to, let's say the most senior level within my team and I'm not
able to find opportunities. Yeah, As a manager, first I have
to have a discussion with my leadership.
I have this engineer, he has this kind of aspirations in his
area or their area. How we can approach this one?
Can we find an opportunity for that one?
If we're not able, I have to communicate clearly.
This is the limit. Either you can live with the
situation until we get an opportunity or you can find a
new team within the company where you can find your the
goals there within that team. And that's natural.
To be honest. In some case situations I'll be
in a different direction. When people have, they have new
life situations, personal situations, for example, they
have more responsibilities in their home, they have new kids
or whatever and the area that they are working on, it's very
demanding. We cannot sit back and wait on
that situation. Also, finding a team with good
balance will be a good move for that person.
Do it where they can have the right balance on their career
and on their life at that moment.
Yeah, yeah. Also for the team, I think if
you notice that there is high pressure and then parts of the
team are not functioning well because of a life situation that
changed, it's fine. But it will put a strain on the
team if it happens for a longer period of time.
If one of the engineers not performing well, the load of
that engineer will be distributed among the engineers
beside that engineer so that the need will not vanish.
The need will be there. The team will feel it over the
time. Just for my context in this
building up relationship with engineers on a one to one level,
how many engineers are you working with nowadays?
What is the scale of the operation?
Right now my current team is around 35. 35.
Engineers 3 engine managers I'm working with, with most of them
either directly or indirectly. So the major, let's say the main
set of people I'm working with right now, around 778 engineers
and engineering managers. This role of engineering
manager, I, I think it doesn't work well at a start up, right?
Because all hands matter. You don't have, I think the
capacity for that overhead that only manages.
They will also need to be hands on basically.
But as you grow in organization and skill, that's when I see
those positions be more apartment and pop up because
people that dedicate themselves into multiplying the efforts of
engineers in growth opportunities or opportunities
within the company. Happy engineers.
If you have 700 happy engineers that pays dividends, basically
people that facilitate that. Those are valuable at that scale
of the organization. When do you think the
engineering position makes sense organization wise and when
doesn't it make sense? I have a strong opinion here.
I always see a need for an engine manager position even
with small start-ups. OK, at some point maybe the
founder, the CTO will play that role, which is fine.
But once the team started growing, you need that level of
guidance within the team. You need someone to take
responsibility of managing the carry growth of the engineers,
aligning the company growth plans with the plans of the
engineers. That's the role of the
engineering manager. They can be hands on.
I did it for 3-4 years in my early career.
It was great experience for myself because you're doing the
designs, you're doing the say architecture of the system.
You're breaking down the task that other engines are working
with you, but it is challenging. It is very challenging because
when you are writing code, you need this kind of amount of
focus on that area. You should be in the zone and
when you are in the manager, people are just reaching out to
you, just interrupting you within while you are working on
your desk. It will be challenging switching
contexts. It will be very hard, but you
can do it if you are able to manage your time properly.
For example, dedicating the early time in the morning for
just recording design. The rest of the day will be just
management that will be that will work.
Interesting. That's also what I've noticed in
people that make assumptions about the context too often with
regards to their manager. Someone comes to them, they make
a bunch of assumptions, and then if they end up being wrong,
that's even more frustrating. And they do so because they
might have too many people that they manage, so they have to
kind of quickly pivot and switch contexts.
But then the assumptions, that's where the crux is, I feel like.
I think assumptions is a by design is there with every one
of us, but it has a lot of side effects, bad side effects.
If you are just trying to rush to a decision with a lot of
assumptions that will put you and put the team in a very wrong
place. So if someone just reaching out
to you just for a quick decision, you should assess is
it critical decision for the team or for the structure of the
code or the service. If that's the case, you should
go with a certain process. What I mean by this, yes, let's
either have a discussion or let's put it in a document where
we can discuss it properly and land on the on the on a
decision. This will be a little bit
slower, but I think it's a good exercise for everyone, for the
manager, for the engineer, for the rest of the team.
These decisions, you cannot skip them and just making them one to
one. With engineers, you have to
bring awareness for the rest of the team and you have to bring
the other minds to that decision so you can make the right
decisions. Interesting.
Capturing it through a document. Yeah, I think that can be very.
I haven't seen that often, to be honest, because a lot of things
are then verbal and then how people remember the things that
were said can also be misinterpreted or misremembered.
Yeah, that's where issues arise. Yeah, exactly.
And that will be the area of, let's say, assumptions.
You're working on something. Someone is telling you with
little words that this is the problem, I'm trying to solve it
by 123. Yeah.
Do you agree on that? You have to make analyse
everything, make a decision in just one minute.
I don't think this will work properly for yourself, for the
team and for the service itself. So approaching it from a
structured way that will help everyone within the team.
And I think writing skill is underrated.
Everyone should appreciate it. I know some people will say be
frustrated, why should I write it?
Is it? Does it worth it?
But I think going through this exercise will be beneficial for
everyone. Interesting.
Circling back to what we were discussing earlier when it comes
to the role of engineering management in smaller
organizations and bigger organizations, I was curious to
hear your opinion on what type of people usually fulfill that
role. Because if I were to look back
ten years ago, I mean, I wasn't really in this field, but this
is what I've heard. It's all hearsay.
Individual contributors were usually pushed towards
management positions because of their technical excellence,
right? If you're talking about
technical skills, communication skills and ownership, people
that would have that would then be kind of pushed towards
engineering management as a next step in their career.
Nowadays I don't see that as often.
There are more depth roles for people that still have all of
that and more so then who fulfills this role of
engineering management as you've seen so.
At some point I agree with you that was the carry growth for
each one of the individual contributors.
When they grow to certain level, the management is the next thing
for them. Right now, luckily it's not
there, which is great because when you go go to management
path, there are so many different skills you need to get
and learn to perform a new position.
It's not only the technical aspect, it's one of the aspects.
And if you have, you should have it for sure.
It's not a question, but there are a lot of other aspects.
You have to get it right so you can perform well in at your
role. People management, how you want
to handle the people growth plans, how you want to handle
conflict, how you want to handle meetings.
This is 1 aspect, how you want to handle products.
You're not APM, but in so many situations as an engineering
manager, you have to act as a product manager by nature.
And the other thing which is hiring business plans, how you
want to put the long term goals for the team and for your area.
All these kind of skills, you don't have them by say, through
the education system. You have to learn them from
scratch as you are transitioning to that, to that role.
Some people will excel because they really like working with
people. They really like to hear people
problems and how to solve them. Some people will get frustrated.
I have so many situations. People transition to become
engineer managers. Then they shifted back.
And during that transition, I'll be honest with you, it will be a
little bit hard. I went through that exercise.
Some part of you, you'll feel OK, I want to just write
software. I want to just write the design
document. I want to get back.
That's what I have right now as product manager I.
Miss it. I have it and I still have it in
my side, so that's why I work a lot of side projects to fulfill
that need. But at some point you have to
make a decision what's fulfilling you more.
For me, I feel that today working with people,
understanding their problems, trying to help them,
understanding the business needs.
How anyone up achieve these goals?
From the business side, I feel motivated when I go through my
work everyday. I feel I have a huge boost of
energy. I want to just get it there.
What's amazing. Yeah.
So that's where I see the need of the Ng managers.
If you are feeling good and you feel motivated about these set
of problems, you'll be excelling as an Ng manager.
Is there any harm in trying it out?
Because you said people try it out and they realize it's not
for them, they switch back to IC.
Most of the companies, they have this kind of process where they
you can try engine management for six months or whatever.
If it is not your thing, you can go back.
This is one approach. The second thing, at some point
at your career growth as an engineer, you have to reach to a
lead position. You are not an engineer manager,
but you are taking some responsibility from the engine
manager. Like you're owning a project,
you're owning the execution, you're aligning engineers and
managing and orchestrating all the execution and stuff with the
with the team. You can get a sense of how
things are happening at the engine management level.
It's through experiment so you can see how things are working
for you. Yeah, Yeah, that makes a lot of
sense. If you were to then look at
those people that transition, maybe do it partially or maybe
get that leadership role, My assumption is it starts with the
one-on-one conversations, building trust with individuals
and being more responsible for their personal growth.
But then you have responsibilities with regards to
strategy, more on the organization side, team scale,
or even team structure in some cases, hiring strategies like
everything gets added on top of that.
How does this like Excel? How do you say that escalate
towards full time engineering management with regards to
responsibilities? It's a progression.
You start as I mentioned by just owning some part of the Ng
manager responsibilities and as grow, as you are growing on your
career, you start finding new opportunities.
As you mentioned right now you are at the first level.
You are owning the execution as an Ng manager.
This is your main responsibility.
You have the road map, you have projects.
It's well defined. You have to execute on it.
This is the say stage 1. Stage one, yeah.
Stage 2, then you can start working with the product,
working with other stakeholders to put the plans for your team.
What are the next projects? How when I approach them, what
is the goal for the business overall and what is the goal for
my area? And then you start jamming with
product managers, with other stakeholders just to come up
with a road map for your team and have a proper discussion.
And as you grow, for example, the next step, you have the road
map, but you don't have enough engineers within your team.
You should have a discussion with your management.
I have this kind of ambitious plan for my team.
It will grow the business by X, but I don't have the right
number of engineers within my team.
I need this and that to my to achieve this goal.
Then you'll have the, let's say resourcing, planning with the
upper management and so on. As you grow within your career,
you start taking more responsibility to Start learning
a lot of new stuff and you'll find your way that at some point
you are covering most of the aspects.
Yeah, interesting. I kind of got hung up on this
product mindset that you mentioned that as engineering
manager you should also be sometimes a product manager.
And I see that in engineering more and more, right, Really
good software engineers really understand the product or the
domain specific to that product, because then they can actually
solve problems rather than just build things.
And building things doesn't actually solve problems if it's
not the right thing. So this mindset I think is
increasing awareness, but then still I think that's where this
dichotomy, I don't know if product, there's still always
one person responsible and I do think it can become a shared
responsibility at the end. I agree with your point fully.
As an engineer, your success will be measured by your ability
on working in an incomplete or imperfect conditions.
Yeah. What I mean by this, don't
expect in all projects you'll have a dedicated product
manager. In that situation, you should
show proper understanding for your area, owning some
discussions about product, how you want to shape the product
within GM management or with the product management and come up
with the right solutions from a product perspective.
To that theory, I have so many examples within my team where
engineers advocated for a lot of ideas.
They started the discussions with product management or with
engineering managers and they come up with a new ideas and
then the product manager in this situation will play as a
facilitator and shape the final outcome of the product.
At the end of the day, they are accountable and responsible of
the product, but most of the discussions in this kind of
situation is coming from engineers, which is totally
fine, not even fine. I totally encourage it within my
team and I see it's happening more and more right now in the
industry. Yeah, I'm now in the role of
product manager. Yeah.
And I I love ideas. I do think it's, I don't know if
it's a fallacy, but it's sad to see that people really get
invested in this idea, right to a point where if eventually to
know, they also get emotionally attached to that idea.
Even objectively, if I can provide clarity on why it's to
know or why it's to not. Now, I really hate to disappoint
people, especially if they're engineers, because in the end
they're going to work on different ideas, right?
For stakeholders, it's different because in the end, they'll be
on a list with regards to milestones or priorities and
they'll be somewhere down the line.
But engineers actually have to then work on other ideas that
they don't have the same buy in for because of that so good
cost. It's like, don't get married to
your ideas. Great point.
So first in my opinion product managers, they should not be a
yes product manager especially for engineers.
Yeah. So this is one, the second thing
they are welcoming ideas from the from the team, showing the
understanding why this is ideas important for that engineer and
building a framework where they can assess the need of that
feature. If the engineers are able to
assess the importance and the need of that feature, they can
do the privatisation by themselves.
And usually I prefer to do this kind of, we have this project
and the other project, but this project will provide more, let's
say, bookings for the business or it will increase our response
time by X. So what's one of these projects
will prioritize? If you are the product manager,
I'll make the engine to make a decision in this kind of
situation. So at least they can show
empathy while we are making that decision.
At the end of the day, people in their early careers, they will
build this kind of emotional attachments against their ideas.
But as they grow, they'll understand, OK, I should
generate a lot of ideas. One of them will go through
exactly and will make the impact.
Others will not go through. And this is the life not only in
the in the industry. Yeah, I absolutely agree with
that. I when you said people early in
career, I was thinking, yeah, I see that on the product side,
but I see that even more with regards to technical ideas like
the implementation direction, solution direction.
You can have a multitude and in the end, sometimes it doesn't
even matter. You don't even need a pro call
list. You need to go fast and iterate.
But then that's also where I see the buy in being really like but
but why not this one specifically?
On the technical side, usually or in a lot of situations, you
have business need. You have to achieve that
business need in a very short time frame.
As an engineer, you should understand the business need.
We need this kind of feature. We need to get it fast.
We have to make a lot of shortcuts that will create
ticket from senior engineers. I'm expecting they'll put a
plan. This is the short term goal.
We will achieve this kind of business goal.
This is the solution for it. It will create XYZ as a tech
debt. The long term plan is like this
and they lay down the long term plan and hone approach it
properly for the business and they hand it over to the Ng
manager. The Ng manager should work on
the first goal which is the short term achievement, the
business goal, get it done. The long term plan will be the
responsibility how to advocate for it on the next planning
cycle because any tech debt will come back later.
Yeah, it will not vanish at some point.
It will break the system if you are not handling tech debt
properly. It will get back and bite you at
some point. So you have to be careful as an
engine manager that tech that should be handled in a timely
fashion in the earliest time possible.
And that goes also into the organizational culture because I
agree with you, it's really hard to make shortcuts that not have
tech debt. So tech debt is a natural thing
in my opinion, right? And you learn how to mediate it,
but then the skill is to communicate that we should
mediate it or to what degree. And then if there's no
organizational culture with regards to tech and prioritizing
tech debt, then that's the hardest part.
Because if you're a company that their core is creating software
for millions of users, like that's their core.
They know tech debt, they know they need to mediate that.
But if I have a retail organization and I have an
e-commerce department, which is part of my retail chain and
retail's still the biggest thing, then it's just a part of
it, right? So they don't.
They might not understand this concept of tech debt or that we
need to mediate it in the first place.
As an owner for that area, your responsibility is to bring this
awareness. Yeah, I made this mistake a lot
of time in my career when I build this assumption that
business are aware of this Technet or they're aware of the
consequences of that Technet, but actually it was not there.
Hard truth. Hard truth.
So as I mentioned, at some point this tech debt will come back
and buy to you. If you want to scale to a
certain level of you want to add a new feature, If you want to
expand to a certain location and you are not, you didn't handle
that. And it will be that that you
have to pay it at that time when you build a new project and your
system is not able to scale to that level.
Responsibility as a managers on that area to bring this
awareness every planning cycle that you should lay down this
tech debt. This is very critical because
one of two three on the short term this is the side effect on
the long term. We are not able to do 123
because of this tech. Yeah, keep reiterating.
It will not harm you. Just keep reiterating.
Just at some point this message will stick and.
Yeah. I also, I think tech debt is
natural. And it's also natural to not
have all tech debt be solved. Yeah.
Because in the end, I sometimes see people spin and be really
dogmatic about tech debt and that then translates into tech
excellence. And in some parts of the
project, we don't need tech excellence.
So that tech debt will never get prioritized from my perspective
right now and then never actually be picked up, but
actually also not really have an effect on the customer or the
goals or the features that we build, right?
It's this balancing act of what Tecta actually has priority and
what is actually fine to have in the 1st place, or will require
such an amount of effort that it's actually not worth it.
So you have to build your privatization framework, Yeah.
What is the impact of this Tecta?
Is it latency? Is it response time or say
failure rate or some other aspects on the on the on the
technical side. So this is 1 aspect.
The second aspect which is your speed of development, how you
are moving fast on that area. The third thing which is the
quality. For example, if you have a lot
of tickets or bugs on that area or a lot of incidents, then this
will be a metric. You can measure it that we have
so many incidents on this area because of this take that we
should handle it. So we will not have more
incidents on that area. At the end of the day, incidents
will be business impact. So how you want to build your
prioritization framework to protest the right that will be
solved in the next planning cycle.
That would be your responsibility to build it right
and to build alignment with the product and with engineer, with
the management of your area. And over the time, at least in
the comments I worked with, we had this kind of allocation for
handling Technet, for example, 20% or 25%.
And then it depends on the area where we can have just engineer
projects where we can improve the state of our system.
Yeah, this will give us as managers the flexibility to
prioritize projects even without justifying them, because
justification will need a lot of effort, mental and alignment and
communication, all this kind of stuff.
So we just make a sample. 20% of our bandwidth will go to
handling ticket engineering excellence.
We'll figure it out. I've noticed it also really
fulfills engineers to work on tech and tech excellence.
It's like, exactly. It's their craft right?
It makes sense completely. One of the last thoughts I had
got triggered by when you were explaining that failures are
great. You learn from failures, even
sometimes more so than success, and I'm curious to see how you
approach failures then, because your role is to also guide
people with regards to personal development.
They're going to come to you with specific queries and
specific contexts, and there you can have the role of giving
feedback based on what you have or advice based on what you did.
But sometimes I've also found myself in this position that I
know they might be I'm making a mistake and I can prevent it,
but then I choose not to, to see how it plays out and for them to
actually learn from it. But then I still have a
balancing act to do for what mistakes are fine and what
mistakes should I actually prevent?
Great one mistakes are, as I mentioned, are great accelerator
for your career growth. And having awareness about these
mistakes is very crucial to to solve them first framework,
which is if there's a mistake or if there's an issue about your
work, about things are happening, about your quality,
all this kind of stuff, just highlighting them build a
framework which is why this is happening and what is the root
cause and how when I approach it.
So bringing the awareness, the solution on that as part of that
awareness so that engineers can embody or the team integrate
these learnings in their next project or the next incident
handling so they can handle it properly.
So this is one, the second thing, it's fine to give your
team a space or the freedom to do stuff as long it's not
business critical. What I mean by business
critical, it will not make the checkout down for one hour or
two hours. This is a big thing, you should
try to avoid it. But they can experiment with
their designs, try to benchmark or try to do other things.
Give them the space. Try not to be, say,
overprotecting. By being overprotecting, people
will just get back to you over and over.
They'll lose the opportunity to learn and make decisions by
themselves. So give them the freedom of
making choices and making decisions with clear boundaries.
Yeah, this, this overprotecting behaviour is also what I've seen
that people then pick up and translate into the next
assignment that they have where they're like, we shouldn't
actually do this because things can break.
And I'm like, OK, what is the possibility?
And then what will be the impact?
Just check out going to be down. And if it's a no, then we might
actually be fine. Also making mistakes here.
But then that bleeds into the next part and they're like, OK,
maybe this landscape is different where it takes a while
to have that realization that you can actually take ownership,
experiment and reap the gains if there's a lower risk.
Yeah, as a manager also you have this responsibility to bring
awareness again by asking questions.
What will happen if you do do that?
Is it going to break down this or that?
What will be the impact on this? Do you have a mitigation plan if
things go wrong on that area? What is your roll out plan?
So starting highlighting the process that will protect the
team and will give the them the freedom to operate freely with
the right processes that will give them the confidence that
they can deliver with a good quality.
Awesome, I've really enjoyed this conversation.
I must say. I feel like it's like inside the
mind of an engineering manager. Maybe I'm going to label it that
in the episode title. That would be great.
Before we round off, is there anything you still want to
share? I always give this curveball to
people at the end and then they're like, yeah, what?
What is left? Yeah, one thing I can share,
it's fine to define your carry growth.
It's very important to drive it to ask your manager and to have
a discussion with your manager how you want to approach it.
It's fine to come up with a new ideas.
Don't you be shy asking questions, asking for critical
conversations with stakeholders in a proper way, in a nice way,
just to understand the business needs.
Having the ownership of your career is very important of your
career growth and not waiting for others to shape your career.
Yeah, that will make things totally different.
Even the manager will look to you in a different with a
different perspective. If you are driving all the
stuff, they be more supportive to you because you're taking the
most, let's say, burden work from their side.
Yeah. And you're owning that one so
they can focus on the areas where they you can grow further
in your career. Yeah, it will be really
appreciated. Yeah.
And it shows that ownership. Exactly.
Absolutely. Thank you so much for listening.
If you've enjoyed this episode, leave a like let us know in the
comments section and we'll see you on the next one.