How do you build a culture of engineering metrics that drives real impact? Engineering teams often struggle with inefficiencies — high work-in-progress, unpredictable cycle times, and slow shipping. But what if the right metrics could change that?
In this episode of the groCTO by Typo Podcast, host Kovid Batra speaks with Mario Viktorov Mechoulam, Senior Engineering Manager at Contentsquare, about how to establish a data-driven engineering culture using effective metrics. From overcoming cultural resistance to getting executive buy-in, Mario shares his insights on making metrics work for your team.
✅ Why Metrics Matter: How the lack of metrics creates inefficiencies & frustrations in tech teams.
✅ Building a Metrics-Driven Culture: The five key steps — observability, accountability, understanding, discussions, and agreements.
✅ Overcoming Resistance: How to tackle biases, cultural pushback, and skepticism around metrics.
✅ Practical Tips for Engineering Managers: Early success indicators like reduced work-in-progress & improved predictability.
✅ Getting Executive Buy-In: How to align leadership on the value of engineering metrics.
✅ A Musician’s Path to Engineering Metrics: Mario’s unique journey from music to Lean & Toyota Production System-inspired engineering.
Kovid Batra: Hi, everyone. Welcome to the all new episode of groCTO by Typo. This is Kovid, your host. Today with us, we have a very special guest whom I found after stalking a lot of people on LinkedIn, but found him in my nearest circle. Uh, welcome, welcome to the show, Mario. Uh, Mario is a Senior Engineering Manager at Contentsquare and, uh, he is an engineering metrics enthusiast, and that’s where we connected. We talked a lot about it and I was sure that he’s the guy we should have on the podcast to talk about it. And that’s why we thought today’s topic should be something that is very close to Mario, which is setting metrics culture in the engineering teams. So once again, welcome, welcome to the show, Mario. It’s great to have you here.
Mario Viktorov Mechoulam: Thank you, Kovid. Pleasure is mine. I’m very happy to join this series.
Kovid Batra: Great. So Mario, I think before we get started, one quick question, so that we know you a little bit more. Uh, this is kind of a ritual we always have, so don’t get surprised by it. Uh, tell us something about yourself from your childhood or from your teenage that defines who you are today.
Mario Viktorov Mechoulam: Right. I think my, my, both of my parents are musicians and I played violin for a few years, um, also in the junior orchestra. I think this contact with music and with the orchestra in particular, uh, was very important to define who I am today because of teamwork and synchronicity. So, orchestras need to work together and need to have very, very good collaboration. So, this part stuck somewhere on the back of my brain. And teamwork and collaboration is something that defines me today and I value a lot in others as well.
Kovid Batra: That’s really interesting. That is one unique thing that I got to learn today. And I’m sure orchestra must have been fun.
Mario Viktorov Mechoulam: Yes.
Kovid Batra: Do you do that, uh, even today?
Mario Viktorov Mechoulam: Uh, no, no, unfortunately I’m, I’m like the black sheep of my family because I, once I discovered computers and switched to that, um, I have not looked back. Uh, some days I regret it a bit, uh, but this new adventure, this journey that I’m going through, um, I don’t think it’s, it’s irreplaceable. So I’m, I’m happy with what I’m doing.
Kovid Batra: Great! Thank you for sharing this. Uh, moving on, uh, to our main section, which is setting a culture of metrics in engineering teams. I think a very known topic, a very difficult to do thing, but I think we’ll address the elephant in the room today because we have an expert here with us today. So Mario, I think I’ll, I’ll start with this. Uh, sorry to say this, but, uh, this looks like a boring topic to a lot of engineering teams, right? People are not immediately aligned towards having metrics and measurement and people looking at what they’re doing. And of course, there are biases around it. It’s a good practice. It’s an ideal practice to have in high performing engineering teams. But what made you, uh, go behind this, uh, what excited you to go behind this?
Mario Viktorov Mechoulam: A very good question. And I agree that, uh, it’s not an easy topic. I think that, uh, what’s behind the metrics is around us, whether we like it or not. Efficiency, effectiveness, optimization, productivity. It’s, it’s in everything we do in the world. So, for example, even if you, if you go to the airport and you stay in a queue for your baggage check in, um, I’m sure there’s some metrics there, whether they track it or not, I don’t know. And, um, and I discovered in my, my university years, I had, uh, first contact with, uh, Toyota production system with Lean, how we call it in the West, and I discovered how there were, there were things that looked like, like magic that you could simply by observing and applying use to transform the landscape of organizations and the landscape systems. And I was very lucky to be in touch with this, uh, with this one professor who is, uh, uh, the Director of the Lean Institute in Spain. Um, and I was surprised to see how no matter how big the corporation, how powerful the people, how much money they have, there were inefficiencies everywhere. And in my eyes, it looks like a magic wand. Uh, you just, uh, weave it around and then you magically solve stuff that could not be solved, uh, no matter how much money you put on them. And this was, yeah, this stuck with me for quite some time, but I never realized until a few years into the industry that, that was not just for manufacturing, but, uh, lean and metrics, they’re around us and it’s our responsibility to seize it and to make them, to put them to good use.
Kovid Batra: Interesting. Interesting. So I think from here, I would love to know some of the things that you have encountered in your journey, um, as an engineering leader. Uh, when you start implementing or bringing this thought at first point in the teams, what’s their reaction? How do you deal with it? I know it’s an obvious question to ask because I have been dealing with a lot of teams, uh, while working at Typo, but I want to hear it from you firsthand. What’s the experience like? How do you bring it in? How do you motivate those people to actually come on board? So maybe if you have an example, if you have a story to tell us from there, please go ahead.
Mario Viktorov Mechoulam: Of course, of course. It’s not easy and I’ve made a lot of mistakes and one thing that I learned is that there is no fast track. It doesn’t matter if you know, if you know how to do it. If you’ve done it a hundred times, there’s no fast track. Most of the times it’s a slow grind and requires walking the path with people. I like to follow the, these steps. We start with observability, then accountability, then understanding, then discussions and finally agreements. Um, but of course, we cannot, we cannot, uh, uh, drop everything at, at, at, at once at the team because as you said, there are people who are generally wary of, of this, uh, because of, um, bad, bad practices, because of, um, unmet expectations, frustrations in the past. So indeed, um, I have, I have had to be very, very careful about it. So to me, the first thing is starting with observability, you need to be transparent with your intentions. And I think one, one key sentence that has helped me there is that trying to understand what are the things that people care about. Do you care about your customers? Do you care about how much focus time, how much quality focus time do you have? Do you care about the quality of what you ship? Do you care about the impact of what you ship? So if the answer to these questions is yes, and for the majority of engineers, and not only engineers, it’s, it’s yes, uh, then if you care about something, it might be smart to measure it. So that’s a, that’s a good first start. Um, then by asking questions about what are the pains or generating curiosity, like for example, where do you think we spend the most time when we are working to ship something? You can, uh, you can get to a point where the team agrees to have some observability, some metrics in place. So that’s the first step.
Uh, the second step is to generate accountability. And that is arguably harder. Why so? Because in my career, I’ve seen sometimes people, um, who think that these are management metrics. Um, and they are, so don’t get me wrong. I think management can put these metrics to good use, um, but this sends a message in that nobody else is responsible for them, and I disagree with this. I think that everybody is responsible. Of course, I’m ultimately responsible. So, what I do here is I try to help teams understand how they are accountable of this. So if it was me, then I get to decide how it really works, how they do the work, what tools they use, what process they use. This is boring. It’s boring for me, but it’s also boring and frustrating for the people. People might see this as micromanagement. I think it’s, uh, it’s much more intellectually interesting if you get to decide how you do the work. And this is how I connect the accountability so that we can get teams to accept that okay, these metrics that we see, they are a result of how we have decided to work together. The things, the practices, the habits that we do. And we can, we can influence them.
Kovid Batra: Totally. But the thing is, uh, when you say that everyone should be onboarded with this thought that it is not just for the management, for the engineering, what exactly, uh, are those action items that you plan that get this into the team as a culture? Because I, I feel, uh, I’ll touch this topic again when we move ahead, but when we talk about culture, it comes with a lot of aspects that you can, you can not just define, uh, in two days or three days or five days of time. There is a mindset that already exists and everything that you add on top of it comes only or fits only if it aligns with that because changing culture is a hard thing, right? So when you say that people usually feel that these are management metrics, somehow I feel that this is part of the culture. But when you bring it, when you bring it in a way that everyone is accountable, bringing that change into the mindset is, is, is a little hard, I feel. So what exactly do you do there is what I want to understand from you.
Mario Viktorov Mechoulam: Sure. Um, so just, just to be, to be clear, at the point where you introduce this observability and accountability, it’s not, it’s not part of the culture yet. I think this is the, like, putting the foot on the door, uh, to get people to start, um, to start looking at these, using these and eventually they become a culture, but way, way later down the line.
Kovid Batra: Got it, got it. Yeah.
Mario Viktorov Mechoulam: Another thing is that culture takes, takes a lot of time. It’s, uh, um, how can we say? Um, organic adoption is very slow. And after organic adoption, you eventually get a shifting culture. Um, so I was talking to somebody a few weeks back, and they were telling me a senior leader for one of another company, and they were telling me that it took a good 3–4 years to roll out metrics in a company. And even then, they did not have all the levels of adoption, all the cultural changes everywhere in all the layers that they wanted to. Um, so, so this, there’s no fast track. This, this takes time. And when you say that, uh, people are wary about metrics or people think that manage, this is management metrics when they, when, when you say this is part of culture, it’s true. And it comes maybe from a place where people have been kept out of it, or where they have seen that metrics have been misused to do precisely micromanagement, right?
Kovid Batra: Right.
Mario Viktorov Mechoulam: So, yeah, people feel like, oh, with this, my work is going to be scrutinized. Perhaps I’m going to have to cut corners. I’m going to be forced to cut corners. I will have less satisfaction in the work we do. So, so we need to break that, um, to change the culture. We need to break the existing culture and that, that takes time. Um, so for me, this is just the first step. Uh, just the first step to, um, to make people feel responsible, because at the end of the day, um, every, every team costs some, some, some budget, right, to the company. So for an average sized team, we might be talking $1 million, depending on where you’re located, of course. But $1 million per year. So, of course, this, each of these teams, they need to make $1 million in, uh, in impact to at least break even, but we need more. Um, how do we do that? So two things. First, you need, you need to track the impact of the work you do. So that already tells you that if we care about this, there is a metric that we have to incorporate. We have to track the impact, the effect that the work we ship has in the product. But then the second, second thing is to be able to correlate this, um, to correlate what we ship with the impact that we see. And, and there is a very, very, uh, narrow window to do that. You cannot start working on something and then ship it three years later and say, Oh, I had this impact. No, in three years, landscape changed a lot, right? So we need to be quicker in shipping and we need to be tracking what we ship. Therefore, um, measuring lead time, for example, or cycle time becomes one of the highest expressions of being agile, for example.
Kovid Batra: Got it.
Mario Viktorov Mechoulam: So it’s, it’s through these, uh, constant repetition and helping people see how the way they do work, how, whether they track or not, and can improve or not, um, has repercussions in the customer. Um, it’s, it’s the way to start, uh, introducing this, this, uh, this metric concept and eventually helping shift the culture.
Kovid Batra: So is, let’s say cycle time for, for that matter, uh, is, is a metric that is generally applicable in every situation and we can start introducing it at, at the first step and then maybe explore more and, uh, go for some specifics or cycle time is specific to a situation in itself?
Mario Viktorov Mechoulam: I think cycle time is one of these beautiful metrics that you can apply everywhere. Uh, normally you see it applied on the teams. To do, doing, done. But, uh, what I like is that you can apply it, um, everywhere. So you can apply it, um, across teams, you can apply, apply it at line level, you can even apply it at company level. Um, which is not done often. And I think this is, this is a problem. But applying it outside of teams, it’s definitely part of the cultural change. Um, I’ve seen that the focus is often on teams. There’s a lot of focus in optimizing teams, but when you look at the whole picture, um, there are many other places that present opportunities for optimization, and one way to do that is to start, to start measuring.
Kovid Batra: Mario, did you get a chance where you could see, uh, or compare basically, uh, teams or organizations where people are using engineering metrics, and let’s say, a team which doesn’t use engineering metrics? How does the value delivery in these systems, uh, vary, and to what extent, basically?
Mario Viktorov Mechoulam: Let me preface that. Um, metrics are just a cornerstone, but they don’t guarantee that you’d do better or worse than the teams that don’t apply them. However, it’s, it’s very hard, uh, sometimes to know whether you’re doing good or bad if you don’t have something measurable, um, to, to do that. What I’ve seen is much more frustration generally in teams that do not have metrics. But because not having them, uh, forces them into some bad habits. One of the typical things that I, that I see when I join a team or do a Gemba Walk, uh, on some of the teams that are not using engineering metrics, is high work in progress. We’re talking 30+ things are ongoing for a team of five engineers. This means that on average, everybody’s doing 5–6 things at the same time. A lot of context switching, a lot of multitasking, a lot of frustration and leading to things taking months to ship instead of days. Of course, as I said, we can have teams that are doing great without this, but, um, if you’re already doing this, I think just adding the metric to validate it is a very small price to pay. And even if you’re doing great, this can start to change in any moment because of changes in the team composition, changes in the domain, changes in the company, changes in the process that is top-down. So it’s, uh, normally it’s, it’s, it’s very safe to have the metrics to be able to identify this type of drift, this type of degradation as soon as they happen. What I’ve seen also with teams that do have metric adoption is first this eventual cultural change, but then in general, uh, one thing that they do is that they keep, um, they keep the pieces of work small, they limit the work in progress and they are very, very much on top of the results on a regular basis and discussing these results. Um, so this is where we can continue with the, uh, cultural change.
Uh, so after we have, uh, accountability, uh, the next thing, step is understanding. So helping people through documentation, but also through coaching, understand how the choices that we make, the decisions, the events, produce the results that we see for which we’re responsible. And after that, fostering discussion for which you need to have trust, because here we don’t want blaming. We don’t want comparing teams. We want to understand what happened, what led to this. And then, with these discussions, see what can we do to prevent these things. Um, which leads to agreement. So doing this circle, closing the circle, doing it constantly, creates habits. Habits create continuous improvement, continuous learning. And at a certain point, you have the feeling that the team already understands the concepts and is able to work autonomously on this. And this is the moment where you delegate responsibility, um, of this and of the execution as well. And you have created, you have changed a bit the culture in one team.
Kovid Batra: Makes sense. What else does it take, uh, to actually bring in this culture? What else do you think is, uh, missing in this recipe yet?
Mario Viktorov Mechoulam: Yes. Um, I think working with teams is one thing. It’s a small and controlled environment. But the next thing is that you need executive sponsorship. You need to work at the organization level. And that is, that is a bit harder. Let’s say just a bit harder. Um, why is it hard?
Kovid Batra: I see some personal pain coming in there, right?
Mario Viktorov Mechoulam: Um, well, no, it depends. I think it can be harder or it can be easier. So, for example, uh, my experience with startups is that in general, getting executive sponsorship there, the buy-in, is way easier. Um, at the same time, the, because it’s flatter, so you’re in contact day to day with the people who, who need to give you this buy-in. At the same time, very interestingly, engineers in these organizations often are, often need these metrics much less at that point. Why? Because when we talk about startups, we’re talking about much less meetings, much less process. A lot of times, a lot of, um, people usually wear multiple hats, boundaries between roles are not clear. So there’s a lot of collaboration. People usually sit in the very same room. Um, so, so these are engineers that don’t need it, but it’s also a good moment to plant the seed because when these companies grow, uh, you’ll be thankful for that later. Uh, where it’s harder to get it, it’s in bigger corporations. But it’s in these places where I think that it’s most needed because the amount of process, the amount of bureaucracy, the amount of meetings, is very, very draining to the teams in those places. And usually you see all these just piles up. It seldom gets removed. Um, that, maybe it’s a topic for a different discussion. But I think people are very afraid of removing something and then be responsible of the result that removal brings. But yeah, I have, I have had, um, we can say fairly, a fair success of also getting the executive sponsorship, uh, in, in organizations to, to support this and I have learned a few things also along the way.
Kovid Batra: Would you like to share some of the examples? Not specifically from, let’s say, uh, getting sponsorship from the executives, I would be interested because you say it’s a little hard in places. So what things do you think, uh, can work out when you are in that room where you need to get a buy-in on this? What exactly drives that?
Mario Viktorov Mechoulam: Yes. The first point is the same, both for grassroots movements with teams and executive sponsorship, and that is to be transparent. Transparent with what, what do you want to do? What’s your intent and why do you think this is important? Uh, now here, and I’m embarrassed to say this, um, we, we want to change the culture, right? So we should focus on talking about habits, um, right? About culture, about people, et cetera. Not that much about, um, magic to say that, but I, but I’m guilty of using that because, um, people, people like how this sounds, people like to see, to, to, to hear, oh, we’ll introduce metrics and they will be faster and we’ll be more efficient. Um, so it’s not a direct relationship. As I said, it’s a stepping stone that can help you get there. Um, but, but it’s not, it’s not a one month journey or a one year journey. It can take slightly longer, but sometimes to get, to get the attention, you have to have a pitch which focuses more on efficiency, which focuses more on predictability and these type of things. So that’s definitely one, one learning. Um, second learning is that it’s very important, no matter who you are, but it’s even more important when you are, uh, not at the top of the, uh, of the management, uh, uh, pyramid to get, um, by, uh, so to get coaching from your, your direct manager. So if you have somebody that, uh, makes your goals, your objectives, their own, uh, it’s great because they have more experience, uh, they can help you navigate these and present the cases, uh, in a much better and structured way for the, for the intent that you have. And I was very lucky there as well to count on people that were supportive, uh, that were coaching me along the way. Um, yes.
So, first step is the same. First step is to be transparent and, uh, with your intent and share something that you have done already. Uh, here we are often in a situation where you have to put your money where your mouth is, and sometimes you have to invest from your own pocket if you want, for example, um, to use a specific tool. So to me, tools don’t really matter. So what’s important is start with some, something and then build up on top of it, change the culture, and then you’ll find the perfect tool that serves your purpose. Um, exactly. So sometimes you have to, you have to initiate this if you want to have some, some, some metrics. Of course, you can always do this manually. I’ve done it in the past, but I definitely don’t recommend it because it’s a lot of work. In an era where most of these tools are commodities, so we’re lucky enough to be able to gather this metric, this information. Yeah, so usually after this PoC, this experiment for three to six months with the team, you should have some results that you can present, um, to, um, to get executive sponsorship. Something that’s important here that I learned is that you need to present the results very, very precisely. Uh, so what was the problem? What are the actions we did? What’s the result? And that’s not always easy because when you, when you work with metrics for a while, you quickly start to see that there are a lot of synergies. There’s overlapping. There are things that impact other things, right? So sometimes you see a change in the trend, you see an improvement somewhere, uh, you see the cultural impact also happening, but you’re not able to define exactly what’s one thing that we need or two things that we, that we need to change that. Um, so, so that part, I think is very important, but it’s not always easy. So it has to be prepared clearly. Um, the second part is that unfortunately, I discovered that not many people are familiar with the topics. So when introducing it to get the exact sponsorship, you need to, you need to be able to explain them in a very simple, uh, and an easy way and also be mindful of the time because most of the people are very busy. Um, so you don’t want to go in a full, uh, full blown explanation of several hours.
Kovid Batra: I think those people should watch these kinds of podcasts.
Mario Viktorov Mechoulam: Yeah. Um, but, but, yeah, so it’s, it’s, it’s the experiment, it’s the results, it’s the actions, but also it’s a bit of background of why is this important and, um, yeah, and, and how did it influence what we did.
Kovid Batra: Yeah, I mean, there’s always, uh, different, uh, levels where people are in this journey. Let’s, let’s call this a journey where you are super aware, you know what needs to be done. And then there is a place where you’re not aware of the problem itself. So when you go through this funnel, there are people whom you need to onboard in your team, who need to first understand what we are talking about what does it mean, how it’s going to impact, and what exactly it is, in very simple layman language. So I totally understand that point and realize that how easy as well as difficult it is to get these things in place, bring that culture of metrics, engineering metrics in the engineering teams.
Well, I think this was something really, really interesting. Uh, one last piece that I want to touch upon is when you put in all these efforts into onboarding the teams, fostering that culture, getting buy-in from the executives, doing your PoCs and then presenting it, getting in sync with the team, there must be some specific indicators, right, that you start seeing in the teams. I know you have just covered it, but I want to again highlight that point that what exactly someone who is, let’s say an engineering manager and trying to implement it in the team should be looking for early on, or let’s say maybe one month, two months down the line when they started doing that PoC in their teams.
Mario Viktorov Mechoulam: I think, um, how comfortable the people in the team get in discussing and explaining the concepts during analysis of the metrics, this quality analysis is key. Um, and this is probably where most of the effort goes in the first months. We need to make sure that people do understand the metrics, what they represent, how the work we do has an impact on those. And, um, when we reached that point, um, one, one cue for me was the people in my teams, uh, telling me, I want to run this. This meant to me that we had closed the circle and we were close to having a habit and people were, uh, were ready to have this responsibility delegated to them to execute this. So it put people in a place where, um, they had to drive a conversation and they had to think about okay, what am I seeing? What happened? But what could it mean? But then what actions do we want to take? But this is something that we saw in the past already, and we tried to address, and then maybe we made it worse. And then you should also see, um, a change in the trend of metrics. For example, work in progress, getting from 30+ down to something close to the team size. Uh, it could be even better because even then it means that people are working independently and maybe you want them to collaborate. Um, some of the metrics change drastically. Uh, we can, we can talk about it another time, but the standard deviation of the cycle time, you can see how it squeezes, which means that, uh, it, it doesn’t, uh, feel random anymore. When, when I’m going to ship something, but now right now we can make a very, um, a very accurate guess of when, when it’s going to happen. So these types of things to me, mark, uh, good, good changes and that you’re on the right path.
Kovid Batra: Uh, honestly, Mario, very insightful, very practical tips that I have heard today about the implementation piece, and I’m sure this doesn’t end here. Uh, we are going to have more such discussions on this topic, and I want to deep dive into what exact metrics, how to use them, what suits which situation, talking about things like standard deviation from your cycle time would start changing, and that is in itself an interesting thing to talk about. So probably we’ll cover that in the next podcast that we have with you. For today, uh, this is our time. Any parting advice that you would like to share with the audience? Let’s say, there is an Engineering Manager. Let’s say, Mario five years back, who is thinking to go in this direction, what piece of advice would you give that person to get on this journey and what’s the incentive for that person?
Mario Viktorov Mechoulam: Yes. Okay. Clear. In, in general, you, you’ll, you’ll hear that people and teams are too busy to improve. We all know that. So I think as a manager who wants to start introducing these, uh, these concepts and these metrics, your, one of your responsibilities is to make room, to make space for the team, so that they can sit down and have a quality, quality time for this type of conversation. Without it, it’s not, uh, it’s not going to happen.
Kovid Batra: Okay, perfect. Great, Mario. It was great having you here. And I’m sure, uh, we are recording a few more sessions on this topic because this is close to us as well. But for today, this is our time. Thank you so much. See you once again.
Mario Viktorov Mechoulam: Thank you, Kovid. Pleasure is mine. Bye-bye!
Kovid Batra: Bye.
Implement engineering metrics, gather SDLC insights & set continuous improvement goals in your dev teams.
Try Live Demo
.png)
.png)
