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.