Webinar: The Hows & Whats of DORA with Mario Mechoulam & Joan Capell
In this session of ‘The Hows and Whats of DORA’ Webinar, powered by Typo and hosted by Kovid Batra, panelists Mario Viktorov Mechoulam, Senior Engineering Manager at ContentSquare, and Joan Díaz Capell, Engineering Manager at New Relic, share their expertise on DORA metrics and their real-world application to enhance engineering outcomes.
They discuss how to effectively use DORA metrics to track and improve dev team performance, and explore advanced topics like Monte Carlo forecasting and using qualitative data to track team health. The session emphasizes the importance of aligning engineering metrics with business goals and product success, avoiding vanity metrics, and leveraging data to improve collaboration and team well-being.
The panel also responds to audience questions, sharing insights on overcoming resistance to metrics adoption, managing cross-team dependencies, limiting work in progress, and balancing speed with stability.
What You’ll Learn in This Episode:
🚀 How to Use DORA Metrics Effectively: Unlock actionable insights to improve engineering performance and delivery speed.
🔍 Monte Carlo Forecasting: Predict delivery timelines and reduce uncertainty by applying data-driven forecasting techniques.
📊 Aligning Metrics with Business Goals: Understand how engineering metrics correlate with product success and business impact.
⚡ Avoiding Vanity Metrics: Focus on metrics that drive real impact rather than those that just look good on dashboards.
🏆 Leveraging Qualitative Data for Team Health: Use qualitative insights to improve collaboration, well-being, and team culture.
💡 Managing WIP and Cross-Team Dependencies: Practical tips on limiting work in progress for better flow and reducing bottlenecks.
Timestamps
- 00:00 — Let’s begin!
- 00:27 — Meet the Speakers
- 02:07 — Icebreaker: Personal Insights
- 07:30 — Importance of Engineering Metrics
- 13:58 — Use Case: Impact of Improvements
- 27:11 — Use Case: Cost Benefit Analysis
- 33:03 — Understanding Goals and Hypotheses
- 33:52 — Example of Measuring Improvement
- 36:08 — Predicting Feature Delivery Time
- 38:27 — Introduction to Monte Carlo Method
- 49:13 — Q&A Session Begins
- 49:36 — Metrics to Control Tech Debt
- 53:41 — Qualitative Data for Better Planning
- 56:50 — Managing Cross-Team Dependencies
- 01:00:09 — Limiting Work in Progress
- 01:03:20 — Conclusion and Parting Advice
Links & Mentions
- Mario Viktorov Mechoulam on Linkedin
- Joan Díaz Capell on Linkedin
- Kovid Batra on Linkedin
- Listen on Spotify, Amazon Music, and iTunes/Apple Podcasts
Episode Transcript
Kovid Batra: Hi, everyone. Thanks for joining in for the DORA Metrics webinar ‘The Hows and Whats of DORA’, powered by Typo. This is Kovid, your host, and with me today, we have two amazing speakers who are some of the front runners of bringing data-driven engineering to the engineering world, making dev teams even more impactful. Please welcome the metrics expert tonight, Mario and Joan. Thank you, Mario. Thank you, Joan, for joining in. Uh, so guys, both of them, uh, come with real and deep experience of educating and implementing engineering intelligence in various dev teams. Uh, Mario, who has had like 15 plus years of experience, uh, he, he is coming to this webinar for the second time and we will see him more frequently coming in. Uh, he, he’s a Senior EM at Contentsquare. Uh, hi Mario.
Mario Viktorov Mechoulam: Hi, Kovid. Hi, Joan. Very happy to be in the live panel again. Thank you for having me.
Kovid Batra: Pleasure. Pleasure. Uh, then we have Joan, uh, who, who comes with, again, 18 plus years of experience in Agile coaching, and he’s an EM at New Relic. So he is managing dev teams at a great company. Uh, I, I, I can assure the audience that the door’s fully packed with insights to share with us today and help us navigate the landscape of engineering metrics. And, uh, this time, uh, this session is really special. Uh, why it is special, because today the insights that, uh, the audience is gonna learn, uh, you guys are gonna, uh, speak about are coming directly from the engineering leaders who have been associated with Typo, who have encountered so many use cases that they’ve come to Typo for understanding how to leverage those engineering metrics and tooling like Typo to actually bring that data driven approach and drive efficiency. So it is gonna be a real, real insight from the real world. Uh, but before we dive into these, uh, practical applications of DORA and engineering metrics, uh, I wanted to do some ice breaking with, uh, Mario and Joan. Uh, so basically, uh, we, we start with, uh, usually we start with some different kind of questions about your personal life, about your hobbies and things. So I, I have come up with something. Um, I would say, uh, you, you would like to talk about, and that way we would also, uh, get to learn more about you. If you don’t like the question, you don’t have any option, you have to answer it. Alright. Uh, so are, are you guys ready?
Joan Díaz Capell: Ready.
Mario Viktorov Mechoulam: Let’s do it.
Kovid Batra: Alright. Alright. So I think, uh, we can, we can start with Joan. Uh, Mario, I’ll give you the second seat because you are here for the second time. Let the audience know, uh, Joan more now.
Joan Díaz Capell: I like that.
Kovid Batra: Okay. Okay. Uh, uh, so I think, uh, Joan, the first thing that we do, uh, to start with is, um, we usually want to know, uh, what are your hobbies? But this time I have thought about something which usually everyone wants to do in this world, but I don’t know if people really want to talk about it. Uh, it’s more about the financial freedom. So everyone is working, making money, and of course that’s, that’s something that we need to live on, but everyone needs that financial freedom and that has been a term quite, uh, like heard quite often a lot. Uh, so what do you think, what is your stage of financial freedom? And let’s say you achieve it. Uh, what would you do at that point and why? Of course.
Joan Díaz Capell: I’m not at that point to be honest, but, um, if I, if I was able to get to that point, what I would like to do.. Um, first I think that, I mean, I would, I would spend most of my time on, on the hobbies that I like, right? So I really like doing sports. So I will be very focused on, on, on sports. But on the other side, I also like this, um, uh, also, I like reading also books about philosophy, something like that. So that’s kind of a part of my side, that side that if I have all this freedom, maybe I will just take my time to just observe, rest, relax, and, and enjoying the, uh, doing, I’m not gonna say doing nothing, because I will just meditating and thinking, uh, more introspective. So I think I will try to just chill, slow down, uh, enjoy my, my, my, my hobbies that, I mean, usually is everything related with the sport to be, to be honest. Like surfing, skiing and going to the gym, et cetera. And apart from that, reading and just, and relax and chill, I think that I will enjoy that.
Kovid Batra: That’s great. Uh, but I won’t stop bugging you here. I would love to know like, why would you want to do surfing? Why would you want to do skiing? What does it bring to you?
Joan Díaz Capell: Ah, wow. Uh, I think it’s this kind of challenge, this kind of mastering the, the, the technique, the, the environment, trying to fight in order to improve and be better with your, yourself actually. So trying to be your, your, your best day after day. And it kinda is nice some of this sports because sometimes it’s like, wow, I’m think I’m doing very, very, very bad this, this time. But then it’s, oh, I do it very, very good. So I think that you also have to live with this situation that there’s good days, you have good days because bad days exist as well. So you have to also to, to, to find that balance.
Kovid Batra: That’s interesting. Thank you. Thank you so much. Uh, Mario, the same question goes for you. Yeah.
Mario Viktorov Mechoulam: Yeah, yeah. I think, uh. I think if as first to, to do that, I’m also far away. We have to, we have to leave Spain, Joan. I think financial freedom is not gonna happen. Uh, jokes aside, I think I would be, I would be writing. I, I love writing. People at work that have had the, have been unfortunate enough to, to suffer me and suffer my, my walls of text, they know I, I like writing. So since I was a kid, I like reading and, and writing stories. So I think I would dedicate, uh, a good chunk of time to that, hopefully in some, uh, on some Caribbean beach. And, uh, if, if I achieve financial freedom at a point in my career where I’ve, I have amassed enough, uh, experience also, I would love to share, I would love to help people, um, with some coaching, with some, um, yeah, I dunno, some, some experience and some lessons that I’ve learned so that, uh, it can help them as well.
Kovid Batra: Perfect. Uh, is there anything specific that writing brings to you? As I asked Joan also, like, why exactly would you want to do that? How does it help you? And what kind of writing specifically if you have to talk about?
Mario Viktorov Mechoulam: Uh, I would say between science fictions but also mystery. I think writing, well you can, you can write your own book, your own story and then, uh, being able to communicate to people, being able to let them experience something that unique, I think it, uh, it means a lot to me.
Kovid Batra: That’s really nice. Great, guys. I think both of you have something deep inside, uh, and that’s really encouraging, uh, and good hobbies to have for sure. Uh, alright. I think on that note, we can definitely get started and tell the audience what we have to offer here. So, uh, before we jump onto the main section where we start talking about the engineering metrics and the use cases, uh, the first thing, uh, I would like to understand from both of you, uh, you both have been like flag bearers of engineering metrics in your teams. Uh, we definitely talked about it, but why do you think it is important? And I mean, there is an obvious answer to it, probably to both of you, but there are a lot of people out there who are seeking that motivation, seeking that understanding of how it can actually impact their teams, their careers. So, uh, Joan again, uh, would you like to go first and tell us why is it important?
Joan Díaz Capell: Sure, sure. I mean, for me it’s, um, the sense of also, uh, of improvement as well. I mean, it seems that we want to be better sometimes and we want to be, uh, better, better at what, what we are doing because we are professionals, right? Um, how do you know that you’re, you’re, you’re working better every time and you’re improving? Sometimes for me, it’s like if I don’t have some kind of metrics, um, I have the feeling that I’m quite blind. Right. So, um. How can I put some light? How can I enlight also the, the progression or what, what the challenge that we are doing if I were, we’re doing in a better way or not? So this helps me also to understand a little bit our improvement also, and also can try to get also some information about the environment that is surrounding us. Like, uh, it’s kind of a complex problem, so we are dealing with different metrics, so they are correlated or not, uh, we are trying to push in the same direction or not. I mean, it gives me some, some light some way also to, to see if we’re improving or not. So it’s kind of, um, it gives me some peace, I would say.
Kovid Batra: Perfect. But, uh, don’t you think, Joan, almost all the engineering leaders, engineering managers out there have some way of measuring what teams are doing? Uh, why we are here today is to explicitly highlight the importance of bringing in a more sophisticated structure, uh, when we talk about engineering metrics. So what would you tell, uh, a person who is doing some level of measurement? Maybe they’re just looking at their sprint activities and understanding how many story points they completed, or they’re doing first level understanding of how their, uh, developers are, uh, completing the committed stories. But is that enough? Like, is that sophistication required in this structure? Uh, and how it is important if it is required?
Joan Díaz Capell: Uh, I would say from my point of view, that it’s never enough. I mean, I usually like to challenge the status quo. So I would say to those people, to, to these people, like, be curious. Try to understand if there’s more things or. Don’t trust, don’t blindly trust what you used to do before or what you hear that all the trends that people are doing. Try to understand also if what is your environment, if there’s any other things that you can incorporate, which are the things that you’re more curious to know about, uh, try to get more information about this because I’m pretty sure that there’s plenty of more metrics that you can use and you can get a lot of advantage of them.
Kovid Batra: Makes sense. Um, Mario, do you have anything to add here?
Mario Viktorov Mechoulam: Um, I think, no, I think Joan’s answer was very spot on. Uh, we also had, uh, a few months back, Clint here, who used to say, ‘I cannot fly blind.’ And that describes it pretty well. So to avoid repeating myself, I think, uh, I, I I like to quote Peter Drucker, like, ‘what gets measured gets managed.’ And in this case, I think if we want to do, to do better and understand what we are doing, and if we are improving, we need to, we need to measure.
Kovid Batra: Makes sense. Joan, back to you. Uh, anything specific, uh, any framework, any set of metrics that you would always recommend to engineering teams, teams who are getting started? Uh, any kind of tip on that part?
Joan Díaz Capell: Uh, framework, framework per se, I’m not a big fan of, uh, uh, and a box that you can just take it and, and use it because that, you know, there’s this quote, uh, never remember the name of that guy that said that, ‘for every complex problem, there’s, uh, an answer that is simple, clean, but wrong.’ Right? So, um, I would say, uh, it depends on, on, I mean, I usually start with a subset of things that I like to have to, to keep in mind, but then I can start adding more things like, uh, I mean the basic ones like throughput, uh, cycle time. Um, WIP, in order to understand how is the, the, the system at that, at that point with a very small set of things. And then I start adding things if I think that they make sense or not, or maybe I add one and then remove. But I don’t have any particular, um, framework to be, to be honest, uh, Kovid, I just start to start small.
Kovid Batra: Makes sense. No, it totally makes sense. I think, uh, every situation, every problem has its own, uh, nuances, which needs to be understood and based on that, one can actually apply something. It could be a part of some framework. It could not be. We need to decide on the basis of the situation and the problem that you’re dealing with. Totally makes sense. Mario, you have any, any opinion on that part?
Mario Viktorov Mechoulam: Uh, very similar. You can see how we used to work together. I learned a great deal from Joan. I think less is more when you start, but there is, there is a, I would say a small set of metrics that you cannot go wrong with. I mean, they have, they, they stood the past of time, so I, I love cycle time. I love WIP. Uh, I love throughput. Just with those, there is so much depth once you start digging that you can already understand, uh, a great deal. And after that, it depends on the context and it depends on what you’re pursuing. So if you are interested in some, uh, X event, X outcome, perhaps you can, uh, look to understand which are the metrics that would be, uh, key indicators, lagging indicators to that, and see, um, what is the team comfortable with measuring, uh, around that, that can give us information.
Kovid Batra: Makes sense. Alright, guys, I think, uh, that’s, that’s a decent start to, uh, handling engineering metrics and using them, leveraging them to bring more efficiency. Uh, today I have jotted down a few, uh, use cases as I, as I told you in the beginning, that there have been, uh, things that we have been discussing with our users in Typo who come with different, uh, scenarios where they want to measure certain things to improve, uh, XYZ in their engineering teams. So, uh, let’s see how many we can cover today. I, I have a lot, of course, we can take it to the next session also, but to start with, the most prominent case is, uh, that we are dealing with is understanding the impact of improvement. So that’s the first use case I, uh, wanted to discuss with you both and, uh, impact of improvements, I, I’ll detail out a scenario and, uh, maybe then you can get a better understanding of what, what I want to discuss and what the, our users wanted to understand. So, let’s say there is a senior engineering leader, uh, who wants to show the executives that the organization is more efficient at releasing software now than the, than organization was two years ago. How the, that efficiency, uh, has translated into lower cost, how that leader could actually use certain set of metrics, uh, to showcase that, that impact of improvements that have happened in the last two years. So what is your outlook on this situation? Which metrics should be used? Is what I wanted to discuss with you.
Joan Díaz Capell: Mario, shoot.
Mario Viktorov Mechoulam: Okay. Um, alright. I think what, when, when I hear this, we’re talking about yeah, efficiency and this is, this is a word that gets thrown around, uh, a lot lately. Um, but before we delve into that, I think we need to define what, what is efficiency, right? So is it, uh, is it, um, I dunno, shortening the cycle time? Is it, uh, reducing the number of, of bugs? Is it, uh, doing, uh, more, uh, more features with the same team that you have today? So we have to, we have to define that. And, and once we do, and we can go in detail into what for me is, are some indicators of efficiency and then hear from, from Joan as well. Uh, and after that we have to, we have to compare, right? We have to measure and we have to compare because if we’re talking about a two year period, um, I would like to think that we are not, we’re not in a situation where we have worked on a system to improve efficiency for two years and then bang, we release that and we try to measure and compare with what we had two years ago. So many things change in the organization that you cannot really do that. So you, I suppose we’re seeing incremental changes, maybe, uh, some bigger jumps here and there, uh, when we change things, when we learn information. But yeah, so the two things would be ‘let’s define what is efficiency’ and, and then, ‘let’s measure’. Um, very quickly, and then I, I’ll, I’ll share, I’ll give you, uh, Joan the, the opportunity to, uh, to complete. Uh, for me, efficiency, I, I like to take the, uh, the, the lean approach, which is do, do more with less. So it’s, uh, more deployments, um, do more, have more throughput. Um, so more of, of the business impact that we want to see with less waste, right? So less handovers, less waiting times, less blockers, less defects, less of all the things that slow us down and reduce or subtract from the value that we are, we’re delivering to customers.
Kovid Batra: Makes sense. Joan, uh, over to you.
Joan Díaz Capell: Yeah. I mean. I like the beginning that what Mario said. I mean, I think that the first thing to, to do here is, uh, define what is, uh, efficiency for you as well, what are the.. Because I’ve been there in different companies that we said we will be more efficient, but what does it mean? Right? Somebody put some kind of metrics there, here and there, but, and we align it on that, are we clear with what is definition for, for, from, from all of us? Because there’s different, there could be different people who sit in different ways because they have different lives inside the company. So I would say that the first thing is to, to have this definition of, of efficiency, right? To see which are the, the, your pain points, right? And then try to see which are these pain points and then trying to, to attack them one after the other one. These kind of leverage points that people usually say that in the system thinking, um, because once you have this, then you can try to, to work around them. Um, and I think it’s also clear what, what Mario said, this kind of benchmarking, trying to compare you with, uh, with you. And this is something that we were discussing with Mario as well, another chat that we had, as I used to work for a company that we were doing software for hospitals and we were doing, we were creating some benchmark for different hospitals because we were not, I’m saying that because we used to compare with all these benchmarks that I think accelerate people also, uh, share with all of us. Like, this is how Meta, Amazon and other companies are working. And I see some companies that they’re trying to compare with them, but are you at that level? Are you sharing the same pains of Amazon, Meta and et cetera? I mean, could be, but it’s not, not every time. Usually, usually not. It’s not the situation. So try to find which is the best benchmarks also. Try to find it better. You can, you can easily compare from your side, from your past year, so it’s kind of easy for you if you know which are the metrics that you want to, to measure. So I will say that start with that. Try to compare with yourself, try to see if you’re better. So you are then moving us what you define as efficiency, so you can, we can see then, uh, um, an improvement.
Kovid Batra: Totally makes sense. Do you have any example to share? Like, Mario just touched on that surface, like it could be more deployments that have started happening. There could be less defects, uh, less of handovers, time-based stage, all those things, right? So similarly, if there is an example in your mind where you would apply certain metrics. Can you share that with us?
Mario Viktorov Mechoulam: Yes, yes. I feel I, I’m always going to the same, which is cycle time, but I think this is one of the best metrics that we have. Um.
Kovid Batra: Okay.
Mario Viktorov Mechoulam: So, so being able to reduce the cycle time, especially the higher quantiles, higher percentiles means a lot, uh, means that we as a team are able to focus on everything that we have committed to do. Uh, every time we put something or we start working on something, there is, there is a commitment. So it’s not, not fair to say after a while, ‘oh, this is no longer important because there is something more important.’ And leave it, we leave it hanging out there. Or, ‘this is blocked because, oh, we have to, a dependency with this team and they cannot collaborate right now, so we don’t care.’ No, that, that’s not the correct, or maybe ‘this person is off, so nobody’s picking up the work.’ It’s teamwork, right? So cycle time is team cycle time. So when I see cycle time going down, especially higher, higher percentiles, it means that we’re getting better at focusing on, on our commitments and we are also becoming a bit more predictable, uh, for the work we’re doing. And I, I, I’ll always remember this fun story. It didn’t happen so long ago, but we are looking at the board, right? And you could see, uh, your typical columns, uh, in progress, waiting for review, review, waiting for validation, and validation pipeline, et cetera, et cetera. And, and we were looking at some tickets that were over there, some pieces of work, and, uh, they were stuck. Uh, they were stuck for different reasons. So I asked the question like, who, uh, who’s, who’s responsible of this ticket? Oh, that, that guy that’s assigned to it. Who’s responsible of this one? Oh, this other guy. Uh, no, it’s, it’s the team. So you need team effort, um, to move the work forward, uh, to prevent these, uh, leakages, this waste. So you’re optimizing the system. And, and there are certain statuses, especially the waste statuses that should be tending to zero. The statuses that you can automate, you should be tending to zero. Um, so yeah, when, when, when you look at all those, you can say with certain frequency, may, maybe we are doing, maybe we, um, whether we are delivering more or less value, that, that remains to be seen because, uh, it’s one thing to be efficient. It’s very different to be effective. So you could be very efficient at doing a lot of very good stuff, but then nobody cares about, so you’re, you’re not making any, um, you’re not making any money out of it. But, uh, the first thing that we need to, to make sure is we optimize that, we reduce waste, and we are seeing work, workflow. Um, and then you, then you start getting to these, these times that, uh, these cycle times that are really, really surprising. Um, and by the way, I fully agree with what Joan said. So we don’t have to go to these benchmarks and trust them blindly. There’s, uh, there’s so many, even, even in hospitals, what you would say, like all hospitals would scale in a pretty similar way. Uh, even then, uh, Joan, Johnny, his, his company, they, they did different benchmarks tailored to the size and the context. So we should be doing that for software companies as well. So the one benchmark that you can always do, or that you can always use to compare is, is with yourself. So first step is always am I, am I getting better with my former, uh, self or my former, uh, my, my team one, one month ago?
Kovid Batra: One important thing that I noticed in this use case, uh, the user actually specifically talked about the metrics that, uh, which the engineering team itself should be looking at. Like we talked about cycle time, deployment frequency, handoff times, and uh, reducing these stages. But also, uh, the user mentions about telling it to the executives who might not exactly relate to some of these metrics and would not be able to actually make sense of, of it in terms of the business. So do you think in that situation there would be, uh, specific things that you would like to explain to the executives and show specific metrics? Like, one example comes to my mind is like, instead of telling cycle time particularly or any phase of the cycle time, like the review time has gotten better or the merge time has gotten better, can we just like talk about the overall epic cycle time? Or maybe the lead cycle time for one story to another on an average, how it has improved. So is there any thought on that part? What it, what we should be communicating to the executives?
Mario Viktorov Mechoulam: Definitely, definitely. When, when we talk about cycle time, uh, maybe the only exec that is interested in that might be the CTO, uh, but, uh, for the rest of the execs, we, we need metrics that are bit more tailored to them. Uh, so sorry, metrics are the same, but, uh, let’s say, uh, the granularity at which we, uh, we share with them, uh, share them with them is a bit different. So, as you said, for execs it might be much more interesting to see, uh, how, what’s a cycle time for a, for a feature, right? Um, how, how many features can, can we ship? How likely are we to ship something that we said we are, uh, we are starting today? Uh, so if we can tell them, we can put something in the hands of the customer, uh, with a 95% confidence in one week or one day, that, that’s big, that, that’s very big.
Kovid Batra: Makes sense. Uh, Joan, uh, do you have anything to add on that point?
Joan Díaz Capell: No, indeed. I mean, I 100% agree with, with, with, with Mario. I mean, um, and what you’re saying also, Kovid, because I, from my experience, what I see is that usually engineering teams really focus on their improvements, time to be every time better and better. Um, and we are part of a whole, right? So, uh, at some point are we improving something that is already working fine? I, I don’t know because we don’t see the rest. So for me, makes totally sense that maybe improving on the engineering, we are part of the, of, of a suboptimal, suboptimal optimization. So if you increase a little bit more review, you start also considering collecting and being, as I said before, kind of curious about what’s happening on the epic or feature level, whatever you want to call it. And maybe you get, you get more information about all the whole process because maybe you are, slower than, you are slower because, um, there’s some issues on product or on design or, uh, another stakeholders or some communication that it’s making a, slowing you down. So if you realize about all this process and you understand that there’s kind of a bottleneck, that it’s outside of the, uh, that the regular, um, metrics that you are taking, like, um, how fast you are deploying or something like that, maybe you improve all the, all the, all the, all the flow on the epic or feature level. So you are able to, to reduce some waste. You are able to be more focused on this feature and at the end maybe you have happy customers.
Kovid Batra: Yeah. Makes sense. I think that’s, that would be one right way to explain also to the executives. Great. Uh, guys, I think, uh, this, this point was pretty, uh, well explained by both of you. Uh, in association to this, I think there is one more use case, uh, that we have encountered, which is around the cost benefit analysis. Somehow it relates to the impact of improvements, but this is specifically talking about the cost benefit analysis. I’ll, I’ll explain the use case and I think then you guys can comment on it. Uh, yeah. If an, if an executive, uh, would like to understand the cost benefit of an infrastructure development initiative, like anything that you have done at the infrastructure level and continue to monitor it as it is being developed and rolled out. The initiative is either supposed to reduce the development cost for new products or provide more bandwidth for engineers to take on more projects. So, uh, which metrics could provide such a capability to, to this executive? And like, I would like to understand that part in detail. Uh, I hope the question is clear. Uh, do, do you guys want me to repeat it?
Mario Viktorov Mechoulam: No, it, it is clear.
Kovid Batra: Okay. Okay.
Joan Díaz Capell: Mario, go ahead there. You’re the senior here so you can start the conversation always and I’ll follow you.
Mario Viktorov Mechoulam: Okay. Okay.
Kovid Batra: Uh, alright. Alright. Like, let’s go ahead with Mario then. Yeah.
Mario Viktorov Mechoulam: Thank you, Joan. Um, so, so when I hear this, uh, to me, um, so reducing costs or freeing more time to do all the stuff is two sides of the same coin, right? Did, did I get this part right in the question? Yeah. Okay, so what, um, so what the use case is, people want to understand how, whether this, this cost reduction or this, uh, saving of time is being materialized or not. So yeah, here, that, that’s why I think it’s very useful to have people in, in the company that, that, that can help around and, and ask the right questions when these initiatives are started because, um, so if somebody came to me with this question, uh, my, I, I would, so my first question to them would be, alright, so you’re doing something, let’s call it ABC. Uh, because probably you’re expecting to see something, so this something you, you should have defined and then you might be right that you’re gonna see that or, or wrong, uh, and you might see additional things. So, uh, for example, if somebody is talking about infrastructure improvements, this is what, uh, this, this is what this customer was asking about, right? So infrastructure improvements can be many things. But let’s say that we are investing in, uh, I don’t know, uh, moving out of our old CI/CD system, uh, introducing, embracing some more competitive solutions out there so that we can, we reduce the gap between the, uh, the moment where the code is, uh, pushed to the, to the master branch and when it’s in production. So putting in, in, in the customer’s hands earlier. Um, I think that, uh, this is one way which we can see has these, um, cost reduction being, being materialized, uh, economical cost. I won’t go there because I think it’s very straightforward. So if you’re replacing technology A for technology B, you’re doing some optimizations here and there and you expect to see some cost reduction, that, that’s very easy. You can see that in the, in the finance, uh, financial, um, sheet. Um, what, what else? Um, so we, we might look at other things like, uh, can we do more? Uh, so how do we free the engineer’s time? So now that, uh, so that now we are doing more and maybe we want to measure that with deployment frequency, uh, however with deployment frequency, it’s, uh, it’s always a bit tricky, right? Because, um, first you need to know whether, whether you have a bottleneck. And, uh, there is an engineer I, who wrote an article I love, a public writer, uh, from, from Hotjar. Um, he, he, he explained how they, they improve the, um, the value of flow at back at Hotjar because they had a bottleneck in their, uh, deployment pipeline, right? And, and they could see that because, uh, the article is out there, it’s very, very, very, uh, recommended. You could see that because they were hitting this bottleneck, so they could see some consistent number of deployments per day and acute. Right. But, um, perhaps when you change the technology and you have introduced these optimizations, uh, you can do much more deployments per day. Perhaps you have a spike. So one day you have 20 deployments, but maybe the, the second day you have two. So you have to keep this into account if you, uh, you really need to have, to have something to deploy. Um, so in, in this case, I would look for, um, maximums. So maximum number of deployments in a given period, daily deployments in a given period to understand if you have removed the, uh, a constraint that, that existed or not. Uh, and that’s enough. So you don’t have to see that every day, this deployment frequency, because at the end of the day, unless you are like the high performant elite team in some benchmarks, you won’t be having, uh, uh, 20 deployments per day. Maybe you do some days, maybe you don’t others.
Kovid Batra: Totally, totally. Joan, do you, do you have an example to share, uh, where any kind of infra improvement impacts the cost and defines the benefit of doing that?
Joan Díaz Capell: Um, not a particular one, but when Mario was talking, I was relating it, uh, again, with the, the topic that we were discussing at the, at the beginning, right? So you have, you should have to be clear about what are the things that you would like to improve at the beginning. So we are talking again, maybe as, as efficiency thing, again, because you want to reduce something or, or increase, I mean, increase the revenue or reduce the cost. Uh, you can try to do both of them or at the same time, you should know first what, what are the things that you would like to do, why you are doing that. You are not doing that because there is a new technology, right? So you have kind of, first of all, you have to be clear with, I would say that you have to be very clear with, um, what you want to improve. And then if you are, you have this hypothesis, then you can check later on if this is happening. Um, or not. So you can then, as Mario was saying, also free up some time then that maybe people can, can use in order to investigate new things, et cetera. But again, I think that it’s kind of understanding what are your problems, that you are doing in order to be more efficient as well, more than, more than solving an issue because you think that it’s the, the way to go.
Kovid Batra: Makes sense. Uh, there, there is one example that I could remember from this discussion. Uh, somebody on LinkedIn had posted about it. Uh, so they said if you are doing some level of improvements, if you’re getting rid of your tech debt, then one good metric to look at would be, uh, the first line of code, uh, that your new developers comes and pushes it. So the time taken, uh, for a developer to commit the first PR should reduce. Basically, that’s how you can gauge, uh, that whether you have improved something or not. Of course, that was very situational and specific to one scenario, but I think this is also one place where we can see how fast people are able to push the code to production. If you have gotten rid of some level of, uh, tech debt or you have done some improvement, automatically those PRs would be getting pushed faster. So yeah, I think that example just, uh, striked me. So I just wanted to mention it.
Mario Viktorov Mechoulam: Yeah, this is a very good example. And I, and I would tend to agree that most of the cases you, it’s, it’s a good predictor. So it can tell you how, how big a repository is, uh, how coupled is the coding site, how complicated, uh, are long, are the, the, the methods, uh, and the different files. It can tell you how, how good is documentation, whether there is shared knowledge between your senior and non-senior engineers in that team or in other teams, uh, your pipeline for deploying data production, quality gates, anything that you could have that can give a quick onboarding and one of these to ship the software with confidence. It’s, uh, all those, uh, yeah, would be, would be great things to, to look for.
Joan Díaz Capell: And also, on top of that, something that, that we usually like to say is that every single line of code that you do, that any user executes, it’s waste till somebody executes it on production. So, so taking a little bit of the lean, uh, mindset here is, uh, are you producing a lot of waste or, or, or not? So the, the less waste that you create, meaning that the more lines that you are doing are there in production and being executed by a user, the better as well, so.
Kovid Batra: Yeah, totally, totally. Perfect. Perfect, guys. Uh, I think we can move on to the next, uh, use case. And I think this is a big, big, big pain point, uh, for engineering managers, for product managers. But let’s, let’s just stay specific to the engineering teams right now. And the pain is, uh, telling, uh, the executive, telling the product team, the business team, when exactly are we gonna deliver? What’s the feature delivery time? Predicting that. And honestly, uh, in my career, I haven’t seen, uh, a robust way, a very predictive way, uh, that would be very accurate. But still, there is something that I came across recently after talking to Mario, and I thought it would be great to bring up this point. So I’ll highlight the use case. I’ll explain it so that the audience also relates to the use case, and then you guys can continue on that point. So it’s the case where the team needs to be more robust. Uh, they need a more robust way to predict the feature delivery time, uh, considering the inherent uncertainties, uh, in individual tasks, uh, there is no accurate way to do it, and a single point of estimate is likely to be very inaccurate. Uh, so a broad range of, uh, broad range might be, might not be helpful for planning. So anything that you guys think would be helpful here? Any methodology, any framework that would be helpful here. Let’s talk about that.
Mario Viktorov Mechoulam: Good. You want me to start again, Joan?
Joan Díaz Capell: No, I think I can start because come on, come for me. I can, I can just now. No, I think that this is a never ending, uh, story, because, uh, we use, I mean, I like to say that, um, by definition estimation isn’t accurate, right? Because otherwise it’s not an estimation. So sometimes we try to, to, to spend a lot of time and trying to understand the, the problem, the issue so we can do a better estimation. And what does a better estimation mean? Uh, spending more time and not to understand better. So sometimes we end up in, I have the feeling that in my experience, we end up in a situation that I’m not sure if we’re investing or wasting time in order to give a better planning. So, um, one of the things that we, I mean, I think that we already started working with Mario, I think it was like six years ago, something like that. It was with, with this Monte Carlo, um, uh, model that, uh, I think that the name, what was the name? The name is coming from, from this random nesting. They in the casinos.
Mario Viktorov Mechoulam: Yeah.
Joan Díaz Capell: Um, but we will talk about Montecarlo maybe later on, in, in, in order to go deep, uh, on it. But we, what we were trying is, uh, moving out of this more deterministic estimation, like you said, okay, we’re gonna deliver this particular day. We’re trying to move more to a, more probabilistic forecasting way, like, uh, understanding our current situation, we have, uh, 80% probability that we will deliver this thing, I don’t know, in two months or before. So then you can, more, you can also manage the risk there because it’s like, okay, it’s 80% probability, but a 7% probability is what? Well maybe, uh, half months. So we can have this discussion also with, with, uh, different stakeholders. And also, um, because usually when we give estimations, we are very optimistic. And to be honest, from my experience, when you say an estimation, you are giving the average because it’s more or less, I think that the worst scenario, it’s 4. Better scenarios, 2. So I don’t know, 3 plus, 3 days, something like that. So we usually work on estimations and an average, sorry. And you know, that average rates are 50% of the time wrong. So it’s, um, it’s a lot of, um, putting a lot of pressure to, to an, to a, an estimation. So, um, for that point, we, this is when we started trying to, to, to move to the, this probabilistic, um, estimation that maybe, I don’t know, Mario, if you want to go deep on, on, on that experiment, uh, we did and we continue running in our companies that we work for.
Kovid Batra: But before, before we go, uh, deeper into that part, uh, you mentioned Monte Carlo. Uh, where is this name coming from? Uh, what is it about?
Joan Díaz Capell: Um, I think it comes from, from casino and these kind of randomness things because, uh, at the end it’s like, I mean, you collect all the data that you have and you dice, uh, uh, you roll the dice, sorry, you roll the dice like, uh, thousand of times and you collect all this information. So based on not all this information, for instance, you can do it on the story points, you can do in number of stories finished, on lead time, all this stuff, we will live on that. So, um, at the end you build a model based on your past data so you can understand which are the probabilities that are based on the behavior that you had, if they’re going to be repeated or not.
Kovid Batra: I think Mario also has done some research on that. Uh, do you, do you have something on, on the Monte Carlo thing? Yeah.
Mario Viktorov Mechoulam: Yeah. You want on the name or on the, on the method?
Joan Díaz Capell: Both.
Mario Viktorov Mechoulam: I, uh, actually, so yeah, I, I think, I think the, the creator of the, or the, yeah, the, the person that first documented this, uh, Monte Carlo probability forecasting, he had an uncle that had some gambling issues. Uh, Stanisław Ulam, I think it was. And, uh, and that’s why he, he ended up choosing, uh, choosing the name. But, uh, but I, I like how, um, I like much more, uh, not the, the gossip or the trivia, but, uh, the explanation Joan, Joan gave, I think it’s much more accurate to, um, yeah, to think about this, uh, probabilistic model because of the randomness in, in the dice rolls. Um, I, I, I love how Joan introduced this, by the way, uh, moving from deterministic to, uh, to probabilistic. Uh, also, so one, one thing he mentioned is that we normally give, um, a scenario which is the, the average when we give estimates. I would adventure to say we usually give the optimistic scenario, not, not even the average. And you can make this example. So you can ask the team about an estimation and are you sure? Yes. And then after a while, ask them, okay, so if everything goes super smooth and super well, what’s your estimation? It’ll be the same. It’ll be, it’ll have a 5% rate. So that’s when you realize that there is at least 10 or 12 variables that you do know, you’re aware of, that can each of them go wrong and each of them can have an impact on others. And there’s probably hundreds that you don’t, are not even aware of that, that can happen. Um, there was this, uh, from a pro-Kanban site, uh, I think it was the, uh, planned likelihood, likelihood. They had this simple, uh, estimator on the website. Now I think you have to register to see it, but you could simply add each of these variables, uh, that could have an impact in a, in a, in an estimation. And the likelihood of these, uh, happening or not happening, uh, you could see once you started out three, four things, like somebody going on a on a, I dunno, breaking a leg, uh, somebody leaving the company, uh, a new urgent thing coming up, you could see how your, your plan suddenly fell into pieces and didn’t make, uh, any, any sense anymore. So I, I love Monte Carlo forecasts, uh, because of that, because they, they take a real scenario and just give you a window, a spectrum of opportunity, a spectrum of, sorry, of delivery dates and likelihoods. And then with that information, I think stakeholders can get a much better understanding of first, what is a team going through? What’s hidden between the day-to-day world, the context which, the technical debt, uh, the people issues that there might exist. And then how, when, when can I realistically wait for something that’s important for me to be done? And that also forces you to do some, uh, to make some decisions, right? Because if 10 things are important to you and you, you start 10 things in a team and you see when, when you’re gonna receive that, uh, well, you won’t like it. Uh, but then you realize that if you choose one single thing, uh, maybe the plan looks much more optimistic now. So forces also stakeholders to make decisions on, um, on priorities. Um, what else? Um, there, there, there is a pitfall here, I think, uh, that we, we did with Joan, uh, in our early days using that. Uh, so we, we loved it so much and it turned out to be so accurate, and we can go afterwards to explain why this is accurate and why more and more teams should adopt it and, and stop wasting time on estimations and another, um, other promises. Um, but the mistake, the mistake we made at that point was, um, we, we started to trust it and like it, so at some point somebody handed us a project that was very urgent, very important, and we took, took, we, uh, Joan introduced the numbers and we said, okay, three weeks. And we said, uh, I don’t know, to the CEO of the company, it’s gonna be three weeks. And with no, no, no explanation, right? So just, just the, uh, I think we gave the 85, uh, percent of likelihood for this being done. Um, so what happened, our, our, our manager came to us and told us, like how is this possible? Sorry, what, what the hell guys? This is very important. Why, why you have to say three weeks? So we sat down and explained like, like, look, there is this, we have to do this work and then A, B, C, and then one to three, and there is this problem and there is this person that’s away, and if you look at our, our throughput, uh, this, this is the most likely date. And then it was like, oh, wow! Of course, it makes sense, but you should explain that, right? If you don’t explain that to the, to the stakeholder, it is gonna be very awkward because it’s gonna generate mistrust.
Kovid Batra: Makes sense. Makes sense. Would you like to add something?
Joan Díaz Capell: No, I would like to add, to add something on, on, on top of that, uh, before, um, before, I mean, because maybe using Monte Carto at the beginning, people can be very frustrated because it’s like, okay, a new framework, I have to learn something, et cetera. I would like just to encourage people like, uh, with this probabilistic um, mindset, um, you can do a lot of things yet without Monte Carlo. Still, I mean, as the very beginning, as I said at the beginning, as a baby steps, I mean, I’m gonna share also some examples that I use with most of the teams that I work with is like, if you have a good structure that we talk already with your features or, uh, epics and you know how you’re delivering them, there’s a very easy, I mean, um, I was taking the throughput of the feature that we were delivering per queue. And it turns out that in one queue we, uh, we released two features. Another one, three features and another one five features. So with this information, I already know that it’s very unlikely that we deliver less than two features, and it’s also very unlikely that we deliver more than five. So we, with all the, this simple information, I already have something that it’s very likely that they will deliver something between two and five. I know that the size matters and we can, in this case, it’s something that we can discuss also, which is the right sizing, which is the expectation of the, the size. But only with doing this thing and not going very deep into Monte Carlo, that it’s kind of a next level, with only this information, you can already start planning and you can give a lot of information there.
Kovid Batra: Makes sense. And I think that’s a very good advice because it’s true, uh, when you’re involved with so many other things on the delivery and like getting things done, uh, introducing a new framework that brings in another level of complexity to find out what it’s gonna get on time or not, might be a little, uh, inhibiting. So it’s good that we start with a very simple probabilistic model as you just explained. And then probably with better and more scaled projects, with more scaling of teams, we can bring in the complete Monte Carlo in place. Great, guys. I think, uh, that, that really helps, uh, at least bring and throw some light on how people should be approaching towards, uh, probabilistic, uh, timelines and not just being deterministic about it. Uh, there is another use case that I want to cover today, but it seems that we are already running, uh, short on time that way. So I would request like we, we start with the QnA, and I’m sure someone is gonna ask about that use case within the questions. And if not, I’ll ask it as a question.
Mario Viktorov Mechoulam: Alright. Okay.
Kovid Batra: So, uh, the audience is waiting. Uh, I’ll just take two minutes of break, uh, for, to have water and then, uh, we’ll start with the QnA.
Mario Viktorov Mechoulam: Okay. Uh, Kovid, I think we also, because this use case is very connected to Monte Carlo and we just started scratching the software, perhaps we can dedicate a session just to talk about it and all the, all the things that we can do.
Kovid Batra: Yeah, totally.
Mario Viktorov Mechoulam: To help this.
Kovid Batra: We can do that. Definitely we can do that. Alright, uh, let’s break for the QnA, uh, two minutes break and then, uh, we’ll join in.
Alright, we are back and we have a few questions already coming in. Uh, oh, by the way, Clint says hi, uh, Mario.
Mario Viktorov Mechoulam: I saw that. Yeah.
Kovid Batra: Perfect. Okay, let’s start with the first question. Uh, that’s come, that’s coming from Saloni. Uh, what are the most important metrics to track if we want to control tech debt? Okay, interesting question. Uh, like if we are looking at tech debt and we want to keep it under control, what metrics should be focused on? Uh, and what metrics we should be working on? Uh, is the question. Mario, would you like to take it?
Mario Viktorov Mechoulam: Sure, sure. I, I think there’s a few metrics that, uh, that people regularly track. Um, and that is, um, the, the, the size of the pull request, for example. So, um, if you have a lot of technical debt in the code, your code might be more convoluted and force you to, to do bigger pull requests, uh, then the defect, uh, rate as well. Uh, because more complicated code, uh, with more technical debt can, uh, inadvertently force you to introduce more bugs, et cetera, et cetera. So there, there is a bunch of those that people have traditionally used. Uh, not long ago I saw something that I loved and I’ve been trying to introduce to my team with not a lot of success yet. So it is there, nobody has pushed back, but it just, it hasn’t had enough traction yet, but it is, uh, tracking the days, uh, since the last time you worked on technical debt or technical health, right? So if you see that consistently at zero, uh, so, or like, sorry, uh, increasing ’cause we’re tracking amount of days since the last time you did that, you have a problem. So you want to make sure that you are, uh, consistently dealing with, with technical debt and you make sure that that is part of the, the way you work. Um, if you see yourself also, uh, planning time for technical debt, uh, you can do better. So you should be able to do that as part of your feature development, as part of your day-to-day work. You should be able to do boy scouting role. So I see this, I know I have, this is important. I’m gonna go and fix it, and things should be able to wait.
Kovid Batra: Totally. I think, uh, we didn’t touch upon that topic of capacity allocation, but there is one, uh, thing that I also have seen is that within your capacity allocation, the work that the teams are picking up, if the technical debt seems to be like normally between 15–20% of every sprint, or every month or every quarter, whichever timeframe you’re looking at, then also we can keep things under control. So in general, uh, a good number, a good benchmark would be your 15–20% of time effort allocation should be towards tech debt, we should be continually improving on that. So just adding to what, uh, Mario, you said, Saloni, to answer your question, uh, this could be a good metric to look at. Have a look at a broader picture of the capacity allocation, and then within that 15–20% should be on the tech debt. Uh, Joan, do, do you have any opinion on that? Any thoughts, any metrics that you think we should be looking at?
Joan Díaz Capell: No, uh, actually I like pretty much what you said, Kovid. I mean also, yeah, in terms of, I think that tech debt is very important. You have to, to keep them in a good shape. Uh, so you have to pay your debt. So, this means that, this means that, uh, and I like that you said this capacity allocation, because we usually, with Mario, when we say capacity allocation is, uh, pieces of work, not people, uh, not people at all. So, I think that having this kind of service dedicated to that, I think it’s, um, the best that you can do also, that you are in your debts day after day and you’re working on it so you don’t forget about it. It’s completely..
Kovid Batra: Totally, totally. I think what I, I really liked what Mario also mentioned about the size of the pull request. Of course that can, uh, tell a lot of other things as well, but size of pull request in general, if it’s large, definitely there is something going on. Uh, and it could be related to technical debt also. Great. Uh, great question, Saloni. Thank you so much. Uh, I hope we answered it for you. Uh, next question, guys. Uh, this comes from Madhurima. Uh, hey, Mario. I have a question. Uh, what kind of qualitative data should, we should collect alongside metrics to ensure better visibility and planning for engineering? Uh, I think a very interesting question. Uh, like we always look at the objective things, the numbers and everything. Uh, but along with that, what qualitative data would help engineering teams, engineering managers, uh, to make better decisions when they’re planning for their teams?
Mario Viktorov Mechoulam: Mm-hmm.
Kovid Batra: I think, uh, Mario, uh, this has come to you specifically, so you can start.
Mario Viktorov Mechoulam: Yeah. Interesting. It’s like if they, they knew me. Um, it’s a very good question and I’m not sure I have a well prepared answer for that, but, um, I would like to connect this to tracking some form of wellbeing. And I wouldn’t do that just for, uh, visibility and planning. Uh, that definitely can have an impact. I would do it for everything. But if you have your team consistently being unsatisfied with the type of work they’re doing, uh, feeling burnout, uh, working over time, not feeling that they have the time to do their best, forced to introduce technical debt, et cetera, et cetera, so this will, of course you have metrics for this, uh, that are quantitative, but this would, would reflect in their wellbeing, in their engagement, in their motivation, in, in if, uh, in if, if they have the opportunity to work on things they love, that they can put their strengths and motivation in. So I think you should track that because otherwise many things that might otherwise look like, oh, it’s the perfect plan with the perfect delivery date with the, uh, I don’t know, um, might, might suddenly fall into pieces. Uh, not, not because, uh, the, the way you, you, you use for building the plan and forecasting and, and dealing with the day-to-day of the team is wrong, but because of simply their wellbeing.
Kovid Batra: Makes sense. Makes sense. Uh, Joan, would you like to add?
Joan Díaz Capell: On the qualitative realm, maybe, uh, maybe I will try to ask something like, um, are the goals clear for you? Maybe, um, do you have any pain during the planning? Um, I don’t know, what else? Um, do you think that what you’re delivering makes an impact? Something like that. But these are not the questions, I mean, don’t take the, that question for granted. Like these are the questions that you have to take, to do, uh, or to ask. Um, I’m taking these questions because I think that, that some company that I work, they were kind of the pain points that some people were complaining, so I would say that when we talk about qualitative data, I would say listen to people, try to understand what are the pain points that they have related to that particular topic and bring it into your data, you know, to see how they are improving. So they were taking back the benchmarking thing again.
Kovid Batra: Makes sense. Uh, the next question, uh, this comes from Aksh. Uh, hey Joan. Uh, my question is that we are dealing with delays in and out. Most of the time it’s because of cross team dependencies and handovers. Uh, how can we track this and optimize for it?
Joan Díaz Capell: Well, what’s in front of a complex problem? So there’s not a simple solution for that. Um, so again, um, when there’s this kind of, how do, what do you do with these kind of dependencies? Do you manage dependencies or do you break dependencies? So I will go first to go deep on that, to understand why do you have these dependencies? Because if you are managing dependencies, you will always have delays, to be honest. So first of all, I will try to see if you can break these dependencies. Breaking dependencies, there’s a lot of things. I mean, I don’t know. I’m gonna make it up. Okay? Maybe they are silly or not, but maybe you have a front end, a backend team and doing these things, things together. Maybe you can mix them and have a functional team or not. Maybe you have a team that is more focused on a particular product and another, another product, and there are dependencies. They have dependencies, but maybe they, you can do the other team that is this product that they’re working or they are sharing some kind of technology. I would go first, first with that. If you cannot do this or this is not possible, I would say that, um, with all the things that we were saying, all these models like understanding the right size in your epic level, um, forecasting, et cetera. This is something that you can visually see. And this is these kind of models that, um, forecast your delivery. Something that with just one click, you can execute. So this is something that you can day after day track and manage it, and you can improve a little bit the, the, the, the pains that you’re having on the, on the, the dependency level.
Kovid Batra: Makes sense. Makes sense. Uh, Mario, uh, would you like to add?
Mario Viktorov Mechoulam: Just one thing. Uh, I think Joan’s answer was spot on, but, um, he once told me something that I think is, is perfect for this situation. Not, not if you just want to track it. So if you want to track it, you have ways to track, uh, waiting, handover, blocked time, review, whatever. Um, but if you, if you want to, to improve it, to fix it, to prevent it, as he said, breaking the dependencies. Uh, I, I would, if you are, if you have the power or if you, at least if you have the influence, I would move those teams closer together. Because if you have teams that are part of a bit of a wider group that share OKRs, then suddenly, yes, you have dependencies. But these dependencies will more likely be collaborations. You’re both working towards the same goal at the same time, because normally your OKRs have, uh, like these windows, three to six months, uh, maybe even a bit less depending on how you, how you do them, right? So by moving the teams closer, um, you have them working on the same OKRs and you probably have much more opportunities for touch points and synchronizations just naturally, right? Just, just as part of how the group works together or, or this part of the organization.
Kovid Batra: Makes sense. Perfect, guys. I think, uh, one last question we will take, uh, that’s from Nisha. How do we make sure that there are not too many work in progress items for the developers? Okay. That that’s..
Mario Viktorov Mechoulam: That’s always the way.
Kovid Batra: Yeah, that’s always the problem. But yes, uh, let’s, let’s answer it to our best, how, how we can, uh, get rid of that or improve upon that.
Joan Díaz Capell: One. One of the things that, uh, I used to, I mean, I tried to, this is the best ever thing, but one of the things that, uh, I tried to do is we were discussing about high level, uh, pieces of work, like more epics and features. So what I’m trying to do with most of the teams is that at the very beginning is we are working in one feature, so just lot of focus on this feature. Just the, the thing that we are limiting the WIP on a feature level, you are already impacting on the WIP that developers get, because if you start working in 10 features, that’s even more complex to jungle around, trying to play some, play some tetris, et cetera. So I would say that at the beginning, start putting your focus on limiting the WIP on the epic and feature level. And then you will see, you can add more. But first, limiting this, I would say.
Kovid Batra: Makes sense, Mario.
Mario Viktorov Mechoulam: Great, great. Um, I think this is the way to go. Uh, if anything, I would add some, some, so if you want to put some numbers on it, there is, uh, an experiment, uh, we’ve been running, uh, for a while, and that is, uh, you probably want to have less items in progress. And not talking about feature, but just the, the database, small tasks or whatever.
Kovid Batra: Yeah, yeah.
Mario Viktorov Mechoulam: Uh, less, less than number of people in the team. Number of engineers. Why? Why? Because if you already have some number of tasks that are, that is higher than the amount of people in the team, people are context switching, people are multitasking, things are waiting, you’re generating waste. You’re doing badly. But if you have the same size of, uh, the same amount of tickets and size of the team, it means that nobody’s collaborating or collaborations are very, um, unfrequent and maybe just happens through pull requests. But you, you would want people to be, uh, helping each other, to be doing pair programming, to be, uh, having brainstorming sessions on how to do this change in the architecture, uh, what happens with the design. So you probably want to keep that number always lower than the number of engineers.
Kovid Batra: Makes sense. I think that’s, that’s the magic trick here. Uh, like if we look at that metric, it would definitely make sense and always the work in progress would be not too many, it would be limited and people will be able to collaborate, get time for it. Makes sense. Makes sense. Alright. Uh, see guys, uh, we planned for more things to talk about, but unfortunately we’re not gonna do that today. Fortunately, if Mario and Joan are available sometime this month again, we’ll bring them back on this webinar and talk about, in depth about Monte Carlo, talk about capacity utilization and few more things that are already in the pipeline. So for today, uh, and that’s our time, that’s our time. Uh, but we’ll definitely join in for the next session. Uh, one thing before we leave, uh, we always, always want you guys to share some parting advice with our audience. So again, I will go with Joan first. Uh, Joan, uh, any parting advice for the engineering managers and the engineering leaders listening out here?
Joan Díaz Capell: You always, I think that I, I can finish with what I, uh, with what I start at the beginning, like, uh, curiosity. I mean, be very curious. Um, I like to say this kind of be like a beginner’s mind, so put everything in, uh, into a question and try to understand why all these things are happening. Don’t take anything for granted. I mean, just be very, very open and, and be, I don’t know, question everything.
Kovid Batra: Good piece of advice I think. That’s, that’s the first step towards making any kind of progress, because only when you explore, you understand what’s out there to improve upon and do things. So totally makes sense. Mario?
Mario Viktorov Mechoulam: To expand on that and to connect with the drainpipe with the initial questions on framework, um, uh, there’s a lot of things out there. Um, so don’t, don’t jump on the first thing that somebody, uh, sells to you in terms of framework. Um, you, it’ll take you some time to feel comfortable with what you see and to become an expert, and you’ll do that by, by experimenting as Joan said. So, start small and build up from there.
Kovid Batra: Totally. Great, guys. Thank you so much for your time today. It was really nice talking to you. Uh, we would love to have you guys back to talk more about such things. Uh, but today it’s goodbye. See you again. Thank you.
Mario Viktorov Mechoulam: See you soon. Thank you.
Joan Díaz Capell: See you. Bye.
.png)
.png)
.png)
.png)
.png)
.png)
