AWS re:Invent 2025 - A leader's guide to advanced mental models and mechanisms (SNR303)

🦄 Making great presentations more accessible.
This project aims to enhances multilingual accessibility and discoverability while maintaining the integrity of original content. Detailed transcriptions and keyframes preserve the nuances and technical insights that make each session compelling.

Overview

📖 AWS re:Invent 2025 - A leader's guide to advanced mental models and mechanisms (SNR303)

In this video, Stephen Brozovich, AWS Executive in Residence and 26-year Amazon veteran, explains how Amazon maintains its culture through clearly articulated mental models, intentional behaviors, and organizational artifacts. He introduces Amazon's 16 Leadership Principles, particularly Customer Obsession and Ownership, demonstrating how they drive decision-making across the organization. Brozovich presents the "working backwards" process, where teams write press releases before building products to ensure customer focus. He warns that mental models erode over time as artifacts persist but their original intent fades, causing employees to become "amateur archaeologists" misinterpreting processes. The solution is embedding mental models into mechanisms—closed-loop feedback systems like the customer service andon cord that reinforce cultural values in daily operations. He emphasizes that shared mental models enable autonomous teams to move quickly within guardrails without constant management approval, a principle now applicable to managing agentic AI systems.

; This article is entirely auto-generated while preserving the original presentation content as much as possible. Please note that there may be typos or inaccuracies.

Main Part

From VHS Tapes to Cloud Leadership: A 26-Year Journey Through Amazon's Transformation

My name is Stephen Brozovich. I'm part of the Executives in Residence team at AWS. All of my colleagues are former C-level executives who led massive transformations to the cloud. I'm the only one on the team that's not the case. I've just been around Amazon for a really long time. I started my journey at Amazon in August of 1999. The world looked quite a bit different back then, and Amazon looked quite a bit different back then as well.

When I joined Amazon, we had already expanded from the US into the UK and Germany. We had four product categories on our retail website. We started, as most people know, selling books. We had expanded into music. Our third product category, an entire line of business for us with good revenue, was VHS. I'm getting old enough that I'm going to have to start explaining magnetic tape and plastic cartridges, and you had to rewind it before you could watch the movie. There has been so much change over the years.

I started out on the technology side of the business, and as part of our platform team, I got to see us move through giant shifts in technology and in ways of getting work done. Everything moved from monolithic architectures to microservices, from waterfall to agile, from centralized resources to distributed autonomous teams, from technology as an IT cost center to technology as a business driver. Along that journey, as fascinating as technology was and is for me, I really became intrigued by the human part of that equation.

Every time you inject a new capability or new technology into an existing organization, it requires a shift on the part of the people in that organization to be able to absorb it and take advantage of it. About thirteen years ago, I took a step out of tech to the dark side. I joined HR. I don't mean to alienate a lot of people in the room. But here was the question we had in our minds. Amazon at that point in time had experienced a lot of success, and we understood very deeply that one of the primary reasons for that success was our culture.

There was a growing concern within the organization that as we were growing and moving into new spaces and adding new people into the company, we might be losing touch with what mattered to us and what had actually led to our success as an organization. For a period of time, I sat in the role of running the Amazon Culture program. We asked ourselves how to think about culture across the breadth of Amazon's organization. Then I narrowed my focus to look at executive development because you as leaders have an outsized impact on the culture of your organization.

The more we can help equip leaders with the right sets of mental models, which we'll talk about today, and mechanisms for them to lead effectively, the better off we will be. The more likely it is that when we wake up and look at our company three years from now, we're still going to recognize it. It's still going to feel very much like us, regardless of whatever technological shifts have happened around us. I then got even further into the HR space and focused on talent management.

For some reason, somebody who was a music major in college ended up running talent management for AWS when we grew from thirty thousand to over ninety thousand employees during that period of time. That was massive, rapid change, and the core fear that we had during all of that growth was how do we make sure that we hang on to this culture that we care about. I know from having spoken with thousands of leaders over the last five years in my current role that that's a very real sentiment for a lot of you sitting in the room today.

You might have joined the company just recently or maybe you've been part of your organization for ten or fifteen years, and you're seeing things change. Some things you're excited about, and other things you're thinking, wow, it just feels like the ship is getting away from us. How do we then unpack what are some of the approaches that Amazon has taken that could be beneficial and helpful for you and your organization in your journey? As this new technology, things like Agentic AI, come in and massively disrupt the way that we do work, we hang on to some of the very reasons why we joined our organizations in the first place.

Defining Culture: Mental Models, Behaviors, and Artifacts

I just gave you a little bit of my background, right? Music major and all this kind of stuff. You'll notice there's no sociologist in any of that. And yet here we're going to talk about culture. What's really interesting to me is that when you start to dig into the topic of culture, you'll find that even sociologists actually disagree among themselves about how to define what culture actually is. It's such a huge term and encompasses so much.

I'm going to use a pretty simple definition I found really helpful for what comprises culture. First, our mental models. These are the ways that you and I make sense of the world around us. This is all the pattern matching that happens in our head. We see something, and there's some sort of an explanation that happens in our brain about why that thing happened. Some of those are learned because we've spent time in business, and we see people behaving in certain ways.

We make assumptions about those behaviors based on our mental models. Some of those might be beliefs or value systems, and sometimes we're not even conscious of these. But based on our mental models, we take actions. Those are the behaviors that are the evidence of the culture, and finally, we leave behind artifacts. These are those things that are visible representations of the fact that there was a human around doing something and left something behind. These three components together make up culture.

Let me give you a concrete example of my experience with mental models. I live in the Seattle area and have lived there for a very long time. There's an old story about when President Obama was visiting Seattle. He was in his hotel late at night looking down at the street, observing what was happening with the pedestrians. There were no cars on the road, but in Seattle, this is typically the behavior you see. The light is red, I walk up to the corner and I wait. No cars. But I'm going to wait for that light to change before I take the next step and start to cross the street.

I didn't think a whole lot about how internalized that mental model was for me until I was in São Paulo. I stopped, and I pretty much got run over by every pedestrian who was looking at me like, "You idiot, there's no cars coming, what are you doing standing here?" This is a perfect example of two legitimate mental models. One is the rule follower, proper mental model, and the other is the pragmatic mental model. Which one's right, I'm not going to say. But what I see there is the evidence of this clash between mental models that shows up in very different behaviors.

The Antikythera Mechanism: Lessons from Archaeological Artifacts

What I want to focus on first, for the sake of the conversation today, is actually the last element of culture—the evidence that's left behind once a human has done something. So we're going to talk about artifacts here for a bit. Now, how many of you in the room recognize this artifact? I've got a couple. Okay, that's how many people actually watched the last Indiana Jones movie because this was the central theme of the movie, so you can see it didn't really do well in theaters. This is something known as the Antikythera mechanism.

It was discovered on the floor of the Mediterranean Sea. Sponge divers around 1901 and 1902 were diving and harvesting sponge from the sea floor, and they came across a shipwreck. They found all the things you would expect to find inside your average shipwreck. They found amphora, giant clay pots, they found statues, they found a bunch of other things, and amongst all of that detritus. They found this thing, this weirdly shaped lump of bronze. No idea what it is, but clearly it didn't grow there. So what do they do? They call the scientists over and the scientists get these specimens, they collect them.

It sat on the shelf in a museum for over fifty years with nobody knowing what it was or what to do with it. In fact, it wasn't until the nineteen nineties, so almost a whole century later, that scientists started using medical imaging technology to look inside ancient artifacts. When they applied that technology to this device, they were astonished at what they discovered. This device was comprised of more than thirty-three precision cut gears. There are actually inscriptions on some of the gears that they can actually read and interpret.

They believe that this device was housed inside of a wooden box. On one side, you could position dials to indicate the current date. Flip the calendar, flip that box over, and on the face are a visible representation of the sun, the moon, and the four visible planets. There's a knob on the side. This device can accurately predict solar and lunar eclipses. It has been carbon dated to somewhere around two hundred BCE. There is nothing this sophisticated in the historical record for another fifteen hundred years.

At this point you're starting to wonder, did I join a lecture on archaeology or what? Bear with me for just a second, I think this is going to play out. Now, as humans, we've developed a discipline. When we find something that we don't understand, that's the discipline of archaeology. Again, told you my backstory, not as an archaeologist, so this is my interpretation of archaeology. I find a thing, I go, what is this? We have a pretty good idea of what it is because actually scientists have reconstructed this device in three dimensions. They've actually recreated the machine and it can accurately predict those solar or lunar eclipses.

The next question we tend to ask when we find this weird thing is, well, how did it get here? And at this point, there are actually a lot of hypotheses. Now one very good hypothesis is that this is of Greek origin. It was after all in the Mediterranean Ocean by Antikythera, which is a Greek island. And those gear ratios, Greeks were very amazing mathematicians. They invented whole areas of mathematics.

However, there are some unusual aspects to consider. The calendaring system used on the back of the device has much more similarity with the Babylonian calendaring system, which has led some scholars to theorize that this artifact is actually more ancient than Greece and of Babylonian origin. Those astrological symbols are really important, and astrology was a major part of Babylonian civilization. I will say there is a school of thought that suggests this is evidence of extraterrestrial interference in the Earth timeline. Now, I'm going to let you decide which one of those is most plausible, but the bottom line is none of us were there when it was made, so we don't definitively know which of these hypotheses is correct.

The third question we tend to ask is why was it made? This is part of how we try to understand ourselves as a species. We look at these things in the past and ask what were they thinking about? What was the motivation behind this thing? Why would they do this? I can come up with a bunch of hypotheses. Is this a way of someone showing off their wealth? All the other wreckage in that shipwreck was evidence of someone who was very wealthy, so it was either someone wealthy shipping their goods from one place to another, or maybe it was the spoils of war moving from one place to another and it sank to the bottom of the ocean.

Other people would say those astrological symbols have much more to do with fortune telling. Or perhaps this was an early form of celestial navigation. How would I use this if I'm plying the trades on the Mediterranean Ocean? It would be useful to know when there's going to be an eclipse, right? Those things are probably really helpful. Although I would say if it's either of those two latter things, it didn't do its job very well because it ended up at the bottom of the ocean. So again, three theories. We weren't there. Which one was it?

Notice how these three questions map back onto these mental models. The behaviors and artifacts. In fact, it happened the other way around, right? Somebody had an idea, based on that idea they built something, and as a result of building something, here we have this artifact that's left. Our belief and our understanding, our experiences—when we shape and create the right set of mental models, those mental models that we embody, that we communicate, that we live out, impact the culture not just globally but of our own organizations. Stop for a minute and think about the mental models that maybe drive your organization. What are those behavior patterns? Maybe you've had experience in multiple organizations and you've experienced the culture clash that shows up when you walk into the room and start talking.

Amazon's Leadership Principles: Ownership as a Foundational Mental Model

Amazon has some really interesting cultural elements. You might have heard of this one: we like to start most of our meetings in silence. You can be in the room for five, ten, maybe even twenty minutes and nobody's talking. It's super weird and really uncomfortable if you're late to the meeting. What's happening during that time is we're all reading this really carefully prepared document so everybody understands it. But the new folks don't, so they walk in and start saying things like, "Hey, how's your weekend?" and everybody's like, "What are you doing?" So there's this culture clash happening because what we do as an organization is different than others.

Let's dig in, in particular, and start with mental models. Amazon has some pretty clearly articulated mental models. Our most foundational mental model is this one: our goal is to become Earth's most customer-centric company. It's a cute tagline and pretty catchy, but now think about the power of that statement. Because I'm being asked on a regular basis to challenge the work that's in front of me and ask, "Yes, but how is this going to make life better for the customer?" And if I don't have a good answer for that, then we shouldn't do this thing. It grounds every activity that we take. Every conversation that we have is rooted in this mission.

We have found tremendous power in articulating these mental models, and in fact, there's no better way to understand Amazon's culture than to dive into our leadership principles. We have sixteen leadership principles. I know we are not unique. A lot of your companies have corporate values or principles, so I'm not pretending that these are the right ones. These just happen to be Amazon's. But I want to talk to you about how they actually impact what we do on a regular basis. Let's look at a couple of them. To start out first, I'm going to talk about ownership. Leaders are owners. They think long-term and don't sacrifice long-term value for short-term results. They act on behalf of the entire company beyond just their own team. They never say that's not my job. Okay, great, proceed. Hang on, stop. First statement: leaders are owners at Amazon. Regardless of your level or role, we see that individual as a leader. It is everyone's job to

have this mindset toward the work that they do. Wherever I am, if I'm packing a truck or building a satellite, I need to be looking at the work in front of me and ask, what's the long-term impact of this decision that I'm about to make?

There's all kinds of pressure and there's some unusual things about Amazon. We've been a publicly traded company since 1997. I have yet in my 26 years to be in any conversation that has anything to do with the close of the quarter. We don't make decisions based on quarter close. Clearly our finance teams do because they tie up the books and we make sure that's all good, but none of our business decisions have anything to do with business cycle and the close and when Wall Street is going to find this out because our perspective is long term.

The next principle is that they act on behalf of the entire company beyond just their own team. Now we're starting to interfere with human nature. Humans by nature tend to be very territorial. Sometimes it's unusual, even within their own company. Someone might say, I don't trust that guy's software. He works two doors down from you. No, I'd rather write my own. But we say, hang on a second. Don't make a decision that sub-optimizes for your unit. Think about the broader impact for the whole organization.

The last principle flies in the face of a lot of people's experiences. They never say that's not my job. Because that's a very human thing to do. If there's a mistake that happens and I wasn't involved in it, I'd go like this: that wasn't me. But here's the thing, customers don't care whose fault it was. They care that there was a problem that didn't get looked at or didn't get taken care of.

That doesn't mean I have to solve everything, but if I see a problem that's not being taken care of as an owner, I'm going to stand over it and I'm going to say, hey folks, we got a problem right here. I don't know how to fix it, but we got a problem right here because I'm an owner and I care. Now think about multiplying that mindset across the entire organization. These mental models have tremendous power. They drive intended behavior. So we spend a lot of time crafting these mental models, and we're going to talk about the mechanisms that we use to help them sink deep into the culture of the organization.

Customer Obsession in Action: From Mental Model to Hand-Delivered Packages

I'm going to share another mental model with you. Here's our very first leadership principle. I know I'm mentioning it second. Customer obsession. Leaders start with the customer and work backwards. They work vigorously to earn and keep customer trust. Although leaders pay attention to competitors, they obsess over customers.

Anytime I have this dialogue with someone at Amazon, I always say read below the line. Don't just stop at the headline. Don't decide what you think customer obsession means. We've been very clear with everyone in the organization by clearly articulating this mental model. First, don't start with solutions. Don't walk into the room going, I got this amazing technology for you, you're going to love it. Start with, what's going on? Tell me more about this problem you're encountering.

Our experience has been when we are truly listening to what those customers' needs are, there is the hot tech item that I'd love to have somebody start using because it's amazing and I think it's really cool, but it might be the wrong tool for what that customer actually needs. And then what have I done? I haven't actually been thinking on a customer obsessed basis over the long term because you're going to get this thing and you're going to go, I bought it. What good is it doing to me now? So everything has to start with the customer, backwards from there.

They work vigorously to earn and keep customer trust. You all know trust. It's hard to earn and easy to break. And so every employee in the company has to think about the impact. If I make this decision, what's going to be the impact on trust with the customer if I do this?

The last sentence is: although leaders pay attention to competitors, they obsess over customers. Of course we should pay attention to what the competition's doing, because there's a whole lot of smart people that don't work at Amazon. It would be foolish to ignore them. At the same time, the source of our energy can never be what the competitor is doing because they themselves are always going to be two steps behind customers' true needs. So again, mental model, clearly articulated, but it impacts behavior in some really interesting ways.

We have software teams all over the world and we organize using what you've probably heard called the two pizza team model. Basically a specific team will have ownership of a specific area of functionality in the company. They own that process end to end. It's build, run, deploy. They are iterating on this constantly and they want to be in touch with their users.

We have one of our fulfillment software teams that's based out of Hyderabad in India. One holiday season, they had flown from Hyderabad to Hebron, Kentucky, which was at the time one of our largest fulfillment center operations, and they were there because their software systems are the ones that are actually helping conveyance work. They own a part of the process, and so they wanted to see how their software actually being used in real life. By the way, if you don't do that practice now, you absolutely should. Go spend time with the users of your software.

Watch how frustrating your tools actually are and recognize that these are smart people dealing with an interface that's not so great. We've made this a regular practice: ensuring our engineers sit with the people who are using the tools. We will learn so much from those interactions. They're out here during the holiday season, and the last truck has left the building for the day. It's also the last truck that can possibly deliver anything by Christmas. They find a package that somehow fell out of the process, fell off the conveyance, and ended up on the floor. They look up the system and see the delivery promise was December 24th. They realize somebody's not going to get their package. This is a big deal.

So they stayed up really late that night trying to investigate all kinds of possibilities. Can we drive it to a different fulfillment center operation? They even looked at whether we could charter a jet. They could get it there, but they ruled that out because of frugality, which is another one of our leadership principles. Chartering a jet was probably not the most frugal thing they could do. But then they remembered their flight back to Hyderabad was happening the day before Christmas, and it had a layover in JFK. It turns out that Mystic Court, Connecticut is a 100-mile drive from there. So what did they do? They landed in JFK, rented a car, drove 100 miles up to Connecticut, knocked on the customer's door, hand-delivered the package, got back in the car, made it back to the airport, caught their flight, and went home. That's customer obsession.

Think about it this way. Here's why this is such a great story for me. Who knows how disappointed that customer would have been by not getting Call of Duty Black Ops in time for Christmas? What kinds of decisions would that individual be making ten years later? They might be in this room right now thinking, AWS failed to deliver on their promise, even though AWS is different. Trust is really hard to earn and easy to break. The impact of those mental models drives behavior in the organization, so we want to make sure we are spending time talking about, sharing, and reinforcing those mental models.

The Erosion Problem: Why Mental Models Fade Over Time and Distance

What we found is that mental models erode over time. Imagine you're in a situation working on a hard problem as a team, maybe as a leadership team. You've come up with an idea, figured out the right process to solve the particular challenge, built the tool, and launched it. At the beginning, the closer we are to the origination of the idea, the artifact, the tool, the more clarity everybody has on why it's being made, what that mental model is, what behavior or action we're trying to accomplish, and what the artifact itself is.

But here's the weird thing that happens. The further away I get in time, in geography, in organizational depth, the artifact persists. But the behavior or the mental model that led to the creation of the artifact becomes less and less clear. Then human nature takes over. When we in the organization encounter an artifact, we turn into amateur archaeologists. It's just what we do to make sense of the world around us. But the challenge is that I'm interpreting that artifact based on my mental models, based on what makes sense to me.

So we see some patterns. Do any of these look familiar to you? The first pattern is rejection. Well, that's a stupid way to do that. I know a better way to do this. I'm going to grab it from whatever my company was. Then someone new comes in and they don't like your process. They want to use their process because it worked for them. That's one action, not a great action necessarily. The third one is not great either. We just say, okay, I have no idea why I'm supposed to fill out Form 27B, so I'm filling out Form 27B. The problem is that when I fill out Form 27B because I don't know the why, what I provide is actually not very good.

In fact, leadership can't make a decision because the data they're getting back is junk and garbage, even though they're asking for the same thing that was effective for them three weeks ago, two years ago, or five years ago. When we don't spend time reinforcing the mental models, what we are left with are the organizational artifacts. That is why I believe company cultures erode over time. We're going to interpret those artifacts based on our own understanding, maybe not even in line with the leaders who created the process in the first place. The truth is that all of our organizations produce artifacts.

Some of them are more permanent than others. If you have a campus and you built a campus, it's kind of obvious that you were there and you built the campus. Some of them are much more ephemeral, like this session right now is producing artifacts. Every one of you that's taking a picture is creating an artifact of this particular session, so those things are potentially more ephemeral.

As we think about this, it means that every new person coming into the company is going to be encountering that artifact. The question is whether they are walking away with a clear understanding of what that is and why.

Working Backwards: The Press Release Process as Cultural Artifact

Amazon is not immune from this pattern. Some of you have exposure to our process of working backwards. For those of you that have not seen this before, I'm going to walk through it really quickly. This is one of Amazon's classic artifacts. Before I've written a line of code, before I've assigned a team to go investigate or try out a new thing, we start by writing a press release as if the product is already live and being used by the customer. This is a forward-looking document. I'm imagining a world, maybe one to two years in the future, or maybe sooner than that, where we have now solved that particular customer's problem.

The first paragraph addresses who the customer is. Actually, that tends to be a really hard question to ask because we often get really excited about the technology. Then we get to who's the customer, and we're like, who would care? But it's so cool, it does this. Who's life will be changed in some small way because this thing exists, and would they care enough about it? So the first paragraph answers who's the customer and what's the nature of the problem or opportunity.

In the next couple of paragraphs, we're going to talk about what the product does that makes life better for the customer, not how. Technology is irrelevant at this stage. What we're looking for is the behavioral change that's possible for the customer because the solution now exists. The third and fourth paragraphs, and the rest of that page, might talk about how this product fits in with the other products that we offer to the customer, or how it makes sense within the context of Amazon's larger business space.

I get a single page, one side, and yes, we have rules on font size and margin. If your idea is not crisp and compelling enough about the transformation of that customer's experience to be able to capture it in one page, you haven't thought about it deeply yet. So we create this vision through the press release, and then what we do is we start to collect questions. As I work on this idea, I'm going to start asking what kinds of questions would the customer ask and what kinds of questions would my internal stakeholders ask about the issue.

By the way, if there's that really uncomfortable question you hope no one asks you about your big idea, you stick it front and center in the FAQ. I may not have an answer to that question yet, but we know it's an important question that we're going to have to address before we move forward. So the press release captures that vision, and the FAQ pressure tests it. And then depending on the nature of the idea, we may or may not have some sort of a visual representation of the user experience.

If what I'm talking about is APIs, I may have API stubs here, rather than some kind of a visual UI. I don't want to spend a lot of time making that thing shiny because I'm not trying to sell the idea. I'm trying to produce the artifacts so that somebody reading these three pieces of information can come to their own conclusion about whether or not this is something that's going to matter to customers.

Every product we've ever launched in AWS started out as a press release. AWS as a business started out as a press release that went through 47 iterations before we signed the first team to go start building anything. It turns out this is a fantastic low-cost way for us to test ideas because you can get seven iterations in and go, what customer would care about that? Scrap it. Far easier to walk away from a bad idea that's still on paper versus one that we've already started to invest in.

We can have a long conversation about this process. This is one process and artifact that you can grab pretty much any Amazonian and ask them what's been your experience with this press release process? It's a process we've been using now for over a decade with customers and partners to say what's the press release you want to write, not about how you're doing business with AWS but about some key customer challenge that you would love to go solve. We find that when we start with the press release, we start with that clear understanding of who the customer is, and what we end up producing actually tends to be the right thing for them to focus on.

When Artifacts Lose Meaning: A Director Who Never Wrote a Press Release

It's not bulletproof. I actually spent some time yesterday at an executive summit where I talked about some of our notable failures in AWS because we've had them too. But it's a very good process that we've been following for a very long time. So you can imagine my surprise when, as part of our executive development team, I'm at an off-site. We have our teams, and by the way, these are folks that are director level and above, so this is very high level in the company. The requirement is that they have been hand-selected by Jeff Bezos and his direct reports to attend these sessions. This is really important, high-caliber talent that we are investing in heavily. We have this off-site, and in that off-site, we had them examining the health of mechanisms within their own organizations. We said, we'd love for you to examine the use of working backwards in your own organization.

After we do a little bit of teaching, we'll talk about mechanisms here in a moment, and I have a specific concept for that word. We'll share that with you in a second. Basically, we have these small groups that have broken up and they're having a little bit of dialogue. I'm being that good facilitator. I did some teaching and now I'm going to drift and listen into these conversations. If anybody has questions, I deal with the questions. I come over to another conversation, and there's a gentleman who's talking about the working backwards process in his work. He's been here for three years, and he's proud of the fact that he's never written a single press release.

I have to pick my jaw up off the floor and then be a good facilitator and lean in and say, tell me more. He starts to share, look. Here's how I've perceived this. Here's how this thing shows up. This just feels like bureaucracy. You guys are getting in my way. I have a great idea. By the way, I've got a great relationship with my VP and if I go in and tell her I need resources, she just gives me the resources because she trusts me. I don't have to do this stuff. That was his actual lived experience. This was a real test case of someone who had entered a part of the organization that was not leveraging those press releases for what they were intended. His answers are logical based on his experience, but notice how far his mental models are from where the intent was when this process was created.

My belief is that Amazon is not unique in this type of challenge. In fact, I've run this exercise a bunch of times. It's super fun to do with teams. I get this team together and what I like to do is actually work with leadership teams or you can do this with your own teams. It's a really simple process. The worksheet is just a page of paper with a grid in it. First column, let's all together as a group agree that we're going to do a deep dive on three artifacts and pick whatever that might be. Maybe that's my PRD form or my income request, whatever process we have that we use, maybe code review goes in there, whatever that might be. What's the process I currently use today? That's the first artifact, first column.

Then independently, you don't get to talk to anybody else. You have to fill out the next two columns. Why was it made? You can't cheat off your partners. What's your theory? Why do you think this thing exists? Third column is kind of interesting. What does it teach? Because here's the thing, every action that you take as a leader teaches your people, whether you think you're doing that or not. The things you pay attention to tell them what actually matters. The way you react when failures happen tells them what matters. The mechanisms that you use teach people whether you want them to or not.

I'll give a concrete example here early on in my career at Amazon. As a young manager I was given the responsibility during performance review season after we'd done some calibrations to allocate funds to my team. You had thresholds, you had boundaries, so I knew I wasn't going to exceed the boundary for any particular individual. But I might have said, you know what, this person's doing well. They're doing good. She, on the other hand, is doing awesome. So I want to double down and actually what I'm going to do is maybe take a little bit of stock from here and put it over here because this person is on the trajectory for going up. Staying within bounds, it's all good. I'm closing within budget, all good to go.

Next day I log into the tool. All of my values had been changed. So I emailed my manager. I'm like, is there a problem with the tool? And he's like, no, no, no, the tool's fine. Your HR partner and I went in and we just kind of reshuffled things a little bit. What did that teach me? It taught me that while we said ownership and they had given me ownership, they didn't really mean it in that instance. So the mechanisms that we use, the approaches that we take actually teach our people something.

When I've done this exercise, it's been fascinating to uncover where we have inconsistencies of belief, even within a team that's been working closely together. I did this with one company. The hilarious thing was as soon as I said artifact, they all said, oh yeah, PR 72, whatever that, I have no idea what the acronym stood for, but everybody's like, yeah, let's talk about that artifact. Then they filled out why was it made independently and what does it teach. Then they shared answers. The hilarious thing to me, I mean I found it hilarious, they probably felt very uncomfortable about it, but the creator of that process was part of the team. When he's sitting here listening to what people think it's there for, he's like, no, that is not why we created this process.

There is evidence yet again that if we don't spend time helping reinforce those mental models, they will erode over time, and you will end up not where you want to be as an organization. Now what happens when we get it right? If we get those mental models in place, what happens?

Shared Mental Models as Guardrails: Enabling Speed Through Alignment

Well, we see shared mental models driving business alignment. In an ideal situation, this is my organization and this is my team. We are all moving full speed and we're headed in the right direction. Reality often looks a little more like this. There's a lot of activity going on. We are all over the place. This is a classic management problem. And because management problems have existed for a really long time, there are approaches that have been taken over the years to solve for this problem.

Now, the typical approach says that is not acceptable. So maybe we're starting here and we want to make sure we don't end up there. What do we do? We typically inject policy or an escalation point or management or a decider, an approval layer to help redirect and guide. Now notice, this does have the end result of us getting the right work done. But at the cost of speed, at the cost of motivation for all those energized individuals who face the corporate no. For whatever reason, because they didn't necessarily know or understand the policy, whatever that rationale might be, they've slowed down.

We think a better model is when we have a system of shared models. We don't have to spend time coordinating or checking in with leadership because we're following inside. I think about these as guardrails around decision making. If my team is operating inside the bounds of those guardrails, they don't even have to talk to me. We point them in the right strategic direction. We get the right data feedback from them to indicate those data points that say they're still headed in the right direction strategically. Here's the boundaries, don't cross those boundaries. Stay inside there, go.

Now I do think that this problem, this illustration actually has a fundamental problem with it. Because it assumes we have the right mental models. And so I want to share with you my favorite five word phrase at Amazon. Unless you know better ones. This is an invitation to dialogue. Yes, we have those leadership principles, but on those leadership principles it says these are our leadership principles unless you know better ones. We don't presume that we have arrived at perfect truth. And every individual perspective has the potential to make us better than we were.

So what I find really effective is when leaders and teams align around what those mental models should be at the organizational level. At Amazon level we call these leadership principles, but lower down we actually use tenets to guide individual teams. So teams will work with their leaders to say what are the guardrails that we should have in addition to the leadership principles, what are those guardrails we create? Now what I'm finding fascinating about that mental model is that that's exactly the same mental model that we're now seeing effective in managing agentic AI.

Because what do you need to have? You need to have some assurance that as you grant autonomy to the system, that it's not going to go flying off the road. And so when things like policy, which I didn't know about until yesterday, got announced, I'm like, yes, this is exactly the challenge that needs to be answered. How do we provide those guardrails? So as we need it for humans, we need it for the machines as well, because when we can provide those guardrails, it accelerates our momentum because we're not having to stop for all those conversations.

Mechanisms That Reinforce Culture: From the Customer Service Andon Cord to Daily Business Rhythm

The last thing that I want to touch on here is at Amazon, it's not enough to articulate the mental model. That's important, get the language clear and crisp. It needs to be understandable, compelling, challenging people's assumptions. We also need to embed those mental models in mechanisms. Mechanisms are the processes that we use as an organization every day.

Now we have a specific construct. When I use the word mechanism, I recognize I'm just pulling a word from the English language. But at Amazon, we've got a very specific construct that we label a mechanism. It is our version of a closed loop feedback process. We take something as input. We have a tool that does some sort of a transformation on that input to turn it into an output. We have adoption, those are the people that are using the tool. We have inspection. We need to know if this process is actually yielding the results we're looking for, and at the end we have output, and finally we have iteration.

Which means I could set up an ideal process that works amazing for the next three months, but if I'm not ever taking a step back to look at it on a larger scale, I may leave a system running that's actually no longer effective or efficient. And so we see iteration as a key part of the concept for mechanism. The concept for mechanism originated, I think, in my timeline maybe 2006, 2007 for us. We mentioned our mission to be customer obsessed, right? The most customer-centric company.

To live out that mission, it means that as leaders, we need to be in touch with actually talking to customers. So Jeff Bezos, really early on, set up this practice where he would on a regular basis, maybe eventually it ended up being maybe once or twice a year, but he would literally sit right next to a customer service associate taking live calls.

That had to be unnerving for that poor customer service associate. So Jeff is sitting next to this associate who is taking a call, and a call comes in. Our software recognizes the phone number, matches it to the customer's account, and pulls up the customer's order history with lots of orders on the page. The associate looks at the screen and says they're going to return that table. She opens the connection, and yes, the customer is calling to complain about the table they received because it's scratched and they want to return it. The associate does what she needs to do to take care of the issue and closes the call.

Jeff turns and says, "How did you know? How did you know that of all the things in their order history, that was the thing they were going to be returning?" She said, "Oh, those tables get damaged all the time in shipping. This is the third one I've done today." Jeff's mind blows. How are we okay knowing before we've even shipped a product that it's going to be defective by the time it gets to a customer? We can't be okay with that. He gets everybody together in a room to have that conversation. Six months later, nothing had changed, and he realized his mistake. His mistake was that he was asking people for good intentions. He wasn't asking for change. Everybody already had good intentions. Nobody wanted to ship a defective product. What we needed was a mechanism that would allow us to make that change happen.

So what we built, we took a page from Toyota. Prior to building automobiles, Toyota actually was a textile manufacturer. Even back when they were manufacturing textiles, their philosophy and the systems they had in place was that everyone's expectation and responsibility was this: whoever is on the line, if they see a single thread out of place, they pull what's called the andon cord, and it stops production for the whole line. It freezes the current state. Now we can go and inspect and find out what's happening. In a lot of American vehicle manufacturing, that's the line that gets pulled only for safety things. There's perhaps a little bit more tolerance, or has been historically, for situations where it's just one of those things—it's okay, we sell a lot of cars, it'll be okay. Toyota's mental model is that anything that's out of place is my responsibility, even if I'm the low person on the totem pole, to pull that cord and stop the line and get the defect out.

So we took a page from that model and said what we need to do is enable that customer service rep to take direct action. What did we do? We built something called the customer service andon cord. As an input, it's customer-reported defects. These agents are taking calls all day long, reading emails, or answering chats. We put as an overlay to the screen on the retail website this tool, and this tool allows that customer service representative, without any further escalation, to click a button that removes the viability of the item from the website. It doesn't delist it because we still have the product; we're just not selling it at the moment. That's typically a management-level decision because that's a line of revenue that you just shut down. But our mental model is that you're going to do the right thing for the customer in real time, take that down, and ask the customer, "Can you refresh the page for me?" And that buy box goes away. That's a trust-building moment.

So in our mechanism model, we have customer-reported defects, we build a tool called this andon cord tool. Unfortunately, that's where a lot of companies stop. We built a tool, yay, we launched it, yay! Who's using it? Do we even know? Some companies go the next step and they have an adoption program, and then they're able to report back to the board that they launched the tool and it has eighty-seven percent adoption among all customer service associates. Yay, stop. Is it actually solving the problem? Where are your metrics and data on that? So in addition to that, that's where inspection has to come in. Do we have the data that leads to the output we're trying to generate? The output we're actually trying to generate is fewer customer-facing defects. It's not just solving that one particular problem, but it's that whole ethos that we're trying to get into people's minds.

So what we've taken is the mental model that says don't allow a known defect to be shipped, and we made it possible to be reinforced through this mechanism. This approach has been a really powerful way for us to do that work. I would say that this thing that we talked about earlier, this working backwards process, it's a mechanism. It consumes ideas, and the output of this process is an idea that's grounded in customer impact. If I can't quantify customer impact through this mechanism, that's one of the clearest signs we get to throw the idea aside and maybe work on something else. It is used not just by writing it, but in that meeting where we sit and we read it in silence and everybody's scribbling on this piece of paper and we have this rigorous debate and conversation.

It is reinforcing these cultural values in the process of figuring out whether we should build this product or not. I have time to have back on disagree and commit. There's a specific way in which we want to engage in that debate. In fact, we say leaders are obligated to respectfully disagree when they have a different perspective. It's not optional. I need disagreement to happen. Why? Because without that particular perspective, I could be off by just two degrees and we could end up in the wrong place.

Now it does say respectfully, so that doesn't give me license to be a jerk. All of these things start to come into play. Insist on the highest standards. This is the right quality solution that we should have in place. Invent and simplify. You're inventing something here, but now you've made it even more confusing for the user. I'm just going to call a self own on that. I think AWS we're really good at the inventing. It's a lot harder to get to that simplified stage, and we inundate you with a lot of things.

They're really cool. They're very customer grounded. In fact, so much so that when our teams are producing roadmaps and they're highlighting all the features we're going to go build, you'll have some leader reviewing a document. There'll be in Appendix G. They'll pull up some random feature that the team's going to go build and say which three customers need that feature. The team doesn't have an answer. It's a big problem. Because we don't build tech for tech. We build tech because we've identified a legitimate customer need that can only be solved with this thing that we're going to go build.

So it's this combination of those mental models. Having the right mental models are key in shaping your culture. But it's not enough to write them down. If we don't have them reinforced by our behavior as leaders, that mental model will erode over time. When we get it right and we clearly articulate those mental models, it drives alignment for our teams and for the organization as a whole.

And then finally, creating mechanisms to teach and reinforce those mental models in the rhythm of the business. We don't have a meeting called let's review the mental models. We have a business meeting where we are going through and looking at the data and trying to make a decision, but we are reinforcing by what we pay attention to. Again, that leader going, which customers need this, that's reinforcing that mental model or asking the question, what's your plan on supporting this thing in sixteen months?

We see a lot of that happening right now. In fact, a lot of the challenges we're seeing in the space of agentic is people go build stuff because it's fun to build. One, it's often disconnected from real customer value or business impact. It's being done because it's a cool toy to play with. Always connected to customer value. Two, your customers are probably planning on using that for a while. Let's be thoughtful right now as we think about pursuing this idea about how we're going to support it in production because ultimately again it's all about that customer trust.

Using mechanisms to reinforce and teach those mental models is how Amazon has managed to go from where we were selling VHS tapes to where we are today. I want to thank you very much for your time. That's all the time that I have here. I will be available outside. Thank you very much.

---

; This article is entirely auto-generated using Amazon Bedrock.