Inside Amazon Robotics: AI, Automation & Engineering Leadership with Sagar Mohan '98, G'03

[music] Hi, I'm Jeff Hemsley and this is another episode of Infoiversity from the High School at Syracuse University. Today we're joined by Sagar Mohan, a technology leader whose career spans enterprise systems startups and largecale robotics at Amazon. Zagar earned his bachelor's in computer engineering from Syracuse University's engineering and computer science school and later completed his master's in information management at the high school while working full-time. His career has included included launching an SAP practice at largecale at a large-scale startup, co-founding an enterprise procurement company, navigating acquisition, and now leading approximately 50 engineers at Amazon Robotics, developing software that manages the largest industrial robotics fleet in the world. Today we'll talk about interdisciplinary training, startup lessons, robotics at scale, and what it means to lead technical teams in high stakes environment. So welcome. >> Thank you, Dr. Emley. >> So you studied computer engineering and later earned your masters here at the high school in information management. How did that mix of engineering systems engineering and systems um shape how you approach problems today particularly in your current environment? >> Yeah. Uh yeah, it's it's been an interesting journey. I would say the engineering background that I got from uh the school of engineering gave me a good foundation for how to decompose complex problems and and and and solve like very specific niche problems. But really the systems thinking um from the high school experience helped me think about organizational problems. How do you solve business uh you know business environment problems and if you think about it most of the environment around us is is a set of complex um complex problems right uh complex systems. And so that that experience from the high school really helped me kind of navigate into the business environment um whether it was you know starting companies or or working with customers um to really decompose what what their business environment looked like and and and really find the right solutions for them. I'll maybe share a bit of an interesting story. Right after graduating um from high school, I moved to Boston and joined a startup that uh worked with a lot of different types of customers on business process automation. And one of these customers uh was a Canadian insurance company. And I had just started with this company in Boston. I was probably week two or three in. I got put on this project. And I happened to fly out uh to Canada the night before everyone else did. Uh so I'm pretty new to the company. I get to Canada. get to the client's office and I I learned from my manager that they've missed their flight and none of my team from Boston was going to be there. So, I find myself in a in a client's environment by myself as a professional services uh consultant. So, I can't tell my customer that I'm new to the company uh because they're paying for us. So I ended [clears throat] up having to spend the entire day working with um this was Blue Cross of Canada uh sort of really understanding their business process and mapping out everything that they do and and really thinking about their systems. It was an interesting experience because there were about a dozen or so different groups that were there and they all thought of their uh their environment as very different and unique and complex. And when we mapped it out, I kept going back and and looking at the commonalities and and thinking of their systems as one monolithic system, kind of bringing in all of the the different things that I was hearing that's that seemed very similar uh to me from my end. Um, and where we ended up was mapping out one business process that actually accommodated all of their needs and they also found a lot of commonalities within their groups. Uh, and and by, you know, this was around 4:00 the the team from Boston shows up and I was a little terrified cuz I'd kind of taken the lead here on my own. Um, but but really it was, you know, being able to listen and understand how their systems are designed today, map it out to where we want to go, come up with a proposal. I ended up uh on that project for the better part of the year and effectively built the entire claims processing uh system for the Canadian Blue Cross. Um which they I think they still use today and it's been 20 years. Um so that you know that's the kind of uh I think thinking and learning that the high school um really helped me build. >> That's great to hear. Okay. So after entrepreneurship, you stepped into larger leadership roles that led you to Amazon Robotics. So what drew you into robotics and what was what was different about that move? >> Yeah, I I've always been interested in in uh robots and robotics. I think it's the the sci-fi background like watching a lot of um sci-fi movies. Um I would say right around the time when I moved to Boston, I watched a TED talk by um a person named Mick Mounts. Uh Mick had uh founded a company called Kefa Systems and his uh his history went back to uh Web Van which was one of the companies we actually studied about at the high school. Web van became one of the big um failures. Um and so a lot of uh a lot of uh kind of textbook um uh you know case studies were written about uh web van and Mick was one of the early founders of that company or or one of the early people at that company and he founded KA systems to solve that kind of real world fulfillment problem. What was interesting about mix uh TED talk was he focused less on the technology and more on the business uh problem that he was trying to solve. And and so that TED talk is really interesting because it really it's it's showing the robotic system but it's really highlighting what business problem is being solved through these robots and I I found that fascinating and I really wanted to work with this company. So when the opportunity presented itself um there was a role that that um that opened up and and I applied for it um and I've been there uh 10 plus years and it's been a fascinating journey. Um, you know, the robotic space is interesting because in in traditional software companies, you can solve digital problems. Robots can let you help solve physical problems. And at scale, if you just look at the size of our GDP, the the number of opportunities we have in the robotic space is is just, you know, an order of magnitude or or maybe several orders of magnitude higher. Um, and that's that's a very interesting and fascinating space for me. So what you just said makes me think that adoption of robotics has a long way to go that we're kind of in the nent stages of it right now. >> Yeah, absolutely. I would say most people's experiences with robots will probably be around the Roombas, you know, the things that uh those vacuum cleaners, but I would say an average um you know consumer doesn't really have that interface with robots and and robotics. Um I'm surrounded by them, so I see I see them every day. But yeah, we're very much, I think, in kind of that early stages of robotics. I think once they enter the consumer market, we're starting to see some of that with autonomous cars, but I think the the opportunities are just endless. Um, and and I think there's a lot of companies that are kind of looking at how to do this safely. Um, but yeah, I think there's there's so much we can be doing with robotics in the future. It's a very exciting space. >> Okay. So now you're at Amazon and Amazon has warehouses, lots and lots of warehouses. So what does that software actually do dayto-day to run those robots? Tell us about what that looks like. >> So there's there's different uh layers of software. So there's all of the the engineering software that makes the robots work that those are owned by the individual teams that um that build those um those robotic systems. And then my team owns a set of software that's used by the operators. So I I run a team called um robotics operations management or ROM. And my team focuses on kind of three distinct areas. Uh the first one is really around robotics maintenance. So we we build a software for our technicians um to be able to do diagnostics and troubleshooting and really kind of keep these systems um fully operational. Uh we're talking about you know several thousand robots per building and we have hundreds of buildings. Uh so at scale this becomes a pretty complex problem to solve. Um so that that that function is really around kind of integrated with the hardware doing a lot of diagnostics and troubleshooting. The second uh focus within my team is around how do we run our operations shifts uh well so if you think about you know ordering something from Amazon um shortly after you place your order the order gets assigned to a building and a series of things have to happen for that order to show up um at your door you know within a few hours to a couple of days um and so managing that shift uh of you know the individuals who are working within their warehouse. So I have a team that basically um looks at all of the es and flows within the shift, all of the um constraints that can happen and and we really decompose the system and and try to highlight where the the system may be bottlenecked. Um the things that might prevent the package from showing up on time. And then I have a third team that focuses a little bit more on kind of big picture um you know looking at trends over the course of the year um to try to understand where we might have you know opportunities and challenges. Um, so we're we're just always trying to optimize our our existing systems. Um, so that team focuses on um looking at seasonality and trends, looking at inventory levels, looking at um changes in some of the buying patterns um that consumers have and that's that's really a long time horizon um software. So a lot of analytics, a lot of kind of data crunching and um we use a lot of AI to try to predict how the system is going to behave um looking ahead. So, so really different focuses and then there's there's a fourth team in my organization that focuses a lot on, you know, ingesting all the data so that these other teams can can use that data. >> Yeah. So, that's some interesting stuff there. You were talking about an amazing transformation of logistics. >> Yeah. >> Really in a decade or two? I mean, really not that long, right? >> That's right. Are there other industries that are learning from Amazon how to do logistics? I >> I think there's a lot of companies that look at at what we do today. Um it's an interesting um it's an interesting question because I think you have to as any industry have to make some bets early on and and so when Amazon invested in fulfillment um and and kind of looked at where the future was going to go, there was a fair bit of risk that they took on. Um so I think there are disruptors in the industry that are looking at you know AI, automation, robotics uh to completely transform their business. Um and look at the Amazon model. Um then there are other companies that I think are are are maybe not willing to take that risk and they they run the risk I think of becoming obsolete. Uh because the the entire world around us is changing with AI. Um, and I think Amazon, the Amazon model has proven to be successful in terms of making long-term bets and um, and really transforming an industry or or several industries at the same time. So now you mentioned data. Um, I with all these robots in all these different buildings and all the kinds of things you're doing there, I imagine it's a massive amount of data. what kind of data is being generated and what role does it play in operations and in um and in preparing for the future because I imagine you guys aren't static like you're responding and building things all the time. >> That's right. Yeah. So my team's uh we consume very different types of data and and massive amounts of data and we're actually processing a lot of this data in real time. Um so one example of the type of data we collect is from all of our um industrial machines and robots and sensors and cameras um and LAR right so we have tons of of uh very low-level data coming to our system um and we're processing that at scale to really look for anomalies look for patterns that we may not otherwise recognize um so a lot of equipment level data coming in you know talking pabytes of data coming in um that we're computing and processing in real time. And that that uh that's actually a lot harder than it than it even sounds. And it's it sounds hard. Um and and really with AI we are looking at you know how can we leverage um you know some of the large language models and some of the foundation models that exist uh to understand what that data is telling us. And so there's a lot of opportunity there. uh the other kind of data that we look at is around uh flow of inventory and volumes and and really looking at you know bottlenecks within our system. So one level higher from the from the hardware but really the the the bigger system at at play which is processing all of the inbound inventory coming in from suppliers and through our our different systems all the way to packages going out to the you know to the consumers. Um and and so there's a lot of things that have to happen for that to work um you know successfully. Um so my team is getting a lot of that data in real time and and really trying to parse out where we might end up with bottlenecks. And really what we're interested in is identifying bottlenecks in the future, right? So predicting where the bottlenecks might happen um and then drive some action now to kind of mitigate those. So happy path for us is we're always ahead of the curve in time in terms of what the data is telling us in terms of where the problems are going to be and then being able to drive some action up front. Um [clears throat] and and and that's the kind of data we look at is is equipment data as well as inventory and kind of the flow of um inventory inventory through our systems. Yeah, it sounds like a huge kind of mapping problem to get all that data to to be merged together in ways that it's useful. >> Yeah, it's it's it's a mapping problem. It's also the kind of keeping the data in sync because we're getting a lot of uh low-level data from systems that are all kind of working together. And in some cases, we find that some systems are emitting data much faster than others. But really the the what's relevant for us is uh everything tying together, right? So we have to look at some of the slowmoving data that may actually be the cause of a problem, but the fastmoving data is telling us there's a problem. And so we have to synchronize a lot of this data sort of in real time to actually figure out where the problem might be. Um and and that's part of it is we have so much data coming in, but it's um some of the slower moving data is actually telling us a lot more and so we have to map it all together. So when software controls things in the physical world, it seems to me that the stakes are different. >> Yeah. >> So how how does building for real world physical automation changed the way that you think about reliability and risks? >> Yeah. Yeah. The risks uh question I think is really interesting because physical robots the first thing we have to worry about is safety of our of our associates and individuals working with these um these massive systems. Um so we take a very very serious uh position on safety and and making sure these systems are safe which goes all the way back to the design um process. Um so we design for safety and then we implement safety systems that can effectively shut down our robotics if there's any risk to an individual. So that is the that is I would say the paramount um problem we worry about. And then when we get into um a physical world as compared to a software only world um you know software uh systems typically have you know well- definfined inputs uh that don't change you know uh consistently or constantly uh in an unpredictable way whereas physical robots have to operate in an environment that's constantly changing around them. So, we have to have a good understanding of what the physical environment is going to be and and consistently map that um and and be able to observe what's happening in the physical environment. So, if you have autonomous robots that are that are driving around a warehouse, um things within the warehouse are constantly changing. And so, we have to be keenly aware of all of the uh the physical attributes that are non-rootic uh that are changing around us. And that's a really hard problem because it's a it's sort of a geospatial view of a of the world that we're mapping in in real time and making decisions on on how the robot should then respond to that physical environment. And I would say the third area where the physical um systems are very different and challenging is with software issues. You can typically fix them with a software, you know, fix a patch or a bug bug report. Um and and so there's lower cost to fixing software systems, but if we miss something in our design process um and we scale our robotic technologies, that cost of fixing that issue is significant down the road. So we have to be very very thoughtful about um our design and and what some of the decisions we're making. So in some cases we have to think about making decisions um that may pan out differently. So we have to be thinking about like what are all the different possible outcomes we could find ourselves in in the future and then build for that future use case. And so that makes it a little bit more challenging with physical systems than just you know software and digital systems. >> All right. I'm going to change tech now. I want to talk about your early career for a minute because I know you started at Carrier and then you moved to a startup and I'm wondering >> what what pulled you in that direction and what did that shift teach you early in your career? >> Yeah. Yeah. The the you know when I graduated from the school of engineering it was right around the year 2000 that right after the dotcom bubble had burst and the job market was challenging. I would say maybe a lot like what it is today. Um and and so Carrier was a good option for me. It it uh let me kind of stay in Syracuse and go to high school but also work in a in a role that um gave me a lot of opportunities to learn and and build my own technical skill set. So at the time at Carrier I was I was one of very few engineers building uh web applications. The rest of the company was working on very legacy systems. So it let me kind of uh build the level of technical depth I needed to be successful in the future. But I always wanted to be part of a startup environment. I wanted to be close to the business that my company was solving or whatever company I was going to be part of. And and [clears throat] in the carrier role, I was pretty far removed from the business. I didn't know who was buying our products and how those products were being built. I was just serving a internal customer. Um, so when the opportunity presented itself to move to a startup in the Boston area, I wanted to join a company that the where where their product excited me and where I understood what the customer that they were serving was trying to accomplish. Um, and the company I joined was about a 99 to 100 person startup. Um, and uh, they had a fairly robust set of customers. Um, the startup environment taught me that I had to effectively work with every part of the business. Um, I was in the professional services group. So, we were implementing our software. I had to work with the software engineering team. I had to work with tech support. I got very involved with sales and marketing. In some cases, I had to work with legal and finance. Um, so everyone from the CEO and CFO down. Um, I direct line of interface with these folks. And so I got to see all of the, you know, sort of the good, bad, and ugly of that business as opposed to just being very kind of uh um, you know, siloed in one area of the business. And it also made me keenly aware of the financial um financial risks with startups. You know, the some of these companies, they have to move uh aggressively every quarter to survive. Uh and that was that was a realization um early on that that this company may not be here in you know in six months or a year from now if you don't if you don't uh consistently sell the product and keep growing our customer base. Um and then that was it was a lot of fun but it was stressful at times as well. >> So you co-ounded a company Absolute Commerce. >> Yeah. Um, so I know that you guys run out of run out of seed capital. >> What did that experience teach you about building a company that you couldn't have learned any other way? >> Yeah, that was an interesting experience. It was a the the co-founder was my former boss at at the startup that I had joined at uh when I moved to Boston. And so right after we folded up our company, um we each did a bit of a retrospective and we gave each other a book to read. And I actually don't remember the book I gave him, but he gave me a book called the four steps to epiphany. And uh it was a fascinating read and it really captured why our company failed. Um and and you know we did a lot of introspection in terms of like hindsight being 2020 would we have done anything differently? And I think we arrived at the answer that probably not. Um so the way the the startup journey went um we we had a lot of existing customers at a former company that were telling us about this business need that they had and so the signal we were getting was you know high demand for our product but the the market was not uh providing that service and so that's really why we we created this company um that we did and it turned out that the the procurement and uh the finance teams the accounting teams within most of our target customer base really needed the product we built. But when we went up to the the higher level leadership within these organizations to sell the product to sign contracts, that's when we started to see a lot of push back. So at the CFO and and uh CIO level, uh our product wasn't their highest priority. They understood the problem we were solving. They understood that their teams needed that product. But when they gave us their top 10 list of challenges, we would have been, you know, number 25. And so that was an interesting realization that while we thought we had understood um the market that we were going after, we hadn't actually understood the the financial, you know, aspects of of that. And so in the book uh you know, the book talked about not just building uh a product, but also building a customer. And I think we missed that part. We we built a strong product. Uh we actually implemented our product at a couple of banks um with the understanding that once we cleared that hurdle right we could tell other customers that banks are comfortable using our software uh so you know it it meets a higher level of um uh sort of security classification if you will but um we didn't understand that the the financial implications of like what it would cost uh for any organization to invest in our software wasn't going to clear the hurdle. at the more kind of executive leadership. It was a painful lesson to learn but it was it was a great uh great experience good good journey and and really if I were to do it again um I would I would look at understanding you know how how critical is that product at the more senior leadership level and that's the thing we missed. >> So now you have about 50 engineers working on multiple teams. >> Yeah. And I think the last time we talked we were talking about success. So tell me how does your def how has your definition of success changed as you've moved from writing code and some of the early days to now where you're leading teams? >> Yeah. Yeah. It's this is a conversation I have often with folks uh within my organization who are looking to take on more of a leadership role. So, uh, one of the things that I think as an individual contributor is always appealing when you think about professional growth is is becoming a a manager and a leader. Um, I think that as an individual contributor, success is a a lot better defined, right? The path to success is typically um well articulated by your manager within your team. Um and so you just have to execute on that on that um uh well- definfined success criteria and and you can achieve that typically within you know 6 months to a year. So most individual contributors are solving problems within the the bounds of that you know that time frame within 6 months to a year but aren't thinking about what the organization is going to look like in the 3 to 5 year time frame. And I think the biggest thing that I had to learn um moving more into a leadership role was you know individual contributors uh get a lot lot of the accolades when things work successfully. Um but as a as a leader you know you take the you take the um the losses if you will. If something doesn't work you know that's on me but if something is a huge success that my team delivered on that that credit needs to go to the team and then they need to celebrate it. Um, so there's a few things that I think I've I've learned over the years um, moving from an individual contributor to um, to more of an engineering leader and it's all about building resilient organizations that have a tremendous sense of ownership and um, autonomy. So I see my role as painting the broad vision of where we want to go. Um, and then sort of getting out of the way, right? So inspire the people, give them the vision, um kind of block and tackle, you know, at a higher level so that they have the space to innovate. Um but then let them make the few mistakes along the way. And so my teams typically will take on a lot of risk and and don't always have to check in with me. Um that's that's the way we have architected the organization. Um, so they can make decisions, they can take some risks, they understand what failure looks like, but they have a tremendous sense of ownership of of what the what the problem is that they're trying to solve. The other thing we try to do within my organization is really biased towards simplicity. There's always a risk in engineering applications of overthinking the problem and building something more complex than it needs to be, sort of overengineering um, a solution. And so one of the tenets within my organization is to start with the simplest possible solution and and then evolve it into something that may become more complex because our need has changed um but biased towards that simplicity. So um and I think that that has given me a tremendous amount of job satisfaction when I see uh folks at my team that understand what needs to be done because the vision is clear, understand that they can take a lot of risk. They can be inventive. Um you know they can uh they can fail a little bit. They can afford to take some risks that may not pan out. Um and and really build that mindset of strong judgment. Um and and that's that's incredibly gratifying and when things work really well, you know, they get to celebrate it. When things don't work well, that's when uh then I have to go and answer for it. >> Yeah. You know, as you were talking, I was reminded of a phrase I learned when I was a manager at a company called Autodesk. Um, a phrase that they pushed around a lot was fail fast forward, which basically means take risks, don't be too afraid to make mistakes, and as soon as you find you've made a mistake, get back up and keep moving. And I kind of appreciated that as a as a perspective that takes the sting out of failure. >> Yeah, we have a concept at Amazon called two-way doors versus one-way door decisions. and and it's really helped us as an organization um instill this risk-taking mindset and and really it comes down to um we think of most decisions as either one-way door decisions or two-way door decisions. A two-way door decision is something you can kind of undo, right? You can walk it back and we think that most decisions are that right most decision decisions that you know uh teams have to make or engineers have to make can be undone. there may be some cost to it or some implications. Um but it's easier then to think about two-way door decisions as potentially worth taking um because you understand the risk. At the same time, when we understand that something is a one-way door decision, there's no locking it back. We we are a lot more thoughtful about it. And it's not that we don't take some of those one-way door decisions. we just have a lot more honest discussion, evaluate the risk more holistically, um, and in some cases decide that it's not worth the risk because undoing it is is impossible. But in most cases, we we put in a lot of mitigations into those one-way door decisions. So I think that kind of a mental model that the organization has come up with really fosters that culture of decision-m and moving fast um in most cases with with a few exceptions um that we that we have to think about. >> Yeah. Cool. I'm going to change ts again. So Amazon of course is one of the companies that has invested heavily in AI and when I talk to people in business you know there's a wide range of adoption. I mean there's certainly companies that are going to be really really slow to adopt and have employees that are resistant to even trying to use AI. And I just imagine in my mind that Amazon is probably one of the companies that's a little quicker at adopting. So what kind of strategies are you guys using to help adoption? Um and where you opt not to adopt, what does that look like? Yeah, Amazon I think has a very very um I would say aggressive mindset towards AI in that we're looking at it in all aspects of what we do today. Um and so we have obviously invested in in companies like anthropic and open AI. So we have very strong relationships with uh with AI companies and and I would say we are a leader in in AI as well. And so really from the leadership um lens uh the message has been um lean into the AI space and find the right balance for your team and for your organization. Um there's a lot of uh initiatives on you know that that spun up maybe a year and a half ago in terms of teaching and training um every role within Amazon in in terms of how to leverage AI whether it was writing code or writing documentation um or problem solving kind of from more from a business lens analyzing data um really every aspect of of um Amazon and really everyone I work with is heavily leverage leveraging AI to do a lot of what they did before just you know um just manually um at the same time we have to be thoughtful about you know who's ultimately responsible when AI makes a decision and so for within my team when we think about writing code the message is ultimately the engineer that's submitting u the the code reviews or or you know owns the workstream is still responsible for um for the code right so we have to have that that that culture of responsibility. We don't want to be in a situation where there's a lot of sloppy code being published because it's fast and easy uh because those things become technical debt in the long term. And maybe that's an area where we're spending a lot of time thinking about what are the right mechanisms or kind of philosophical um uh tenants we can put in place so that you know we don't end up with a lot of uh AI generated slop right so we have to be very very thoughtful about that. Um but for the most part I think AI is uh it's a tremendous um disruptor in the industry and I think companies like Amazon's recognized that early on. Um and so we have we have a lot of our internal systems that that are evolving and morphing to to leverage AI. Um, and I would say what a lot of what I do today looks very different than I did than it did 6 months ago or a year ago because every application, every system um is heavily integrated with the with AI. Um, but we also recognize that it's it's an evolving system and it's not perfect. Um, and in the cases where it doesn't do things well, we still, you know, rely heavily on our judgment and our um and and the teams that that are ultimately responsible for delivering those systems. Yeah, interesting stuff. Okay, so if you were a Syracuse student today and you were interested in robotics, technical leadership, what what would you tell our students to be working on and building now in terms of their skills and perspectives? >> Yeah. Yeah. I uh I think there's a few things that I would really encourage everyone to to think about. Um I think one is um having a a strong kind of technical depth in in an area of interest to you, right? So, and and this maybe goes even um as far as back as when I graduated. uh the I think the market is always going to value technical depth and kind of technical problem solving and and that engineering mindset of decomposing complex technical problems and and really having a good understanding of what you enjoy doing and and what are the technical um you know what is the technical depth you need to have in those on those areas is uh I think that's that's universally going to be true in the industry. Um I think the other one is maybe related to the first one is building a really strong problem solving um skill set and framework. Um I think throughout my career the things that benefited me were where I was able to challenge based assumptions and um and kind of go to the root of the problem we were trying to solve. I found that oftent times when we were presented with a project or an opportunity or or a challenge, there were some baseline assumptions that we were working off of, but we hadn't challenged those baseline assumptions and and having that kind of framework for problem solving. Sometimes you actually have to look at what it is that you're solving for, right? And and question it and make sure that you're actually uh you have a good understanding of what problem you're trying to solve. And I think uh as as students graduating today especially with the role of AI um that human judgment becomes even more important and and building a framework for problem solving um from a from a human lens I think will be uh will be really valued in the market and I think the third and maybe the most important thing is uh continue to grow and learn. So um like I today will still have my own kind of side projects with Raspberry Pies and ESP32s and I still try to stay very technical and learn where the where the industry is going and what all the technical um developments happening in the field. Um and and you know with things like AI, I I spent a lot of time on research papers and finding where um the future is heading, right? Like where is the industry going? What are the new developments that could be disruptive? Um so as you as you graduate I think you have to have that hunger for you know continuous learning and build that framework so that you know independently of the the work you do at at whatever company you join you have a separate thread which is how do I learn what's happening in the industry outside of the company that I work with and and I've seen this happen where folks who work at certain companies get get very kind of um embedded with the problems of their companies are solving um and not really paying attention to what's happening outside. And that's that's a pretty big risk. So, if you have that um learning mindset, you're you're going to pay attention to everything that's outside of your industry or outside of the company that you're working in. And and and that just prevents you from, you know, becoming obsolete and and those folks will then see the the trends, right? whether it's um you know e-commerce 20 years ago or kind of the push towards mobile maybe 10 to 15 years ago or or AI now you'll see those waves coming and and and be able to adapt um to those >> yeah I you know talking to our alumni I think one of the things that a lot of alumni tell me is that they left the high school with the mind set around being adaptable to technology and I think that's a big key for success in our fast changing world today. >> Yeah, >> Tyler, thank you very much for your time. Um, I Infoiversity here at Syracuse, we really appreciate you taking the time to talk to us. >> It's been my pleasure. Thanks for taking the time as well. >> All right, have a great day. >> You as well. Thanks. Bye.