Kazuya

Posted on Dec 6 • Edited on Dec 8

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

🦄 Making great presentations more accessible.
This project enhances multilingual accessibility and discoverability while preserving the original content. Detailed transcriptions and keyframes capture the nuances and technical insights that convey the full value of each session.

Note: A comprehensive list of re:Invent 2025 transcribed articles is available in this Spreadsheet!

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 reinforcing mechanisms. He introduces Amazon's 16 Leadership Principles, particularly Customer Obsession and Ownership, demonstrating how they drive decision-making across the organization. Using the Antikythera mechanism as a metaphor, he illustrates how organizational artifacts lose meaning over time without reinforced mental models. Brozovich details Amazon's Working Backwards process (press release, FAQ, visuals) and the Customer Service Andon Cord mechanism, showing how Amazon embeds cultural values into daily operations. He emphasizes that mechanisms must include input, tools, adoption, inspection, output, and iteration to effectively reinforce mental models and prevent cultural erosion as organizations scale.

; 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 Music Major to Culture Guardian: A 26-Year Amazon Journey

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 onto 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 a little different back then. Amazon looked quite a bit different back then.

Just for point of reference, when I joined Amazon, we had already expanded from the US into 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. Right, I'm getting old enough 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 moving 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. And along that journey, as fascinating as technology was and is for me, I really became intrigued by the human part of that equation. Because 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, to be able to take advantage of that.

And so about 13 years ago, I took a step out of tech to the dark side. I joined HR. Now I don't mean to alienate a lot of people in the room. Okay, fine, you can get up, that's fine. I totally understand, sir. I get it. 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, very deeply that one of the primary reasons for that success was our culture.

And 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 that we might be losing touch with what mattered to us and actually what had led to our success as an organization. And so for a period of time I sat in the role of running the Amazon Culture program. How do we think about culture across the breadth of Amazon's organization? And then I narrowed my focus to look at executive development because you as leaders have an outsized impact on the culture of your organization.

And so 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 be able to lead effectively, the better off we will be and 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 30,000 to over 90,000 employees during that period of time, 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. And 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 10 or 15 years, and you're seeing things change and some things you're excited about and other things you're like, 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? So that 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. Now, I just gave you a little bit of my background, right? Music major, 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.

Understanding Culture: Mental Models, Behaviors, and Artifacts

Now 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. So I'm going to use a pretty simple definition I found really helpful for what are the things that comprise 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 and we make assumptions about those behaviors based on our mental models.

Some of those might be beliefs, 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 leaving something behind. And these three components together kind of make culture.

So let me give you a concrete example of my experience of mental models. I live in the Seattle area and have lived there for a very long time. And there's an old story about how at that point in time, then President Obama was visiting Seattle, and he was in his hotel late at night, and he's looking down at the street. And he observes what's happening with the pedestrians. There are no cars on the road, but in Seattle, this is typically the behavior you see. The light's 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.

Now I didn't think a whole lot about how internalized that mental model was for me until I was in São Paulo. And I stopped, and I pretty much got run over by every pedestrian who's 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, 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 in Archaeological Interpretation

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 little bit. Now, how many of you in the room recognize this artifact? I've got a couple, 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, 1902 were diving and harvesting sponge from the sea floor, and they came across a shipwreck. And they found all the things you would expect to find inside your average shipwreck. They found amphora, you know, 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 50 years with nobody knowing what it was or what to do with it. In fact, it wasn't until the 1990s, so almost a whole century later, that scientists started using medical imaging technology to look inside ancient artifacts. And when they applied that technology to this device, they were astonished at what they discovered.

This device was comprised of more than 33 precision cut gears. There's actually inscriptions on some of the gears that they can actually read and interpret. And 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, on the face are a visible representation of the sun, the moon, and the four visible planets. And there's a knob on the side.

This device can accurately predict solar and lunar eclipses. It has been carbon dated to somewhere around 200 BCE. There is nothing this sophisticated in the historical record for another 1500 years. Okay, at this point you're starting to wonder, did I join a lecture on archaeology or what, what the heck? Okay, 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 Stephen's interpretation of archaeology. I find a thing, I go, what is this? Okay, 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, we ask, 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, like Greeks were very amazing mathematicians.

The Greeks were amazing mathematicians who invented whole areas of mathematics, so it's possible that the Greeks were responsible for building this device. However, there are some unusual aspects to it. The calendaring system used on the backside of the device has much more similarity with the Babylonian calendaring system. So there's a school of thought that says this is actually more ancient than Greece and is of Babylonian origin. Those astrological symbols are really important, and astrology was a major part of Babylonian civilization. I will say yes, there is a school of thought that says 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 is the right hypothesis.

And then the third question we tend to ask is, well, 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? Here again, 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 contained examples 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, look, those astrological symbols have a whole lot more to do with fortune telling. Or perhaps this was an early form of celestial navigation. How do 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. 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?

Now notice how these three questions map back onto these mental models. The behaviors and artifacts. In fact, it happened the other way around. Somebody had an idea, and based on that idea they built something. As a result of building something, here we have this artifact that's left. Yet again, you're probably sitting here thinking, Steven, you haven't moved on to anything other than archaeology yet. Get us to somewhere else.

Mental Models in Action: Amazon's Customer-Centric Foundation

Well, here's the deal. Our beliefs 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. So 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 has some really unique 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. It's 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 that. But the new folks don't. So they walk in and start with, hey, how was last weekend? And everybody's like, what are you doing? So there's this culture clash that's happening because what we do as an organization is different than others.

But let's dig in, in particular. Let's start with mental models. Now 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. It's 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.

Leadership Principle: Ownership Beyond Boundaries

Now, 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. Great. 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 weird 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 off of 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.

Next sentence, 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. I mean, sometimes it's weird, like even within their own company, well, I don't trust that guy's software. He works two doors down from you. No, no, no, I'd rather write my own. Oh no, hang on a second. Don't make a decision that sub-optimizes for your unit. Think about the broader impact for the whole organization.

And then the last sentence 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, right? 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.

Customer Obsession: From Hyderabad to Connecticut

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. 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.

Now, 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.

And our experience has been when we are truly listening to what those customers' needs are, look, 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?

Last sentence, 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 weird and interesting ways.

So we have software teams all over the world and we organize, and you've probably heard the two pizza team model, but 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 that they are iterating on this constantly and they want to be in touch with their users.

And so we have one of our fulfillment software teams that's based out of Hyderabad in India. And 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, and they own a part of the process, and so they wanted to see how is my 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 these are smart people that maybe you're dealing with an interface that's not so great. So we've made this a really regular practice. Let's make sure that our engineers are sitting with the people who are using the tools. We will learn so much by those interactions.

So 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. And 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. Delivery promise was December 24th. And they go, 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 here? They even looked at, could we charter a jet. And we could get it there, but they ruled that out because of frugality, which is another one of our leadership principles. So chartering the jet was probably not the most frugal thing that they could do, but then they remembered this.

Their flight back to Hyderabad was happening the day before Christmas, and they had a layover in JFK. And it turns out that Mystic, Connecticut is a 100-mile drive. So what did they do? Landed in JFK, rented a car, drove 100 miles up to Connecticut, knocked on the guy's door, hand-delivered the package, got in the car, got back, got their flight, went home. That's nuts. That's crazy customer obsession.

But 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, and what kinds of decisions would that individual be making 10 years later? They might be in this room right now going, AWS. I still remember when they failed to deliver the promise, even though AWS is different. Trust is really hard to earn and easy to break.

The Erosion Problem: When Artifacts Outlive Their Mental Models

So the impact of those types of mental models drive behavior in the organization, and so we want to make sure that we are spending time talking about and sharing and reinforcing those mental models, because what we found is that reinforcement of mental models erodes over time. So imagine you're in a situation, you're working on a hard problem as a team, maybe as a leadership team, you've come up with an idea, you've figured out the right process to solve the particular challenge, you've built the tool, and you launch 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's that mental model, the behavior, what's the action that we're trying to accomplish, and then the artifact itself. But here's the weird thing that happens. The further away I get in time, in geography, in organizational depth, what tends to happen is the artifact persists, but the behavior or the mental model that led to the creation of the artifact becomes less and less clear.

And then human nature takes over, because what happens 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, I'm interpreting that artifact based off of my mental models, what makes sense to me. And so we see some patterns. Do any of these look familiar to you?

The first pattern is reject. 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. And then someone new comes in and they don't like your process, they want to use their process because it worked for them. So that's one action, not a great action necessarily.

The third one is not great either, because then we just like, okay, I have no idea why I'm supposed to fill out Form 27B, so I'm filling out Form 27B. And then the problem is when I fill out Form 27B because I don't know the why, what I provide is actually not very good. And in fact, leadership now can't make a decision because the data that 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 or two years ago or five years ago, whatever that is.

When we don't spend time reinforcing the mental models, what we are left with are the organizational artifacts, and that is why I believe company cultures erode over time, because we're going to interpret those artifacts based off of our own understanding, maybe not even in line with the leaders who created the process in the first place. And 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. And the question is, are they walking away with a clear understanding of what that is and why?

Working Backwards: The Press Release as Product Development Tool

Now, Amazon is not immune from this pattern. Some of you have some exposure to our process of working backwards. For those of you that have not seen this before, I'm just 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, maybe it's sooner or further than that, where we have now solved that particular customer's problem. First paragraph, who's the customer? Actually, that tends to be a really hard question to ask because we often get really excited about the tech. And 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 I get the first paragraph, who's the customer? What's the nature of the problem or opportunity? 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, the fourth paragraph, 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. Because 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. And 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, 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 forty-seven iterations before we assigned 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 for that? Scrap it. Far easier to walk away from a bad idea that's still on paper versus the 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. And we find that when we start with the press release, we start with that clear understanding of who the customer is, what we end up producing actually tends to be the right thing for them to focus on.

It's not bulletproof. I actually spent some time yesterday, I had a talk at the 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.

When Mental Models Fail: A Director Who Never Wrote a Press Release

So you can imagine my surprise when, as part of our executive development team, I'm at an off-site. And 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 high-importance, high-caliber talent that we are investing in heavily.

And we have this off-site. And in that off-site, we had them examining the health of mechanisms within their own organizations. And 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 a teaching piece and talk about mechanisms here in a little bit, and I have a specific concept for that word that we'll share with you in a second, we have these small groups that have broken up and they're just having a little bit of dialogue. I'm being that good facilitator, so I did some teaching and now I'm going to drift and listen into this conversation. If anybody has questions, you deal with the questions, then I come over to another conversation.

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. What he does is 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.

Here's the thing, 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 off of his experience, but notice how far his mental models are from where the intent was when this process was created. My hunch, my belief, is that Amazon is not unique in this type of challenge.

The Artifact Exercise: Uncovering Misalignment in Your Organization

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 leadership teams, or you can do this with your own teams. Really simple process. The worksheet is just like 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 so we pick whatever that thing 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 weird. 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, that's what you're doing. The things you pay attention to tell them what actually matters. The way you react when failures happen tells them what matters, and the mechanisms that you use teach you 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, we've done some calibrations, and I was given the responsibility 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 I'm going to take a little bit of stock from here and I'm going to 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. It's just 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 do we have inconsistencies of belief, even within a team that's been working closely together. I did this with one company, and 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 the why was it made independently and what does it teach, and 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 mental 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.

And so what I find really effective is when leaders and teams storm around what those mental models should be. At the organizational level at Amazon, 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: Embedding Mental Models in Daily Operations

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. The concept for mechanism originated, I think, in my timeline maybe 2006, 2007 for us. 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, you know, eventually it ended up being maybe once or twice a year, literally sit right next to a customer service associate taking live calls.

That's got to be unnerving for that poor customer service associate, having the CEO founder sitting next to them. So Jeff is sitting next to this associate that's taking a call, and a call comes in. Our software recognizes the phone number, does the match to the customer's account, and pulls up the customer's order history. There are lots of orders on the page, and the associate looks at the screen and says they're going to return that table.

She opens the connection, and yeah, the customer is calling to complain about the table that they received because it's scratched and they want to return it. So 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 of all the things in their order history that that was the thing they were going to be returning? And she said, oh, those tables get damaged all the time in shipping. It's 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 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.

And so what we built, we took a page from Toyota. Now, I don't know how many of you know this, but prior to building automobiles, Toyota actually was a textile manufacturer. And even back when they were manufacturing textiles, their philosophy was, and in fact the systems that they had in place, it was everyone's expectation and responsibility, 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. Freeze current state. Now we can go and inspect and find out what's happening.

Now, sadly, 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 a little bit more tolerance for, it's just one of those, it's okay, we sell a lot of cars, it'll be okay. Toyota's mental model is anything that's out of place, it's my responsibility, even if I'm low person on the totem pole, to pull that cord to stop the line and get the defect out. And so we took a page from that model and we said what we need to do is enable that customer service rep to take direct action.

So what did we do? We built something called the customer service Andon cord. As an input, it's customer reported defects. So these agents are taking calls all day long, or they're reading emails or they're 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 buyability 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 you're going to do the right thing for the customer in real time to take that down and ask the customer, can you refresh the page for me? And that buy box goes away. Talk about 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?

And so some companies go the next step and they have an adoption program, and then they're able to report back to the board, we launched the tool and it has 87% 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, and what's the output we're trying to generate? The output we're actually trying to generate is fewer customer facing defects. It's not just let me solve that one particular problem, but it's that whole ethos that we're trying to get into mind.

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. And 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, put it aside, and maybe work on something else.

From VHS Tapes to Agentic AI: Sustaining Culture Through Transformation

And 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 should we build this product or not. I have time to have backbone, 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. And 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 here all the features we're going to go build, you'll have some leader reviewing a document. They'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? 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. And so using mechanisms to reinforce and teach those mental models, this is how Amazon has managed to go from where we were selling VHS tapes to where we are today.