Well, we think, particularly for people leaders, as we try to think of our role as to find a way to yes, so rather than you know, go into a lot of meetings and people think it's their job to say no. Really, my job is if someone's brought me a proposal, is to try to work out how to get it to yes.
Welcome to How I Work, a show about the tactics used by the world's most successful people to get so much out of their day. I'm your host, doctor Amantha Imba. I'm an organizational psychologist, the founder of behavioral science consultancy Inventium, and I'm obsessed with finding ways to optimize my work date. My guest on today's Best Of episode is Paul Migliarini. Paul leads the Amazon Web Services business across Australia and New Zealand, which is a role that he's been in
for the last four years. Prior to joining a WS, Paul held senior leadership roles in Asia and Australia with bt Motorola, Regis and Ernst and Young and most recent as the CEO for Regis A and Z and the Regional Managing Director for South Asia at BT SO. I was really keen to have Paul on the show because I've heard so many things about Amazon's culture and just their ways of working, which I find fascinating. And there is nothing better than and able to get an insider's
perspective on how it all works. So if you've ever wondered what goes on behind the scenes of one of the world's biggest, fastest growing, and most powerful companies, I think you'll love this chat with Paul. So on that note, let's go to Paul to hear about how he works. Paul,
Welcome to the show. Great to be I want to start with what we were just talking about before we started recording, and this is that you've been having email and calendar problems on your phone and now you're actually going to change your behavior as a result of what happened. Can you tell me about that.
So it's totally by accident, and as I say, constraint does breed innovation in many cases. And so I had an issue with I with my phone, so for some reason that I still haven't resolved, my email and the calendar stopped working and I just haven't gotten around to getting it fixed. And so I've been living in this world without email and calendar. And my realization is that I really miss my calendar, but I don't miss my email.
And it's helped me be a lot more present and helped me manage the context switching that happens during my work day, but equally the context switshing that needs to happen when I go home in a much more effective way. So you're very intentional about when you look at your email and when you're focused on it what you do with it. And I'm thinking it's contributing to a pretty good increasing productivity. So when and if I get my phone fixed, I think I will leave my email off
and put my calendar back on. But it's been a really positive change by accident.
That's awesome. And so you're saying when you get home, like rather than in the pre broken phone days, you might maybe check your email a few times, like throughout the night, because it's just so easy to do when it's on your phone, But now it's intentional. You open up your laptop once and check totally.
And because you know, in our world and I think most people would work in this way, you're working across multiple time zones, you know, within Australia and New Zealand, but around the world, and so you've got these threads that stay open, and you're trying to process things in real time because customers are looking for quick results, and so you tend to just continue to look at things
because you've got so many things that are open. Sometimes that's productive because you can be really responsive, but most of the time it's not, because you get distracted by a whole raft of things. It could easily wait till another time, a more formal time.
Yes, because I was going to ask, like there must be listeners kind of going, yeah, but what if there's an emergency that you're going to miss, what do you say to that?
People can call or they can send an SMS or or something like that. And so there are other means to get in touch.
That's right, there are, aren't they? We forget about the barone. Yes, good old fashioned calling. Yes. Well, I want to dig into Amazon's leadership principles because I think they're really interesting and maybe for those really most listeners are not aware of the leadership princes. Can you just explain briefly what they are, why they exist?
Sure, So we have fourteen of these principles that the best way to think about it, I think is as an operating system for the company. So there's a set of principles that are booke ended by two the first being customer obsession, which is that everything we do in the company starts with a customer and works backwards, and we try to take a really long term perspective to that and keep customer trusts out kind of core true north. And the other end of the book end is deliver results.
And then there's twelve other principles that sit between those two, and a lot of it started goes back to kind of the early days of the company when we floated in nineteen ninety seven, Jeff Bezos wrote a letter to
shareholders and said some important things. In that letter. He said, you know, we're going to build a company that's really focused on the customer, and we're going to index on the long term and not be thrown off course by short term sort of market forces or other things that make it in the way of us and our customers.
And I think that a lot of those principles and a bunch of others have been codified over the years into the four Leadership Principles, and what we try to do is as an organization is operate in a very decentralized way where people close to the customer can be really clear on how to make good quality decisions at high velocity velocity without having to refer them back to
managers or even to head office for decision making. So it helps us move really really quickly, and it helps us make good quality decisions around what we're trying to do for our customers. And really it's one of the big fundamentals on how we can move really quickly, and it's a kind of absolute bedrock of how we run our company.
Yeah, fourteen, Like that's a lot. And one of them's frugality, which just sort of seems odds with having fourteen principles, Is that right? Yeah, So I do want to delve into maybe frugality first and tell me about what does that mean and how does that actually play out. Like, for example, we're just talking about lunch before and apparently Amazon's not giving you a free lunch what you're a tech company.
Well, there's a couple of aspects to this principle of frugality. One of them is that we believe really fundamentally in this idea of investing in things that we can directly correlate with benefit to our customers. And you know, we think that, you know, a lot of these superfluous benefits don't right, We try to It's not as though where
we don't spend. I think, as I recall one last year, we were one of, if not the largest spending globally in the context of R and D, you know, over twenty billion dollars in R and D. But we try to make sure that investment is deliberately focused on creating value for our customers. So that's one big aspect of it. We try to be really disciplined about that. The other
big aspect of frugality is this notion of constraint. You know, so when you do actively constrain resources, typically what you find is that you come up with really interesting ways to solve problems. So in a world where you have unlimited resources, you probably aren't going to be a particularly innovative company because you don't have to be. But when you're actively constraining resources, you tend to find really creative
ways to solve problems. So that's a couple of the fundamentals that sit behind this notion of frugality, and it's a really important leadership principle, and often most people will say it's one of the more difficult ones because we're growing so quickly and investing so readily and in so many important things, and you know, we try to think really big, which is another one of our leadership principles, and be very expansive as to how we think about
creating value for our customers. And you have to invest a lot, you know, and then to actively constrain resources at the same time is quite a difficult discipline, but a really important one.
And so can you give me an example of where you've had to apply that in a way. I guess that's been challenging for you and your role.
So typically what will happen is, you know, we will get an investment plan and often the teams will be saying, look, I'm looking to you know, there's this many customers and we believe fundamentally we can we can help them in a really interesting ways, and therefore we need this, you know, this level of investment, and we'll go, okay, that's interesting, but you know, how would you do that with half
the investment? Because we're constantly thinking about this idea of scale and in particular the notion of doing it in a non linear way. You know, so as we're trying to grow our business, you know, how can we be doing it in a way that's not proportional ae where
because that's allmly not effective in the long term. So we'll consciously say well, okay, you can have half or you can have a quarter, and invariably what happens is it's super interesting because the team go away and because it's conditioned through our principles, it's not a real frustration. People know that's why we're doing it, and it's just as a forcing function to go away and think about a problem in a very different way, and most people find it to be pretty useful.
So would that then be unusual to give a project the full funding that has been requested.
It really depends. I mean, we are investing, you know, really really heavily, you know, lots of people, and that's because the market opportunity is there and we see that customers are driving a lot of value from the work we're doing, and therefore we're investing against that. And so there's a tension, you know, between the two. And it's
a question of how well you manage that tension. I guess that just coming back to leadership principles for a moment, I mean, part of the way or one of the easier ways I think to think about it, is that we have this kind of fundamental belief around the company that we are a company where builders come to build.
And so this notion of being a builder, it really is the embodiment of these fourteen leadership principles that you really focused on invention, you really want to think big, you have a strong level of ownership and biace for action around how you solve customers, and so you can roll all of those principles up into this idea of being builders. And we think that everyone's a leader and everyone should be a builder and really therefore represent those principles in a really kind of effective way.
So how does that relate, like in terms of everyone's a builder. If you're in say sales marketing or something like that, like you're not an engineer, how do those people conceptualize that.
I can give you a real example. So my current manager, Ed who was my predecessor in my current role a number of years ago, now four or five years ago, was looking at what we're doing for our customers, and he had a hypothesis around this notion of global customers
and how they wanted to deploy tech. And so he had an idea basically, and he wrote it up in a six page and he said, look, we need to think about building a new organizational unit that's really built specifically for the needs of these global multinationals who who want to consume tech in different ways. They're highly distributed. And so he wrote a six pager and when build a entirely new business today is a multi billion dollar
business from a six page document. So that's a really good example in the world of sales of how this works today. We have a team of people here who are doing an incredible work around this idea of what we call the cognitive customer experience. So we've got a platform that effectively creates a software based contact center called Amazon Connect. But equally, what we're seeing is that loads of customers are looking to integrate that with AI and a whole raft of other things that will help them
to transform the customer experience. And so we created a small team we called it a two pizza team of builders who are out there.
And I can explain what you mean by a two pizza team that are not familiar with that chanel.
So it's essentially a small cross functional team that has their requisite skills within it to operate completely autonomously. And the idea is that what we want in terms of scale is a team that it's kind that you could feed with two pizzas is the basic rule of thumb. So we think it kind of ten to twelve people roughly. And the reason we try to keep it small is because what happens is as teams grow is you tend to have to create a whole series of mechanisms to
establish to manage cross functional communication. So what happens is once you get to a certain level of scale, you're building all of these overheads into the team and it impairs your ability to move fast. So we call it a two pizza team and have a principle around scaling
those teams horizontally that enables us to move fast. So we created this two pizza team around Connect and today we've got many, many hundreds of customers across Australia and New Zealand using the Connect platform integrated with a whole aft of our artificial intelligence services to think in a very different way around improving the customer experience. And there's many of those types of examples.
Yeah, I like the idea of scaling horizontally. That's an interesting way of putting it. And I've heard Bezos say that he would prefer two completely separate teams working on the same thing and not knowing about each other's work, and then just kind of finding out after the resources have been used. Can you maybe go into that a little bit, because I feel like that's a really challenging concept for most organizations that are organized and really structural.
As a leadership principle, that's kind of helpful there. It's called having a bias for action, and so we believe that one is probably better than two, but equally too is a whole lot better than zero. And what we mean by that is that doing nothing is not a
good answer. So invariably, what we accept that if we have a bias for action and we see an opportunity, rather than stopping and waiting and aligning all of the resources and making sure there's no waste, invariably what tends to happen in a lot of companies is nothing right, And we accept that in some cases, what we might create is a situation where there may be two people or two groups of people doing the same thing or
even more. But if we're moving forward around the customer's agenda and we've got good rigor in what we're doing and we're learning, then ultimately it's going to be better than doing nothing because we'll learn and at some point in the future we may consolidate or aligne or whatever, but it's way better than doing nothing. So accept that in moving fast and having a bias for action, there may be some waste.
So how does that then sit with you as a leader, Because again, I would imagine most senior leaders it is important for them to retain control and understand what's going on in every pocket of the organization and feel like they're all like across it. But I would imagine it couldn't be like that here based on that. What's that?
Yeah, it's kind of interesting. I often tell people that you don't do a whole lot of management work at Amazon. You do a whole lot of coaching, and the leadership principles become really helpful there because you know, we're hoping that people are out in front of customers making great decisions and helping customers in a really effective way. And the last thing I want to do is get in
the way of that. I want to give them as much freedom to do that work as I possibly can, because it'll enable them to move faster, and we'll learn from that and we'll just get better and better over time. In terms of helping our customers, what we try to focus on, rather than outputs is a set of inputs. So we try to feel really convicted around the inputs. You know, in the case of the cognitive c X work that we're doing, we look at, you know, how
many customers are experimenting with a platform. We look at how much value they're getting from it. We look at the skills that they might otherwise need to be able to really affect change and get value from the platform.
So we'd measure those sorts of inputs and make sure that we're applying our effort on the right inputs, because then, you know, what we try to do is apply the test that says, well, let's then measure the causality to outputs, you know, which might be sort of a set of business goals might be in our case, it may be revenue or sales or the p and l or whatever, and as long as we feel like we're convicted on the right inputs, then it's really about ensuring that we're
supporting the teams effectively and enabling them as much freedom as possible to move quickly in front of the customer. Yeah.
Kind that's interesting, so kind of like lead versus lag measures, I guess.
Yeah, you could call them leads. You know, we use the term inputs quite intentionally, and we do measure a lot of things. We're a very data driven organization and we try to be very, very convicted and have a whole lot of rigor on in terms of what we
measure and the inputs we measure. So that's some of the thing we think about, and hopefully those inputs really guide us to the things that are most important for our customers and in the fullness of time, we think that'll mean that will create value for us.
Now, you mentioned bias for action as one of the leadership principles. There's also deep dive is another one. And for me, kind of when I was looking through them and thinking about them, they feel kind of at odds and I want to know how do they actually play together and complement each other.
Yeah, there's certainly a tension there, and that tensions quite deliberate. So the way we think about that particular aspect is that it comes down to judgment, which is embodied by another Leedgshire principle called write a lot, and we try to ensure that we're making a judgment call. In this case, the judgment call is built around the type of decision,
and so we think about decisions in two forms. We think about a decision being a two way door, that it's inherently reversible, in which case we should index on moving quickly even if we don't have perfect information. We just need to kind of use into wish and judgment
and move really quickly. Equally, if we take the view that it's what we call a one way door, so inherently irreversible, then we expect that our leaders and by the way, everyone inside Amazon is a leader, so when I talk about leaders, I'm talking about everybody as opposed
to people leaders. Then we expect our leaders to exercise good judgment and dive deep and go really deep into the problem, get to the root of the opportunity or the root of the challenges in a very rigorous data driven way to ensure that we're making as good as decision as we possibly could. And so that's how we think about that.
Is it always obvious whether the door is one way or two ways?
No, it's not always obvious, which is why we rely on good judgment. You know, we're hoping that people can see, hey, this is you know, I think in most cases it's reasonably obvious when you look at a decision and go, well, you know, I can see how that's inherently reversible. Like if we've got that wrong, as long as we've got good rigor around what we're learning, then you know, we'll
pivot and iterate in an effective way. Equally, if it's a really big decision, and you've seen some of those, there's really big decisions you know that we've made invariably people like Jeff Bezos and in our case Andy Jasse you are super involved in those decisions, and everyone goes really deep on those specific decisions. But usually it is, but in some cases not so much.
I feel like, disagree and commit gets a lot of pr as one of the leadership principles, And can you explain for those that haven't come across it what it means? And then I'm curious how you have personally gone about applying that, because I think it's a challenging one.
Yeah, I think it's one of my absolute favorites on many levels. The root of the principle is this idea that you know, if you have if you're a scenario where we're in a room for context that has white walls and there's another wall that is black, and you know, we could have a debate as to whether the wall is white or black. And what happens in many companies is you tend to land on consensus and you go, okay, let's agree that it's great, but the answer is that
wall's white and ambiguously white. And so what we should do is we should have a really robust and rigorous argument that gets us to the right answer, and let's have a lot of backbone about that, you know, and make sure that you know, if we have a strong opinion on it, we're putting that opinion on the table in really forthright ways and because it'll we believe it
will get us to a better quality answer. And we shouldn't be meek and mild about that, and we shouldn't be consensus based because ultimately, if we land on the wrong answer, it's going to be mean about outcome for our customer. And so what we try to do is we try to build a bunch of cultural conditions that
say it's really okay to have a very rigorous debate. Now, clearly it needs to be respectful, it needs to be data driven, but it needs to be forthright, and we expect people to have a load of backbone on that. And it's good because it creates a level of permission.
And what happens is we you know, it's a big part of how we recruit people that you know, we have an expectation that you're going to going to really fight your corner on a position if you think it's important for customers, you're not going to back down for unless you you know, you've really made your case clearly.
And then the other part of it, of course, is to say, look, when we've made a decision, then let's make sure we've made it, you know, and nobody is second guessing the decision, because we'll choose to move forward. And so I find it's really really helpful because most of the people I work with at whatever level I can rely upon to give me a really honest, data driven view on a perspective, and that's really really useful.
You know, you don't have to second guess or assume that people won't most people, I would hope all people inside our company will.
So how does that work in a meeting then, because normally I'm just thinking about a typical meeting where it's a consensus based decision as it is that you know nine to nine percent of companies and you know when the meeting has finished because you've reached consensus. But here, like, how how do you know when you've reached the decision because you don't have that natural consensus of closure.
Well, we try to make sure that we make a clear decision, and most meetings are kind of unusual in the sense that we do really believe in being very data driven and rigorous in our decision making, and we have a mechanism for that. Most meetings, by the way, internally we don't use PowerPoint. Most meetings are governed by a sixty well and as long as six page narrative. But it's a written form narrative. And the reason we use a narrative is because it does that job right.
You're not relying on interpretation you're not using high level, superficial data and know nice pictures. You're actually having to write a long form narrative and you have to substantiate the statements you make in that narrative with clear data,
and when they're well written. What we find is it's really useful because at the start of a meeting, we stop and we read it and usually take fifteen to twenty minutes in silence to read it, and it gets everyone onto the same page in a really effective way,
really quickly. And what I tend to find and we have basically a set of principles around how these meetings should run, which is that people that the senior most person in the room should speak last so as not to introduce any any bias inadvertently, and then we have a robust debate and then the opinions of the senior person you're kind of informed by everyone else's opinion, and then typically we get a fairly clear decision as a
consequence of that. So I find that that mechanism, in particular, that narrative is really helpful to getting clear decisions, you know, and that have backbone disagree and commit principle is clearly at work. But what happens is with the document is you do tend to get a lot of rich data that kind of removes a lot of the interpretation and subjectivity that you often see with PowerPoint in other organizations.
Yeah, I want to come back to the six page narrative, but on the disagreeing commit for you, how how do you manage that just internally because I imagine there must have been many decisions that you disagreed on but had to commit to. Like how how internally has that worked? Yeah?
Totally fine. I mean I love it, you know, you know because I feel and certainly it's the case with the people I work directly with, is that you know, you really, you really are expected to have a strong, strong opinion. And actually it's it counts against you if
you have an opinion and you don't share it. So I'm going to give you my opinion, but you know, the expectation is you do it in a very objective, data driven way, and so here's the basis of my opinion, and you'll have a good quality argument and it's not subjective, it's objective, and you tend to get the argument or conversation built around the right things, and you get to
a much clearer decision. And you know, it's happened many times that decisions have gone against me, and I feel totally fine about that because it's not as though you're having voiced an opinion and you usually what you find is that it's a good, considered decision that gets made, even if it's one that you probably don't agree with, And so I find it to be really effective.
How do you pick up for that in recruitment? Because I feel like so many cultures, my own workplace culture and Inventium included, like we've got very nice, agreeable people, and I love this principle of Amazon's and you know, it reminds me of radical candor, and like there are sort of lots of versions you know of that, I guess, So, how do you pick up for that in recruitment to find someone that's actually going to thrive in a disagreeing commit environment.
Yeah, we test for it. And the way we test for it is that we have another leadership principle called hire and develop the best, And the thinking behind that leadership principle is that we want every person who comes into the organization to be a creative. In the context of our company, culture that they're bringing something that's additive, and the test we use is that they're better than fifty percent of people already in that role. So we try to apply an empirical test to that, and then
we have a mechanism that we call the loop. And in the loop, it's quite a a structured process where a candidate who usually has already met a competency bar goes into a process and specifically, what we're trying to test for is whether the person is raise the bar
in the context of our culture. And each of the interviewers in the loop is assigned to one or two leadership principles, and we'll ask a series of questions related to gathering data as to whether that person raises the bar or not against the leadership principles, and then we have a debrief at the end and we compare data points, and one of those leadership principles will always be have backbone, disagree and commit, and we'll have a conversation about it.
If we don't feel like the person raises the bar, we'll talk about why and whether we feel like it can be mitigated, because nobody is going to be perfect against forteen leadership principles. It's usually the case, but the question is can they be mitigated and do we feel like the strengths outwigh some of the perhaps risks that we see, and then what happens, which one of the things I really like is we have typically in recruitment processes, you have a lot of biases that are built into
recruitment processes. You have a bias from the hiring manager who's invariably got it incentive to hire you because at that particular point in time he or she may not have someone in the role and therefore is suffering as a consequence of doing two jobs. You know, there's a
whole bunch of biases there. So we have what's called a bar raiser, and the bar raiser is typically what we think of as a role model, amazon in someone who's really kind of embodies of leadership principles in a really strong way, and they're certified and they have no stake whatsoever in the outcome of that decision other than to ensure that this person raises the bar against our
leadership principles. And in the debrief, that person has a veto and it often gets exercised, and so we try to make sure that if you accept the premise that you know, our culture and our people are going to drive in the fullness of time, our ability to be successful for customers and therefore successful ourselves, then the point of hiring is a massively important point in time in the context of our long term success. So we spent a lot of time and effort on that.
Yeah, that's awesome. With the questions that you're asking around the leadership principles, are they more like behavioral questions where you're like, tell me about a time where you've disagreed and committe like, is.
That we're just looking for an evidence base around how the persons operated through their career that you know that we think aligned strongly to the things we think are really important.
Do you remember your recruitment process?
I do. I do.
What are some of the things that stood out to you or that you that were most memorable in terms of how they worked out whether you were right for the role?
I don't know, because you don't get visibility to your own process. Yeah, no, you don't see the output. Obviously it must have been, okay, must have been. But look, one of the things I find and I get this feedback consistently from people is that culture is a kind of interesting thing because it's not as though it's good
or bad. There's no judgment. I think typically people are good, you know, fit well in a culture, or they don't right, and you may be an outstanding performer but not right for the culture, in which case you're probably not going to be successful or happy in an organization like this.
It's so strongly attuned to these fourteen leadership principles. So what I found is that even though it's a very time intensive process, it's a really good screen both ways because you know, often what I've had is people coming into the process going, look, I've got a really clear sense of your culture now, because you know it's so evident through the process, and you know, I just don't
think it's the right culture for me. And that's awesome, you know when you get that sort of an output, because it's given people a chance to get a real sense of how the culture works and whether they're going to be happy and thrive and operate well in that environment. So it's really useful in that sense.
Yeah. Interesting. I want to come back to the six page and narrative because I had heard that power points are banned. Was that hard by the way to I imagine in your pre Amazon or pre WUS life you would have credited lots of PowerPoint. What was that like getting that up?
In actual fact, I used to be a management consultant, so I lived in PowerPoint for a long time, and so I thought I would struggle with it. Actually, but it became a big It took a long time. And because it's not it's not a natural thing. A lot of people don't spend time writing long form documents in any company, and so actually it's a learned skill and it just takes a bit of practice. And we you know,
so we use long form narrative for most things. So for instance, when we when we do an interview, we'll write our notes up as long form narrative. We don't use bullet points. We just write them up as long form narrative. And so you just become very practiced at it. And so what I find is now it's just it's
it's so useful. I just couldn't imagine operating without them now. Actually, because because of the level of rigor and depth you get to and when you're writing one, what I find is I probably write maybe six or seven of them a year, long form, six pages, and when you're writing them, it gives you exceptional clarity because you really have to. It forces you to be quite rigorous and to think things through deeply, So both in terms of consuming it in terms of getting people onto the same page and
writing them, it's a really really useful mechanism. And so I thought it'd be a lot harder than it was, to be frank, and it wasn't at all.
Like I imagine when you say narrative, I imagine something reading like a short story. Is that the right interpretation?
Yeah? Yeah, six page long form narrative, full sentences, no.
Dot points, no dot points, beginning, middle, and end, with data woven in.
Black and white. You know. Yeah, wow, you can have lots of appendencies, by the way, and so some people do. I never do. But you see these documents that are so well but you don't have to read them, and that's the rule. And so again it's a forcing function. So people have them, but you're not expected to read them. So you need to write the document with a view that the apendicies may not be read.
How long does it take to write one of it?
Kind of depends. It depends. So like I sit down and write, you know, a kind of a document that summarizes our aims at business once a year, and I take a lot of time on that because you know, I really go deep in every part of the business and thin deeply about it. So maybe that's you know, fifty or sixty hours of my time to write that. Equally, I've written docs that I can do, you know, in an afternoon in three or four hours, that aren't perhaps as deep or kind of analytical as the broader docks.
It just kind of depends. You just get very good at writing them. Some of them are quick to write, Others take a lot longer that.
You taught how to write, because I feel like the ability to write, and particularly the ability to write pros is a lost skill. Does Amazon give you training?
We do have narrative writing courses and so it's totally optional. So if people want coaching on it, you can get you can get coaching. And then there's what you do find to your point is there's a bunch of people who are just really good at it, and they invariably become coaches to everyone else as well. I'm not one of those people.
So how did you get better at it? I assume that you've improved at it during your time here.
It's just practicing conditioning. You just get you consume a lot of them, you know, you write a lot of them. You just get good of it. I think moderately competent, I would describe probably not good.
Yeah, I'm just I'm fascinated by that. I feel like there'd be you know, people listening to this going, ah, do away with powerpoints. But then I feel like with the amount of time and rigor that's going into a six page narrative, and I assume that they don't have to be six pages, but that's just the limit that's right. And I assume that they are like font sized guidelines, so you're not just going eight point five.
Totally ten point font minimum. There's there's hard rules around margin sizes and line spacing the whole lot. Because you know, you can imagine every trick in the book has been tried absolutely. You know that this notion of a forcing function is an interesting one. That the idea that it's a fixed six pages is really useful as well, because you know, I know that Andy writes a six pager on AWS each year for Jeff and I sit there and going, you know, goalie, how would you know fit
an entire business into six pages? And you know when I struggle to do the AMZ business and Edwin, who runs out APEC business, does the same. And it's a super forcing function because it does force you to synthesize your messaging into a coherent six page narrative. You can't just waffle on forever, and you've got to get to the important points and you've got to you've got to make it constructive and really focused, and so that becomes useful as well.
I imagine that must be a beautiful time saving device because I feel like like that much thought does not go into PowerPoint decks and there's often a lot of unnecessary totally waffle Where is this? It's all, It's all there. And I want to pick back up on what you said about how within the meeting is when people will actually read the narrative. Is that right? So the of time blocked out for reading.
Normally, what happens is you take you read in silence for the first fifteen to twenty minutes of the meeting, and everyone reads in silence, and again as a bunch of protocols around that and what are they? We just complete silence because people are focused on it and concentrating on their docks, so you know, just being respectful those is important. So it's quite funny, like it's really feels very unnatural when you first join that. Everyone sits down
and you know, hi, how are you? And let's read a dock and you sit there in silence for twenty minutes and read a dock. I find it so super useful because you do get this situation where often what happens, particularly with PowerPoint, is you've get people that are just wonderful communicators and can communicate really well and present really well. Often that can cover a lot of sins. And the
reverse is also true. You get people that are poor communicators who can't get a point across well, but actually what they're saying is really important, and that's kind of I think that's potentially very risky in a lot of companies. What you want to do is get the right message and because you've got time to construct it well and a narrative, typically what happens, and it's not always the case. You know, invariably, if you've get a poorly written narrative.
You know, you don't get a great caller outcome, but when it's well written, getting everyone to the same page with the same data set at the end of that
twenty minutes is really powerful. Because the other thing that happens with PowerPoint is you'll have someone who has seen an hour and they'll spend forty five minutes of the hour presenting a pack and you've got a bunch of questions for each of each of the pages, so you can stop and ask questions, and often you don't get to a really clean endpoint because you're debating different things
and it leads a lot to interpretation. So often find that you just don't get as cleaner an outcome, which means it actually takes a lot longer because you're reving through things a lot more. That doesn't seem to happen as much.
Yeah, I do like the fact that it really takes out a lot of the biases that you know, if you've got the gift of the gab, you can sell moost things through a PowerPoint deck and the reverse is true. But also I like the fact that the ratios of consuming information versus talking about the information is really different here because You're not just like in passive mode listening
to a PowerPoint presentation. You're actively reading and processing something that must make for a very different quality of discussions.
I think, so, yeah, invariably it does.
I want to ask about the PRFAQ, which, from what I understand, is Amazon's version of a minimum viable product.
Well, probably not. I'd say it's a precursor to a minimum as we would call a lovable product as opposed a viable product. So invariably it goes back to our leadership principle, right, which is that everything we do starts with the customer and works backwards. And so one of the mechanisms we use to underpin that is the PRFAQ.
So what does that look like?
So essentially what happens is that we have a process. We call it a working backwards process clearly, and the idea is that it's working backwards from the customer. There's a set of questions. Your listeners won't be able to see these questions, but I'm just funking security on my security tag, and there's five questions. If you want to look at those and.
Can I read these out?
I can?
So the working backwards questions, who is the customer? What is the customer problem or opportunity? Is the most important customer benefit? Clear, how do you know what customers need or want? What does the customer experience look like? That's cool? And this is like a little laminated card that you've got attached to your Curity neckcloud.
And the reason it's called the working backwards process is because everything we do starts with a customer and works backwards. Now, the first step is to say, all right, well, how do I know that this is useful for the customer? And so our way of doing that is to write a press release. And what we do is we write a press release at some point in the future about
this particular service or product or initiative. And the reason we do that is and we tend to have fictitious quotes from potential customers and other people, and we're trying to apply a test that says, how do we know that this particular thing that we're proposing to do is really going to have impact for our customer? Because you can build a whole lot of things and then find you've gotten to the end of a process and go, well, you know that really just didn't add a whole lot
of values. So the pifique is our tool to do that. And so what happens is you start drafting these press releases and it really helps you to think about them in with the customer in mind, because you're saying, it's total point of reference is whether this will create value, will be useful, or be valuable. And the quotes help you because you're actually saying, well, how will this person consume this and what would their reaction be to this
particular thing. So that's the press release. Now the FAQ is kind of interesting because what you then do is you think up a whole series of frequently asked questions, and typically they're grouped into sort of outward facing questions. You know, it might be how would we think about pricing this? You know, all of the things you could otherwise think of, and you know, internal questions like maybe
an investment type conversation, those sorts of things. And what we try to do is apply a test that says, look, how do we think We try to come up with the hardest possible question. So again we're trying to use a forcing function that says, look, let's have considered as much about this problem as we possibly can through these FAQs, and again it's just a forcing function to do that
planning and assuming. And what tends to happen is these power of FAQs tend to iterate a lot and if you get to a good answer, then you go into your sort of MLP type phase where you're starting to build a prototype and getting this thing built. But everything starts there. There's nothing significant that we do that doesn't have a paer FAQ. And often what happens is you'll get to a certain point in the life cycle of
this thing. Because I'm using the word thing because it could be a product or a service, it could also be a project, it could be a whole after things, and your reference back to the PERCQ going well, you know what do we envisage this would look like? And you know how do we track back against that? So it's quite a useful mechanism.
That's fascinating. What percentage of ideas get past the PRFIQ stage?
I would say a lot. And the reason I would say a lot is because we don't have a defined process for ideation and investment. There's no investment committee, there's no clear path. And that's pretty intentional because you know, you don't know where an idea is going to come from, and so you don't necessarily want to preordain you know, how to get an idea. So we have this management I guess philosophy, this idea of the organizational Yes, have you heard about that context?
I don't think I have nice.
So what we think, particularly for people leaders, as we try to think of our role as to find a way to yes. So rather than you go into a lot of meetings and people think it's their job to say no, really, my job is if someone's brought me a proposal, is to try to work out how to get it to yes. And so in many cases, what happens with a per FAQ is it iterates, which is, look, oh, you know, maybe you should think about A, or you think about B, and look, why don't you go to
have a conversation with person over there? And you know, I'm not sure this is quite ready, but like I think, if you think about A, B and C, you know we can get it there. So often what happens is the per of FAQ becomes a tool to help with the process of iteration. So the reason I say most is because if you've got a fundamentally good idea that holds water in the context of creating value for customer. Then most of what we're trying to do is work
out how to get it executed. Now, in some cases that could be really quick and really easily easy, and the process enables that. In other cases, though, it'll take a lot of iteration to get to a point where we go, Okay, good, let's move, you know, And so most of the time you're really working towards yes as opposed to a killing idea and saying no.
I love that. Yeah, working towards yeah, getting to a yes. That's so different to how most people operate because no makes you sound smart generally because you you know, it's funny.
It's easy to say no. It's a lot harder to say yes.
Yeah, Absolutely, I love that. My final question for you, Paul is how can people find out more about you and Amazon Web Services and by what you're doing? Like, where where can people go to find out more?
Thank you? Well, look, I really appreciate this opportunity because you know, fundamentally, the thing that enables us to be successful for customers in the fullness of time is being able to attract great quality of people who have awesome careers here, so you know, it's fun to be able to talk about our culture and hopefully you know, people see it as being interesting and you know context around
where they can do great work. And you know, we've got lots of lots and lots of roles open in Australia and New Zealand today, so always looking for great people. You can go on to our website. You know, I'd love it if you're based in Sydney or Auckland. We have made your customer events each year. Our summer he's in April, about thirty thousand people are expected at the International Convention Center in Sydney, and we'll have a similar one in Auckland i think in the June July time frame,
and we have a whole lot of events. You know, if you're a developer, we have big developer days through the year, so i'd encourage you to come to any one of our events as well. And you know we often have meetups and our partners have meetups, so there's many different ways you can you can come and meet our team and get us sense of the work that we're doing and hopefully the work that you might do. If you chose to come and work with us.
That's awesome. And we'll link to the career's page in the show notes and also just the events page as well, so I people want to find out more, we'll put those in the show notes. Paul, it has been an absolute delight and just fascinating hearing how Amazon works. So thank you so much for your time.
It's a pleasure. Thank you really appreciate it.
Hey, there, that is for today's show. If you like this episode, why not share it with someone else that you think could benefit from it. I just thought there were so many great tips that Paul shared that so many organizations and leaders could benefit from knowing and maybe trialing out at their organization. So that is it for today's show and I will see you next time.