Randy Shoup on eBay: Engineering Sped Up, the System Did Not

This is an excellent talk, with so many hits close to reality that I kept getting déjà vu while listening. And the story already has a first act: in 2023 I covered how Randy Shoup and his team doubled engineering productivity at eBay. The new talk is the uncomfortable second act. The technical transformation worked, yet in Shoup's assessment the business trajectory and executive culture barely moved.

Shoup was eBay's Chief Architect and VP of Platform Engineering from 2020 to 2022. According to his talk, the Velocity initiative delivered 2× more features and bug fixes per unit of time. Deployment frequency improved 10×, lead time fell from 10 to 2 days, and change failure rate and time to recover improved 3×. These are numbers from the speaker and his slides, not an independent audit. The scale is still striking: roughly 5000 engineers at the company; Velocity eventually covered 400 product teams and 4500 applications and services.

There was no secret framework. Teams were asked: if you had to deploy every day starting tomorrow, what exactly would stop you? Their answers became the Platform Engineering backlog. The work then covered build, test, and PR validation time; deployment and upgrade automation; a shared staging environment; DORA as outcome metrics; and developer friction as an input signal.

The interaction model mattered more than the tooling. Senior platform ICs embedded with product teams, leaders synchronized daily, teams shared local automation, and Security, Compliance, Accessibility, and Localization stopped acting as external gates and became participants in improving flow. They started with pilots, expanded in quarterly cohorts, and repeated the cycle: find the bottleneck, remove it, then see which problem just got promoted.

Shoup then asks the uncomfortable question: if engineering productivity doubled, why did it not turn the business around? His answer has three layers.

1️⃣ Strategy and planning The annual plan was built centrally and locked in for a long time. Work was funded only if it was large enough to become an executive-level initiative; smaller changes survived by hitching a ride on giant programs. New evidence arrived, but the course could no longer change.

2️⃣ Execution Releases involving dozens of teams and years of work remained normal. Leaders were rewarded for delivering the promised list, not for moving a customer or business metric. The feature factory produced more features — exactly as requested.

3️⃣ Culture Using Ron Westrum's typology, Shoup describes it as pathological: fear of mistakes, searching for someone to blame, zero-sum executive competition for scope and headcount, and Not Invented Here. In that system, caution is not a defect in individual people but a rational survival strategy. This is where the déjà vu becomes strongest. Speeding up CI/CD is politically easier than changing budgeting, decision rights, and incentives. You can give teams an excellent road, but if the route was fixed 18 months ago, they will simply arrive at the wrong place faster.

In hindsight, Shoup argues that support from the CEO above and enthusiasm from teams below were insufficient: transformation also needs a middle-out coalition with peer leaders whose boundaries and incentives it inevitably affects. His account of the culture and his firing is one participant's version, not an independent investigation. That is also what makes the talk valuable: he is not selling another transformation playbook; he is showing the limits of one that already succeeded.

And in 2026 it is impossible to miss the AI sequel. If agents accelerate code production without improving task selection, feedback, and decision-making, the feature factory merely gets a larger engine. Before asking "how much faster did we get?" it is worth asking a different question: "is engineering speed even the constraint on the outcome of the whole system?"

#Management #Leadership #Culture #DevOps #PlatformEngineering #Engineering #Metrics