linked to the new bundle and restart the web server processes, which would happen in just a few seconds. He types all that up but he doesn't press enter, then he takes the dog and we're all crying around, he holds the dog in front of him and he takes the little paw and like click Yeah pushes the it pushes the enter key. So Rufus

launched beside. Mhm. This episode is sponsored by Florio, founded by ex Amazonian. VJ. Ravindran Florio is the leading research back system using virtual reality to deliver immersive fun and affordable lessons for Children and adults with autism spectrum disorder. Special discounts are available for current amazon dot com, employees learn more at Florio tech dot com. That's F L o r e o t e c h dot com. Hi, I'm dave chappelle and I'd like to welcome you to the invent like an owner of 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, business leaders and all students of history. The goal of the podcast is to capture the 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. 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 Alex Settlement, who I remember is one of the nicest people at amazon. As you'll learn, Alex joined amazon, fresh out of college and was one of, if not the first full time front end web developers at the company. In fact, his first job title was html wizard. Alex is going to share what it was like being a 21 year old, telling older and more experienced coworkers what could and couldn't be done in html Given HTML limitations in 1997. And we'll also pass on advice to entrepreneurs who are working in new technologies where the tools are still very primitive. Welcome Alex,

thank you. Dave, you're far too kind, so happy to be, I'm so happy to be on the show and to have a chance to share some of my stories with everybody,

awesome. So what start at the beginning, it's always a good place to start. How did you get to amazon? You know what year? And you know, maybe give some of that background?

Right, so I was an English major at the University of Pennsylvania in the late 90s and the Internet was spreading very quickly, universities at that time. And actually, even though I wasn't an engineering major, my English department was very tech forward. They had their own unique server which was on the public internet. So I had an account on that server which gave me a sandbox to learn web programming. And by the time I was a senior at U PENn I had steady side work building websites for various university departments. So I cut my teeth building at the University of Pennsylvania's web presences across a few different departments.

Well, I was gonna say, I'm assuming that amazon wasn't actively recruiting on campus that early. Maybe they were, but I didn't think they were. So how did you find out about the opportunity at amazon in particular and and then also like what attracted you to amazon back then?

Yeah, they definitely weren't doing on campus recruiting, nothing organized like that. I got my amazon introduction via one of the professors who I worked for. James O'donnell is a classics professor and he was also vice provost for information systems at University of pennsylvania at the time. And so I worked for him doing different, different projects and he had previously taught at University of Washington In a previous year where he met Rebecca staff who was an early Amazon employee who at the time was studying for her library science degree. And so after the fact in the spring of 1997

who was Rebecca again, just to give context for listeners.

Rebecca staff all was on Marion mojito site development editorial team and was there earlier than me, but I can't remember exactly how much longer she had been there, but

prior to me. Okay.

So in the spring of 1997 Rebecca calls up professor O'donnell and says something to the effect of, hey, I'm looking for a book lover who was familiar with UNIX and knows how to make web pages and James said I have the man for you. So that's called being in the right place at the right time. And that was how I got my own screen, which led to my interview prior to the interview, I was already an amazon customer, so I was aware of them, but I wasn't thinking of them as a job opportunity per se. I had bought programming book and also a bunch of obscure out of print titles. So I was pretty familiar with sort of, uh, the long tail of amazon beyond just the bestseller lists. Uh, throughout the interviews, I was, I was definitely compelled by the idea of,

of bringing literacy and broad access to all kinds of books to all kinds of people. You know, to me, the idea of the long tail is very egalitarian, not just the bestseller list that someone has may be paid to be on or that, You know, a small number of bookstores have elected to carry. And so I like the idea that a customer could find something really great. It was very idealistic. I also liked that Amazon was taking the Internet seriously. You know, the idea of a catalog that had millions of titles was pretty bold and audacious in the late 90s. You know, I'm in the interview this whole interview day and I'm sort of silently incredulous the whole time because we're talking about all this stuff and I'm thinking they really want to pay me to make websites because I don't know, I mean to me, I knew the internet was growing academically,

but in a business sense, I didn't really have any idea. And frankly my other job prospects were looking kind of ho hum for me. I wasn't really a business type, but I figured, well I could probably monetize my hobby for a few years after college while I figured out what I really wanted to do. And also my Amazon offer included, among other things, a relocation bonus. So, you know, I'm 21 I think, hey, free cross country move. That was, that was my mindset at the time that I was interviewing at amazon.

You just said you liked that amazon was taking the web seriously. Can you just tell me what you mean by that? Our listeners, what you mean by that? Did you have a different sense of what the web could be? You know, versus maybe what mainstream did? Or was it just your initial reaction

to the team? My resume had at the time. A list of your legs that were the portfolio of the work I had done while in college, most of the university or else. So I understood that the web was growing. It was very valuable for at least an academic setting and for access and tooling, but I didn't have the sense that it was important for business. So there were really no other businesses that had online presences and it wasn't viewed as necessary to have any kind of online support for whatever your business did or municipal service or something like that. So the idea that this was a full time company where they only had an internet presence, you know, I thought was pretty out there and I was amazed that they even had enough work for me full time.

I know you also then said you were a technical higher but you weren't on the engineering team. How does that just for someone who doesn't really know how to think about that? You know, a listener, what was the distinction or you know, why would it matter

that sort of thing? Well, so kim and Joel, some of your previous guests have talked a lot about the engineering teams. Dwayne and Ruben were on the engineering team, I think Dwayne was Reuben's manager. Right. So there was a group of people who were actually building the website and the software every day and, you know, scrambling around trying to keep everything up and running. I was hired on to mariam Overheats site development and editorial team, which was not under the engineering organization. So I forget if I picked that job title or she picked it. Html wizard. But, you know, we kind of thought it was cute and the site obviously existed prior to my arrival, but I was the first specialist in UI and it was viewed as something that belonged with the home page and the staff who wrote reviews and not viewed as essential back end

engineering. And so when you were hired, I know you were in the low 100 employee count, what were you first task to do and maybe it was just get used to things. But like what was after that first to to answer what were your first has to do and what was like the first big thing you worked on, you know, to sort of really get not not your feet wet, but your whole body immersed in, uh, how things got done

underwater as a gasping for breath. Yeah, that's about right.

Yeah, that's right. Well, so yeah, it was

about 400 staff or so when I first started and that at the time, we just counted the warehouse employees and see us and everyone is staff. So that would be the whole Columbia building on Second Avenue plus the soda warehouse on fourth and Dawson. That was the company. When I started on my very first day, the other technical folks on Miriam's team walked me over to the crumpet shop in pike's market and uh, we had crumpets and they told me about, you know, how things work, how to organize things. Obviously the company just sold books back then. It was right there on the website amazon dot com books and it was very easy to pinpoint at that time where Jeff was in the building if he was in the building because of that iconic laugh.

Yeah. So

my first few project, we're just fixing bugs on the site while I learned how to work on an engineering team, I had never worked With other engineers before in the shared code base. So I had a lot of ramping up to do in those best practices and I was tutored in programming pretty much from the get go, but it wasn't long before I was pulled into my first big project, which was the V three launch.

So V three, When did that happen? And what was the a few people have mentioned it, this is probably the first time we go into detail about it, but like I'm assuming it was late in 97, but what were a couple of the big things that were

part of it? Yeah, so V3 was a site redesign, at least from my perspective it was I had my hands full doing that. We were introducing a new Nav bar site wide and several new features which I can talk a little bit about but I think we're going to launch in september october of 97. I know it was going to be before the holidays but also just as soon as possible. And so you know what was going on then is that our our product catalog was growing in size and we were growing in customers. But the way that almost all customers interacted with our site was they would come to the home page, they would do a search, they would hopefully add that book to their shopping cart, detail, page shopping cart by and then they would be gone and there's a catalogue grows. We wanted to make sure that we would wanted to find ways to expose the customers to the breadth and depth of our catalogue. So we built new UI features to try to expose those parts of the catalogue, namely browse browsing through lists of titles. By category, by taxonomic classification was A huge feature that we built. I believe we built it for V three.

I'm almost sure. So before V three, because everybody's mentioned browse and maybe just clarify for me the difference between browse and Nav just because there are some similarities. But did they not have categories of products before V. Three or how are the books organized or how did a customer if they weren't gonna search? Did they just find the ones that were on the homepage or you know, was there no browse hierarchy or taxonomy?

I mean I have these mock ups that I worked on with the designers in the summer where I was building browse template. So I know I don't think brown eyebrows existed before I came. And yeah, you could search there was some lists of the best seller lists and there were featured titles. So we had editors who were writing features about great new books that were coming out across different categories. But with with browse then we would have actual places for different genres. Science fiction over here, Romance over there. In fact we called them book rooms for a while. I was looking at my notes, we called them book rooms for a while. We didn't really know what to call these brows landing pages where we would introduce the genre or what was what was interesting in that category. And so it was also interesting because it was it was like this combination of our like book loving nursery meeting computer science graph theory. Because there's really thousands of ways you can organize titles and you could programming in a pretty dumb way that we need to program in a smart way so that it would go out on the site and scale. And at the time we weren't allowed to use relational databases for any of our content that that we wrote. So we had to find ways of building these, read only data caches and kind of crude files that we would push out in a bundle along with the software in order to make these features actually work on the website.

Can you just take a little detour there for a second and tell me why relational databases weren't an option at

that point? Well, I think KIM described it really well. We had two big servers. We had the web server and we had the database server. Two pieces of hardware wasn't yet a services based organization. So the database was plenty busy fulfilling orders, taking orders and storing critical customer information like credit cards. And there weren't enough, it was enough bandwidth between the web server and the database server to pull any kind of read only content like that. God, we didn't have enough memory on the web server to cash it. So we had to build files. It was part of this homegrown system that we've developed over the years.

You mentioned one other big part the navigation. So can you talk about maybe just quickly described? There was no navigation before because you just said it was just amazon books. So what was the big deal about adding navigation to the

website? Well, is even speaking about something more simple, like a knave bar on every page. The site was so crude back then it wasn't even didn't even have a consistent look and feel or nav bar across the top. And so we added features that would allow the customers to try new things. So we had browse for categories. We had best seller lists. We had award winning books. Oh yeah and the very first version of our recommendations system. We went through a lot of iterations on that. I know we lost something in V three that would recommend books to the customers and prior to that the site didn't really know anything about the customer. Right? You would just browse aside and it was just the same thing so you would have a shopping cart. But other than that there was no personalization of the site. Like not, certainly not. Compared to today.

Miriam, who headed your organization? She was a VPs site development. She mentioned that and I haven't spoken to her yet publicly. You know what we've been talking behind the scenes and she mentioned that instant recommendations were a big feature. S VP. David Risher wanted because it was something we could talk about to the press. You know that was easy to communicate. We can make recommendations based on your particular interest. Could do you remember was it fueled by did you have to indicate a bunch of books that you liked? Because if you were a brand new customer who hadn't purchased anything and hadn't really looked at much. Do you remember how that was powered?

Remember I have mock ups where I built a Ui around something that was just like that where the customer would basically fill out a quiz And we would figure out you know what kind of books that might be worth recommending to them. And that was the input to the recommendations engine. I don't remember if we actually launched with that one or something that was better and you know more passive based on the customer's behavior. We're talking 25 years ago here. So I don't really remember the details.

That's fine by the way. For listen, I'd love to get any screenshot copies you have and we can add it to the post. Like we did for Reuben had a ton of photos for his his episodes. It was fun to add all that. I mean you were 21 years old, you were new at the company. Tell me about what made the V three difficult maybe, you know, because I'm assuming people wanted it to look a certain way and act a certain way. You know, tell me how that was and what your reactions were to everything.

Yeah. I mean that's definitely where you know that metaphor being slightly underwater, you know, rings true for me because I had been building everything that html on the web could do for a few years. But when I worked on V three with the design team, you know these were designers who had 20 plus years of experience and they would deliver mock ups that were basically Photoshop style, static print style layouts with all the positions of all the elements fixed. And they were very rich with graphics and text interspersed.

They were used to designing for print publications, right? And yeah,

there was no such thing as a web designer back then. So we had hired other kinds of designers to do the work of designing for the web. And so here I am my job since I was a technical higher, my job was really sitting at the edges of the intersections between all these different disciplines, editorial design, marketing and to a certain extent the engineering the capabilities of the platform. So here I am 21 looking at these designs and thinking, wow, this is great, this is great, this looks awesome. I can't implement any of this. And then began a long series of back and forth where I would build what I could implement onto the on our development server and then the designer, we would have design reviews where they would look at what actually existed and they would mark it up and try to reclaim, you know, better control over the design and positioning. So I spent a lot of time in those early years, unfortunately apologizing for what html couldn't do and trying to negotiate what we could do with the tools that we had with the capability with the layout that we had. Um yeah in the browser,

I'm assuming everything with short staffed that's been the consistent theme of not only the first, all these conversations but also my years there. So how did that manifest itself? If you needed something done by a technical team or somebody in editorial, like you're on Miriam's team, that's a whole bunch of non technical people actually. And so how did that work with a big launch? Like a site redesign where you need some technical things done? Like were there any hacks you guys put together to to make yourselves more effective or more productive?

Yeah, I mean the engineer is basically built a basic template ng system for me to use which would allow me to build templates and this is all in a pre ph B world. They weren't the kind of web frameworks that there are today so that I could build templates and you is that I could launch without having to recompile the software and also these data cache files for ways we could add new features, new lists of things to the site without it being search or placing an order or any of these, any of the core functionality which the engineers worked on. And so in that sense, they were trying to enable more and more staff, technical staff like me and the un nontechnical staff who I supported to build more the site out with more stuff without everything having to go through, you know, Kim's engineering team because we knew that didn't scale

either. Was it Kim's team or was it somebody in your order that built like the tools for the editors to use to create reviews or to modify the content on the best seller page, You know what I mean? Or all of the category notes. You know, there's a history page, you want to have some history content and history bestsellers. So were those tools that were built for the editors done by somebody on in Merriam's or is or was that something done in conjunction with kim and the technical engineering

side of things? By and large? They were done by Miriam Zorg and you know, this this almost predicts a future where amazon has self sufficient teams that can do as much as possible to launch a new product or a new feature without having to work through centralized resource planning. So yeah, the other technical hires on Miriam's team and I built the tools for the editors to schedule and preview and launch content. Um and we kept on evolving those tools, you know, chipping away at them to make them a little bit sharper over the years to enable more feature development. We were also hiring up more staff at that time, not just technical, but non technical. And so everything was growing And these people who have been around even just a few months earlier at the scarce knowledge that they had to try to scale out and to train up more people and to build tools to automate the things that you used to do

manually. So tell me about launch night, So you probably worked on this for months, like what was it like? When did we launch? Was it during a slow part of the day, was it at night? Like or you tell me how that worked back then?

I love launch night, the launch knights of the big projects where some of my fondest memories at the company and because you know when you're working on a big project like this, especially for me, a site redesign or a whole bunch of new features, you're spending months living in the future. You know, when I looked at the amazon website from my desktop, my personal copy, it had all these cool new features. It had a new knave bar look and feel it was way better than what was live. Uh, and obviously there are many others who are also working towards this goal of pushing something out that's great for the customers. You know, it's a process of creation. And so when you go to launch night, that's the night when you're going to actually roll it out and it's really exciting. Obviously,

people are both tired and a little bit nervous because they don't really know what's going to happen. And what we do was we would launch in the middle of the night because the traffic was the lowest then. And since we really didn't know what was going to happen, we wanted to have basically the least amount of risk as possible and with the ability to roll it back if it was completely messed up right. This was also in the days where we didn't preannounce things, there were very limited press releases for things. So it was just, we're rolling out new features, we're not going to give any notice. We don't want any competitors to know any, anything more. And so we would just, you know, we would just do it as it were.

I talked to somebody just doesn't aside on that, that told me like even back then it was, we didn't even send launch emails. Like it was a big argument inside the company. Like engineers didn't want to send anything because considering it's spam. Whereas at some point, people like, you know, VP jen cast, you know, to launch the music story like, no, we have to email customers and tell them we have a, a new music store, you know, and so, you know,

it's possible. We didn't even tell customers about the nap, you know, or the changes. It was just different the

next day We just wanted to have the option to where if it really didn't work, we weren't committed to a public date of launching a new product. Certainly not back then where we were, you know, I don't even know how we determine what the date was. Maybe that there just weren't any more P one bugs.

So when we push something like that out, I mean, was it so back in the day that we would put up like a temporarily closed for maintenance or was it just it would switch over for customers as the, you know, the cached website got updated.

We didn't have to take down the site for things. I remember v. three, we did not uh maybe for others. We had two very very briefly, but what what would happen was so we all collect around someone's death in the Columbia building and like I said, it's late at night and we've been working on this for months. People are gassed, they're so exhausted, but they're also excited because again, we're finally going live with something they've been working really hard on. And anyone who is a student of amazon history knows that the reason why amazon is such a dog friendly culture is due to one dog and that dog's name is

Rufus

Rufus the dog. That's right, eric and Susan Benson's lovely little corgi. He was a fixed year all around the Columbia building when I started I remember my first week he would just just just silently watch me eat my burrito and just give me the puppy dog eyes, literal puppy dog eyes and beg for food, but sweet little dog. And so in the middle of the night we would gather around probably eric Benson's desk and he would write up the command. So we've already pushed the software out the bundles out on the web server but it's not live. He types up the UNIX command to flip the symbolic link to the new bundle and restart the web server processes which would happen in just a few seconds. He types all that up but he doesn't press enter then he takes the dog and we're all crying around he holds the dog in front of him and he takes the little paw and like

click

yeah pushes the enter key. So Rufus launched the site, He did this for v. three and music and countless others. And what happens at first is nothing really because it's kind of anti climactic. You just push the button but you know, shortly thereafter we start tailing the log files, following the logs of activity and you see people are starting to pick it up and use it right away, which is like a really exciting thing. But then of course along with that traffic comes bugs. So in the air logs you also see, oh that's a fatal error. Oh that's another bug. I better go work at that. And so we would usually happen including V3 is after the initial excitement wears off. You go back to your desk for a few more hours and fix those really important ones that can't wait till the morning. You know, get that patched out and then go home with a pager close by and try to get a few hours of sleep before

the next day. Yeah, I remember for launches, you just can't go to sleep, you're sitting there for hours using it in real time and at some point you just gotta go collapse and you know, go to sleep and you come back in the next day and you realize it's time to just start it all over again, you know, start working

on what's next and It's still day one the next

morning. Yeah, exactly. So the three was a big deal because it brought much better discovery tool. I mean right like discovery and a much richer experience. Like when you think about the amazon leadership principle or at that time it was the core value. What was it all about customer obsession? Like where do you see, what was it all about for V three? Because so many people talk about V three like it comes up all the times before I got there. So it's interesting to hear all the old timers like you and marry him and Joel and kim like everybody talks about it. So it must have been just a really, really big deal for the early teams that constantly still refer back to it.

Yeah, it was a big deal. And I think, I think you nailed it Dave. It's, it's really customer obsession basically from the time I started in the summer of 97, all the way through this lunch and beyond. It became very clear to me that this wasn't just a job. It's weren't just engineers building some stuff like we were all collectively on a mission to serve customers best to help them find the right book of the right product for them. And it meant a lot to us that they actually started using the using it right away and that we were continuing to grow. Yeah. We were only thinking about the customers and how to serve them best.

You mentioned some things we talked earlier before the call about what were some of the tools that got built. But you know, just to give an example for people, because engineers now you have to put it into perspective of what things were like back in 1997, like where they're, you know, one or two like key tools or process changes that even changed during the launch. That let's stick out

for you. I can think about one that really illustrates where the internet was when I started versus where it went, went after their and definitely is relevant to things like scaling and growth. Product images. So when you go to a detail page, you see an image there. And since when I came, we only sold books, they were called cover Images. So the cover of the book. And when I started at the company, uh, if an editor wanted to run a feature on a book, like say we were gonna put a book on sale a bestseller or something, they would write the feature and then they would use some internal tool that would eventually run a script. There was there was a Mac desktop sitting under my desk That would run these scripts to grab a cover image and apply a little sticker on it, like a little discount sticker that says 40 off or on sale or

whatever some little image. It

would apply the transformation to put the sticker on the, on the cover image and then upload the new cover image onto the spot where the production web server could access it. And by the way, kim is not gonna be happy that I'm telling this story. But this little file system for the cover images, it bypassed all of our rigorous software and catalog deployment mechanisms, toaster four was mounted directly online. So we use that to our advantage. She'll

be commenting

on this. I'm

commented earlier today.

So that's, that's all. Sorry kIM. I'm so sorry. But it was really cool. So you know, in terms of our growth, like this is great when you want to write a feature or two and you're, you know, you're working with a small team. But over time, you know, our marketing department and other departments want to be able to put stickers on anything and they want to be able to change the prices dynamically on the site and have the customers see what's on sale. And so we really couldn't do this with like a built, we needed to find a way to at runtime figure out if we need to apply any special transformations to the cover image and then serve an image like that and then cash it so that the next time you don't have to do the computation. So what started as a small script running on a Mac eventually became an image server, which at times we could do more traffic than the web server itself because if you think about the request pattern for e commerce pages,

okay. You've got one detail page and one cover image. But on the home page you might have six or seven cover images or search or browse or really any list of products. You've got maybe a dozen image server calls for one web server call. So this other piece of software had to had to be scalable and performant and do all the kinds of crazy stickers and translations and rotations and scaling that the site development and marketing teams needed in order to grow the site in the late nineties.

Yeah. Even every book cover itself. Just using that example, you could have multiple sizes because you could have a tiny one on a search result. The big one on the page. To your point, you could have one that's tilted 35 degrees, you know, to make it look better in a fan style or whatever. So, so that all got built or the first version of that all got built during V three. So what

you're saying, I would say it was after V3, but around this time is we knew that this little mac applying the sticker script was not going to scale. And we started working on more sophisticated solutions. By the time the image server was came to full fruition, it had the attention of people like kim and Joel and we had a larger engineering team working on it because it was so critical to not only the customer experience but the availability of the site.

Right. And you also told me a story earlier about the, well you mentioned the page earlier. So I wanted to make sure we came back to the page your story before we, before we got to the music or the big music launch. We should tell the story about the pager. But it's actually, it's not just a good story about you and your wife, but it's just a good story also about ownership and the type of what engineers, a lot of people, but primarily engineers had to deal with for a long time.

Yeah, so the

pager, uh,

That was one of those things that definitely I needed to scale at some point in my life. You know, I was given my first pager sometime when I was 21 or 22 and that was someone else on the team who used to carry the pager. They were a fungible engineer. And so they were moved to another, another department. They were like, Hey, you know, how to do all this web stuff. So different people who carried pagers own different kind of areas of the system. But I would own, that would be the first point of contact for customer facing uI issues, which included typos or just html errors or really, you know, sometimes catalog errors. And uh,

I was really the only one who was on call for that for a long time. And then in the sometime in 98, a bunch of us, it was, it was a weekend, a bunch of us on the web team all decided to go out kayaking and so you know, it was one of those rare times, we got to go do something fun and we weren't working and so we, we gotta kayaking and I'll never forget, we're on the lake and I look off to my side and I see one of my colleagues coming straight at me broadside with this look of deep fear on her face, and the last thing she said to me before the boat hit me was no

breaks,

so the bow of the boat literally hits me in the side, I tumble off into the water, my pager on clips from my belt and go sinking to the bottom of Lake Union. And we looked around, we were like, oh no, the whole Web team is here on the water, the page is gone, we're just totally unreachable where something were to go wrong. And that monday morning the web team got together and we agreed, okay, we need to have an on call rotation and it can't just be Alex anymore. We need to share the load. Um What's amazing though is that the story is really about ownership. It's one of those other amazon principles that comes up often and everyone was so committed to building the website, it actually wasn't that hard to staff up an on call rotation with a primary and a secondary. And you know,

it would, it would change over the weeks. And of course with each person we hired, we could add them to the rotation and then the work comparatively for the others would reduce. So, you know, back then, it wasn't just being on call, it was about what kind of tooling and other best practices could you capture, you know, at three in the morning when you fix the problem so that the next person on call would have an easier

job of it To be a devil's advocate. Why wasn't that important to fix the typo at 3:00 AM? You know, I mean if you look back on that, maybe some of those could have been putting a list and you you get to it at nine, you know what I mean? Like I understand doing everything you can to but like was there at that point in time, the concept of priority one priority to priority three. Because I think like back then you were doing a lot of things that could have waited six hours.

Well you might have to ask David or Miriam about that, but I have to say again, a 22 year old English major does not want to look dumb with typos on a website that you know, upwards of, you know, maybe a million people are using. So I didn't want the typo on there either. And so I didn't always have a problem. I wasn't always upset by the idea of being paged to fix something I wanted to know and I owned a lot of that code and I wanted to know if I had caused the error and oftentimes I had caused the error. So it's probably good that I should fix

it. So let's jump ahead. So the next big thing you worked on, which we've talked about with some other people is moving from books only two, we're gonna sell other products, you know, music launched I think in June of 98, and then DVD video launched later that year, I think in November before the holidays. Well, what was your role on that launch? And why was that? Not not only a big deal, but why was it really difficult? Because if someone who's not thinking that deeply about it and say, well, you're just now at books now,

you just do CDS, which is, you know, more products. Why was it a big deal? And why was it really, really

difficult? Yeah, music was a big one. You know, it was our first expansion beyond books. And so, you know, from this, from the get go. You know, you've got, say, two dozen or more engineers or technical types who have been assuming that product going through your software is books for two plus years. So there were just many built up assumptions and the UI code base also, it's at amazon dot com. Books as the title of the company everywhere. And so I had to touch just about every line of display code to break that assumption that the product type was books.

So the work was across the stack. The software had to change the catalog, obviously had to change fulfillment systems had to change, you know, we were again, we weren't just selling books anymore. We were sourcing all kinds of different products. There was media, but it was music cover images or a different shape and size than book cover images. The availability was different. There were different catalogue fields like say, run time instead of page count. You don't, that doesn't really look very professional. If you say the page count is 20 minutes. You know,

that doesn't make any sense. So it was just a lot of code that had to change and a lot of you, I assumptions had to be changed for me especially. And I remember, you know, I was working on my list of bugs for the music launch and I saw this bug go by in the database that in the in the warehouses the shrink wrapper was melting the cds. I just thought, geez, I've got bugs and I've got problems, but at least my bugs don't like melt customer orders. That seems like a tough

problem from a web dev perspective. I mean, you must have literally been finding things in the templates where they I said, what's the book title rather than product title or book category, you know, rather than product category, things like that. That probably every template, someone who wrote it two years prior didn't think about other things. So it was probably all of the descriptions were booked specific. Is that fair to say

absolutely every template and also this, you know, I've been talking a little bit about some of these template in capabilities that we were given from the other engineering staff. This was really the time when we decided that we needed to be able to say if something else in the code in the template at runtime so we could switch on the product type at runtime. Um And that was a big change. That was when our custom template in language started feeling like instead of just some macros and started feeling a little bit like a programming language which was utilized by an increasingly large group of web and ui developers.

What was it called? Like what was an example

of that? So the software that received the request process, the request was called Obidos and others kim have talked about that rubens work was in abydos for example. But then when it came to interpret the html templates, they had a macro system which they called cat substance and I think it was short for like catalog substitution or category substitution. Something like that was it was kind of, I forget exactly. I probably should know the answer since I'm an expert in it, but I don't. And so kat subs had very humble beginnings where in the, you know when I first came there would be a little macro, another template that would allow me to pen the session I. D. onto every link on the template so that between one page to the next, we could remember what the customer's shopping cart was because we didn't even assume that the customer had cookies in the late 90s. So with the session idea in the U. R.

L. You can map to a shopping cart that we stored without a cookie. Right? And and then we get to music where we need to do if it's this kind of product or if it's or later on with toys and video. If it's you know, if the age range of the child is this, then we have to do different kinds of you. I And so over time we beg borrow and steal new cat subs macros out of the developers in order to enable again, loose coupling between the layers, more expansion of ui features with a team that owns as much of that as possible without having to go through centralized planning.

Would cat subs be used for something as well? Like Well actually back in 97 people weren't browsing on phones. Right? But they would it be based on the size of the resolution of their screen or what like where they're blind web browsers at the time? Like I don't know is that the type of thing it would be used

for as well? That's a good question. You actually mentioned something that we did do with cats ups where in the I forget when it was someone someone in the late 90's after music there was already this like chirp of something new going on a new platform where some people would come to my office and say, hey have you heard about this browser that runs on cell phones in Japan and the Japanese telco providers are giving internet over the cell towers. And I was like man that sounds really primitive. And you know the screens were this big so there were these tiny little postage stamp screens, low resolution, low band with you know limited access

And you have to type using the 1-9 or you're the 12 keys on the phone. Yeah,

that's right. No, no multi touch. But you know there's another example I said yeah let's build custom templates for mobile browsers and push it out there. We didn't have to change any of the back end software. We just had to re skin the features to accommodate the limited capabilities of the cell phones. But that was really when we started doing mobile web uh, support for customers as

well. And it was probably another 5, 10 years before mobile became really big. But cat subs allowed you to basically do a lightweight version. That was good enough. Maybe at the at that point in time without requiring a major project. Because you could just say if they're coming on this type of a device, give them the, you know, an extremely scaled down version of the data on the screen. Is that kind of the version of it? Like no image, maybe

just Yes, exactly. And he did mention the blind actually in the late 90s we also had a text only version of the website where we would switch out the graphics and try to simplify the layout so that for those browsers that would read the page to the to the end user, it

would work right. That's awesome. I actually didn't know any of that existed, I was there but I had no idea that that

existed. In fact there was often debate about how soon can we launch? Like how ready is the software and the back end and whatever support we needed for the new features, there was rarely a debate about pushing out launch to add more. In fact, we believed in brutal triage where we need to get the thing that really matters to the customer out there and we can just add more the next day. Especially the UI we can always add more you I the next day, you know, we were constantly rolling out new versions of the site and so for these critical launches, it was really like how fast can we get out there

Brutal triage was a term I learned when I got to Amazon could just give another maybe 30 seconds on that because the real summary is You're getting up to a couple of days before launch and you have 18 things that aren't gonna make it, you know, so just maybe explain what that was, who would lead it and you know, sort of what you learned from that.

Well, a lot of the leaders like mariam or the PMS would drive that prioritization, but I would give my input like, well to fix this bug, it would be, you know, a certain number of days or hours, a certain amount of risk is the customer experience really worth it to do that work now versus a week or so from now. Usually the answer is no. You know, we want them to be able to browse the site, I want them to be able to find books into their shopping cart and as long as that works well then we're launching.

Yeah, I remember kim Rock Miller who interviewed on the first episode, she gave me the example of when they were launching music that they weren't gonna have a classical, I think was the classical catalog wasn't gonna make launch. And she and jen had a healthy discussion over that, but that's an example of something that got triage and probably brutal triage to say no, we're not going to launch the world's greatest music store, what we wanted to do at the time with classical because it's not make or break for the day of launch. And I think classical then launched probably two months later or something like that. But the other thing I learned with brutal triage is a lot of times like those things that you really think matter don't matter that much. Like yes, you can launch them a week or a month later, but some of them never launch because the core things don't work or you know, whatever. So

yeah. And we really never had the staff to feel like we fully staffed anything back then. It was always like, well what can we get away with the resources we have and we don't want to launch something in like the middle of the holidays because we wanted to keep the site somewhat stable. Certainly during the first couple of holidays I spent my time in the warehouses instead of in front of a desk, just, you know, packing orders and pretending like I was a christmas

elf. Yeah, I enjoyed that time, honest. It was a nice change of pace and you also got to see how your work manifested in the product's going to customers. So so if you had to step back and give advice to and I'd say from I asked this of every guest but if like your perspective is unique because you were sort of building the front end at a time when the tools were pretty, you know not not developed. So if you think about advice for current entrepreneurs maybe in new areas technology, what would you pass on from your experience at amazon as a youngster with limited tools on the web, You had plenty of tools

so I know jimmy. Um Yeah, well so I have been thinking a little bit about this with the benefit of hindsight and I feel like you know young technologies just don't have great tooling. If I think about the internet back then there were no internet scale, no sequel databases, there was no wordpress, there was no PHP, there were no edge caches, we had to build all that stuff ourselves and it was like the tools were like made of stone and so I feel like if an entrepreneur wants to maximize their impact in like a Greenfield environment or a young technology, you've just got to be willing to work with the stone tools and what can you make with those stone tools is really the question. But over time the quality of your tools, if you chip away at them and make them sharp and make them good for you, the quality of your tools can actually translate into a competitive advantage. That's the first thing I think the second thing is, you know, this is kind of back to my no regrets comment earlier. You know,

I feel like bias for action is a really important leadership principle everywhere. I looked at the company when I started, I saw builders and we weren't just this was not just a job, these are people who are making things and I fit right into that. In fact, remember kim our story about the Just Do It award. Yeah, well, I'm trying to be humble here, but I won that award three times. I'm like mr bias for action right here.

I have one. Well, it's up on top of my shelf up here. I don't I actually have no idea what I got it for that. Which is uh that's kind of why I'm doing this podcast because I can't remember things

as well anymore. So what's

your what's your favorite just do it award since you got three of them? Which, which of the three is probably your favorite?

Well, you know, kim made a pretty good point that some of them were not for things that had a longstanding impact. And so you've got to kind of put that in perspective. But you know, my point is definitely that like bias for action matters and I like being bias for action. I don't think innovation is necessarily highfalutin. I think it's moving fast and launching and iterating and so, you know, maybe I was a little bit of a loose cannon on the site on the team, but I think it's important to have some of those loose cannons

for the listener while you look for that, I'll just share, like just do it award given out to employees who basically all add a definition to the website. But basically it's to go do something, you're not allowed to ask for permission, which is part of it. It has to be well thought out, but it doesn't even have to have been successful, which is a, you know, that's a Jeff way of thinking, like hopefully it's successful, but it's really that if you go and ask permission, not only is somebody gonna be likely to say no, but it's going to slow the process down. So they want people like Alex who has an idea to do something to feel empowered to try it, if he's given it good thought and thinks it's worth it. And then some of those get recognized with these awards in front of the whole company.

That's right, That's a great way of describing it. Dave. So, yeah, okay, so I found one um, so just a quick context, number one is after I'd done work on music and all these other product launches. I also worked on auctions, which Joel mentioned, you know, by that time I had achieved a competence in rapidly dressing up the website with different types of UI and pulling different types of products together. And anyone who knows me knows I love movies, so I'll never forget the All Hands where I got this award. This is mid 1999 now, so it's later.

And by that time, the all hands each, each quarter, the all hands would grow in size by a noticeable amount. So by this time it's a pretty big audience of people, jeffs up there on this age and here's what he reads. Okay, my boss, Gus Lopez did this right up when he nominated me. Uh did your nominee undertake the effort of their own initiative? Yes. Did the nominee clear this effort ahead of time? No.

And

then Jeff Reed's pictured, this is Jeff Alex Danger Edelman created and launched the Groovy amazon dot com. Austin Powers store, the day that the spy who shagged me hit the theaters. From hipster books to Shagadelic videos, amazon dot com customers were able to buy and sell Austin Powers products when they needed them most, all in one location. The store also featured links to Austin Powers at auctions, future video sign ups, I. M. D. B. Information and other mike Myers movie titles. You would never guess that a child of the seventies, that's me would have the right mojo to create this groovy store. Oh,

behave. And then of course he laughs and it just rings out in the crowd. And so it was that was a good one, I would say. That was that was a good just just

do it. Award if you have any screenshots of the Austin Powers Store. I'd love to include those as well.

I'll try to

look and one last part about the aspiring entrepreneurs thing. Like how do you think that applies to new technologies like things nowadays like virtual reality, augmented reality? Is that the same thing or their tools a lot better comparatively? Or they're basically in the same type of place you were when you started working at amazon? Well on

html. Yeah, interface programming has obviously come a long way since the first days of the Web. The web browser was a killer app because it was so lightweight. You only needed one piece of software to access the internet of myriad user interfaces. And because of the way html works and stuff, we maintained a high degree of control over the user experience because we shipped it out along with the transactions. So it was more like data and I believe that our ability to rapidly iterate in this area was it was a key driver of our early growth. And so when I look at things like young technologies today, like VR, a our voice command, they reminded me a lot of the early web, they have a lot of promise, but very few people are taking them seriously. Yet the bandwidth, hardware and the access are all very limited. But the UI is data that you can send along with other things.

But basically the tools are still made out of stone and there are numerous constraints. But you know, I've always felt that the best innovations are born out of extreme constraints. I would encourage entrepreneurs to lean into those young technologies to lean into the stone tools and try to make something great and not be afraid of the constraints. And I also think it's vitally important to be biased for action and willing to iterate rapidly, you know, even if you make mistakes, especially on the part that interfaces with the customer, because they will tell you if it works or if it doesn't

work. Yeah, well, that's awesome. Thank you so much for being a guest on the podcast and uh I think people are gonna really enjoy hearing, you know what it was like making website html work in the early days, and also how far ownership and bias for action can take a young employee. So it's sort of important for those young employees joining companies like amazon, you know, that you have the ability to make a huge impact if you put your head down and approach it with the right attitude. And finally it was great to see you and catch up, you know, and I meant what I said at the beginning of the podcast, like I really do remember you as one of like just a friendly person because I think it was probably from the auctions launch, you know, there were a lot of very stressful days and we would have meetings and there were certain people when you go in there, they don't lighten the mood,

you know, you're, you know, and and you were just somebody, even though we were all stressed out and working hard, that had time to smile and uh I feel the same way about your wife, Jordan as well, so, and Jordan, hey is also the woman who almost drowned you in Lake Union.

That's right. The woman who hit me with the kayak is now my wife, so we're good now.

Yeah, that's awesome. So it's nice to see you. None of that niceness has gone away or changed, so

thanks, Dave. You're too kind. It's great to see you too. I'm really excited doing

this show. Thanks well for the audience. Thank you for listening to the event. Like an owner podcast. If you'd like more details about what we discussed today or want to contact me with edits or to correct what the story's Alex just told. It's his fault, not mine. Please visit Invent like an owner dot com to sign up for the weekly newsletter. That's it for today and remember? No sniveling. Yeah, Yeah. Don't.