was something called the Megadeals, which was our agreements with the major search engines of the time to have ads placed and search results. This was a big deal and these were altavista, yahoo and A. O. L. To try to get us traffic.

Hi, I'm dave chappelle and I'd like to welcome you to the invent like an owner podcast where I talk with the amazonians who helped build amazon dot com into one of the world's most valuable companies. This weekly podcast is for entrepreneurs, future business leaders and all students of history and not to mention some people who might want to get a job at amazon. The goal of the podcast is to capture amazon creation stories and create a historical archive. On that note, my guests are recalling history as best they can. It's possible some of the details are fuzzy or just plain wrong. If that happens, it isn't intentional and I invite future guests or commenters on the web site to help us get the facts as straight as they can be now on with the show. Today, I'm excited to be talking with kim rock Miller, Worked at Amazon for more than 10 years from 1997 to 2007, and lead teams, including retail systems, worldwide customer service and personalization, among many others.

And amongst early amazonians, kim epitomized ownership, getting things done and innovation all while emphasizing kindness, which was necessary in some of those stressful big meeting rooms. Along the way. Today, we're gonna be talking in depth about the processes that kim and her team put in place in the early days to increase the effectiveness, repeatability, if that's a word, and quality of those early release cycles. And I'm sure we'll bounce around some other topics to for the listeners out there, you'll hear a lot about the precursors to modern software development approaches things like continuous builds, for example, and what pre deceived them. Well, it's slightly technical, I think even nontechnical listeners will learn a lot about how large scale websites are developed because this is not amazon specific and we'll have kim's take on that. So welcome, kim.

Thank you. Dave, glad to be here.

I mentioned that you started in 1997. It was a year before me, but maybe gives listeners some background of what you did or where you were before Amazon. And what attracted you to Amazon at the time? Was it a person? Was it did you know about the company? What is it that dislodged you from what you were doing before

Your so this was the very early days of a lot of things. It was 1997, I was in a tiny startup in the bay area. We were trying to do java-based apps for small businesses, phone tools, calendar, and scheduling, carpools, things like that. And you know, we weren't exactly blowing it out of the water so the corporate checking account was going to change change and we were looking for additional investments. We were looking for mergers acquisitions. We were looking for jobs as individuals all the while trying to finish our product. And one of the folks who work for me said who had sent her resume to everybody she had ever known said that you should send your resume to my old boss, Joel. And it turns out that not only had she worked for Joel, but my co founder Scotty had also worked for Joel when they were an Apple.

This was Joel Spiegel and he had left Apple to work for Microsoft, but five months earlier had left Microsoft to join this little tiny startup. And the only thing I knew about amazon was that they sold books and had door desks and that was it. So meanwhile I had other stuff to do, like trying to save this this little company. But I sent my resume up to Joel and turns out Microsoft offered to buy us, not really because they were interested in our product, but because they wanted a six pack of engineers to dump into a project they had going but they were going to invite us up and so you know what, I think I'm gonna be up there anyway, take an extra day talked to this guy, Joel. So I had breakfast with Joel interviewed at amazon the next day following Wednesday. This was a friday following Wednesday I had an offer and 10 days later I was working at Amazon and nobody was more surprised than I

was. Did your coworker joined you to just to work with

Joel? Yes, she did. She joined slightly after I did. And Joel and I both put the hard press on her. This was Erica lock,

you know Erica, That's great. And the funny thing is I'm talking to Joel on saturday. So this is almost a perfect segue. I had no idea for instance that Joel was the person that recruited you in. Do you remember the interview were their interview loops then? Or was it

one or two people? Yes, absolutely. There were and I remember a fair amount of it. I had a breakfast meeting with Joel first just to see if there was any interest. And he asked, you know what three things do you need in order to launch something? And I was like, well you need to know what you're trying to build also features. Yeah, what else? He said you need to know if there are any hard deadlines that are driving it. What else? And I was like, you know the angel on my shoulder said resources, you have to know if you have the people in the material.

I'm tingling right now because this is what I wrote down on a post. It before this started. I don't know if you can see this, but you were the person that told me a long time ago with the program manager's job is managing resources time and scope. And if you want to move, you know the deadline or you want you either throw more resources at it, you give it more time or you know, change the feature set. It's just funny. It's one of those things I remembered from a long time ago and I jotted it down before we started.

It's one of the magic triples. And if I had not pulled resources out of the depths of my mind, I would not be working at amazon. So it turns out that basically what happened was my friends vouched for Joel and they also vouch for me to Joel. And so that was a big part of my getting the impetus to join because I was looking for somebody who would invest in me, who would help me grow as a leader. And Joel was somebody who had that reputation and so I was willing to basically throw over everything for that shot. I didn't believe that amazon was going to be world beating. I had just crashed the startup. Okay. I used those stock options to paper a bathroom that wasn't what was driving me. And in addition Microsoft did offer to buy the company and the hiring bonus was larger than usual because it was a company. And so I turned down four times as much cash to join amazon as Microsoft because

as a Joel, he's a convincing

guy. Yes, he is. Uh And boy that decision worked out because Joel really was everything that my friend said

that he was. So you were reporting to Joel? I'm assuming like was there a list of things a mile long? Was there like kim we need you in your first six months. These are our biggest problems like who are your co workers.

So Joel hired me as the group program manager for engineering and group program manager meant that I was going to be leading other technical program managers but there weren't any. So that was basically me. So I was doing technical program management while hiring a team to do that as well. Which was really amusing because I had never been a TPM before and had never worked with one. So I was having to figure out, you know, pretty much on the fly what that

meant and what was amazon needing at the time because they probably had a bunch of engineers. You were a former engineer,

right? Yes, yes. I had been a software developer for you no more than a decade and I was doing project management, team management and my startup, but I had never, never worked with TPM s and so Joel had an Apple where they were very product focus and he had also worked with them at Microsoft where they were more technically focused and he thought a blend of those would be great. While I was like super, let's see if we can be useful in making the project teams successful, delivering project management delivers. That was the motto. And so we went about trying to do that. It was a lot of feeling your way, trying to figure out what was going on and how to make it go on better. Uh first week I was at the company, I was just wandering around the halls and I'm going, Where did they keep the adults?

You know, it was one of the oldest people there and I was 36. It was a bunch of very young folks. And so what we decided to do was to take the lightest touch possible because people were just going all out all the time and you really didn't want to do anything that was too heavy handed, it wasn't going to go over well and it wasn't going to be useful. So I would tell people I want more methodology, but with a lower case m You know, I so 9000 when you were

hired, Was it a Kim? We need to standardize some processes because things like were they looking three months out or 15 months out and saying this is going to break badly. And so were you tasked with two or three big things to try to wrangle or you know, how did you decide on this first view?

I was tasked with a couple things and basically there was only one of me at the time. So it was only the things that were most critical to the company's success that got any of my attention. So the thing that I was trying to help shepherd in the summertime was something called the Megadeals, which was our agreements with the major search engines of the time to have ads placed in search results. This was a big deal and these were altavista and yahoo and A. O. L. And each one of these agreements had been handcrafted by the business development team try to get us traffic because it wasn't obvious how you

would do that. It's a really awesome story too because you and I both remember the BD team went out and essentially locked up the, you know, it's almost like the anchor tenant in the mall, you know, for the Ol altavista, Excite Yahoo and they locked those all up in those first few years as a way to accumulate customers if you will and to your point your team had to, our teams that you helped work with had to make all of those relationships

work well. We were doing things that people have not done before. This was not something that even the search engine must have done before. So we were figuring out how these things would get displayed how the information will be given back and forth. Then, you know, we were running experiments on wasn't doing anything for us. It was also a really fun conversation that I had with the head of business development when I explained to him that because of the way the deals were structured, the potential to be orders where we would owe money to all three of the search engines. That was fun. So

is that because of cookie traffic from all three were recorded and we had to then pick priority.

The basics are we were paying the different search engines for different things and you could sign up to pay. For example, if somebody came to us from one search engine and it was the first time they had ever come to amazon, we would be paying them for a new customer. But if they came, same customer came to us on the same order From another search engine, put another item into the cart, we would owe them for that. And if they came from another search engine within 30 minutes and put another item in the cart, we would owe them for that.

So for the listeners, this is like the precursor to what our affiliate programs. Right? And then figuring that out like people don't think about that. But when you come to amazon through a link and you put something in your cart, the person who sent that traffic or the website that sent that traffic gets compensated for everything you put in your cart let's say. And did the work you did on those beady deals? Did that translate into the amazon Associates affiliate program or were those developed separately?

Those were developed separately. But people from my team ended up getting assigned to the Associates program again to help them develop that

more extensively. Those names well

known or uh yeah the TPM assigned associates was Colin briar.

Well yeah I'll be talking to calm Colin just wrote a book called working backwards. So you know he's a long and distinguished career there. I didn't know that. That's another interesting one. I was wondering when you were telling me your background earlier if you came from the same company that Colin and charlie Bell came from? If I thought you were gonna tell me that too. So that's a different story altogether.

No that was that was S. T. G. And uh no I was not part of that company. Right. But I was really glad we made the acquisition. That was very much a aqua hire.

And so after the B. D. Deals you were talking before about some of the automation projects, did one of these roll into the next because you're working on the B. D. Problem and then you're seeing so we have this other thing that's starting to create issues Or did you just own everything?

The other thing that was going on that summer was something called V3 which was the third release of the website. We were numbering them back then and that was going to be launched towards the end of September. And it was a lot of things were involved. We were changing the navigation on the website, we were adding features like oh I don't know one click. We were changing the underlying architecture of the hardware and the software for launching and all of these things were going on simultaneously just trying to get a handle on it and make sure that it would launch. And it was in the process of trying to do these things while these other things were going on that we started implementing some simple changes to the software development process to try to rationalize what was going on at the time I arrived in order to launch something to the world, basically anyone would compile the single, execute Herbal. That was the website and put it out on the single server that we had. And that was how you launch something, you know, which wasn't exactly well controlled. It's

just working in production

kind of sort of, so not thrilled by that. Not to mention that if you really needed to roll something out, it might take a while to get a good bill together because other people would have been checking things in and maybe they didn't compile immediately. And so that was a bit distressing.

Did this manifest in problems or did you and other people at the company like Joel and shell know that it was going to become a big problem or was

it both? It was hard not to notice. Right. Everybody carried a pager. We would get bug reports. I'm Jeff's mom, Which you would notice things had gone wrong. So yeah, it was highly visible. That were, could be improved now. Also recognized a couple of things. Okay. In the middle of 97 there was maybe 35 people in engineering. Okay. This is a very small group of people doing everything right, Everything from the back end and the warehouse management systems and the credit card management,

customer service

and customer service tools, everything,

catalog inventory like just massive

all of it. Okay. So there wasn't a lot of spare cycles And in addition, prior to my joining and this is not something I have personal experience with. But basically the website was growing 30 a month, every month for the 1st 18 months the company was in business and so everybody was scrambling just to keep the lights

on. Can you explain to break that down into? Obviously it's exponential growth. But what are some examples for people that aren't engineers the types of problems, but that Leads to because obviously Facebook had to deal with it in a different era and other companies, lots of companies have to write. But like especially back then, what types of problems did 30 month over month growth basically forever. What kind of problems did that create for even world class engineers to

deal with? Well when you don't have the capacity to deal with the things you have to do things slow down or people can't access the website. So it's like having an actual store and somebody coming to the door and the door is locked and they're beating on the door saying let me in, I want to buy things and inside you're running around juggling eggs saying go away. I can't deal with you right

now. So it could be both not enough hardware or inefficient software running on that hardware that needs to be able to cue up orders faster or because the bottle that could be anywhere right. It could be in credit card processing, it could be in catalog speed, anything.

Yes there could be a lot of things and as you solve one of those issues it flows downstream to the next place that is not able to deal with that load. And prior to my joining. What they had done was purchased two very large deck machines and they had one that was serving the website and one that was dealing with the database. Again, the website was a single executed. All the database was a single database and these the database for example, ran everything. It ran the website, it ran the warehouses and customer service. It ran financial reporting. It ran everything. And what they did was they bought one of these machines where you could slot in additional pieces of hardware to give it more capacity. And so as we would start running too hot we would buy in another another back plane and and shove it into the machine. But that was we were running out of slots because the machine just wouldn't expand indefinitely. And so one of the things that we were doing for this V3 release was changing from having a single front end server to having multiple front end servers. And this was a big, big deal because once you had multiple servers, it was going to open up a lot of things. Number one, you could take a server down in order to do maintenance or

other kind of grades grades

to it and the entire website would not go down worldwide. That would be a good thing. In addition, if you could have multiple machines on the front end, you could add another one and get incrementally more capacity. That's a very good thing. So this major architectural change was going on at the same time that we were going to be doing changes to the website and the way it worked that customers would see

was also part of it. The advantage of having multiple front end servers that you could roll out new, is this the first instance of rolling out new versions of the website by just taking a few down, updating them and then putting them live and then taking the other ones down and updating those, you know what I mean? So that you could push out changes without disrupting because I remember in the early days, we used to basically, we're closed for maintenance sort of a page while we made changes, which is still pretty common with smaller

websites. Yeah, so that's the beginnings of being able to do that. One of the things that we implemented as part of this change to multiple servers was having something we called Master, which was the ability to push a new build out to a master machine that internal people would have access to, but external people would not. And so we will be able to what was called baking on Master, where we would beat on it and place orders internally and see whether it was doing what we thought it should do prior to putting it out. Such that the outside world.

You mentioned in V 31 click and you mentioned a lot of this back end items. But what was the impetus of the change of navigation? And why was that such a big deal? Not just for consumers or you know, shopping customers, but why was it a big deal for the website itself? And maybe like where did it come from? Like what led to it?

So I wasn't as involved with the change to navigation, but basically it was the beginnings of starting to move to a tabbed navigation system. It wasn't tapped, but it was the beginnings of thinking about the top knave bar as being significant to how customers would wander around the site. There was the ability to highlight different activities, different kinds of things that would be coming down the road. So for instance the release that would be coming up the following november was going to include gift certificate and we would be able to highlight that offering in the navigation work.

Yeah, it was a big deal. I mean not just the like I remember I joined in 98 and worked on the music and the video store. So we were building on the work that your teams did and I was totally oblivious to it. But I do also remember things like the gift certificates were huge, right last minute purchases and then that 98 Christmas I think we added our first like gift store. You know, we're we were going out and buying digital cameras and you know, I don't even know what, what was current at that time, but that basically all built on that. And what was the big change to the website or the code that was needed to accommodate different categories.

Okay, so a different categories comes later. So we are skipping ahead now. Music Launched in May of 98.

I'm sorry, I didn't actually even mean that I was thinking of navigation as categories I think when you're saying but the change in the navigation, it wasn't necessarily category

specific. No, it wasn't very specific at that point. Again, this is very, very long time ago and this is 97 and the only thing we were selling was books. So nobody was really thinking, well I won't say nobody because at least one person, the company was thinking about four categories than that. But we were basically thinking about how to sell books better and faster and how to survive with respect to again, how to survive. We were very, very seasonal. We were focused on christmas even though we weren't seasonal at the time because we were growing too fast between christmas 96 christmas 97. Our traffic slash revenue was I believe eight X. So you had to be prepared

for extremes and really the extremes, they're the same thing we were talking about earlier. It's every single system, the bottleneck can appear somewhere. So the catalog team, the search team, the every team had to basically simulate what happens if we're 10 X or 15 X and will it still keep working and trade off over investment versus, you know, capabilities.

Right. And this was something that you had to project as the engineering team where resources were going to be needed because everybody was running very, very lean and you didn't know really ahead of time whether it was going to be supply chain or catalog or site navigation or search or what have you, where the bottleneck was. And so we would move people around as we saw a need for scaling or for launch or what happened. And that was something that led to the concept of fungible engineers, the idea that we would be working in the same language across all of the software and be using the same operating systems so that people could do that more easily and could help out and could contribute in multiple teams. This has as you can imagine, a good and bad effects.

So when you got there, would you say that again? It was 1997. So was it a state of the art for current entrepreneurs? Would you say it was closer to minimum viable product? You know, the whole M. V. P. Thing, Get something out there? Or is it really sort of on the other end of the spectrum given 1997 like quality of the team? Like where was it on that spectrum? Was it pretty complex at that time even?

Okay, it was not state of the art. I had come from silicon graphics for example, I've worked there and frankly, software development and engineering challenges were more challenging from an engineering perspective than what was happening in the amazon. Amazon is basically a database and website. So as far as engineering goes, there were some interesting challenges with respect to again, keeping up with scale. But you know, that wasn't really that compelling for engineers at the time.

Yeah, because they look at and say, well, that's just that simple problem there. I want to work on this big, mathematically challenging algorithm over here. And so you had to convince them partially that hey, you're going to be part of creating something incredible.

Yeah, we had no problem recruiting NBS. We had some problems recruiting kitchen ears,

right? I'm going to come right back to that. So before we're talking about some of the other things your teams put in place, like nightly builds code reviews because that's all basically impacts all of these things we're talking about. Can you talk about some of the biggest changes that you and your team or the team? No one wants to take credit for any of these things, like, but the things that you worked on with the team to improve the productivity, let's say, of the engineering organization, because at that point let's like mostly was engineer driven, like there's plenty of B D and plenty of product management, everything else, but it was very much an engineering problem for a long time,

correct? Yes. So we tried to do things that would not be burdensome to people, but that would have impact in trying to make things work better is the best way to describe it. And so, for example, code reviews, we were seeing things that were causing bugs that were too obvious that if anybody had taken another look at it, it would have jumped out at them that it was an issue. So we implemented code reviews and what it said was when you do a check in, you need to include the name of the person who looked at it. Somebody besides yourself who took a look at this code, include that name in the check in notes, that's

it. So they were then responsible as well. They were

something useful as well. Exactly. We didn't say you had to check off these things, You had to look for these kinds of issues. No formal mechanism. Nothing just has anyone else looked at this code besides you?

We're code reviews a new thing at that point or with a common industry wide and they just weren't being done at amazon because you guys were running so fast.

Yeah, it's not like we invented. Right, Okay. But there was there were people who recommended certain outside methodologies again, in terms of what made it good or bad code view and we were like, no, we are not going to go there, we're not going to be so prescriptive, but we are going to say, you know, another set of eyes who would be useful do that. And the way that got implemented was Joel, who was the VP of engineering at the time said thou shalt. And I started looking at every code check in to see whether the name was there and if the name wasn't there, I got to send a note saying, where's the name? And so over time that started to become ingrained in the culture, that's

how that happened. I had one side question, why did you decide to switch from being an engineer to being a TPM? I wanted to ask that for a long time before I did the little research getting ready for today. I actually didn't know you were an engineer before. So had you already made that transition after you left HP and S. G. I to the startup that you were at or was amazon really a brand new career for you?

I had wanted to go into management for a long time, but I couldn't find anybody who was willing to give me that opportunity until I left S. G. I. And became a team manager for a little startup, basically, I need to define somebody who's need was greater than their fear. And I found that and it was only because I had taken the risk of joining a startup and because people that he knew vouched for me that Joel was interested in taking me on. So it was something that I felt was a better fit from my particular skill set than continuing to be an individual contributor.

I'm kind of emotional here, because like I was an accountant before amazon hire me, you know, like it was partially Warton that helped that transition, but it's the same thing, it's like people like Joel and Andy who took a flyer, you know, based on having some shared connections and all that sort of thing. But it was a big transition that I probably couldn't have made going to a Microsoft, but a young upstart company was willing to take the risk a little bit more. And so in any case, it's, it's really interesting to hear that because I never knew any of that before.

It was of course helpful that I was a pretty decent engineer because that helped me make better decisions. It helped me communicate better with the engineering teams. It helped me in a lot of ways, but it seems pretty clear that my destiny in life was not to be softly.

One of the other things you mentioned was nightly builds was a new thing. Can you explain again? Got to give listeners the context of 1997 versus now, like why that was a big deal and sort of how that's evolved over the years and what your team's role, wasn't it?

So let's talk a little bit about what a software applications, so a software application is something where you take a bunch of code and you compile it into an execute able and the execute Herbal is what you hand over to the operating system to say, hey, why don't you run this? And it will do things like communicate with the user. So at amazon, the thing that we were building was a website and it was a single execute Herbal that would perform all the functions that you saw on the website, from presenting a page to doing a search to taking your credit card, all that. And it was happening in a single execute Herbal. So all of the code that any of our developers were writing that had anything to do with the website, All got compiled into this one, executed. So this is thousands and thousands and thousands of lines of code in different files, all of which have to come together and get organized into a single excusable. And what that meant was if somebody was working on a piece of code and they would do a little work on it and save it away, but maybe it wasn't quite ready for prime time.

It might not compiled, there might be syntax errors in it. And what that meant is that if anyone anywhere in the organization had done that the overall execute Herbal couldn't be built and this was a problem because you never want to be in a situation where a failure or a mistake by an individual stops the entire train. And so what we were doing was trying to build the execute Herbal every night so that we would find these kinds of things before. We absolutely needed to do something that was critical.

Just a constantly rolling of checking, testing, releasing on the

nightly build. We didn't get to that point of like a daily release for a long time. But a nightly build would allow you to spot these kinds of pedestrian problems well in advance. And the discipline of habit. A build available at all times was useful because it meant that people were paying more attention to that kind of capability

and that was then manifest itself in Master and then QA would pound on Master and everybody would pound

on Master. It would enable a lot of things, I guess the best way. But it's certainly not the be all end. All. What you're trying to do is you're trying to think about ways to make it be possible to move fast. So once you have this concept of a nightly build, then you can have a concept of a continuous ball and then you can notice maybe it shouldn't be a single executed. Maybe we should have pull that apart. Such that if there's a problem with search, it doesn't mean that other forms of navigation are broken as well. And so you start pulling and teasing out these elements that used to be all better treatment.

What's that referred to now? Because now there isn't a single execute herbal, what would people refer to or how would they refer to that? Or think about that now for engineers coming out and joining companies.

So the end stage of that is something called a service oriented architecture. And this is the idea that individual functions of the website are their own service and that other elements that are performing functions call on that service to provide that ability to either a subsection or a piece of the website. So what that means is you have a whole lot of independently running elements that combine to create capabilities that you can then use in a lot of different ways.

Is it fair to say that that's the precursor of amazon web services without diving down that rat hole for now, I'm sure we'll talk to people, but is that the precursor of AWS sort of separating all these services if you will

find them? Certainly, the concept is critical because amazon Web services is from its very beginnings, the notion that you are delivering small pieces of capability that can be combined in different ways, but it's not the case that the services that we pulled out got deployed as amazon

web service. Yeah, I get it. So basically the big thing here is a service oriented architecture and I'm assuming again, amazon wasn't the first to do this, but it was maybe one of the first to apply it to large scale e commerce and I'm assuming the primary driver of that was scaling or reliability or

everything, all of those things because you get a lot of benefits from doing that approach in particular, it speaks to some of the core values that we had at amazon from the very early days, for example, ownership, if you have a small piece a service that you are providing and you own that service and how it performs and the capabilities that it provides and you own its support and its maintenance and its code

and its metrics and its value, all of those,

it's yours and you can see your contribution and if you execute some bias for action and do something interesting with it, then you can see what it does for customers. And so all of those things are enhanced by teasing these things apart. You know, it's hard to say I own the amazon website. Yeah, but it's a lot easier to say I own search.

It is something I liked like when I joined and I'm sure it's changed now. It's been forever ago, but it was really impactful. Remember the just do it awards where people would get basically a sneaker, a Nike sneaker, maybe they got bronze now, but it was really cool. Not that they gave them out to employees who did things. It was that it didn't need to succeed. It just needed to be a big audacious thing to benefit customers, but it didn't necessarily have to work. Do you remember where that

came from? I remember vividly. So there was an all hands meeting where Jeff announced the just do it award as a mechanism to embed the value of bias for action in the company, Jeff was very concerned that we would become bureaucratic and high bound and like some of the banks he had worked with prior to amazon and so he wanted everyone to be thinking all the time about how they could do things better and do things for customers. And so the idea behind this just do it award was that as long as you had used good judgment and had not asked for permission, then you were eligible for this war. I personally was freaking horrified at this idea because the last thing I as somebody who was trying to organise and coordinate and make things happen in a predictable way in the engineering thing, the last thing I wanted was people randomly running around doing shit. Okay. That was not a happy announcement from my

perspective. Do you remember who got the first one? And then secondly, did you change your opinion about it at all? Or do you still feel that same disagreement with it?

I do not recall a just do it award that. Did something tremendously wonderful for the company or for customers? No, that's not. That didn't happen. But I just can't bring one to mind. The best thing that I can say is that amazon put mechanisms in place to make their values real and that is important. The amazon values there were six when I joined customer obsession, bias for action, ownership, innovation, high hiring

bar frugality.

Thank you. Your desks or death or desko work. Those things had concrete elements to them and in that I thought was magnificent. Whether or not the individual shoe represented something that I wanted. They're

not all good ideas, but I did like that. It made it like real or it is. I get as especially you, I'm sorry. You're like in my mind the world's greatest program manager or technical program manager, but like it's almost like the exact opposite of what you want is people going out. And so I get that. But at the same time at most places, people just aren't encouraged to have a bias for action. And so there's a happy medium in between those two things that I think largely they accommodated. But most companies just never say go try things, you know what I mean? They go get permission and get another permission and another permission. And and that's what Jeff was probably protecting against becoming a bank

like that. Yeah. And I've got a great story actually where Joel plays a significant role around again bias for action And I didn't really think about it in these terms before. But so we're trying to get V3 out and we're trying to move to multiple servers. And so those servers were being delivered to the company and after they were delivered, they would need to sit around for three days to a call me because you don't want to unbox a server and plug it in and fired up because you can run into issues around, you know, condensation, right humidity plus

you wanted to get to know the other servers,

you know? So anyway, so we were in an everyday counts situation and I was talking to the folks in our system network operations center and one of them said to me, well, you know, I could get these for us three days sooner If we paid for expedited shipping. But that was going to cost $3,000 and I didn't blink. I said you do that because I wanted those three days. And so that meant that they were going to be delivered on saturday morning of labor day weekend. But anyway, I desperately wanted that to happen because three days is three days and you know when you're gonna launch towards the end of september these are pretty critical days. So I said do it and I went back and I was having my one on one with Joel and I said oh by the way, I just told me it was brian and uh it's not that he should spend three grand to get those three days. And joe looked at me and he said, let me shake

your hand. That's right

because he wanted people like me out there making decisions to push things forward. Now, what I did not know at the time was that Joel as a VP of engineering at amazon dot com, the world's preeminent e commerce bookseller, Joel Spiegel at that time had 50 bucks in signing

authority. I knew you were going to go to the signing authority because because you know Jeff wouldn't care either. So

so not only did I not have the authority to tell somebody to spend $3000 Joel didn't have the signing authority and tell somebody spend through. And he went to joy Kobe our CFO at the time to make that happen. But he didn't fill me in on it because he didn't want me hesitating to do those kinds of things and that is how you make your values real because that previous companies I would have gotten chewed out

for that. Now I know there's like 1000 of these, I spoke to Joel just randomly and we spent like Joel, I just wanted to talk about the idea like it was like 45 minutes in and like joe we gotta hang up and record this at some point because he, you know, he's very incredibly mission driven, like, again, he was one of those people that believed in me way more than deserved and really impacted my life in a lot

of ways. I was walking with Joel to our one on one and this is about three weeks after I joined and he said, so how's it going? And what do you think? And I chose my words very carefully. I said I'm even more impressed with the facade than I was when I joined because you know, it was the duck paddling like hell beneath the water, but nobody saw that and I myself, I wasn't surfing the wave but I wasn't drowning

either. Were there any big mistakes that you look at in hindsight? And again, we all have them. But like one thing that steps out and say if I had done that differently and this is more about telling other people, you know, like was it too much control? Too little control? Like something that comes to mind from that first six months

of year. This is hard because it's hard to say we would have succeeded without it, but I kind of feel bad the extent to which I promoted the work insane FFS because I did, I had a hard time paying my bills, not because I didn't have the money, it's because I didn't have the time to pay them. I was working 7:30 AM to 7:30 PM at the office. I

know it's

a little, it was a little nuts. It was totally insane, you know? And who knows if everybody hadn't been doing that, would we have succeeded? I don't know, but I don't think it

was healthy. It wasn't healthy. But again, you and I have both had similar difficult startup experiences and you were an investor in mind, like you get a lot more humble, you know, you get a lot more humble when you've tried to do it and you see what it takes and not just as people, it's just luck and effort and maybe it would have succeeded without the effort, but but I'll bet on the effort. I don't necessarily want to sign myself up for it again, but, you know, I don't regret having having done it, you know, so, one other question before you get to the end. So when you step back from it,

and let's say you squint, you know, at all of the things like when you talk with current entrepreneurs, What types of lessons do you think they should get out of? Because those problems you dealt with and the team dealt with, you know, in 1997 are there's new problems, but it's the same sort of approach to it. What would you tell to a young entrepreneur, you know, who's starting their company and running into their own bottleneck situations? What would you tell them?

I would say you need to focus on the right things, there's a lot of shiny objects out there and there's a lot of ways to get distracted, but as long as you are clear about what's really important to do and not, you'll be more likely to be successful. We came up with the idea, we, I came up the idea of launch requirements and I was very, very clear about what the definition of that was, which was you will not launch without this. And so that made people make hard decisions and when you are resource limited, you have to make hard decisions and you need to have help in focusing what will move you forward. I'm making those hard decisions.

Yeah, I remember I never heard the term brutal triage before coming to amazon and then you know you do learn it like there's the must haves and then there's the things we can do in a week and then a lot of those things we can do in a week you never do because the first stuff didn't work, you know what I mean? We're based on feedback, you go do other things and so yeah, it's like what do you actually need to do to get out the door with? And I thought we were going to have time to talk about all kinds of other projects, but I'll have to ask you to come back at some point. So you already mentioned Joel, who I'm talking to on saturday, who else is somebody that you think? I know you and I have spoken about one or two but like who would you like to hear from or hear some stories from that you think may not have the full

picture, you know, I don't think you could pull anybody off of the phone tool and talk to them and get something interesting from those days because everybody was contributing something important to the success of the company. That's the benefit of a small enterprise, is that everybody is doing something and has a perspective and something to share. So yeah, basically, if you could talk to them all, that would be great. I'll work on it. But you know, Joel and mariam and I was on a walk today with Greg

linden, I'm going to talk to Greg. Greg was not only good stories about him working on auctions, but also he had his own startup finery and he's done a lot of really interesting things over the years, so yeah, he's definitely high on the list. I can't wait to talk to him.

Yeah. Talk to Duane Bowman from Search anyway, like I said to all of them because they were all doing

great stuff. Yeah, I can't wait to have the story of the bottega boxes told because it was sort of a it was a term there and it probably took me three months at amazon to realize that it was Duane bowman, Ruben Ortega.

So

I mentioned to you on amazon, we always say every page has to sell, so on the post, we're gonna put up for this podcast. I wanted to ask if you had one or two products that you'd like to, I know you've become a semi professional baker

for for those

who aren't aware and we also share parentage of french bulldogs, but are there any products that you recommend that I throw

in there? Sure. So I'm on the board of a nonprofit called U. P. A. Social ventures. And what they do is invest in entrepreneurs in India right now who create jobs for the ultra poor. So basically pulling people out of poverty through dignified work and uh it's worth taking a look at some P A social ventures.

U P A Y A

P A Y A.

So kim thank you so much for being my first guest on the Invent like an owner podcast. I personally found it really interesting and I'm positive other people are going to as well. And in addition it's just always good to see you and to catch up for the audience. Thank you for listening to the event, like an ogre podcast, the number one first episode. Sorry, not the number one anything. If you'd like more details about what we discussed today or want to contact me with edits or to suggest future guests, topics, whatever. Please visit Invent like an owner dot com and sign up for the weekly newsletter and be sure to subscribe to the podcast to get all the future episodes. That's it for today and remember? No sniveling. Mm no. Mhm. Mhm.