# How I Doubled eBay’s Productivity - And Still Got Fired

## Метаданные

- **Канал:** InfoQ
- **YouTube:** https://www.youtube.com/watch?v=nSfdsue3Wps
- **Дата:** 14.05.2026
- **Длительность:** 49:17
- **Просмотры:** 3,296

## Описание

Can you double engineering productivity and still fail to save the company?
 
Former eBay Chief Architect Randy Shoup reveals the raw, "middle-out" truth of eBay’s massive DevOps transformation. From co-inventing database sharding and Kafka-style messaging in 2000 to battling a "culture of fear" and 10-day lead times in 2020, Randy shares the technical triumphs and the organizational "third rails" that eventually led to his exit.

If you are a senior developer, architect, or engineering leader, this is a masterclass in the Innovator’s Dilemma. Learn why DORA metrics and high-performance "Velocity" initiatives are often not enough to overcome centralized waterfall planning and "learned helplessness" in a flat business.

⏱️ Video Timestamps (For Navigation)
0:00 — The Rise and Fall of eBay Velocity 
1:15 — What eBay invented (Sharding, Tracing, Circuit Breakers) 
3:45 — The State of eBay in 2020: 10-day Lead Times 
6:10 — The Value Stream Map: Identifying the Bottlenecks 
9:00 — Doubling Productivity: Outcomes of the Velocity Initiative 
12:30 — The "Randy Shoup" Playbook: No Original Ideas, Just Execution 
15:55 — Scaling the Transformation: S-Curves and Pilot Teams 
18:40 — Modernizing Mobile: From "Impossible" to Weekly Releases 
21:15 — Why We Didn’t Save the Company: The Innovator’s Dilemma 
24:30 — Strategy vs. Execution: The $1.5B Payment Project 
27:10 — Pathological vs. Generative Cultures (Westrum Typology) 
31:00 — The "Third Rail" that got Randy fired 
33:45 — Lessons Learned: Top-Down, Bottom-Up, and Middle-Out 

🔗 Transcript & slides available on InfoQ:   https://bit.ly/4nABJjC       
   
#SoftwareArchitecture #DevOps #EngineeringLeadership #DORAmetrics #eBay #TechStrategy

## Содержание

### [0:00](https://www.youtube.com/watch?v=nSfdsue3Wps) The Rise and Fall of eBay Velocity

Great. Thanks. Yeah, I'm excited to be back at QCon. My first San Francisco was 2007, so yeah, 18 years and counting. Um, yeah. So, today I want to talk about lessons from the rise and fall of eBay velocity. and I'm going to tell you the story of what so far has been like the biggest achievement of my professional life and then I'm going to tell you how I got fired for it. So we could also have called this talk uh this how we doubled engineering productivity at eBay which we did but we still didn't save the company which we didn't. Um so uh I don't know how many are old enough to remember the start of eBay. Uh I'm old so I actually do remember when eBay started. This is back in 1995, the beginning of the web. And it might be hard to remember now, but in the first 10 years of eBay's existence, it was really a very uh pioneering technology company. I mean, not just like pioneering in the business model, which it was, but also really pioneering in terms of technology. So, here are some things that eBay invented or

### [1:15](https://www.youtube.com/watch?v=nSfdsue3Wps&t=75s) What eBay invented (Sharding, Tracing, Circuit Breakers)

co-invented along with other uh places at the same time during the first 10 years of its existence. So database sharding, a real-time search engine which had never been built on the planet before 2003. Eventual consistency at large scale as distinct from doing everything uh in these monster, you know, synchronous database transactions. Distributed tracing, we had that in 2000. Centralized logging, Feature flags, we called it something different, but we had that in the early 2000s. guaranteed messaging. So think Kafka with a transactional outbox and item potent consumers and readback. Uh it's basically Kafka but in 2006. Uh SLO driven configuration of system software circuit breakers, we called it something different. Graceful degradation, staged cluster deployment, and then automated coordinated multicluster rollout. So that's not too bad for the beginning part of uh of the web. I mean that was 30 years ago. Uh so here's what's happened since then. So in the year uh in the year 2007, eBay's gross merchandise volume, meaning the sum total of the goods and services that are transacted through eBay in 2007 was $50 billion US. It is today about 75 billion US. So that's a 1. 5 times uh growth. Well, okay. Uh this is what US e-commerce has done uh over that period. So, US e-commerce has grown 8x. Uh, eBay GMV has grown 1 and a halfx. And if you correct for inflation, which has been 56% since uh 2007, it looks like this. So, what happened? Uh, my part of the my second part of the story because I've been there twice. Uh, my second part of the story starts in 2020 when the CTO who I'd worked with before um came to me and said, "Hey, Randy, I need you to come back as our chief architect. I need you to shake things up and I need you to help me bring eBay into the modern world. And that was a pretty exciting uh idea. I was really excited about this idea because I actually really love eBay. Uh so here's what eBay looked like in 2020. So we had 3,000 engineers or roughly 400 teams and what we called the core product organization. That's basically the product engineering, customerf facing stuff and everything behind it. And then 2,000 engineers in what we call the core technology division. That's all aspects of systems, software, infrastructure. eBay maintains its own proprietary data center. So, it's like all of that kind of stuff all in those 2,000 engineers. Uh what also was true at that time was uh eBay is uh

### [3:45](https://www.youtube.com/watch?v=nSfdsue3Wps&t=225s) The State of eBay in 2020: 10-day Lead Times

had multi-quarter initiatives that were going across uh 50 teams um sometimes more than 50 teams. Uh 4,500 applications and services around the site that were all actively you know working. Uh the deployment frequency uh was about once or twice a month on average for each of those uh applications. and the lead time for change. So the time between a developer committing her code and it actually shows up on the site was 10 days. So I had my work cut out for me. Um and of course anytime you want to do some kind of transformation or introduce uh platform engineering ideas is you really need to assess where you are. So I started with what we would call in lean a pro a uh value stream map. I basically looked end to end at what did the software life cycle look like and this is my words for it. You can use any words you like, but it to my mind the software or the product life cycle has these phases. There's planning, which is how does an idea become a project. There's software development. How does a project become committed code? There's software delivery. How does committed code become a feature that customers can use on the site? And then post-release iteration is how we change and iterate on that uh feature in real time. uh and I uh survey I couldn't talk to all 4,000 or all 5,000 engineers of course but I surveyed a sort of um cross-section across uh the eBay sort of engineering ecosystem and I found we found very consistently a bunch of problems that everybody was facing. So on the planning side, there was lots of inter team coordination, tons of dependencies, and literally every team at eBay had too much work in progress in terms of software development, lots of challenges with build and test time, lots of context switching for individual developers, a very highly coupled architecture, which as you can imagine with the chief architect hat, that was something I was concerned about, really no service contracts between individual services of those 4,00 applications and services, and tons and tons of hidden work behind the features you know that we were delivering in terms of software delivery minimal pipelines I mean there were pipelines but like they weren't great uh lots of issues with our common staging environment still a bunch of manual testing in a lot of areas no fully automated rollout all the way from commit to the site no canary deployments and then even though we had co-invented feature flags 20 years earlier they weren't being used effectively or much at all uh in terms of post-release iteration we had lots of gaps in terms of our monitoring

### [6:10](https://www.youtube.com/watch?v=nSfdsue3Wps&t=370s) The Value Stream Map: Identifying the Bottlenecks

uh tracking issues and what I call dysfunctional experimentation where some teams were not doing any experimentation at all and other teams were experimenting to the nth degree. Uh okay, lots to fix. Um should I do them all at once? Well, absolutely not. Um so we decided to focus in this central area around software development and software delivery. Why? Because if we can improve software delivery, it makes everything else possible by enabling faster change and reducing the cost of change. Right? So back to Nicole Forskrin's uh wonderful keynote this morning um by reducing the cost of change uh shrinking the size of changes that you make instead of you know iterating once a month and like getting 12 bytes at the apple during the year what if we iterated every day and we got 365. Um so what we wanted to get was this. So we wanted from a planning perspective instead of big upfront planning that you did you know the year before instead rolling planning with small cheap experiments and then if and only if something is successful only then do we double down with a big massive coordinated project. From software development we would like to have small batch sizes. very fast build and test iteration. We would like for every developer to check in uh his or her code every day. So daily merges and deploys. And we would like to have a decoupled architecture software delivery. We wanted to have a fully automated test and deployment pipeline. We would love it if it went one hour from commit to deploy rather than 10 days. Uh when we wanted to iterate in production with feature flags. And then finally on the post release iteration side, our goals were endto-end monitoring of the user behavior, tracking everywhere, small cheap experiments again and then rapid feedback on the results. So that's what we wanted to do. So how did we uh approach it? We started what we called the velocity initiative. We wanted to go faster so we called it velocity. Uh and I started this work in 2020. Uh as I will tell you later uh I was let go in 2022 but that work has continued and most of my team is still there doing this work uh very effectively. So I'm going to talk about the outcomes and then how we achieved them. So the the main outcome which I feel super proud about is we doubled engineering productivity. So for all of the teams that we work with and when I was there it was 25% of teams but now it is 100% of teams for every one of the teams that we work with we doubled the number of features and bug fixes that they can do in unit time. So this is something that's called flow velocity and essentially it's you know how many things can you get out the door whether features or bug fixes with the same team uh same team size same team composition. Uh in terms of the dora metrics which are super important uh as we learned this morning in the keynote or maybe reminded ourselves in the keynote we improved the deployment frequency 10x from 10 days to 1 to two days. We improved lead time for change uh oh sorry um deployment frequency 10x uh lead time improved uh 5x so 10 days to

### [9:00](https://www.youtube.com/watch?v=nSfdsue3Wps&t=540s) Doubling Productivity: Outcomes of the Velocity Initiative

two days change failure rate even though we weren't focusing on those areas actually also improved 3x and time to recover improved 3x so in 2020 this is what eBay's DORA metrics looked like so really solid medium performer you know between one week and once per month uh deployment frequency between one week and one month lead time for change time to restore service change failure rate and this is what we did for all the teams after we uh we did the first iteration of this work. So we basically moved every team at eBay from 35th percentile medium performers on the Dora metrics to 75th percentile high performers. So that feels really good. Um how do we do it? Uh well as I like to say I had no original ideas through this entire time. It's really just executing the very standard DevOps accelerate Dora playbook. So, exactly as Nicole told us this morning, we focused on identifying and removing bottlenecks. If there was a bottleneck that bottlenecked a bunch of teams, we focused on that. We released that bottleneck. Then there was the next bottleneck behind that. We worked on that and so on and so on and so on. As somebody said, once you solve problem number one, problem number two gets a promotion. Uh so we uh tactically or uh tangibly we substantially reduced build test uh startup and PR validation times. We invested really heavily in the reliability and the comprehensiveness of the common staging environment. Um we did a ton of automation around upgrading the software around testing around deployment and around sight speed which is like user experience latency. Um and then we also did a lot of work that was not technical at all but was really about process. So we streamlined a bunch of team processes, we streamlined the code reviews and we removed uh and streamlined what uh eBay used to call partner signoffs. So it used to be true that if I build uh built a platform sort of component or service, then uh whenever I wanted to make an upgrade to that uh component or that service, I would have to explicitly ask all of the teams that used my software, could you please test with my new version, and I would have to wait for all of them to say yes, yes, yes before I could release version number uh version number next. Can imagine that doesn't work very well if you want to move quickly. And so uh one of that was one of the things we tried to get rid of. Uh so how did we work? Um this was uh unfortunately new uh but it was very effective which is we collaborated. Um so we had cross functional leadership. I led from the platform and infrastructure side and then I had a wonderful partner uh Mark Weineberg on from the kind of product engineering side. So we kind of both uh led this program uh together. We had what I like to call an embedding model where people on I hired really senior individual contributor architecty tech leady people into my team and then in my phrase I would send them out into the provinces to go learn you know pair with people in individual areas of uh of eBay uh learn their problems help them directly if you could solve them directly but then also bring back to the central platform team here are the problems that we're experiencing over here in the buying area or in the selling payments area and so Um and then this was new but it shouldn't have been. Um platform and product engineering teams really work closely together. So like we when we built something in the platform we'd say hey which teams want to like be alpha testers with us and teams you know some number of teams would raise their

### [12:30](https://www.youtube.com/watch?v=nSfdsue3Wps&t=750s) The "Randy Shoup" Playbook: No Original Ideas, Just Execution

hand and we'd worked very closely with them on new things that we were building. Uh communication was super important. So we did daily leadership standup. So I and my partner in crime met every single day after lunch you know without fail. super helpful to like unblock each other and help move the thing forward. We did a weekly team of teams meeting where all the teams that were involved at any given moment in this program uh all came together and talked about the things that they were struggling with uh celebrated their wins and like a little bit of friendly competition about you know teams making uh improvements over here and over there. We did weekly deep dives with individual teams. So again going and asking hey what can we do to make your life better? Um and then a monthly operating review with executive leadership. Uh again no uh none of these ideas is uh is new. Um so we use the Dora metrics as I was telling you before as our outcome metrics. So we wanted to drive faster deployment frequency shorter lead time for change uh as our in input metrics and this um grew more after I was there but um measures of developer friction. So looking at the pipeline for you know somebody deploying their software noticing when things get stuck or when things are bottlenecked you know process-wise or technology-wise or whatever and then just releasing you know talking to whoever releasing those bottlenecks and making things flow better. Uh we as part of that work we instrumented the entire end toend uh delivery pipeline. We had timing for every step. We had success metrics for every step, which meant that we really had this global view of where people were struggling with, you know, doing software delivery, but also we could drill into specific uh business units, specific teams, specific builds, specific deployments to kind of figure out what uh what we could do to make things better. And then we just iterated over and over again. So we again the uh this is called the Deming process from uh W. Edwards Deming back in the 50s. Um he's the one who went and taught the Japanese or worked with the Japanese to do the Toyota production method and like you know all sorts of great stuff. Uh so uh the cycle is called PDCA. Plan, do, check, act. Have an idea, try it out, see if it worked. If it was good, do more of it. If it was not good, do something else. Here's how this worked in practice. So I would go to teams and again we were meeting with every team every week pretty much. Uh hi I'm your friendly neighborhood chief architect. If I see that you're deploying you know once every two weeks once every month. Okay cool. Um but if I told you that you had to deploy your application every single day tell me all the reasons you can't. And that's not a challenge. That was like an opportunity. And so they said okay Randy you know do you want the whole list or just the top 150? Um and here are all the reasons you know that are preventing us and um they had said these things before but you know the previous approach of the platform team was mostly not to think about it but now I was like okay great you just gave me my backlog your impediments are exactly my team's backlog and as you can hope that um that fostered a lot of collaboration and partnership from those teams uh so in terms of culture and behavior one of the I think was super important was that we made it fun. We made it fun to do this

### [15:55](https://www.youtube.com/watch?v=nSfdsue3Wps&t=955s) Scaling the Transformation: S-Curves and Pilot Teams

work. So we had regular weekly progress on the metrics. You know, um winning is fun, right? Making forward progress is fun. This is a lot why we all become engineers. Um and then again, as I mentioned in that team of teams meeting that we would have every week, um the teams would be inspiring each other to improve. Uh and also telling them why like we're all on the same team here ultimately. So you know this team over in selling you know improved their code review process or improved their rollout process and people would say wow your metrics uh you know you moved your metrics in this great way what did you do and they said well here's what we did and here's the tool if you want to use it or you know here's the ideas that we had. So everybody really working together and trying to make the whole place better uh in terms of community and sharing. So it used to be true that platform teams automated things and wrote tools and product teams consumed them. I mean that's not terrible but I don't know product teams are engineers too. And so a lot of these conversations ended up with uh product teams automating their own things. So a lot of automation around their code review processes, automation around performance testing as I mentioned sight speed and so on, automating accessibility testing, uh all sorts of stuff and a lot of those and all of these examples were ones my team didn't touch at all. We just sort of inspired it by like having the open conversation. One team decided to take the plunge and then you was uh shared among everybody. Uh we did regular team demos as part of this uh team of teams. So again uh really trying to encourage teams to um have fun and to uh celebrate their wins and then again as I mentioned you know sharing tools and learnings really broadly across the organization. Uh so as a consequence we had a lot of partnership with our customer teams. Um and particularly we'll talk about this in the second half of the talk but one of the challenges that eBay has had over time is sort of a culture that was a culture of fear. And one of the things that was really important for my partner and I, my partner in crime and I, is to make it psychologically safe even for teams to say that they were struggling. Like we needed to help people to understand it's actually okay. I mean, okay, you deploy once a month. That doesn't mean you're a terrible person. That means you deploy once a month. Let's figure out how it can be twice a month, three times a month, 10 times a month, that kind of thing, right? So there's no terrible. There's only like where we are and then can we get a little bit better or maybe even a lot better. Um and again everybody doing it together also made that easier if you see what I mean right every team saw other teams having their impediments having those impediments you know released or helped or whatever um and sort of encouraged everybody to get better. Um and then you know uh again I came from the platform and infrastructure side and so the other

### [18:40](https://www.youtube.com/watch?v=nSfdsue3Wps&t=1120s) Modernizing Mobile: From "Impossible" to Weekly Releases

aspect of partnership was um teams that traditionally would be seen as impediments to flow like hey sec you know I do everything every day except for you know the security team. Okay let me go talk to the security team and see what we can do to like shift that to the left. Uh well I do it daily except for compliance and socks related stuff. Okay great let me talk with the compliance team. uh I could do it except you know I have to do these really long running accessibility tests. Okay, great. Let's figure out how we can run those accessibility tests either offline or faster or something like that and localization etc etc. You see just the general idea is like state the problem and then we'll figure out together what's the right kind of place uh to solve it and then at least for the the first part of the time that I was there was really strong executive support. Um so the CEO was constantly highlighting this work in their company all hands. Um my partner and I presented to the eBay board of directors. It was mentioned in quarterly earnings calls and then um no pressure guys uh but you know we kept hearing uh this is the most important initiative in the company and we need to go faster. Uh so uh scaling the initiative so um we started out with a bunch of pilot teams that represented about 10% of eBay's uh engineers. So maybe 400 engineer or sorry 300 engineers out of the 3,000 maybe 40 teams out of 400. Um and you know we worked with those teams at a really extended period for the first year and then we kind of got we figured out how things were going and then we also like had already removed a bunch of bottlenecks and then we could start to go faster. So then we would do quarterly cohorts. So we would bring in you know another 10% or another 15% of teams you know in Q1 of a year and then another set in Q2 and another set in Q3 and you'd have this kind of like cons S-curve. So like you know successive S-curves of okay what this team these teams are starting and then they're getting more mature and then we start the next set of teams and they're getting more mature and so on and then we expanded quarter over quarter and then I'm happy to report that you know my former team is still um uh doing that work and again now they've touched all the teams which is fantastic uh so in terms of automation uh that's the other aspect of scaling right so one aspect of scaling is like making it wider but the other is making it easier so uh again we did regular deployments for every application and service even if uh as was true of many of those 4500 even if they weren't actively maintained. Why would you do that? Cuz if there is a bug, which sometimes there is, or there's a security vulnerability, which often there is, uh you need to be able to re-release it in a safe way. So

### [21:15](https://www.youtube.com/watch?v=nSfdsue3Wps&t=1275s) Why We Didn’t Save the Company: The Innovator’s Dilemma

we automated what we called a patch pipeline. Uh and we use that for uh things that should not be behavior changing, right? So like security vulnerabilities, dependency upgrades, uh we had lots of legacy and proprietary API. So as we made uh improvements to them, we automated uh all that stuff and um there was a lot of great engineering that went into that work. Um and it made it really seamless for a lot of teams to not have to learn how to do this stuff. Um the other thing which happened mostly when I wasn't there um but I'm so proud of the team that did this um is they really introduced AI across the entire software development life cycle. So really starting from the CI process um and then like expanding uh right onto production and expanding left in upstream into the kind of uh day-to-day developer workflow. So obvious things that you use a AI for are you know code generation, test data, sure legacy code migrations, absolutely PR summarization and code review, you know like automated code reviews uh which help the human code reviewers. Uh then uh maybe not so obvious but like use AI to help manage the CI pipelines themselves or basically point when a build fails like analyze why uh produce an RCA if it was really bad. um analyze the test failures uh predictively optimize the pipeline uh efficiency um and then uh downstream deployment monitoring and automated rollbacks when things went to the site and then also sort of um helping out the human so uh not automated but um LLM generated developer support documentation feedback analysis etc. So there's a wonderful talk by my uh former team member Arvin Khan at CDCon where he talks for 25 minutes on all this great stuff and there's probably 25 or 30 different parts entirely independent parts where they introduced AI. So really fantastic work. The other thing I'm really proud of is mobile modernization. So eBay was really early actually to uh having mobile apps. So very early maybe 2006 I want to say 2005 2006 eBay had iOS and Android apps out there in whatever they were whether the app stores or whatever um and as a consequence of course you know 15 years of accumulated croft and you know and originally they had to build all their own frameworks because nobody had them now there's swift UI now there's jetack compose and so like remodularizing the architecture and there's a lot of work associated with that um and then uh release management And so one of the things that was most one of the most impactful things that the team did was go from monthly uh releases when I rearrived at 2020, eBay was releasing their iOS and Android apps monthly. Now they can do it in one day. Uh and there's a lot of work that went into this. Um and uh in fact the most skeptical person that we could get to weekly deployments was my mobile release manager. And so I said to him, hey, let's see if we can get to mobile, sorry, to weekly releases by the end of this year. This is 2021. So let's imagine we started

### [24:30](https://www.youtube.com/watch?v=nSfdsue3Wps&t=1470s) Strategy vs. Execution: The $1.5B Payment Project

January 1st and we were doing monthly releases. And hey, by the end of the year, could we have a stretch goal of doing a weekly release? And this guy told me, I love this guy. He's like, can't be done. Okay, let's give it a go. Uh, you're probably right. Whatever. We'll see. Let's give it a go. So then um uh we're at April. So four or five months in, say it's April, um we give we try the first bi-weekly release. I'm like, that's not so bad actually. So we did a few more bi-weekly releases. Uh and then we got to July and the team was like, you know what, these bi-weekly releases are going really smoothly. Like there's a lot less changes when it's two weeks versus a month and it's a lot easier to figure out what's wrong, etc., etc. And so let's give a go. Let's give it a go to see if we can do a weekly release. And we did one uh seven months in and we never stopped. We never once stopped. So we went from and when I say we, I didn't do the work. That team went from it's impossible to do that Randy in 12 months to 7 months on their own telling me they could do it and did do it. So great work. Uh and this is what he said to me when I reconnected with him recently. Again, fantastic guy. Love this guy. you Randy, you were kind enough to help me adapt and see the light through air cover and rational small tests of the process and that's how we got uh fast uh build and release for um for mobile uh apps. Uh the other thing that really warms my heart when I've reconnected with a bunch of people on my team uh recently is multiple people not just one but many people have said you know when we're having a discussion we ask what would Randy do makes me feel good. Okay, well that's great. Uh, problem solved. Uh, talk is done. Well, we're here. eBay is still a household name, still with a flat business. So, let's take a really hard look at assessing what we were able to achieve and maybe why we weren't able to get as much as we would have liked. Again, very, very proud of all the technical improvements that we did. We absolutely improved the lives of every single developer at the company. So, these were the intended goals. This is the slide that I had up earlier. Uh what did we actually get? Well, we didn't get everything. That's fine. Uh in terms of software development, we did I think fairly get build and test iteration. Like I think that's fair. We did get for many applications daily merges and deploys. That's pretty good. Not for every engineer, but at least for every uh application. We got a fully automated test and deploy pipeline. Like I think that's actually fair all the way through to the site. Uh including canary deployments and so on. We there's a lot more iteration in production with feature flags and I think we'd made some good strides on end to end monitoring. Well, okay.

### [27:10](https://www.youtube.com/watch?v=nSfdsue3Wps&t=1630s) Pathological vs. Generative Cultures (Westrum Typology)

So, we made all these improvements and we should feel proud about them, but like why didn't we save the company? Uh, I can think of four reasons. strategy and planning. I can think of execution and delivery. I can think of technology deadends and I can think of organizational culture. So, let's talk let's start with strategy and planning. So one of the challenges of being an early pioneer like eBay is what's called the innovator's dilemma. So this is something that postulated by Klay Christensen that um when you are an innovator in a space and like are really successful it's hard to disrupt yourself like there's this mental model to like are you going to be able to disrupt yourself and we were chatting at lunch and like a very small number of companies have done that. Netflix is a great example, by the way. Used to ship DVDs. Now I hear that they do some streaming. Uh it is very difficult to uh to disrupt any business model, but it's particularly difficult to disrupt a really successful business model. Uh and so if you want to disrupt eBay, here's how you do it. You don't try to be eBay everywhere and for every category. You become the eBay of a particular category and do that. So, you decide, hey, I'm going to be the electronics used store or uh instruments, you know, musical instruments used store or I'm going to be the clothing used store. By the way, I just named without naming them three or maybe 10 uh eBay competitors. So, that's how you do it if you're interested. Uh the other thing is learned helplessness. So again, we saw that essentially flat uh graph of I mean flat in constant dollar terms uh of um of the gross merchandise volume. And so all of the people that have kind of grown up within eBay over the last 15 years have had that as their experience there. And that doesn't mean they're terrible people, but it does mean that what is adaptive in an environment like that is really being very riskaverse. Does it make sense what I'm saying? like if if you're kind of in this flat unchanging situation, the correct adaptive approach is to be very riskaverse. Uh and that's what happens. The other challenge is that the aversion to risk is well-earned. Um the one of the things that's really been challenging over the long term is eBay's relationship with a seller community. And um it seems sometimes that like every time we make a userfacing change it would be met with like revolt. And when I worked there the first time from 2004 to 2011 I worked on eBay search engine and every time literally every time we would make improvements to the search engine for the buyers sellers would get mad. So as an example we made spelling we introduced spelling corrections. So, let's imagine like you tried to sell an iPhone, but you spelled it I fo ne instead of I p. Well, there was somebody whose business model was looking for misspelled iPhones, buying them, and you know, buying low and selling high. That was the arbitrage model that not like one person had, but like hundreds upon hundreds of people. Similarly, when we made improvements to the ranking function for search to show more relevant items, again, we disrupted business models because people had learned how to, you know, find the really good stuff in there, right? To kind of go digging needle in the haststack kind of idea, they would find those things, buy low, sell high. And so, every time we made improvements, like literally an improvement, it was disrupting somebody's model. So eBay is large enough and and enough of an economy that every inefficiency in eBay's world is an arbitrage opportunity that somebody's already exploiting. Cool. Okay. Uh centralized waterfall planning. So this is something that's always been true. Uh so uh there's an annual multimonth companywide planning cycle.

### [31:00](https://www.youtube.com/watch?v=nSfdsue3Wps&t=1860s) The "Third Rail" that got Randy fired

Um and the way that works is this. uh work can only an initiative can only happen if it's approved by the executive team. Okay. Work uh an initiative can only get to the executive team if it's big enough to get on the list that's presented to the executive team. Uh so if you have a smaller project that doesn't involve, you know, tens of teams, it actually can only be can only really survive as being like a writer. If you guys know what that like a rider on a congressional bill uh like you tack yourself on to some other big project because that's the only way it can get approved. Uh exe execution and delivery. So uh I mentioned before that you know there's a history of really massive coordinated releases and for some of these things you know a bunch of them are complicated but some of them where the cycle time meaning the end to end time is measured in quarter or quarters or years and more than one of them has involved 50 or more out of 400 teams. So one example is eBay managed payments. So people may remember that eBay and PayPal used to be one company right? So eBay acquired PayPal in 2002 and then they went their separate ways in 2015. Well, as part of the separation agreement, um PayPal was still the payment provider for eBay for the next 5 years. So like from 2015 to 2020, uh PayPal remained the payment provider. Great. I mean, that made perfect sense. But what that meant was there's a deadline at 2020 where eBay is going to have to, you know, learn how to take credit cards. And so I don't think the work started 5 years didn't took the whole 5 years. I they maybe they started maybe the last three years, but there were about 2,000 people that worked on that project. Um, and so if you do the math of three thou 3 years times 2,000 people, that's 1. 5 billion US in personnel costs alone. Um, and unfortunately it ended up having slower payments for sellers because when you use PayPal, you get the money right away, but when you go through the banking system, it like takes, you know, a day to clear or maybe three days to clear, etc. Uh, feature factory. So uh that's a phrase that we used to use uh about it um where again this is in this you know what's adaptive essentially flat business um is focusing if I want to be successful and I can't drive outcomes I want to focus on meeting milestones and like being really predictable and you know doing activity um so you know rewards for milestones uh as distinct maybe from customer value uh one of the things I remember most um vividly was when I joined the first time in 2004 before um and I was sitting with Karen Cassella, my um uh my manager at the time. She works has worked for many years at Netflix and now is retired. Love her. Um so the VP of engineering was up. We had a big you know all hands of like a thousand people uh much like this. Um

### [33:45](https://www.youtube.com/watch?v=nSfdsue3Wps&t=2025s) Lessons Learned: Top-Down, Bottom-Up, and Middle-Out

and uh the VP says uh we should be very proud. We delivered 5,000 train seats to the business this quarter. You're like what in the world is a train seat? A train seat is two weeks of engineer work. So think of it as two engineer weeks. Two person weeks. So a way to think a way to restate what she said was we did 10,000 person weeks of work. Yeah. 5,000 train seats, So again, if you do the math, that's saying we spent $60 million because it doesn't say anything about the outcome, right? Doesn't say we grew revenue by X. We grew profitability by Y. We reduced uh we improved reliability by Z. It said hey we delivered this amount of effort. [snorts] Uh technology dead ends. So you remember the opening slide about here are all the great things that eBay did in the beginning and they were really great. I mean really revolutionary stuff. I was so proud to be a part of it you know at the tail end of that. Um but also lagards in some technologies right this happens. Um, for a long time, eBay was generating HTML via starting with XSL XML and using XSLT to generate the HTML. Uh, that didn't age well. Uh, SOA was shared databases. So, um, for a long time, uh, they had so well so it was shared databases as opposed to individual databases for the services. Um, in terms of infrastructure, like eBay maintained a custom OpenStack fork for a long time. Uh then that got way out of date with the mainline. Then they went to Kubernetes and again a custom fork way out of the mainline. It's been a challenge. Um running your own data center. Uh Hadoop is still the um data warehouse. Uh there's a proprietary JavaScript framework which I guarantee no one's ever heard of called Marco. Um and proprietary mobile frameworks until now. So like now it's Swift UI and Jetack Compose which is great. But like originally and it's not even wrong like 2006 neither of those things I mentioned existed. Um, also eBay is sort of late to the public cloud, by which I mean eBay does not use the public cloud. Um, really late to open source. I mean, like obviously eBay is a consumer of open source, but I and one of the people on my team like was the open- source like guru or whatever. Um, uh, open- source uh, manager person. There's a better word for that. Um, uh, at eBay. Uh, it was going to be me, but then I was like, it shouldn't be me. somebody who worked for me uh was on that and I really am passionate about open source as I hope many of you are but I wish I' I wish we saw more eBay open source projects if you see what I mean right like it's you know there's not as much of stuff that eBay is like actively maintaining out in the world um versus a bunch of other companies that are similar size and kind of similar name uh pretty late to microser and microservices and isolated databases um late to continuous delivery like that was what I was there to do um as I mentioned late to fully automated testing like end to end without human involvement. Um they're still kind of struggling to get interface contracts uh effective. Uh late to automated canary deployment that was something that we introduced on my team. Um and then late to GraphQL. So uh at the end I want to talk a little bit about organizational culture because I think that is the um the driver of a lot of these things. Um so uh people are maybe familiar with this accelerate book. Who has read the accelerate book? Everybody who has not raised their hand, walk right out of the room right now, go buy the book, read it, and then you can come back and watch the rest of it. No, I mean it's a land say landmine goodness. It's a landmark uh in our industry like Nicole Forsrren who you know gave the keynote this morning uh and you know was very modest about not talking about all the amazing things she's done like she has given the world the way to do good software. So read this book. Uh one of the many uh and it's a small book. One of the many things that it points out is how important culture is to software delivery performance and then also to organizational and business performance. And so she leverages a typology of a sociologist named Ron Westerm who talks about pathological cultures, bureaucratic cultures, and generative cultures. And you know, one of the challenges and you know what happens is like if you have a generative culture, you're going to be do really well on the dorometrics. If you're a bureaucratic culture, you're going to do middling. And if you're a pathological culture, you struggle to um to be good on the metrics. Um and this is something that really characterizes a bunch of the things that I that I saw at eBay and I'd love to see changed. So I love the company. I really do. Um and again the research that went into the accelerate book uh has proven that organizational culture predicts software delivery performance and also predicts organizational performance. If you tell me what your organiz organization's culture is like, I will tell you that it is way more likely to have this kind of software delivery performance or that kind. So uh pathological cu uh organization there's a big culture of fear. Again I want this to be better. I really do. Um but there's a big culture of fear. So very highly political. Again this you know it's this uh you know uh household name with a flat business situation. Uh acknowledging failure is seen as rude or even threatening to people. Um there's a lot of emp as a consequence empire building for executives. Right. Again it's a zero sum kind of scarcity mindset situation. Uh, and so if I were max trying to maximize my success at the company, which I did not, um, I would try to maximize my span of control over my team's span of control and I would try to maximize the size of my team. Uh, eBay has an idea that they're exceptional. And I think that's not wrong for companies to like feel that they're unique, like there's a reason why the company exists. Um but one of the uh bad outcomes of that or at least that I uh experienced a couple of times is a sort of a syndrome of not invented here. So there are lots of indust industry standard approaches out in the world and rather than adopting them by default and only then thinking about proprietary mechanisms the culture is a little bit the reverse of that if that makes sense. And one of the contributing factors it's not the only one is that people tend to stay a long time. I mean, that's great because it's a fun place to work. Um, but it's a challenge because you um when people in my team of 150, I had five people that had crossed their 20-y year anniversary and great people like it's not about the people. It's like but those people had 20 years of experience at one place. You see what I'm saying? Uh again, top down waterfall planning. So, um you know, in many situations, you know, the plan has kind of been set in stone, you know, 12 months or maybe even 18 months before. Um so not a lot of real-time autonomy to adjust to market conditions or changes in the product or rather changes in the environment. Um there's a fantastic experimentation platform that is very good from a statistical perspective but often it's used either to confirm the ideas that they had 18 months ago about what how the feature was going to do um and then in this culture of fear used to make sure that nothing broke. Um not going to go into a lot of detail about this. Uh but the reason why I was fired was the third rail that I touched was um pointing out to another uh colleague of mine that um uh that it is not agile to have uh requirements gathering sprints, then design sprints, then development sprints, then QA sprints, then rollout sprints. Um that's what's called waterfall. Uh so uh in this person's organization there was a real culture of terror unfortunately. We had a bunch of refugees from that team that came into mine and boy they could tell some stories. Um big empire building from that person as I mentioned faux agile. Um and unfortunately this person like decided to um there were a bunch of quality issues several years before I had come back. Um and they personally approved all the deployments that their team made for a year. Uh and uh after I was fired uh this person was as well. Uh so what did I learn? Um I learned that this is a reference to Silicon Valley. Um in order for a um transformation to be successful, obviously it needs to be top down, right? You need to have executive and leadership support. Obviously it needs to be bottom up. You need to have support from people that are actually doing the work, you know, at the leaves of the organization. But also, I think the key thing that I would do better if I went uh went back again is middle out. By which I mean engaging peer leaders like laterally in the organization and getting them excited about the work as well. Um just like the internet, uh when you see resistance, you should route around it as opposed to like going right up against it. And unfortunately, my personality is the second, not the first. Um I think also it's important to see the whole board. So it's not just important you know to make technical improvements which again I feel very proud about the ones that we did. Um so demonstrating the results there but also um you know there's really uh the big gap which I hope is filled sometime is kind of going upstream into that planning and making that less waterfally less like top down uh and so on. And then uh another lesson I learned is that you know it's a lot harder to change a 5,000 engineer organization than it is to change a 100 engineer organization. Uh so I work at a 100 engineer organization which is called Thrive Market and I'm very happy at transforming that. So uh thanks very much. I think we might have some time for questions. Fantastic stuff Randy. Thank you so much. Any Oh hands already up. Fantastic. Uh thank you for sharing your voyage and journey. Um I had a question about number two, the route around resistance. Like do will that feel people left out of the conversation? Like how do you manage the FOMO that can almost feel like being threatened because in some ways it feels like they're being pushed aside? — Um yes. Uh I Yeah. So I mean I think you're assuming a little bit in the question, but there's nothing wrong with that. Um, I mean, I'll say two things. I'll say it can again in a culture of fear, pointing out that somebody could be better can be perceived as threatening. Does that resonate with people? I mean, you know, people can be better, but like if you're in a culture of feeling very fearful, pointing out, hey, you're two, whatever that is, you could be three. Um, that can feel threatening to people. And so again, rather than in my kind of naive and straightforward way, hey, you should really be three and I'll help you make I'll help you be three, like I'm here to help you be three. Instead, maybe like leave that for the moment and do something else. Is there the possibility that someone would have a have FOMO and feel left out like that's actually that would be a good thing, right? So like oh, you know, you guys don't want to be helped like that's cool. That's all right. Like I'm going to start over here. And then uh this did happen over these five years is like teams would see, oh wow, you know, you doubled the productivity of that team over there. I won a little bit of that. So I think your question is exactly the way that it should work when it works well if that makes sense. So thanks Sid. Anything else? Got one. — So thanks for the great story, Randy. Particularly the honesty and the calling out the things. I think you're in a really interesting point because I find when companies sort of come to this bad place, the mistakes were made 5 to 10 years before. And so I'm interested like sort of circa 2015 like what had to change at eBay to sort of avoid this bad culture to avoid like have you thought through like what you would do differently in your first in um I mean I thought a lot about what I would do differently. Um, I mean to your specific point, I was there from 2004 to 2011 as an individual contributor on the search engine and then I did other things for 9 years and then I went back in 2020. So I actually don't know what was there in 2015. Um but I think your general point of the seeds of this is true at any place the seeds of today's challenges were seown not even a year ago often but like 5 years 10 years 15 years I mean I think that's really right there's a reason why there's a culture around companies right like Google has a culture Amazon has a culture Netflix has a culture right so like these things are long are longived um and what would I do differently I mean I you know I thought a lot I don't know it's this talk um — what should the company have done differently I mean I so many I mean like I don't know resolve these issues right like talk about instead of doing I mean as an example instead of doing like instead of only doing yearly planning it's good to do yearly planning because it's good to have a plan but then you should be able to deviate from it you know and all aspects of this like these are all things that I would change and I'll just say again like I there's so many people that I really like and respect at the company and I want it to be successful. I genuinely do. Um and yeah, like this is one of those like this is maybe my plea to the world like please help them make it better. Like I couldn't one more quick question. Yeah, perfect. — Steps in. In my experience, right, [clears throat] culture tends to be top down and as you have executives rolling over, right, sometimes it can be hard to sustain. I mean, how do you keep up the is it the middle out kind of an approach to be able to build a foundation for that culture that would survive uh executives rolling over? — It's a good question. I mean, executive change is a thing. It wasn't a thing that affected this work, although it totally does other work. just as a factual matter about this particular transition or transformation rather. It wasn't really about executive change. It's actually more about executive not change if you see what I mean, right? I mean that's open and honest, right? Like um that's kind of what I was trying to hint at. It I mean look uh I don't know top down is a thing, right? It's a thing in the world. Like I'm a top right in my current I have an S in my title. Um uh and also um and yeah and it can be challenging both as um executives change and like the new person comes in with new crazy new ideas that are totally different or alternately uh executives don't change and they keep the old way of doing it. So like there's kind of what's it what's the anacarina principle? It's like every unhappy family is unhappy in different ways but every happy family is the same. Yeah. It's kind of that right. So, you want just enough change if that makes any sense. You kind of want the Goldilocks situation. I think we are out of time. — Perfect timing, Randy. Yeah. — Join me once again. Thank you, Randy. —

---
*Источник: https://ekstraktznaniy.ru/video/51771*