Podcasts about randy oh

This episode originally aired on Software Engineering Radio.Randy Shoup is the VP of Engineering and Chief Architect at eBay. He was previously the VP of Engineering at WeWork and Stitch Fix, a Director of Engineering at Google Cloud where he worked on App Engine, and a Chief Engineer and Distinguished Architect at eBay in 2004. Topics covered: eBay's origins as a single C++ class The five-year migration to Java services Sharing a database between the old and new systems Building a distributed tracing system Working with bare metal Why most companies should stick to cloud Why individual services should own their own data storage How scale has caused solutions to change Rejoining a former company The Accelerate Book Improving delivery time.  Related Links:@randyshoupOpenTelemetryLightStepHoneycombAccelerate BookThe MemoValue Stream MappingThe Epic Story of Dropbox's Exodus from the Amazon Cloud EmpireTranscript:[00:00:00] Jeremy: Today, I'm talking to Randy Shoup, he's the VP of engineering and chief architect at eBay.[00:00:05] Jeremy: He was previously the VP of engineering at WeWork and stitch fix, and he was also a chief engineer and distinguished architect at eBay back in 2004. Randy, welcome back to software engineering radio. This will be your fifth appearance on the show. I'm pretty sure that's a record.[00:00:22] Randy: Thanks, Jeremy, I'm really excited to come back. I always enjoy listening to, and then also contributing to software engineering radio.Back at, Qcon 2007, you spoke with Markus Volter he's he was the founder of SE radio. And you were talking about developing eBay's new search engine at the time.[00:00:42] Jeremy: And kind of looking back, I wonder if you could talk a little bit about how eBay was structured back then, maybe organizationally, and then we can talk a little bit about the, the tech stack and that sort of thing.[00:00:53] Randy: Oh, sure. Okay. Yeah. Um, so eBay started in 1995. I just want to like, you know, orient everybody. Same, same as the web. Same as Amazon, same as a bunch of stuff. So E-bay was actually almost 10 years old when I joined. That seemingly very old first time. Um, so yeah. What was ebay's tech stack like then? So E-bay current has gone through five generations of its infrastructure.It was transitioning between the second and the third when I joined in 2004. Um, so the. Iteration was Pierre Omidyar, the founder three-day weekend three-day labor day weekend in 1995, playing around with this new cool thing called the web. He wasn't intending to build a business. He just was playing around with auctions and wanted to put up a webpage.So he had a Perl backend and every item was a file and it lived on this little 486 tower or whatever you had at the time. Um, so that wasn't scalable and wasn't meant to be. The second generation of eBay's architecture was what we called V2 very, you know, creatively, uh, that was a C++ monolith. Um, an ISAPI DLL with essentially well at its worst, which grew to 3.4 million lines of code in that single DLL and basically in a single class, not just in a single, like repo or a single file, but in a single class.So that was very unpleasant to work in. As you can imagine, um, eBay had about a thousand engineers at the time and they were, you know, as you can imagine, like really stepping on each other's toes and not being able to make much forward progress. So starting in, I want to call it 2002. So two years before I joined, um, they were migrating to the creatively named V3 and V3 architecture was Java, and.you know, not microservices, but like we didn't even have that term, but it wasn't even that it was mini applications. So I'm actually going to take a step back. V2 was a monolith. So like all of eBay's code in that single DLL and like that was buying and selling and search and everything. And then we had two monster databases, a primary and a backup big Oracle machines on some hardware that was bigger, you know, bigger than refrigerators and that ran eBay for a bunch of years, before we changed the upper part of the stack, we, um, chopped up the, that single monolithic database into a bunch of, um, domain specific databases or entity specific databases, right?So a set of databases around users, you know, sharded by the user ID could talk about all that. If you want, you know, items again, sharded by item ID transactions, sharded by transaction ID... I think when I joined, it was the several hundred instances of, uh, Oracle databases, um, you know, spread around, but still that monolithic front end.And then in 2002, I wanna say we started migrating into that V3 that I was saying, okay. So that's, uh, that was a rewrite in Java, again, many applications. So you take the front end and instead of having it be in one big unit, it was this, uh, ER file, EAR, file, if run and people remember back to, you know, those stays in Java, um, you know, 220 different of those.So like here is the, you know, one of them for the search pages, you know, so the, you know, one application be the search application and it would, you know, do all the search related stuff, the handful of pages around search, uh, ditto for, you know, the buying area, ditto for the, you know, checkout area, ditto for the selling area...220 of those. Um, and that was again, domain, um, vertically sliced domains. And then the relationship between those V3, uh, applications and the databases was a many to many things. So like many applicants, many of those applications interact with items. So they would interact with those item databases. Many of them would interact with users.And so they would interact with a user databases, et cetera, uh, happy to go into as much gory detail as you want about all that. But like, that's what, uh, but we were in the transition period. You know, when I, uh, between the V2 monolith to the V3 mini applications in, uh, 2004, I'm just going to pause there and like, let me know where you want to take it.[00:05:01] Jeremy: Yeah. So you were saying that it was, um, it started as Perl, then it became a C++, and that's kind of interesting that you said it was all in one class, right? So it's wow. That's gotta be a gigantic [00:05:16] Randy: I mean, completely brutal. Yeah. 3.4 million lines of code. Yeah. We were hitting compiler limits on the number of methods per class.[00:05:22] Jeremy: Oh my gosh.[00:05:23] Randy: I'm, uh, uh, scared that I have that. I happen to know that at least at the time, uh, Microsoft allowed you 16 K uh, methods per class, and we were hitting that limit.So, uh, not great.[00:05:36] Jeremy: So it's just kind of interesting to think about how do you walk through that code, right? You have, I guess you just have this giant file.[00:05:45] Randy: Yeah. I mean, there were, you know, different methods. Um, but yeah, it was a big man. I mean, it was a monolith, it was, uh, you know, it was a spaghetti mess. Um, and you know, as you can imagine, Amazon went through a really similar thing by the way. So this wasn't soup. I mean, it was bad, but like we weren't the only people that were making that, making that a mistake.Um, and just like Amazon, where they were, uh, they did like one update a quarter (laughs) , you know, at that period, like 2000, uh, we were doing something really similar, like very, very slow. Um, you know, updates and, uh, when we moved to V3, you know, the idea was to get to do changes much faster. And we were very proud of ourselves starting in 2004 that we, uh, upgraded the whole site every two weeks.And we didn't have to do the whole site, but like each of those individual applications that I was mentioning, right. Those 220 applications, each of those would roll out on this biweekly cadence. Um, and they had interdependencies. And so we rolled them out in this dependency order in any way, lots of, lots of complexity associated with that.Um, yeah, there you go.[00:06:51] Jeremy: the V3 that, that was written in Java, I'm assuming this was a, as a complete rewrite. You, you didn't use the C++ code at all.[00:07:00] Randy: Yeah. And, uh, it was, um, we migrated, uh, page by page. So, uh, you know, in the transition period, which lasted probably five years, um, there were pages, you know, in the beginning, all pages were served by V2. In the end, all pages are served by V3 and, you know, over time you iterate and you like rewrite in parallel, you know, rewrite and maintain in parallel the V3 version of XYZ page and the V2 version of XYZ page.Um, and then when you're ready, you start to test out at low percentages of traffic, you know, what would, what does V3 look like? Is it correct? And when it isn't do you go and fix it, but then ultimately you migrate the traffic over, um, to fully take, get fully be in the V3 world, and then you, you know, remove or comment out or whatever.The, the code that supported that in the V2 monolith.[00:07:54] Jeremy: And then you had mentioned using Oracle databases. Did you have a set for V2 and a separate V3 and you were kind of trying to keep them in sync?[00:08:02] Randy: Oh, great question. Thank you for asking that question. No, uh, no. We had the databases. Um, so again, as I mentioned, we had pre-demonolith that's my that's a technical term, uh, pre broken up the databases starting in, let's call it 2000. Uh, actually I'm almost certain that's 2000. Cause we had a major site outage in 1999, which everybody still remembers who was there at the time.Uh wasn't me or I wasn't there at the time. Uh, but you know, you can look it up. Uh, anyway, so yeah, starting in 2000, we broke up that monolithic database into what I was telling you before those entity aligned databases. Again, one set for items, one set for users, one set for transactions, you know, dot dot, dot, um, and that division of those databases was shared.You know, those databases were shared between. The three using those things and then V sorry, V2 using those things and V3 using those things. Um, and then, you know, so we've completely decoupled the rewrite of the database, you know, kind of data storage layer from the rewrite of the application layer, if that makes sense.[00:09:09] Jeremy: Yeah. So, so you had V2 that was connecting to these individual Oracle databases. You said like they were for different types of entities, like maybe for items and users and things like that. but it was a shared database situation where V2 was connected to the same database as V3. Is that right?[00:09:28] Randy: Correct and also in V3, even when done. Different V3 applications, were also connecting to the same database, again, like anybody who used user, anybody who used the user entity, which is a lot we're connecting to the user suite of databases and anybody who used the item entity, which again is a lot, um, you were connecting to the item databases, et cetera.So yeah, it was this many to many that's, I'm trying to say many to many relationship between applications in the V3 world and databases.[00:10:00] Jeremy: Okay. Yeah, I think I, I got it because[00:10:03] Randy: It's easier with a diagram.[00:10:04] Jeremy: yeah. W 'cause when you, when you think about services now, um, you think of services having dependencies on other services. Whereas in this case you would have multiple services that rather than talking to a different service, they would all just talk to the same database.They all needed users. So they all needed to connect to the user's database.[00:10:24] Randy: Right exactly. And so, uh, I don't want to jump ahead in this conversation, but like the problems that everybody has, everybody who's feeling uncomfortable at the moment. You're right. To feel uncomfortable because that wasn't unpleasant situation and microservices, or more generally the idea that individual services would own their own data.And only in the only are interactions to the service would be through the service interface and not like behind the services back to the, to the data storage layer. Um, that's better. And Amazon discovered that, you know, uh, lots of people discovered that around that same, around that same early two thousands period.And so yeah, we had that situation at eBay at the time. Uh, it was better than it was before. Right, right. Better than a monolithic database and a monolithic application layer, but it definitely also had issues. Uh, as you can imagine,[00:11:14] Jeremy: you know, thinking about back to that time where you were saying it's better than a monolith, um, what were sort of the trade-offs of, you know, you have a monolith connecting to all these databases versus you having all these applications, connecting to all these databases, like what were the things that you gained and what did you lose if that made sense?[00:11:36] Randy: Hmm. Yeah. Well, I mean, why we did it in the first place is develop is like isolation between development teams right? So we were looking for developer productivity or the phrase we used to use was feature velocity, you know, so how quickly would we be able to move? And to the extent that we could move independently, you know, the search team could move independently from the buying team, which could move independently from the selling team, et cetera.Um, that was what we were gaining. Um, what were we losing? Uh, you know, when you're in a monolith situation, If there's an issue, you know, where it is, it's in the monolith. You might not know where in the monolith. Um, but like there's only one place that could be. And so an issue that one has, uh, when you break things up into smaller units, uh, especially when they have this, you know, shared, shared mutable state, essentially in the form of these databases, like who changed that column?What, you know, what's the deal. Uh, actually we did have a solution for that or something that really helped us, which was, um, now 20, more than 20 years ago, we had something that we would now call distributed tracing where, uh, actually I talked about this way back in the 2007 thing, cause it was pretty cool, uh, at the time, uh, You know, just like the spans one would create using a modern distributed tracing, you know, open telemetry or, you know, any of the disruptive tracing vendors.Um, just like you would do that. We, we didn't use the term span, but that same idea where, um, we could, and the goal was the same to like debug stuff. So, uh, every time we were about to make a database call, we would say, Hey, I'm about to make this data, you know, we would log we about to make this database call and then it would happen.And then we would log whether it was successful or not successful. We could see how long it took, et cetera. Um, and so we built our own, you know, monitoring system, which, which we called central application logging or CAL, uh, totally proprietary to eBay. I'm happy to talk about whatever gory details you want to know about that, but it was pretty cool certainly way back in 2000.It was, and that was our mitigation against the thing I'm telling you, which is, you know, when something, when not. Something is weird in the database. We can kind of back up and figure out where it might've happened, or things are slow. What's, you know, what's the deal. And, uh, you know, cause sometimes the database is slow for reasons.Um, and what, which, what thing is, you know, from an application perspective, I'm talking to 20 different databases, but things are slow. Like what is it? And, um, CAL helped us to, to figure out both elements of that, right? Like what applications are talking to, what databases and what backend services and like debug and diagnose from that perspective.And then for a given application, what, you know, databases in backend services are you talking to? And, um, debug that. And then we have the whole, and then we, um, we, we had monitors on those things and we would notice when databases would, where be a lot of errors or where, when database is starting in slower than they used to be.Um, and then. We implemented what people would now call circuit breakers, where we would notice that, oh, you know, everybody who's trying to talk to database 1, 2, 3, 4 is seeing it slow down. I guess 1, 2, 3, 4 is unhappy. So now flip everybody to say, don't talk to 1, 2, 3, 4, and like, just that kind of stuff.You're not going to be able to serve. Uh, but whatever, that's better than stopping everything. So I hope that makes sense. Like, you know, so all these, all these like modern resilience techniques, um, we always had, we had our own proprietary names for them, but you know, we, we implemented a lot of them way back when,[00:15:22] Jeremy: Yeah. And, and I guess just to contextualize it for the audience, I mean, this was back in 2004. Oh it back in 2000.[00:15:32] Randy: Again, because we had this, sorry to interrupt you because we have, the problem is that we were just talking about where application many applications are talking to many services and databases and we didn't know what was going on. And so we needed some visibility into what was going on.Sorry, go ahead.[00:15:48] Jeremy: yeah. Okay. So all the way back in 2000, there's a lot less, Services out there, like nowadays you think about so many software as a service products. if you were building the same thing today, what are some of the services that people today would just go and say like, oh, I'll just, I'll just pay for this and have this company handle it for me. You know, that wasn't available, then[00:16:10] Randy: sure. Well, there. No, essentially, no. Well, there was no cloud cloud didn't happen until 2006. Um, and there were a few software as a service vendors like Salesforce existed at the time, but they weren't usable in the way you're thinking of where I could give you money and you would operate a technical or technological software service on my behalf.Do you know what I mean? So we didn't have any of the monitoring vendors. We didn't have any of the stuff today. So yeah. So what would we do, you know, to solve that specific problem today? Uh, I would, as we do today, I would, uh, instrument everything with open telemetry because that's generic. Thank you, Ben Siegelman and LightStep for starting that whole open sourcing process, uh, of that thing and, and, um, getting all the vendors to, you know, respect it.Um, and then I would shoot, you know, for my backend, I would choose one of the very many wonderful, uh, you know, uh, distributed tracing vendors of which there are so many, I can't remember, but like LightStep is one honeycomb... you know, there were a bunch of, uh, you know, backend, um, distributed tracing vendors in particular, you know, for that.Uh, what else do you have today? I mean, we could go on for hours on this one, but like, we didn't have distributed logging or we didn't have like logging vendors, you know? So there was no, uh, there was no Splunk, there was no, um, you know, any, any of those, uh, any of the many, uh, distributed log, uh, or centralized logging vendor, uh, vendors.So we didn't have any of those things. We didn't. like caveman, you know, we rent, we, uh, you know, had our own data. We built our own data centers. We racked our own servers. We installed all the OSS in them, you know, uh, by the way, we still do all that because it's way cheaper for us at our scale to do that.But happy to talk about that too. Uh, anyway, but yeah, no, the people who live in, I don't know if this is where you want to go in 2022, the software developer has this massive menu of options. You know, if you only have a credit card, uh, and it doesn't usually cost that much, you can get a lot of stuff done from the cloud vendors, from the software service vendors, et cetera, et cetera.And none of that existed in 2000.[00:18:31] Jeremy: it's really interesting to think about how different, I guess the development world is now. Like, cause you mentioned how cloud wasn't even really a thing until 2006, all these, these vendors that people take for granted. Um, none of them existed. And so it just, uh, it must've been a very, very different time.[00:18:52] Randy: Well, we didn't know. It was every, every year is better than the previous year, you know, in software every year. You know? So at that time we were really excited that we had all the tools and capabilities that, that we did have. Uh, and also, you know, you look back from, you know, 20 years in the future and, uh, you know, it looks caveman, you know, from that perspective.But, uh, it was, you know, all those things were cutting edge at the time. What happened really was the big companies rolled their own, right. Everybody, you know, everybody built their own data centers, rack their own servers. Um, so at least at scale and the best you could hope for the most you could pay anybody else to do is rack your servers for you.You know what I mean? Like there were external people, you know, and they still exist. A lot of them, you know, the Rackspaces you know Equinixes, et cetera of the world. Like they would. Have a co-location facility. Uh, and you, you know, you ask them please, you know, I'd like to buy the, these specific machines and please rack these specific machines for me and connect them up on the network in this particular way.Um, that was the thing you could pay for. Um, but you pretty much couldn't pay them to put software on there for you. That was your job. Um, and then operating. It was also your job, if that makes sense.[00:20:06] Jeremy: and then back then, would that be where. Employees would actually have to go to the data center and then, you know, put in their, their windows CD or their Linux CD and, you know, actually do everything right there.[00:20:18] Randy: Yeah. 100%. Yeah. In fact, um, again, anybody who operates data centers, I mean, there's more automation, but the conceptually, when we run three data centers ourselves at eBay right now, um, and all of our, all of our software runs on them. So like we have physical, we have those physical data centers. We have employees that, uh, physically work in those things, physical.Rack and stack the servers again, we're smarter about it now. Like we buy a whole rack, we roll the whole rack in and cable it, you know, with one big chunk, uh, sound, uh, as distinct from, you know, individual wiring and the networks are different and better. So there's a lot less like individual stuff, but you know, at the end of the day, but yeah, everybody in quotes, everybody at that time was doing that or paying somebody to do exactly that.Right. Yeah.[00:21:05] Jeremy: Yeah. And it's, it's interesting too, that you mentioned that it's still being done by eBay. You said you have three, three data centers. because it seems like now maybe it's just assumed that someone's using a cloud service or using AWS or whatnot. And so, oh, go ahead.[00:21:23] Randy: I was just going to say, well, I'm just going to riff off what you said, how the world has changed. I mean, so much, right? So. Uh, it's fine. You didn't need to say my whole LinkedIn, but like I used to work on Google cloud. So I've been, uh, I've been a cloud vendor, uh, at a bunch of previous companies I've been a cloud consumer, uh, at stitch fix and we work in other places.Um, so I'm fully aware, you know, fully, fully, personally aware of, of all that stuff. But yeah, I mean, there's this, um, you know, eBay is in the, uh, eBay is at the size where it is actually. Cost-effective very, cost-effective, uh, can't tell you more than that, uh, for us to operate our own, um, uh, our own infrastructure, right?So, you know, you know, one would expect if Google didn't operate their own infrastructure, nobody would expect Google to use somebody else's right. Like that, that doesn't make any economic sense. Um, and, uh, you know, Facebook is in the same category. Uh, for a while, Twitter and PayPal have been in that category.So there's like this clap, you know, there are the known hyperscalers, right. You know, the, the Google, Amazon, uh, Microsoft that are like cloud vendors in addition to consumers internally have their own, their own clouds. Um, and then there's a whole class of other, um, places that operate their own internal clouds in quotes.Uh, but don't offer them externally and again, uh, Facebook or Meta, uh, you know, is one example. eBay's another, you know, there's a, I'm making this up. Dropbox actually famously started in the cloud and then found it was much cheaper for them to operate their own infrastructure again, for the particular workloads that they had.Um, so yeah, there's probably, I'm making this up. Let's call it two dozen around the world of these, I'm making this term up many hyperscalers, right? Like self hyperscalers or something like that. And eBay's in that category.[00:23:11] Jeremy: I know this is kind of a, you know, a big what if, but you were saying how once you reach a certain scale, that's when it makes sense to move into your own data center. And, uh, I'm wondering if, if E-bay, had started more recently, like, let's say in the last, you know, 10 years, I wonder if it would've made sense for it to start on a public cloud and then move to, um, you know, its own infrastructure after it got bigger, or if you know, it really did make sense to just start with your own infrastructure from the start.[00:23:44] Randy: Oh, I'm so glad you asked that. Um, the, the answer is obvious, but like, I'm so glad you asked that because I love to make this point. No one should ever, ever start by building your own servers and your own (laughs) cloud. Like, No, there's be, uh, you should be so lucky (laughs) after years and years and years that you outgrow the cloud vendors.Right. Um, it happens, but it doesn't happen that often, you know, it happens so rarely that people write articles about it when it happens. Do you know what I mean? Like Dropbox is a good example. So yes, 100% anytime. Where are we? 2022. Any time in, more than the last 10 years? Um, yeah, let's call it. Let's call it 2010, 2012.Right. Um, when cloud had proved itself over and you know, many times over, um, anybody who starts since that time should absolutely start in the public cloud. There's no argument about it. Uh, and again, one should be so lucky that over time, you're seeing successive zeros added to your cloud bill, and it becomes so many zeros that it makes sense to shift your focus toward building and operating your own data centers.That's it. I haven't been part of that transition. I've been the other way, you know, at other places where, you know, I've migrated from owned data centers and colos into, into public cloud. Um, and that's the, that's the more common migration. And again, there are, there are a handful, maybe not even a handful of, uh, companies that have migrated away, but when they do, they've done all the math, right.I mean, uh, Dropbox has done some great, uh, talks and articles about, about their transition and boy, the math makes sense for them. So, yeah.[00:25:30] Jeremy: Yeah. And it also seems like maybe it's for certain types of businesses where moving off of public cloud. Makes sense. Like you mentioned Dropbox where so much of their business is probably centered around storage or centered around, you know, bandwidth and, you know, there's probably certain workloads that it's like need to leave public cloud earlier.[00:25:51] Randy: Um, yeah, I think that's fair. Um, I think that, I think that's a, I think that's an insightful comment. Again, it's all about the economics at some point, you know, it's a big investment to, uh, uh, and it takes years to develop the intern, forget the money that you're paying people, but like just to develop the internal capabilities.So they're very specialized skill sets around building an operating data centers. So like it's a big deal. Um, and, uh, yeah. So are there particular classes of workloads where you would for the same dollar figure or whatever, uh, migrate earlier or later? I'm sure that's probably true. And again, what can absolutely imagine?Well, when they say Dropbox in this example, um, yeah, it's because like they, they need to go direct to the storage. And then, I mean, like, they want to remove every middle person, you know, from the flow of the bytes that are coming into the storage media. Um, and it makes perfect sense for, for them. And when I understood what they were doing, which was a number of years ago, they were hybrid, right. So they had, they had completely, you know, they kept the top, you know, external layer, uh, in public cloud. And then the, the storage layer was all custom. I don't know what they do today, but people could check.[00:27:07] Jeremy: And I'm kind of coming back to your, your first time at eBay. is there anything you felt that you would've done differently with the knowledge you have now?but with the technology that existed, then.[00:27:25] Randy: Gosh, that's the 20, 20 hindsight. Um, the one that comes to mind is the one we touched on a little bit, but I'll say it more starkly, the. If I could, if I could go back in time 20 years and say, Hey, we're about to do this V3 transition at eBay. I would not. I would have had us move directly to what we would now call microservices in the sense that individual services own their own data storage and are only interacted with through the public interface.Um, there's a famous Amazon memo around that same time. So Amazon did the transition from a monolith into what we would now call microservices over about a four or five-year period, 2000 to 2005. And there was a famous Jeff Bezos memo from the early part of that, where, you know, seven, you know, requirements I can't remember them, but you know, essentially it was, you may, you may, you may never, you may never talk to anybody else's database. You may only interact with other services through their public interfaces. I don't care what those public interfaces are, so they didn't standardize around. You know, CORBA or JSON or GRPC, which didn't exist at the time, you know, like they didn't standardize around any, any particular, uh, interaction mechanism, but you did need to again, have this kind of microservice capability, that's modern terminology, um, uh, where, you know, the only services own their own data and nobody can talk in the back door.So that is the one architectural thing that I wish, you know, with 2020 hindsight, uh, that I would bring back in my time travel to 20 years ago, because that would help. That does help a lot. And to be fair, Amazon, um, Amazon was, um, pioneering in that approach and a lot of people internally and externally from Amazon, I'm told, didn't think it would work, uh, and it, and it did famously.So that's, that's the thing I would do.[00:29:30] Jeremy: Yeah. I'm glad you brought that up because, when you had mentioned that, I think you said there were 220 applications or something like that at certain scales, people might think like, oh, that sounds like microservices to me. But when you, you mentioned that microservice to you means it having its own data store.I think that's a good distinction.[00:29:52] Randy: Yeah. So, um, I talk a lot about microservices that have for, for a decade or so. Yeah. I mean, several of the distinguishing characteristics are the micro in microservices is size and scope of the interface, right? So you can have a service oriented architecture with one big service, um, or some very small number of very large services.But the micro in microservice means this thing does, maybe it doesn't have one operation, but it doesn't have a thousand. The several or the handful or several handfuls of operations are all about this one particular thing. So that's the one part of it. And then the other part of it that is critical to the success of that is owning the, owning your own data storage.Um, so each service, you know, again, uh, it's hard to do this with a diagram, but like imagine, imagine the bubble of the service surrounding the data storage, right? So like people, anybody from the outside, whether they're interacting synchronously, asynchronously, messaging, synchronous, whatever HTTP doesn't matter are only interacting to the bubble and never getting inside where the, uh, where the data is I hope that makes sense.[00:31:04] Jeremy: Yeah. I mean, I mean, it's a kind of in direct contrast to before you're talking about how you had all these databases that all of these services shared. So it was probably hard to kind of keep track of, um, who had modified data. Um, you know, one service could modify it, then another service control to get data out and it's been changed, but it didn't change it.So it could be kind of hard to track what's going on.[00:31:28] Randy: Yeah, exactly. Inner integration at the database level is something that people have been doing since probably the 1980s. Um, and so again, I, you know, in retrospect it looks like caveman approach. Uh, it was pretty advanced at the time, actually, even the idea of sharding of, you know, Hey, there are users and the users live in databases, but they don't all live in the same one.Uh, they live in 10 different databases or 20 different databases. And then there's this layer that. For this particular user, it figures out which of the 20 databases it's in and finds it and gets it back. And, um, you know, that was all pretty advanced. And by the way, that's all those capabilities still exist.They're just hidden from everybody behind, you know, nice, simple, uh, software as a service, uh, interfaces anyway, but that takes nothing away from your excellent point, which is, yeah. It's, you know, when you're, again, when there's many to many to relations, when there is this many to many relationship between, um, uh, applications and databases, uh, and there's shared mutable state in those databases that when is shared, like that's bad, you know, it's not bad to have state.It's not bad to have mutable state it's bad to have shared beautiful state.[00:32:41] Jeremy: Yeah. And I think anybody who's kind of interested in learning more about the, you had talked about sharding and things like that. If they go back and listen to your, your first appearance on software engineering radio, um, yeah. It kind of struck me how you were talking about sharding and how it was something that was kind of unique or unusual.Whereas today it feels like it's very, I don't know, if quaint is the right word, but it's like, um, it's something that, that people kind of are accustomed to now.[00:33:09] Randy: Yeah. Yeah. Um, it's obvious. Um, it seems obvious in retrospect. Yeah. You know, at the time, and by the way, he didn't invent charting. As I said, in 2007, you know, Google and Yahoo and, uh, Amazon, and, you know, it was the obvious, it took a while to reach it, but it's one of those things where once, once people have the, you know, brainwave to see, oh, you know what, we don't actually have to stop store this in one, uh, database.We can, we can chop that database up into, you know, into chunks. And that, that looks similar to that herself similar. Um, yeah, that was, uh, that was, uh, that was reinvented by lots of, uh, Lots of the big companies at the same time again, because everybody was solving that same problem at the same time. Um, but yeah, when you look back and you, I mean, like, and honestly, like everything that I said there, it's still like this, all the techniques about how you shard things.And there's lots of, you know, it's not interesting anymore because the problems have been solved, but all those solutions are still the solutions, if that makes any sense, but you know,[00:34:09] Jeremy: Yeah, for sure. I mean, I think anybody who goes back and listens to it. Yeah. Like you said, it's, it's, it's very interesting because it's. it all still applies and it's like, I think the, the solutions that are kind of interesting to me are ones where it's, it's things that could have been implemented long ago, but we just later on realized like, this is how we could do it.[00:34:31] Randy: Well part of it is, as we grow as an industry, we just, we discover new problems. You know, we, we get to the point where, you know, sharding over databases has only a problem when one database doesn't work. You know, when it, when you're the load that you put on that database is too big, or you want the availability of, you know, multiple.Um, and so that's not a, that's not a day one problem, right? That's a day two or day 2000 and kind of problem. Right. Um, and so a lot of these things, yeah, well, you know, it's software. So like we could have done, we could have done any of these things in older languages and older operating systems and with older technology.But for the most part, we didn't have those problems or we didn't have them at sufficiently enough. People didn't have the problem that we, you know, um, for us to have solved it as an industry, if that makes any sense.[00:35:30] Jeremy: yeah, no, that's a good point because you think about when Amazon first started and it was just a bookstore, right. And the number of people using the site where, uh, who knows it was, it might've been tens a day or hundreds a day. I don't, I don't know. And, and so, like you said, the problems that Amazon has now in terms of scale are just like, it's a completely different world than when they started.[00:35:52] Randy: Yeah. I mean, probably I'm making it up, but I don't think that's too off to say that it's a billion times more, their problems are a billion fold. You know, what they, what they were[00:36:05] Jeremy: the next thing I'd like to talk about is you came back to eBay I think about has it been about two years ago.[00:36:14] Randy: Two years yeah.[00:36:15] Jeremy: Yeah. And, and so, so tell me about the experience of coming back to an organization that you had been at, you know, 10 years prior or however long it was like, how is your onboarding different when it's somewhere you've been before?[00:36:31] Randy: Yeah. Sure. So, um, like, like you said, I worked at eBay from 2004 to 2011. Um, and I worked in a different role than I have today. I've worked mostly on eBay search engine. Um, and then, uh, I left to co-found a startup, which was in the 99%. So the one, you know, like didn't really do much. Uh, I joined, I worked at Google in the early days of Google cloud, as I mentioned on Google app engine and had a bunch of other roles including more recently, like you said, stitch fix and we work, um, leading those engineering teams.And, um, so yeah, coming back to eBay as chief architect and, and, you know, leading. Developer platform, essentially a part of eBay. Um, yeah. What was the onboarding like? I mean, lots of things had changed, you know, in the, in the intervening 10 years or so. Uh, and lots had stayed the same, you know, not in a bad way, but just, you know, uh, some of the technologies that we use today are still some of the technologies we used 10 years ago, a lot has changed though.Um, a bunch of the people are still around. So there's something about eBay that, um, people tend to stay a long time. You know, it's not really very strange for people to be at eBay for 20 years. Um, in my particular team of let's call it 150, there are four or five people that have crossed their 20 year anniversary at the company.Um, and I also re I rejoined with a bunch of other boomerangs as the term we use internally. So it's, you know, the, um, including the CEO, by the way. So sort of bringing the band back together, a bunch of people that had gone off and worked at it, but at other places have, have come back for various reasons over the last couple of.So it was both a lot of familiarity, a lot of unfamiliarity, a lot of familiar faces. Um, yup.[00:38:17] Jeremy: So, I mean, having these people who you work with still be there and actually coming back with some of those people, um, what were some of the big, I guess, advantages or benefits you got from, you know, those existing connections?[00:38:33] Randy: Yeah. Well, I mean, as with all things, you know, imagine, I mean, everybody can imagine like getting back together with friends that they had from high school or university, or like you had some people had some schooling at some point and like you get back together with those friends and there's this, you know, there's this implicit trust in most situations of, you know, because you went through a bunch of stuff together and you knew each other, uh, you know, a long time.And so that definitely helps, you know, when you're returning to a place where again, there are a lot of familiar faces where there's a lot of trust built up. Um, and then it's also helpful, you know, eBay's a pretty complicated place and it's 10 years ago, it was too big to hold in any one person's head and it's even harder to hold it in one person said now, but to be able to come back and have a little bit of that, well, more than a little bit of that context about, okay, here's how eBay works.And here, you know, here are the, you know, unique complexities of the marketplace cause it's very unique, you know, um, uh, in the world. Um, and so, yeah, no, I mean, it was helpful. It's helpful a lot. And then also, you know, in my current role, um, uh, my, my main goal actually is to just make all of eBay better, you know, so we have about 4,000 engineers and, you know, my team's job is to make all of them better and more productive and more successful and, uh, being able to combine.Knowing what eBay, knowing the context about eBay and having a bunch of connections to the people that, you know, a bunch of the leaders there, uh, here, um, combining that with 10 years of experience doing other things at other places, you know, that's helpful because you know, now there are things that we do at eBay that, okay, well there, you know, you know, that this other place is doing, this has that same problem and is solving it in a different way.And so maybe we should, you know, look into that option. So,[00:40:19] Jeremy: so, so you mentioned just trying to make developers, work or lives easier. you start the job. How do you decide what to tackle first? Like how do you figure out where the problems are or what to do next?[00:40:32] Randy: yeah, that's a great question. Um, so, uh, again, my, uh, I lead this thing that we internally called the velocity initiative, which is about just making us, giving us the ability to deliver. Features and bug fixes more quickly to customers. Right. And, um, so what do I figure for that problem? How can we deliver things more quickly to customers and improve, you know, get more customer value and business value?Uh, what I did, uh, with, in collaboration with a bunch of people is what one would call a value stream map. And that's a term from lean software and lean manufacturing, where you just look end to end at a process and like say all the steps and how long those steps take. So a value stream, as you can imagine, like all these steps that are happening at the end, there's some value, right?Like we produced some, you know, feature or, you know, hopefully gotten some revenue or like helped out the customer and the business in some way. And so value, you know, mapping that value stream. That's what it means. And, um, Looking for you look at that. And when you can see the end-to-end process, you know, and like really see it in some kind of diagram, uh, you can look for opportunities like, oh, okay, well, you know, if it takes us, I'm making this effort, it takes us a week from when we have an idea to when it shows up on the site.Well, you know, some of those steps take five minutes. That's not worth optimizing, but some of those steps take, you know, five days and that is worth optimizing. And so, um, getting some visibility into the system, you know, looking end to end with some, with a kind of view of the system systems thinking, uh, that will give you the, uh, the knowledge about, or the opportunities about we know what can be improved.And so that's, that's what we did. And we didn't talk with all 4,000, you know, uh, engineers are all, you know, whatever, half a thousand teams or whatever we had. Um, but we sampled. And after we talked with three teams who were already hearing a bunch of the same things, you know, so we were hearing in the whole product life cycle, which I like to divide into four stages.I'd like to say, there's planning. How does an idea become a project or a thing that people work on a software development? How does a project or become committed code software delivery? How does committed code become a feature that people actually use? And then what I call post release iteration, which is okay, it's now there are out there on the site and we're turning it on and off for individual users.We're learning in analytics and usage in the real world and, and experimenting. And so there were opportunities that eBay at all, four of those stages, um, which I'm happy to talk about, but what we ended up seeing again and again, uh, is that that software delivery part was our current bottleneck. So again, that's the, how long does it take from an engineer when she commits her code to, it shows up as a feature on the site.And, you know, before we started the work. You know, two years ago before we started the work that I've been doing for the last two years with a bunch of people, um, on average and eBay was like a week and a half. So, you know, it'd be a week and a half between when someone's finished and then, okay. It gets code reviewed and, you know, dot, dot, dot it gets rolled out.It gets tested, you know, all that stuff. Um, it was, you know, essentially 10 days. And now for the teams that we've been working with, uh, it's down to two. So we used a lot of, um, what people may be familiar with, uh, the accelerate book. So it's called accelerate by Nicole Forsgren. Um, Jez humble and Gene Kim, uh, 2018, like if there's one book anybody should read about software engineering, it's that?Uh, so please read accelerate. Um, it summarizes almost a decade of research from the state of DevOps reports, um, which the three people that I mentioned led. So Nicole Forsgren, you know, is, uh, is a doctor, uh, you know, she's a PhD and, uh, data science. She knows how to do all this stuff. Um, anyway, so, uh, that when your, when your problem happens to be software delivery.The accelerate book tells you all the kind of continuous delivery techniques, trunk based development, uh, all sorts of stuff that you can do to, to solve that, uh, solve those problems. And then there are also four metrics that they use to measure the effectiveness of an organization, software delivery. So people might be familiar with, uh, there's deployment frequency.How often are we deploying a particular application lead time for change? That's that time from when a developer commits her code to when it shows up on the site, uh, change failure rate, which is when we deploy code, how often do we roll it back or hot fix it, or, you know, there's some problem that we need to, you know, address.Um, and then, uh, meantime to re uh, meantime to restore, which is when we have one of those incidents or problems, how, how quickly can we, uh, roll it back or do that hot fix? Um, and again, the beauty of Nicole Forsgren research summarized in the accelerate book is that the science shows that companies cluster, in other words, Mostly the organizations that are not good at, you know, deployment frequency and lead time are also not good at the quality metrics of, uh, meantime to restore and change failure rate and the companies that are excellent at, you know, uh, deployment frequency and lead time are also excellent at meantime, to recover and, uh, change failure rate.Um, so companies or organizations, uh, divided into these four categories. So there's a low performers, medium performers, high performers, and then elite performers. And, uh, eBay was solidly eBay on average at the time. And still on average is solidly in that medium performer category. So, uh, and what we've been able to do with the teams that we've been working with is we've been able to move those teams to the high category.So just super brief. Uh, and I w we'll give you a chance to ask you some more questions, but like in the low category, all those things are kind of measured in months, right. So how long, how often are we deploying, you know, measure that in months? How long does it take us to get a commit to the site? You know, measure that in months, you know, um, where, and then the low performer, sorry.Uh, the medium performers are like, everything's measured in weeks, right? So like, if we were deploy, you know, couple, you know, once every couple of weeks or once a week, uh, lead time is measured in weeks, et cetera. The, uh, the high-performers things are measured in days and the elite performance things are measured in hours.And so you can see there's like order of magnitude improvements when you go from, you know, when you move from one of those kind of clusters to another cluster. Anyway. So what we were focused on again, because our problem was software delivery was moving a whole, a whole set of teams from that medium performer category where things are measured in weeks to the, uh, high-performer category, where things are missing.[00:47:21] Jeremy: throughout all this, you said the, the big thing that you focused on was the delivery time. So somebody wrote code and, they felt that it was ready for deployment, but for some reason it took 10 days to actually get out to the actual site. So I wonder if you could talk a little bit about, uh, maybe a specific team or a specific application, where, where, where was that time being spent?You know, you, you said you moved from 10 days to two days. What, what was happening in the meantime?[00:47:49] Randy: Yeah, no, that's a great question. Thank you. Um, yeah, so, uh, okay, so now, so we, we, we looked end to end of the process and we found that software delivery was the first place to focus, and then there are other issues in other areas, but we'll get to them later. Um, so then for, um, to improve software delivery, now we asked individual teams, we, we, we did something like, um, you know, some conversation like I'm about to say, so we said, hi, it looks like you're deploying kind of once or twice.If I, if I told you, you had to deploy once a day, tell me all the reasons why that's not going to work. And the teams are like, oh, of course, well, it's a build times take too long. And the deployments aren't automated and you know, our testing is flaky. So we have to retry it all the time and, you know, dot, dot, dot, dot, dot.And we said, great, you just gave my team, our backlog. Right. So rather than, you know, just coming and like, let's complain about it. Um, which the teams work it's legit for them to complain. Uh, I was a, you know, we were able, because again, the developer program or sorry, the developer platform, you know, is as part of my team, uh, we said, great, like you just gave us, you just told us all the, all your top, uh, issues or your impediments, as we say, um, and we're going to work on them with you.And so every time we had some idea about, well, I bet we can use Canary deployments to automate the deployment which we have now done. We would pilot that with a bunch of teams, we'd learn what works and doesn't work. And then we would roll that out to everybody. Um, So what were the impediments like? It was a little bit different for each individual team, but in some, it was, uh, the things we ended up focusing on or have been focusing on our build times, you know, so we build everything in Java still.Um, and, uh, even though we're generation five, as opposed to that generation three that I mentioned, um, still build times for a lot of applications we're taking way too long. And so we, we spend a bunch of time improving those things and we were able to take stuff from, you know, hours down to, you know, single digit minutes.So that's a huge improvement to developer productivity. Um, we made a lot of investment in our continuous delivery pipelines. Um, so making all the, making all the automation around, you know, deploying something to one environment and checking it there and then deploying it into a common staging environment and checking it there and then deploying it from there into the production environment.And, um, and then, you know, rolling it out via this Canary mechanism. We invested a lot in something that we call traffic mirroring, which is a, we didn't invent. Other T other places have a different name for this? I don't know if there's a standard industry name. Some people call it shadowing, but the idea is I have a change that I'm making, which is not intended to change the behavior.Like a lots of changes that we make, bug fixes, et cetera, uh, upgrading to new, you know, open source, dependencies, whatever, changing the version of the framework. There's a bunch of changes that we make regularly day-to-day as developers, which are like, refactorings kind of where we're not actually intending to change the behavior.And so a tra traffic mirroring was our idea of. You have the old code that's running in production and you, and you fire a request, a production request at that old code and it responds, but then you also fire that request at the new version and compare the results, you know, did the same, Jason come back, you know, between the old version and the new version.Um, and that's, that's a great way kind of from the outside to sort of black box detect any unintended changes in the, in the behavior. And so we definitely leveraged that very, very aggressively. Um, we've invested in a bunch of other bunch of other things, but, but all those investments are driven by what does the team, what do the particular teams tell us are getting in their way?And there are a bunch of things that the teams themselves have, you know, been motivated to do. So my team's not the only one that's making improvements. You know, teams have. Reoriented, uh, moved, moved from branching development to trunk based development, which makes a big difference. Um, making sure that, uh, PR approvals and like, um, you know, code reviews are happening much more regularly.So like right after, you know, a thing that some teams have started doing is like immediately after standup in the morning, everybody does all the code reviews that you know, are waiting. And so things don't drag on for, you know, two, three days, cause whatever. Um, so there's just like a, you know, everybody kind of works on that much more quickly.Um, teams are building their own automations for things like testing site speed and accessibility and all sorts of stuff. So like all the, all the things that, you know, a team goes through in the development and roll out of their software, they were been spending a lot of time automating and making, making a leaner, making more efficient.[00:52:22] Jeremy: So, so some of those, it sounds like the PR example is really, on the team. Like you're, you're telling them like, Hey, this is something that you internally should change how you work. for things like improving the build time and things like that. Did you have like a separate team that was helping these teams, you know, speed that process up? Or what, what was that [00:52:46] Randy: like?Yeah. Great. I mean, and you did give to those two examples are, are like you say, very different. So I'm going to start from, we just simply showed everybody. Here's your deployment frequency for this application? Here's your lead time for this application? Here's your change failure rate. And here's your meantime to restore.And again, as I didn't mention before. All of the state of DevOps research and the accelerate book prove that by improving those metrics, you get better engineering outcomes and you also get better business outcomes. So like it's scientifically proven that improving those four things matters. Okay. So now we've shown to teams, Hey, you're we would like you to improve, you know, for your own good, but you know, more broadly at eBay, we would like the deployment frequency to be faster.And we would like the lead time to be shorter. And the insight there is when we deploy smaller units of work, when we don't like batch up a week's worth of work, a month's worth of work, uh, it's much, much less risky to just deploy like an hour's worth of work. Right. And the, and the insight is the hours worth of work fits in your head.And if you roll it out and there's an issue. First off rolling backs, no big deal. Cause you only, you know, not, you've only lost an hour of work for a temporary period of time, but also like you never have this thing, like what in the world broke? Cause like with a month's worth of work, there's a lot of things that changed and a lot of stuff that could break, but with an hour's worth of work, it's only like one change that you made.So, you know, when, if something happens, like it's pretty much, pretty much guaranteed to be that thing anyway, that's the back. Uh, that's the backstory. And um, and so yeah, we were just working with individual teams. Oh yeah. So they were, the teams were motivated to like, see what's the biggest bang for the buck in order to improve those things.Like how can we improve those things? And again, some teams were saying, well, you know what, a huge component of our, of that lead time between when somebody commits and it's, it's a feature on the site, a huge percentage of that. Maybe multiple days, it's like waiting for somebody to code review. Okay, great.We can just change our team kind of agreements and our team behavior to make that happen. And then yes, to answer your question about. Were the other things like building the Canary capability and traffic mirroring and build time improvements. Those were done by central, uh, platform and infrastructure teams, you know, some of which were in my group and some of which are in peer peer groups, uh, in, in my part of the organization.So, yeah, so I mean like providing the generic tools and, you know, generic capabilities, those are absolutely things that a platform organization does. Like that's our job. Um, and you know, we did it. And, uh, and then there are a bunch of other things like that around kind of team behavior and how you approach building a particular application that are, are, and should be completely in the control of the individual teams.And we were trying not to be, not trying not to be, we were definitely not being super prescriptive. Like we didn't come in and we say, we didn't come in and say, alright, by next, by next Tuesday, we want you to be doing trunk based development by, you know, the Tuesday after that, we want to see test-driven development, you know, dot, dot, Um, we would just offer to teams, you know, hear it.Here's where you are. Here's where we know you can get, because like we work with other teams and we've seen that they can get there. Um, you know, they just work together on, well, what's the biggest bang for the buck and what would be most helpful for that team? So it's like a menu of options and you don't have to take everything off the menu, if that makes sense.[00:56:10] Jeremy: And, and how did that communication flow from you and your team down to the individual contributor? Like you have, I'm assuming you have engineering managers and technical leads and all these people sort of in the chain. How does it[00:56:24] Randy: Yeah, thanks for asking that. Yeah. I didn't really say how we work as an initiative. So every, um, so there are a bunch of teams that are involved. Um, and we have, uh, every Monday morning, so, uh, just so happens. It's late Monday morning today. So we already did this a couple of hours ago, but once a week we get all the teams that are involved, both like the platform kind of provider teams and also the product.Or we would say domain like consumer teams. And we do a quick scrum of scrums, like a big old kind of stand up. What have you all done this week? What are you working on next week? What are you blocked by kind of idea. And, you know, there are probably 20 or 30 teams again, across the individual platform capabilities and across the teams that, you know, uh, consume this stuff and everybody gives a quick update and they, and, uh, it's a great opportunity for people to say, oh, I have that same problem too.Maybe we should offline try to figure out how to solve that together. You built a tool that automates the site speed stuff. That's great. I would S I would so love to have that. And, um, so it, uh, this weekly meeting has been a great opportunity for us to share wins, share, um, you know, help that people need and then get, uh, get teams to help with each other.And also, similarly, one of the platform teams would say something like, Hey, we're about to be done or beta, let's say, you know, this new Canary capability, I'm making this up. Anybody wanna pilot that for us? And then you get a bunch of hands raised of yo, we would be very happy to pilot that that would be great.Um, so that's how we communicate back and forth. And, you know, it's a big enough. It's kind of like engineering managers are kind of are the kind of level that are involved in that typically. Um, so it's not individual developers, but it's like somebody on most, every team, if that makes any sense. So like, that's kind of how we do that, that like communication, uh, back to the individual developers.If that makes sense.[00:58:26] Jeremy: Yeah. So it sounds like you would have, like you said, the engineering manager go to the standup and um, you said maybe 20 to 30 teams, or like, I'm just trying to get a picture for how many people are in this meeting.[00:58:39] Randy: Yeah. It's like 30 or 40 people.[00:58:41] Jeremy: Okay. Yeah.[00:58:42] Randy: And again, it's quick, right? It's an hour. So we just go, boom, boom, boom, boom. And we've just developed a cadence of people. We have a shared Google doc and like people like write their little summaries, you know, of what they're, what they've worked on and what they're working on.So we've over time made it so that it's pretty efficient with people's time. And. Pretty dense in a good way of like information flow, back and forth. Um, and then also separately, we meet more in more detail with the individual teams that are involved. Again, try to elicit, okay, now, where are you now?Here's where you are. Please let us know what problems you're seeing with this part of the infrastructure or problems you're seeing in the pipelines or something like that. And we're, you know, we're constantly trying to learn and get better and, you know, solicit feedback from teams on what we can do differently.[00:59:29] Jeremy: earlier you had talked a little bit about how there were a few services that got brought over from V2 or V3, basically kind of more legacy or older services that are, have been a part of eBay for quite some time.And I was wondering if there were things about those services that made this process different, like, you know, in terms of how often you could deploy or, um, just what were some key differences between something that was made recently versus something that has been with the company for a long time?[01:00:06] Randy: Yeah, sure. I mean, the stuff that's been with the company for a long time was best in class. As of when we built it, you know, maybe 15 and sometimes 20 years ago. Um, there actually, I wouldn't even less than a handful. There are, as we speak, there are two or three of those V3. Uh, clusters or applications or services still around and they should be gone in a completely migrated away from, in the next a couple of months.So like, we're almost at the end of, um, you know, uh, moving all to more modern things. But yeah, you know, I mean, again, uh, stuff that was state-of-the-art, you know, 20 years ago, which was like deploying things once every two weeks, like that was a big deal in 2000 or 2004. Uh, and it's, you know, like that was fast in 2004 and is slow in 2022.So, um, yeah, I mean, what's the difference? Um, yeah, I mean, a lot of these things, you know, if they haven't already been migrated, there's a reason. And it's because often that they're way in the guts of something that's really important. You know, this is the, this is a core part. I'm making these examples up and they're not even right, but like it's a core part of the payments flow.It's a core part of, you know, uh, how, uh, sellers get paid. And those aren't examples. We have, those are modern, but you see what I'm saying? Like stuff that's like really core to the business and that's why it's kind of lasted.[01:01:34] Jeremy: And, uh, I'm kind of curious from the perspective of some of these new things you're introducing, like you're talking about, um, improving continuous delivery and things like that. Uh, when you're working with some of these services that have been around a long time, are the teams the rate at which they deploy or the rate at which you find defects is that noticeably different from services that are more recent?[01:02:04] Randy: I mean, and that's true of any legacy at any, at any place. Right? So, um, yeah, I mean, people are legitimately, uh, I have some trepidation that say about, you know, changing something that's

As Randy Goldberg says, ‘no one dreams of going into the sock business.’ But if there is one sock company you can name off the top of your head, it’s probably the one Randy built with co-founder Dave Heath. Bombas Socks has grown from a small Ecommerce company with a mission into a $100-million dollar enterprise, and the success they’ve had all boils down to remembering the fundamentals.  On this episode of Up Next in Commerce, Randy takes us through his journey to Bombas. He details why founders need to avoid ‘shiny object syndrome’ and focus their sights on the basics if they want to succeed. Plus, he talks about Bombas’ culture of transparency and how to decide between leading with the company mission or the merits of the product when trying to attract customers. Key Takeaways: Bring in the Right People. Scaling requires people — employees, execs, investors, and mentors. Lean on your network, ask questions, hire carefully, and create a dialog with other D2C companies to learn from them. Pro tip: It’s time to bring someone else in when you start to ask questions that neither you nor anyone on your team can answer Ask Yourself, “What Matters More?” When it comes to getting better conversions, don’t let shiny objects distract you. For example, changing the copy or placement of a video matters a lot less than the speed of the site. The faster your site speed, the more conversions you will have. Stay focused on what investments really convert Transparency Impacts the Bottom Line. When employees feel invested in the company and comfortable in the environment you create, they begin to ask more questions, buy-in to the company mission, and work harder to achieve success for themselves and the company For an in-depth look at this episode, check out the full transcript below. Quotes have been edited for clarity and length. --- Up Next in Commerce is brought to you by Salesforce Commerce Cloud. Respond quickly to changing customer needs with flexible Ecommerce connected to marketing, sales, and service. Deliver intelligent commerce experiences your customers can trust, across every channel. Together, we’re ready for what’s next in commerce. Learn more at salesforce.com/commerce --- Transcript: Stephanie: Hey, everyone. Welcome back to Up Next In Commerce. This is your host, Stephanie Postles, co-founder of mission.org. Today, I'm really excited to have Randy Goldberg on the show, the co-founder and Chief Brand Officer at Bombas. Randy, welcome. Randy: Thank you for having me. Happy to be here. Stephanie: Really excited to have you. Thanks for taking the time. I'd love to dive into your background a little bit before we get into Bombas, a little bit about what brought you into the world of Ecommerce and starting Bombas. Randy: Yeah, I guess, we have a sock company, an Ecommerce sock company. I say this a lot, but I don't think anybody ever really grows up dreaming of being in the sock business. It was kind of a winding path for me to arrive at Bombas and to think about this company. My background is in branding, so I was a copywriter and a strategist, and I worked for digital agencies and I worked for a lot of brands through the years. Writing brand books, trying to find out where they had gone astray, brands that were sort of struggling a little bit. I think through that work, I gained a perspective on what I thought a good company looked like, talked like, acted like. At some point, I moved from the agency side to the media side and I was working at a digital media company, and that's where I met Dave Heath, my co-founder in Bombas, and we sort of cooked up the idea when we were working together way back then in 2011. Stephanie: Cool. Why did you guys think, I want to start a sock company? Did you both want to start this or did one have to pitch to the other? Randy: Yeah. Well, I don't think we thought of it as a pitch. We were friends and we were both very entrepreneurial in our outlook. Our families were entrepreneurs. We just, I think, had that same point of view on the world, and we liked the idea of maybe starting a business one day. We weren't actively writing things on a whiteboard and crossing off a list, but we would just talk about things and the business landscape at the time. It wasn't, we need to get this done this year, we were just having a regular day, and Dave was on Facebook, and he saw a campaign that the Salvation Army had been doing with Hanes. Randy: The Salvation Army, they had a quote in there that said socks are the most requested clothing item in homeless shelters. We were having lunch, and Dave said, "I saw this quote, did you have any idea about socks and homeless shelters?" And I said, "No, and I don't even understand why." We started to call around to some shelters in New York, and we were talking to people and we just realized that there was a real problem here. If you're living on the streets, a fresh pair of socks, foot hygiene means a lot. You might be walking more and have less frequent opportunities to wash your clothing. And then, shelters don't accept used socks for donations. So they were always having a shortage and it was always a big need and people would have to buy new socks and then donate them. Randy: People just tended to donate the things that they had worn or gently used. We really just wanted to help solve the problem. So, we started thinking about that, we started buying socks and donating them. Then, I guess just the way our minds work, we started to think there's probably an opportunity here. We looked at the success that Toms had been having and saw their one-for-one business model, and Warby Parker had just launched at the time and they had a charitably inclined business. We thought, maybe this business model really works for this product. It really maps well to it. Just because this is a product that people really aren't allowed to donate on their own. Randy: Then we started to think about socks and we just got obsessed with socks. We were like, socks just haven't changed in 50 years. Athletic socks look the same. They're cardboard, they're white or they're black. Even if you're somebody who cares tremendously about the things that you wear, where they come from, what you're putting on your body, the last thing you get to generally is socks. We thought there was an opportunity to make something really great, to really improve on a product that people take for granted, and that are afterthought in the consumer market, to help solve a problem that's an afterthought sort of for shelters and organization. Randy: Just like, if we can make something really great, we'll sell a lot, and if we sell a lot, we can donate a lot, and if we donate a lot, we can help solve a problem in the community where we work and live. It's easy to look back and say that, but at the time, it just took a while for us to wrap our head around this and think about it as a business idea. Stephanie: Very cool. I will say that I'm definitely someone who had socks as an afterthought, but I will say when I tried on Bombas, I was like, this is a whole different level of socks. I didn't realize I cared about them at all. I would normally just get black ones and just be like, whatever, as long as they're short, I don't care. Then I tried them on, I'm like, oh, these are game changing. They're amazing. Randy: Thank you. I think that's what we're going for. We want to change the way people think about socks, and make it hard for you to go back once you put on a pair of Bombas. Stephanie: Oh yeah. You can't. In the early days, when you were starting out, how did you think through the economics of developing the one to one program? Randy: The early days for us, that meant making sure that we could, from the start, bake into the unit economics, the donation pair, so that no matter what anyone said along the path, if we were raising money, if we were building the business, that there's nothing anybody could do because we were ironclad around the donation model. We built it into the covenant of the business. We've codified it. It's just something no one could ever really take away, but just focusing on it from the beginning and making sure that we could afford to do it, as a for profit enterprise, was a big early step. We've grown and we've gotten smarter about it and we've built a big network of giving inside of the company. It's all gotten bigger and better, but it really started with that idea. Randy: I think that's the right question. Did you think about it from the beginning? Yes, or else we wouldn't have been able to do it and maybe somewhere along the road, we would have compromised, but it's been a big part of how we've talked about the business and the brand and a big part of the success of the company, and having a great product on the side for the consumer allows us to afford the development costs of the donation product, which is an important thing to make sure we're making a product for people who are experiencing homelessness or living on the street. All of these things have been really thought out from the start. Stephanie: It's amazing. I think I saw that you reached profitability by year three. What does your revenue look like now, annually? Randy: Well, we don't typically share exact revenues like numbers, but it's a multiple hundred million dollar a year company at this point and profitable. Stephanie: Very cool. Yeah, I think that's what I saw, but I wanted it to come from you instead of me saying what I think that I read. Randy: Yeah. You read correctly. Yeah, so profitability, I think you're seeing a lot of direct to consumer companies and Ecommerce companies now really starting to think about profitability in this moment. The way that people are raising money and what companies who are handing out money have been looking for, it's forcing a lot of companies who've raised a lot of money and had profitability as a down the road kind of goal, shift how they're operating and shift how they're thinking. I see that, and I've talked to founders who were dealing with this and it seems really painful. I think for us, it was a goal from the beginning. We wanted to have a really solid conservative financial outlook, get to profitability quickly, build a business for the long-term, for the long haul. Randy: We want our grandkids to be wearing Bombas. That's one of our core values. I think that plays into the way that we built the business from the unit economics and financial side of things as well, and the way that we approach marketing, which obviously as you know, as a direct to consumer company, is the hot topic, of course. Stephanie: Yep. Were there any issues that you ran into along the way? Because scaling to over a hundred million revenue is probably pretty tough. Is there any lessons you learned along the way or things that you're like, ooh, we did this great, or we maybe should have done this a bit different? Randy: I think the number one lesson is about focus. Know what you do really well, know why your company exists, why your product deserves to exist in the world, and then focus on doing that well, focus on telling the same story over and over and over again. Whenever we've been able to really focus on that product on the donation, on the sort of foundational elements of the business, that's when we've done the best, and that's when the company has grown really well. When we've gotten distracted by, hey, let's try this pop-up retail idea, or let's advertise in this new place that is unproven, but seems good for this one specific reason, and it's taken our focus away from the things that we do best, that's where we've had the most trouble. I think that's been the big theme for us in the early years, is just focus has really led to growth, and it's where we've had the most success as a company. Stephanie: Very cool. When thinking about the first conversion or a brand new customer, do you think the social good aspect of the business sells the product initially? Because it's pretty hard to convey how good the socks are on the website. Randy: Yeah, it is. It's hard until you, I guess, you try them on, and we just want to get as many socks on feet as possible. But yeah, there has been a constant debate at Bombas since day one about what comes first and the way we talk about the company. The quality of the product comfort or the mission, our commitment to give back to the community. Some people come for the product and stay for the mission, and some people will come for the mission and stay for the product. I don't think we've solved that debate. We poll our customers and we're surveying people and we're thinking about this a lot, but I think the thing that works the most in marketing for prospects, people who haven't heard about our company, is talking about comfort, is talking about the quality of the product. Randy: The mission definitely helps complete a sale, helps with the follow on sales, and our customers, people who've already made purchases, expect us to close the loop, report back on how we're doing with the donations that we promise we would do on their behalf. That storytelling element helps us with both sides of it. It's just about where we show up with the mission and where we show up with the product marketing, at what time in the life cycle. It's an ongoing debate and we stay nimble around it, but those are still the two elements, and they have been since the beginning that show up the most in our communication. Stephanie: Cool. The other thing I saw that you all had was the happiness guarantee, which I was like, how do they remain profitable? Because one of the things I think I saw in there was, if your kid outgrows a sock in a year, which I have three kids, so I'm like, that could happen quick, or if your dog chews up a sock, which our dog, [Tossy 00:11:14], does that every day, how do you make sure that people aren't abusing those rules? How did you come up with that happiness guarantee? Randy: I think for us, we think about the great companies that we all like to work with, or shop at, or interact with. A common theme is that they have great customer service and they stand by their products. We wanted to make that a hallmark of Bombas. In the early days, Dave would take all of the calls that would come in to our phone number on his cell phone. So we would be out talking about the business or in a bar, back when there were bars. He would get a phone call and go outside, and an hour later, he'd come back and he'd just talk to a customer. I think that idea of just making sure that we're taking care of the people who are spending money with us, that led to the idea of the happiness guarantee. Randy: We have our internal customer service team, they're called the customer happiness team, and we've also, just sort of connecting it back to the business, to get back to your question, people who interact with our customer service team have two times the lifetime value of customers who don't. We're trying to turn issues that people have into positive experiences, and that turns people into bigger longterm customers, because then they trust us, they trust that we take care of them. Sure, there are people who try and abuse the policy, but that's far outweighed by the number of people who are just trying to solve a problem, or get to the bottom of something and want things to be right and don't want to have to jump through a lot of hoops to get there. Randy: For us, the good of having that really strong internal team to deal with our customers and to respond to problems, and yes, to make sure that if your kid outgrows the sock that's expensive or that ... We'll be there to grow along with you. All those things are ... we just want peace of mind as people go through the process and think about, should I be making this purchase right now? Stephanie: That's great. How do you train your customer happiness team? Because I feel like it takes a certain kind of person to be peppy and to, like you said, have a higher lifetime value with the people who interact with that team. What kind of training process do they go through? Randy: It's pretty rigorous. I think Dave passed on the mentality of our customer happiness team to the person who originally ran the program, and he's still running that team. I think, like almost everything at Bombas, when we have something that we want to do and we feel like we've reached the limit of how we can handle it ourselves, we try and bring in people who are way smarter than we are and have the right skillset, and really focused on hiring great people. It also helps that, people who come to work at Bombas, tend to want to give back to the community and are inclined to support and work for a company that cares about that as well. Then, we in turn, care tremendously about our company and the company culture, and all of those things lead us to find, I think, the people who are right for the roles and write for the company and speak to those core values, and that's how it works with the happiness team. Randy: They're trained, not only on what to say in the situations that come up most often, but how to deal with Bombas customers, how to put the extra spin on it. It's about, I guess, just that level of care. Our whole team really appreciates that customer service team, and we make sure that they know how appreciated and important they are as the first line of defense for our customers internally as a team. I think giving them the support and love that they need as the team that has to deal with a lot, and has to clean up mistakes when they happen and make sure that everybody's happy, and then understanding how we want them to communicate with the world as a brand. The way that we talk in an ad versus a video, versus on the phone with the customer, versus internally, none of that should really be different, right? We're trying to be really consistent as a brand. Stephanie: How do you create that consistency? Because I can see as a company grows, and I've seen this happen before, where you start developing silos and the teams are kind of off doing their own thing, maybe trying their own marketing campaigns, and it starts getting a little bit chaotic. How have you kept a consistent culture and feel at Bombas? Randy: Yeah. We're not immune to some of the issues that you just brought up. But just recognizing it, being honest about it, trying to get ahead of those things, and focusing on that core messaging and communicating well internally. We're also at the stage where we're really thinking about planning and processes as a company as we've grown to 150 employees and being remote, how we interact and how we work cross departmentally. Those types of things are at the front of mind right now. We're hearing it from our team, we listen to ideas, we bring in people to help us. I think we're laser focused on making sure that some of those breakdowns and that siloed work doesn't get the best of us. We have seen that and we're working on it. Randy: I think any company that starts off operating like that, when you have five or 10 people, that would be overbearing, and I don't think the type of people who end up coming to a company that small would appreciate that, but as you grow, you have to adjust and you have to get ahead of it so that people keep that same feeling of freedom in terms of thought, in terms of how they can innovate in their work and get things done, and expectations around their jobs, all that stuff becomes really important to be more documented, to have tighter processes so that people feel freer to do the things that they love to do. That's what we're trying to work on, but it's not an easy thing. Stephanie: Yeah. It's definitely a tough juggle. If someone were to join and they're employee number five, and then all of a sudden, there's 150 employees, it's like, okay, well, I used to be able to do everything at the company, and now you want me to shrink my role. A tough thing to work through with employees. Randy: Yeah. It's a challenge. You want to retain the people who made Bombas, Bombas, but you also want to make sure that people are growing in the right way, and there are opportunities, and the new people who come in at certain levels understand what they're supposed to do and what everybody else is supposed to do. You just start to get into these things that maybe you thought you would never have to deal with if you started a company, but as it grows, this is what it looks like. Stephanie: Yup. Were there any resources that you leveraged along the way when you were growing quickly, when you were like, I need to learn this or I need to figure this out, or companies that you were watching to learn from? Randy: Yeah. I think that's been our mindset since the beginning. Just from our early advisory board, just to fill in the gaps, to hires that we've made, the things that we tend to lean on are people. Dave and I are like, we don't know the first thing about performance marketing, when we started this business. We need to bring in somebody who's an expert in that, or at least, have somebody on our advisory board who can help answer questions for us as we grow that until we have that right person, or to help us find the right person. That's been a big part of how we've grown this business, is leaning on our network to reach out to people, to ask questions, to make good hires, and then watching other D2C companies and having a good dialogue with the other D2C companies who have grown to our size and larger. That's been really helpful as well. Randy: Then you also think about companies like Toms. They've been really helpful to us, in terms of watching out for certain mistakes that they've made along the way with their donation aspects of their business. They've been really open with us about those things and helping us avoid them. We try and do the same with other companies who reach out and want advice from us as well. Stephanie: Very cool. How did you think about building out the website? What kind of things did you want to have on there to make sure that you kept with the brand story, but also, sold enough to be able to be profitable to keep the model working? Randy: It's a great question. The idea of what a website looks like when it's your only store is so important. You want to have that right blend of storytelling, but you want people to be able to breeze through the checkout process the right way. That's been a journey for us. I don't think it's anywhere near where we want it to be, but I would think that you would ask any direct to consumer company and they have a lot they want to do, and their technology roadmap is pretty long, and that's part of it. You're always building, you're always tweaking, you're always improving. You're looking at the data and you're making changes to just make it better. Randy: In the beginning, at some point we have to replatform. But just the processes along the way to get us from where we started to where we are now, to where we're heading, it takes a lot of care and attention. Like I said, when it's your only store, I think it's your job and your duty to make sure that it works and operates really well. Stephanie: Yeah, I completely agree. How did you know it was time to replatform and what was that experience like? Randy: I knew it was time when we just had so many issues with managing traffic or the backend or uploading content. It was wrong. We launched the business and the website in 2013. Since 2013, there've been a lot of changes in technology and the way that Ecommerce works and looks. If you went back to a site from 2013, as a 2020 consumer, you wouldn't last a minute. You'd be out. Stephanie: You'd bounce right away. Randy: You'd bounce. There was a lot more tolerance then, but less people using Ecommerce because the experience just wasn't great. I think, if you go back even further, and I think about this a lot, if you were starting a direct to consumer company in 2009 and you didn't have a lot of money that you would raise, building the website itself would have been prohibitively expensive for most brands, for most companies. But if you managed to get it up, the marketing was basically free. There was no algorithm that was holding your content back. If you had a Facebook page, whatever you posted, everyone who followed you with anyone who shared it, and anyone who got added to your page, not some of these early companies, resources to build a site were able to build huge businesses. Randy: But then, as it shifted, now, if you want to launch a direct to consumer company, the technology is basically free, getting that website up, but the marketing is prohibitively expensive. It's totally flipped. We just happened to launch, I think, in a sweet spot where the technology had gotten more affordable and the marketing was still affordable, but it was not free like it had been in 2009, and it wasn't very hard or challenging environment like it is now. We sort of had time to figure out both pieces, and we had runway to figure out the marketing and we could afford the technology. Then that got a lot better, and just have to stay on top of and ahead of all those things. Stephanie: That makes sense. To focus on the website piece first, and then we can jump into the marketing aspect, so the website, was there any like big fundamental changes that you made where you're like, this made the biggest difference when it came to sales and conversions and even getting traffic in the first place? Anything that you remember that you change where you're like this had the biggest improvement for us or a couple of things? Randy: Site speed, I think is the number one thing. As a person who comes from the creative side of the business, a copywriter or strategist, there's nothing that I could do from my previous job or as a brand person that would make the improvement of one second of site speed in terms of how something loads or how it acts. Just sort of getting over some of the sort of shiny objects into saying, oh, if we change the copy here, or what if we put this video here, or had this type of look on our site? If you make your site faster, it will convert better. Things like that, just understanding the fundamental way things move and what people want from you, layering the other stuff on top then becomes just sauce and becomes fun. Then you can start to have incremental changes and things that work. But I think, just looking at site speed, if you want one good thing, that's where I would start, as dry as that might be. Stephanie: Yeah. No, that's a great one. Was there anything affecting the site speed that you were surprised by? Randy: I think the way that you manage and load images, obviously has a big effect on that. Your product architecture and understanding Randy: I think some of these things you don't realize when you're starting out, but the way things are organized, hosted, served, there's sort of best in class ways of doing that now. But if you want to have your variants of your products perform a certain way, or if you want to create bundles in a different way than most companies do it, then all of a sudden, you're creating ... you could be creating extra things that are weighing your site down, even though you think ... it helps you organize the things that you want to sell the way that you see them in your mind. It doesn't always benefit you because maybe you're slowing things down. If people are bouncing before they're even seeing it, then what's the point? Again, this isn't my area of expertise, but these are the things that you learn along the road when you're doing everything in a business when there's five people. Stephanie: Yeah, I think that backend infrastructure piece is hard to focus on in the beginning because you're so excited about the product and the marketing, and like you said, getting good copywriting and telling your friends that you don't really think about how to set up, maybe the data and the backend piece to actually create a good performing website. Randy: Totally. Listen, like I said, my background was in branding. I was a copywriter. I think we built this business around the brand because it's, in many ways, a commodity that you turn into a brand. You do that by being really consistent and having good storytelling and build a moat through brand. But none of that exists if you don't get the infrastructure piece right, and you can't get to that. I talked to founders who were starting companies, and they're so focused on hiring the right creative agency or branding agency, they'll put together the right logo, and it's just not the right place to start in my mind, even though I love that work and I love thinking about that for companies and thinking about how you communicate to the world and understanding why your product exists, but without that fundamental infrastructure piece, no one's going to care about that other piece. It's just maybe a little bit of a sad truth for creative side of business people. Stephanie: That's okay. Got to hear it sometimes. Randy: That's right. Stephanie: One thing I saw that you guys were doing was that you were investing in a data science team and embedding more data elements into the customer journey. Can you tell me a little bit more about that and how you knew it was the right time to bring on a team like that? Randy: How will you know it's the right time is that when you start to ask questions that you can't answer, and nobody internally can answer it. That's the truth, and when one person ... Randy: You also know when you're having a debate about something in the business and somebody is able to pull out data or a statistic related to what you're talking about, and the conversation ends because it's hard to argue with the data. When you see that and you've thought about it the other way, and you're not trying ... You can't convince data, right? I know [crosstalk] manipulated. Stephanie: There's no argument there. Randy: That's right. Then you sort of think, this is really valuable, and rather than trying to think about something from the perspective of, I think it should work this way, you want something to show you how it should work, and you want to be able to interpret data the right way and be able to use it to your advantage to build out a strategy, rather than just making assumptions and going off of somebody who has the most experience or who has the most seniority. I think companies get in trouble when they just rely on the loudest voice in the room or somebody who's the most persuasive at arguing rather than bring data as a voice into the room for decision making. Randy: I think it started to creep in when we would understand a little bit what we don't know, and then have debates that were a little bit out of our depth and we didn't have the right people. We didn't really have that skill in the beginning. We knew that it would be a big part of this business, even back in 2013. We just knew that it wasn't the first thing we were going to invest in. It just sort of came naturally to the time. We were always excited about the idea of what a data science team could bring to the table for a sock company. There was a point where you almost can't operate without it anymore. Stephanie: Yeah. That's awesome. What does it look like now having that team, and what kind of metrics are you guys paying most attention to? Randy: A lot of the metrics are the same. You'll see a lot of Ecommerce companies paying attention to, but what the team looks like, and what's interesting is, now that we have the team in place, getting other teams to work with that team the right way is the key, and getting our directors and decision makers accustom to partnering with the data team, to help surface solutions to problems and present them and work, it goes back to some of the work that we're doing, trying to figure out the processes and cross departmental work and to avoid some of the siloed behavior that you brought up earlier. A big part of that is the data team and how they can help support. There's support teams within an organization, there's execution teams, and that's very much a support team, and they love answering questions for teams, and some teams use the data and analytics team more than others. Randy: We just try and be really loud about it at our all hands meetings and present back case studies so that people understand how they could better use that team. It's a process and something that was getting better all the time, but you just sort of have to make it central to how you operate as a company. That doesn't happen overnight. It's a big change. We've been working on that for the last six months to a year in a major way. I think it's really paying off for us. Stephanie: Very cool. Yeah, I definitely have seen business intelligence teams in the past struggle with being able to create a partnership with the product team or the engineers. I like the idea of showing a case study. So instead of pushing it on a team member, it's like, well, here's what another team did. Look how great this turned out, and encourage them to want to partner with that team even more. Randy: Yeah. You're making decisions, how many times a year should we ... We're not a promotional company. But if you wanted to ask a question, like how often should we do a sale? There's logical times of the year when you think that should happen, and the merchandising team might have a different perspective than the marketing team, and using the data team to think about the effect on customers or prospects. There's so much information that could help steer a decision like that, that is major to the business. Those are the types of things where you start to see a lot of power in the team like that. Stephanie: Yeah. We're talking about data. I want to also shift into the aspect of transparency. I read that you and your co-founder both had subpar experiences with transparency at previous companies you were at. I wanted to hear, how do you think about being ... Well, first tell me the story. I want to know all the nitty gritty details, and also how did that influence your culture now? Randy: Sure. I don't know, the cliff notes is that was a major influence on our culture now, but we had the experience together. Like I mentioned, we worked together at a previous company, and at that company, the person who ran the company brought amazing people together, and there was a great team, and the work was fulfilling and we learned a lot, but it was really hard to have conversations around career growth or compensation, or how well is the company doing? Or data. One person tended to hold on to decisions for so long that it was counterproductive and it was demotivating for people. You felt nervous to even ask a question, and nobody understood their stock options. You would ask questions about it and you'd get them response months later. Randy: That sort of fogginess around the things that people really care about when they're going to work at a smaller company, it was really hard for us. We knew no matter what company we started together, building a culture of transparency, where people really understood the why behind the business, the core values, the financial performance, what their ownership meant, and a culture of being able to ask questions, that was hallmark from the beginning. We just wanted to create the company that we would have loved to have worked at and centering our employees in the business, and thinking about them just as much as we do our bottom line. Our theory was that it would make the bottom line better. People would be more inclined to give something beyond their capacity or to continue to learn or to grow if they felt safe and supported at the company. Stephanie: Cool. Yeah, that definitely is a good way to build a company from the ground up, and maybe not fun to have that experience, but hey, you learn from the best people you work for and the worst people you work for. Randy: Absolutely. I wouldn't trade that experience because that's what led to the culture that we've built at Bombas. I think, if you talk to our employees and the way they think about it, we're maybe more proud of that than anything else that we built in this company. Did I give you enough nitty gritty details? Is that good enough? Stephanie: Yeah, I was hoping for a little more drama, but I'll take it. That was good. Randy: There was plenty of drama. We can talk about that offline. Yeah. Stephanie: That sounds good. Earlier, I mentioned, I also wanted to hit on your marketing a little bit. What kind of channels do you focus on? What are you seeing success in right now in any new channels that you're excited about? Randy: Yeah, for us, listen, we're a direct to consumer company that started in 2013. Can you guess what our number one marketing channel is? Stephanie: Facebook? Randy: Bingo. Right. Okay. I think we still see a lot of success there, and while it might've been a way larger percentage of our marketing mix in the early days, and we've diversified away from that a fair amount, it's still an important driver for us. In the beginning, in the early days, we would create a video that we didn't even intend to be an ad, just a thank you to our customers, and then eventually it gets turned into an ad on Facebook that's seen a hundred million times. Leaning into the trends and trying to see around the corner at Facebook. now working closely with that team. has really helped grow our business. Randy: One of the things that we have had since the beginning is ROI positive or breakeven on first purchase. We're not over our skis on Facebook spend, while lot of companies are to just to try and build up their customer base. For us, it was important to really be disciplined. We knew that if we were going to grow our budget and grow our company, and we were a really marketing led company, we'd have to diversify away. So, Hello Podcasts, radio, direct mail, TV. Those are all big parts of the business now, and they're all growing probably at a faster rate as a percentage at least of the business than our online ads on Facebook. But search has grown for us tremendously in the last year and a half as our brand has grown and recognition has grown. Randy: Some of that comes from broader marketing, like on TV, and then people are searching Bombas by name, and we can lean into search advertising and that works better. Some of these things are just about timing. Yeah, we still have a tremendous success sort of trialing things out online. We've never used a creative agency. Everything is internal at Bombas, so all of our creative direction and the marketing team and the partnership between the creative team and the brand teams and the marketing team operates as an internal agency. We like places where we can test things, test creative, test lines, test different cuts of videos, see what works, preview it, and then build it out into bigger campaigns that could work across all those different places that we talked about earlier that I mentioned. Randy: I don't know, that's sort of more of an overview than what's working now. But if I think about the last few months, when everyone's at home with COVID, people who were still able to afford to be buying things right now online are looking for comfort, and socks have done well in this moment. On the other side of things, we talk a lot about our efforts in the community and how we've adopted and been able to help out in this moment above and beyond how we normally do. That's also something that people want to hear about. For us, it's the combination of the product and the storytelling and the marketing mix, and making sure that we're nimble enough in all three of those places to make adjustments as we build and grow. Stephanie: That's awesome. Do you find that you have a community also, because it seems like with your story and your brand, you would have this community of people who want to lift you up and talk about you and spread the word organically without you really having to push too hard? Randy: Yeah, absolutely. Community is a big word at Bombas. Something that has been since the beginning. I think about the community of giving partners that we have. In the beginning, when we wanted to donate the socks, you buy a pair and we donate a pair on your behalf. We didn't know how to do that. We started with one giving partner that would accept socks from us, and we learned a lot from them. Then we built a specific sock that we donate, that's more tailored to the needs of the homeless community. Since then, now we have 3,500 giving partners across all 50 States. These are the people who are working really hard on the front lines helping out that community and doing what they can to serve their communities, and our job is to support them. Randy: That is a big community. We get a lot of feedback from them. Then you have our customers who really care tremendously about the product and the donation aspect of it, and they're telling our story on their behalf. You mentioned earlier about one of the keys, I think for us is consistency. The more you're telling the same story in different nuanced ways, the easier you make it for other people to tell your story on your behalf, and that word of mouth marketing, or letting people explain to somebody else when they're having dinner that, hey, they just got these socks and they're really excited about them. Randy: They donate for every pair they sell, and they also just happen to change the way they feel about putting on a pair of socks in the morning, and they feel more supported and comfortable in their daily life. That's a pretty amazing thing that you can get somebody talking about socks at dinner. I think all of this stuff is related, making sure the messaging is tight, keeping that internal, having a marketing team that's nimble and always trying new to new and different areas, and then having that product that's really high quality to support all of that, to give you the confidence to go out and sell something. Stephanie: That's great. How do you keep things organized? Because I'm thinking about, you have all these community organizations that you're mentioning to do the one to one program, then you've got your own product that you need to focus on. How do you make sure that you're spending the right amount of time with each area? Randy: You don't want to be playing whack-a-mole, I guess. You want to be seeing ahead of things a little bit. There's a certain element of making sure ... You start to see when some friction comes into a certain side of the business and you need to spend a little bit more effort getting your go-to-market process ironed out, or on the technology side, if we don't install an ERP process in the next X amount of time, we could see a lot of trouble. I think that starts with a leadership team that communicates really effectively, often open, and is really humble, and then syncing up on our company roadmap, and making sure that when something does seem like it needs a little bit more attention, that people spend their time on it. Randy: That's the idea. I guess some of that is also thinking about, and talking to companies that are a year or two ahead of us, and have been through some of these sort of growing pains at the same times, and looking for the pitfalls that they went through and trying to get ahead of it rather than to have to be reactionary. Stephanie: The D2C community, it seems like they're very helpful with each other, and you just mentioned, looking to someone who's maybe two to three years ahead of you, how have you utilized that community and leaned into it to get advice or build friendships or mentorship? Randy: Yeah, it's a great community. For us, we're a pretty open group. We talked about transparency and communication as pillars of Bombas from the beginning. We want to help out other companies who are coming up behind us, and then we've looked to other direct to consumer companies, and other, generally, just good companies to try and help us out. You ask the question and you find that people are generally willing to say like, yeah, this is how we did this, or connect with this person on our team. They know that at some point they'll have a question for you. We've always been just asking questions outside of the organization. It's the same approach with hiring. We want to bring in people who are smarter than we are. Randy: We want to ask the questions to the companies who are ahead of us. You don't get the answer if you don't ask the question. It's just an important thing, and I'm not sure why this group of companies especially is more open or collaborative, seeming than other groups that you've been in, but maybe it's this generation of founders and the way that we grew up and the interest in community, and the expectation from customers that our company just can't look the way it used to look or act the way it used to act, and it has to have more of a purpose. Maybe that just drives us all to be a little bit more open and a little bit more flexible and a little bit less guarded about some of the things that we're doing. Stephanie: Yeah, I agree. It also just seems like there's so many opportunities. It's not like you're going to be talking to someone who's doing exactly what you're doing. There's just so many opportunities and so many things to start and try that I'm sure that also helps with people wanting to share and show how they did things. Randy: Yeah. I don't really feel competitive with anyone in that space. In some ways, those companies, you could see them as more of our competition than another sock company, because we're competing for the attention of people online. It doesn't matter what you're selling. If somebody else is taking away time that somebody might spend thinking about Bombas, then I guess that's competition, but approaching it, from a lens of collaboration and like, if they can help us know we can help somebody else, it's just the way we've done it. I'm not sure it's right, or it does feel like it's helped us. It is nice to feel like there is a community around this. I like to think about these companies, I like the community of the businesses. Randy: I'd rather be lumped in with these companies, as a community of people that can help each other with the business side of things, than on the brand side of things. I'm wary of being one of the direct to consumer brands out there, because I don't feel like that set of companies always looks the best or the type of press that is out there is always positive. For me, it's just about the people running it and the people at these companies, and making sure that people in our teams are connecting to people who've done something that they maybe don't know how to do perfectly. Stephanie: All right. Before we jump into a few higher level Ecommerce themes, I wanted to hear what is the best day in the office look like for you? Randy: Oh, the office. Stephanie: How do you walk home when you're like snapped in and you're like, that was a good day. Randy: Remind me of what an office is. Stephanie: Okay. What's the best day from your bedroom look like? Randy: Well, okay. It is interesting to think about at home versus at the office. The office is a big part of who we were as a company and getting everybody together and that spirit of community that comes into it, and being able to sit down with someone face to face. We do miss that. Although the teams are really productive and risen to the challenge of working remotely. The best day feels like when something goes well beyond what you expected and teams are celebrating each other and recognizing each other. Also, when we have a speaker from one of our giving partners to give us perspective on what's happening in our work life and why maybe it's not the most important thing in our life and in our world. Randy: When all of those things are kind of clicking together, I think people remember why they work at this company, what's truly important, how they can impact it, and then the collaboration and the spirit that comes along with it. Those are the best days for me, when you're reminded of what's important and how that impacts the company. Stephanie: I think it's good to document those days too. I really like, there's a coffee shop, Philz, right up the street, and they have all these pictures of their employees and just having fun and team meetings they have. It's on the way when you're headed to the bathroom, but it's really fun. I would think as an employee, but also as a customer to see and remember like what it felt like that day and how excited this person looks when they're receiving this award. Because it seems like it could be easy to forget when something's moving so quick. Randy: Totally. I love that idea. I also think about the times when we all got to volunteer together. Now we tend to volunteer in smaller groups which is obviously still great. We have sign up sheets for all of our volunteer opportunities and you have to pounce on them to get the spots that you want. I think that speaks a lot about the culture of the company, but some of the photos you look back on from those moments, or those days when the team feels really connected, those are really exciting days. Stephanie: Yep. All right. A higher level Ecommerce question. What do you think the future of online shopping looks like, like in 2025? Randy: Ah, like when we're all driving around in flying cars, what does Ecommerce look like? Stephanie: Yup. I'm on Mars. Where are you? Randy: I might be on Mars too. Do you want to have a rival colony? I'm down or maybe we have a collaborative colony. Stephanie: Okay. Oh, I'm down. Maybe, we'll see. Randy: We'll see. Okay. All right. We'll see. We'll figure it out then. Stephanie: It depends if you accept my LinkedIn request, I guess, then I'll know. I'll be like, is it any cooler now? Randy: Wait, that's how we judge if you're cool, is if you accept our LinkedIn request? Stephanie: I just made it up, but we'll see. I might have higher criteria afterwards. Randy: Okay. All right. We'll put a pin in that. I don't know what the future of Ecommerce looks like, I got to tell you, I know the percentage of people who get comfortable shopping online, that's only going to go up. I know that companies are going to invent new ways to make it easier for people to buy their product, to review their product, to look at it. I think ease is the name of the game. In a world that's going to be more and more competitive, the way to stand out is going to change. All I know is it's not going to look like it looks right now, and having the attitude that, even if you're doing something right, that the way to succeed in a few years, it's going to be a different version of right, then you'll be okay. Stephanie: Yep. I love that. All right. Before I move into the lightning round, anything that you wanted to share that we missed, where you're like, I really wish you asked this, Stephanie, and you just didn't? Randy: No, like I said, I'm here for you guys. You want to talk about Mars and infrastructure, then great. Whatever you want to talk about. Stephanie: Mars and the moon, that'll be the next podcast. Anyone who wants to sponsor it, hit us up. I don't know what we're going to talk about, but we're going to need help to figure it out. All right. Lightning round brought to you by Salesforce Commerce Cloud. This is where I ask you a question and you have a minute or less to answer, Randy. Are you ready? Randy: I'm ready. Stephanie: All right. What's up next on your reading list? Randy: Can we just start that over? Sorry. Stephanie: Yep. What's next on your reading list? Randy: Up next on my reading list is the Mike Nichols book. I'm not sure what it's called, but I'm excited to read it. Stephanie: What's it about? Randy: Its about the director, Mike Nichols, and his life. Stephanie: Cool. We'll have our producer, Hillary, will find the link to that and everyone can go explore it there. Randy: I don't tend to read business books. I know that they could be helpful, but I'm more interested in people, humanity, fiction, novels. Stephanie: Yep. Cool. Any podcasts you listen to? Randy: Yeah. There's a great podcast I listened to about words called The Allusionist, Allusionist with an A. Love that podcast. I have a whole list, but let's just do one. Stephanie: Yeah. We'll check that out. Any hobbies that you're really getting into these days? Randy: Hobbies that I'm really getting into. I really like this sport called paddle tennis. It's not pickleball, it's not ping pong. It's called paddle tennis. If you look it up, it's like a fast version of tennis. You play with a paddle and a tennis ball, but you poke a hole in it. There's like a really small, but passionate community around the sport. It's really fun. Stephanie: Do you play on a tennis court? Randy: You play on a small tennis court. It's basically the service boxes and two-ish foot baseline, and a net. You serve under hand, and you can't serve [inaudible 00:52:55], and you poke a hole on the tennis ball so it doesn't fly everywhere, but it still bounces. It acts and feels like tennis, but like a faster version. It's really cool. You can play in New York. There's courts in New York in StuyTown and Peter Cooper Village, and there's courts in Venice Beach in California. Those are kind of the two centers in the US. It's not a very big popular sport. Stephanie: We will have to bring it up to Palo Alto. I will be the one do that. That would be my initiative over the next year. Randy: Do it. Stephanie: All right. If you were to have a podcast, what would it be about, and who would your first guest be? Randy: Oh man. If I was going to have a podcast, wow, I don't know. Do we need another podcast? Do we need a podcast from me? Stephanie: Yes, we do. Randy: Maybe it would just be rants. Just do like a short rant every week. I don't know. Stephanie: I like that. Hey, that seem to do well sometimes. Stephanie: That's okay. All right, this one's slightly harder so you might have to think. What one thing will have the biggest impact on Ecommerce in the next year? Randy: I think the thing that will have the biggest impact on Ecommerce in the next year is the timing on reopening the economy and stores and retail. If people can't go to stores or don't feel comfortable going to stores, they're going to, inevitably, accelerate their comfort level with shopping online. We already see that happening. I think it's just going to push that trend line even further forward. I'm for one, excited about it. I think the biggest, biggest test for this will be this Q4 and the holiday season, and to see what percentage of shoppers are shopping on Ecommerce and what they're demanding of Ecommerce retailers that they weren't a year ago when the percentages were smaller. Stephanie: Yeah, I completely agree. Great answer. Randy, it's been a blast having you on the show. Where can people find out about you and Bombas? Randy: You can find out about Bombas at bombas.com, and everywhere else you would expect, B-O-M-B-A-S. That's it. Thank you for listening and thanks for having me. Stephanie: Yeah. Thanks so much. It's been fun. See you next time. Randy: All right. See you next time.  

Click the post for details on this episode! Welcome back to Open House! Randy Seidman here, excited to bring you another two hours of the grooviest beats. If you want to be heard on the show, call +1-315-RANDY-OH (315-726-3964), drop me a voicemail and let me know where you’re listening from. Had a great time … Continue reading

Click the post for details on this episode! Welcome back to Open House! Randy Seidman here, excited to bring you another two hours of the grooviest beats. If you want to be heard on the show, call +1-315-RANDY-OH (315-726-3964), drop me a voicemail and let me know where you’re listening from. Had a great time … Continue reading

Click the post for details on this episode! Welcome back to Open House! Randy Seidman here, excited to bring you another two hours of the grooviest beats. If you want to be heard on the show, call +1-315-RANDY-OH (315-726-3964), drop me a voicemail and let me know where you’re listening from. Had a great time … Continue reading »

Click the post for details on this episode! Welcome back to Open House! Randy Seidman here, excited to bring you another two hours of the grooviest beats. If you want to be heard on the show, call +1-315-RANDY-OH (315-726-3964), drop me a voicemail and let me know where you’re listening from. Had a great time … Continue reading »

Click the post for details on this episode! Welcome back to Open House! Randy Seidman here, coming to you from Thailand, and excited to bring you another two hours of the grooviest beats. If you want to be heard on the show, dial +1-315-RANDY-OH, drop me a voicemail and let me know where you’re listening … Continue reading

Click the post for details on this episode! Welcome back to Open House! Randy Seidman here, coming to you from Thailand, and excited to bring you another two hours of the grooviest beats. If you want to be heard on the show, dial +1-315-RANDY-OH, drop me a voicemail and let me know where you’re listening … Continue reading

Click the post for details on this episode! Welcome back to Open House! Randy Seidman here, coming to you from Thailand, and excited to bring you another two hours of the grooviest beats. If you want to be heard on the show, dial +1-315-RANDY-OH, drop me a voicemail and let me know where you’re listening … Continue reading »

Click the post for details on this episode! Welcome back to Open House! Randy Seidman here, coming to you from Thailand, and excited to bring you another two hours of the grooviest beats. If you want to be heard on the show, dial +1-315-RANDY-OH, drop me a voicemail and let me know where you’re listening … Continue reading »

Click the post for details on this episode! Welcome back to Open House! Randy Seidman here, excited to bring you another two hours of the grooviest beats. If you want to be heard on the show, dial +1-315-RANDY-OH, drop me a voicemail and let me know where you’re listening from. Had a great time playing … Continue reading

Click the post for details on this episode! Welcome back to Open House! Randy Seidman here, excited to bring you another two hours of the grooviest beats. If you want to be heard on the show, dial +1-315-RANDY-OH, drop me a voicemail and let me know where you’re listening from. Had a great time playing … Continue reading

Click the post for details on this episode! Welcome back to Open House! Randy Seidman here, excited to bring you another two hours of the grooviest beats. If you want to be heard on the show, dial +1-315-RANDY-OH, drop me a voicemail and let me know where you’re listening from. Had a great time playing … Continue reading »

Click the post for details on this episode! Welcome back to Open House! Randy Seidman here, excited to bring you another two hours of the grooviest beats. If you want to be heard on the show, dial +1-315-RANDY-OH, drop me a voicemail and let me know where you’re listening from. Had a great time playing … Continue reading »

Click the post for details on this episode! Welcome back to Open House! Randy Seidman here, excited to bring you another two hours of the grooviest beats. Thank you for the calls that have been coming in over the last few months! If you want to be heard on the show, dial 315-RANDY-OH, drop me … Continue reading

Click the post for details on this episode! Welcome back to Open House! Randy Seidman here, excited to bring you another two hours of the grooviest beats. Thank you for the calls that have been coming in over the last few months! If you want to be heard on the show, dial 315-RANDY-OH, drop me … Continue reading

Click the post for details on this episode! Welcome back to Open House! Randy Seidman here, excited to bring you another two hours of the grooviest beats. Thank you for the calls that have been coming in over the last few months! If you want to be heard on the show, dial 315-RANDY-OH, drop me … Continue reading »

Click the post for details on this episode! Welcome back to Open House! Randy Seidman here, excited to bring you another two hours of the grooviest beats. Thank you for the calls that have been coming in over the last few months! If you want to be heard on the show, dial 315-RANDY-OH, drop me … Continue reading »

Click the post for details on this episode! Welcome back to Open House! Randy Seidman here, excited to bring you another two hours of the grooviest beats. If you want to be heard on the show, call 315-RANDY-OH, drop me a voicemail and let me know where you’re listening from. I wanted to start today’s … Continue reading

Click the post for details on this episode! Welcome back to Open House! Randy Seidman here, excited to bring you another two hours of the grooviest beats. If you want to be heard on the show, call 315-RANDY-OH, drop me a voicemail and let me know where you’re listening from. I wanted to start today’s … Continue reading

Click the post for details on this episode! Welcome back to Open House! Randy Seidman here, excited to bring you another two hours of the grooviest beats. If you want to be heard on the show, call 315-RANDY-OH, drop me a voicemail and let me know where you’re listening from. I wanted to start today’s … Continue reading »

Click the post for details on this episode! Welcome back to Open House! Randy Seidman here, excited to bring you another two hours of the grooviest beats. If you want to be heard on the show, call 315-RANDY-OH, drop me a voicemail and let me know where you’re listening from. I wanted to start today’s … Continue reading »

Sad and Depressed :( Ryback wants to get drunk really fast It’s conversatioN, there is no S in my F*CKING SHOW! Play my music!!! I’ll take a free ring for my backyard. A lot of feedback It’s good to have influence. I wonder how big her… Some Dusty Rhodes Talk. Ryback is torturing himself. There’s a ghost haunting Ryback. How much has Ryback lost in sales due to the Amazon Debacle? Ryback’s interesting attire. The Secret Bowling Alley. Holding it Together. The post broke! Ryback vs Learn more about your ad choices. Visit megaphone.fm/adchoices

Click the post for details on this episode! Welcome back to Open House! Randy Seidman here, excited to bring you another two hours of the grooviest beats. If you want to be heard on the show, call +1-315-RANDY-OH (315-726-3964), drop me a voicemail and let me know where you’re listening from. Had a great time … Continue reading

Click the post for details on this episode! Welcome back to Open House! Randy Seidman here, excited to bring you another two hours of the grooviest beats. If you want to be heard on the show, call +1-315-RANDY-OH (315-726-3964), drop me a voicemail and let me know where you’re listening from. Had a great time … Continue reading

Click the post for details on this episode! Welcome back to Open House! Randy Seidman here, excited to bring you another two hours of the grooviest beats. If you want to be heard on the show, call +1-315-RANDY-OH (315-726-3964), drop me a voicemail and let me know where you’re listening from. Had a great time … Continue reading »

Click the post for details on this episode! Welcome back to Open House! Randy Seidman here, excited to bring you another two hours of the grooviest beats. If you want to be heard on the show, call +1-315-RANDY-OH (315-726-3964), drop me a voicemail and let me know where you’re listening from. Had a great time … Continue reading »

Click the post for details on this episode! Hello and welcome back to Open House. Randy Seidman here with another two hours of the grooviest beats. I’m staring to air some listener calls, so if you’d like to be heard on the show, drop me a voicemail at 315-RANDY-OH (+1-315-726-3964), I look forward to hearing … Continue reading

Click the post for details on this episode! Hello and welcome back to Open House. Randy Seidman here with another two hours of the grooviest beats. I’m staring to air some listener calls, so if you’d like to be heard on the show, drop me a voicemail at 315-RANDY-OH (+1-315-726-3964), I look forward to hearing … Continue reading

Click the post for details on this episode! Hello and welcome back to Open House. Randy Seidman here with another two hours of the grooviest beats. I’m staring to air some listener calls, so if you’d like to be heard on the show, drop me a voicemail at 315-RANDY-OH (+1-315-726-3964), I look forward to hearing … Continue reading »

Click the post for details on this episode! Hello and welcome back to Open House. Randy Seidman here with another two hours of the grooviest beats. I’m staring to air some listener calls, so if you’d like to be heard on the show, drop me a voicemail at 315-RANDY-OH (+1-315-726-3964), I look forward to hearing … Continue reading »

Quantifying Empathy - Episode 23 Twitter Hearts and Facebook Reactions TL;DR - You KNOW Marc, Randy, and Scott couldn't let Twitter messing with Favorites and Facebook Reactions go without some spirited discussion. Facebook is testing emoji reactions - this is the ‘dislike button' by Owen Williams @ TNW Hearts on Twitter on the Twitter Blog. RECLAIMING CONVERSATION : The Power of Talk in a Digital Age is Sherry Terkle's new book which influenced some of Randy's thinking. Kaliya Hamlin (@identitywoman) was mentioned during the episode. Transcript Intro: Welcome to the Social Media Clarity Podcast. Fifteen minutes of concentrated analysis and advice about social media in platform and product design. Randy: I'm Randy Farmer Scott: I'm Scott Moore. Marc: I'm Marc Smith. Randy: Really, Twitter, hearts? Scott: Really, Facebook? Reactions. Randy: Oh, my gosh, guys. We have a lot to talk about since the last time we've had a session. The big social guys have gone nuts for emoticons as a way to express yourself with a single click. Scott: We already had ways of expressing ourselves, they were just very generic. Now we're trying to be specific about it. Randy: Twitter changes from stars to hearts ... Scott: ... and Favorites to Likes. Randy: Yeah, and Favorites to Likes. [as if] they're exactly the same. If you think they're the same, people out there, just think what if they changed it back to a pile of crap. Is that the same as a heart, or a star? When I think of Twitter's problems, I don't think this is one of the ones that was very high on the list. Scott: No, but it's one of the ones that helps them get attention. It helps generate notifications. They practically said, 'we're not getting enough people using the Favorite, so now we're going to change it to something that more people will use.' That generates notifications, and that brings people back to the app. Randy: So, something that was meaningful, now means less. Marc: Is it the case that you are more likely to love something than like it? Randy: Well, that's not the test on the table in this case. It's Like versus Favorite. Marc: Yeah, but the like generates this heart, which suggests love, and it used to be a star. So, we're moving from star to heart. Admittedly, we're going from Favorite to Like, but is there really that much more like than favorite in the world? Scott: I think that the context was really different. From what I gauged from the reactions, other than people just hating change, was that Favorite de-noted a bookmark, and then expanded from there. A lot of people were using it as, "I'm saving this link for later", or, "I'm saving this Tweet for later". Some people were using it as, as you would for any signaling system, some people were using it as, "I like what you said". Now, they've actually tightened up the context while at the same time, loosen it, by saying, it's a like, which can mean anything. Anything that's positive. It's a positive mark on it. Randy: Right, and they retroactively marked every Favorite a Like. How many gillions of those they have, I don't know. At least one person I was talking to yesterday when I first saw this in practice, and was shocked by it, was Kaliya [Hamlin], otherwise known as Identity Woman, and she says, "Oh my God, now I've got to go fix all my Favorites on Twitter, because I don't love most of those things." Scott: Yeah. Some people were tweeting out "Liking your tweet is not consent." Randy: That's awesome. When we first thought of doing this episode, that hadn't even happened yet. That's just the freshest thing, that happened yesterday. Before that, Facebook was going to start testing the emoticon variants, or they call Reactions, as a response to the demand for dislikes. Marc: Right. So, we don't get Dislike, but we get Reactions. Randy: Well, and if you look at the reactions, the icons are ambiguous. I don't know if that's a feature or a bug. They do, in fact, include a dislike one, called Angry, it's angry face. It's like, what's this about? I think this is what we wanted to talk about, is we wanted to take some of these seemingly crazy, and capricious ideas, and talk about what it is maybe they're trying to do. We've been calling this, amongst the three of us - " Quantifying Empathy." So, we are going to have a conversation about that today. Marc: Right. It seems that what we're seeing is a feature that allows people to have a very light weight way to author some higher level of attention. I mean, after all, the system knows who "saw" each piece of content, and it even reports that for some pieces of content on some platforms. It'll say some number of people have been exposed to, or have seen the piece of content, but that's sort of the lowest level of content measurement. How many people might have seen it. Now with the Like, or the Love, or the Favorite, or the reaction, we're trying to get people to click, and just click, but to click from a field of choices to give us a higher resolution sense of, what did that click mean? The Like was too ambiguous. So, now we have angry, and happy, and sad. What are the other ones? Grumpy. Randy: You can make up as many as you want. Scott: Great. Randy: No, there's just a few. There's a Yay one supposedly. Scott: Yay. There's Wow, there's Sad, there's Angry ... Scott: ... and there's one other. Randy: So, when you use ambiguous faces, in the case of Facebook, it actually lacks all subtlety. Does it mean what the face expresses to you? Or, does it mean the words that are written underneath it? Scott: Yeah. Am I angry at you because of something you said? Or, am I angry about the same thing you're angry? Am I expressing actual empathy, or am I reacting against you? Marc: So, this is a great piece of ambiguity that the interface has yet to resolve. You pointed this out earlier, that people are splitting their reaction to what this story means _for the author_ of the story, and their reaction _to_ the story. So, there's this ambiguous reference that must be clarified, and these additional features do not clarify it. If anything they add more ambiguity. Randy: Interesting in Facebook, is you've always been able to use these exact same icons, you've always been able to add them to a message. You did it by posting a reply to post. You would then explain - so, you could put in a sad face, and say, "I feel sorry for you. If I can help you in any way, let me know." Right? So, you have this rich interaction that would be going on between humans. So, what do the humans actually want? What are good for humans? Probably saying more, not saying less. What really kind of drives it home for me, is when you *count* them. I say, when you click on an angry icon, there's object missing. There's a famous expression; "This sentence no verb". Right? Well, now with the reactions we have; "I'm angry with..." or "I'm mad at..." Marc: That's great. That's great. Randy: I'm sad at ... Right? In the same kind of construction, with that missing by pulling them out. Then you count them, and you say, "Lots of us are mad at..." We don't even know if those people are mixed and matched on what they're mad at. Scott: Right. A lot of people are mad, but we don't know if they're mad at, or mad with. Randy: Yeah, and I've got to tell you, that's going to drive people off. Just the mad icon alone is going to drive people away from posting, because they can't figure out, you know, if you have any social anxiety, any feedback, other than "we love you, it's okay" is going to be harmful. So, it surprised me that they said Dislike is too negative, we get that, and then put an angry face. In counting them they're already finding out in Spain and Ireland, where they're testing it, messages are coming back with a mixture of counted face types. Want to talk about no way to interpret data - What the heck does that mean? Facebook's excited, because they got a lot of clicks they probably wouldn't have got before. That they can use to route messages to your email box. Scott: Yeah, so the cynical side of me says - so one thing in developing, and choosing what they were going to choose as far as what icons to go for - they looked at all the one word, and sticker-only posts, and they just kind of aggregated all that together, and said, okay, these are the things that people most likely say in those replies, when they're posting an emoticon or sticker or something like that. So, they're just making it easier for them now to count and quantify that for other purposes. Either to send notifications, or more likely a lot of the brand pages, the blogs, and other folks out there who are into Facebook marketing, are saying this could be useful, because now you can get more detailed information about what your brand reaction is. So, it's just another thing that someone's going to measure in order to sub-divide targeted marketing. Randy: Yeah, but that ends up, it's true, and diluting. We all recall the experiments people have been doing just with Like and Share, if you think X: Like this thing. If you think Y: Share this thing. Right, because they're trying to manipulate these various counters. So, it occurred to me, they could have just put in a polling mechanism. So ... Scott: Twitter did put in a polling mechanism recently. Randy: Good. Scott: Yeah, Facebook used to have polls. A long, long time ago, Facebook used to have polls, and they took them out. Marc: So, this is an interesting point. If we're going to be critical of the reaction system, we ought to suggest an alternative: One alternative is to allow the poster to list the reactions that they are interested in having people choose from. So, a little bit of a hybrid between a poll, and these emotion icons. Maybe you could react to me with sympathy, empathy, or cash, or other. Scott: Well, you could even take the system that they have now, and say, which one of these would you like to focus on, or how many of these would you like people to, you know, is this a 'Wow - Yay' type of post? Do you want Wows and Yays, and you don't want Sads on your post, because that's not what you're talking about? They actually have something built in, this is really funny, in Facebook, they have the option for being able to say, "I'm feeling blessed." Or happy, or sad, or angry, and they have this list of about 25 of these things, and why can't I +1 somebody who is feeling a certain way already? Because now the context is, "I'm with you on this. " Marc: So, what's the ultimate goal here? We want users to click more, and ... Randy: ...let's be clear: Advertisers want users to click more. Marc: Right, right. I meant to say, what is the system designers ultimate goal here. They want users to click more. As system users though, as people who use these features, what is our goal? Randy: I got to say, I'm with Sherry Turkle on this, that anything that reduces human conversation, is probably truly reducing empathy. If people out there are interested, I'll put a link in the show notes to show Turkle's latest book and work. It talks specifically about the fact that we've been reducing ourselves to machine interactions with lighter and lighter interfaces to the point where we don't even know what empathy is anymore. We don't have to respond with any empathetic statement when all we have to do is click a sad icon. Scott: Yeah, and I really want to read Sherry's book, but I'm starting to think that there's a slight difference in that, and a little bit more optimistic in that, yes, using our smart phones, and what not, are pulling us away from face to face conversations, and I think we're having to figure out now that we're breaking that, what can we do, now that we're turning our faces towards devices, what can we do to actually build back in? What are the things that we're missing, and how do we rebuild that in our systems? How do we get folks to build up more empathy with people, and can we do that with systems? I think it's something that is important. These systems are light weight, and they're somewhat useful, but they lack deeper meaning, which is exactly what you're saying. Randy: Well, don't take the simple path. Don't just count clicks on dots, right? Design interfaces that help people solve problems. Scott: Right. Randy: People do this. Marc: What problem do people feel like they have? I mean, at the moment Facebook trained us to want to generate certain kind of responses. We want Likes, we want Comments, we want some kind of currency that proves we consumed other people's attention, and that they've granted us some kind of approval. Is that they only purpose that we could use this platform for, and is that the only purpose these reaction features are designed to support? Scott: Well, obviously not. I mean, that's not the only purpose. Facebook's purposes might be at cross purposes with those of us who want to actually build communities online, and help people develop deeper, meaningful relationships. That's why I think that these are light weight, but not very meaningful. They might suffice in those ambiguous situations, especially in a network like Facebook, where very often you are not close friends with the people who are on your Facebook network. So, sometimes commenting deeper on something could become awkward, because you just aren't that well connected, but you want to acknowledge. So, I think there's room for the social grooming that a Like, or any of these kind of reactions would provide, but I think that we should be thinking about, as designers, and as people who are fostering online communities, how to help people get to that deeper conversational engagement, that Sherry Turkle is point out, even though we are still on our devices. Randy: Right. So, I think I can summarize my thought on this, clearly, which is, any interface that allows a single click for me to add angry, without and object on it, decreases my chances of influencing the person, or the event, I was angry with, because there is no context provided. So, the one way we can improve using these tools is if I choose angry, I do actually have to say at what. Scott: Well, and as a designer, we could even prompt people that if you choose ... Randy: Exactly. Scott: ... that if you choose something it would give them the ability to provide the context, rather than the context-less emoticon. Randy: Yeah, so, agree and disagree are missing. We know from helpful/unhelpful movie reviews that two of those icons are going to be re purposed for that, because they already are. If they had helpful and unhelpful we know those would be mapped to agree and disagree, for controversial objects. So, is angry going to be the new disagree? Scott: Yeah, I think so. Marc: So, is this all because typing a few characters, a comment, a short message, is too burdensome, and is it too burdensome because of the time, or because we're doing it with one thumb, standing in a checkout line, and that's why we really need, at most, the two to three to four tap method for replying to complex situations. Rather than the forty- or fifty-tap necessary to actually type out a five- or eight-word sentence. Scott: I think that's a good point. I don't think that these systems are being designed with user convenience in mind to necessarily help us to communicate with each other better. I think that they are there to help us generate notifications, so that we come back to the application faster and more often. Randy: A single click on a face has striped almost all semantic meaning from the event. Scott: I think you have a point that this particular system is being set up, and this particular way, because mobile devices are being used for the quick in and out, you know, quick check. Users are using it that way, and Facebook and Twitter are adapting to that particular use in order to capture that behavior. That's what it is, it's a behavior capture system. They're getting somebody's attention, they want to get somebody to "engage," even though I don't think that's engagement. Then they're going to pull all that data together, and they're going to use it as either targeted advertising, or use it to generate more notifications to bring the original posters back to the application, where you deliver more ads. Marc: So, I would say it as this: Why not to like the new Like - I'm angry, you might be happy, but we might not be able to tell. Randy: That sounds like a great summary to me. Scott: Yeah. Yeah. Randy: Thanks everyone. I hope you're enjoying the new format. Go ahead and say thanks, guys. Marc: Right. Scott? Randy: Say thanks. Scott: Oh, that. I'm not. I'm like, now I'm lost. Marc: You're not thankful? I'm thankful. Thank you everyone. Scott: I'm Angry. Thanks. Randy: Okay, that's great. That's an ending. I'll take it. Scott: I don't know why. I'm just Angry. Marc: Well, I'm going to be Grumpy in a minute, so ... Randy: I might even keep a little of this. Marc: Bye-bye. Randy: All right. Outro: For links, transcripts, and more episodes, go to Social Media Clarity dot net. Thanks for listening.