Balancing Technical Expertise and People Management in Tech Leadership

Hey Ramiz, how are you doing?

Hey Mike, I'm good. How are you?

I'm okay as well. Thank you for asking. I mean, the weather isn't that nice. I just looked through my window, but it is a winter. What do you want, right? So tell our listeners, Ramiz, who you are. What's your journey in the tech industry?

It dates long, long back. So I started around 2002 within the tech as a sysadmin when sysadmin was the desired job. And I evolved with the job and I got into automation and getting working hand in hand with developers. So like the beginnings of the movement of DevOps. And I turned manager at some point. Uh, there was a— then that was a really a, a turning point in my career that I, for some reason, I can get into that a bit later, but I got more interested in people problems and how can we get teams to really deliver their best and work together and like foster a good environment. Uh, so it made more sense for me to switch into management. So I switched into management. And since it's been like almost 9 years now that I've been doing that, and I've ventured in startups, scale-ups, large companies. And most recently, I got into coaching. I used to think I was doing coaching as a manager when I used some coaching techniques. But I learned that coaching isn't just asking questions and isn't just whatever we read in books, there's methods, there are different things, there's different state of mind. So I decided I want to venture into that, and I got trained on coaching. And today I am, I am a fractional leader within tech and a coach, leadership coach.

Okay, so you went from being an individual contributor to effectively transitioning to peopleware, just people management, coaching, and leadership role. That's a very natural journey a lot of, you know, tech leaders take. Some do stay in the, you know, in the software development piece because they feel like people are too difficult. So it's a very interesting topic to unpack. So in the spirit of the show, Ramaz, what do you believe, as in what is your personal opinion, what is the most one thing which is most important for fostering tech growth?

Growth requires learning and being— having an open mind. And I think the number one thing to foster is the ability for people to say, I don't know, to fail without— and to show their less— like, their lack of knowledge without fear. If they have that, they'll be able to grow. If you don't have that, there's nowhere you can go.

So it's a growth mindset that's the first and foremost, isn't it? If you don't think of doing experiments and, you know, accept the failure and learn from it and move forward, you're unlikely going to see the growth, isn't it?

Yes. So, yeah, I mean, tech growth for me equals a growth mindset But if in order to have like to empower people to have this growth mindset and to foster this growth mindset, you have to allow them to fail and say, I don't know, it's not failing the same sense, but like having a safe environment where I can fail and say, I don't know, is the only requirement, almost only requirement, but like the most critical requirement for having a, for fostering a mindset of growth and hence have tech growth.

Okay. How do you foster such an environment, Ramit? What would be your, you know, go-to? Let's say you walk in a room, you know, or you hire as a coach, or, you know, you take a role, you know, you come in, you get to know your environment and you go like, well, that's not really a good environment, you know, for growth to happen. How do you build a plan to get that culture fixed?

Building a plan to get the culture fixed requires really understanding what's going on. But let's, let's start with the obvious things. Lead by example. Show that you are open to learning, that you don't know things and be, have a curious mind and show everyone that you are like them. There are things you don't know and you will ask for help. And when you fail, you will acknowledge the failure and you will say, it's okay to fail. That's the first thing any leader should do is to lead by example and really show the growth mindset that they have and be vulnerable and say, I don't know, or make mistakes and apologize for these mistakes and learn and move on. I think that's the number one thing in any situation a leader can do. And I think it's like the most basic thing because it doesn't need me. I don't need to know the people and what everything, the problems. I start with myself. I show hum— I am humble. I show vulnerability and I lead by example. Now, reasons why things might be difficult for having a growth mindset are going to be, I think there's countless, but they mostly would be around, in my experience, Ego and individualism. Um, I need to know everything if I'm gonna grow. I need— I— it's always I, I, I, I deliver. I need to be better. I need to deliver this into production myself so I can get promoted. I need to be great. When we have a team of superstars, nobody can show vulnerability. Nobody can take the price of not knowing or relying on someone else. But by fostering a team mindset where instead of saying I, we always talk about we, the team delivered, we deliver, the team is doing great. If you start using those pronouns instead of I or that person, like individuals, that creates an environment where, okay, I don't know, but I have my colleague who complements my skills and my knowledge, and together we will get things. That means together we would— so I don't know, but you will, you have my back, so we will work together, and I will learn from you and you will learn from me. So it comes a lot naturally this way. Um, I think that's the— I mean, thinking about it, uh, it's the main thing if you allow people to do that. That's well, uh, also having in place, um, processes and basically like allowing for time for people to learn. Like if we expect people to know everything already, there's no time for them to learn new things. Like if someone comes to me and say, I need to learn a little bit more about this framework because we're going to be needing it. I need some time like this sprint, so I cannot take all the stories. I want to have however the team plans their work, but I need a couple of hours, uh, week to learn something new, we should be open to that. We should allow them to do that. Or I think one of the mistakes some companies do is not giving time off for learning. Like, if an engineer comes and says, hey, I'm taking this course, it's going to take me a full day, I'd rather do it on my— during my daytime instead of doing it on my weekend. So would you allow me to go to this event where I'm going to learn something, or like this training? Or can I have an hour every day so I can complete a 5-hour training course, okay, where even if I'm not paying for them to— like, if I'm not paying their expenses, the least I can do is provide them the time off. And then that again says that the company wants you to learn and accepts the fact that you don't know things, and you're here to learn, and we benefit, and you benefit.

Okay, I love that. I really like that, the lead by example. I think it's is highly underestimated, especially by, you know, leaders in positions that, you know, they come from that position and what they actually show will get absorbed a lot more when compared to what they actually say, you know, uh, just in the meetings or in the emails. You know, showing that you, you know, you accept mistakes, that's, uh, that's a powerful one. I really strongly agree with that one. Um, you mentioned a few things which for me felt like, um It's like a coaching elements, like leading by example, you know, potentially, you know, showing how to deal with ego within the teams. And then you mentioned a few elements which are a little bit more like managerial elements, which is, you know, giving time off work, you know, to go and learn that because that's going to be a budget and, you know, and it's going to be like management of time. How do you see those being different, like coaching versus managing or coaching, you know, slash managing? Like, in your mind, are these one and the same, or are they, you know, two different things?

I wouldn't call it coaching necessarily, but I, I, I see your idea of separation, and I like that. I think we can talk about it more about people management and, and leadership, or, uh, yeah. Yeah, I would call it like tech because a tech leader only takes care of the logistics around work, like your time off. And yes, but a manager takes care of people more and the environment.

So, okay, so let's define it. What is people management?

People management, although the word says people and management, managers don't manage people. People manager manage the environment around people so that they can have the best place for them to grow. If the best place for them to grow is a place where it fosters growth mindset— I guess we agree on that already, but just in case— then that's what you need to do. If what you need— if what you— if what the company wants to create an environment, or if the team needs a different environment, that means different needs. So that's why it's called people management, but it's actually environment management for the sake of people, because I think a leader or a manager at any level— because the word manager sounds like, oh, it's like, that's a first-line manager— but like, at any level of management, at the end of the day, we are responsible. Like, the, the main mission we have is to deliver the right thing on the right time in the most efficient way. It sounds harsh, uh, very material, and— but it's actually, it's the hard truth. We're all here to make money. We make salary, the company makes money so that they can pay ourselves. We have to be part of the success in delivery. Okay, but— or let's say in a better way, and in order for us to deliver the right thing at the right time in the most efficient way, there's so many things we need to work on, which is we need the best people to do the things, and we need to give them the right tools and empowerment and Everything we can talk about, about fostering the right culture within tech and non-tech, like, so that the team can really deliver their best. And your most biggest lever, leverage we have, or like lever we can tune, is the environment where people work. We can't change— and technology comes and goes, we're going to make so many technical decisions, but if you don't have a team that can react to different changes and is product-minded because they have to think about the product, uh, and you cannot deliver the— you cannot deliver the right thing in the most efficient way. So people are a big part of how you deliver the right thing at the right time in the most efficient way. So that's why we need people managers in that sense.

So if we ask a question, what makes a good management team, or what makes a good you know, senior leadership team, which effectively, you know, you mentioned different environments, product mindset, which would be a product team. You have likely a tech team, you're likely going to have marketing team, maybe a sales team. So you're going to have different teams or departments within the organization. And, you know, you'll have some type of heads of leaders of these, of these departments. So if you think about that layer of, of, you know, senior leadership from your perspective, what are you saying? They should be managing the whole environment of the organization to make sure that what's being enabled is all towards the people being just better at their jobs. Is that— that's what I'm getting. Is there anything, um, strategic of how you will look at this? Like, if you, you know, you're part of this senior leadership management team, and, and let's say, you know, a, a very common challenge is that, you know, we're not getting things done in time, or, you know, we want to do 10 things, but we actually getting 5 things done, meaning that, you know, the velocity of getting things done is slower. You have these, these are like always on the table as challenges for, for leadership teams. Like, is there any go-to from your perspective of how you start thinking about how can we do things quicker, uh, in tech specifically? Like as a tech leadership?

Okay, I think there's two topics here that we need to, to address. When we say leadership team, it implies that this is a team. Now, one of the things that are hard is how can you get a bunch of people who have their own different lines of organizations and actually get them to work as a team. I think Patrick Lencioni coined the term first team, first team mindset, where as part of a leadership team, this is my first team. This is the team, the number one team for me, not the teams that I manage. The team that I put priority number one is the team of leaders. Now, that's something that's important. And when we say team, we say support, we say accountability, we say trust. And we say collaboration. So if we have a first team mindset within the leadership team, they would work together. Now, more often I've seen, and I've been part of a leadership team where we had this also a part of our dysfunction, is that how can we work together, especially when we're talking about that there's probably different functions. Like you said, you talked about the other different non-tech functions. I was part of a leadership team where I was tech. I was the tech head of, head of engineering, and there was a head of product and head of design, and we had to work together, and that was hard. How can we keep each other accountable without stepping on each other's toes and without feeling like, without any blame? And without, like, just the fact that if I, if I'm asked what, how many have you hired and what's your, like, where are you at your hiring, or where are you with the deliveries and not to feel as this is something like somebody is doing a, like they're trying to see if I'm doing right and they're going to blame me if I'm not. This is accountability between teammates. So we have to keep that. So if we have the different functions working together as a team and they have this mindset, it will take time for them for things to really work out, but that will improve by default Like, again, leadership by example. So if the leadership team is functioning well together and they are holding each other accountable, it will go— like, it will trickle down to their teams, which means it will improve, even by a little bit, the cross-team collaboration. The problem with cross-team collaboration is it's very costly because it requires orchestration of work, requires communication. And if I see my leadership team, like the people above me, not communicating between them, it's harder for me to take a step towards someone outside of my organization, of my team, and so on. So we start from the top, lead by example, like become a leadership team, work together. It will improve the rest of the communication, trickle down more or less. And at least when you demand something, you're not demanding it like, hey, I'm doing this and I ask you to do it like me. So yes, you are kind of, you're allowed, I mean, you're allowed to ask because if you're not doing it and you're asking everyone else to do it, it feels like, oh, that's someone who's not sincere. There's no credibility. So that's the one thing. So this, like, if leadership works as a team, they will work better regardless, um, and it will trickle down. The second topic about, uh, what you said is pace or speed of delivery. Now, I have a difficulty with speed. A lot of, a lot of managers consider like the pace of delivery or the sprint velocity, or like how much have we delivered, as an important metric for team performance. I personally don't think that's a good team metric, and here's why. The team will deliver— the delivery of the team will never be like on a straight line. There will always be fluctuations So many things. What's more important than how much have you delivered is how predictable our delivery is. Also take into consideration how— what kind of pace the business, like the baseline of the business, needs. And then we can build our expectations around those two things. Like, we need to be able to deliver fast. That's a good statement to start. And fast means we need to be able to deliver value value, not saying specific projects. Let's say every 2 weeks we need to have something new, or weekly we need to see something new, and our users need to see their progress happening weekly. That's a good beginning of a discussion. Now then, management comes and looks, okay, we need to make sure that our teams have sustainable delivery and that they can, uh, we can be reliable in sense that we ask, they deliver. And they always like— sorry, what we ask and they promise to deliver, they deliver. And that's the most important thing, reliability. Like, we can trust that they— if they say they deliver, they will deliver. Now, urgency and like, okay, now we need to deliver so many things, but does that fit with what we have agreed on? Does that fit with the current capacity of the teams? There are spikes that we're going to need to push because there's business needs, an important one, but most of the time, most of the deadlines are actually artificial. There's no hard deadline. It's rare. There are times where there are hard deadlines, where if we don't deliver feature A on Monday, next Monday, then we're dead. Okay, it's rare, but it happens. But most of the time, we want to be ahead of things. Like, we want to— by quarter, by next quarter, we need to have something delivered. And it doesn't have to be the perfect thing. It has to be like— I— we need to think incrementally. So We need to adapt the idea of, okay, business has so many needs, let's deliver everything as fast as possible, to what's a sustainable speed that allows teams to be reliable and without overdraining, uh, and what is really important, essential to be delivered on specific times. And we adapt everything together instead of saying we need fast and fast is the absolute value we're looking for, because that's not sustainable and doesn't take into position like the reality of things.

I, yeah, I buy into that. Um, how do you calculate the, the predictability of delivery? So for me, it feels a little bit like a maybe chicken and egg situation. So if I'm measuring my, say, sprint velocities, I have some type of numbers coming out and giving me on, you know, at the end giving me a predictability measure. So because I look at my fluctuations with the sprint, I have a median line in it. I can say that that's, that's as best as we can be about predicting our capabilities, you know, of getting things out in, in a stable manner. If you don't like measure velocity in any way, how, how do you, how do you start with that, you know, uh, being able to predict of, um how the team will perform effectively.

It is actually a chicken and egg kind of problem because, okay, if I don't know the pace they're delivering because every story is different, every feature is different, then how can I measure? And like, if they— and I— okay, if everything they promise they deliver, which is half of the statement of being reliable, then how that can— how, like, okay, Is that enough or not enough? So if they promise to deliver one feature, okay, how do I know that they couldn't have delivered more? So there's also the fact that I need to verify what they're saying and what they're doing. So, okay, there's no perfect solution, of course. Every context has different things. But one of the things I like to do is never ask— like, it's— you want every work to be value-add. Like when, when you break down, like let's go down like really at the developer level. So developers get like this feature and they create an epic in, let's take Jira because it's the thing I'm most familiar with, and then they create the epic and they create a bunch of stories that depend on each other or not, and then they can work on them and deliver some. If the story, if each story isn't, is like, or is sized differently and the, the— some stories have actual real value and some stories have preparation things. This is not real value, as in user doesn't see it. Then there's a disconnect between what we want to have, which is continuous value delivery, and, uh, work items that have various sizes, and it's hard to plan work around it. But if we take any epic or any idea, feature, opportunity, and break it down to as small as possible and have kind of standard-sized stories for developers, then we can really measure how many stories they complete. And we don't even have to measure how many stories they complete, it's how much value have they delivered. Every value is one, one value item. So by breaking down everything into more or less standard, standard size, then they keep delivering. And then what I want to know is the, that desired value that I want to have at users, have it reached the time they want. Instead of— we don't want to squeeze in as much speed and, and, and like output out of developers. It's the other way around. It's I need to have this amount of value out, and okay, what do I need to make sure that this team can deliver as fast, or I can deliver at this pace outside. So if they deliver at that pace, good, then we can have a discussion. Can they deliver more? We can try, we can adjust. So that's why it's a chicken egg, because you never— you start with an assumption and validate the assumption and keep going at it. Uh, never go into how many hours you spent a day coding, how many tickets can you deliver. How many story points can you deliver on a daily basis or on a weekly basis? The velocity thing in the sprint is very difficult to count, especially when you start to have people leaving, like on vacations. And you have to— again, every change you do to the team will break the whole thing. So that's, that's why don't look at the team, look at the whole tech org. Are they delivering at the pace we as a business expect, which is, let's say, 2 value items per week, whatever it is. And then you start and you validate and you start.

I like the concentration on the value rather than on any other thing, because, um, if you give developers space to create solutions, they will likely will want to code everything up themselves. You know, sometimes you potentially want to make a decision that, you know, you want to partner up, you know, buy versus build type of situation. You know, do you want to recreate something which already exists, or do you want to just bring in and integrate with the partner? Maybe there's open source package. Maybe we can solve this problem in totally different ways and have the same value as being put forward, but done a lot quicker with less, you know, leftover code liabilities. So I do like that, concentrating on what exactly we're doing, why we're doing this, what is the value, and what is the quickest ways of achieving that value. And then, you know, nitty-gritty bits about how can we get, you know, the velocity up and all of that, that's, uh, that's likely a different topic, right? So I like that. So one, one of the big challenges which is happening in the current market is, uh, cultural differences, um, and how you sort of, you know, get the team gelled well. So I'll give you context. So because, you know, with the remote work And especially in UK with the Brexit, you know, there's real lack of talent. So businesses are looking to offshore and they're looking to hire people, you know, in Europe, you know, Ukraine, Poland, Lithuania, very popular countries, Bulgaria as well, Romania as well. You know, they're looking in India, which it was always there. India was always there. South Africa as well. So suddenly, you know, you get these teams being put together where you have like frontend, backend discipline, they're all remotes, but they're very different culturally, right? The backgrounds are totally different culturally speaking. And these cultures, you know, they tend to clash. So from your perspective, do you have any approach how you sort of foster inclusivity in a diverse team? To get the team sort of, you know, working as a team, which you mentioned before, you know, that, that importance of the team being an actual team.

That's one of the topics that is very dear to my heart because I've been in a place where there was diversity but no inclusion in the sense that every— we had a lot of diversity, but the— you end up with a certain majority somehow. Of course, uh, and this majority dictates how everything should be. So as a diverse person— or another, let's not say diverse person, it's a bit, um, I was a different person, as a person with a different culture, different background, different attitude, not even just a different personality, uh, and I come into the office, if I don't act like the rest I'm on the outside. If I act like Ben Sharf, then I'm accepted inside. And that's where inclusive is— like, this is why we need inclusion. So yes, the problem you're talking about is very real, um, especially within the remote, because there's always going to— I mean, unless the company is fully remote from day one, which is, I think, still remains to be rare, the most cases is there's a company that starts somewhere and there's a bunch of people who started in that company, and then they start to add more and they start to open up, and then you end up with a certain majority of people within the circles of the initial company. But then all the new people, either they come in and feel accepted or not, and it all starts again and again with the people managers and how they work within their teams. Uh, what I do for fostering that sort of inclusion is Again, you start by yourself, lead by example. You don't— okay, you act in a way that accepts others. So you never— you try to be sensitive to words. Sometimes you need to be sensitive to people, different people's needs. The classic things, someone who doesn't speak much, don't force them to speak. Make sure that they have what they need if they need to speak, but don't force them to speak up. Stupid examples like lunch breaks. Some people don't take lunch breaks because they like to eat later or they like to eat alone. So, okay, this is not much of a remote kind of situation, but it happens within companies when you have like— let's take France as an example. In France, lunch break is kind of like sacred. Everybody leaves at a certain time, everybody goes to eat together, and it's an event. You have this person who doesn't like to eat that sort of food or doesn't have the habit of eating or prefers to eat alone, not at their desk, but just in a quiet— because that's their quiet time. If they don't eat with a group, are they excluded? Like, when they go back, are they excluded or not? They probably are. So by accepting the differences and as a manager showing that you accept, you're setting the first step. Now It's hard if you have only one different person. It starts— it's because it has to start from the hiring and the beginning of when you're hiring. Are you hiring diversity? Because the more different people you have and the more different characters and different backgrounds, the more it's easier for people to feel part of that. Okay, this is diverse. But if you're hiring panel is looking at, we're hiring people like us, then you have different people that pass through, or as they go through the interviews, they learn from the very beginning, okay, if I want to get into this company, I need to tune my behaviors to match them. And as a candidate for a job, you're doing everything you can to get in. So you're in a position where, okay, I'm going to do whatever they need me to do to get in, unless I am quite aware that this is against my value, so I need to run away. But that's a different thing. Sometimes I just need to change some behaviors, which means I don't belong unless I look like the others and act like the others. So it starts from the hiring and how you onboard people to how you as a leader act and The more people you get in that are different from different backgrounds— again, diversity here is not only about gender, race, ecosystem— I don't know how to say this correctly— economic and social backgrounds. There's also different characters. I can give you, for example, I, when I'm Egyptian and I live in Finland and now I live in France, in every one of those three countries, and I lived like at least 8 years in each country, of the— I am different than everyone in this country, even in my home country where I grew up. I am different than the people around me. So if I— and I had to change always my behaviors to do that. And I'm really happy to see that the ideas of inclusion and diversity is being addressed these days because now I can go to work and feel, uh, oh, this is a place where I can be myself. And that makes the whole difference in my way of communication, in my relationships, in how much I am involved with the product in my team. So it's not, uh, I don't think it's, it's a, um, it's a nice-to-have. I think it's a must-have in order for us to grow as a team and deliver better. Again, to deliver the right thing in the right time, the most efficient way. Everybody should feel part of this.

Yep, I think it is a must. If you think about the teams and team dynamics, it's it will be very hard to generate trust and get the team gelled together if there's no inclusivity in a fairly diverse team. And that team will tend to dysfunction, or as you said very rightfully, there will be the majority which sort of pops out from that team, and, and it's going to be still very, you know, very less than the whole team. Yeah, so it is very important, and it starts with leadership. You're absolutely right, it's one of these lead by examples, set that element as a cultural thing, you know, don't tolerate behavior which is non-inclusive and reward the behavior which it is.

You have to be very clear on what we want. I think explicitly state that we are an exclusive team. Sorry, we are an inclusive team and we We don't tolerate this and this behavior and call out that behavior for the behavior, not the person. So call out, this behavior is not something we accept, and also call out the good behavior so we can build. Um, but if I'm gonna just go one back, one step, you were talking about teams gelling. It's not just about inclusion because even the same people from the backgrounds and everything would have difficulty really gelling, and that's by again, consciously taking action to build trust inside the team. I think building trust is the really the cornerstone of building a team is that if we trust each other, then we can be vulnerable with each other, then we can hold each other accountable. And I, again, I would like to address that the work of Patrick Lencioni on this, on the 5 dysfunctions of a team, and it is all like the first need of a team to be functional is building trust. So I think in order for us to take a team from a group of people into a real team that gels, like you mentioned, we start with trust. And trust, we can build on it by, okay, let's be vulnerable, and then we can hold each other accountable, and then we can work together and build everything else on top of that.

Yep, 100% agree, Ramit. And I mean, Patrick has a very good book, another book to mention, it's called The Ideal Team Player, which is probably, you know, anyone listening and thinking about the teams, it's a very good book to read of how you spot and how you hire and how you grow an ideal team player. And if you look at people individually and you ask a question, is this a person who is a team player? Because if you build a team from team players, you know, the only outcome you get is a very good team because everyone knows how to play a team. And when you hire, potentially you want to, you know, look at that skill. You know, it's sort of soft skill, but it's definitely, you know, coachable skill in this in a sense of understand that you're part of a team and there's things you can show or lead by example to show how the team is actually, you know, run by default. Because you mentioned about I in the very beginning, you said, you know, I do this, I do that. There's no I in the team, as cliché as it sounds. There's no I in the team, right?

I agree.

So, uh, okay, so moving on, um, um, I got one, uh, which is sort of like, uh, about Aligning goals, career expectations, goals with business priorities. This is a very, again, very common challenge, especially in the bigger organizations when you have different things happening. You know, people come in from— let's take an example, you know, as a, like a backend discipline. They go like, you know, I see myself being, you know, the best Python developer they can be. As a result, you know, I want to work in these type of projects, maybe, you know, big data projects, and the business goes like, look, you know, the next one year, like, we have nothing on big data, it's the same, we're thinking we're gonna push some other direction, you know, that by default becomes a problem, but you don't want to lose that person, you know, he's been with the business for a couple of years, and you want to give him a good environment to grow, like, how do you go about that challenge?

That's a difficult one, especially the specific case that you mentioned. It's difficult because we are facing it at a later stage where, like, then where we're supposed to actually be catching that. So if you have an engineer who is someone we'd like to really, really rely on and their aspirations or like growth path is not aligned with the company's Ah, that's a tough one. How can you convince them? So it's either they can switch a little bit or try to find some side project, but that doesn't, that doesn't fulfill their growth path and doesn't really bring value to the company other than keeping that person.

So it's too late then, Ramaz, isn't it? Just like, you know, as a manager, you know, you dropped the ball over here, right? You should have spotted that sort of need coming much, much sooner. So let's take a step back. Let's say we did that. Let's say we spot that just in time. How do you go about spotting this? Is that, you know, some type of, you know, once a quarter, once half a year, once a year type of let's talk about your goals. Let's set your goals in the beginning of year. Like, do you have a framework of how you you know, tend to spot these things.

What's the number one tool people managers have for managing the environment?

Asking questions.

It's time, right? Time. And time specifically spent in one-on-ones. That's the number. Of course, asking questions is the right way to go through the one-on-ones, but even before even talking about asking questions, dedicate one-on-one time. And this one-on-one time isn't about, okay, where are you on Project A or Project B? Like, it's about the individual and what their career aspirations are, what their performance is, feedback, everything about the person. I always like to start my one-on-ones regardless of what the agenda we have prepared. What's on your mind? Because you need to give them space to talk about what's on their mind. So when I had small teams, I always tried to— small as in up to 6 or 7 people— I would dedicate 1 hour weekly for each report. We don't have to use it all, but if they need to talk about things, because they need to have unstructured time so that they can speak their mind out without feeling, oh, we only have 5 minutes left, then I can skip this for later. So what's on your mind? And they start talking. And what else? And what else? And what's important for you? And as they go, they don't know they want— like, especially like when they start thinking, okay, I want to do more AI, for example. That's a hot thing today. So if you have this kind of discussion and unstructured time where they talk about what's on their mind, they'll start telling you, oh, this looks like interesting. I'm looking— I really want to look into it. And then Okay, now this person has been talking about this for a couple of weeks now. Let's be clear that this company is not doing AI. We have a very clear product vision that AI is not part of. So I need to be clear with that person about it. Now that person can decide that, no, this is where I want to go and it's done. There's— that's a conflict of interest, kind of. So we're going to have to part ways at some point, but let's make the best until this happens. Because the fact is Everybody will leave it someday, but the whole point is how can you get them to stay the longest while they're most productive and most happy. So it's that early so that it doesn't become, oh, I— if I don't do AI now, I'm done. So they can— maybe we're lucky and they will find something, and maybe over time we change the company's direction, we might want to include some AI project, but at least it's clear enough from the beginning so that we can accommodate each other. I think that's how you prevent yourself from being at the point where I need to do AI project now or else I'm leaving.

Okay, you mentioned 7 or so reports. Um, what if you have— what if you are a manager of managers? So let's say you have, you know, 7 reports which are, you know, developer managers. They have their own 7 reports. So you have, you know, you have these levels of levels which you still need to get that information. And is that Does that come back again to lead by example? You have your own one-to-ones with your, you know, developer managers and you talk with them about their career expectations and you go like, hey, can you make sure you talk with your own guys and, and feed back into me? I was like, so effectively the question is that does anything change if you are manager of managers?

It does change, and I used to think that it shouldn't or it should change in a subtle way, but it actually does change drastically. And here's why. So when I first stepped into a manager of manager role, I had a few ideas of like how I want to do people management and how I do the one-on-ones. And I started imposing my way, or kind of say, I expect you to do like one-on-ones that last like at least weekly and an hour around. And I started saying how how I expect them to do things. But that's micromanagement almost, because I'm telling them what to do. As a manager of managers, I need to take a step back from the details and set expectations. So my expectation is that you address career, like have career discussions, address their tech growth, their personal growth, their career options at the company, how they want to grow. You also address the lack of skills and the, like, how they, like, what skills are missing in your team, uh, the well-being of everyone. They include, like, I need to set expectations that on the outcome, not expectation on how it's done. So there's this kind of fight inside me where I wanted to do things my way because I know this works, but I also want them to do it their way because that's the way they best do. And I need to really specify a good level of abstraction of on the outcome so that they can do. It doesn't mean that I will never ask, how are you doing it? Because by asking how are you doing it, I'm holding them accountable and I am giving us as manager and report a space for to grow together. Like I can learn from them and they can learn from me. So that's why, uh, so that's how it becomes different. But the real difference is instead of setting expectations on how things are done, you set expectations on the outcome you expect them basically on the why.

Yeah, that's a very strong one, and I did very similar mistake as well, looking back to it. Which leads me to my next question. So if you thinking about becoming a manager, right, is there a list where you feel almost like a mistake list, right? So, so let's say I'm an individual contributor, you know, I'm, I've been doing this for quite some time, I'm, you know, I'm a senior in the team, everybody comes to me with all the questions, you know, naturally some type of people management role opens up, maybe team lead, you know, maybe something more. The business will look at me and go like, you know, like, everyone's asking questions anyways, you know, you're the most senior in the team, you know, here's a, here's a, here's a role, here's a promotion. When that transition happened though, from, from writing code to leading people, that's, as I told you, you know, it's a different game. Like, it's, it's an absolutely different room. When people make that transition, like, do you have a list where, you know, most common mistakes or maybe most common misconceptions people presume or how they need to run that role and just some, some gotchas people should be looking if they're thinking about becoming a manager?

I don't have a list of mistakes, but I have a list of like a couple of advices that I would like to give to anyone who's considering. The first one might be also a cliché, but Management is not a promotion, it's a different career. Once you get into management, your focus is shifted away from technology and more into people. I'm not saying that you forget technology, but remember that very well, that you have new responsibilities now, different expectations on you. Your work, like, your success doesn't depend on you, it depends on your team more or less now. And I would even say that one of the advices I would even like, if I want to go like deeper into that and tell them, here's maybe something you can do is especially as soon as you transition into a leadership position within a team, some companies say it's 50/50, like individual contributor, 50% individual contributor, individual, and 50% people management. I'd say in your first 6 months, do as much as 80 or 90% people management, as much as you can. Of course, you're not gonna just like do useless things, but the more you can focus more on people, the better. Because you need to— I mean, you need to be in the middle where you do enough tech and you do enough people and like balance. But when you're beginning, you tend to go towards tech because that's where you are good at. So if you don't want— you want to not rely on tech at all to, to ensure that your team is delivering well, and rely more on everything else. There is people management. And then by doing the extreme of one side, you balance out a little bit. And then over time, you will be able— you will be much better at balance because you have a tendency to go tech. Now you're going to push yourself fully towards people, and then you will end up being balancing soon enough. So that's the first one, is remember that your work is more about people than— so don't rely to, like, to succeed, don't rely on yourself, rely on your team. The second thing about being a manager is, again, within the same context of my team, I deliver— like, my, my, my impact is not through me, it's through my team— is you're gonna have different people. Different, like this whole things we talked about, like about inclusion. And you need to be very much— how do I say it— uh, you're gonna listen, listen more than do anything. You're not managing people, you're managing the environment. So everything we've talked about, so it means you need to listen more to see what's going on and remember what was good Like, what, what, what are the things that you really wanted your manager to do and never did? And start experimenting. I'm not saying do them, but experiment with those. For example, in some teams, managers have always been like assigning work, and you've always— I always wanted to take something and do— okay, now you have a chance to try something different. Think about it, bring it up with your team, and maybe let them choose what works, what things they want to work on. And see, because this is something you always wanted. So use your past experience as a manager to improve, to experiment. And you're not doing things alone, this is a team, so work with your team. I think these are the 2 or 3, uh, change in mindset that you want to do.

How important do you feel feedback is in this process, as in feedback from, from your um, from your own manager. So even if you step in that role, you're still going to be reporting to someone. And I feel like seeking out feedback, or maybe from your team, or maybe from, you know, from your line manager, whoever is talking with you, just going like, how am I doing? You know, can I do something else? You know, this is what I'm thinking, is that a good idea? Do you feel like that feedback loop is, is positive, or that maybe potentially can be Negative in a sense that, you know, you're showing that you don't really know what you're doing in some areas.

Well, thank you for bringing that up because sometimes I get focused on things and I forget the basic stuff. I think feedback is very, very important. But like everything else, a tool is just a tool. If you don't know how to use it, it might do more harm than good. And the problem with feedback, it's not if you know how to use feedback as a tool, But everyone using that tool should be, of course. Now you're a people manager. Now you should be, or have some leadership role. You should be smarter than others, or smarter at using this tool. So you, if someone uses the tool bad, you should be able to spot that and adjust and help them, because feedback is critical for growth. That's the point. Um, okay, so it is, but ask feedback not just from your managers, but from Everyone, 360, go everyone ask feedback from the most junior people to the most senior people. Actually, don't go and ask, build a place where feedback is given, not asked for. I think that's like top on feedback is where everybody keeps giving feedback to everyone. And start by learning how to give feedback, do the lead by example, give feedback and ask for feedback so that they can get used to it. And then start making it possible, empower them, making it safe for them to give feedback, and feedback will just flow. Well, just flow is a bit of an exaggeration, but yeah, it will come.

Yeah, people always have opinions to share if you come out and, you know, give a forum and ask good questions. So, you know, feedback will come, and it's always— not always, but it's very often something you don't think about, you know, because everyone's different and everyone has opinions. And the more diverse opinions you can source, as in, in a sense of, of a feedback for any challenge you're trying to, you know, tackle, it's just going to be a good data point to think about. And I really liked what you said about, you know, um, uh, that, that beginning. And I remember a quote which I, I use myself, is it's not, it's not how but it's who, which, which allows to sort of think about that delegation piece. Because when you make that, you know, you, when you make that transition from individual contributor to, to management, you know, you still, you know, as you said, you lean towards doing things yourself. And, and, and that 50/50 or 80/20 or whatever is your balance, if anytime you have a situation, if you're going to ask a question, not how 'But who?' That sort of puts you in a mind frame where you go like, okay, who can solve this for me? It's not me. I don't want to think about how I will solve this. I want to think about who could solve that for me. So it's all sort of, you know, helps to make that transition that it's not about what you can do, it's about how you get from the team and what they can do. Okay, so that, that, that's a good tackle on that one. Um, I got one which is, um I lost my question now. So it's, um, um, it's how you balance, um, it's how you balance the, the, your management and leadership skills and not getting or not falling off the cliff on your technical skill, right? So I had that, I had that struggle for, I don't know, maybe 2 years or so when I went into management. I really didn't want to lose, you know, the buildup of me knowing the tech, which, which was like 10 to 15 years, you know, backends, frontends, and DevOps and all of the shebangs. And when I went into management, what you rightly said, it's a different career. So suddenly you become a very new, uh, you know, pretty much a noob in management. So it's, you know, it's so much to learn and everything you're doing is seems like a mistake. And then you have all of this, what, you know, made you good on the other side, and it's very, you know, hard to say goodbye to it. How do you like managing, you know, to, to get better at leadership and management, but at the same time not, not really fully forgetting the tech, but still keeping, you know, in sync of what's new, you know, how you use that technology and all that stuff? Like, do you have your own ways of doing that?

Uh, that's a very tough thing, uh, and I haven't been good at it myself. Um, so I don't know if what I'm gonna say makes sense or not. It's— I'm trying, I'm trying to make sense out of it myself at the moment. So yeah, go for it. Yeah, as I got away from tech and more into leadership, in the first— like being a line man, like the first line manager where you are working with ICs directly, you, you are still involved. You're taking your part of the work. And even if the team goes a little bit bigger, you're involved in a lot of things. So it's easy. It's when you start leading more than one team or mainly managers where you start to be less involved in the day-to-day. And at some point I actually found myself way behind. And my definition of way behind is, can I go back and work as an individual contributor with the knowledge and skills that I have right now? And I discovered that I can't. Like, if I'm going to go now and go back to a— I don't think I'm going to even work as a senior engineer anymore. Like, my level is that I can still pick up a lot of things, but I'm so behind on so many things. So what— especially that I was from the DevOps side, and then I moved into the managing product team, so I lost sight a little bit of all the details of the DevOps and infra. So now I can't. And does it— but what I ask myself is, if I have chosen the path of leadership, I need to remain technically relevant, but I don't need to be the one making decisions. So my approach today with that is every technical decision is being made is being written down and shared. And like always in my organizations, I always push for that, that I want to have RF, like RFC style, where you propose, like you write a design document, people comment on it, and then there's a decision made. So I read all of that and I have technical discussions, uh, formal and informal, and that's how I remain relevant and remain I keep my technical muscles working so that I can differentiate when what's good and what's bad, and I can tell this is the right direction, this is bad, and know when I don't know about it so I can actually get other people's help. I think it's like, as if you, if you decide to just go one step above a manager of 4 or 5 engineers that you're working with them, then you have to make the hard decision whether like, what does technically relevant mean instead of how good am I technically? I don't know, at least for me. I know for some people, like going, like some people who can just go at any point and write code again, it, for, for some, this was never me. And I know that I can't go and do it. And when I try to do like side projects, I struggle a little bit, but I'm, I've made my peace with that. And I think I want to remain technically relevant so I can have discussions around architecture, learn the new things happening. Learn every decision being made. So I also increased my— the amount of things I know, uh, without having to be able to go and do code reviews or like start coding myself.

I like that. Yeah, you, you become a lot more conceptual, uh, rather than the deep, you know, deep dive type of technical knowledge. You, you know why you use the tech, you know why the decision was done, you know, you have some potential requirements of value you want to get out of that, and that that relevance, you know, it's always shrinking. So being able to go back to your team and actually ask the good questions and sort of dig if you need to. But yeah, you need to say goodbye to an actual— because otherwise you're just half-assing, you know, both domains. Like, you're not going to be a good coder, you're not going to be a good manager if you're trying to sort of 50-50 balance this. And if you chose to be, you know, to lead people, like, just learn that discipline well and do that very, very well. And that, that is, you know, that, that's your history, right? That, that's something you left behind. So I want to talk a little bit, Ramis, about creating change, because I feel like when people come into that management position, like, that's just going to be one of the first things that they will be challenged with. You know, they will be sitting, they will be looking at things, and they will be like, I want to change that part. You know, I want to change that there. I want to you know, restructure the team or whatever is that change. At that point in time, there's going to be— how do you communicate this, you know, to your team, you know, to the business and to all the stakeholders so you actually get a good buy-in and everybody's on board with what you want to do?

Making change and how do you bring change, that's a sales job.

Okay.

At least that's how I try to see it now. I used to think that, oh, there's change to be done. Let's just show the merits of things. And sometimes that has worked for me and sometimes it didn't. But making change, getting buy-in requires emotions and managing and some good level of emotional intelligence so you can build trust with people who don't work with you on a daily basis and address their fears and their aspirations so that they can accept what you're saying and so much more. And I've been reading a lot about sales recently just to learn about this and negotiation. I've brought in change in some organizations I worked at. And when it was a change I'm doing in my organization directly, I needed to bring everyone— like, I always did this, uh, RFC approach. So here's what I think we should do, and this is why I chose this and that, and this is why I'm doing this, and here's a document that explains everything. Feel free to comment and say everything you want, and I'm open and accept every change you make. And I actually open, say, this is a collaborative document, just edit there. You don't have to leave comments, just edit. We can find everything in the history, it's fine. So people tend to look at that in a way, okay, so it's not a final decision, it's not something imposed, it's not something rigid. Let's talk about it. It allows them to get into it. And same thing with peers or with like managers, like your seniors. If they feel that you're coming in with the solution, I think they tend to trust you less unless you really have already established a lot of trust before. But if you only rely on trust, you're eating up from your reserves. So you have to be very clear about like, okay, this is what I think should bring the best result and it's a collaborative thing. Tell me what you think. They get into it. And you start talking and talking. I think communication is the only way to get buy-in. Now, I'm not that great at buying. I've been able to do some changes, especially when it comes to my organization, when I want to do things and I talk to others. Uh, I don't have a framework for getting buy-in or selling ideas. I really hope— I really wish I was better at that, but I'm good at observing coming up with what change is really needed and how it addresses the problem I've seen. So I think I've honed it a bit, my skills, especially with coaching as well, because coaching really, really taught me how to be more observant and have an eye for things. And so I can really figure out what's wrong or what I think is wrong. And this is where I start. I think is wrong is this, and I think and I have a good feeling, intuition maybe sometimes, that if we take this road, we're going to get a better approach. And then you either get like full resistance, or, and then you have to work through it, or you have to figure out if there's emotion, like what kind of emotions are involved. I think there's a lot of emotional intelligence involved in that.

Yeah, I mean, you said it is a sales job, so You know, correct me up a little bit, but it is because at the end of the day you're selling a vision and people might not see as you see, especially if it's a very contextual vision. So if it's like techno technology domain vision, they will not understand, you know, the details within your vision as good as you are because that's your vision, especially non-technical people. So you have to sell it. Like you want it or not, that's going to be a sales process. What is going to be a process of influence? You know, how many, how many buy-ins you get at the table? You know, how many people can you influence, you know, before you even put that vision forward? So that's definitely a very salesy operation in a sense. So you mentioned resistance, like when you put that forward, you know, you're going to get either this is great, let's go ahead and do that, or you're going to get like, I don't like it, right? So, as I come back to our tech leadership positions, so let's say you are a fresh team manager, team lead, and you go like, I want to do this thing, and then you get that resistance from within the team, you know, maybe half or maybe just couple or maybe one, but you know, a team superstar goes out and goes like, I don't think so. So you get that pushback. Is there ways how you, how you deal with that situation?

Yeah, so I actually had that situation. Uh, I just joined the company, um, and I wanted to make things more asynchronous where enough of the— like, every time we make a decision, we like get 8 people in a room and brainstorm. No, let's create— let's address it by, okay, for every stream of work, there's an owner and the owner has to, uh, make things, make things happen in a way. So, okay, here's a new epic to work on. So here's the owner. The owner creates a design document to explain, or ask someone to create. But again, so there's a bit of project management. So that's more work for developers. Most, like, a lot of developers don't really like doing that sort of project management. But then, uh, after we've written everything down, we start breaking— like, that owner has to make sure it's broken down into work items in Jira and so on. Now immediately everybody says, oh, but that— where— how can we make sure that there's consensus if we— like, not everyone is good at writing, not everyone is good at commenting? Well, I know that's hard, but let's look at what's, what's good about it. And I think what the most— the thing that helped me the most in, uh, softening the resistance is, hey, this is step one, this is phase one. We tried this change. If it doesn't work, let's give it X amount of time, let's try it out. And if we think that this doesn't solve the problem that we— that's clearly— so any design document starts with what? Problem definition. So that's where my— also again, my document started with, here's the problem, here's how the symptoms of the problem. Here is the cause of the problem. This is why I'm creating this framework of work. So we have clear— we don't have metrics necessarily to measure things, but we have a clear problem statement and a clear desired output. And within the, like, after a month, we're going to review, is that getting us any closer? And all I want from you today is not say yes, we're going to do that. It's a vote of confidence. Like, this looks like a good approach to get us to where we want. And then we iterate. And then maybe phase 2, we do something else. It's going to be an evolving thing. I think having this approach where it's an offer for us to take a different direction, and we are all into it, and then we will all be evaluating, and it's not a decision and I'm pushing you to do things that you don't like. No, you have a say in every step of the way. And if we don't like what we've done, in a month from now, we can scrap it and try something new. Together we want to get in a better place. I think that helped a lot. So even like, how can you get people to disagree but commit? Is that they know that if, if I can prove myself right later and like, okay, I disagreed but committed, but now we should try the difference, and now you should disagree and commit. It gets them to really, uh, buy in. Well, not necessarily buy in, but at least join the wagon. And that is a very good step forward.

It's a consensus-reaching exercise, isn't it? It's like, this is what I think, but I need the majority, you know, in the room to be on the same page. And it becomes almost like, let's meet in the middle, you know. What exactly don't you like about, you know, this proposal? How do you think you can do this better? This becomes just conversation until you almost negotiate, you know, the division, which is, you know, you get majority buy-ins to move forward. Yeah, I can—

one developer during that time when we were doing this, and like how I was like trying to get people to accept to disagree but commit, and she told me, this isn't— we are used to working with consensus. What you're bringing here breaks that. And we talk everything, and at the end we come up to, okay, this is not consensus building. This is consenting. We want people to consent to doing things even though they don't agree with. So it's, again, it's around what Amazon says, like, use the, like, this disagree but commit. So if, I mean, if you disagree, then you're, this is not consensus. Say, I don't like it, but let's agree to disagree and I'll just do what you want. And that's not consensus, that's consentment, where I don't like it, but I'm going to do it because I consent. To do it.

Do you feel like in these situations, if the decision is wrong, people go like, haha, I told you so. Like, it just comes back like, I knew it's a bad idea type of conversations. If they are, you know, sort of forced to consent.

Nobody should be forced. Yep.

Okay. Not forced. Yeah. That's a strong word.

But it can come back and say, ah, I told you so.

You so.

Well, as a leader and leading by example, I should accept the fact that I was mistaken. And yes, you told me so, and I thought that, and I, what, with whatever information I had, I made a wrong decision. And thank you for supporting me even though you knew it was wrong. Now let's find another way that takes us somewhere else. And I think next time there will be less of, haha, I told you so, and yeah, oh, we didn't take the right, let's, let's find a better approach. And Again, lead by example and get people to work with you.

What you just said is so strong, Ramiz, and, you know, people should use that all the time. Like that ability to come out and go like, yes, I raised my hand, you know, that was a bad idea, you know, we did a mistake. That goes so long in the sense of building trust with the team and getting all of these, haha, I told you so, you know, behind you, 100%. So I got one which is theoretical situation. I never been really part of it myself, but let's say you have built a culture which is very accepting of change. So it's very, very fast-moving, very fast-paced culture, you know, very innovative culture. So when anything comes in, you know, here's a new idea, here's a new idea, great, let's take it, let's do it, let's take it, let's do it. So you think, you know, you have things moving forward very quickly. How do you, um, balance, uh, stability of the systems and, you know, technological sort of decisions and infrastructure decisions with that speed of change? Like, because effectively, if you have way too much things getting changed very, very quickly at some point things gonna break, right? Like either technical debt is getting built up or, or something's not going to get seen and, and, you know, you're sort of gonna shoot yourself in the foot. And so how do you like balance those two?

There's two approaches I would take here. First one is it's more of a book, it's, it's more of a culture thing. So you want everyone to be really connected to the product. So when they're making or architectural decision in every step. They know the— what the product really needs and how the product would look like in 6 months from today, or at least our vision for it. Everything changes, but again, we have an idea of when we're building this that in 6 months it would look like that. So it helps us make better decisions. And for that to happen, everyone needs to be really product-minded, and I think that's a must-have. Now that's fluffy and culture thing and you want to have it, but then, okay, what's more concrete? Um, one of the things— again, this is an idea, not necessarily something very strong from my side— uh, it's all about stability and quality. So when you build things that change a lot, you need to allow for this, the stability. And at some point, you need to know at what— like, you need to create this maturity metrics where at this point in time when we say decide that this system needs to be at this maturity, we have the definition of quality and maturity. Like a system that we've never— like a system where we're still building like from scratch probably has zero quality and maturity in it. So we start from first level, which has minimum requirements. And then once we've stabilized this, again, we need to describe again what every level of maturity means. So systems that change a lot remain in maturity 1, systems that start to stabilize put in maturity 2. And a good— I think a good exercise to understand the state of things today and when building up this maturity metrics is, is using the Wardley mapping, uh, where you start drawing like on two axes, the, uh, it like as closer you get like what systems are very close to, uh, users and which system are more like far from user which are hidden, and which ones are novelty and which ones are stable things. And you start mapping them, and you can figure out from Wardley mapping which system should be more mature at this level. And you can start to get an idea. And by applying this model to your services and systems and components, even sometimes even parts of your monoliths could be treated in the same way, is this part has this amount of of quality and insurance or assurance we want. So here's the minimum level of work we do. And this has— this model and this idea has to be built not just by tech people, it's by tech and product, because product has to be on board. Because when you— when devs come and say, okay, now this, according to our understanding of the system, this compo— this service here needs to be a maturity level 2, and today we're far we need to spend time and stabilize it. Otherwise, we're risking outcome— like, we're risking things with users, and which means business is impacted. So that's— so we need to align on these things so that when we say, oh, this system is maturity 2, product understands that maturity 2 needs to be more. And why is it maturity 2? It's because it is closer to users, or because now we need to stabilize things because we need to build things on top. You can't build things on top if it keeps changing all the time. So you're gonna have to spend more time maturing this one, and then you can move on. And by having this alignment between product and tech and the clear maturity levels, you can try to address some of that. But again, life happens, and especially in startups, things can just break. And again, accept that things can break and accept that we need to move fast. And don't get attached to code, get attached to outcome and value for users.

Okay, yeah, I like the maturity, um, system maturity measures, or I don't know how you call it exactly, but giving, uh, giving a flag where you are, you know, riskier is, uh, is a very healthy exercise because then you can treat those areas in the different ways. And if you, if you're moving very quickly— so in the industry I work, which is, you know, I, I, I— online gambling, which is very highly regulated industry, so So every time you make a release ticket, it needs to go through a certain regulator. So the speed of release is actually outside of your control to some extent in some jurisdictions. So when you do release tickets, like you have to specify a risk around that release, right? And you think about that risk in a way of impact and probability. So you go like, you know, how likely that this will cause some issues, you know, that usually goes back to what you're changing, the code change, code change set size. And the impact is basically if something happens, like, what's the impact? You know, how much of, like, systems— like, will payment fail? Will, you know, playing games fail? You know, or whatever is the impact. So when you think about that risk, you always think about where I'm making release, into which service I'm making release, you know, which components and modules am I changing. And if you have that maturity matrix, let's say, you know, it's very easy to judge your risk around that. You go like, okay, well, I'm making changes in the very shaky areas of our system. So my risk should probably be quite high, right? In a sense of, and then you start thinking, okay, well, if the risk is high, how can I take it low? You know, can I maybe split that release in a couple of releases? You know, like maybe I need to run extra tests, you know. It's like that, it forces you to think differently. So that's a very good shout out, I like that. Right, so one question, last question, Ramiz, um, is there anyone in your network, uh, which you think would be a good guest for the show?

Oh, I think a lot of people would be great guests.

Yeah, just do some name dropping if you can, uh, anyone you would like to invite to the show.

I would invite, uh, my friend Monica Giambito.

All right, Monica. What does Monica do?

Monica is a tech leader. She worked in startups and scale-ups, and she, she— I think she was one of those leaders that managed to remain very technical as well as taking care of people, uh, and I think she also has a very good knack for, for leading organizations to success. Um, so that's why I would really suggest.

Okay, let's see if we can get Monica on. So thanks for doing this, Ramiz.

Hopefully— thank you.

Yeah, hopefully it was pleasant. I think we touched very good topics and the information for the listeners is going to be all awesome.

I enjoyed it and I hope the listeners enjoy it as well.

All right, thank you.