Startups have been and will be a big factor in powering India to be a $5 trillion economy. Startups have a need to grow the customer base, product offerings, scale their technology and grow the teams. Succeeding in all of these parameters in a rapidly evolving environment is what makes startups successful. Agility enables startups to conquer these challenges. An agile culture is very important for successful Agility. The 3 pillars of building such a culture are alignment of goals, decentralised decisioning to attain those goals and a continuous feedback loop on decisions’ outcomes.
More details: https://confengine.com/conferences/agile-india-2022/proposal/17248
Conference Link: https://2022.agileindia.org
We welcome you all to the section spurring Growth with an Agile Culture by Ramkumar Venkata ram has more than 24 24 years of experience in adtech, big data, ecommerce, US and database both in US and Indian markets. And he has also got an extensive experience in quality engineering and tech processes and managing teams. So over the course of his career he has led engineering operations for many tech driven companies in many industries. Currently he's the SVP of Engineering at Cashfree. Without further delay, I'll hand it over to you Tom. Thanks Jay. And first of all, I want to thank all of you. Happy Friday morning and it's great to be here at the Agile India to Rejuven conference. And after the covered two years of it, it's really great to be talking to people, sharing ideas and we expect to do this more in person next year. So a little bit more about my background. I actually crossed the 25th year since I filled in that for the India conference form. So it's been a great journey and Lot has changed since I started my career 25 years back. A lot has changed. Lot has also not changed but one thing that has changed significantly is agility or how we build products. And that has significantly changed. My first company, it used to be 18 to 24 month release cycles and that was the norm at that time, right? So 18 to 24 months and even if that product release got delayed, it used to be by order of six months from that time to now. In 24 months, company is born, goes through multiple rounds of funding and is able to have a significant impact by two years. Right? So this is a huge tectonic change on how things are developed, how things are reached, customers, et cetera. So a lot of things also need to change underneath and that is going to depend a lot on agile culture. Right? And growth is extremely important. And that's the topic for today that I thought we will discuss and share my thoughts and we will also have 15 minutes at the end of the time to hear from all of you. If you have any questions or you want to add from your experience, that would be great to hear. And the last three companies that I've been with has been with startups, two in a tech startups and the current one is a fintech startup and I've actually seen day to day. Right. What are the different challenges of growing? The startup needs to grow in revenue, it needs to grow in terms of products and features and the team also needs to grow and scale. So it's a day to day thing that we've been seeing and why it might be a little bit overwhelming but it's very, very challenging and refreshing to be able to make things happen. Yeah. So today we will talk about Agile culture and how it is the foundation for growth. A lot of things needs to fall in place for growth, but an agile culture I think, is the foundation that makes everything else happen. And we'll also spend a lot of time on how it can be done and how we've done a few things and what has worked for us and what does not work for us that is also very important. I think many times we do talk about the why. Why is extremely important, but after we agree that, okay, this is going to be very, very important, how do I actually grapple with the real life situations and how to do it at this moment? I also wanted to recall one of my favorite professors that I did my parttime MBA there, Mr. El Prasad. And at that time he had said that organizational culture and organizational behavior would be the most important thing, that you folks will be grappling ten years down the line when you are leading teams, when you're working in teams, etc. Right? And at that time I didn't believe it that much, but he couldn't have been farther from the truth. It's about exactly ten years since he spoke those very wise words and we spend a lot of time on building this and improving it and sustaining it. And I just wanted to thank him for his guidance. We'll start the day with a couple of very wise sayings by two scientists, one by Stephen Hawking and another by our own Natal Gala. The first one says intelligence is the ability to adapt to change. So change is a given. And Stephen Hawking, we all know he's a very, very intelligent person and he is defining intelligence as the ability to adapt to change. Scientists also a lot of things actually change. They do a lot of experiments, they have a lot of hypotheses and then things don't exactly go the way they expect or they have to change their hypothesis, we do the experiment, etc. For. So I think he has very nicely put this as intelligence ability to adapt to change, that's external changes how we respond to it. Then Abdul Kalam says you cannot change your future, but you can change your habits and surely your habits will change your future. So this is the second part. So how can I change internally to be able to change my future? So this applies to an individual. This applies to a team, which is nothing more than sum of individuals and then a company, which is nothing more about the sum of teams. So we may not be able to change the future directly, but if we can change our habits, then these habits will definitely help change our future. So I think these two things sort of embodies what agility is about, right? Agility is not so much about processes or tools that we use and today we're not going to be touching upon that much of those parts. Those are very important to get right. But the more important things are the agile culture. So why identity? We spend a little bit on that. I'm sure a lot of us have answers to this. Why Agility? There are multiple very valid answers to that. I'll try to summarize some of it that's very relevant for us today. In 2022. The first two, the goal and world class from India, sort of relevant to where India is today in 2022, after 75 years of independence and sort of doing a reset at that time, right? And then the three and four is for global. Right? Globally, all organizations are faced with the same things. We have the goal, ambitious goal of becoming a $5 trillion economy. And recently, we've become the fifth largest country in terms of GDP, and we want to be number three, and we will be number three in the next few years before this decade gets over. That's the goal. And I believe Agility is going to be helping and spurring the goal and making that happen sooner than later. World class from India, $227,000,000,000 out of it is happening. And we have 5 million software professionals, engineering professionals, and that's a huge pool, and we have the largest pool of engineers in the world. And number three, high stakes. I just took this example of 1995. We can say that that was the time when the Internet boom started. And at that time, 57% was sort of hardware driven economy and 27% of software. And today it is completely reversed. The hardware has gone down 10%, and then 78% is happening in software. So what does it mean? That means it's very, very high stakes. Lot of things at play. Billions of dollars to be won or lost in terms of competition by companies. And whenever the high stakes games are there, there wouldn't be wonderful competitors, wonderful players out there. Just like in professional sports, you take tennis and you take the top three folks right now, or you take our IPL, or you take cricket. The delta between the winner and the loser is actually not that much like if you take a very literal example of a tennis match, at the end of it, you take the number of games, one number of points, one, et cetera. Delta is going to be very surprisingly, that maybe ten more points won by federal business. The same comes to products. Also, the delta between the first and the second. If you take AMD or intel, right, 99%, or even if you take the exact 5%, 95% of it is going to be pretty much the same. But the difference between the first and the second is going to be there and how they compete and how they make that difference add value to the customer. How do customers perceive it? Is one what's called maternal? Is Agility more important than ever? So we did talk about how we did software releases earlier. We talked about high stakes games. Now we talk about how in two years time, companies have started from inception and are very, very mature with thousands and thousands of customers within two years. So I believe, yes, I think agility is more important than ever. Barriers to entry are being lowered continuously with different platform as a service, drawing as a service, and all the building blocks that we need to build a product is now available to everyone equally. So earlier it was not so much in case you wanted to start another company, you wanted to start another database company, or you wanted to start another operating system company, or even if you wanted to start another ERP company. Right. The barrier to entry was quite high. It was not easy to ship software, it was not easy to set up all your support systems, et cetera, et cetera. Now, within a few months, maybe a few weeks, if you have a really cool idea and you can actually take it to market within a few months. So barriers to entry is being lowered continuously. The other one is ideas alone are not as unique as we like to think. When we start off, we might be thinking that this is a great idea and maybe I only have this idea. I wanted to quote Mr. Minor Koslav, so he's a very famous venture capitalist. I read once that he had said that if you are the only person with a particular idea, that means everyone else has thought about it and rejected it. So that was a good perspective that he shared, that ideas may not be as unique as we think. What does that mean? So if the ideas are not that unique, that means multiple people are going to have those ideas. All of us are working towards achieving those goals, even for cash free payments. We are not the only vendor out there. So it's not Microsoft, Amazon. Everyone has competition. And because of all of this, it's great. Customers have numerous choices. They can choose from a B and also they can switch over later. So we are also moving towards no code and low code platforms where the migration cost from one product to another product is again being over. Earlier, if I chose multibillion dollar ERP vendor, I would be investing multiple millions. I would be having maybe hundreds of people doing that implementation. And then because once I've implemented that, I may not be able to switch over because so much cost has gone into that project. That is not true anymore. Right? So we can easily integrate with different APIs. There are platforms which makes API integration easier. So customers have numerous choices. So to me, what is most important is rapid and continuous innovation over time. So it's not the original idea, it's not the next ten ideas, but rapid and continuous innovation continuously beating the competition. So even if you shipped the product first, maybe someone else is going to replicate it and they might have the second move on advantage. So how do we beat them again in the next game? So I think that is the most important one. And here again, I wanted to share one more very interesting thing that one of my professors that I, Mr. Mahadevan had said at that time I had this curiosity that a lot of agility things that we do today, kanban, et cetera, comes from the manufacturing world and they've been able to drive the cost significantly down. They were able to do just in time manufacturing. They were able to do even zero inventory manufacturing. So I was asking it seems to be very involved and very competitive there. While it's not that much in software, this is about ten years back and his answer was manufacturing has evolved over decades and they are the precursor to software. And software is still more like a younger child and we are still going and maturing but we will get there at the same stage sooner than later. And I think that is happening now in this decade and maybe towards the end of the last decade, the competition and the need for agility is becoming more and more and becoming comparable to the manufacturing industry. So now let's look at we look at why agility and now let us look at what is agility and what are my thoughts on this? So these six things I thought is very important. This sort of embodies agility. The experiment part is the first one. We can't know everything just by thinking, by gut feel. Just like as scientists also they experiment. They might have an hypothesis but they are not exactly sure that it's whether it's going to pan out as they think. So I think the ability to experiment is a very very core feature of agility. It can be external events happening, disruptive changes happening in the market, new players coming in. How do customers actually react to our features? Do they react exactly as we expect them to? Or do they prefer other ways of operating with the product? So that is one adapt. How do we adapt to both the experiments that we conduct as well as maybe the experiments that our competition they are releasing a different version of the product or a different amalgamation of things that is more attractive to the customers. How do we adapt to that? How do we even adapt to change in how the employment market is right? And how do employees work now? We are in the hybrid work model right now. COVID was sort of completely disruptive. A lot of us have actually come out better and stronger out of poverty. How do we adapt to such situations rethink? So how do we be curious and open like a scientist? Scientists only goal is to find the truth, right? So scientists don't have any particular agenda of okay, this should work out like this way or that way. But the scientist. He or she has a very open mind. I want to see what is out there in nature. I want to discover what are the truths in nature that I can derive by the conducting experiments. So be curious and be very open minded. Like I said, the fourth one is the flow of work. So flow of work saves time for learning and innovation in a growth phase of a company or any company. If there are a lot of interruptions. If there are a lot of redoing things maybe due to quality recalls. Maybe a car manufacturing industry. We can think of it as a car means they call and that completely disrupts the flow of work at that particular company for months or with so many other litigations. Et cetera. That can come out. The same thing can happen in software, right? So there are outages or the quality of the product that went out wasn't up to the mark. It's sort of entrusted. Similarly, if the how do I say, from the product consumption to UX to development to QA to DevOps if that thing is not flowing smoothly, we would be spending a lot of time at each junction of where the work interjects between two teams it becomes a little bit more choppy and that again affects the speed of the releases. The fifth one is the right product and we've all heard about getting the product market fitment, et cetera. But what I see is the right product should emerge when we do all of these things. We are conducting experiments, we are adapting to customer feedback, we are open and rethink and we are continuously innovating the store of work and the perfect product emerges. I'm not saying that we conceptualize the perfect product or the right product and we build the right product and we stick to it right. That is not agility. The right product should emerge over time and should be delighting the customers. And the last one is build it right. They do the right thing more often than not. I do agree that we do have to take some calls as and when we need to do, but do the right thing more often than not it does work out because it again connects back to the flow of work. If we built it right, that means we can iterate so much faster. On the next version of the some anti patterns that we have seen and many of us might have seen is when we think about agility there might be some thoughts around we are not yet big enough for this. So one thing that will work for us is to say yeah, maybe you're not that big enough but for the customer paying for the product and the customer relying on your product, we are paying. So they don't want us to compromise on our uptime, on our quality, et cetera. So that's one thought that you can have. Maybe you're still a small team. But if your products are going to be lined upon by a customer, then you have to think that you're big enough. One, two. Another thing that this came from the Google Book on software engineering that they gave a rough guideline that if you're about five years old, your software or you expect your software to be there for five years or more, you are big enough, then you have to start doing the type of things. The secondary pattern is we don't have time, right? Let's get out the product ASAP. It is important. I have a little bit of out of clue from the last few days, apologize for that. It is a multi round game. So this is not a one round game that we are playing with our competition, right? Who gets to the finish line and who makes some product out there, right? But it's a multinational game. Again, we have to balance this with the MVP as well. But we do have to remember that customers do have a strong memory and it has to be minimally viable. It has to be viable. Right? They should not be upset with the product, they should actually love your product and then only they are going to give you more chances for the next version of the product and that I think again relates it to fix it later. So I'm saying that only if we get a chance, right? So if there are too many issues, maybe you won't get a second chance to fix it for the customers. The fourth one, fourth anti pattern is that only the tech or the product matter. Right? So I somehow get it out. I've built it and somehow get it out and I think that is what matters. So here what has helped us to sort of work with this thought or perception is what if Agility is the road to that goal? Yeah at the end, the product or the feature that we put out and it's used by customers. Most important. But what else? Agility is a road to the goal, right? We need internship, we need energy, i, we need logistics to work beautifully. So improving all of that, improving that makes your end product better and faster. So I think that's one thought there. The fifth one is mine as an individual or my team optima. So when we are growing rapidly, we cash free payments. Also we have these different pods and each part has product manager UX, QA and DevOps, et cetera. They own end to end things. So there might be a little bit of the pressure to deliver and do optimize for themselves. Right? It's genuine and because they really really care about their product, they really care about their Okas as well. But we also have to see how we can win or lose as a team. So we'll talk about how we can solve that and that sort of helps the overall company or the global optima be optimized. The 6th one is do I need to write? So here what I would say is with repeating oneself, be agile. And in the new hybrid workplace, the write first culture is a huge, huge time saver and writing also brings a lot of clarity to the author and the product requirements or the design or architecture becomes so much, so much more better when it's written and then discussed with folks. We've also heard about other companies where it's been working out very very successfully that we have to write a one pager or a two pager clearly circulate that ahead of time and that has a huge impact on the momentum and agility of a team. How to build an agile culture. The first one is collaborate. We've all heard of that term and here I want to point out that 85% of job successes are due to soft skills. It's not the hard skills, it's not the technologies that we know or need to learn, but it's about soft skills and collaboration, et cetera. It's not easy to build, but it's very rewarding and hence very most important to be able to build that. Second, I will touch upon collaboration a little bit more in detail because it's very important in the next slide. So I'll go to the next one, which is OKRs. How it helps build an Agile culture. So when I started off on the OKR journey actually about four years back, I had my little bit of a suspicion of okay, we had KPIs, we had goals, et cetera. How is OKRs? Different. But reading the book Measure What Matters gave me great overview of why OKRs are different, why it seems to be working. And since then we've used it in multiple companies and it's actually helped us make things happen because it is open, it allows every team to align. And another thing that I see is it support and monitor. So it's not something that we set at the beginning of the year, beginning of the quarter, forget about it and then take a look at the end and see where we are. But within a team and across teams we sort of constantly see how we are doing and how do we need to support if someone needs some help in this particular. And that is exactly how we are solving this previous thing that we talked about as my team optima, which is a global team optima, right? So there is a global company goal or a departmental goal and then two, three teams are working towards that. And then if that overall goal is not happening, let me get visibility into that and then we are able to go adjust and support and make that happen. And yesterday we actually had a release where two teams came together to make a consolidated product which is a win for our company. The third one is decentralized decisions. Decentralization is super, super important. In the new agile world, we cannot have decisions being cascaded top down. And the more decision makers a company has, the more successful they are going to be. So from entry level pressure coming out of college to anyone, they need to be looking at decisions. We talked about a lot of choices for customers. Similarly, there are lots of choices for solving technical problems. Any single problem that you take, there are probably be at least five to ten different choices. Some are open source, some are managed services and a plethora of options. So how do we make those decisions? Do I build it in house, do I buy it, etcetera. So what we set, some of the frameworks that we set is for all of these decisions be data driven, right? So down your requirements, then consider, okay, what are the things that option that are in front of me, including building it? What do I get out of this ROI? And then publish it, have a very, very tough discussion and review and then go forward. And then sometimes there would be not that many easy decision to make. So in that thing, go ahead and experiment, collect feedback, and then go ahead. And all of this needs to be documented because decisions are not taken once and not revisited, because the situation might again change. For example, today I might have chosen to go with an open source in house implementation and I have to document the reasons for that six months down the line. Maybe it is hitting some scaling issues, but rather than revisit this whole thing, again, if it is documented, I take it from there. And then, okay, what was the previous pros and cons now has it changed? And then maybe I revisit that decision. And another thing that is very important is to encourage people to take that decision also with not of information. Very rarely we are going to get perfect information to support people to take those decisions and have a blameless culture. So even if they took that decision after and then maybe something changed, maybe something was not exactly done right previously. It's okay, we've learned a lot from that and how can we take it forward? So this is something that is helping us tremendously and different people taking different decisions and teams and also sharing that with other teams which will accelerate their decision making. Fourth one is learning challenge the status quo. Sometimes we might hear that this is how we have done it, right? So we made it a habit to avoid saying that. So always challenge the status quo. Even if you were the previous decision maker, let me take a step, a step back from that previous decision. You are not the decision and decision is not you. So what if it is different? Just asking that simple question, two word question, what if things have changed? It's a beautiful way to be agile, find better ways and keep the mind agile by learning. So it helps the body and mind as well. As we keep learning more, we find newer and better ways to do things. So collaboration, I wanted to spend one slide on that because that's OKRs. Things also it's hard to do, but it can be done. But collaboration is even more softer. How do we sort of build it? Right? So open your working process. So some of the folks may think that I would prefer it and at the end just release it and wow everyone. But when we do that we are losing time because what if someone had some very very valuable feedback very very early in the cycle that would have changed the course of how that particular design or how that particular decision went. So, opening the working process is super important and we encourage people to be again brave and not worry about not being perfect at the time that they are sharing it. Also curate info while we present the work in process. It should not only be a dump of information, but create for the reader. How can they quickly get the picture that you have in your mind and then being able to comment on it? Keep the data also as an appendix, or if some of them want the details, but curate that information. Make all of this discoverable. We talk about SEO or websites, but if your requirements or your design or your decisions are not discoverable, then maybe people are not able to take advantage of that. The fourth one is absurd. It's easy to insert new documents. We might see this out there, but to do an absurd is a little bit harder. But once you do an insert, the same exact same thing might have ten to 20 different copies of it. For example, what is the state of my product, what are the features out there, how is my current architecture, et cetera. If I have ten products, ten versions of each of them, imagine how much time is last in figuring out what is it right now, right? So even though an absurd might be a little bit harder to do, we do encourage folks to keep it up to date because that is what saves time for the team. One too many is much better than one on one communications. In one on one communications. Again, you have to repeat things that you've said to that person that many times. So we encourage open Slack groups, we use Slack or any such tool, microsoft teams, et cetera, and then communicate to all. Even if you have a question, ask everyone, right? It improves the bus factor of the team. Also more people know about more things so that when you are going on vacation or thing, you don't have to be called to fix some issue. There are other people who can actually hold the fort and this has to happen across the entire network within. Teams, across teams and even external parties, right? For the business that we are in we interact very closely with banks and other financial institutions and how do we collaborate with them is again going to be a differentiator in how we win. So we've heard examples of how the Japanese car manufacturers opened up their entire supply chain data to the vendors and part suppliers and etc and that is when they were able to get to zero inventory supply chain. So similarly right so we have to open up and open up the collaboration channels and keep it working across the entire network. So secret of the culture, right? So we have a thing called our Hat theorem for the techies there today in the call we would have heard of the Cap theorem and we say that only two of the things are possible in the Cap theorem but in theorem all three are possible. So humble, ambitious and talent. So these three virtues are great to have in people in your team and being humble is very very necessary condition for teamwork. If humility or vulnerability is not there, then it becomes silos. People are not that open, people are not able to give feedback because how will it be perceived by that other person et cetera. The second one is they have to be ambitious, goal driven, find things to make things happen, perceive whatever roadblocks come and go to achieve it. And the third one is necessary condition, we have to have talent to make things happen. So any two out of the 3 may not be sufficient. For example, if I'm humble and ambitious, I don't have talent, I actually can't do it if I'm ambitious and I'm talented, but if I'm not humble, maybe I can work as an individual but my influence sort of is not as great as if I was humble and able to help people as well as more importantly seek help. So agile culture building and then sustaining it, right? How do we do it in the current team? Use LMDs and then coaching by immediate leaders as a big big impact and then L and E for the leaders as well and then very important is support and unblocked by leaders there will be actual challenges on the ground and unless there is support from leadership for the agility culture et cetera, it may a little bit sputter or it might slow down. So leaders have to find things where people are getting unblocked inefficiencies are there and then unblocked. Second one is hiring. We do a lot of interviews, we focus a lot of on technical aspects but also focus on is that person able to rethink? Will they be data driven? We actually do a round for some of the folks which we call the Unconference round where we ask people to present about most challenging and interesting project that they've done and that gives us a great sense of how would I be able to work with this person. Also whether data driven, are they humble, ambitious, et cetera. Now we speak team players over not so great team players. After hiring the onboarding is extremely important. We know the first 30 days it's going to be very crucial. So during that time, celebrate Agility. Agility, as I said again, is not just about processes and tools, et cetera, but how fast we are, how simple we are. So celebrate agility. Use your Agile champions to set it on, so that when that person comes on board into the company, they are hitting the down. So focus on time to contribution. How quickly can they actually contribute to the company? How good is your onboarding process, how good is your design architecture if you're onboarding engineers, et cetera. And the last one is sustaining this culture. When you are ten people, certain things you can do differently. Then you're now growing and then as you grow, the number of people coming into the team is also going to increase. So how do you sustain? So one thing that we tried earlier is cross pollinate with Agile Butterfly. Agile Butterflies are the folks who are beautifully collaborating across different functions and teams. So use them, maybe sometime move them around by different teams in case the Agility is slightly less than one particular team. Maybe do some shuffle so that overall Agility increases. And then one thing we are also doing is sort of gamify this thing on a leaderboard where people are able to see how other teams are doing, learn from other teams on Agility and teamwork the another important one is the Amplifying developer productivity. We know the importance of this is in the context of a software development organization, the most of the expenses or cost of the company is towards the RNC expenses. So it's extremely, extremely important to focus on this. So Engineering Excellence initiatives, then see where you are, then plan for it and then use OKRs, so we have a 30 70 split for Engineering Excellence items as we talk about the SRE, CICD code, non functional requirements, et cetera. So we dedicate that much time to build it right as we discussed earlier. And that is very important. It has to make it into your has to be aligned with product and then product and engineering towards make all of that happen. Then the engineers development environment, the QA environment, et cetera, is a common problem which sort of can tend to slow down the Agility. So we have seen that in multiple places. But we've been focusing on improving this so that an engineer has their own complete development environment equivalent to a set of open source Apache Spark environment. Any developer can quickly set up the entire environment on their laptop. The fourth one is make retrospective action items happen. Many times we do retrospectives, but over time the feedback we saw that it was coming down a little bit and that was happening because people felt that okay, we are talking about all of this but how much of it have we actually changed? So we made a small tweak here to even track those things and show to the team that yes, we are making change happen and the last one is reduced meetings by moving to a right first culture and that we saw as a huge impact on the meeting time and number of people that need to come into the meeting. So focusing and giving number one priority to make the developer productive is going. To have huge rewards from we are on top of the R. Sure. This is my only couple of slides so common Delama. So reuse services. People agree that we want to reuse services but then the other team doesn't have time now, right? So we hit that one. So what we've done to solve that problem is the team that needs it, builds it, uses it and transfers it across to the other team. And this we've been doing multiple times over the past few quarters and it's worked wonders for us. Have it to get it out ASAP. We talked about it. Engineering excellence is planned by the end it spills over. How we solved it is use an integrated OKs for both product and engineering excellence. Fourth one, other functions are not agile. So here what we said is depending on the extent of the dependency, find a solution rather than leave it that it cannot be because we've said the entire network has to be a giant. So work on it may not be as easy as doing a job within a team or within a function but we are working on that. The last one is agreement is there but change doesn't actually happen. Right? For that be open and publish the analysis, publish the data on different things, right? Whatever you want to change, start publishing dashboards or reports every week across the board and it just works like magic. That's what we've seen. So that's about it folks. And as we say bye. Just wanted to quickly recap takeaways from this session. Agility gives you a competitive edge, right? It is hard to excel at this but most rewarding and hence the most important thing. Agile culture needs to be nurtured and sustained from the people front. We talked about being humble, ambitious and got talent and the environment has to support this people. So it has to be open, data driven, decentralized and it has to be very very productive. And if we have all of this, growth will be delivered. You will have the right product, you would have built it right and the customers would be jumping for joke and they'd be delighted. Thank you all and happy to have the discussion with you. Sure. Thanks Ram. So we have three questions, all three are from Pradeep. So first question collaboration. What are the specific things that you did during the last two years since many or all of us were working on remote. What are the ones that worked and the ones didn't work? Remote working and we're on. Yeah. So I think what changed is initially collaboration means let's come to a meeting, let's get a few people and then talk about things and that had to change and that was a good change that I think is happening is moving towards this right first culture. So before any thought that I want to share, I spend time and then I write that sort of one page why what? And all my analysis and then send it out ahead of time, ideally 24 hours to 48 hours before and people can go through it, ask questions within there and then when you come to the meeting, everyone has the context operating right now we only have to make a few more decisions. I think this accelerated the collaboration and these discussions are going to be happening over time. So the life first culture has helped us and we are also in a hybrid work mode. So right now, once postcobid we are in a hybrid working model. So we structure the times when we are coming in. So things that need more discussions, more face time are clubbed into certain days when that particular team is coming in. That's also helped us. The third one is the making meetings more productive. We use a particular tool a lot of times meetings, someone sends the meeting minutes and then there are open items to be done by different people. But then over time there are so many meetings and so many action items that it becomes an ocean and some of them invariably get stopped. So we have invested in one particular tool and it helped us make our meetings very effective and it integrates with all the collaboration tools like things and then the meeting notes just comes there, agenda comes there and then when you go to the next meeting, everything is out there who has what action item, it's very easy to go through them. That is that. And then we invested in Agile coaching and we do that at multiple levels for PMS, for Em, for teams as well as for Freshers. So the freshers join. It's not just that we are doing technical things but we coach them on Agility and their collaboration is also stressed as a very, very important thing and a few other things that I touched upon also we've actually started doing it even in our interviews, checking for the Agility aspects. Thanks Ram. Second question again from Pratt on hiring. Are you still able to do this kind of conference with a candidate and asking for many questions? Even with the current challenging time with candidates holding multiple offers, are there any success mantra for getting the right candidate joined? Yeah, it's a good challenge to have. We are growing and a lot of opportunities, it means a lot of opportunities in the market, right? So that's good for everyone. So just like how we compete on products, right? So we have to put our best face forward, convince the candidates as to why they have to join. So even after the offer, we do have multiple touch points, but so do other companies. Just like as I said, continuous innovation. But we have to try and we have to connect to the candidate and then convince them as to why they should join our company. What is the purpose of for example, in our case, we do say how we are impacting 30 million people right now in India, touching that many people and how that is going increase. So similarly, every company will have an impact that they are having on people and at the end of the day, while they might have competing offers and all, they also want to be in a culture where they are happy, they are productive, et cetera. So these things have to be sort of showcased and told to them and this unconfidence around is actually working well for us, where the candidate also is able to see, OK, what kind of people will I be interacting with, how do they approach things, how do they ask questions? So it works both ways. Great. Thanks, Tom. Another question from Sharp. Is there a way to measure how much an art sculpture is friendly or agility? Friendly? Agility. I think it's more about agile, how much agile they are and maturity and agile. Right, okay. Yeah. So here one thing that we are using is a little bit popular, the Dora metrics as to how agile we are, how often do we release, how much time it takes, what the change failure rate? That is becoming quite useful. Those four metrics we are measuring. And then we've added a few more of the metrics where we've seen maybe some challenges. So we wanted to highlight that. So there are seven challenges in this whole software development lifecycle. We wanted to pick that and then see whether we are making progress on that front. Right? So that might change after some time. If we fix that particular issue and it's no longer an issue for us, we might take that attribute off and then maybe it will uncover something new in the process. Right? So have a sort of Agility scorecard based on your teams and your challenges with a few maybe common industry, common ones, and then work on it and then once it's done, maybe revisit it and then maybe put in a different set of attributes to measure the new charge. I'll rephrase the question again, I think it's more about probably I think I read it wrong. So it's more about how to measure an organization culture, whether it is friendly for Agility or not. I think how much friendly they are for Agility. Is there a way to measure that? Yeah, I'm not sure we can measure that. But what I'm thinking is if all these other matrices, right, like say the four meter metrics, if there we are not competing with the best in the world, that would mean that we are not that friendly to a job, right? So if you take that hypothesis, it's going to be very rare that I'm extremely agile and not friendly to agility. Yeah. And then there was another great book, I would maybe suggest that Accelerate, and that book actually has surveyed 200 companies on agility more thorough than most of them, including me, can do. So they've done a great job in that. And they actually make a point that maybe too many metrics also might pull us in different directions. They did some analysis on which matrices actually move the needle and which matrices are related. If two matrices are going to sort of be very eliminated and give you the same outcome, then they say maybe chop off one and keep one. Right. And based on that, they suggested these things. So they're saying that these are great, they are independent and great predictors of agility and everything else will somehow reflect into that. So I do maybe suggest that a good read of that as well. Sure. Thanks. One more question. I think you have answered this already, but I just repeated, can you give more insights on the Dora metrics, when and why it was introduced and how it is evolving? Maybe my earlier answer sort of overlap with the question. Right. So that book is what I would recommend because it's a long answer, but they've covered it really well. So they talk about lot of matrices and then they sort of finally say that these four matrices are great indicator of agility. Thanks to I think we're done with the questions here. Thank you. Thank you. Thank you, James.