AWS re:Invent 2023 - Lead with AI/ML to innovate, reduce tech debt, and boost productivity (SEG205)

hi everyone welcome to this session over 5 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 death and we are going to actually talk about it today how you can address technical de or how you can actually manage technical de when proper mechanisms are put in place not only you can manage technical debt but you can reduce your overall to total cost of ownership in the long term my name is Anu Gupta and I 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 built 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 death and build a continuous process so it's not accumulated over time then my colleague an will come and she'll talk about a prioritization framework because that's really important is how do I prioritize technical de items later we'll hear from Justin from shutter St and he's going to give examples of real world use cases and how shutter stock was able to First identify technical Deb and address them and later on we'll talk about some common technical Deb patterns that we have seen and some AI tools that you can use to address those technical Deb patterns and we'll talk about some of the key takeaways so technical Deb 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 de 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 have been asked or have heard these questions why didn't you build it right the first time another question we know our technical death 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 death 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 uh there is an i paper that goes into more details about different categories of technical death that's linked on that slide but I'll try to focus on two technical death categories which are often overlooked first is process technical death it's often overlooked because you create processes over 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 there are inefficient processes or you can automate some of these processes and improve productivity of your teams for example you could have uh customer support and that service could be a manual process or can have some inefficiencies you can improve that by reducing that process technical death another example is people technical death think of people technical death as concentrated knowledge or concentrated information inform about the systems that have been built over time is just within few people in your organization what if those people leave or there is no skill development that's happening on a continuous process means people are making uninformed decision they're 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're not informed they would make the same decision and over a period of time you start accumulating the debt that's a 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 so 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 death 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 at a baseline you can clearly Define what kpi is for example you could be unit cost metrics for you or just customer satisfaction what is that kpi that you're looking for from that Baseline and next is you take action you prioritize investments in tech technical deth based on the impact from the Baseline so you identify is it impacting your baseline or not and if it is it's an an normally 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 death and address them and depend 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 Gartner Gartner 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 flywheel what's the mental model to build a continuous process let's talk about that let's look at a flywheel that you can build for your organization to build that continuous process you start with Investments in your technical Deb those investments will reduce operational overhead over time for examples 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 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's 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're aware of what are the right cost optimized design patterns to use and if they making the right decision you will have higher efficiency and improved efficiency which will further lead to reduced operational overhead and that will actually spin that continuous cycle that we saw so let's summarize what we discussed so far technical Deb is beyond code refactoring or design related and you will hear some of these examples from an and Justin lron as well without 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 death 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 n to talk about the prioritization framework that you can build thank you n my name is an hunt and I'm the worldwide product manager for digital native businesses at AWS worldwide in this role I talk to product leaders at some of our most Innovative and hypers skill 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 when news 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 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 priority ization framework which we're going to 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 H 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'll become completely unmanageable you as a leader in your business are in a similar situ 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 ding 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 you'll hear things like I thought I was going to love this product but I called customer support 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 the news was pointing out these can actually decrease your customer experience and create a real issue for your business so one anti patternn that I hear a lot from leaders around the world is I know how to solve this I'm just going to throw in the best people and let them take care of it I'm going to hire the best and just let them go or they'll say I'm going to 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 the 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 at 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 in 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 5 years ago you built a really great system state-ofthe-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 new technologies that come out that maybe 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 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 part of the fly well beinging 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 lag 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 AIS 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 man 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 it 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 outside negative impact finally in a few minutes we're going to hear from anig 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 an my name is Justin heisa 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 may not know a brief background on shuttershock 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 turbo squid brand and this content comes from over 2 million contributors globally spanning 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 and 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 integration what are the key values that we provide to our customers there's a couple one of them quite simply is a license and a license is per 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 thatt 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 increase with submission and we need 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 an 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 so an I our IP review and legal form process is more complex and our technical quality process looks for things like blur noise and other artifacts in content it's also important to understand your risk tolerance so when applying automation different buckets of cont 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 is has specific rejection reasons applied and we were 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 to 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 over 300 guidelines that I need to have in my mind would make making a decision that's a lot of cognitive load that improve 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 in to end the education piece I touched on a little bit our content operations team we worked with them to establish a new ground Tru data set to build this model on which we did on Amazon sagemaker we also deployed inference on Amazon Sage maker 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 and asking questions now and informed design what do I mean by this taking the time to understand the problem end to end I I have to and the other piece is stakeholder management I get the question uh 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' 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 their expectations of personalization every application and interaction that customers um perform the Baseline expectation as personalization and an touched on that and to our earlier point we had product drift we weren't keep our investment did not match the pace at which customer expectations existed for personalization and this surfaced 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 kpis in how certain areas of our content catalog weren't performing as well as we dug into this we needed to re we Revisited those and enhanced 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 a beautiful turquoise beach photo aerial um 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 they prefer some close-ups and illustrations in a small proportion our style ranker learns those user preferences based on their engagement activity in 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 and of the images a user engaged with sty ranker learns how to represent user 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 they might be personalized toward towards their country or other variables but not specifically for them style ranker ranks those search results so that 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 a user in the travel company will get more casual wide angle shots we touched on through various testing and iterations we've now learned that we've driven all of our key kpis 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 inua flywheel reference by establish establishing a clear ownership model over this domain and focus we able to dramatically increase our product velocity in summary I hope you can take some of these real world examples of how to apply AI to your own businesses to reduce technical debt and a newe back to you to talk about some approaches to identify and manage Tech debt and transform that into Innovation acceleration thanks Justin so as you might have heard Justin talked about how shutter stock was able to reduce people and process technical debt which were not really technical debt to start with they were just limitations so Li today's limitations do become tomorrow's technical death and it is okay 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 iterate 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're 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 death using something called modular monolith so it allows you to scale your system so you're pay 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 death 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 flywheel that we saw earlier we talked about creating a continuous process and how investments in your people and continuous skill development can keep that flywheel going but what if I tell you there is a better way to spin that wheel faster is augment AI tools along with your teams to spin that wheel faster now these AI Services I'm going to actually talk about the AWS AI services that you can use and some of the common design patterns that we have seen these AI tools will augment with your teams to spin that wheel faster because they learn by themselves and they are doing continuous skill de development by themselves so let's look at the common technical deck patterns so there are five patterns that I have come across in my customer conversations and I'm going to talk about how AWS Services can speed up Innovation by reducing technical death for those patterns the first is architecture 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 AI 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 start 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 de item is observability and I'm not just talking about monitoring logs or metrics observability 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're looking at different logs and you're trying to correlate different events to identify the root CA 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 devops 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 an'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 your all the teams are following the same coding standards which is where you look at how much time developers are spending on onboarding 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 AI companion for your teams and generate the code and while your teams are focusing on bu building new features it can actually allow them to Adare 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 how many incidents and findings have happened in the last year and you try to measure that as a metrix 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 AI 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 vulnerability is and at the same time suggest 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 C 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 use generative AI capabilities along with Amazon connect because it can provide that agent assisted experience to your customers in a more personalized manner so your thems can focus on more productive tasks 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 build trying to build the perfect application it is likely that you don't have the right visibility into technical de so it's important that you do that prioritize what matters using the framework that an talked about a prior Iz ation framework you should think of managing technical death as a continuous process it's not something that you do one time and forget about it because then the technical death will accumulate and then you need to address it so build a continuous mechanism or a process to address technical death it's important for business and Technical teams to work together to prioritize and address technical death and it's a common notion that technical death 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 de and lastly you can use some of these AI 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 death here are some resources for you to dive deep into later on or the topics that we talked about here earlier so today after you leave reinvent I'd recommend that you think about do you have the right visibility into technical death if so do you have the right mechanisms to address technical death and manage technical death and third if so do you are you using the AI tools to reduce the additional overhead so your teams are much happier and they're actually innovating for your customers with that I want to really thank you for coming for this session

2023-12-09 10:18

Other news