What Fascinates Randy Shoup of WeWork?

On this episode, I talked to Randy Shoup, the VP of Engineering at WeWork. We recorded this episode and we were in new digs in Salesforce tower in San Francisco. And a random coincidence when I was a kid, other than computers, I had a keen interest in world history. And it turns out that Randy and I share that in common. We cover a wide variety of topics, including the fall of the Berlin Wall, and also talk a bit about the history of Silicon Valley, which is always an inspiring refresher course. As an interesting trivia point, stick around until the end, and find out what Randy and Roger Federer have in common. Enjoy.

All right, so I am very lucky to be here in Salesforce Tower. I've been watching this building come up over the last little while and always kind of itching to get inside. And I finally got my chance today. And it was better than I imagined, I guess was very kind to show me a very unique view of both Coit Tower and Alcatraz, which I've never actually seen in one line of sight from the angle I saw here. And if I'm lucky, and the fog clears, I might be able to see the Golden Gate Bridge at the end. So I'm already having a great day. But let me before further ado, I’ll ask my guest introduce himself. Please go ahead.

Randy

Thanks, Bobby. My name is Randy Shoup, and I'm VP of Engineering here at WeWork. And so the reason why you're able to see this, as you know, to connect those two ideas together, is WeWork as a coworking space company just opened their San Francisco headquarters here in Salesforce Tower. So we have floors 36-38, and several which are local San Francisco headquarters. And I say that because the company is headquartered in New York—this is our sort of, you know, local/regional headquarters, I suppose. But we also have a floor for members that is either open now or opening soon.

Bobby

I'm certainly eagerly looking forward to that particular floor. Because as we talked about before, I'm a WeWork customer—a very happy, and kind of almost a raving fan of WeWork. And looking forward to that opening up.

So I thought I would begin this interview, as I do with most interviews, talking about Mikhail Gorbachev.

Randy

I love it!

Bobby

And so we'll get to that in a second. For those who don't know, I would love if you could paint a picture about, let's say, going into college, what your interests were and what you thought you were passionate about doing career-wise, when you graduated from college.

Randy

Beautiful. Very clever and cleverly done! So as we were talking before, a bunch of people in our industry that have very straightforward lines from their interests as children or whatever, into their current job, and mine is there, but also not there. And I'll explain what I mean by that.

What you're hinting is, when I entered college, I wanted to be an international lawyer. So I entered college, it was in 1986. So height of the Cold War between the US and the Soviet Union. And during high school, I did speech and debate. And one of the things that we learn about is all sorts of current events-related stuff, including, particularly all the thousands of nuclear weapons that each of us had pointed at each other. So I majored in political science, and was particularly interested in East-West relations. So actually, while I was at Stanford, I went to do a joint program in West Berlin. I say West Berlin because there was a wall around it at the time. And and that was a quarter there, and then a quarter in Krakow in Poland, which was, again, behind the Iron Curtain. So both wonderful experiences. And nobody knew this in 1989, when I went, but that was the last gasp of that particular division, right? So the wall was about to come down.

And a couple months later, nobody knew that and I wasn't there for that, I was back here. But the Wall came down. And then two years later, the Soviet Union collapsed, etc.

You mentioned Gorbachev, so lots of things we could talk about in there. But one of my personal heroes at the time then, and still is Gorbachev because if you know your modern history, post-World War II history, as I'm sure you do, the history of World War Two is lots of peaceful uprisings violently put down all over Eastern Europe, right. So Hungary and the Prague Spring in 1968, and and and... And so there was no reason to believe in 1989 that another one of those wouldn't have happened. There was every reason to believe that the Soviets would and could have violently put down all of that opening that started in Hungary and went to Czechoslovakia and went to East Germany, etc. And they certainly had the capability to do it, you know, tens and tens and tens of tank divisions everywhere, and they didn't. Why didn't they? A lot of it was because Gorbachev saw that it would be a better world if he didn't, and I don't think he expected this. Do you need to collapse and things to happen? You know, nobody sees that. But if there's any one person on the planet to credit for the fact that we didn't have a World War III at that moment, it's Mikhail Gorbachev.

He subsequently visited Stanford in 1990. Right around the time I was graduating, and I got to shake his hand. And I wish I had a picture of that, but, but I don't, it's only in my eyes, or only in my brain. But yeah, great, great personal hero for me for so many reasons.

Bobby

That's terrific. As a high schooler thinking about college, debate was something you were very passionate about. Where are you interested in, you know, computers and programming at that time?

Randy

Yeah. So the other thread of this, the other way to tell this story, is my family and I moved to the Bay Area before it was called Silicon Valley. I was born 1968. So I just turned 50. We moved here when I was 1 and a half from Pittsburgh. And my parents met at what is now called Carnegie Mellon University. When they went there, it was called Carnegie Institute of Technology. And my father was in one of the first computer science PhD programs in the country at Carnegie Mellon. He got his PhD in computer science in 1970. And then quickly, you know, immediately after get earning his PhD, came out to California to first work in Berkeley for a company, which collapsed at just the right time, as Xerox was forming their lab, which is called PARC—Palo Alto Research Center. They put that lab together in 1970, ‘71, something like that. Then my father joined as like one of the first six or eight researchers in the lab. As a side note, his PhD thesis was, he proposed FPGAs, Field Programmable Gate Arrays, that's basically reconfigurable hardware. Turns out as another sidebar, there's an Amazon service for that right now, a US service where you can get access to FPGAs. And also, every time you do a Bing search, the ranking of Bing search is done by FPGAs that they have bolted onto the back of the racks of big servers back then that computes the ranking function, which is the hyper expensive part of all the search engines figuring out what to show in first position, tenth position, hundredth position, etc.

Anyway, so they had a project that they called catapult, which is exactly about that. Anyway, he didn't do any of that work. He didn't actually even himself, take FPGAs forward, other people did that. But if you like follow the graph of papers, like back, back, back, back back, the proposal of that was my dad's 1970 PhD thesis, which my mother typed on a typewriter. And you can see that—you can see a PDF of it online, but it is a PDF of printed type where you can see the crossed-out, like, whatever you call it, like Liquid Paper or WhiteOut stuff. Anyway, pretty cool.

At PARC, and this will all connect up in a moment, he pioneered a bunch of modern computer graphics at PARC. So he built this thing in 1973, which was called SuperPaint. It's like the first video digital video graphics system. And like the first paint system, or one of the first. The metaphor is super familiar today—you have a palette on the left-hand side, or actually on the left-hand monitor palette, where you like, have a colors and you choose your brush, and do you want a line or an ellipse or whatever. And then on the right-hand side, there would be a monitor where you would have a canvas and you would draw on there. And so the metaphor is that you'd be familiar with from like Mac Paint or Microsoft Paint or something like Dasher, straight up, like all they're in 1973. And he built that piece of hardware, you know, by hand, like he programmed it in machine code. It was pretty badass, actually. I mean, as all the people at PARC, right, like, he wasn't uniquely badass, he was like, equivalently badass to all the other people. And so subsequently, that work there inspired one of his collaborators, Alvy Ray Smith, who went on later to co-found Pixar with Ed Catmull, when they earned an Academy Award for their work, like a technical achievement award or whatever, in ‘98. I believe they were very kind to the academy went to them and they said, hey, we'd like to give you guys at Pixar this technical achievement award. And to their great credit, they said, we'll be very happy to accept that award. But you have to find this crazy guy Dick Shoup because he was the one who inspired us decades earlier. It's great. And so that was pretty cool.

Bobby

Just to take a second because I think I know and revere the lore that Xerox PARC has in Silicon Valley, but I think that for the next generation that starts to get a little bit diluted, and I always want to always just bring it back, because I think it is just so critical. I mean, I would not be here sitting here talking to you or have the career I have without it. But for me, it was always this part of reverence because it plays a very important part in the, you know, the founding of Apple. And how Steve Jobs and Steve Wozniak went there and I believe got inspired by the graphical user interface. So I don't know if your dad and the Steves ever crossed paths…

Randy

There's an indirect correspondence with both of Steves later, which I can maybe talk about through Alvie. Or through Pixar. There's a whole story about that.

Bobby

But is there a talk is famous for the graphical user interface, but I believe it's a few other hits.

Randy

There are four or five things that they invented there. So they invented the graphical user interface. So that is a bitmap representation of what shows on the screen. So first off the screen wasn't a green screen. Meaning no disrespect, but when you program computers in the ‘60s, or ‘70s, the ‘80s, even the beginning of the ‘90s, a lot of times you would program on a terminal, which a was terminal connected to some big mainframe or some monster computer, but also was only text. And so you know, the introduction of Bitmap graphics, which is now modern, you know, everywhere, like you can’t imagine interacting with a computer without it, that was developed at PARC. So that's pretty great. So that's overlapping windows, that's the bitmap, which means there's a bit in memory, which if it's on, represents a white pixel, and if it's off, represents a black pixel, right? That type of idea. And so that allows you to do, you know, proportional fonts and bold and italic. All this stuff is applied to everything, mix graphics together with text, all that kind of crazy stuff. So cool.

So they did that graphical user interface, they did Ethernet. Every way that you are in the moment communicating with the internet—it's like everything, everything land-wise, is basically, you know, Ethernet or, you know, 10 generations later now. I just saw AWS announce—one of the tiny, tiny little announcements among the massive set of announcements of Reinvent—that oh, by the way, we have 100-gig instances. And that wasn't a thing anybody heard about because they announced all this other crazy stuff. But 100 gig, that's pretty good. That's pretty good. I'm no network engineer, but there was a time when nobody thought Ethernet could go to one gig! Yeah, that was impossible. And they did it. And then they did 25. And they did 40.

So graphical user interface, laser printer, object-oriented programming—because Small Talk was was invented by Alan Kay at Xerox PARC… And then there are a bunch of other ways that are very modern ways of building computers, which were also invented there. So they built the world's first personal computer, which they called the Alto. The guy, Chuck Thacker, who designed the machine, he decided in three months, by the way, with one other guy, one of the main things that they developed, which seems so obvious and modern, but wasn't done was what he called micro-parallel processing, which is the CPU would schedule all the peripherals. So you’ve got to know that in the ‘60s, it used to be that all the peripherals had their own little controller. And so  when Wozniak was putting together the first Apple, it was like 50 chips or 60. And like the fact that he was able to get it from 80 chips down to 50 chips was crazy, amazing.

And so now, we kind of have one chip with a few other ancillary things, but it used to be again, every peripheral—so drive, keyboard, network controller, all that kind of stuff—had their own little controller chip in the correct role, and which would be scheduling itself. And then somehow, they'd have to coordinate with each other, right? And so the genius of this particular element was seeing that he had a CPU that was a lot of time idle. And he could use that CPU power to schedule everything else. And oh, by the way, if you have a single thing that's scheduling all the things, now you can pipeline them and now you can actually do a scheduler.

Bobby

And so for anyone that happens to be down near Xerox PARC, if you're driving in Palo Alto down Deer Creek Road, nowadays you will run into Nest over there. And on the other side of Nest, all of these things that Randy's talking about were created. I think that's pretty great.

Randy

Coyote Point. Oh yeah, it's right down there.

So, you know, as a six year old, I got to go with my dad to work on the weekends. And my brother and I used to beg him to take us to work first because they had this conference room that had been vaccinated. It's like, I mean, no, like, we're sick. Yeah, sure. We would make forts in the beanbags. And that was super fun. As a parent, now I have a 12 year old who will be the third generation of Shoup engineers—whatever kind of engineering he does, because of him, not because I'm telling him to.

It never occurred to me that it was weird as a six year old to beg your dad to take you to work with him on the weekends. We begged him every weekend, “Could you please take us there?” and he was like, “Okay!” And he would go and do more work on his thing. So later we got to play on it like I would build made spaceships, I drew spaceships with the Super Paint, and all that kind of stuff. And then one time he like took me aside and he was like, “Do you want to print that out? Okay, can you do that.” Even color printing was magical. He joked with me as I printed it out on the laser printer there, and I still remember, he's like, “Don't show this to anybody from IBM!” And like, who am I gonna show it to? Anyway, that was super cool.

So that was always the bed in the back of my head. And I always liked math and computers. So while I was in college, even though that was for sure not my career—because by the way, he's got his own Wikipedia page, and he's won an Academy Award and an Emmy and was a great big pioneer. Not that I was discouraged by that, it didn't leave a bad taste in my mouth. But it was very clear computer science was my dad's area. And I needed to find something else, if that makes any sense. Not because he discouraged me but just like, oh, that's what a computer scientist does. And I can't do that. So maybe I'll do some other things.

So my other thing was international law. We said, through college, I did. I was always interested in math and computers and I did want to study it in a serious way. At the time, thank goodness, Stanford didn't have minors, and I totally would have minored if Stanford had minors—now they do. So thank goodness, I went then. But the only way to study it for serious was to double major. And so I ended up finding this eclectic major called Mathematical and Computational Science, which is not in the engineering school. So it was actually easier to do as a double major. And it was like a core of Applied Math, plus Computer Science and Statistics and Operations Research. For the modern people, like Operations Research is what we call Optimization Theory. You know, queueing theory and network optimization and all that kind of stuff.

Actually during college, we don't have to tell all these stories, but as a political science major, one of my friends from high school was my roommate, and he was a double E. And through a long series of coincidences, he ended up getting two offers to have programming internships or internships at Intel over the summer, only one of which he could take. And I remember, I'm sitting there reading, you know, I don't know, Tocqueville, or some American history thing. And he says, “Hey, you know anybody who’d want a programming internship?” And I said, “Well, I would,” because the Arms Control Center hasn't called me back about working on nuclear weapons reduction. And so I ended up taking that job.

But you know, knock on wood, it was a lot of hubris that went into my going down there and interviewing for it. And I just showed him all the top courses I take, and most of which were just math, and I think I'd taken maybe one or two programming courses at the time.

Bobby

Do you remember what languages you were in those courses?

Randy

I do. At Stanford, the Intro to Computer Science course at the time was teaching—this is through Java, by the way—so they taught C++, Prolog, Lisp, and Ada. So every one of those that I say is very of the time. Yeah. Not timely. That is very old at the time. Because Ada was hyper structured, it had exceptions, and it had like, all this amazing stuff. And nobody used it, because it was too complicated for most people, or most compilers to do. But the military could use it. But anyway, I think you learn Prolog because that's the thing and you know, LISP for functional. So that’s really cool. And very intentionally, four different styles of language.

But when I worked at Intel was, there was a program, which they used for statistical process control. So like when you're doing physical systems—even before computers, I know you know this—even before computers, people took measurements of science that they were doing, and they remembered those measurements, and then they use those to figure out was the process of like building this particular semiconductor or this particular mask, was that in in spec or out of spec or whatever. Anyway, so they basically wanted a tool person that could help them build some tools to visualize all these things. And I didn't I use this statistical package, which is called something I totally forget. But they had a proprietary language called RPL, which was very similar to a C language, but it was all garbage collected and everything. So it was very, very easy to use. And so I built using all the tools that they had, I built a bunch of graphs and a bunch of stuff. Just tons of fun.

Bobby

So you got the bug, and then we get to the your end of your undergraduate time. And, you know, the international law, political-science career path…

Randy

Yeah, so when I graduated, that was still my idea. So I did this internship for a couple years after sophomore year, junior year, and then I worked there senior year, two days a week. So it was nice to earn money and stuff. And I was gonna go to grad school, so I was for sure gonna do a law and international relations joint program, because that's how you do that stuff. And there's a bunch of those programs. There's like Harvard and Tufts and Georgetown has those two. It's a bunch of good programs in that, so I applied to all them, but only after two years. First I went and worked for Oracle as a software engineer for a couple of years, basically to screw around and earn some money and have some fun, because, you know, going straight to grad school—that was going to be on the track. And so I wanted to take a break a little bit. I worked for two years for Oracle really enjoyed it. But then  much to the amazement of my manager and other people, I took the GRE and LSAT and applied to all these programs. I ended up going to the program that Stanford Law School has with the Johns Hopkins School of Advanced International Studies in DC—that's a graduate school in international relations, obviously. And that joint program was a little bit of both. But it turns out that at the end of my first year, which was this year at the law school, I thought law school was fine. And then I got what I should have been the perfect job. So it was in Silicon Valley live on Sand Hill Road, by the way, like same complex at, like 3000 Sand Hill, that complex of VCs, it's right next to right next to 280.

We were a tiny office in a big New York law firm. So we had tons of resources. I was the first intern that they'd had, so they were really nice to me. And it was casual dress. Most of my colleagues at the time, this is now ‘92 or ‘93, most of my colleagues or classmates were working in suits in fancy law firms. And I was working in a fancy law firm, but wearing jeans, which I really liked. Anyway, so it should have been perfect for all these reasons. And I just hated the work. Like its intellectual property work, which we think would be very exciting—I thought it would be—but it turns out that getting people patents is not that fun. It's fun to be an inventor, right? It's fun to get up on the whiteboard and describe your invention. Well, what the lawyer does is they they write all the things that you say, and they take pictures of your diagram, and they turn that into some very hard-to-read patent, and they go back and forth with the patent office and fight bureaucratic battles. At the end of which, hopefully, they give you your patent. And their only feedback to the lawyer is okay, either if you got the patent or not. But it's easy to get patents, sadly, way too easy. But then the other feedback is 20 years later, when the patent gets litigated. Did you draw the patent well.

Anyway, so I hated that. Long story short, I ended up having this real crisis of confidence, crisis of my direction in life, and went back to my parents and everybody saying, you know, that thing I've been telling you I want to do for 10 years, I just learned that I don't want to do it. And so I'm gonna go back to software.

Bobby

Thankfully you had a fantastic fallback.

Randy

So many of those coincidences laddered up without any of which it wouldn't have been possible. Like if I hadn't had that random experience with my roommate during internship, all these random things. And the fact that I discovered I didn't like it after the first year instead of… if I had been two years into a four-year program, very different, I for sure would have finished. Even if I knew I hated it, I was like, Well, I gotta at least finish that.

Bobby

We call that the sunk-cost fallacy.

Randy

Exactly right. So the fact that I was first year into it, the fact that that first internship was so perfect in every objective way that I could measure, and also that I hated it… because if it was a terrible boss, or I had to wear a suit every day, just knowing myself, I would have assumed it was that.

Bobby

Yeah. You got a very clean signal from the experiment. You've had such a fantastic career with all these household brands that everyone's really familiar with. I know, it's hard to do this with much depth, but it would be useful, I think, for folks that haven't worked in these organizations, maybe you could just spend a few minutes comparing contrasting the engineering organizations and cultures, because these are all very strong companies in their own right: eBay, Google Stitch Fix, and now even WeWork?

Randy

That's a great question. I will try to do it justice. So yes, so I had the opportunity to work as the chief engineer at eBay for about six and a half years; I worked at Google on the early days of Google Cloud, running engineering for Google App Engine, which is the platform as a service. Stitch Fix, I was the VP of Engineering for two years, grew the team from 25 to 125. And we IPOed and everything, and now WeWork for the last seven, eight months. So yeah, very different engineering cultures and very different kind of phases of companies.

I guess I can contrast the two big ones and the two small ones, and this is very unfair, and it's very different today, but organizationally, when I joined in 2004, so I remember that day. That's a long time ago, because I'm gonna say harsh things like eBay, lots of things about eBay, like how not to run an engineering organization. When I got to Google in 2011, 2012, somewhere in there, I think a lot of things at the time Google had done right. eBay has totally turned itself around, by the way. And it's not even Google today.

One of the things I always point to about eBay, which again, they stopped doing, was they treated everybody all the engineers as one big pool. And they formed project-based teams, but short-term project-based teams, so there's a pool of a thousand engineers, and I have this project, that's going to add this feature to this feature. And for this feature, some engineer has scoped that thing. So some engineer has looked at what the product manager wrote up for the feature, and they did a good job writing it up again. And then some engineer diligently said, “Okay, that's like four weeks of HTML work, six weeks of database work, and 10 weeks of application server work,” and that's literally how they would do it. And then the project team will be formed of who's an HTML person, I'll take one of you, or I'll take two of you for two weeks each. You're already laughing!

I said, I'll take three databasing people for two weeks each. And I'll take two application server people for five weeks each. And note that no one knows all the several things that have happened there. One, you repeat, those people are not permanently in that area of the code. They parachuted in. So even though they're excellent engineers, they have no incentive nor are they allowed to build things properly, or clean up what was there. They just have to add on their new thing in the most horrible way possible. They didn't have any input into the problem. They were solving the feature, they were building the architecture of it, the design of it or the estimation of it. They were told “You have four weeks to do this thing, because some engineer you've never even met said that's how long it was going to take.” Awesome. And again, everybody was well meaning. But the structure of this is what is horrible.

So like no long term association with teams, everything very short term. And so you can imagine after a couple of years of this, the codebase is a disaster, which it totally was. So their solution, which is—I'm just laughing at myself—the solution which benefited me personally, but is horrible from an organizational perspective, and I feel guilty for being a part of it. They were like, alright, well, so these one-thousand people are clearly producing terrible code. So we're not going to change the way we work. Instead, what we're going to do is we're going to hire 20 gray hair people that have been around the block for a while, which I had been at the time, and we're going to hire those people, and they're going to tell the other thousand what to do. Boss says that's the opposite, hence, the eBay architecture team. And they were 20 of the best people I've ever worked with. Again, very strong engineers, well-meaning, genuinely good and nice people, but put in this situation where like, each of us… do the math,  each of us is like responsible for order 50 or 100 people's worth of work. And we're trying to figure out how do you help it be more sustainable. And that was hard.

The the positive end of the story is we ended up disbanding the architecture team, not firing them all, but correctly dispersing them to their individual teams. Because we all had areas of domain expertise—mine was search, but other people had other ones. And people were just dispersed into the teams. That's how we've had this out of state. So that was the history of that.

And there's also a history at eBay, which is that it was never an engineering-driven culture. It's always like more, I mean, particularly in the Meg Whitman and subsequent eras, way more of an MBA-driven thing, which isn't fundamentally bad, but it made it difficult to feel entirely empowered as engineers, and we were typically not as much given problems as given tactical solutions, if that makes any sense.

Google, by contrast, though, is an engineering-driven culture with its own dysfunctions, by the way, its own tradeoffs. But fundamentally, it's a highly empowered organization. And so even at the I think it's now 50,000 engineers, that's not the size of the company. That's the size of the engineering organization. Massive, massive, massive—but it doesn't behave as one top-down thing, it behaves is something like 50 10-person startups or 10,000 five-person startups. And through the process of setting goals and objectives and having those be responded to and met by the individual teams, that's how it works. And so, that is how the Googles and the Amazons and the Netflixes of the world tend to be organized.

Stitch Fix, by the way, much smaller organization, but same thing where very small, highly empowered teams where you give them a goal rather than a solution and they figure out with the help of people that are product, designers etc—it's not just engineers, but like the plurality is, it, if that make any sense?

Stitch Fix, and WeWork were both at similar stages. So again, when I joined Stitch Fix two and a half years ago, I was there for two years. We were 25 engineers in the company, we grew over two years 5x to 125. Yeah. And the beauty of that is it was at a much smaller scale, but that same highly empowered full-stack team model. So we actually ended up growing but through, as I like to say, cellular mitosis. People who remember their high school biology, cellular mitosis is where  a cell divides into two, and each of those daughter cells divides into etc, etc. And so it wasn't always like dividing into two. But when there would be more than, let's say, six people-ish of work to do in a particular area, and we had the people, we would cleave the teams into like two or maybe three sub-teams. And then that's how we ended up going from the 25 to the 125.

And we did that seamlessly. Because we a started with a structure that made sense that map to customer problems. So there was always stuff we were building for the stylists that choose the clothes, there was always something that we were building for the warehouses that store the clothes, there was always something that we're building for the clients, the customers. So that division, that was always true. And even as we grew 5x, the amount of people that we put on those things, the subdivisions among them, like always naturally felt very clean. And also, it's a nice distributed thing. So it wasn't like we had 100 of those 125 people coming through all at once and being onboarded in some central way. Instead, it was very highly distributed. And so each team would, even at that fast growth rate, each team would be maybe growing like maybe one new person a month or two months. From the perspective of an individual engineer on an individual team, it wasn't this massive growth rate, except in aggregate it it was.

Bobby

So when you were growing like that, for the interview process, were they primarily out of those small pods?

Randy

Thank you for asking that. You know your stuff.

We did do a centralized interview process by discipline. Say for a full stack engineer, the stack was rails, so people would, the traditional person would be like, all the way frontend to database, because that's the classic full-stack thing. Then after a while we started having a little bit of specialization. And we had a few operations people that form related infrastructure people, which was excellent, you know. I spun up that team. And then we interviewed differently for those people, for those skill sets.

Over time there were a bunch of specialized JavaScript and frontend skill sets, which we were needing to do. So we ended up having—I'm making this up, but on the order of three or four or five different interview pipelines, but they were all very templated, which was wonderful. So again, when you have that kind of structure, you could distribute the interviews, anywhere, anybody who's trained in that area. It's like, do the first do the phone screen, blah, blah, blah. And then a wonderful thing that I really liked about that interview process was that we would tell people, okay, we have all these opportunities, and we might even reach out to say you should join the team that builds the styling tool. But like, as we go along, we'll learn more about that person, that person will learn more about us. And at the end of it, we'll have a conversation that is like the double opt-in among that management. And then with a candidate like, oh, we originally thought you might want to join XYZ team, that would be cool. But here's this other opportunity that it sounds like marries your skills and interests better. And that almost universally had a great reaction from people on my team.

At WeWork my team builds all the member facing technology. So we built the mobile app that the members use to get access to the spaces, book rooms, and all the steps that they need to do. And then my team also builds tools for the community managers—the receptionist behind the reception desk, that make the buildings actually all work. And that's relevant, because the only metrics that matter is, are the members’ needs being met? And are they satisfied with how we're meeting them? And are the community managers needs being met? And are they satisfied with how we're meeting them? We have much more higher granularity metrics than that. But at the end of the day, we measure ourselves on “Do members want to stay with us longer? And are they satisfied? And is our community manager is able to efficiently do their job and are they satisfied?”

The reason why I say it that way is because from a corporate perspective, and from a leadership perspective, and my thing, it almost it doesn't really matter how we do that. I mean, it kind of does—I do have strong opinions about how to run the engineering organization and all the processes. But at the end of the day, if we are meeting those needs in a sustainable way, that is our job. We have done our job. We can go home and pat ourselves on the back. I

Google does tend to have an outcome-oriented model of OKRs that comes from Intel. Objectives and key results. Not the only way to do it, but it's a decent, well-understood way. And you say what the objective is, like, “I would like to drive revenue this much, I would like to introduce these new capabilities, I would like to allow customers of the App Engine to do this and then the other.” And then we the team responds, in some sense with the key results about how we're going to do that. So it's all about the outcome. And then the key results, and various other ways are like, are really just ways of management asking, Are we on track to doing that? And then the management question to ask oneself is, “What can I do to remove barriers? To make things more useful?”

Bobby

Those are super powerful. I mean, I think it is super important to align around this notion of outcome and customer happiness and so forth. Yeah. But how have you found navigating the fact that a lot of times those kinds of outcomes are things that you're doing in concert with product management?

Randy

It often is a different organization. It should never feel like a different organization. In no healthy organization does product have a set of goals that are non-overlapping or distinct from engineering. So that makes sense. We're all partners in this thing. And the Google model, and also the WeWork model, is that we do have parallel organizations, but we don't have parallel goals or parallel metrics. When I say “my team,” I mean people that don't even report to me. I mean the product managers who don't report to me, I mean the customer support people that don't report to me, I mean the communications people that don't permit work to me. But all of us that work together in this member-experience, member-engagement area, we all have a common set of objectives and metrics.

Bobby

That's terrific. That's the key.

So one last piece of trivia that I think is kind of interesting. So I believe that your last name harkens from the German-speaking part of Switzerland.

Randy

That is true. It's true.

Bobby

So I'm a little bit of a tennis nut. And one of the greatest tennis players of all time is from the German-speaking part of Switzerland: Roger Federer. So I don't know if you play tennis, but if you didn't, I would give it a try. Because apparently there's something in the water there.

Randy

That's funny. So I am not a tennis player. But my father was incredibly good. He was played table tennis in college and was very competitive, like nationally competitive at table tennis, and could play as a consequence. He could wipe the floor with me in any racquet sports. That's racket ball, tennis, all those things. I didn't get that. It's a generation-skipping thing.

Bobby

Maybe your son will get it!

Randy

Maybe so. Maybe so.