Lead with AI/ML to innovate, reduce tech debt, and boost productivity

Hi, everyone. Welcome to this session over five years at AWS. I have talked to a number of customers from large enterprises to digital native businesses. And the most common thing that I've heard in this conversation is how do I address technical debt? And we are going to actually talk about it today, how you can address technical debt or how you can actually manage technical debt when proper mechanisms are put in place.

Not only you can manage technical debt, but you can reduce your overall total cost of ownership in the long term. My name is Anu Gupta and I'm a Principal Solutions Architect with AWS. My role at AWS is to work with customers to optimize workloads on AWS. And today we are going to talk about some of the tools that you can use. Some of the mechanisms and processes that you can actually build in your organizations so your teams can effectively work and innovate for your customers.

So let's look at the agenda for today:

• First, we are going to define what is technical debt and there are different definitions so that we are on the same page of what is technical debt.

• Then we are going to look at some of the technical debt categories and some often overlooked categories. I would say we are going to talk about what those are.

• And then we are going to actually talk about an actionable plan that you can build and you can use that plan to address technical debt and build a continuous process. So it's not accumulated over time.

• Then my colleague Anne will come and she'll talk about a prioritization framework because that's really important is how do I prioritize technical debt items later?

• We'll hear from Justin from Shutterstock and he's going to give examples of real world use cases and how Shutterstock was able to first identify technical debt and address them.

• And later on, we'll talk about some common technical debt patterns that we have seen and some AI tools that you can use to address those technical debt patterns.

• And we'll talk about some of the key takeaways.

So technical debt, what is technical debt, technical debt doesn't really appear on your financial statements? So it's not really a financial debt. It's basically all the technology related work that's accumulating over time and is a death that you need to pay eventually and requires investments if not paid in time or not managed in time. It starts impacting your customers and starts impacting your customer experience.

Now, how many you have been asked or have heard these questions?

• Why didn't you build it? Right? The first time,

• another question, We know our technical depth but it's not our priority.

• And another question that you might have heard. So what value are we going to get after retiring technical debt?

So these are some of the questions that we have heard from customers and we are going to answer some of these questions in the coming slides.

So before we talk about the process and mechanism, let's look at some of the technical debt categories. Here are some of the examples on the slide that you can see. Now, this is not really an exhaustive list. There is an I Triple E paper that goes into more details about different categories of technical debt that's linked on that slide. But I'll try to focus on two technical debt categories which are often overlooked.

First is process technical debt, it's often overlooked because you create processes over a period of time, those processes become inefficient but they are still there and you don't really without the right visibility, you don't know that they are inefficient processes or you can automate some of these processes and improve productivity of your teams.

For example, you could have customer support and that service could be a manual process or can have some inefficiencies. You can improve that by reducing that process, technical debt.

Another example is people, technical debt, think of people technical that has concentrated knowledge or concentrated information about the systems that have been built over time is just within few people in your organization. What if those people leave? Are there is no skill development that's happening on a continuous process means people are making uninformed decision. They are not making right decisions on price performance ratio. Whether it's a cost optimized decision or not, or whether it's secure or not, if they are not informed, they would make the same decision. And over a period of time you start accumulating the debt. That's the people debt.

So now we have talked about the categories at Amazon, we believe in building mechanisms for recurring problems. So mechanisms require you to create some processes to solve them and a flywheel that will keep it going and provides a feedback loop to improve it over time.

So think of flywheel as a mental model of how you want that to continuously work and mechanisms are the processes that will support the flywheel.

Now let's look at the flywheel and the mechanism that you can build.

Do you start with measuring? So without the right visibility, you won't be able to address the problem. So first is you start with visibility, identify what metrics really matters to your business for technical debt and examples could be system downtime, developer productivity, customer satisfaction score or just team happiness, right? So there are different metrics that you can measure, use those metrics to monitor, have tools in place to monitor those metrics and set a baseline.

Because how would you know, whether it starts impacting your business or customer experience, if you don't really have a baseline, so you create a baseline using the monitoring tools. And once you have created a baseline, you can clearly define what KPIs, for example, you could be unit cost metrics for you or just customer satisfaction. What is that KPI that you are looking for from that baseline?

And next is you take action, you prioritize investments in technical debt based on the impact from the baseline. So you identify is it impacting your baseline or not? And if it is, it's an anomaly, you start addressing them and be outcome driven.

So again, going back to the metrics, if you don't really have a way to monitor and measure, you won't be outcome driven, you won't really measure the results. So once you have addressed the technical death, start measuring the results that how did it really solve a business problem for you? How did it add value to your business? And then you revisit and reiterate on that.

An example could be you allocate a percentage of your sprint to get the right visibility into your technical debt and address them. And the percentage would depend on your organization depending upon your teams, you can come up with what's best for your needs.

So before we dive into the flywheel, this is a quote from Gardner, Gardner predicts leader who actively manage technical debt will achieve at least 50% faster service delivery times to their business. It emphasizes the importance of building a continuous process, not letting it accumulate and then address it.

Now, you would ask, what's the fly wheel? What's the mental model to build a continuous process? Let's talk about that.

Let's look at a fly wheel that you can build for your organization to build that continuous process. You start with investments in your technical debt, those investments will reduce operational overhead over time. For example, you could be looking at a better customer experience and you could your teams will be spending less time managing technical debt, they will be spending more time building new features for your customers.

And if they are building more features means they are happy, you will have happy and motivated team because now they're spending time on what they like to do means building new features for your customers. This also leads to better customer experience or improved customer experience.

And when your customers like your product, you know, definitely they are going to actually increase the adoption of the product. You will probably get more customers eventually leads to higher revenue and then you will have investments, higher investments in technical debt.

So you take those revenue and then invest it further in your technical debt and the process continues. So there is a cycle that's built. But what keeps that cycle going is continuous skill development.

So if you don't invest in your people for skill development, they are going to make uninformed decisions. But if you are doing continuous skill development, they are aware of new features that are coming in. They are aware of what are the right cost optimized design patterns to use. And if they are making the right decision, you will have higher efficiency and improved efficiency which will further lead to reduced operational head. And that will actually spin that continuous cycle that we saw.

So let's summarize what we discussed so far:

• Technical debt is beyond code refactoring or design related. And you will hear some of these examples from Anne and Justin later on as well.

• Without knowing what to address, you cannot really solve a problem. So having the right visibility is a key building, a continuous process for addressing technical debt is a success metric.

• If you don't really put a continuous process in place, it accumulates over time and then you have to address it.

Now let me hand it over to Ann to talk about the prioritization framework that you can build.

Thank you Anu. My name is Anne Hunt and I'm the worldwide product manager for digital native businesses at AWS worldwide. In this role, I talked to product leaders at some of our most innovative and hyperscale companies all over the world and what a lot of our product leaders both on the engineering and product management side as well as on the business side are telling me is they say we know, we have technical debt and we know it's slowing down our innovation and yet we also have a whole backlog of products and features that we need to build. How do we prioritize one against the other?

So Anu showed us a really great mechanism for measuring monitoring and taking action on technical debt. If you want your teams to work independently and really get this going, they actually have to have leadership buy in from the very top of your company. And the reason for this is if your teams are trying to squeeze in a little bit of technical debt work every sprint, which is a good thing to do. But if that's all they ever get to do, they'll never be able to work on those really big strategic items. And so leadership buy in is super important.

The other thing that's really important to keep teams working independently and innovating is that they have a shared prioritization framework which we're gonna talk about next. With the shared prioritization framework, they can make their own decisions instead of having to get caught in some kind of bureaucratic decision making by going up the hierarchy every time they need to make a decision.

So as a leader, why should you pay attention to technical debt? I like to compare it, it's not financial debt, but I like to compare it to financial debt a little bit. So suppose one month you make a decision to take out a loan for something, say a bicycle with a small amount of interest, it's perfectly appropriate. And then at the end of that month, you decide. Hm, I want to buy something else. I'm not really wanting to pay it off right now. So you put it off a bit and maybe that's appropriate as well. But if you keep doing that every month, eventually that debt will get so big that it will become completely unmanageable.

You as a leader in your business are in a similar situation except worse because every single development team in your company may be separately taking out those technical debt loans and sometimes your team can leave and go to another company. But you as within the business are left with that technical debt. When they leave, Jeff Bezos said, if you don't understand the details of your business, you are going to fail. And I admit that when I first heard that I used to think, yeah, you know, I know the details of my business. I understand revenue, I understand profit. I understand what our products are, product features and that stuff.

But there's something under the covers that's equally important, which is this technical debt which can be anywhere in your system. And that's something that leaders also have to understand.

So let's turn to a prioritization framework. I like to start with what is the right product because that really drives all of these decisions about what we prioritize. And we like to start with the customer and work backwards from their needs.

The right product is one that delivers customer value, customer value is delivered when the product achieves the customer's needs desires or pain points. And when you do that, the customer actually repays you with time attention or money. And that value exchange allows your business to achieve its objectives as well.

The right product is one that is driving customer value and business objectives at the same time as effectively as possible. I call this the sweet spot. But your product is actually more than just technology from the point of view of the customer. The product is like an abstraction layer over the people mechanisms and technologies that together make up your user experience.

And if you're not sure if this is true, take a look at some customer reviews and different products, you'll hear things like I thought I was gonna love this product, but it called customer support. I had a terrible experience or I tried to put in my credit card and it wouldn't take it and then I didn't know what to do or I couldn't end my subscription when I wanted to these kinds of processes and people issues which are really types of technical debt. As Anu was pointing out, these can actually decrease your customer experience and create a real issue for your business.

So one anti pattern that I hear a lot from leaders around the world is I know how to solve this. I'm just gonna throw in the best people and let them take care of it. I'm gonna hire the best and just let them go.

Or they'll say "I'm gonna implement a new process, maybe Scaled Agile Framework or something like that and we'll just get everybody aligned." What happens when you do this is you can actually end up in a worse spot than you were before. You started to see that this is true.

Think of a case where you hire a great developer and you bring them into a team and suddenly they're confronted with this massive legacy monolith. And the only way they can make any changes or innovate or create anything new is if they have to deal with all these dependencies and try to break up the monolith and everything and eventually they just get frustrated and they could actually leave.

One more point I want to make, which is very specific to AI is that the core development team is larger than it used to be when you're building an AI powered product. Really the first thing or one of the first things you have to think about is what data do I have that I can use to drive my artificial intelligence. And that means that data is really important and you have to get that together. So data engineers often come into the picture and data scientists and then you have to think about what AI can I buy or build to run that product as well. So then you've got to bring your AI scientist in and you've got to start doing prototypes. And so what that means is that the very first point when you're listening to customer needs desires and pain points and you're brainstorming with your team about what solutions are possible. You need to have more of these people in the room because only they know what you can really build with the data and the AI.

So what we used to call a product trio, I would now call at least a product quartet.

Returning to the mental model of technical debt. Suppose five years ago, you built a really great system state of the art, totally achieving customer value business objectives and it was running great and then you leave it alone over time. That sweet spot actually drifts away and it ends up with your product not being uh in that sweet spot anymore.

One example is what I call the drift away from business efficiency. This happens a lot when you build a homegrown system or you have manual processes, which is the best you can do a few years ago. And now there are new technologies that come out that may require, that can be automated or maybe require less operational overhead. So even though the customers still love your product, it's not actually delivering on the business value that it should. And this will actually end up leaving you open to the competition who might be adopting those new technologies.

And we, we're going to hear in a minute from Shutterstock, from Justin, from Shutterstock, he's going to talk about a manual process that they innovated around and improved greatly.

Another example is the drift away from customer value. So this is something that is happening a lot right now. It happens because customer expectations change with AI on the scene and everyone talking about it, customers expect a much better user experience and a much more intelligent product than they used to. And those expectations are changing rapidly. So your product that used to be in the sweet spot is now still delivering business objectives for a while, but the customers can quickly get dissatisfied with it, which leads me to suggest this prioritization framework.

I would start number one with the effects on customers. A lot of people don't realize that technical debt does have an effect on customers pretty directly. In fact, in some cases, I've actually seen that leading indicators of a legacy system that needs to be refactored are that there are repetitive customer issues occurring that you can't fix because they would be too big and you would need to do a strategic change to your system, either the people, the processes or the technology. So I would look at that first. Is that technical debt impacting your customers?

Secondly, and very important as well. How is this impacting your internal team? We talked about the part of the fly well being, how you, you know, people engage in continuous training and the motivation of your team can drive innovation. If you're not doing that and you have a legacy system, you're really great people on your team, your top talent will start becoming dissatisfied because they can't innovate the way they really think they should be able to and they should be able to and finally effects on the business, which are sometimes a little bit of a lagging indicator. You see those after the customers and the internal team become very dissatisfied.

Let's look at a, a graph here with cost. People talk about this a lot. We have investment on the y axis and time on the x axis. The blue line represents the cost of a refactored system and the pink line, the cost of a legacy system. So looking shorter term, you'll see that there is a certain investment you have to take to manage and pay down technical debt. But if you took the area under these two curves, you'd see the area under the blue line is actually smaller than the area under the pink line. And what that means is that the cost, if you look out a little far enough will be lower if you uh actually refactor and fix your system.

Secondly, let's look at a graph that takes into account satisfaction of customer in the team. In this graph satisfaction is on the y axis and time on the x axis. The customer line is blue and the team line is pink. What I've seen a lot is that with technical debt in the immediate term, both the customer and the team will start out pretty satisfied. In the case of the team, they quickly get dissatisfied when they realize that leadership is not prioritizing technical debt. And so they have to continue to work with the legacy system. The really great talent on your team will end up leaving and the people who remain will stay at a steady state of lower satisfaction where they're really not driving innovation for your business. And that's a bad state to be in an even worse line is the one that you see here with the customer where the customer satisfaction will actually drop all the way down as your competitors come in and create a more state of the art system.

Just to summarize AI has not changed a few things. The things that hasn't changed is that technical debt is still very, very much a business concern, not just a technical concern and it grows over time. And the best way to prioritize it is always to start with the customer experience and work backwards.

What's new is that customer expectations are changing faster than ever with AI. The core team is larger than it used to be and technical debt that has to do with data ends up having a really outsized negative impact.

Finally, in a few minutes, we're going to hear from Manu again, who's going to show us the good side of this equation, which is that there are some new AI powered tools that can help you monitor, manage and action on technical debt. But before that, I want to hand it off to Justin from Shutterstock, who's going to give us some really interesting uh examples of what they did there. Justin, thanks.

My name is Justin A, I'm the vice president of data services at Shutterstock and one of my key responsibilities there is around content life cycle. So this is around our content ingestion from our contributors, our search discovery and personalization experiences as well as our generative AI product.

Before I get to my two use cases for those of you who may not know a brief background on Shutterstock. We operate a digital content marketplace and within that marketplace, we have over 700 million assets ranging from photo video, audio sound effects as well as the world's largest 3D content marketplace in our Turbosquid brand. And this content comes from over 2 million contributors globally spending 200 countries and last year alone, they submitted 80 million assets into the marketplace.

We're extremely proud of the fact that we've paid out over $1.3 billion in lifetime earnings to our contributors. And in many cases, this has dramatically improved their quality of life. We meet customers where they have content and creative needs. So from our traditional offering like our web and mobile products to APIs SDKs and for those of you that aren't aware, Shutterstock content powers some of the largest multimodal generative models on the planet. And for these customers, we support direct storage integrations.

What are the key values that we provide to our customers? There's a couple, one of them quite simply is a license and the license is legal permissions around how a piece of content can be used. The other key components that are important are around our historical technical quality, around our metadata quality and around some of the legal processes we apply from a model release perspective and also property releases.

The first case I'd like to talk about is how we boosted productivity and reduce that for our content review function. What is content review and why do we do it? I touched on some of those aspects to provide those quality standards and legal requirements and guarantees content goes through a review process as volumes increased with submission and we needed to manage costs while also managing quality. We need to re evaluate our technology and business processes involved in this to scale and overcome limitations.

We knew that we needed to apply automation, but we needed to learn about where, why and how and critically we needed to ground and align people. This ranged from our content operations team product technology. And as Anne mentioned, our data science function, the grounding mechanism to start was to orient everyone on our key KPIs. In this case, it was unit cost review. In order to know where you're going, you need to know where you're starting from. And having a baseline metric is critically important.

This pie chart represents a unit breakdown of how much time is spent during various aspects of the review process. And each of these have varying complexity too. So an RIP review and legal reform process is more complex and our technical quality process looks for things like blur noise and other artifacts and content. It's also important to understand your risk tolerance. So when applying automation, different buckets of different buckets of review have different risk profiles. So making a mistake on whether or not a content is a piece of content is blurry or not, is very different from making a judgment on an IP process.

As a result of these things we chose on our technical quality aspect to start first, this still represented a significant impact to our business while also having a lower risk profile on the tech side. The first thing we need to do is establish a ground truth data set. Historically, our content review has specific rejection reasons applied and we are prepared to go start training a model. But when we were doing so we uncovered a piece of process that we weren't familiar with and it exposed itself in the form of data debt.

So when a content reviewer historically looked at a piece of content and made an assessment, they may have selected that the piece of content was rejected because it should have had a property, a model release and didn't, but it was also blurry and they didn't select that it was blurry. Also, this caused a problem for having a reliable data starting point for training a model. As a result of this, we had to go through and work with our content operations team to establish a new ground truth data set.

On the process side, we had to look at our content review guidelines. When I'm a reviewer looking at a piece of content, i have 300 guidelines that i needed to have in my mind when making a decision, that's a lot of cognitive load that improved, that impacts review time as well as quality. And lastly, we applied tooling efficiencies to make sure we understood that the tool they were operating in was operating as efficiently as possible.

The results of these activities combined on the image side was a 35% cost reduction compared to 2022 on the red line. You can see that that is the baseline cost comparison to 2015 and the blue is our submission volume rate on the video standpoint. The impact was even greater at 51%. But there's a larger financial impact as video content also takes more time to review and thus is more costly. And this was magnified by the fact that there was a large spike in submission volume in blue. So having this unit cost reduction was critical for being able to manage our costs.

Some key considerations here, i touched on the baseline measurement data, an understanding of risk tolerance and customer focus was critical. Having our data scientists and the rest of our engineering team collaborate closely with the people. Actually using the tool and executing review was very important for them. Understanding the entire process end to end the education piece. I touched on a little bit our content operations team, we worked with them to establish a new ground truth data set to build this model on which we did on Amazon SageMaker, we also deployed inference on Amazon SageMaker and as we planted the seeds for them, understanding how data quality impacts automation going forward. They now have this consideration in mind when they're making decisions from a process standpoint, they ask questions about, well, what data are we collecting? How does this impact? Hey, if we store it this way, is it still usable for models? So they're actually being proactive in asking questions now and informed design.

What do I mean by this taking the time to understand the problem end to end I have to. And the other piece is stakeholder management. I get the question. We're not, we're not coding yet. Like what are we doing? And it's critical that you're able to communicate and push back that having an informed design and a plan is critical after we had established that we hit all of our target milestones from a delivery standpoint.

The second case, I'd like to talk about is customers and the expectations of personalization. Every application and interaction that customers um perform the baseline expectation as personalization. And he had touched on that and to an earlier point, we had product drift.

"We weren't, our investment did not match the pace at which customer expectations existed for personalization and this service itself in the form of process and organizational debt. So a combination of people departure and reorganizations led to a lack of focus in this area.

We were looking at some baseline KPs and how certain areas of our content catalog weren't performing as well as we dug into this. We needed to, we revisited those and enhance some of those KPIs. And we knew that we needed to focus back on the customer. In order to have a next generation solution.

We discovered that the visual aspects of images were quite important to user selection criteria to learn visual styles. We've been experimenting with different image features. Here's some examples that we use. You can look at this photo, it's beautiful turquoise beach photo aerial. We also experiment with some first party data we've collected as well as various vector embeddings.

Here's some examples of images licensed by a user from a company in the food industry. You can see that they have a preference for dark and homogeneous backgrounds and prefer stocky images versus in the wild. If you prefer some close ups and illustrations in a small proportion, our style ranker learns those user preferences based on their engagement activity on the platform.

Here we see how it works for each user. We have their engagement history and a set of features that identify them such as their user identifier, the company they work for maybe the country they operate in. Here. We have the food industry user we saw before and a travel company user and they're interested in more wide angle shots and travel images with bluish colors based on the features of the images.

The user engaged with style ranker learns how to represent users and images in this visual space in there, elements with similar styles are embedded closely. So basically we can compute affinity scores for all of our users as well as its relationship to the content in our catalog. And here's the application in our search results.

Previously, users might have gotten less personalized results from the search engine. It might be personalized towards their country or other variables, but not specifically for them. Style ranker re ranks those search results. So the users get the content that fits their style preferences. For instance, when searching for people images, food industry, user would get these stocky close up images with homogeneous backgrounds related to the food industry. While using the travel company, we get more casual wide angle shots, we touch on through various testing and iterations. We've now learned that we've driven all of our key KPs from our search success rate to our licensing rate and our conversion rate. All those KPIs have improved as a result of this capability. And this was a clear sign that realigned our product to meet the customer needs, as well as our business objectives to anu's flywheel reference by establishing establishing a clear ownership model over this domain and focus we are able to dramatically increase our product velocity.

In summary, i hope you can take some of these real-world examples of how to apply a i to your own businesses to reduce technical debt and the news back to you to talk about some approaches to identify and manage tech debt and transform it into innovation acceleration. Thanks justin.

So as you might have heard, justin talked about how shuttle stock was able to reduce people and process technical debt which were not really technical debt to start with. They were just limitations. So today's limitations do become tomorrow's technical death and it is ok because it may not be the best choice to build that perfect application when you are just starting as a business.

So let's take another example of a monolith application when you are starting as a business and you're trying to just test the market feasibility and then look looking for experimentation. The goal is speed, you want to rate as quickly as possible for new features in the market. And at that time, you may make a decision to just build a monolith application because you can actually deploy new features much more quicker to those applications in the process. You are making some reckless, some prudent decisions on the limitations and you may not really have the same availability and resiliency requirements at that time.

But as your business grows and then you have to scale your system, there are new requirements that come in, there are limitations that would come in. You won't be able to actually scale that system to meet the new user demand. And at that time, you need to have the right visibility and then you need to address that architecture, technical debt using something called modular monolith. So it allows you to scale your system. So you are paying off the debt and eventually, as you scale further, probably you have new lines of business, you have new products and offerings. And at that time, what you're looking for is you hire more people to work on developing new features, you want them to be working independently. And at the time, the limitations become technical debt would be you think about going from a monolith architecture to a microservices architecture, you measure the outcome, the results that it is giving you.

So without a proper mechanism, you would not know when those monolith application designs have started impacting your customers or customer experience. And then teams may be unhappy with additional overhead of managing that monolith application.

So let's go back to the fly wheel that we saw earlier. We talked about creating a continuous process and how investments in your people and continuous skill development can keep that fly wheel going. But what if i tell you there is a better way to spin that wheel faster is augment a i tools along with your teams to spin that wheel faster. Now, these a i services, i'm going to actually talk about the aws services that you can use and some of the common design patterns that we have seen. These a i tools will augment with your teams to spin that wheel faster because they learn by themselves and they are doing continuous skill development by themselves.

So let's look at the common technical debt patterns. So there are five patterns that i have come across in my customer conversations and i'm going to talk about how aw services can speed up innovation by reducing technical debt for those patterns.

The first is architectural technical death. And the most common example is monolith application you start by measuring how much time to market do you have for new features and what's the cost of maintenance for that particular application? You start to gradually decompose the application. But the challenge that i have heard from a number of customers is how do i decompose the monolith application? This is where we provide some of these a i tools that you can use. There is aws microservice extractor for.net application which will analyze the code for you and identify and create that visual dependency graph along with machine learning algorithms, making recommendations of microservices that can give you a starting point for creating microservices from that monolith application. Similarly, there is another tool called v function. It's a aws partner tool they provided for java application, which will give you similar dependency graph and then help you get started with the code refactoring journey.

Another most common technical that item is observable and i'm not just talking about monitoring logs or metrics observable is do you really understand your customer experience? End to end think of a production issue. When you are in a production issue, you are troubleshooting and looking at different metrics, you are looking at different logs and you're trying to correlate different events to identify the root cause and this is happening while your customer is impacted. What if there is a better way that you can proactively identify any impacts to your customer before it happens? And that is when you can use some predictive monitoring tools. So aws amazon dews guru provides that proactive monitoring. It helps you identify any performance issues before it actually starts impacting your customers. You can use it to create a baseline because it learns the application behavior over a period of time and identifies anomalies and then notify you when needed of those anomalies. So you can proactively take actions, try to rectify before your customers are impacted.

Now, this is something that you might have heard or seen before. High quality software is cheaper to produce and to anne's point earlier, it is cheaper to maintain a refactored system over a legacy system over a longer period of time. So we are going to talk about the third technical debt item which is coding quality or coding best practices. Your teams require knowledge of different programming languages, different coding standards and they need to remember all the different coding standards when they are actually building these features for your customers. A common challenge that i have heard is non-standard coding best practices is how do you put governance around it that all the teams are following the same coding standards, which is where you look at how much time developers are spending on, on boarding, how much time they are actually spending, trying to commit code. And you will realize that you need to actually improve efficiency. And the way to do that is we have recently released amazon code whisperer. It can be an a i companion for your teams and generate the code. And while your teams are focusing on building new features, it can actually allow them to adhere to all the standard coding practices for your organization. So you don't, don't have to remember everything. It will reduce your code review cycle as well. So the time to market is also increased.

The fourth common technical debt item that i have seen is identifying the security vulnerabilities. And this is more of a process thing how many incidents and findings have happened in the last year. And you try to measure that as the metrics, you will realize that there are ways you can actually prevent certain incidents from happening and then you can reduce some during the development life cycle itself. So aws provides amazon code guru security. That's an a i tool that you can use. Your teams are spending a lot of time trying to review the code, identifying any vulnerabilities or performance issues. And a common challenge is how do they make sure that they are following all the security guidelines that you have and they need to manually track the bug fixes as well. Amazon code guru security identifies code code vulnerabilities during the development life cycle itself before it actually goes into production. So, wouldn't it be nice to have a tool that detects vulnerabilities? And at the same time suggests what's the remediation for that vulnerability? So it is reducing that additional overhead that your teams have.

The fifth common technical debt pattern that i have seen is manual processes. Now, there could be inefficiencies. The processes could have been created earlier, but they are no longer applicable. And the common example is customer service. When you want to serve your customers, customers are demanding, they would like to actually have customer service whenever they want, whichever channel they want, they want to actually use a mobile phone or a laptop to reach out to your customer support. How you can provide that customer experience is used generative a i capabilities along with amazon connect because it can provide that agent assisted experience to your customers in a more personalized manner. So your teams can focus on more productive task than responding to some of these questions.

So this brings us to the end of our presentation. But here are some of the key takeaways. I want you to remember work backwards from your customer requirements. Instead of trying to build the perfect application, it is likely that you don't have the right visibility into technical debt. So it's important that you do that prioritize what matters using the framework that ann talked about a prioritization framework. You should think of managing technical debt as a continuous process. It's not something that you do one time and forget about it because then the technical debt will accumulate and then you need to address it. So build up continuous mechanism or a process to address technical debt. It's important for business and technical teams to work together to prioritize and address technical debt. And it's a common notion that technical debt is only for the technical teams. You need to involve business team because it is adding business value. You deliver results and you work with them to prioritize investments in technical debt. And lastly, you can use some of these a i services that i talked about such as amazon code whisperer code guru security to reduce that additional overhead on your teams and boost their productivity, their happiness on reducing the technical debt.

Here are some resources for you to dive deep into later on our the topics that we talked about earlier. So today after you leave re invent, i'd recommend that you think about do you have the right visibility into technical te? If so do you have the right mechanisms to address technical debt and manage technical debt? And third if so do you, are you using the a i tools to reduce the additional overhead? So your teams are much happier and they are actually innovating for your customers with that.

I want to really thank you for coming for this session."