In this episode of the groCTO Originals Podcast, Kovid Batra talks with Jagannath Kintali, former Head of Engineering at Dojo and ex-startup co-founder, about building impactful engineering teams focused on customer delight.
Jagannath shares his extensive experience of over 18+ years in engineering, discussing the importance of building what is needed rather than overshooting with extravagant systems. He emphasises creating high-performance teams through trust, purpose, and customer empathy. Jagannath highlights his journey, the learnings from his startup, and how he implemented these insights at Dojo, including stories about curtain ordering systems and observability projects. This episode provides valuable insights on leadership, team building, and aligning engineering efforts towards solving real customer problems.
Kovid Batra: Hi everyone. This is Kovid, back with another episode of groCTO Podcast. And today with us, we have a very special guest. He’s Ex-Head of Engineering, Dojo. He has been an ex startup co-founder. Welcome to the show, Jag.
Jagannath Kintali: Thank you very much, Kovid. It’s, uh, it’s been a pleasure and thank you for having me on your show.
Kovid Batra: Great. So for the audience, uh, Jag is short for Jagannath and on this show, I think we’ll be calling you Jag. Is that okay with you?
Jagannath Kintali: Oh, that’s absolutely fine. Thank you. Yes, uh, Jagannath, it’s usually not the most common name in the Western world. So short form is Jag.
Kovid Batra: Yeah, that’s, that’s really cool. I think, uh, be a Roman when you are in Rome. So, that works. Yeah.
Cool. So, uh, on that note, like for the audience, um, today’s topic is. How to build impactful engineering teams that really build for the customer delight and I think Jag has, uh, really good hands-on experience with nurturing such teams. But before we dive deep into that part, I think we would love to know more about you, Jag. You have been a startup co-founder and I think it’s been a long journey of 18 years in the engineering world. Tell us something about yourself so that audience, audience, gets, gets to know you a little more. Um, your personal life, your hobbies, what you have been doing, uh, maybe about your startup.
Jagannath Kintali: Oh, absolutely. Uh, I am, my name is Jagannath. Uh, I actually do come from Orissa where Jagannath Puri, uh, Lord Jagannath Puri hails from. So after, uh, being there in Orissa, I’ve done my engineering, uh, I decided to come for a master’s degree in the UK and that’s where I started my software engineering career, uh, so to say, started as a, a software engineer, but once you come from, uh, this background of engineering and add a world to explore, but obviously the Western world was, uh, and especially UK was completely new to me, and the opportunities that you see over here was, uh, so many, I always wanted to go into building something of my own and having something of my own and to start something which will serve the community and, and a certain customers segment in general. And so, I ended up doing after several years of doing software engineering roles and especially my expertise is in solution architecture. But after several years, I decided to take the plunge, like everybody else wants to do that. But yes, I got to warn everybody and the audience that my startup does belong to the 9 failures out of 10 that all the startup happens. But I’ve done that and I have no regrets in giving it a try and doing that, but it is the most, uh, beautiful experience I had during the startup time, and we tried to do it for just over two years. Um, but yes, it was all about, uh, hyper local services, providing services to, um, customers within a certain community. But yes, ever since then, um, I’m still very much passionate about engineering and what I’m very passionate about is building or engineering beautiful products for customers who, you know, have a need for it, a particular challenge that it solves. Solving the customer problems is my main aim in life, and I’ve grown up in a, um, you know, I’ve grown up with the ethos or the principle is that, uh, to service, you know, uh, godliness. That’s where all it comes from. But yes, learning to be a, a pilot, which has been a dream of mine for a very long time. So let’s see how that goes. So hopefully I will get that license in this lifetime.
Kovid Batra: All the best to you for that.
Jagannath Kintali: Thank you.
Kovid Batra: Uh, you, like you said that, uh, you had this beautiful experience of, uh, being a co-founder and having that startup experience particularly. Um, what, what was your major learning from it? Like if I have to say like when you came out of it, I’m sure, uh, it’s never a failure, obviously. I mean, I have been..
Jagannath Kintali: Absolutely.
Kovid Batra: So what you learn out of it is something which is very different from what you do in a job. You get such a holistic experience of solving problems and building solutions when you are doing things as a co-founder or probably as in the leadership of a startup also, for that matter. So what was your learning from that journey? If you could, uh, like highlight that for us.
Jagannath Kintali: My total learning, as you said, it’s never a failure, and actually based on the learnings from the startup, I’ve had many successful jobs based on the learning from, uh, from the startup and, uh, I’ve had many, uh, many times, uh, uh, tried to think about and summarize what, what were the things that I could have completely done, uh, differently, and that’s what I keep on using in my future roles. And I boiled it down to basically three, uh, different learnings. First of all, it was the product. Then second comes the, uh, people aspect of it and how you execute it. Those were the three areas that I, I think, uh, were the three main learnings. First, it was the product, that service that we were trying to provide. It was a very simple concept. It was a matchmaking process where somebody as a service holder can provide the service to a person who is in need of that service and a very hyper local at that point. So within, um, 15, uh, 20 minutes, you get your service, uh, sorted, whether it is, uh, looking for a cleaner, whether you’re looking for a locksmith, or whether you want to, uh, wanted somebody to get some, uh, grocery from the store, uh, to you. Now, nowadays, it sounds like it’s so common. It wasn’t that common in 2012, 2013 when we, uh, started this. But, uh, the first learning was we, the opportunity was so big, we got a little lost, in my opinion, as to which area we should concentrate on. So there were just so many avenues we wanted to go down on. We should have, uh, probably own down in a, kind of set of services and tried to build that platform and repeatedly perfected or make it much more efficient, the process of end-to-end, somebody requesting for a service and somebody getting a service and the feedback loop going back and forth and repeatedly doing that through our systems, through customer feedback and through the service, services that we provided, particularly one or two. We tried to widen it straight away with 10 to 12 different services. And what happens is every service type has, uh, different kinds of needs that the need of a, uh, a cleaner or a maid, uh, you’re looking for a maid is completely different than looking for a locksmith, or, uh, you know, looking for, uh, a nanny’s, uh, completely different and trying to, uh, funnel all of those requirements and make it efficient into one single channel was the most difficult thing. What we should have done is just pick one particular vertical, try to get some traction on it and then you will realize and you will have your learning and then use that learning in other services. Slowly added that.
So being in a particular and it is very behavioral because this is not a Uber, uh, type concept where you have the service being provided outside your house. The service we were trying to provide was within the house. So there’s a big trust factor that needed to come in. And every country that you go to, we were trying to do it in the Middle East, where, uh, it’s a service Mecca. Um, and we want to get some traction over there, but I was in London at that time. I did not spend enough time, uh, I’ve been there quite often, but I do not spend enough time. Be there, be emerged into the local community and try to figure that out by yourself. Going back to the first principles of totally immersing yourself into finding out where the needs are, what the actual requirements are, where the actual inefficiencies are and how to join the dots. Trying to sit completely away and trying to, uh, uh, totally imagine the inefficiencies and, and not looking at the reality was probably one of the, uh, challenges, uh, uh, we faced and the biggest learning, uh, I’ve had in, in, in doing that. And second, uh, on the people side. That was on the product side. People side, it brings me, uh, uh, to the, it’s very related to the topic that we’ll be talking about. It’s building that very strong team.
When you are a startup, it is very difficult to get the right set of people and, uh, you’re looking for funding, you’re looking for finances, you don’t, uh, uh, you are not going to get, uh, you know, the star players that, uh, you wanted on your team from day one, it is very difficult to do that and also trying to build a, uh, build a team, which is totally dedicated for the purpose. What we did was, okay, let’s go out and find a team, whether it is a third-party software provider, uh, or software consultancy, a small outfit somewhere, and try to bring them in. What we didn’t do, that would have also worked, but what we didn’t fail to do, in my opinion, is, is, uh, giving them that purpose. So they always worked as a consultant. They were not integrating. They were not, uh, bought into the product that they were trying to build or the company. Uh, company had a mission, company was trying to solve a particular customer challenge. We did not expose that particular team to that area, and they were just literally taking instructions and building a software system. They didn’t have the direct interaction with the customers or trying to understand the customer problem that we were trying to solve. Uh, that, that, that was the biggest gap, and this is where the impactful engineering comes into play. I’m a true believer in building teams which are totally exposed to the customer challenges. That doesn’t mean that you have to go and talk to the customer every single day, but you’ve got to understand the customer problem that you’re trying to solve on a single, every single day. Find out why, why it is that you are doing and everything that you’re building, how it is impacting the challenge you are trying to solve. If you don’t have that, if you don’t have that purpose, if you don’t have that, uh, you know, the belief that you are actually doing something, which solves a customer problem, you have lost the interest, the engagement of a particular team, and that’s where it goes downhill.
We’ll talk about many different things, and, uh, I’m sure we’ll go in-depth into it. But, uh, those were the biggest learnings and the execution of it. Obviously, being in 3 different geographical locations, we were trying to coordinate and do that. If you want to do a startup, be there, be in the location, be amongst your customers, understand the problem, even be the person who is even delivering that service and, uh, and try to understand the entire life cycle of a product. It’s not about building a software system, which you think will be very useful. It is, uh, if there are no customers who are using it and customers are not willing to pay for it, it’s not going to work out for you. It’s always going to end up in a, uh, well, 9 out of the 10, uh, do fail as starters because of that reason. So, you know, those were my biggest learnings from doing a startup, but I wouldn’t change, uh, this experience, uh, ever. I mean, it was, it was probably the hardest two and a half years of, of my life, we lost a lot of money also, uh, but wouldn’t change the experience for, uh, for any amount of money, for sure.
Kovid Batra: Perfect. I think, uh, the best part about such journeys, uh, are that in those hardships, in those times, you actually see a significant change in your mindset, how you think about things. It’s more like reality coming to you. Uh, it’s, it’s more like reality slapping you, saying that, okay, this is how things should be working, right?
Jagannath Kintali: Yeah, absolutely.
Kovid Batra: So, uh, I think that’s when you, you evolve the most. I mean, according to my understanding of how one should be, um, leading life in this universe is understanding more of world concepts, how reality works, the more you become empathetic and compassionate towards people, nature, how things are working around you, the better decision-making you bring into your, yeah. So I think startup has done that to me at least, and I feel the same when you are talking about, uh, realizing that it’s about building great teams also who focus on customer empathy, like customer delight, so that they can bring out those solutions which really solve the problem. You just don’t become a feature factory delivering features, taking instructions, delivering features. You actually deliver value. That’s how the mindset changes. And on that note, I think, uh, which is, of course, the topic for today, now when you are like four or five years ahead in that journey, you have been leading an engineering team for Dojo, I’m sure you would have incorporated some level of, uh, framework or some level of practices which inculcate this customer empathy or, uh, teams that are fundamentally aligned towards solving problems rather than just building features. So can you tell us about some of your experiences in your journey, how things worked out for you after that, and how you implemented this learning in your, in your teams?
Jagannath Kintali: I’ll start with the story this, uh, while having this conversation, it just came to my mind, previous to Dojo, I worked for it, uh, I was working for a software consultancy and I was working for it, uh, one of the biggest retailers in, uh, in the UK, and, uh, uh, I’ll tell you my first, uh, foray into, or the first time I ever was so delighted, uh, with the work I was doing. So the story goes as if that, so this biggest retailer, they, so it’s a super, um, what is it called? A superstore. They sell from food to clothing to anything, you name it, and they sell it, and they also sell curtains. So this is early into my career, and I’m in this, and I’ve been given this responsibility to design a curtain ordering system. Like, I have no knowledge about curtains. I didn’t even know that there were so many types of curtains that existed in this world, there’s so many textures, the type of cloths, and how the look will be, how to hang it, and all of those, but again, never interacted with any of the actual users. It was a consultancy. So, you know, you went into a dark room, you designed a system, and, and you deliver it to this, uh, retailer. It took my time trying to understand that the business, how the curtain, curtain ordering system works and how it goes from A to B, and when customer orders and it goes to the manufacturer, it comes back, uh, to the retailer and how they deliver it. Everything was beautifully fine, and, and went in, you designed to the best of your ability, right? Uh, trying to understand what the customer might need or, or the shop, the shop assistant who’s using your system to provide this service to the, uh, customer, but somehow we managed, we had a conversation, the system was delivered on, well on time and, and so. But, uh, I never felt like I, uh, so proud of, uh, this project, you know, it’s, it’s, I always used it as a job, okay? I went to work, I did some coding, I built some systems, it’s running absolutely fine, it is delivering what it’s supposed to deliver, you input A and the output B comes out, and those were the right input and output everybody was looking for. Job done. But then I was, in my off day, I visited one of these retailers and I went to one of the stores and I was with my partner at that time. So we were both visiting the store and I was trying to figure out how could I use this system that I built. I wanted to show, okay, I built a system, but I actually went and ordered some curtains at, at this store and the lady who was, uh, uh, serving us in, in the store, she pulls out, uh, an, an, the device, that were hand-held devices that they were doing, and she pulls out the system that the UI that, uh, was built by me and, uh, and two other engineers. And as soon as I saw that, uh, a UI and the ways she was using it, the satisfaction I got and the joy, that the happiness that I got just looking at, uh, and you know, your, uh, hard work is being utilized by somebody, and, and it is being very useful to somebody. On that day forward, onwards, I’m telling that something completely changed in the way I think and the way I approach and, uh, approach my work and the way I try to find that delight every single time I do something in my professional career, it completely changed.
And the best learning, uh, we were talking about in the introduction is the best learning from my 19 or 18, 19 years of engineering, uh, leadership, one thing that I have learned from, uh, uh, some of my senior engineers, I was in a project, one sentence that sums up all of it, ‘Build what you need, not what you want’, because there is this thing that we always overshoot. It’s, it feels like we should be building this, uh, uh, wonderful system, the most efficient, the most effective and do that. But no, you just need to build something which you need and the customer needs, that’s the most delightful thing that you can do for a customer and providing that talent. So that’s one of the best things that has ever happened. And from that moment onwards, this is what, how it has changed my, my perspective on software engineering in general, and how even in engineering leadership.
So coming back to the, I know it’s a roundabout way, but then coming back to the original question about how I’ve done this in my, uh, you know, my, my stint or my, uh, my work at, at Dojo, I tried to find the purpose or, or even build this purpose within a team. Building a high-performance team, in my opinion, it’s nothing to do with tech. It’s nothing to do with what you are trying to achieve. It’s about building that trust and finding that purpose every single, you will find, uh, a star, uh, engineers. You will find all the, uh, uh, right people in the, uh, uh, right places. But if they don’t have a purpose, if they don’t have a goal, they don’t have a direction to go towards, none of this works. And bringing that trust factor is the clue that will bind the team together in moving towards that goal, moving towards that ultimate aim of delivering that customer delight or the impact, customer impact that I keep going back to. And my way of doing it, there was no framework. There is, I know this might be very controversial and there’s nothing to do with frameworks or there’s nothing to do with, you know, reading books or, uh, uh, engineering leadership, it was pure and simple, uh, people’s relationship and building relationship and understanding each and every person within your team that you have. And the more you do it, the more it trickles. I started with a simple team of five when I started, I ended up, uh, when I finished with Dojo, finished at Dojo, I was looking more than 60, 70 engineers at a time. But once you build this environment where you build relationships, you build, you play the long game, not, never a short game for, for the purpose, you build relationships, try and understand each and every person who is within your team, what is that purpose and give them that purpose, give them that direction, give them the, uh, validation and recognition, which is the most undervalued aspect of software engineering. You provide them the right scenarios and the right environment, you will have a high-performing team every single time. I can guarantee you that.
That’s, that has been my mantra. It’s about personal relationships and building relationships and understanding people and going back to the first principles, and why we are doing it, give them the same input. Usually, I mean, it’s almost like if anybody replaces you as well, every team member within a particular team should be able to reiterate the same purpose within the team. So that’s how I always see it. Everybody having the same mentality and, uh, you know, the collective high mentality and trying to achieve that same goal, does a lot of good in a longer run. Uh, you might not see that in a shorter term, but for a longer run, it is the most, uh, the best thing you can do.
Kovid Batra: I think I absolutely agree with you. And in fact, uh, you said there is no framework as such. This is what you do and how you achieve things to build better teams. But I think this is the framework, according to me. Like on your behalf, I would just say that if you really want to build a team that cares for the customer and you are the one who is leading the teams, you build that relation, you build that trust with your team members, and every discussion, every sprint or every procedure that you are following to build something, if you’re putting that out in your thoughts, putting that out in your documents, maybe even if there are some PRDs where you are mentioning why we are solving this along with what needs to be built, I think that’s when you crack the things, because every day, if there is a discussion in the room where we are talking about solving the problems for the customer, automatically everyone starts thinking like that. Of course, there has to be a first-level trust built to be, uh, to be there where everyone looks up to that mindset which you are adopting or if you are preaching that. So this is the key, I believe. Like in every team, whether big or small, you just need to make sure that whatever you are following as a philosophy while building products for the, for the customers, that needs to propagate in every discussion, every document that’s going out from you and people would automatically start following it, and I think that’s how things over a long term would, uh, get imbibed fundamentally, uh..
Jagannath Kintali: Fundamentally. It’s the basic fundamentals that you, uh, uh, that you target and everything, uh, everything falls in place afterwards. And one of the things I’ll tell you for sure, like once you have this, your work becomes a side effect because you are building that, uh, mentality. Are you building that mindset across? The team, you move like a single unit and move and try to target, you know, what you were aiming for. The one thing I actually forgot to mention, or I wanted to bring up is that, you know, people talk about resolving conflict. How do you resolve conflict if there are two competing ideas and which is having, you know, you are having heated arguments or discussions about what is the best way to move it forward? I ask simply the question, which one, which solution will have the biggest impact? For our customer, the problem we are trying to solve, can it, which one does have, and there is always a single solution, there is never a multiple solution which says, okay, this will have, whether you count that as a, uh, how beneficial it will be for the customer, the cost impact of it, or how long-term effect it will have, how it will even have, uh, reduced tech debt, also in the longer run, you will find that asking that question, which one will have the better impact or most, most impact for the challenge that we are trying to solve, then you will, in terms there, there is a resolution always, most of the time.
Kovid Batra: Okay. Yeah, yeah, yeah. I totally get it.
Jagannath Kintali: And every sprint, what we used to do, uh, we do use the uh, uh, you know, the sprinting method as well, in every sprint, we will reiterate. We follow this OKR process, the, you know, and the key results and objectives and key results. Every sprint, we will try and make sure that the objectives and key results are pretty aligned to the needs of the company. First of all, you have your customer, then you also have your company goals to meet as well. So you have to keep this in balance in trying to go through. Make sure that it is still very much valid. It’s still very much aligned to what we are trying to move towards. It’s, it’s, it’s a pyramid kind of structure, if we were to talk about frameworks that we are doing, each and every team needs to do, set their own objectives and key results that they want to try and achieve. But those objectives and key results, need to also come from top-down. So we meet in the middle. So you have very strategic goals set by the founders of the company, Execs, right from the beginning, and then they will say, these are the different areas that we will be targeting on. And, you know, the squads and basically the teams will set their objectives accordingly from an engineering perspective, from the product perspective, and they meet at the middle. That’s how we have always looked into doing that. So it is very aligned. It is very, very much towards the company and the customer aims, uh, or the customer challenges that we are aiming for. And that’s how, uh, in my opinion, that’s, it is not, it is never going to be perfect, but the best results we have got so far is by this OKR framework.
Kovid Batra: Got it. Got it. I think, um, one more thing that I realized, like setting up these objectives and key results definitely brings that structural angle to solving the problems and doing something as a team. But going back to the first point from where you started with a story, I really loved that. And as a, as a, let’s say, as a team member, let’s say, you have been a, an, a leader for the team, if this is something how you would explain something to the, uh, the team members, the developers that how one should be thinking about things, I think that can also go a very long way, right?
Jagannath Kintali: Long way. Absolutely.
Kovid Batra: So basically, getting those team meetings sometimes around, uh, sharing such stories where they actually, uh, experienced what customers feel like, getting into their shoes and experiencing something, and then going back to your desktop or laptop and coding, I think that also is a big, uh, big-time need for, at least for the developer space, because it’s most of the time they’re coding in their own zones and there is a very big disconnect, but if, if we propagate this thought and we incentivize this thought, I think that can also go, as I said, long-term, in terms of building teams that are able to think with empathy, compassion for the customers.
Jagannath Kintali: There’s another story I would like to, uh, tell you. It’s, uh, in, in Dojo, we wanted to, um, introduce, uh, a particular engineering paradigm regarding, uh, observability, right? So the whole idea is that every single system that is, that exists in, in Dojo, we should be, uh, it should be totally observable. Uh, we should know about how it is performing, where it is, how, how much traffic it is coming through, how much CPU or memory, the whole shebang. But it, it was a very, uh, nice, a niche, a concept that we were trying to introduce in Dojo. Dojo was in, in, in its journey to, in its scale of journey. So how do we do that, uh, impact? How do we even, uh, build this, talk about this story, how to, how useful this is going to be, right? So what we did is that we did a very small project and we put it out regarding observability and we called it the ‘architectural pane of glass’. We used to, well, Dojo has a massive, uh, TV screens within the engineering floor, where we are displaying numbers and Grafana dashboards and, uh, you know, all stats flying around. What we did is we took a complete product and every component of that product, we devised it. So it was basically a Grafana dashboard, and every, we broke it down to different parts of the, all the components that builds that system and the system basically builds the product. And we showed everything pictorially on this Grafana dashboard, and every time any problem that would happen within these particular components or systems, it flashes, right? It’s saying, hey, there’s an error, uh, and there’s a metric failure or all the, uh, SLAs and SLIs that you have set, which is dropping down. You have the variants and all of that. It’ll start flashing. What happened, uh, by doing that is, is that every person who passed that, uh, screen, uh, and we have multiple products in Dojo, so any other product members who were passing that, including our CTO and founders, so every time they will pass this screen, they would stop by this screen, right? And they would say, Oh, what’s this about? This is something that we haven’t seen. And this is and ‘red, green’ is a, you know, universal language. You know, if it is showing red, that there’s a problem. It is green, then it is all going well. Oh, why is there a problem? And it became a conversation starter.
Kovid Batra: Got it.
Jagannath Kintali: And what we were trying to push for is, is, is the effective way of operation, uh, of all the different systems. And what we did is building that team who would say, and it was right next to where the team was sitting down, right? So every time somebody came around and talked about, uh, this big screen, the team would really feel, uh, very good about what they have built. They can see the usefulness of this product that we were trying to push for. And what that resulted in, we got the funding to build a team, we got the funding to afford and take that even further and spread it across entire Dojo Engineering. And I, last time I checked, I haven’t been to Dojo in a while, but, uh, the observability system that we have built is uh, I can put my hand on heart and say, probably one of the best in the UK market or in, in, in the FinTechs. I’d go even further in the world, but I haven’t seen many of the other systems, but it’s one of the best systems that we have built. It’s been a journey of two years.
So what I was trying to get to is that even doing small little things and having that customer delight, in this case, it was an internal community of engineers that we were trying to do. But you can see how you can capture the imagination of the customer and uses that you are trying to solve the problem for and get them engaged. And it’s a two-way street. Because the customers are getting engaged, the team is now getting engaged, and they are finding that, oh, uh, you know, that people are talking about this particular product. I was meeting with this person from that particular team and they were saying, hey, how can we, get that system built for us? And it becomes a starting point and starting conversation point, and it spreads all by itself. What about there was no company direction or a top-down approach in doing that? This is doing things very organically and trying to capture the imagination and showing that, hey, this is also possible, this is something that can be done. And, and of course, the product was very useful. We didn’t have as much observability into our systems as, you know, previously, this allowed us to observe our systems even better. So it worked out beautifully and it’s a story that I will probably never forget for as long as I am in this profession. It’s how all of the observability team started from there.
Kovid Batra: Got it. Got it. Amazing. Amazing. I think, uh, this is really a good example where not just thinking about customers who are business customers, but these developers, these people are your internal customers who you have to cater. And as a leader, if you become compassionate and empathetic about how you can actually make them, uh, push towards success metrics and think, think about things which they would align with and bringing this at such large scale, ultimately, would impact your customers also. So I think a very good example shared here and it was a really, really good session.
As we are moving out of time, now I would like to take this to a close end. Thanks a lot, Jag, for bringing such beautiful, beautiful insights on how you can actually build great engineering teams and sharing your experiences at Dojo. It was a lovely, lovely experience for sure.
Jagannath Kintali: Thank you very much for having me on. And it’s always nice to go back to, we, we as engineers, as professional, we don’t usually do this enough where we, uh, stop and, uh, take a pause and look back in our previous experiences, and, and it brings me great joy to even talk about all the different experiences and it, it brings a smile to my face as well. So it was very delightful and, uh, delightful for me as well. Thank you very much for the opportunity.
Kovid Batra: Great. Um, we would definitely love to have you back sometime again, uh, talking about more such engineering challenges and how things work out in the engineering world.
Jagannath Kintali: 100%.
Kovid Batra: Thank you for today. Thank you, Jag.
Jagannath Kintali: Thank you. Have a good day. Bye.
Kovid Batra: Thank you. Bye.
Implement DORA metrics, gain dev visibility & drive success in your teams.
Try Live Demo
