Timeless lessons on running software companies that endure | Alyssa Henry (Square, Amazon, Microsoft)

Alyssa: We sat within the Visual Basic team, but then, quickly, got reorg'ed and moved around, ultimately ended up,in the Windows Group for a while,various other incarnations and then wound up in the SQL Server Group. Tim was interesting as well, too, because it was the one of the few kind of cross platform teams.

 We had, Unix, base drivers for ODBC, we supported Oracle, we supported, Java. And so all this sort of stuff where the whole rest of Microsoft wouldn't touch at all, we worked on all the cross platform stuff. That was cool.

Brett: When you think about running a software company today, are there very specific ideas that you collected back then that are still relevant to the way that you think about running, organizing, business strategy, sort of those type of things that have now endured for multiple decades in your mind?

Yes and no. And maybe this was not Microsoft cause I think it came later, but, organizations are distributed systems. A lot of the things that you learn in computer science land about how distributed systems operate, turns out that's what organizations are. You need to think about,the distance between the nodes in your network. and how communication scales across the number of nodes in your network. You need to think about recursive decomposition if you want to scale. And I said, there's a lot of things like that, that I carry forward and, it's like, how can you reframe a problem in a different way and let you see it in a new light?

Alyssa: Not that humans are computers or anything, but, there are laws of networks, right? And, Metcalfe's law and a bunch of these other things, right? Conway's law, some of these other things that end up applying. So that's sort of the, yes.

The no... One of the interesting things. when I moved from Microsoft, to Amazon, I kind of,it's sort of like, when you travel to foreign countries, if you've never left the U. S. and you go someplace new and especially as a kid or whatever, wow, they don't speak the same language I speak here. That's wild.

You're like, oh, the food on the menu is totally different. so you notice the differences, but then you also notice all the similarities, right? In terms of, you know, what are the same anddifferent companies, it's kind of like going to a foreign country. And kind of the more you see of different companies, the way they operate, you start to understand, what are the things that are sort of, using the analogy, part of the human condition, you know, or part of an organizational condition, what are the things that are context of the environment and the culture and these sorts of things.

And so, one of the things that was interesting, again, from Microsoft to Amazon was, Microsoft, when I left at the time, most groups had like a one to one ratio of,software design engineers and tests, so SDETs to, software design engineers, right? And so there was just heavy investment in the QA process, if you will.

And I get to Amazon and I'm like, where are the testers? Like, where's QA? Like, you mean we just, we build stuff And we deploy it and then we see what happens. this is insane. And the company wasn't all that big when I joined, but I, did kind of looked at the, org structure or whatever, and just determined that there were more vice presidents and there weren't like a ton of vice presidents, but there were more vice presidents at the company than there were quality assurance people at the company at Amazon.

 I'm like, why is this like, why? Like two very successful companies, Why is the model so different? The Five Why's process always so informative, right? Why is it like, when you see a difference or you see something unexpected, right?

Like, how do you get to root cause of what it is? And what I ultimately got to the root cause is one of these, again, enduring lessons or things I've taught with me is that,Microsoft, again, I mentioned manufacturing earlier, like back in the day, literally Microsoft, when you shipped, it was called RTM, Released To Manufacturing. 

Because literally Microsoft had a manufacturing plant in Bothell where it printed, floppy disks right back in the day and put things in boxes and then shipped them off to Egghead where they sat on the shelf. And the cost, of a major failure or a bug in that environment is incredibly hard because the time frame and the cost associated with quote," rolling back", is significant.

 If you find a mistake, an excursion, a bug, you know, late in that, right? Yeah, it can be millions of dollars, tens of millions of dollars, whatever, right? And so you do the ROI calculation on, how much would I spend up front? Knowing that most of the bugs you find, your customers may never find, most of them won't be catastrophic things or whatever, but you do the ROI equation on what would it cost if it got passed versus how much would I spend to detect it ahead of time?

And the equation works out. But in the Internet phase,and particularly on, retail, where, you know, Amazon at its core at the time was, you're selling books and shoes and things like that, that whole ROI risk based ROI equation changes, And to me, that was super important.

Another example, even like I worked in SQL Server databases, and we were obsessed with Two Phase Commit and, Transactional Semantics and ensuring, basically double into your accounting all this, right? Cause you're sending it out to a general population of people that are running their businesses on these things.

And they expect that, that all foots, right? Whereas Amazon is like, yeah, we can spend a whole lot of time and money and costs making sure that, you know, it's always one-semantics, full transactional compliance, right?

Two phase commit all this. And then some warehouse workers going to drop one of the pieces of inventory on the floor. And all of a sudden, even though your system says you've got what, you know, it's all reconciled. The humans just screwed up the whole thing anyway, right? You know, And so again, it's this kind of risk based or ROI of what's the cost to ensure you prevent your failure, ensure semantic versus like, what are you actually getting on the outside? And so that to me, really shaped my thinking in a lot of ways where it's like, you kind of have to go back. And it's just because it's right in the context of one business doesn't mean it's right in the context of another business and that you really have to think about, well, how much am I investing to, ensure this quality or, in one form or another, versus how much do I get for having that level of quality? All the businesses risk, make decisions at some level, right? How much risk am I willing to take? What's the margin of safety?

How bad is it? If it goes wrong, how much is it going to cost to prevent it from going wrong and you're just managing that equation, through people, through products, you know, through your compliance through, you know, everything.

Brett: In your mind, is it like you can get down to an explicit equation or it's a squishy sort of set of ideas?

Alyssa: It's fuzzy math, right? Because you like, you can't quantify specifically, right? But I'm all um, okay, napkin, right? Here's the range, right? So you're working with the ranges worst case, best case, something in between, right? High level, whatever.

Brett: A bunch of things came to mind. One is, when you think about the consistent variable about, you articulated as the human condition, the kind of things that regardless of what setting tend to be true, do you have like in your mind, here's like the three or five things that I just know to be true about human beings and I take it with me? 

Alyssa: I think there's a few things. One is, I do fundamentally believe that everyone's well intentioned, right? people may do things, but it's, the default isn't that they're not well intentions. It's they're, if, if there's a disagreement or something, it's, there's a different set of underlying principles or different view of the landscape and that risk reward trade off or whatever the, what you have.

I think I, I call it the Thomas, the tank engine, theory of humanity is like, everyone wants to be a useful engine, right? You know, how do you find ways that you maximize, you allow people to maximize their own utility? Cause that's, what's fulfilling, right? You know, and people will find that in different ways and people have, have different strengths, right?

And so it's but how do you discover that? and that. It's true, true for an organization, on the whole, so both of those things, right? How do how do you amplify an organization's good intent? How do you amplify the utility of the people that make up the organization

and create a team of compliments of folks and skill sets. So I think those things are true. People vary, on all sorts of other, of all sorts of other, angles, and it's, that's the joy of building teams and bringing, how do you make all those things work together?

Brett: So in the context of working at Amazon, how would you describe in whatever loose terms This sort of optimization function or like equation that you just articulated was there. And if you remember when you joined Square, how would you describe it? 

The interesting thing that you said about Microsoft, was that if you're shipping once a year and putting something on a disk, if that is your business, everything has to flow from that reality. The constraints change, your risk tolerance changes. a different environment like Amazon,

I can just like intuitively see why doing something correctly at Microsoft could be incorrect in the context of Amazon. In my mind, when I think about something like AWS versus Square, I think they tend to be maybe more similar. 

When you arrive at something like Square, after being so successful at Amazon, what's the process like of like reorienting and understanding, like, what is the new equation here?

Brett: Yeah, it's always disorienting. and there are a couple of,a couple of different things in there. 

Alyssa: Again, different companies make different trade offs. And so you end up with different kind of outcomes and cultures, but, any business there's, really kind of four key constituents, in the business.

So you've got,your customers, your employees, your, shareholders, and then the communities that you operate in. 

Brett: And there were differences in all of these between the different companies is how you stack rank those.

Alyssa: Every company has all 4 of them, but how you stack rank them really changes. How the company ultimately operates and what the culture is like, and you can pick examples that have chosen different orderings of them. 

Brett: Microsoft was, not that it wasn't customer focused, but it was more technology first then.

So I would say it was kind of tech first more than anything else. Right? It was like, it's cool technologies. Like, are we doing heavy duty research? Are we doing that? And customers were kind of came second, it's no fun to build something that no one uses. So you need customers.

But it was at the time it was very much tech first, and kind of customer second. It was always very, pro employee,gold-plated benefits, care a lot about shareholders as well, but also invested in the community.

And so it's not just the stack rank, but it's like, how much you do on each of these. Whereas like Amazon, customer, customer, customer. Tech was an ends to a mean to the customer. I would say shareholders, like, if you look at just Jeff's initial letter, he talks about customers and he talks about shareholders.

No mention of employees, right? Employees came later at, when they decide, oh, Earth's most customer centric, but that came much later and it was not in a, you felt that through the whole company. And then community, was not a thing at all. There's no community grants.

There's no charitable matches. There's no, none of that. And stack rank them in different orders and then very different emphasis on them. Square when I showed up,I think in some ways it almost was more, employee first, in some ways. Still cut, you don't have a company, you don't get product market fit without customer.

but the extent to which employees were front and center, was different than anything I had experienced before. Shareholders didn't really matter at the time we were, we were private and we had investors, but community was big emphasis to, we would go outside and pick up garbage around the Tenderloin every day, every Friday, right?

On company time kind of thing. The culture, then, of each of those three companies was different based on, implicit,not fully stated, stack ranking and, if you had a hundred dollars to spend, how much would you spend on each one of them? Right?

Relative, relativeness on them.

So, 

before you continue on, do you think there's a causal relationship in the way they can figure that or in the case of Square, that the company actually worked in spite of that,you know, supporting the community on Friday, actually it worked in spite of that.

Alyssa: I'm probably a little bit biased. Obviously you've got to care for your employees, we're knowledge businesses, right? The team is the knowledge base that builds the product and engage with your customers and supports your customers.

But I think. Yeah, too much emphasis on both employee and community can send things kind of sideways and you find companies that decided to go be a B Corp because they really value community and, I would say that probably got in their way more than, more than it helped them. So yeah, I think everything starts from the customer.

 If I had to stack rank for me, it's customer number one and with a heavy emphasis on that. And then everything sort of flows.

Brett: So on that, one of the things that's interesting is, I've studied and talked to lots of people that have been at Microsoft at various sort of chapters, certainly it seems like back in the nineties and two thousands, it was very technology oriented. Do you think that enabled the success or that if the, if you could have run the company and oriented around customers at that time, it would have been better off?

I'm not sure. I mean, obviously it was early, very early stage in sort of the maturation of the industry, there was a lot of just fundamental tech stuff that we take as fundamental parts of technology today that we're still in very early innings. I do think, you know, it's about tech for tech sake.

At the end of the day, you're not going to be successful with that. you have to tie it back to customers. Microsoft is a fantastic fast follower. And so it actually was good at seeing competitors who spent the time with the customers, understanding what they want and then just did it better, cheaper, faster.

And so if you've got someone else kind of out as well, too, like you can take databases, right? Oracle's ahead in databases,Borland was ahead in a lot of the, programming languages,you have WordPerfect and WordStar ahead on, document editing, you had 1, 2, 3, ahead and VisiCalc ahead on spreadsheets.

 There's a lot of following and on that again, if you just, somebody else has done the customer research, to figure out and then you just go read their forums and things like that (laughs). You know, you do it better, cheaper, faster. I do think, the fast follower, you don't have to be as customer focused.

You can be more technology focused, but to be, out on the front edge, you know truly, innovating on product. You're not order taking from customers, but you have to really see their pain points and their problems and work from first principles on how it is you're going to solve their problems, using the tools that you have, or the tools that you need to go acquire. 

In the mid 2000s up until, like, the last few years, I think the dominant building paradigm tended to be very customer oriented in Silicon Valley. It feels like over the past few years with what's happening at the infrastructure level of AI, you're starting to see more research oriented, technology oriented companies that can raise capital for the first time in a long time. When you go back to what, at what, what it looked like to be in a technology first company, what is like an example or a story that comes to mind in terms of what you were working on or colleagues of yours? And how did something eventually get tied back to something that someone at Microsoft could charge a customer for? Is it,the fast follower idea or like, how does it connect to, at some point, (that) a subset of the technology is commercialized?.

Alyssa: I think this is an evergreen challenge. You look at Xerox PARC,strong R and D invented a lot of technologies, never commercialized, right? Um, You look at, Bell Labs, same thing. And in many ways, you look at a bunch of stuff that,Microsoft research had, just, I think companies struggle to connect those two pieces. 

You do end up in the disconnect.It's two different languages, right? When you go talk to someone in Microsoft research back in the day about what they were doing, and they're like, can you put this in your product?

And it's like, well, okay, can it do this or that or the other thing? And how we're going to get how, we're going to get to the right quality level or... or gosh, this is way too out of sync from what any of our customers are asking for. And so I think there's this kind of constant push and pull.

And I think, again, it's the industry. The pattern says that if you have an R & D lab. Others are more likely to monetize your R & D than you are. Right?

Brett: What is the why behind that? Like in a vacuum, it doesn't make sense. But to your point, over 50 years, this continually makes sense that oftentimes the leakage or spillage out of these much more research oriented, environments, tends to benefit external parties than sort of the owner of the research lab, if you will.

Alyssa: I don't know that I've got a great answer to that, but like, again, it's one of these things. It's a, it is a puzzle on it, but it is this, it is this pattern. I think some of it too is if you've got existing products that, , yeah, you've got a roadmap, you've got a set of customers that are saying, I want X, Y, and Z. You know, best use of new innovations where you can see this thing, you go, okay, my customer's not asking me for this at all.

But I can see how it can apply and to solve this problem or this thing that they are doing that they, they become nose blind to, if you will, right. They're doing something where they don't need to be doing it, or it's like, it stinks. Um, But they're just so used to it that they keep going. But I think more often than not, you just kind of get on the treadmill of, you know, you do, you know, more mature products, spend a lot of time talking customers and, you know, they're they're telling you, what they what's the Henry Ford story or whatever, right?

You know, and there's some amount of just, probably back to human nature under under pinning that, and it may be that folks outside the organization able to kind of take a just okay, clean sheet, right? We're starting with zero customers. How can we create something using this technology without having to worry or think about how it integrates into an existing business or an existing customer base.

Brett: Okay, so we took a left turn, but you were part of the way through explaining the idea of when you join Square and you were trying to figure out like what is the optimization function or how does the machine function. What set of my ideas are useful here and in what ways do I kind of have to go back to first principles or actually I think they are doing it incorrectly here, but no no, becauseI understand the system, it is correct.

Alyssa: Well, 

it was a crazy time when I joined, right? Shortly before I joined, right? The Wall Street Journal would publish an article about, how Square was, you know, shopping itself around, looking for a buyer, what's going to make it. It was losing a hundred million dollars. you know, Hashing Twitter had, had just come out and,panned Jack a bit.

 I joined in May and then in August the Fast Company article about, yeah, I think the title was, "Back to Square One". Um, you know, Basically, Squares throwing spaghetti at the wall, trying to figure out what that is that they're going to do.

It was a little bit of a crazy time and it was a little bit of a, it was a little bit of a crisis situation. That's an overstatement, but there was this kind of sense within the company that, cause employees see what's being written externally. And as much as you like to say, ignore the press, 

narratives do take hold and they take hold not only externally, but then, internally as well. And so,

I joined Square because, going back to why I joined, I'll get to what I did. One, I thought Jack was super interesting. Two, I was at an age and stage where I'm like, if I'm going to make a change and ever go experience what Silicon Valley is like, I've got a really short window based on the age of my children.

 And so I was in that window and the window was quickly expiring. And Jack and I hit it off and, Sarah, uh, Friar, who's the CFO at the time, really enjoyed talking to her. And, and so I'm like, let's give it a try.

You know, what's the worst that can happen? But yeah, as with most jobs, I had the same feeling, in the first six months of being at Amazon after Microsoft, I was like, what the heck did I do? What was I thinking? I'm like, this place, just as when I went from Microsoft to Amazon after six months, I'm like, this place is insane.

What are these people doing? same thing, at Square.you know, In some ways, it was a little bit of a culture shock from the fact, A. W. S. felt more entrepreneurial and more risk taking in some ways. But in a kind of a structure and coherent way, then, then Square did at the time.

And, so I think it goes back to that kind of, maybe to over emphasis on employees and, spent more time talking about the snacks and the snack bar, then, like, what are we doing to drive the business kind of thing, right?

 So yeah, I mean, it's, it's piecing apart and figuring out what matters and what doesn't.

When I joined, I joined as the head of infrastructure. And so I had parts of engineering, not all, I had the infrastructure engineering, Gokul had product engineering and product. There was a separate person on design. We acquired Caviar. Gokul went over to lead that. And then Jack's like, here you go.

And so I took on, all the product engineering design stuff for Square. And it was, uh, it was definitely a crash course, right? Never worked on mobile before. Hadn't worked on anything with the U. I, was still getting indoctrinated to, Bay Area, smallest, youngest, company I'd ever been part of.

 The part that really felt like a startup was,there's no HR, like all the HR stuff is underdeveloped. All the finance stuff. There's no planning processes. There's no levels or how do you do promotion? Like, all of the human capital management stuff didn't exist.

And so part of it was even picking apart it. Like, how much do I need to invest in helping build out all these other functions in addition to how, what do I invest and organize make sense of the product portfolio and, uh, and go from there.

Brett: What did you end up doing and in what order?

Alyssa: First is, it, you do the survey, the landscape, right? You gotta go wide and an inch or two deep and a bunch of things to start to figure out, okay, where things working, where they're not? But then also how, like, how do the things connect? So it's okay, this is broken, but, maybe it doesn't matter now toss that out right? Yeah, we'll go fix that next year, two years from now. Versus, oh, gosh, there's actually material for the business. So, a lot of is,figuring out the material, figuring out where the problems are,Where the successes are, and the materiality of all of the above.

And different people do that in different ways. I'm, I'm always a combo of 'quant and 'qual. I was like, I spent weekends rummaging around the data warehouse, which, one, I could learn the architecture of the system that way, because databases are reflective, you look at the table structures, and then you can figure out, what all the entities are and and the interrelations between all the entities, you figure out, whether it's material revenue or not. You slice it by a bunch of different ways. And so you start to get the 'quant view. Like, how many customers you have, which customers are using which products where's most the revenue coming from and all that kind of thing. So 'quant. And then you do the 360 you just go talk to everybody and that's the call.

And so you're talking to people within the team, but then you're also from the 'quant trying to figure out. Okay, well. Well, who are our top customers, right? Okay. Well, I'm going to go talk to some of our top customers and they're going to give me the good, the bad, the ugly, right? You know, Just like you're going and talking to employees asking, asking the same sort of kind of questions of what's working, what's not.

And you start to just then build the picture,of the business of the code of the organization.

Brett: What are some of the things that seemed broken, but actually were correct? Do you remember any of those things?

Alyssa: So one of the big debates we had when, when I first got there,going back to what I mentioned, the Fast Company article or whatever, there was this big debate. It's okay, there'd been like just this rapid expansion, some organically and some inorganically of kind of the number of products in the suite.

And I think,Kind of at first blush, it was like, oh, my gosh, we are like, Dustin, like, we're doing a lot of stuff and we have very few people on each initiative and, do we have enough kind of wood behind each arrow? Lots of debate on that,cross the executive level, as well as within the teams, 

I was probably a little bit more towards we should,call a couple of these things. And if they're great ideas, we'll come back to them later. We ended up not. And, you know, and I think in hindsight,it's hard to know what it would look like alternatively. But I think, you know, a key part of the overall value proposition,is the broad ecosystem and the integration interconnection between things.

Brett: To your point, there wasn't a lot of structure, there weren't levels. How do you figure out what you're going to implement from your past versus like, it would be very easy to say we had a very sophisticated level system at Amazon.

I'm going to bring that and implement that here. What's like your inner algorithm that sort of tells you what I'm willing to sort of take from the past versus sort of start all over or modify sort of in some way. 

Alyssa: having some structure, so that folks understand both expectations and what career progression looks like. I mean, There's a reason why every company ultimately has job descriptions and a set of and a set of levels, right? So in my mind, that's the thing where it's like, okay, that's not really open for debate.

At some point now, if you have 10 people, do you need that? No. But at some point where you have enough people where you can populate and you start on a discipline by discipline basis, like we started with, we had to hold, pretty big batch of engineers, right?

We had hundreds of engineers, right? And they're wondering how they're doing, how they progress and that kind of thing. We had maybe. Yeah. 20 designers, right? So let's not bother with one on design. like, you know, you start to get to a scale of a couple hundred in a given kind of function where it starts to make sense.

So you go, okay. All right. we'll start here where there's kind of critical mass and then it's like every company is different, right? There's things you can pull Bradford off the shelf and they give you some guidelines and things like that. But ultimately, it's got to fit with your culture and what you do, you involve, you involve senior people who are respected in the organization.

 And that are willing to spend some time engaging in on it, and you get them involved in crafting it. So it feels tailored to the organization. It makes sense. And so you got buy in from the folks that are, that others look up to.

Brett: There's this interesting dynamic, when you're at a scaling company, where I think the very best ones have this ability at various points along the way to figure out what has served them well, and in what ways they sort of have to update or evolve their thinking. I think what's unique about scaling software businesses is it's very easy to get stuck in the way that you were doing things because it is so rare for anything to work. So for example, if you had a company and it got to extremely strong product market fit and you mandated that everybody could only type with one hand, it would be very easy to say, we must always, you know, type with one hand. . And the other sort of conflating sort of factor Is you often have people who are there very early, and a subset of those stay for a while, and so there's often a group of those people who as you're trying to kind of continue to grow a business are Curmudgeons or well, we don't do it that way here or what are some of the things you've figured out about how you sort ofeffectively move e chapter to chapter in a company?

Alyssa: It does vary by company and I think, one of the things that Amazon as a whole did really well, and I think some other places have not done as well, but it's like this constant process of explicitly asking, what are our sacred cows? And questioning them right? And revisiting them and, they'd be, sacred cows outcome and all like, all shapes and forms in terms of, you know, product business organization, all that kind of thing.

Because there was a, why initially, but context changes and the why changes. And so some of those things need to get tossed out. But you're right. I think people, it's either Curmudgeon-ly or, humans don't like to change, and or sometimes even nostalgia, like, for the past, where it's sometimes, like, even when things have moved on, you'll get, you know, people saying, oh, but it was so great back in the day.

Right. and you have to kind of keep pushing, pushing the change and pushing forward. 

Brett: You, joined at a time that was somewhat chaotic and improvisational and what are the things that the company then got right, that unlocked sort of the chapter over the last 10 years? Can you boil it down to a small number of insights that sort of compounded over time?

Or was it of little things that all connected in some way?

Alyssa: I think it's more of the latter category, right? Like there's no, there's, there aren't silver bullets. There's not just like, if I do one or two things, it's compound effect of some things, but then it's the, aggregation of many others.

So it's, you know, It's a combination of, who you hire, what the team is. Communication is one of the biggest things, right? How are you figuring out how, and communication has to change every time yougo through an order of magnitude change in organization, right?

Let's get around table and hash this out, right? You can't get 30 people into a roo m and hash things out, let alone if they're there across four different time zones and that kind of thing.

It goes back to, like, I believe people have good intent. I believe everyone wants to be useful when, when things go sideways, both internally and or with your customers. It's usually communication, right? And so you've got to constantly be looking at, okay, well, what are our communication mechanisms? How, what am I doing? How am I adding on? How am I removing? How am I changing that? So that we all have the right amount of information at the right time so that then we could make informed decisions and go, right? So I think communication is sort of at the top and explicitly designing those communication structures and thinking about, for what purpose each mode and mechanism plays and, what's synchronous, what's asynchronous, what's in writing, what's, in voice, you know, and that kind of thing.

And then, 

And then culture,and being explicit about that. if you have clearly articulated, you know, Amazon called leadership principles,if you have communication and you have those things, then you can push decision making down the organization.

 I think, as you scale, you're going to have decision making right? One way or another, but you want to you want to have confidence in the decision making that's happening on the organization. And if you go back to okay, well, if there's clear communication, so that people have the context of what's going on and left hand has the context of right hand in the appropriate way.

And if you have that foundation of culture, so that when there are, judgment calls, right? You have a shared framework that's going to say, based on our cultural values, the tiebreaker goes in this way, right? Whether it's, hey, we're customer first versus, even if there's two options here, one saves us money, one's better for the customer.

Gosh, there's compelling reasons on both for customer first or organization, you know, which one are you going to pick? And so I think those two things together, allow you to scale the organization and you have to keep revisiting. Each of them, as you grow and scale.

Brett: It feels like in the case of Square, but definitely in talking to so many people that have worked at Amazon, that operationalizing values was done at an extraordinary level. But like the default is, you know, we have a bunch of words on a page and it doesn't really guide behavior or to your point, create a shared consciousness that, it's sort of scaling judgment to a certain degree.

Other than sort of like the generic things, oh, well, we interview for values or whatever, like what was going on there that allowed values to really guide how people behaved?

Alyssa: You really have to operationalize it. And so, one, you have to articulate them, right? But then operationalizing it means, when you're hiring, when you're talking, you're giving feedback on a candidate, it's in the context of those values, right? You're going back and so you're, in all of your interview panels and everything like that, you're framing evaluations of people in the context of those values. Then when you're doing performance reviews and you're doing promotion, right, it's in the context. So all your people processes have to tie it back to that.

Because then people know, oh, okay, it's not just some words on the wall. Like, I'm not going to get promoted if people don't think I'm good at, you know, 'think big' or whatever it is. Right. Which is one of our stated values and I'm going to be assessed explicitly and I'll be promoted or not, you know, or get a good review or not based on that.

And then it's in the day to day. It's in the doing the work. When you're looking at, okay, we've got to make a decision, our decision making framework and process. Is our decision making framework and process tying back and referencing those core cultural values or not?

And so if you're, all of your people processes, and if your business product strategy, as well, are all tied back into that then that, that's operationalizing it at scale. And now, and every employee is going to understand because they're just going to see it every single day. That it's, a key part of what's going on.

If it's not in those things, it's not gonna stick. And so you really have to have alignment,you have to have alignment across the organization, because there's different functions, right? That, play in to all of those different processes and if they're not all aligned and all driving towards that, then it won't work.

Brett: When you think about your, long stint at Amazon, are there any stories that come to mind that bring to life how powerful it is to have a values oriented culture in that way?

Alyssa: Companies are cult and where does the word culture come from? It is a derivative of culture, vice versa or whatever, right? you know, I think what's powerful is, you know, not every culture, not every cult is right for every person. That's okay. Like you're going to, if you can, build a strong tribe, where you've got people that have the shared set of beliefs that creates belonging, right? And, you know, you could talk to any of the HR people how do you increase retention? How do you increase job satisfaction? A lot of it comes down to belonging, right?

If you select folks that are more likely to feel a sense of belonging, if you weed out folks that don't fit the culture, you create a stronger, tribe. You end up with less internal, it's not less internal debate because you still have debate and that's important, you'll less likely end up with warring factions because your warring factions often come from a non shared belief system.

Right? And what people and humans fight over, is differences in beliefs. And so the more you can bring your organization to have a set of shared beliefs, the less internal bickering you're going to have, about differences in beliefs and the more you really can then just focus on your customers and, your business and the outcomes that you're trying to drive.

Brett: And for you, are, are shared belief stuff that exists, outside of well articulated values? Or it needs to be captured there?

Alyssa: I think it has to be captured because, it can happen by osmosis with a small enough group, right? With a friend group, right? Most the time people kind of are attracted to other people with similar belief systems.

You might have, some issues or some things where you differ on.We've self selected in, we were friends because we have a set of, shared beliefs in at least, some number of areas.

So it works on small, but you can't scale it. The trick to building a business that can scale is putting in all of these things that provide the scaffolding, right? The foundation that will allow you to scale without getting to a point where things just sort of crumble.

Brett: When you think about this idea of,strong culture, strongly stated cultures the sort of implicit idea that, like, if you think about an excellent director of engineering that you worked with at Amazon, many of them definitially would not be excellent directors of engineering at Square?

Alyssa: Absolutely. Part of that is just like the space, right? If you get someone who's an expert on databases and operating systems, and you ask them to come build a checkout screen for a point of sale, they're going to be like, I got absolutely no interest in doing that.

So some of it is like the, the product itself. Some of it translates in terms of there are some cultural aspects that are similar between and not, but there's some just differences fundamentally. And, in the culture and then the type of culture that you need, to support different types of businesses. A focus on design and aesthetics was absolutely not, not only not AWS, but frankly, it wasn't Amazon as well. Like Amazon, I figured out yeah, the ugly homepage converted way better, than one that got prettied up. And so they reverted out of the prettied up one and went back to the one that converted better.

Right? Whereas at Square,Well, this is before I joined, but we figured out that the,black little card reader actually sold better than the white little card reader. And we said, yeah, but we don't care. We're going to stick with white one. And that goes back to a cultural element around we value design and aesthetics, more than maybe what the exact data is telling us.

And those are both valid choices for different reasons.

Brett: What did working at Square for so long, teach you about taste?

Alyssa: We talked about part of the Square operating principles, we want to build remarkable products. And if we're launching something new, we want it to be an, a minimum remarkable product, not just a viable product.

 Remarkable had a number of different, kind of characteristics to it, but one of them was elegance, right? You can have two chairs, you know, both are simple chairs, but one is crudely made and one is elegantly made.

And you can tell that they're like, they're both very simple, or a little black dress, right? There is something about the craftsmanship, that boils something down and make something simple and make something truly elegant.

And I think that was a key part. That was a import of some of the Apple DNA,that we had in the business, but I think it made sense in the context of a Square in a way. you know, we weren't pioneering, I mean, the card reader initially was, but as we moved on, a payment terminal was not a thing, not something brand new.

It's like, oh, wow, here's a card reader with a receipt printer in it. But the differentiating value is, elegance and a care and thought. And so, again, I think it makes sense in different contexts, different companies, and is that a thing you're trying to differentiate out or not?

Brett: You sort of got it this with your answer, but when you have a company that values aesthetics or an aesthetic or values taste in a very specific way, how do you scale that?

Alyssa: It's challenging. Um, I think it's hard, we had a very broad product suite, and,at one point we had, centralized at a design. had to actually I had to hire in someone and they just got overwhelmed.

They're like, I don't know how to like, don't even know how to engage on this. 

Brett: Cause you can't do design review for 40 products or...?

Alyssa: Exactly. Right. That's where, and I don't think we did this well, but, where being really clear on defining the culture and the things that matter and, and then pointing back to them.

So you start to train the organization down on what the eye is, or what trade off of this versus this, right? Do we trade off between,elegance or functionality, right? We had lots of internal debates about that at a time where we didn't, that wasn't clearly defined.

We had a camp that's like, we shouldn't include the ability to swipe in this next generation of reader because we should be paring this thing down as most simple, and others like, but the U. S. isn't an AMV tap market. Like everyone's going to need another one of these things.

And yeah, this looks beautiful, but now you've got to have two, you've got to have this thing and this thing, right? You know. So real debates on that. I don't think we did a particularly good job because we hadn't defined, at that point in time, hadn't defined what mattered, so that folks, so we'd go back and say, okay, before you get into having to make a trade off, you've already made the meta trade off and said, this is what we're in value over this.

Brett: Talk more about why that was so hard to crack. 

Alyssa: Because the organization was splintered, right? You have to drive it from the very top. Hardware eventually moved over to me. If you've got, hardware saying, I've got this set of values. I'm going to make trade offs this way.

And the software team is saying this. And then at one point we had it, you know, a separate sales team. They were saying this, and then you've got HR going, well, we actually. And so if you've got five different sets of values, you have no values. Like you really, you have to drive it from the top down at the point where all of the different parts of the organization meet. 

Brett: And that

 is just difficult to do?

Alyssa: It's very difficult to do through influence. reasonable people can disagree. And so at some point you need kind of what they call it, the benevolent dictator. Right?

Brett: But that wasn't you?

Alyssa: Ostensibly Jack, but one of Jack's Greatest strength is his ability to let other people do things, but then you run into impasses sometimes where there isn't alignment and you just don't get agreement. But,again, I think we, I think we did phenomenally well. We made progress on parts of it.

And others, I feel like it's still unfinished business.

Brett: I thought it was really interesting when you kind of gave the card reader example of do you allow swipe or whatever it was and you kind of have form and function or elegance and kind of pragmatism that sort of polls. Did you try to sort of come up with a series of examples that then would get disseminated to the company so they could understand how a trade off was made?

Or even if you feel that this idea of scaling taste or some of these issues with different values at different parts of the company,

I would say Square, Airbnb, Apple, there's a small number of that seem to have done a vastly better job than others at scaling an aesthetic or taste or something squishy.

Alyssa: I think part of it is like different parts of the company with different constraints. We tried to have a set of, I would call it "Block-wide" and we weren't called Block then, that spanned all the parts of the organization. But it never got built. It never got operationalized into all the places I talked about previously.

What ended up happening is it just fractured. And like, You would find 50 different sub teams of various parts across, the entire company that had their own set of, these are our cultural. So you, you get alignment in your own, and some of that was a benefit, right?

You know, we take Square versus Cash, for example. Different customer set and differentiating on taste in different ways. The Square aesthetic, very Apple-esque, right? Elegant and modern, you want to evoke trust, right?

'Cause you're running your business on it and you want it to be, you know, cool, but you want it to be fit into a bunch of different,store environments and that kind of thing. Right.You take, Cash App on the other hand, and it was like, okay, the demographic that we're going after is,young folks, many of them under banked, many of them inner city and our aesthetic is hip and edgy. So how you marry hip and edgy with, elegant, tasteful and,and trustworthy like, very different things.

And so part of it then comes back to like, then how do you organize and how do you then build some of these supporting functions like HR, where you need to cascade all this through when they're kind of going, well, I we can't make a progress cause they're different.

Brett: When you talked at the very beginning about the idea of like all of these are distributed systems problems. I think in talking to folks that have reported to you over the years, This sort of large product portfolio had a lot of implications on how you ultimately organize and do you organize around end customer product, you add Cash App as like kind of a separate business unit that kind of seems like it had a wild journey over the last number of years.

What was sort of going on with the way you organize the company?

 I think understanding who your customers are, matter, matter. And obviously you've got variation within that, but you got to understand like, where do you have clusters andwhere's the product fundamentally different, serving different customer needs. So like the, You know, I mentioned Cash App, you know, fundamentally different product than a point of sale, 

A peer to peer money movement app or whatever, or personal banking and finance app. Very different than, a point of sale, at a restaurant or a retailer, very different demographic, a consumer versus a business. So, you know, I think organizing those separately, having, one design team that's trying to, or one product team trying to serve those very disparate customers I think is problematic because you just, there isn't really common ground. You're trying to do different things. Then recursively with the, even within Square. Square was interesting as we started very much as a horizontal product, the little white reader, right? The functionality, taking a credit card, it's basically the same thing. Whether you're selling soap or you're selling a churro, you know, or you're selling some flowers or you're selling, um, an airline, uh, you know, a flying lesson.

So varied payments in general are very horizontal. But once you start moving up the software into, into, software to operate a business and you start to look at the workflows, and you start to look at what you need to go do. 

It seems different, if your a restaurant....

Alyssa: It's entirely different. And so, you know, the challenge with Square was, we'd started horizontally and we'd started, I would argue the amount of actual software was pretty small.

It was at the beginning, it was just the kind of the pin pad, charge it, added a little bit more in there, but, pretty horizontal. Um, but As you start to want to expand and work with larger customers and replace some of the existing systems they have and not just going into, you know, Square started, it was all white space.

There was, these were all customers that were not getting served. And so you're not trying to display something that already exists. You've opened, you've unlocked this whole town. Best way to start right? You know, uh, which is fantastic.

But as you start to then look at, okay, well, you know, how do I move into the adjacencies and it all starts, it's different customers, different needs, 

Brett: I also think it's interesting that you went from, blue ocean to red, like, it wasn't just, oh, there's a couple, like, the POS space has been, is mature and as competitive as you can possibly get..

Alyssa: As I started working in Tangle in the Square business, I was like, oh my gosh, what do I do? We've got a huge product portfolio. We've got horizontal products, which for payments works, but in the POS space, It's not going to work.

Our product team was going, gosh, we're hearing from our, we're hearing from our customers. We're hearing from a sales team that for all of these major verticals we have, we've got an incomplete, we don't have bingo. Right? We've got, we've got certain squares, but none of them line up to serve any of them.

Right? So what are we going to go do? And that just came from again, operating this horizontal way. You know, oh, we're hearing that, we really need, tabs from talking to restaurants, but we really need, um, refunds talking to retailers.

And so we build pieces of it and none of it connected. Well, we need to start understanding and starting looking through, not just from a feature lens, looking through a customer lens and then building, you know, basically vertically for the various areas. What you needed for a hair salon and how to schedule an appointment and all that, totally different.

So that's when we said, okay, well, we're going to start to organize teams. We had to set a horizontal things like payments. We had a horizontal payments team, but we're going to have a team that's focused on restaurants. And we're going to have a team that's focused on retailers and we're going to have a team that's focused on,

on health and beauty so that we can make sure that we're getting bingo in each these and not, not just sort of being all over the map. And that we've got people, for each of these products. You could go find standalone startups that were doing just that one right. My bet was like,

okay, well, if my head of product is trying to think about how to beat,all the legacy players, plus all the incumbents across all of these verticals, like, I don't know how they wake up every day and figure out what to go do. Right? I don't know how to wake up every day and figure out how to do on that.

So, instead, we're going to go, okay, let's start to tease these apart so that there's a, a general manager, if you will,you know, has the equivalent remit of, whoever's leading the startup that's doing that same thing. So, at least they have a fighting chance in terms of being able to focus.

Brett: On the specific needs of a specific customer set and figure out what features to go build in what order to go serve them. And so that's ultimately how the org structure shook out?

Alyssa: Every organization is matrixed in one way or another, right? If you have a functional org and multiple products,you're organized by function, you're matrixing the products across the functions. That comes up with a set of tradeoffs. Or you flip it and you say, okay, well, we're gonna,organize by product, with the functions, you know, not rolling up to ahead of, each of the function. And then we'll matrix the functions in a virtual way across those.

And so ultimately, and there's no right or wrong on those things. The more products you have in your portfolio, the more you have to move to that model where, you're not at the highest level organized by function. And instead, you push the functional organization down. You matrix that across.

Brett: So that's what we did. And then we had an underlying,platform team that says, okay, well, part of the value prop of the, suite of products is you want some commonality, right? I was gonna ask like, how payroll work? Because you don't wanna rebuild payroll for restaurants, for beauty, for...

.

Alyssa: So you're going to have both some products are horizontal, like payments or payroll, and you start with entities.

Right? So it's like, okay, well, there's a common employee entity, right? Or a common order entity or a common payment entity. And that,every product needs to use the common employee, needs to use the common buyer, needs to use the common, payment, all that, so that you can string them all together.

And so if I created an employee, in the POS as a cashier, and now I decide to go use payroll. The payroll product already knows about that employee that you created in the POS, because it's the same underlying platform 

underneath.

Brett: 

Is most of product roadmap then driven by the GM understanding the customer and building for that customer? 

Alyssa: Yeah, I mean, it's push and pull. The more you want an integrated product, and more products you have, the more dependencies you can have, right? By definition, right? If the payroll team is using the same employee entity as the POS team, right? You've got to figure out, how do you sequence this set of functionality for the employee from the POS team, the payrolls going, but I also need to know what state they live in, or, with our wage rate or something like that, which you don't need.

And so you've got to negotiate those things. And it's creating dependencies between them. And so a lot of it comes into dependency management, getting those cross things, right? And getting the sequencing right on some of the core elements that you say have to be the same. And then living with some amount of, okay, well, we're going to take on tech debt here.

We're going to take on product debt here, we're going to go do something that we know is not integrated. Um, We're going to let this GM run ahead and go do something that we know we're going to have to go fix later, but it's imperative from a competitive dynamic that we not wait and don't let, what was the quote, perfect be the enemy of done or whatever like that.

, , Um, and so it's, it's balancing all of those things.

Brett: So how did you think about sort of setting an annual goal or orientation for the company when. It almost sounds like, to a certain degree, you ended up with a collection of companies, a company that's in service of the beauty space, a company that's an operating system for restaurants, which obviously have a lot of similar common shared infrastructure.

But how do you align a whole company and get a sense of kind of cohesion on on like an annual cadence?

Alyssa: I think it's large in terms of, just the, breadth of the product ecosystem or the breadth of the business, then it is the number of employees, right?

And so I think the complexity comes in when it's when it's multiple products serving, different personas, right? Different customers. And then that's the complexity you have to manage.

And I think, it's hard to get down to any one thing because you end up with the least common denominator, that it ends up being some financial goal or something that, you know, well, I can't move the needle on that or, you know, whatever. 

 It's usually, hey, here's a set of themes or, there was always a set of three, or three themes that we had every year, strategic priorities and not every team fit into every one of the priorities was never just one because of the breath that we had, but every team fit into, let's say, one or two of the overall priorities and understood how their work laddered to that, even if banking didn't apply as a priority, didn't apply to, the Square email marketing team. 

Brett: What's like an example of of an annual theme?

Alyssa: Omnichannel was a theme, for a number of years. Square started as a, as a, you know, in person payments. Very clear. We all know this as consumers. We want omni channel experiences from the businesses we do business with. I want to, before I drive down to go, um, look at your shop are you selling the kind of product that I want, can I go look and see what your inventory is online?

And then I may choose to then go drive to your store. Cause I don't want to wait for you to ship it to me, but I want to know. Do you carry X, Y, or Z? And I don't really want to call you on the phone and ask you. And so there's all these things that we know on each animal matters and other companies started in the online world and you're seeing them then go, okay, driven by customer demand, adding, in person, we started in person.

We were driving, expanding into online. And so that was a thematic priority that, touched many, many teams. Obviously, the pandemic threw fuel on that fire as well, too. And, and pushes even harder there. So that was a theme. Um, international theme too, you know, that's another one where, you know, individual product areas or businesses will go, I don't know why I would go build feature X, Y, or Z for market, you know, one, two, or three, because there's so few customers there. It's like, you get into chicken and egg, like, well, we're never going to have any customers there if we don't have the features that serve that market. And so some of the stuff is then you just kind of top down and go, yeah, I know if you were making the decision on your own, you would not prioritize these things.

You get to, You get to prioritize a set of things and there's a set of over the top things that get prioritized for you, where we're trying to make the whole greater than the sum of the parts.

Brett: hmm. Switching gears slightly, what have you learned about competition? And I'm particularly curious to ask you, because certainly in the context of Microsoft and Amazon, the story I tell myself is they were incredible competitors.

And certainly when Gates back in the day was running Microsoft, I can't think of a more competitive company. And, and I don't know exactly how you would articulate it in the context of, Square and then Block, but certainly as the company matured, it went into probably the most competitive, generally low margin sort of category that you could be in.

So does anything come to mind, around how you think about operating in a competitive market or the role of competition on, strategy or product roadmap or sort of anything else?

Alyssa: well, We talked a little bit earlier about,kind of this notion of companies they're excellent pioneers or they're excellent fast followers. Very few are able to do both well. I think again, Microsoft and Amazon are interesting in that,Microsoft is an incredible fast follower.

Very, very good at seeing something, happening out in the landscape and going, we're going to do better, cheaper, faster. As a fast follower, I mean, you have to just, competition has to just seep from here because it's all you, you're defined by, you're defined by the competition, right?

And frankly, in the absence of competition, the company struggles, right? Because you, you're, you, you're defined by competition. So if you've won, and Microsoft, I think part of the malaise for a number of years was it kind of won in, in its key markets. And it's like, okay, now what? 

I think Amazon, at its core in its DNA is more of a pioneer, definitely. And not that Microsoft didn't pioneer and didn't innovate it and not that, you know, Amazon, didn't try to follow on things,or didn't like, you know, I think some of the, devices and mobile phones and some of these other things, like I think Amazon had a struggle being a fast follower or just a follower because it didn't, none of the operating mechanisms and everything in the company really built to follow.

They were all built from,pioneering something. And I think one of the key differences when you're a pioneer, There's less of a difference between minimal viable product and minimal remarkable product because there aren't other viable products in the marketplace.

So if you're new, and if it's viable at all, the reason it's viable is because it's remarkable. But if you're a follower, going into an existing space, they're different, right? You can't say, oh, we launched this thing and it does all the basic things. Like it does all the minimal things that somebody needs.

The marketplace is going to go, so what? I got other options. Why would I bother switching and finding about your new thing? It's not 10 X better, you know, it does it, like it's not better, cheaper, faster kind of thing, like, don't care. And so it is interesting because companies kind of fall in one or the other.

And that was one of the interesting things with Square. In the kind of cultures, that the little white reader was very much a minimal. It was a minimum viable product for sure, but because it was new and there's nothing else like it. And, it was all in that white space.

It was also a minimal remarkable product. And in fact, if you look at the, like the very early ones, it wasn't elegant design. It wasn't like, none of that had been refined yet. But the fact that you could do something that you couldn't have done before, and it really was minimally viable, but it was also minimally remarkable so companies kind of falling into two categories.

As you go and expand into new areas though, that's always the struggle, right? The culture had been built initially on this product where, it was a pioneer product. There weren't other things in the space. You like, you could operate in different ways to moving into these spaces where, as you like, very, very crowded, right? The bar for minimum is very high. And there's so much other competition in the space that stand out, right? You really have to do pretty different things. then just match the feature set for everything else.But those are again, culturally, they're very different.

Brett: So what did that look like? 

Alyssa: Well, you get teams, they're going, well, look, you know, hey, we shipped this kind of half ass thing before. And that found in the, you know, it was half ass when we, when the company launched or we've had some other, half ass products, found amazing traction they were all in basically white space. Even like kind of our original lending product. Same thing. It was very much into white space, right? But then you launch a payroll product it's like, it's not taking off. There's nothing about it that, you know, makes it look really any different than some of the other places in the space.

And so the teams have to rethink about,well, how do you, how do you build a roadmap? How do you, where and how are you going to differentiate? Or are you going to try to play that fast follower playbook? In which case, tell me how you're better, cheaper, faster.

Brett: And so did, did you find there was a specific subset of talent that was much better suited on going after the Red Ocean opportunities?

Alyssa: Yeah, they're definitely different things. And that goes back to part of the reason why, you know, organizing in different teams and moving away from a pure functional organization, I think helps as well, because it really, you need, you need different people.

Brett: Going back to sort of the point around Amazon as a, company that tends to be more pioneering. It doesn't immediately seem like an intuitive thing that a company should do. Like, Cash App is right on the edge of what would make sense, but it's in sort of the same vein. Most of what Microsoft has done, at least in the enterprise over the last handful of years, makes sense. That's an example of like a pioneering thing that doesn't start with what is, traditionally an unfair advantage.

And so I'm interested in like, what the story was there and what was interesting about that?

Alyssa: AWS, it was small when I joined, but it predate, like it existed, predated me. S3 was a little less than a year since public launch when I joined. So I can't firsthand tell you,exactly all what happens, but, there were a couple of things from my understanding. First, even when I joined AWS, a lot of where it started, kind of the first stage of AWS services, I think, are not even branded AWS anymore, but we're the e commerce APIs. And so it actually, it explains how Jassy got there as well, too. In that he was on the marketing side and he ran a bunch of the affiliate marketing stuff at one point. So in order for third party websites to merchandise Amazon's products.

They needed to be able to call a set of APIs in order to get, information on, what the cover of the book looked like and what the price was and,and a bunch of other stuff. And so that's what the company initially built, these kind of public APIs, in order to support the affiliate marketing program and e-commerce.

And so that was kind of the bulk of it. And that was actually the bulk of the employees when I joined AWS,But through that,

they were talking to a lot of customers. They're talking to all these website owners, right? 

Brett: And this was when website owners wanted to list their merchandise on AWS or it's the reverse, sorry, on Amazon or it's the reverse, when Amazon was powering a bunch of...?

Alyssa: So affiliate marketing, right? If I have, Alyssa's Cooking Site or something, right? I'm sharing these recipes, for, you know, my amazing meals and,I'm telling you how to make hummus and I'm saying you should put it in a food processor. And my favorite food processor is the Cuisinart Pro 13- 

Brett: And you're

linking back, yeah?

Alyssa: I'm linking back. And then if you're reading my website, you're like, oh, gosh, I really should get that Cuisinart.

And you click on that link. It has basically a cookie tag that goes, you go buy on Amazon. And then yeah, I get paid out on it. And so that was kind of the initial use case for it. All these website owners had a whole class of problems in terms of, the tools they needed to build their sites.

 I as, Alyssa's cookbook, you know, a website, I'm really not, caring about running a site really. And it's like, yeah, and go to Go Daddy and one of these places. But there's a bunch of these things, you know, storing my images, so all that kind of stuff. 

And then same thing internally with,with a lot of the teams. So Amazon pretty decentralized and how, you know, on the retail side teams ran, and we were seeing this pattern of, again, all the teams within the company reinventing the wheel, like having to build image storage, for this and this and this, and for this category and that category, for the target website, in addition to the retail website or whatever.

And so I think it was a pattern matching across both internal customers and external customers going, hey, there's a set of these core things that, all these teams and all these, third parties are doing that have nothing to do with what they're actually trying to accomplish. It's just this, the undifferentiated heavy lifting.

And so I started looking into that and found the opportunity and sized it and said, yeah, gosh, this could be interesting. We could help ourselves and we can help these customers that we're talking to and let's give it a go.

Brett: Did part of the reason it work is it goes back to, it was a white space at the time?

Alyssa: It was sort of a way, it's interesting. You know, Sun had tried, a model sort of like this, but their target audience probably looked more like a classic set. Like the customers, quote, they were talking to, look more like classic Sun customers. And so they were talking about, you know, basically time sharing and share and that kind of stuff.

 They never really got traction on it. Microsoft was, had been talking a little bit about it. I remember we were, you know Salesforce had launched. And so they were running, I don't know if it was even called cloud at the time. 

You know, We were having debates like, would anyone ever wanted to have somebody else, you know, run or manage or host their, their database for them. And that, so there were some of that, but there was a lot of kind of innovators dilemma, disbelief, that kind of thing. There was white space because, kind of neither Sun or Microsoft, both of them were kind of looking at it or had attempted things, but it kind of never really got it going.

Both of them had innovators dilemma a little bit in that it would, what AWS ultimately came out with, is much about a, a business model innovation as it was a tech innovation, right? It was the ability, to pay as you go and rent slices, whether it was a slice of storage or as a slice of compute or whatever, and not have to commit up front for the whole thing and doing it at, pretty low margins. Where both Microsoft and Sun were sitting on pretty hefty margins for their pieces. And so, this was white space and opportunity and margin expansion.

Brett: That point is really interesting. So is it the idea of selling the marginal unit or on demand sort of computer storage. Did those ideas come from understanding what the customer wanted? Or was it like, I think there's an opportunity here and someone just came up with, let's switch the business model here.

Alyssa: Honestly, I don't, I wasn't there, predates me. 

So the team that, the cost center code, if you will, the team that I joined when it was AWS was called, utility computing. And so when I joined EC2 hadn't even launched yet. S3 had launched and actually Uh, Mechanical Turk and SQS had launched. Right. But the name and the, and, you know, if you look at some of the early presentations and everything like that, you know, it's the analogy to electricity.

Again, I think it goes back to this. I think it was thinking about this analogy of, you know, compute, and computing is really just this fundamental utility that's undifferentiated. That should, should operate like a utility. How do utilities bill? All utilities, you know, they meter what you do and they bill for what you use and not what you do.

And so I think it was, drawing that analogy to these things. And I don't know how much of it was, they decided to do this and then match the analogy to what was decided or came up with the mental model and then the business from there. I don't know for sure.

Brett: When you joined the team, was the trajectory and vision set that people had high confidence that this was going to be an extraordinary business or it was like a science project?

Alyssa: It was a science project. It was funny when I, I was running decent sized team, ordering. It was like the pipeline, you know, once you checked out, it was kind of everything from like, okay, do you have funds? Can we authorize your card? Can we plan the inventory all the way down to injecting inventory into the filament centers or whatever?

And it was kind of like the center of like the big business and everything. Um, when I looked at going over to, AWS, folks are like, God, Alyssa, what happened? What are you doing? That's total career suicide. What are you doing over there? Like, We thought you were doing really well over here.

Like, it looks like you just got seriously demoted, right? Like, you know, and,there was externally, the business week article, the title, you know, Amazon's risky bet. But internally it was not, it was considered a risky bet. It was like, why, you know, why is Jeff putting money into this thing?

Like we're strapped in other areas. Like it's never going to pay off. you know, It's another random founder idea, right? You know, and, and early on too, it would be like, the margins were, it was a loss making, we weren't making money, um, and it required a fair bit of CapEx.

Brett: so why did you want to go work on that?

Alyssa: I'd been thinking about, going to Amazon, I, interviewed, because I wanted to learn how to run an internet scale business and I'd seen the promotion processes within Amazon or within Microsoft There were no women at the VP level that either weren't in, HR or finance, or legal, or that hadn't, basically come in and hired in at that level. There's no one that had been promoted in there. And there were people that had been at Microsoft and left, done some stuff and then get hired back,

um, you know, Or had started companies and their company got acquired. it was pretty clear that like there wasn't an internal path. And pretty clear this internet thing was going to be big. At the time Microsoft's only internet service was MSN.

And it's like, okay, well, that's not exactly, a shining beacon of, um, well, we'd acquired Hotmail as well, but that was kind of a separate thing down in Silicon Valley that wasn't really connected to the rest of the company. And so I figure, well, you know, I'm gonna go like, if Amazon's want to hire me to run the core of their Internet business that all their revenues running through that could be interesting, but I don't want to work in I. T. and I don't want to work in a company that,it's like I'd done my I.T thing. I'd started at Microsoft there. I didn't want to go back to that. Well, the day I got my offer from Amazon that I was considering, like, do I want to leave Microsoft to do that or not?

It was the day as S3 launched. And,one, I saw, I'm like, oh my God, that's cool. But it also like it, it blew up a bunch of the internal forums within the company where,a bunch of these, internal chat groups where everyone was like, looking at it. And going, how the hell did they do that?

These prices make absolutely no sense. You can't actually sell this for this much. What are they doing? And everyone's like, when Microsoft would never sell anything for a loss, right? So again, go back to internal DNA and the company, right? That's not quite true because eventually like the XBox,but the business that was still a razor and razor blades model.

And so we were like folks like James Hamilton, who eventually then moved over AWS. 

Brett: He has great hair.

Alyssa: He does, he could have been in a rock band. But, uh, you know,here's the back of the envelope math on some of the stuff on like have bandwidth prices or whatever.

It's like, how the hell are you doing, right? But anyway, so the day I got my offer and I'm like, okay,clearly Amazon's clearly got, more then, more than just a retailer, it clearly thinks of itself as a technology company, because no retailer in the right mind would ever watch something like this.

I'll go and then maybe someday I'll have the opportunity to work on S3. So less than a year later, I did.

Brett: Now that you have the benefit of hindsight, why did it work so well, or, what were the things that, the company got right that allowed it to blossom into like one of the most valuable businesses in the world?

Alyssa: Some of that is strategy, some is planning, some is luck. I think there are a couple of things. One,

AWS made a very explicit decision,very early on in terms of deciding which customers to focus on. 

So, I think one of the smart decisions that AWS made was, was the explicit decision focus on on startups,rather than enterprises, and I think that it was smart in a couple of different ways.

One is, I think I mentioned earlier that one of the big differentiation, was as much about business model as it was about functionality in that, it was the pay as you go, sign up with a credit card, get going, no large upfront expenditure. if you're an early stage company bootstrapping, you got, some seed money or whatever, right?

The dollars are precious. You don't know what's going to work. Would you rather, get up and running and try something and iterate on it? Or would you like to upfront commit to coal lease for a year and this many Sun servers and, your Oracle database license and all that?

 Whereas if you're an enterprise, it's like, there's a lot more certainty you kind of, you've got, you got S3 budget. Okay, well, I don't really care if I'm paying, day by day or month by month. 

Brett: Well, enterprise also likes certainty. 

Alyssa: Totally. Yeah, the business model innovation, it literally was an innovation, was much better fit for the startup customer than the enterprise customer.

And then sales cycles are faster. And I think, the, in the startup space is again, it was a, it was a feature to be able to just go online, sign up, try it, get going. Developers didn't have to go ask anyone, you know, you didn't have to have a big, you didn't have to have lawyers get together to, you know, agree on the contract terms and all that kind of stuff.

And so we really kind of got going and, and served need. And it was, fascinating early on how, again, just these really, very basic primitive services, particularly like S3, got used. And yeah, as my team would tell me when I first joined, abused. S3, Simple Storage Service was, was designed as a storage service, but internet connected and accessible.

So, you know, one of our first internal customers was,that Amazon Media team, and we were storing media files and whatnot for them. And then they were using them and then serving them to the website, but we were basically the origin store for them. And there was a separate CDN that sat on top of it and everything. When S3 launched, it was internet accessible and it worked as an origin store, but because it was internet accessible and you could pay as you go and Akamai was just as hard to deal with as any other enterprise software vendor and everything, we started getting all these customers using us, not just as the origin store, but as a CDN.

 My first job, my first task when I joined the team was to go figure out pricing, because requests, were free at the time, our bandwidth was cheap, it was cheaper than what you could get without scale. It was cheaper than what you get at Akamai, because Akamai wouldn't even talk to customers at small scale, like you're small, our sales team can't engage with you, won't do it. And so we were getting hammered, with requests.

In fact, Twitter was using us, for all of their, thumbnail pictures, uh, all their profile pictures. It launched kind of right around the same time, as S3 did, and they, they had used, uh, maybe slightly after, and they'd used to store all the images. And then we were serving directly out of S3 and we were just getting, From them and others getting hammered with these requests for a system that was not built wasn't intentionally built to handle high request rates.

And so it would overload some of the servers. And so there's, like, it would, it would cause outages. So the service was going down and we weren't getting paid because, like, these profile images were coming in. Took no storage and because they were small, there was no bandwidth, but the request costs were really high, but we didn't charge for them.

So it was figuring all that out. But then it also was fascinating because then it's like, well, clearly there's a market gap here. Cause it's like, why this is not intended to be a CDN. It's an okay, but not great CDN. So clearly there's, there's,there's white space in this market for a CDN. And so that's when we actually, we started designing and then building CloudFront, which is AWS out of the S3 team because it's all this adjacency and I think the story kind of went like that for a lot of things.

Is that how most of the building blocks... So many them, I think there two modes and I actually think of AWS is actually kind of having two discrete stacks. The EC2 EBS kind of class of services RDS, which basically it's, we're going to take open source, we're going to frack, we're going to host it,

and we're going to meter bill you. So it's, it's,there's definitely, from managing multi tenancy, there's technology innovation, but not necessarily at the core infrastructure level, because it's repurposing open source software at the infrastructure level. And then layering on technology for multi tenancy and then for pay should go billing. And there's a class of services, and so a lot of the stuff that comes out of that space is looking about what's happening in the open source world and going, oh, this thing's catching on there. Okay, well, how do we take it? And then apply multi tenancy and then apply the AWS building model and that kind of thing.That's kind of one path that things come out and then kind of what I think of as kind of the second stack, S3, there was simple DB at the time and that got replaced with DynamoDB. kind of class of services in there, where a lot of it is seeing, it's looking at application patterns and customers aren't asking for a particular thing. but you kind of see how they're using and in some ways, abusing, services and you go like, oh, gosh, they're trying to do X, Y or Z, yay. We should go build a service for that. so I wrote the original paper for Lambda, which is the serverless computing platform and, pitched, uh, to go do it, it actually took me three or four years through before I got it funded in the annual planning process. But it was one of the things where it's like, we don't have a compute service in this other sort of fully managed stack and you can see customers building these applications where, you know, they able to use, you know, S3, they're able to use Dynamo, they can use CloudFront, but then they have to dump into this other thing, for compute where they don't need full time instances. so. I think the innovation comes in kind of different places and you end up with sort of different patterns on on how you go do it. 

 so some is more community based and some is more kind of pattern matching and understanding a net needs of customers. 

When you were building in the earlier days of AWS, was it always clear that it was going to be building blocks basically sold to developers? Cause at the same time, I would imagine at the application level, you also had all sorts of issues with people trying to build websites and apps and. Was there ever sort of thought about basically going up the stack or it was just the developers, basically the buyer, we're starting with startups and that's who we're building for. was definitely building blocks was the, core of it. I mean, if you looked at the original AWS logo, right? it's like, it's a set of blocks, right? but we started looking at the application space, and had debates on that.

 and then ultimately hired some folks and started building out basically, Working on the equivalent of the Microsoft office suite. Some of it's out there. So like some of it's gone well, some are not. So again, not so good at following. Yeah. I don't know if you've used Chime.

It's not my favorite of all of the, I think it's a, it's a distant behind Zoom and Google meets and Teams and...

Brett: That is, that's such an interesting insightaround, uh, you kind of have the dominant hand, you know, pioneer or fast follow. 

Maybe to wrap up, uh, I'm always curious, and I think you'll have an interesting answer because you've worked with so many extraordinary people along the, the journey of building companies.

Are there folks that have had like a disproportionate impact on the way that you see the world? 

Clearly, there's lots of different people. Right. And, it's always interesting thinking and learning patterns and anti patterns. So, there's the things that, oh, I would want to emulate that. And there's the things I would not want to emulate or this is, you know... 

Knowing what not to do can be equally as useful. 

Alyssa: They really can, um, it's going to sound trite, I guess, but if I were to pick one, um, like Bezos really is just like Gates as well, though, I didn't get nearly as much as exposure to him, as I did,you know, I had some meetings, but, uh, I was much further earlier in my career for the, down the organization and that kind of thing. Bezos has framework, like he really thinks in terms of frameworks and has been good about articulating things like, you know, one way for show the doors, right. Yeah. A bunch of these sorts of things. So, get big fast was the mantra, you know, When I joined the company or rallying cry and how important, like he just, kind of burned the bridges, if you will, we're going to go and we, we're we're going to tell our shareholders, you know, we're going to go burn a lot of money.

We're going to go grow and we're going to get big. And if this is a, if that's the right, the one beyond great. And if it's not, this is not the company for them. So I think there's just a lot of insights and things that they think had, had an Outsized impact on my thinking, just in terms of where I was in my stage of the career.

Brett: in getting to, to work with him, were there, there were so many things, obviously in annual letters and he's, he's shared in terms of different frameworks, working backwards from the customer, day one thinking, et cetera, et cetera. 

 Are there things that you kind of picked up that are not part of like the sort of public narrative around him or ideas that has kind of been open source to a certain degree?

Alyssa: I think a lot of it has been open sourced. you know, I think there's always a fair bit of transparency around those sorts of things. In many ways, it's the secret sauce, but also wasn't secret at all, But it goes back to, can you really build the mechanisms?

Can you embed it into the organization? not everyone can, and it's probably not appropriate for every organization as well, either. 

Brett: Is what enabled that the kind of uncanny ability to take these squishy abstract ideas and come up with a language that makes them sit in people's brains in a specific way? 

Alyssa: I think that's some of it. I think it's also just the talent density. It was just incredible. and the whole S team, like. Incredibly smart, right? you sit in the room, like, with Bezos, like Bezos is, um, Tom Skutek, right? Always they're kind of together, uh, both of, you know, CFO, you know, super bright and, you, you present something and they'd be going back and forth on it and you just.

It's just the IQ super high. You get in a room with Wilkie and um, you know, and Jeff Williams is Wilkie alone. Right. Again. the talent density and the, and the kind of everyone sharpened each other's help sharpen each other's pencil, which you don't see 

everywhere. 

Cool. Well, thank you so much for sharing with us. 

Well Brett. It's been fun.

Good to see you again.