 We welcome you all to the session Spurring Growth with Anagile Culture by Ram Kumar Venkatesan. Ram has more than 24 years of experience in ad tech, big data, e-commerce 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 his 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 Cache Free. Without further delay, I'll hand it over to you, Ram. Thanks, Vijay. And first of all, I want to thank all of you. Happy Friday morning. And that's great to be here at the Agile India 2022 conference. And after the COVID 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 Agile India conference form. So it's been a great journey and a lot has changed since I started my career 25 years back. A lot has changed, a 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 the 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, I would say a tectonic change on how things are developed, how things are reached customers, etc. 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. I'll 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 at 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, right? So it's a day to day thing that we've been seeing. And while it might be a little bit overwhelming, but it's very, very, very challenging and refreshing to be able to make things happen. So, yeah, so today, we will talk about Agile culture and how it is the foundation for growth. A lot of things needs to put in place for growth. But in 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, right? I think many times, we do talk about 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 am in my part-time 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 10 years down the line when you're leading teams, when you're working in teams, etc. And at that time, I didn't believe it that much, but he couldn't have been fathered from the truth. It's about exactly 10 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 Abdul Kalam. 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. For 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 the hypothesis or redo their experiment, etc. So I think he has very nicely put this as intelligence is the 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 a sum of individuals and then a company with nothing more about a 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. 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, very important to get right, but the more important things are the agile culture. So why agility? We'll spend a little bit on that. I'm sure a lot of us have answers to this. Why agility? There are multiple, multiple, very valid answers to that. I'll try to summarize some of it that's very, very relevant for us today in 2022. The first two, the goal and world class from India is sort of relevant to where India is today in 2022, after 75 years of independence and sort of doing a reset at that time. And then the three and four is for 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 billion out of IT is happening and we have 5 million software professionals. So engineering professionals, sorry. 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. You can say that that was the time when the internet boom now 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 if that means it's very, very high stakes. A 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, they're going to be wonderful competitors, wonderful players out there. Just like in professional sports, like whether 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 user 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 won, number of points won, etc. The delta is going to be very, very surprisingly that maybe a 10 more points won by Federer, Nadal or Dokovic. The same comes to products also, the delta between the first and the second. If you take AMD or Intel, 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 and value to the customer, how do customers perceive it is one what's going to happen at the end. This agility more important than ever. So we did talk about how we did software releases earlier, we talked about high stakes games now, we talked 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 platforms 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. So 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, 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, etc. Now, within a few months or maybe in a few weeks, if you have a really, really cool idea and you can actually take it to market within a few months. So barriers to entry is being lowered continuously. The another 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 one Mr. Vinod Kosla, 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? 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 is not Microsoft, Amazon, everyone has competition. And because of all of this, it's great that customers have numerous choices. They can choose from A, B and also they can switch over. So we are also moving towards no-code and no-code platforms where the migration cost from one product to another product is again being lowered. Earlier if I chose a multi-billion 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. So we can easily integrate with different APIs that are in 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 10 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-mover 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 want to share one more very interesting thing that one of my professors at IM, Mr. Mahadevan had said. At that time, I had this curiosity that a lot of agility things that we do today, Kanban, etc., 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, very involved and very competitive there while it's not that much in software. This was about 10 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 growing 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 looked 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, 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 a hypothesis, but they are not exactly sure that 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 the department? So that is one. How do we adapt to both the experiments that we conduct as well as maybe the experiments that are competition? They are releasing a different version of the product or a different amalgamation of things that is more attractive to the customer. How do we adapt to that? How do we even adapt to change in how the employment market is? 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 COVID. 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. So the scientist doesn't have any particular agenda of this should work out like this way or that way. But the scientist 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, very open minded like a scientist. 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 card manufacturing industry, we can think of it as a card made recall. And that completely disrupts the flow of work at that particular company for once with so many other litigation, etc. That can come out. The same thing can happen in software. The outages or the quality of the product that went out wasn't up to the mark. It sort of interrupts the flow of work. Similarly, if the product conception 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 intersects 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, etc. 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 in the flow of work and the perfect product emerges out of this. 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. 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. That means we can iterate so much faster on the next version of the product. 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 has worked for us is to say, maybe you're not that big enough, but for the customer paying for the product and the customer relying on your product, we are big. So they don't want us to compromise on our uptime, on our quality, etc. So that's one thought that you can have. Maybe you're still a small team, but if your products are going to be relied upon by your 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 are 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 right things. The second anti-pattern is we don't have time. Let's get out the product ASAP. Yeah, it is important. I have a little bit of a bout of flu from the last few days, some follow-up days for that. It is a multi-round game. So this is not a one-round game that we are playing with our competition. Who gets to the finish line and who makes some product out there? But it's a multi-round 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. It has to be minimally viable. It has to be viable. 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 was saying that only if we get a chance. So if there are too many issues, maybe you won't get a second chance to fix it for the customers. The fourth anti-pattern is that only the tech or the product matter. So I somehow get it out. I've built it. I somehow get it out. And I think that is what matters. So here, what has helped us to work with this thought or perception is what if agility is the road to that goal? At the end, the product or the feature that we put out and is used by customers is most important. But what if agility is the goal? We need infrastructure. We need energy. We need logistics to work beautifully. So improving all of that, improving that makes your end product better and faster. So I think that one thought there. The fifth one is the my or mine as an individual or my team, Optima. So when we are growing rapidly, we cash-free payments also. We have these different parts and each part has product manager, UX, QA, DevOps, et cetera, their own end-to-end thing. So there might be a little bit of the pressure to deliver and do optimize for themselves. It's genuine and because they really, really care about their product, they really, really care about their OKRs as well. But we also have to see how we can win or lose our 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 sixth one is, oh, do I need to write? So here what I would say is we're repeating oneself be agile. And in the new hybrid workplace, the right 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. And so even every, 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. So 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 technology that we know or need to learn. But it's about soft skills and collaboration, et cetera. Not easy to build, but it's very, very rewarding and hence very, 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 OK, we had KPI, we had goals, et cetera. How is OKRs different? But reading the book, measure what matters, gave me a great overview of why OKRs are different, why it seems to be working. Since then we've used it in multiple companies and it's actually helped us make things happen because it's open. Because it is open, it allows every team to align. And the 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 OKR. 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. 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, then we 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 will probably be at least five to 10 different choices. Some are open source, some are managed services and plethora of options. So how do we make those decisions? Why build it in-house? Why buy it? Et cetera. So what we've set, some of the frameworks that we've set is for all of these decisions be data driven. Put down your requirements, then consider, okay, what are the things that options 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, very important is to encourage people to take that decision, also with not 100% of information. Very rarely we are going to get perfect 100% information. So 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. So we made it a habit to avoid saying that. So always challenge the status quo, even if you were the previous decision maker. We take us just to step back from that previous decision. You are not the decision and the 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, yeah, it's hard to do, but it can be done. But collaboration is even more softer. How do we sort of build it? So open your work in process. So some of the folks may think that I would perfect it and at the end, just release it and wow everyone. 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 work in process is super, 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. So curate info while we present the work in process. It should not only be a dump of information, but curate for the reader. How can they quickly get the picture that you have in your mind and then being able to comment on that. Keep the data also as an appendix for if some of them want the details, but curate that information. Make all of this discoverable. We talk about SEO for websites, but if your requirements or design or your decisions are not discoverable, then maybe people are not able to take advantage of that. The fourth one is absurd. It is easy to insert new documents. We might see this all the while, but to do an absurd is a little bit harder, but once you do an insert, the same exact same thing might have 10 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 10 products, 10 versions of each of them, imagine how much time is lost in figuring out what is it right now. Even though an absurd might be a little bit harder to do, we do encourage folks to keep it up to date. That is what saves time for the team. One to many is much better than one-on-one communications. In one-on-one communications, again, you have to repeat things that you said to that person that many times. We encourage open Slack groups. We use Slack on any such tool, Microsoft Teams, et cetera. And then communicate to all. Even if you have a question, ask everyone. It improves the bus factor of the team also. More people know about more things so that when you are going on vacation or a thing, you don't have to be called to fix some issue. There are other people who can actually hold the fault. And this has to happen across the entire network, within teams, across teams, and even external parties. For the business that we are in, we interact very, 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 et cetera. And that is when they were able to get to zero inventory supply chain thing. So similarly, 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. So we have a thing called our hat theorem for the techies that 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 the hat 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. 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, right? Goal driven, find things to make things happen, perceive your whatever roadblocks come and go to achieve it. And the third one is a necessary condition, right? We have to have talent to make things happen. So any two of the three may not be sufficient. For example, if I'm humble and ambition, I don't have talent, maybe 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, right? 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 LNDs and then coaching by immediate leaders has a big, big impact. And then LND for the leaders as well. And then very important is support and unblock by leaders, right? So there will be actual challenges on the ground. And unless there is support from leadership for the agility culture, et cetera, right? It may a little bit sputter or it might slow down, right? So leaders have to find things where people are getting unblocked or inefficiencies are there and then unblocked. Second one is hiring. We do a lot of interviews. We focus a lot 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 understand about most challenging or 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 they're data driven, are they humble, ambitious, et cetera. Now we speak to team players over not so great team players. The after hiring, the onboarding is extremely important. We know the first 30 days is going to be very, very crucial. So during that time celebrate agility, right? Again, it's 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 the tone so that when that person comes on board into the company, they are hitting the round. 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, right? When you are 10 people, certain things you can do differently, then you are now growing. And then as you grow, the number of people coming into the team is also going to increase, right? So how do you sustain? So one thing that we've tried earlier is cross-pollinate with agile butterflies, right? Agile butterflies are the folks who are beautifully operating across different functions and teams. So use them. Maybe sometime move them around by different teams, right? 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. Another important one is the amplifying developer productivity, right? We know the importance of... This is in a context of a software development organization. The most of the expenses or cost of the company is towards the R&D expenses. So it's extremely, extremely important to focus on this. So engineering excellence initiatives, right? See where you are, then plan for it, and then use OKRs. So we have a 30-70 split for engineering excellence items for, as we talked about, the SRE, CICD, R&D score, non-functional requirements, et cetera, right? So we dedicate that much time to build the right... Build it right, as we discussed earlier. And that is very important. It has to make it into your OKRs. It 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 agenda thing, right? 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, say Apache Spark environment. The developer can quickly set up the entire environment on their laptop. The fourth one is make retrospectives, action items happen, right? Many times we do retrospectives, but over time the feedback, we saw that it was coming down a little bit, right? 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, right? 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 then last one is reduce meetings, right? 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. Ram, Vijay here, sorry to interrupt. We are on top of the R, we can speed up. We have two questions. This is my, only couple of slides. So common dilemmas, 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've talked about it. Engineering excellence is planned, but 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've said is, depending on the extent of the dependency, find a solution rather than leave it that cannot be because we've said the entire network has to be agile. So work on it may not be as easy as doing agile 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? That 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, right? That's what we've seen. So that's about it folks. And as we were saying by 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, right? 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 joy and they'd be delighted. Thank you. Thank you all. And yeah, happy to have the discussion. 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 are all of us were working on remote? What are the ones that worked and the ones didn't work in a remote working environment? Yeah, so I think what changed is initially collaboration means, right? Let's come to a meeting. Let's get a few people and then talk about things, right? And that had to change. And that was a good change that I think is happening is moving towards this right first culture, right? So before any thought that I want to share, I spend time and then I write that sort of one pager 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 in there and then we come to the meeting. Everyone has the context already, 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, right? So the right first culture has helped us and we are also in a hybrid work mode, right? So right now, right? Once post COVID, we are in a hybrid working model. So we structure the times when we are coming in. So things that need more discussion, more FaceTime 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, right? We use a particular tool. A lot of times meetings, we 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, right? So we have invested in one particular tool and it's helped us make our meetings very, very effective, right? So 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 to, right? Who had what action item? It's very easy to go through them. That is there. And then we've invested in agile coaching and we do that at multiple levels for PMs, for EMs, for teams, as well as for freshers, right? 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, right? We've actually started doing it even in our interviews, right? Checking for the agility aspects. Thanks, Ram. Second question again from Prateep 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 join? Yeah, it's a good challenge to have, right? So 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, right? Just like, as I said, continuous innovation. And then so, 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, right? What is the purpose of that, for example, in our case, we do say, right, how we are impacting 130 million people right now in India, touching that many people and how that is going to 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 culture where they are happy, they are productive, et cetera, right? So these things have to be sort of showcased and told to them. And this unconference round is actually working well for us, where the candidate also is able to see, okay, what kind of people will I be interacting with? How do they approach things? How do they ask questions? So it works both ways. Thanks Ram. Another question from Sara Sharap. Is there a way to measure how much an org's culture is friendly or agility? Friendly or agility? I think it's more about agile. How much agile they are and maturity in agile, right? Okay, okay. Yeah, so here, right, one thing that we are using is the now a little bit popular, the Dora metrics as to how agile we are, right? How often do we release? How much time it takes or the change failure rate? I think 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, right? So we wanted to highlight that, right? So there are certain 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 challenge. Ram, I'll rephrase the question again. I think it's more about probably I read it wrong. So it's more about how to measure an organization's 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 we, all these other matrices, right? Like they say the four matrices, if there we are not competing with the best in the world, that would mean that we are not friendly to agility, right? So if we take that hypothesis, it's going to be very, very rare that I'm extremely agile and not friendly to agility, right? So, yeah, yeah. So I think I would, and then there was another great book I would maybe suggest that, right? So Accelerate. And that book actually has surveyed 200 companies on agility, right? Much, much more thorough than most of us including me can do. So they've done a great job in that. And they actually make a point that maybe too many matrices also might pull us in different directions. They did some analysis on which matrices actually move the needle and which matrices are related, right? If two matrices are going to sort of be very, very related and say give you the same outcome, then they say maybe chop off one and keep one, right? And based on that, they suggested the same, right? So they're saying that these are great. They are independent and great predictors of agility and everything else will somehow reflect into that, right? So I do maybe suggest that a good read of that as well. Sure, thanks Ram. 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 overlapped 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 a lot of matrices and then they sort of finally say that these four matrices are great indicator of agility. Thanks Ram. I think we're done with the questions here. Thank you. Thank you all. Thank you, Jay.