 Yeah, thanks for joining. And I'm going to talk a little bit about gamifying deaf effectiveness today. I'll start by speaking a little bit about myself and then I'll speak a little bit about the topic. So I have worn many hats in my past lives across multiple companies. I have worked for Comcast for about five years. I then switched to be a part of Netflix's originals journey for a while and then I've been working at Walmart. And just recently I joined Real.com as a senior director for developer experience. My work has usually spanned the productivity space. My passions are around CI, CDN quality. Chaos engineering has been something that's been near and dear to my heart and I've practiced it for the last eight years or so and performance testing and analysis. So this is sort of the area in which I work. So one of the big things that I have focused on is how do we think about developer productivity and overall developer effectiveness? So what do we want in any company in any team? We want healthy, happy, high performing teams that can innovate quickly and continue to deliver quality products to delight the customer. So if you notice the things that I've highlighted we can sort of concisely say that we care about speed, quality and developer joy. In most companies, the fact of the matter is that speed is usually the number one thing which is we want to make sure we innovate fast. Sometimes there are concessions given to quality and developer joy is usually a much ignored fact unless the developers sort of mention it themselves. So this is a fact. If you think about what matters, right? For any company that is innovating at speed, features matter, right? How quickly are you getting the features out the door? The performance of the development team matters. How able are that development team? How quickly can they bring in new features? How quickly can they adapt to new technologies? The question for developers usually is how visible is this project leadership? How do I grow? Can I do more in my role? Can I increase my scope? Reaction time to issues like incident management, right? How quickly can an incident be taken under control? And then finally, most of the teams, they focus on what the manager says, right? What's the loudest voice in the room? People are listening to it and they want to make sure that the manager is satisfied. But things have actually changed in the last couple of years, right? The ways of working have evolved and we have evolved sort of with them, right? Currently there are global hybrid teams that work at any corporation of any size. We have actually been pushed to accept a remote first working environment. We have distributed teams all across the globe and these distributed teams have to be high performing. How do we enable that? So if you think about what we want in the last couple of years, the idea of healthy, happy and high performing teams has been challenged. So today I wanna try and talk a little bit about how to get that mojo back and how to get the teams back to being productive. So as I mentioned, we had talked about a bunch of things that mattered in the pre-pandemic environment, right? But let's talk about what really matters, right? What really matters today is efficiency, getting work done from wherever you are in the world, right? What matters is team culture or like just to make sure that the team actually is supportive of all of the things that you need to do in your personal life. And there is low drama, right? It's also important to build resilient systems which allow you to sleep well at night, right? You don't wanna be on a call 24-7 doing everything, right? And then there is adaptability. It has, this last couple of years has forced us to adapt and it has caused this anxiety of various kinds. We wanna be making sure that going forward we can adapt with zero anxiety. And finally, we want communication. We want over communication from our team. We want respect. We want inclusion of ideas and all of those good things. So taking all of these into account, let's define what developer effectiveness really is, right? A developer effectiveness in my mind is the ability to provide an environment for a developer to be as effective as possible to get the bottom line success for the company. There are three broad areas where we can take a look at how the developer is effective. One is in the initial developer onboarding, right? Starting a new role or starting a new project, there is a certain ramp-up time that is required for each developer to be able to get to where they can be productive. The second is day-to-day. Any developer when they're doing day-to-day work, there is a certain amount of functions that they need to do, there is a certain amount of tooling they need, right? Making sure that they are enabled to do that. And then finally, there are big re-factors, big redesigns, big re-architectures, right? These are also things that developers participate in. So let's keep this in mind as we think about metrics and going forward. So a brief description of what gamification is. Gamification is nothing but an idea that we can use incentives, rewards, or maybe something like badges, reputation, and defined levels for folks to be able to upskill themselves or learn to be able to achieve. So incentives, rewards are something that encourages folks to do more than what they can. Badges and reputation are things which people get as something that they can boast about. And then there's levels, right? Like we have software engineering levels. So in my past lives, in the last, I would say, 10 years or so, there are many different attempts I've made at trying to understand what's the best model to make sure that devs are challenged. So the first attempt is going to talk about challenging devs. So the first time I tried something, I said, okay, let's challenge the developers by creating a tech lead in the team who would be the best example of what this team should be, right? So tech leads are the ones who can challenge themselves the most, who are going to be people who are going to raise their hands often. And then I said, okay, fine. It's analogous to real life, right? We usually have great point averages which allow us to determine who's doing better than the other person. There is something like Stack Overflow where you have online reputation points. There is also a dev ladder where people can go from senior to staff to principal and so on. We can also challenge developers by saying, hey, let's incentivize a growth based on abilities like adaptability, capability to execute on something that's high importance. And finally, rewards for mentoring, right? This kind of challenge environment when we practice this for a couple of quarters or so, we realized very quickly that there are some major disadvantages, right? And the observations that I had was we realized a lot of fiefdoms being created. There was a lot of small groups that became very focused on loyalty towards one item or one person which were mostly led by ego and not much else, right? This caused a lot of anxiety. Even for those who are performing really well, they felt anxious that, hey, we are not part of something and that is not really making anything effective. The other observation was that there was a lot of duplication of effort because as there was high visibility work that was appreciated by leadership, multiple teams started pouring in their resourcing to be able to say, hey, we also did this, right? And this duplication of effort was really a time-wasted and not really adding to any effectiveness, engineering or otherwise. And finally, the most important thing that we learned very quickly was that even though mentoring was needed in most companies, it is not something that can be gamified, right? It is an art, there are some people who are good at it, some people who are not and that is something that happens as an expansive sort of a broad scale thing. It's not something that is a science. So using these observations, the one thing we realized was, yeah, this was a big fail, right? We didn't really succeed at this gamification attempt. So that brought us to saying, okay, you know what? If we don't challenge the devs, what else can we do? Yes, we can challenge the process. So the second attempt that we made at gamification was to say, hey, let's look at challenging the process. So how do we do that? You said, okay, there is a process to deliver the software. Let's incentivize the speed of delivery. We said, let's provide badges for teams that are high performing. So let's move away from focusing on developers to move to focusing on teams and provide badges for doing really well, right? Hey, you had a very clean sort of deploy schedule for the last month. Here is a batch for you. You performed really well in a high pressure situation where 10x traffic was being consumed by your team and you still perform with low latency. Here is a batch for your team, right? And then upskilled rewards for individuals where you would say, this person has been doing really well. They have trained themselves on AWS certification. That's great. Let's give them more scope. Let's give them more rewards, right? We also found that we could create more transparency in the promotion process. So folks know exactly what they're looking for. Leadership is looking for when they say, this person can be promoted from one level to another. And finally, we started putting cating on quality, right? So we said, let's actually have policy engines across the entire software chain where we can say if a certain level of quality is not met, there is a ding or some kind of a detraction for that person to be able to say, let's do this better. This was not all expect as I worked as expected. So the observations we had here at the top one was, there was a very significant speed versus quality trade-off which we had expected, but we didn't expect to the level that it happened. We also realized that badges were not really popular among people, right? Which is if you gave someone a badge, it became redundant very quickly when there was a future incident. For example, you could have an incident for a month or two, but the moment you had a revenue impacting incident, all of that previous wins were lost, right? The bonus promo eval process, the side effect of making it transparent was that it also started getting politicized. So people started holding specific items in that promo process, accountable to people to be able to get things done. And that was not really what was intended. And finally, the quality gating, even though it worked partially, it needed a lot of training. It needed a lot of acceptance within the entire community and that was not something that it was a hasty decision to push it through. So I wanna briefly touch upon what we found with quality and speed. And I'm gonna use data that is also found in the state of software quality report that was published last year. It was found that quality and speed when it comes to that, there is a lot of companies who claim that quality is important, but like 70% of these respondents who were looked in that report. However, that is not always true. A lot of folks, a lot of companies tend to push out innovation quicker just because they realize that the customer would be happy to see that. So there have been a lot of quality misses due to speed. And just the last year or two, we have seen a number of issues, right? Some of these issues that I'm showing are large scale issues that happened directly because there were quality issues, either memory leaks, or either like not fully regression tested software. All of these resulted in millions of dollars of software loss, as well as laws of trust within the customer. So not really a good place to be, right? So if you think about it, quality versus speed trade-off is a genuine trade-off that we really didn't want to have. We wanted to have something where you could say there is quality and there is good velocity. So you could assume that the gamification attempt too was sort of a fail, but we had some learnings, right? We had some good learnings. What were those? One was that we saw a marked improvement in incident reduction because of quality gating. If we had quality gating that said unit tests have to be above 70%, certain number of performance tests have to be done. Certain amount of chaos engineering exercises have to be done. That actually improved our incident response rate as well as the leaking of bugs to broad stop. Up-skilled rewards really boosted morale, right? So every time someone would finish a certification, there was a general consensus that that person is going up. They're actually training themselves. There was a positive reaction with them, right? Transparency in promo process was appreciated, but it was abuse. So we realized that there is something that was good in this that could come out of a just transparency. However, we'll have to curb the abuse in some way. The other main thing that came out of this was that some of the process improvements which we had gamified were a massive force multiplier, which means the team actually backed it 100% and we were able to get a lot of traction on some of the innovations that we did with the process. So it was not all bad. What we learned essentially was that in order to be effective, a developer needs to be enabled. So effectiveness needs enablement, right? This was a big learning for us. If we do not have the right kind of enablement for the developers where they are not able to get what they need in a quick enough time, we're not really getting any effectiveness out of them. We realized that we have to gamify the process. I think that one was clear, not the people, because we do not want to create anxiety in folks. We want to make sure that it's a process that has to be gamified and not measuring people. We realized that there are trade-offs and thinking of trade-offs, we also made it very conscious effort to actually say, let's choose one versus the other or at least choose that we will lose one parameter if we try to optimize the other. This made us very aware of what those trade-offs were. And finally, in the last couple of years, we realized that remote work needs top-notch support, top-notch communication, as well as a lot of room for making developers fail and then learn and succeed from that. So these were sort of our primary takeaways that we said, okay, you know what, let's take all of this, let's talk about some steps to make these things possible. So step one, what we did was, we said, let's focus on onboarding. Onboarding is that time when a developer is feeling massively unproductive. They are just coming into their work, they get a new laptop, they're setting up their account, they have to spend time installing packages, then they check out the code, they start reading the documents, they start talking to other folks in their team, they begin their work and then finally they come in some code to fraud. This entire exercise can take upwards of two weeks, right? Even in the best cases, two weeks is sort of the minimum for someone to get truly productive. So we said, okay, you know what, let's minimize the onboarding time. So we start off saying, let's minimize onboarding time to be less than two weeks and let's see how far we can get. So we said, okay, let's use sensible defaults to preset the workstation of the laptop with the right kind of packages, the right kind of code, the code environment, et cetera. For example, if a developer is someone who's coming in as a Java developer and they need the specific kind of IDEs, they need specific kind of jars to be able to begin their code setup, let's make sure that's already preset and preloaded. In addition to this, we paired some of the new hires with tenured developers during the setup phase, during the first week. That enabled many of these folks to actually get done with obstacles much sooner because they were getting dedicated help from folks who have already done this in the past. We actually found that for a few teams, there were onboarding cases where teams were able to come, developers were able to come at code to prod within three days. This boosted a lot of morale, and not just for the development team, but all the way upwards to our executive leadership. And the other thing that happened as a side effect, as a good side effect of this, is for onboarding new devs, the acceptance into the team was faster because there were people now working with the devs to ensure that their setup is complete. They're able to use their preset workstations and get productive much faster. What is step two? Step two, we realize is we have to do CICD. There is no way around it. I've linked a really interesting exercise, really interesting sort of effort that's taken place around the world where folks are agreeing on what a minimum continuous delivery model looks like. So I definitely encourage everyone to look at it. What we did was we said, okay, let's define a clear pipelines to prod, right? It should be a uniform way to get to prod. There should be uniform steps to get to prod. And we said, okay, this gives, we realize that this gives high confidence to developers. We realize that there is importance in getting quick feedback to issues. So typically your CICD pipeline looks like this, right? We start off with planning. We start coding things. Those are verified or built using Jenkins or your favorite build system. You profile them or you run performance tests on them. You do performance profiling on them or you do different kinds of tests on them. And then you deploy it in course production. You monitor what's happening in production and then you come back and start fixing it all over again. So this is our continuous deploy process, right? And obviously during the continuous deploy process, you have various gates and guardrails where you starting with design verification, stakeholder review at the start with plan. During code, you write tests, different kinds of tests. You verify using UI verification end to end tests, et cetera. You do your security checks, things like that. You verify the performance. You do different kinds of analyses. And finally, you deploy it and make sure that when you're deploying it, you're deploying it in the highly available disaster recovery ready fashion, right? So all of this, if we had defaults for these, right? If you have sensible defaults for being able to test this, if you had good templates that could be shared with the developers, the developers then feel empowered to be able to do their work faster. And the side effect of doing that faster means that we can actually get really good effectiveness from them. So this is a model that has worked for us. There is variations of these models that different teams used, but in a sense, this was essentially the blueprint for that, for every team. So final step, and this is really the most important step in addition to all the tooling, right? It was about active inclusion. What does this mean really, right? Active inclusion is basically about making sure that folks in the team understand that their opinions are valued and there is true meritocracy in the team, right? So the leaders in every team needed to include all the ideas. So this was more of a process change, but also a personal growth for many of the leaders where they had to say, okay, let's include all ideas that are coming from every member of the team. And let's make sure that as a team we discuss and we develop empathy for the other viewpoint so that we give it that respect that it needs, right? Also, when it comes to challenging or criticizing something, right? Let's criticize the decisions that were taken, not the person. And a lot of times this takes practice because when you're in a room with another person or even a Zoom with another person, you tend to start focusing on them instead of the actual decisions that are taken. One way to solve this is by making decisions data-driven. So then you can come back to the data, examine it and then use that to make your future decisions, right? The final thing which is actually significant, even though it's subtle is celebrate successes, even the small ones, right? Active inclusion involves people knowing that what they did, what they have done for the team, what they have done straight up for the team through the night or they delivered something that was thought unimpossible within the timeline. Those things have to be celebrated, right? And in a very public way. Also, don't isolate blame. Blameless postmortems and blameless root cause analysis are the name of the game and many folks in the industry are adopting it. So that's what active inclusion, and this is really more about making sure that the leadership is up to speed on this, right? So now let's put this all together. So we said, okay, we have now understood what has happened. And so we said, let's try something when we put this all together and let's try another attempt at gamification, right? So we said, okay, what does this look like? It's all about enabling developers. So if you're gonna enable developers, we need to make sure that we have amazing tooling that can help them accelerate. Imagine what a developer could do in one day. Let's have tooling that can allow them to do the same thing within one hour. How can we challenge that, right? And the answer to that is make sure that we use community supported software, we use enterprise software that has good reputation in the market, and we build abstractions and tool teams within our area to ensure that there is support for the developers instead of them having to build everything and reinvent the wheel every single time, right? The other thing that was important was to allow teams to nominate worthiness, which means that teams typically know who the go-to person is for solving something, right? There are people in the team that the team looks up to. Let's reward them. Let's allow the team to nominate who becomes the tech lead in that team. And this worked out really well because this allowed the team to say, I respect this person, I will hear what they have to say, and this person is nominated by me. So it created a lot of acceptance within the team. Cross-training was crucial, right? So you want to make sure that you cross-train all the developers. So every single level of developer knows that there is a growth path for them where they can upskill and do more by contributing to the company and to the bottom line. And frankly speaking, for every developer, it's also important how their resume looks outside of the company, right? So we enabling devs also means enabling them to learn new things, right? And finally, in enabling devs, we also wanted to make sure that we reward empathy and passion. So we wanted to make sure we give them tools to help accelerate so that they can deliver quickly, they can deliver quality, and they can feel really good about what they're contributing. But at the same time, we wanted to make sure that anyone who is empathetic was passionate about the software and the work they're doing gets that reward, gets that acknowledgement. And the second thing for leaders was removing obstacles, emphasis on any debate not involving the person. So ego-less debates where we can bring in data, any decision that is being made should be back with data. There are teams that are doing this for the last 10 years or so at Netflix and it's really been wonderful to work with those teams, right? So allowing teams to explore and find new paths. This is really important where sometimes we focus on deadline and driven development so much that we don't realize that, we don't realize that there could be things that the teams could do, right? There could be hackathons where teams could create new ideas and actually explore those. So we want to allow teams to also explore and find those new paths, right? In short, this is a line that I borrowed from the Netflix culture deck, which is freedom and responsibility. It's a really powerful idea to be able to give freedom to a developer and give them all the tools they need to succeed and then share that responsibility as well with them, right? So they feel responsible the moment that freedom, that independence is given to them to be able to create really quality product. So doing this enabled us to be successful so far, right? It's not something that we've not found obstacles, but those obstacles removing them has allowed us to continue on this gamification route. So what were the outcomes? I mean, all of this ideation is great, right? What are the real outcomes? What did we really see coming out of this, right? We are in a current state of innovation, right? In most teams that practice this kind of idea, the state of innovation is where we are, right? Which means the speed of delivery is high even though there are extremely strict standards on how the code can actually go to production. The code cannot go to production unless it clears all the quality gates and guardrails. And in many cases, these guardrails are thresholds that alert based on what is seen in the code during that phase of the testing, right? Teams are highly aligned on the overall goals of the organization, but they're loosely coupled so that they can find autonomy in working themselves. Loose coupling also enables team to develop their own inclusion policies for ideas and for new thought and that enables them to get to that highly aligned goal in a faster manner, right? The other thing that has happened over time is that teams understand and accept that nothing is perfect, but we have to work on it as a team. And this is something that is a major sort of aha moment for teams that realize that, hey, we're not gonna get everything at one time. Speed and quality and everything is not gonna happen at once. We have to differentiate between what we need and that is going to provide our developer joy, right? So in all, morale has been high and very happily the engagement scores or the pulse surveys that are conducted regularly in companies has also resulted in sort of seeing some really high scores, right? So overall, the state of innovation is happy and we are able to provide a lot of information back to the developers on how they're doing. So you can measure them, you can create metrics. But remember that devs feel safer because they are not now being measured for what they bring to the table. Instead, it is all about making sure that there are great systems that enable their fast deployment and their fast innovation. So what did we get out of doing all this? So we are coming back to what we started with, which is we have an ability to now say we have healthy, happy, high performing teams that can innovate quickly, fairly quickly and continue to deliver quality products to delight the customer. This is the same sort of thought that we had when we started this discussion but remember that through this, we went through two years of pandemic and then now in the hybrid environment, we still can get to this, right? But the emphasis is on making sure we have tooling, we have the right kind of sort of concentration on developer joy and making sure that active inclusion allows us to get there faster, right? So if I were to just summarize what I spoke about and what the big takeaways from this talk are, is gamify the process, right? Use the pipeline. So if we look at the CI CD pipeline, we can take that and gamify that CI CD pipeline with gating and guardrails is nothing but a video game that a developer will enjoy to play, right? They want to be able to get to production, which is the final level. By getting through all of the initial levels, that's how they can sort of go through the pipeline, use the gating and guardrails to protect them and then finally get to the end of the process. So equipping the team is a no-brainer. You do not want the team to go out in search of finding tools that they can actually get help from internally. An internal tools team or an internal team that allows them to access all of the infrastructure easily, all of the security policies easily is a key distinction in high-performing teams. An active inclusion is something that goes a long way, right? For folks who feel there is not enough respect, there's not enough communication, waiting to hear what they have to say provides a lot of input to leadership to be able to make some significant and valuable changes in any organization. And this is the best benefit of the win-win from this is that people who provide their input also feel that they contributed towards the organizational structure as well. So that's a big win for any company. Developer satisfaction. So developer satisfaction is a very crucial thing when we talk about developer joy, right? Joy is when you contribute and you see that your core is accepted and everything's awesome, right? But developer satisfaction is when they feel satisfied not just in their work but also in their home environment, right? So the developer satisfaction and the overall wellbeing translates into innovation. A developer that takes time off after their own call and then comes back re-energized to be able to tackle on bigger, better issues is the kind of developer we are looking for. And so that is also a big takeaway for me from the past, right? And finally, the most important thing that came out of all this for us is that investing in tooling or efficient tooling enables something like now where we have a remote first reality, we have a hybrid system to work with and this kind of hybrid system is what I am assuming would be the future for all of us for the next, I would say 10 years or so. So efficient tooling is something that is a no-brainer and is a non-negotiable in today's day and age. It allows teams to work remotely and still be productive. So these are the big takeaways and this is all I had. So what I'm gonna do is then hand off to Ravi and Ravi, are there any questions that I can answer? Yes, thank you, Vilas, for the interesting session and the good thoughts that you need to find out about. Yes, do we have around four questions with Q&A? Let me read out those questions for you. The first is from Manjunath and it says, do you also see purpose and autonomy as what really matters? How would you rate them as compared to the others you listed? Okay, so I think I'll speak about autonomy first, right? Autonomy is crucial for any high-performing team in fact, I feel that the more teams are confident about their performance, the more they want autonomy, right? Because that provides that respect to them. They feel that, hey, we are adults, we can take these decisions and we can really succeed, give us that and we will succeed, right? So I feel that autonomy provides a team with purpose because unless that is provided, the teams do not find a way to self-grow. Otherwise all that remains is just meeting deadlines, right? So I would say that autonomy I would rate very high and I would actually see purpose as a sub part of autonomy because I think without autonomy, you cannot fulfill or even find purpose successfully. I hope that answers the question. Thank you, Velas, let's go on to the next question from Pradeep Chandran. It says, onboarding, giving predefined image which with code setup, it may be a miss of the new joiner to understand the how to set up the dev environment. What do you think? Yeah, I think that's actually an interesting point, right? So the question that I would ask is, how you're paying this person who's coming in, right? It could be a very high performing person or it could be someone who's coming in from a really, how to say this, good university. Think about how you want to use their time, right? When we thought about that, we were like, for example, we are hiring someone who's coming in from a really reputed university and we want them for their skills, right? They come in and then we are letting them figure out how to set up a dev environment instead of using their skills to be able to put production code, right? So I think that is the challenge that we saw and we actually found that setting up a dev environment over time is going to actually become easier because we want to try and containerize things even within the dev environment. So if you look at your Mac today or your Windows laptop today, they are essentially trying to make things as easy as possible for someone who comes in. Imagine how you use an iOS device versus what you would do with a Windows laptop, right? iOS makes it easy so that you can onboard. So you're not missing the onboarding. It's really saying, let's save you from that onboarding and utilize your significant talents and actually development of software. I hope that answers the question. Good, good question and great response. There's more to the next one here from an anonymous attendee. Many organizations which already do these in one way or the other are still affected by great resignation. Where developers who are looking for more continue to move towards organizations which do not use the same practices. What do you think organizations are missing here? Yeah, so I sort of read ahead a little bit, Ravi, on this. So that's why I moved to this slide. So what we actually found is that even when we did the tooling and we also gave enough support for folks to do onboarding and things like that, the softer skills were missing with leaders, right? So active inclusion is not really about the developers as much as about leaders retraining themselves, right? So that is what organizations are missing. And if you think about the great resignation overall, right? Folks who are leaving are not necessarily leaving because something is bad, but they're actually leaving because they themselves are trying to find a better place for themselves to live in, to work in rather, right? So it's not about good versus bad. There could be politics in two companies, right? But for the person who is moving from one company to another, they may just feel that, hey, this is going to give me something more than this other place. And most of those are soft things, right? Of course, there is money and all that involved. But if you bring in something like active inclusion where you're telling the person, I empathize, I understand where you're going with this. It creates a lot of retention bonus. We have not lost any person during that great resignation. Luckily, that's good. And that's probably because there has been open dialogue about it in our company. Okay, let us move on to the next one. It's a short question. How do you measure developer satisfaction? Is it a tangible metric? Yep, we can measure developer satisfaction. So developer satisfaction can be measured by multiple things, right? So there are KPIs like Dora metrics. You can utilize that to measure developer satisfaction. It's not a first order metric. It is a second or third order metric, right? Because developer satisfaction being high means that there is less barriers to innovation, which means it makes it more confident for the developer to commit change more easily and high quality change more easily, which means there may not be much incidents in production. And so you could say change failure would be low. There is a high rate of deployment, which means CI CD is enabled. And you'll see that overall the lead times or the cycle times are going down. So you can use the Dora metrics to measure developer satisfaction in a sort of a third, sort of a, how does this derivative kind of way. Thank you, Lars. And the next question is a bit Lindy here. Technology from JC Ramachandra. Technology keeps changing faster. We can't incorporate all the latest ones in our project every time. Some transformation projects run for years. However, the developers, especially the junior ones, always want to work on the latest. What is your advice in managing and engaging such a set? So very good question. This is something that I have been challenged with as well in the last couple of jobs where we've always had folks who want to do the shiny new object in the market, they want to do that. The challenge, Jayashree, is that you can't satiate them with legacy work, right? So the question then becomes, can you engage them in a meaningful way in finding something new? And that's essentially where, what we tried essentially was to create Tiger teams for innovation and enabling them to do things like show and tell kind of demonstrations. We would reward that by giving them projects that would be more about refactoring legacy code or sort of, instead of maintenance-based things, trying to show them how what they are working on connects back to the actual bottom line of the company. And in some cases, we actually allowed them to learn with the person who's most tenured in the team, telling them how this actually gives us our bread and butter for the company. And there are challenges actually in even in legacy systems that today folks do not know how to solve. So when someone shows something cool, you can always connect back saying, hey, by the way, this is a really cool thing. We did this 20 years ago and here is how we did it. But I'm saying this, I'm not saying that this has worked. In many cases, it has not worked. So it is definitely a challenge actually. In fact, I would say that that's an ongoing thing to chase down is how do we engage and keep people focused on fundamentals rather than chasing the next shining object. That's a hard problem to solve. Okay. I don't see any more questions in that Q&A icon. Thanks once again for the interest in the session. Thanks everyone. And I'm seeing the chat responses as well. Thank you so much for the feedback.